Import from VMware fails after upgrade to XOA 5.91
-
@jasonmap said in Import from VMware fails after upgrade to XOA 5.91:
@florent Nice! This latest change allowed my migration to complete successfully. Seems like the peak transfer speed was about 70Mbps. 4.77GB in 5 minutes. I'm guessing the thin/zeros made this so fast?
yay
the thin make it fast(espcially since it only need one pass instead of two in the previous api), XCP is a little faster to load xva , and there is some magic . No secret though, everything is done in publicwe invested a lot of time and energy to make it work fast, and we have more in pipeline, to make it work in more case ( vsan I am looking at you) or to access more easy the content of running VM
-
Just a quick update - I imported a handful of VMs today and was even able to move over the VM that failed on the weekend so I think that patch works @florent
-
@florent
Thanks. I have kicked off an Import but it takes 2 hours however....the first small virtual disk has now been successful whereas it was failing, so I am confident the rest will work. Will update then.Thanks
-
-
Hi, a question about these patches and thin provisioning.
My test import now works, however, it fully provisioned the full size of the disk on an NFS SR.
[root@XXXX ~]# ls -salh /mnt/NFS/d8ad046d-c279-5bd6-8ed7-43888187f188/ total 540G 4.0K drwxr-xr-x 2 root root 4.0K Feb 6 09:33 . 4.0K drwxr-xr-x 27 root root 4.0K Feb 1 21:22 .. 151G -rw-r--r-- 1 root root 151G Feb 6 10:45 1c3b93da-de07-4a4f-8229-60635bc2f279.vhd 13G -rw-r--r-- 1 root root 13G Feb 6 09:43 1eae9130-e6eb-45be-ae25-a7dcb7ee8f4e.vhd 171G -rw-r--r-- 1 root root 171G Feb 6 10:51 751b7a5f-df32-4cb1-9479-e196671e7149.vhdThe two large disks are in an LVM VG on the source and combined, use up 253 GB of the 320 GB LV. They are thin provisioned on the VMware side.
Am I wrong to expect the vhd files on the NFS SR to be smaller than what I see? Does LVM on the source negate thin provisioning on the xcp-ng side?
Not a big deal, I am just curious.
Thanks
-
thank you all, now time to do a patch release
@acomav said in Import from VMware fails after upgrade to XOA 5.91:
Hi, a question about these patches and thin provisioning.
My test import now works, however, it fully provisioned the full size of the disk on an NFS SR.
[root@XXXX ~]# ls -salh /mnt/NFS/d8ad046d-c279-5bd6-8ed7-43888187f188/ total 540G 4.0K drwxr-xr-x 2 root root 4.0K Feb 6 09:33 . 4.0K drwxr-xr-x 27 root root 4.0K Feb 1 21:22 .. 151G -rw-r--r-- 1 root root 151G Feb 6 10:45 1c3b93da-de07-4a4f-8229-60635bc2f279.vhd 13G -rw-r--r-- 1 root root 13G Feb 6 09:43 1eae9130-e6eb-45be-ae25-a7dcb7ee8f4e.vhd 171G -rw-r--r-- 1 root root 171G Feb 6 10:51 751b7a5f-df32-4cb1-9479-e196671e7149.vhdThe two large disks are in an LVM VG on the source and combined, use up 253 GB of the 320 GB LV. They are thin provisioned on the VMware side.
Am I wrong to expect the vhd files on the NFS SR to be smaller than what I see? Does LVM on the source negate thin provisioning on the xcp-ng side?
Not a big deal, I am just curious.
Thanks
LVM is thick provisionned on XCP side : https://xcp-ng.org/docs/storage.html#storage-types
-
@acomav How big are you original VM disks? (eg the total disk size on VMware)
-
@florent The VM is on an NFS SR which is thin provisioned. LVM is inside the VM on the virtual disks.
-
@olivierlambert Hi.
The disk sizes (and vmdk file size) are 150GB and 170GB. Both are in a Volume group and one Logical Volume using 100% of the Volume group mounted using XFS.Disk space in use is 81%:
# pvs PV VG Fmt Attr PSize PFree /dev/sda2 centos lvm2 a-- <15.51g 0 /dev/sdb VolGroup01 lvm2 a-- <150.00g 0 /dev/sdc VolGroup01 lvm2 a-- <170.00g 0 # vgs VG #PV #LV #SN Attr VSize VFree VolGroup01 2 1 0 wz--n- 319.99g 0 centos 1 2 0 wz--n- <15.51g 0 # lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert IMAPSpool VolGroup01 -wi-ao---- 319.99g # df -h /dev/mapper/VolGroup01-IMAPSpool 320G 257G 64G 81% /var/spool/imapThe vmdk files live on an HPE/Nimble CS3000 (Block iscsi). I am now thinking I will need to get into the VM and free up discarded/deleted blocks....which would make the vmdk sizes smaller. (as they are set to thin provisioned with vmfs)
I'll do that and retry and report back if I see the the full disk being written out to XCP-NG. -
Good idea, thanks
-
@olivierlambert
I can confirm it was my side. I had to do a few things to get the VMware Virtual disks to free up empty space and once I did, the VM Import to XCP-NG to an NFS SR successfully copied the virtual disk in a thin mode.
For anyone reading this who will be preparing to jump ship off VMware.I am using vSphere 6.7. I have not tested against vSphere 7 yet. Not bothering with vSphere 8 for obvious reasons. My VM was a CentOS 7 VM with LVM to manage the 3 virtual disks.
- Make sure you Virtual Hardware is at least version 11. My test VM was a very old one still on version 8.
- For the ESXi host the VM lives on (but you should probably go all hosts in the cluster), go into Advanced settings, and enable (change 0 to 1) VMFS3.EnableBlockDelete. I thought I had this enabled but only 2 of the 5 hosts in the cluster did. You may need to check this is not reset after updates.
- Due to using CentOS 7 (perhaps) I could not used 'fstrim' with the discard mount option. It was not supported. I filled up the diskspace with zeros, synced, and then removed the zeroes.
# cd /mount point; dd if=/dev/zero of=./zeroes bs=1M count=1024; sync; rm zeroesChange count=1024 (Which will create 1 GB of zeroes in a file) to however big a file you require to nearly fill up the partition / volume. eg count=10240 will make a 10 GB file.
Windows users can use 'sdelete'.I could have waited for vSphere to automatically clean up the datastore in the background at this stage, but I was impatient and 'storage motioned' the virtual disks to NFS storage in Thin mode. I confirmed only the used space was copied across. I then migrated the disks back to my HP Nimble SAN and retained thin provisioning.
-
Great news and also great feedback! I think we'll add this in our guide
