Xen Orchestra 5.110 V2V not working
-
@florent That's a good summary, however, V2V did power off the VM before starting the import, which defeats the point of a warm migration, and the power off is abrupt, not allowing the OS to cleanly shutdown, which means that there's a potential for data loss.
Thank you.
Edit: I was just looking at the blog post for 5.110 and I noticed this:
The interface has been polished as well. There’s now a progress bar visible from the start of the migration, speed metrics are recorded in the VDI, and snapshots are created at each step. This allows the process to pause and resume safely without needing to create multiple VMs. Finally, UEFI VMs are no longer forced into Secure Boot mode, avoiding previous boot issues.I guess I'm confused as to why I didn't see any of this?
-
@farokh do you have at least one snapshot on the source ? The data migrated while the VM is running are the data before the last snapshot
The power off is effectively a call to powerOff, is there a better alternative (that can work with or without the vmware tools installed) ?
the progress bar are visible in the task view, or on the disk tab on the VM being imported ( not yet in the form , this will probably wait for the XO6 version of this page )
-
@florent Yes, I made sure that I had a snapshot.
I guess my main question is why the VM is being powered off? It's supposed to be a warm migration, meaning the VM is running while the data is migrated, correct?
But, assuming that you have to power the VM down, and I haven't done any programming or scripting with ESXi, but I can tell you that the web interface can tell if the VM has the tools installed. If the tools are installed, you should be able to send a Shutdown request, which should shut the machine down gracefully, allowing the OS to perform tasks prior to powering off. You can wait a few minutes and if the machine hasn't powered off yet, you could then issue the power off command to stop it.
Next time I test a migration, I'll check the task and/or disk to see the status.
Thanks.
-
Hi, just wondering if there's any update on why the VMs are being shutdown for the migration.
Thanks.
-
We made a patch release of XOA, improving some aspects. Have you tried it?
-
@olivierlambert No, I wasn't aware. I'll take a look.
Thanks. -
Is there a blog or forum post about the updates? I can't seem to find anything.
Thanks.
Edit: and without the VMWare tools, there's no way to do a clean shutdown. It's, again, simply powered off.
-
Tried it again, on a different VM. I took a snapshot, and made sure that the VMWare tools were uninstalled.
The job was started at 10:57, it's now 18:42 and the job is still running.
At 12:30, the VM was shutdown and has been shut down since then.
Edit: So the import completed at some point (something like 7-8 hours), but the original VM was never started up again.
-
@florent is working on improving the details of each step so you know what's going on.
-
@farokh the VM (from source or target) are not started automatically
After the migration, the VM from on the xcp-ng host shoud be ready to start, with snapshot corresponding to the steps of the replication
this is not automatic because, for now, we put a lot of work on the disk data transfer, but there is much to do around it to ensure the VM start exactly as intended : guest tools, advanced network or storage configuration.
-
@florent The VM I ws referring to was the one on the ESXi host.
If you're providing a warm migration, then that VM should be running during the transfer.
If for whatever reason a warm migration can't be done, then the user should be made aware of that.
At this point, just to be safe, I'm going to make the assumption that the VM to be migrated has to be powered off.
-
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.
-
Hi,
- The fact is doesn't work for you doesn't mean it doesn't work for everyone. Sadly, especially in IT and on-prem, there's a near infinite combo of ESXi version, firmware, network, storage and compute associations. We do tested with at least dozens of different cases (internally and with users), and for the vast majority it works. I understand it's frustrating for you, but you cannot simply tell "it wasn't tested", making the impression we did not work at all on this despite spending weeks doing exactly that.
- That's exactly the goal of the community forum: giving feedback so we can improve it. The way you give feedback will encourage (or not) the fact we'll dedicate time with you to solve your issue on your setup.
There are actual people behind this, investing a lot of their energy into it, diminishing what they did is not helpful for anyone.
-
Hi,First off, I want to acknowledge the team's commitment and hard work. It's clear that a lot of effort has gone into testing across many different environments, and I truly appreciate the energy and dedication that everyone puts into this project.
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.
My intention was not to diminish the team's work, but to highlight a potential gap that might help improve things further.
-
@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...
-
@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
-
@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 ?
-
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.
-
It does work now since the latest version (at least for almost everyone except for people reporting issues in here)
-
@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.
