@florent said in [VDDK V2V] Migration of VM that had more than 1 snapshot creates multiple VHDs:

@MajorP93 the size are different between the disks, did you modify it since the snapshots ?

would it be possible to take one new snapshot with the same disk structure ?

Sorry it was my bad indeed.
On the VMWare side there are 2 VMs that have almost the exact same name.
When I checked for disk layout to verify this was an issue I looked at the wrong VM.

I checked again and can confirm that the VM in question has 1x 60GiB and 1x 25GiB VMDK.

So this is not an issue. It is working as intended.

Thread can be closed / deleted.
Sorry again and thanks for the replies.

Best regards
MajorP

@wmazren I had a similar issue which costed my many hours to troubleshoot.

I'd advise you to check "dmesg" output within the VM that is not able to get live migrated.

XCP-ng / Xen behaves different than VMWare regarding live migration.

XCP-ng will interact with the linux kernel upon live migration and the kernel will try to freeze all processes before performing the live migration.

In my case a "fuse" process blocked the graceful freezing of all processes and my live migration task also stuck in task view similar to your case.

After solving the fuse process issue and therefore making the system able to live migrate the issue was gone.

All of this can be viewed in dmesg as the kernel will tell you about what is being done during live migration via XCP-ng.

//EDIT: another thing you might want to try is toggling "migration compression" in pool settings as well as making sure you have a dedicated connection / VLAN configured for the live migration. Those 2 things also helped my live migrations being faster and more robust.

@florent said in [VDDK V2V] Migration of VM that had more than 1 snapshot creates multiple VHDs:

@MajorP93 the size are different between the disks, did you modify it since the snapshots ?

would it be possible to take one new snapshot with the same disk structure ?

Sorry it was my bad indeed.
On the VMWare side there are 2 VMs that have almost the exact same name.
When I checked for disk layout to verify this was an issue I looked at the wrong VM.

I checked again and can confirm that the VM in question has 1x 60GiB and 1x 25GiB VMDK.

So this is not an issue. It is working as intended.

Thread can be closed / deleted.
Sorry again and thanks for the replies.

Best regards
MajorP

@Pilow said in [VDDK V2V] Migration of VM that had more than 1 snapshot creates multiple VHDs:

@MajorP93 in your screenshot, CA and CA_1 seems to be two disks on the original VM... ?

They're even different in size.

each are suffixed with -000001-delta, indicating one snapshot, on each disk

two vmdk on source gives you two vdis on destination, as intended

Thanks for your reply.

The VM only has 1 virtual disk (60GB) on VMWare side.
Otherwise the situation would be clear and I would not have asked the question

Best regards
MajorP

Dear Vates team and community,

I am currently in the process of migrating our whole internal VMWare infrastructure to XCP-ng / Xen Orchestra.

I am using the new VDDK based V2V tool for this matter.

I noticed that when having more than 1 snapshot for a VM on the VMWare side the V2V tool will create multiple VHDs even though the VM only has 1 virtual disk on the VMWare side.

After migration the disk layout of the VM looks like this:

My question is: is it possible to merge these into 1 single VHD so the disk layout matches the one of the VMWare side?

And: is it possible to have 2 snapshots per VM on VMWare side and prevent this from happening so that the resulting XCP-ng VM only has 1 VHD per VMWare VMDK?

Thanks a lot in advance!

Best regards
MajorP

@wmazren I had a similar issue which costed my many hours to troubleshoot.

I'd advise you to check "dmesg" output within the VM that is not able to get live migrated.

XCP-ng / Xen behaves different than VMWare regarding live migration.

XCP-ng will interact with the linux kernel upon live migration and the kernel will try to freeze all processes before performing the live migration.

In my case a "fuse" process blocked the graceful freezing of all processes and my live migration task also stuck in task view similar to your case.

After solving the fuse process issue and therefore making the system able to live migrate the issue was gone.

All of this can be viewed in dmesg as the kernel will tell you about what is being done during live migration via XCP-ng.

//EDIT: another thing you might want to try is toggling "migration compression" in pool settings as well as making sure you have a dedicated connection / VLAN configured for the live migration. Those 2 things also helped my live migrations being faster and more robust.

@Andrw0830 I am using paid version of ESXi / vSphere.
The free version of ESXi has so many limitations that I consider it pretty much unusable / only usable for very limited basic tests.
It would not suprise me if your issue is due to the license limitations within ESXi.

@Andrw0830 For me V2V also shows a blank status for VDDK and I am using version 9.0 of the .tar.gz aswell.
Import of VMs from ESXi works fine and VM get’s shut down on the ESXi side automatically. I do have the little quirks mentioned before though.

@olivierlambert said in XOA 5.110 - Import from VMWare shows "vddk:" without ok or checkmark status:

Is it clear in our doc @Danp to make a snapshot on the VM we want to live migrate, and ourselves? (ie it's not done via the V2V automatically?)

I was also performing tests with the new V2V VDDK feature and noticed that it is required to manually create snapshots on VMWare side.

I was wondering: is there any particular reason that V2V is not creating the snapshots automatically?

I think if it would create the snapshots automatically it would be a great improvement and make the feature more intuitive to use.

Another thing that I noticed:
after successful migration by V2V VDDK tool the resulting VM on XCP-ng side has 2 snapshots:

Are they required? Can they be deleted automatically by V2V feature?

In the old V2V implementation (without VDDK) I did not have these snapshots after successful migration.

Anyways: thank you so much for this great product, I am currently preparing the migration of our internal infrastructure from VMWare to the Vates stack and am feeling great so far about the product and the community!