Xen Orchestra 5.110 V2V not working

DustinB

@idar21 said in Xen Orchestra 5.110 V2V not working:

unique configurations slip through the cracks,

In all fairness, edge cases are never tested for until you're building solutions for those edge cases.... It is a bit rough to simply throw the entire thing away because you're on an edge case and a tool built for the masses doesn't work on that edge case...

olivierlambert

@idar21 said in Xen Orchestra 5.110 V2V not working:

I certainly didn't mean to dismiss the significant work that's already been done. At the same time, I think it's important for us all to be open to constructive criticism. Sometimes, even with the most thorough testing, unique configurations slip through the cracks, and that's nobody's fault—it's just the nature of complex IT systems.

That was exactly my own point. And this forum is filled with posts of us solving bugs from people's feedback, all along from the last 10 years at least. So we do appreciate a LOT any constructive feedback: we want to fix what's broken, even for free!

I was talking about this sentence:

I don't think the tool has been tested properly.

Which doesn't sound very constructive in my opinion. That was my point, nothing more. Constructive feedback: yes. Non-constructive feedback: no.

So let's move over, to be able to assist, we need to know your XOA version (or XO commit), exact ESXi version, the kind of storage you use. That is the base of constructive feedback

florent

@idar21

@idar21 said in Xen Orchestra 5.110 V2V not working:

Don't intend to bump in but the new migration tool isn't working as per the release notes.

I had similar issues, there is no warm migration. My testing against esxi v7, resulted in:

.Abrupt power off of source VM on esxi.
.VM disks start copying. I can see disk copy progress in tasks.
.Migration tasks fails but multiple disks of the source VM keeps on copying.
.when all the disks are copied, there is no VM with the name available in xcp.
.All disks are labeled orphaned under health in xo.

.Where is the pause/resume function as stated in the release notes.

I don't think the tool has been tested properly. The only difference from older migration tool to this one is progress of disk copying. Otherwise nothing new. The old tool could only do cold migrations and had issues with vms with multiple disks. The new can also only do cold migrations and still has issues with multiple disks migrations.

First, I would like to say again that latest can be fresh, and that we know that we ask for our users to be more inventive with latest, in exchange for faster features. Even more for users from source.

The documentation is still in the work, and will be ready for sure before this reach "xoa stable". The resume part don't have a dedicated interface : you do a first migration without enabling the "stop source", and then, later you launch the same migration with stop source enabled ( or VM stopped ) and it will reuse the already transfered data if the prerequisites are validated.

Then debugging an issue with migration is quite complex, since it's involve multiple systems, and we won't have any access, nor control on the vmware part. It's even harder without a tunnel.

I will need you to look at your journalctl and check for errors during migration . Also are the failing disks sharing some specific configuration? what storage do they uses ? Is there something relevant on the xcp side ?

farokh

So just checking in to see if there's been any progress on being able to do a warm migration (e.g. with the VM running)?

Thanks.

olivierlambert

It does work now since the latest version (at least for almost everyone except for people reporting issues in here)

farokh

@olivierlambert OK, I guess I'm still waiting to hear why the VM that is being migrated is being shut down on the ESXi host...

Thanks.

olivierlambert

Question for @florent

florent

@farokh
have you got a snapshot on the source VM ?
XO won't take a snapshot for you, the snapshot need to be present before starting the migration

Also, we release a more complete documentation of V2V : https://github.com/vatesfr/xen-orchestra/blob/master/docs/docs/v2v-migration-guide.md

farokh

@florent Yes, I had a snapshot, that isn't the issue. The issue is that the VM is powered off and then the transfer begins.

Thanks.

florent

@farokh can you post a task log ( the json ) , even one of a running import, as long as it is after the power down ?

farokh

@florent Next time I attempt one, I can do that, but again, my question is why is the VM being powered down?

Thanks.

florent

@farokh AFAIK it is powered off to transfer the data after the snapshot, since the active disk is locked ( unreadable) as long as the VM is running

To be able to do a better answer I will need to see what's happening, so the task log

farokh

@florent I guess I'm confused. What then does "Warm migration for all ESXi versions" mean exactly?

Powering off a running machine is really a problem since that can lead to all kinds of corruption/data loss issues.

DustinB

@farokh said in Xen Orchestra 5.110 V2V not working:

Powering off a running machine is really a problem since that can lead to all kinds of corruption/data loss issues.

Not if you properly shutdown your VM, your applications should get to finalize all of their writes and gracefully close and if going "Start > Shutdown" causes data corruption you have some severe application issues that aren't related to the hypervisor.

farokh

@DustinB That's my point. The "Warm Migration" powers off the running machine.

DustinB

@farokh said in Xen Orchestra 5.110 V2V not working:

@DustinB That's my point. The "Warm Migration" powers off the running machine.

Are you stating that it forcibly powers the VM off, or does it gracefully execute a shutdown, IE "Start > Shutdown"?

farokh

@DustinB It forcibly powers off the VM.

florent

@farokh In case you need to ensure that the VM is powered off manually :

do the first migration without "stop source"
stop the VM properly
launch the migration . It will only transfer the data from the snapshot

florent

gracefully powering down a VM may need to go inside the VM ( through ssh/powershell) and that is something we try not to do, especially since we do not know anything on the os inside

It can be easily scripted if you know what is the type of VM running and how to authenticate inside them

DustinB

@farokh said in Xen Orchestra 5.110 V2V not working:

@DustinB It forcibly powers off the VM.

You'd have to do what Florent is saying in this case. But I question why should it matter as long as the migration completes successfully and the VM boots on your new pool...