[BETA] [HPE] Migrated VMs from VMware Compatibility issues

[dcolpitts]

VMs migrated from VMware using the native VME migration tool. Not being support / not working is a pretty major issue long term as I converted one customer site last week in this manner. Any hope of work around or fix for this? Is it just a matter of upgrading the compatibility of the qcow2 images from 0.10 (which is what the migration tools create them as) to 1.1 (which is what VME natively creates new disks as) with qemu-img?

dcc

[dcolpitts]

Yes!!! I managed to get imaged based backup of a VMware Migrated VM, without completely recreating the VM. Still need to do some work get the method worked out and documented though.

[dcolpitts]

When attempting to backup VMs migrated from VMware to HPE Morpheus VM Essentials using the native HPE VME migration mechanism using the Veeam Plug-in for HPE Morpheus VM Essentials (VeeamPluginHpeMorpheusVme_13.1.0.206.BETA.exe), the back job fails with:

Failed to perform backup: Failed to start the backup job: internal error: unable to execute QEMU command 'transaction': Can't make bitmap 'VeeamCheckpoint-4585a37c-0c67-47c5-81c2-9ea33917119c-d8917f3e-6329-4464-bbe8-fa08889c190b' persistent in 'libvirt-1-format': Cannot store dirty bitmaps in qcow2 v2 files (0:00:11).

Upon further investigation, it appears that that the native HPE VME migration mechanism creates the qcow2 disk images with compatibility version 0.10. When you create a new VM in VME, the qcow2 disks images are created with compatibility version 1.1.

When you reconfigure a VM and move the disk from one datastore to another datastore, the moved disk will be converted to version 1.1. Once the disk is converted to 1.1, then Veeam is able to create the checkpoint, and backup runs. I was able to successfully do an image based backup of an AD controller I converted using the native HPE VME migration mechanism last Tuesday after I move it to a new datastore and then back this morning. And then I was able to restore guest files from the image.

So I don't know what is not supported about it, but it appears to work once the disk format is 1.1. Note that I have NOT tested this on Linux VMs yet - only Windows. But I suspect it will be the same results.

And it goes without saying - USE THIS METHOD AT YOUR RISK! I'm assuming both HPE and VME doesn't technically support (yet).

Gostev - I sent my documentation and all the screenshots to support my findings to Andrey Stadler little while ago if you want to follow up with Andrey (or me out of band).

Good luck.

dcc

[cody.ault]

I'm running your suggested compatibility upgrade steps by HPE to make sure they're comfortable with these steps. I'll update the thread when I hear back. We do have a different work around planned for v1 but it's not in the beta.

[JaySt]

does not seem like Veeam has to be one providing the workarround/fix here. ideally should be fixed in the migration workflow of VME tooling.

[dcolpitts]

I'm not disputing that JaySt. It's being brought to the attention of the dev that built the VME migration tool today in Barcelona at HPE Discover. I don't know why they would opt to make the disks version 0.10 when everything else they do is 1.1... I'm just providing the work around I found for it.

[dcolpitts]

The other issue is that perhaps not everyone is going to have that 2nd datastore available with enough capacity to storage vmotion their migrated machines. When I was testing this yesterday, I only had 400GB of empty space on the boot partition of my host, and I had one VM that was 500GB in size (the migration tool also thick provisions the disks). Fortunately, there was only 375GB of used space inside the disk and I was able to zero the drive out with sdelete64 before storage vmotion to get it down to about 380GB of used space, and even then I had to do the storage vmotion disk by disk instead of everything at once.

So I totally agree - the VME devs should be fixing this. And there are several short comings with VME that still need addressed to be a viable alternative to ESXi for SMB.