Importing ESXi Datastore & VMs directly
-
Hi.
I've got a (free license) ESXi box that I have a couple of dozen VMs on, mostly test stuff, but a handful that run services that are public (albeit non-commercial: It's a few low traffic websites, a Mastodon instance, and a couple of games servers.) I'm looking to switch, with the least fuss and learning curve, and so far xcp-ng seems to be a good candidate.
I've set xcp-ng up on a similar box, and have tested migrating some of the smaller VMs across using the import>from VMware option. This only works if the VM is stopped, and is very slow - in the order of 2-3 hours for a 64GB drive. I think this is because of my limited licence? For most stuff I can live with this - I'd just leave it going overnight - but I'd rather not have the public services down for this long, and it's likely to be even longer as the drives are significantly larger.
Is it possible, therefore, for me to move physical ESXi datastore drives across to the new box, and either use them directly, or access and import from them to the xcp-ng data drives?
-
@irrelevant said in Importing ESXi Datastore & VMs directly:
Hi.
I've got a (free license) ESXi box that I have a couple of dozen VMs on, mostly test stuff, but a handful that run services that are public (albeit non-commercial: It's a few low traffic websites, a Mastodon instance, and a couple of games servers.) I'm looking to switch, with the least fuss and learning curve, and so far xcp-ng seems to be a good candidate.
I've set xcp-ng up on a similar box, and have tested migrating some of the smaller VMs across using the import>from VMware option. This only works if the VM is stopped, and is very slow - in the order of 2-3 hours for a 64GB drive. I think this is because of my limited licence? For most stuff I can live with this - I'd just leave it going overnight - but I'd rather not have the public services down for this long, and it's likely to be even longer as the drives are significantly larger.
Is it possible, therefore, for me to move physical ESXi datastore drives across to the new box, and either use them directly, or access and import from them to the xcp-ng data drives?
Sorry to say yes it's a limitation of the free license. In order to live migrate its required to have at least a Standard Edition license of VMware vSphere ESXi. Any edition less than this will not be able to live migrate, only migrate with the VMs stopped.
The data store drives on the VMware host can't be moved physically as XCP-ng doesn't use VMFS it can translate but can't use them in the regular sense. Also the contents of the drive when installing XCP-ng are wiped, so they can't install XCP-ng to. On top of this XCP-ng is using the Linux filesystem called ext4.
So therefore unfortunately the public non-commercial sites would need to be migrated during a planned and announced ahead of time period of downtime!There's also a free tool which will automate this process and does a really good job.
Also may I recommend a second host to pool together with the new destination?
Setting up a shared storage is required when pooling servers together.
Anyway if your running XCP-ng 8.2 you'll need to use Xen Orchestra, though it also houses a VMware to Vates migration tool otherwise known as V2V (https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/).
-
@john-c
Thanks, that pretty much confirms my thinking then. I'll keep practicing, and plan out how to best arrange things. I've got enough kit hanging about to set up another xcp-ng host, and have a dedicated storage box already talking NFS that I could set up some space on for shared storage, see how that performs. Once I'm happy it's working/will work I can work on scheduling some downtime for the public stuff.. -
@irrelevant said in Importing ESXi Datastore & VMs directly:
@john-c
Thanks, that pretty much confirms my thinking then. I'll keep practicing, and plan out how to best arrange things. I've got enough kit hanging about to set up another xcp-ng host, and have a dedicated storage box already talking NFS that I could set up some space on for shared storage, see how that performs. Once I'm happy it's working/will work I can work on scheduling some downtime for the public stuff..It's best with a dedicated storage device of its own as VMs and virtualisation can get pretty large! I have read that recommended minimum when virtualising is 2TB as this gives enough room for the VMs and disks to grow! Also you will additionally then be able to restrict access to the NFS shares and firewall port(s) for NFS to the XCP-ng hosts and Xen Orchestra (it will need access for some of its features). While the SSH (on shared storage) can be restricted to other devices you designate for access or even switched off on the hosts (XCP-ng hosts).
Also all of the VMs for the pool for the live migration feature, will need to be held on the shared storage.
Also depending on your needs you can achieve with XCP-ng access to features, which weren't available on the free license of VMware vSphere ESXi!
As part of the live migration feature, it works best if they hosts are identical as you won't then have VMs left behind unable to migrate between hosts! So with my home lab I have got two servers which were professionally refurbished, and configured to my specifications which were for them to be identical so they can be the XCP-ng hosts.
I also got another sever of the same brand and model to be installed with NAS OS software (e.g. TrueNAS) so it can host the VMs with out creeping corruption (e.g. "Bit rot"). Though the storage server can alternatively be running FreeBSD or some other OS, just beware of not "bit rot" safe filesystems.
-
@irrelevant What's the specification of the hardware of both hosts and also what's the network speed. Especially for the management network interface, as this is the one through which VMs on XCP-ng are imported and also likely exported on VMware vSphere ESXi?
The reason being if the hosts and/or network aren't that quick then the migration of the VMs from VMware to XCP-ng will take longer!
If you can connect the management network to a faster interface then the migration won't take as long to complete.