Misleading messages during restore from backup

olivierlambert

I'm not sure to get it. If it's a restore, the source is not a SR but a BR. The question is the destination SR, so you do confirm it's a local SR to h2?

peo

@olivierlambert I can make it even more confusing

But first, you're correct about me misnaming the BR as "Remote SR".

Just found out that the machine I backed up is NOT running on xcp-ng-1, but on xcp-ng-3 (I assumed it was xcp-ng-1 because of the message):

olivierlambert

XO doesn't care where the previous/existing VM is running, restore creates an entirely new VM, so I'm not sure to get it either

peo

@olivierlambert but the "importing content" message is incorrect:
"on SR Local h2 SSD new (on xcp-ng-1)"

That's the problem (not to where it's restored to, and has to be run from because it's a local SR)..

In the message, what do "xcp-ng-1" have to do with this operation ? It's not involved at all..

olivierlambert

It's where the task is hosted. XO does not invent it, just fetch it from XAPI. It's using exactly the "resident on" field from there: https://xapi-project.github.io/xen-api/classes/task.html

So it's not an XO "problem". I don't know the mechanism behind the "resident on" logic, so pinging @Team-XAPI-Network

peo

@olivierlambert Thanks, that explains the "on .." part of the message, and as you mention, it's not a "problem", but just confusing in the context of that full message.
The optimal would of course be that the task was launched on the host that is "closest" to the SR, in this case a local SR on xcp-ng-2.

This one (unrelated list of previous tasks) makes the message more clear what the "on.." part is about:

gthvn1

@olivierlambert as you said the resident-on field of a task is set by the helper which creates the task. So the value should be the name of the host where the task has been created.

olivierlambert

And I assume the task is created on the master regardless the restore place is?

gthvn1

Not sure to understand but for example if you run xe vm-start <uuid> on slave1 but the vm is started on slave2 (because it uses a storage local to slave2) then the resident-on will be slave2. It's because the task Async.VM.start is really created on slave2 even if the initial command has been received by slave1. Does it answer your question?

olivierlambert

Partly, I will see when back from vacation Anyway, unrelated to XO