importing_vmware_vms_into_kvm.rst

Note

This functionality requires virt-v2v (https://www.libguestfs.org/virt-v2v.1.html) binary installed on destination cluster hosts (needs to be installed manually as it's not a dependency of the CloudStack agent during the agent installation).

Requirements on the KVM hosts

The CloudStack agent does not install the virt-v2v binary as a dependency. The virt-v2v binary must be installed manually on KVM hosts, or the migration will fail.

The virt-v2v output (progress) is logged in the CloudStack agent logs, to help administrators track the progress on the Instance conversion processes. The verbose mode for virt-v2v can be enabled by adding the following line to /etc/cloudstack/agent/agent.properties and restart cloudstack-agent:

dnf install virt-v2v

echo "virtv2v.verbose.enabled=true" >> /etc/cloudstack/agent/agent.properties

systemctl restart cloudstack-agent

Installing virt-v2v on Ubuntu KVM hosts does not install nbdkit which is required in the conversion of VMware VCenter guests. To install it, please execute:

apt install nbdkit

Supported Distributions for KVM Hypervisor:

.. cssclass:: table-striped table-bordered table-hover

Linux Distribution	Supported Versions
Alma Linux	8, 9
Red Hat Enterprise Linux	8, 9
Rocky Linux	8, 9
Ubuntu	22.04 LTS, 24.04 LTS

Importing Windows VMs from VMware requires installing the virtio drivers for Windows on the hypervisor hosts for the virt-v2v conversion.

On (RH)EL hosts:

yum install virtio-win

You can also install the RPM manually from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.noarch.rpm

For Debian-based distributions:

Ubuntu don’t seem to ship the virtio-win package with drivers, which causes virt-v2v not to convert the VMWare Windows guests to virtio profiles. This could result in slow IDE drives and Intel E1000 NICs. As a workaround, we can follow the below steps to install the package from the RPM on all KVM hosts running the virt-v2v:

apt install virtio-win (if the package is not available, then manual steps will be required to install the virtio drivers for windows)

wget https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.noarch.rpm

# install “alien” which can convert rpms to debs
apt -y install alien

# the conversion, can take a while
alien -d virtio-win.noarch.rpm

# install the resulting deb
dpkg -i virtio-win*.deb

In addition to this, we need to install the below package as well to avoid the error “virt-v2v: error: One of rhsrvany.exe or pvvxsvc.exe is missing in /usr/share/virt-tools“.

wget -nd -O srvany.rpm https://kojipkgs.fedoraproject.org//packages/mingw-srvany/1.1/4.fc38/noarch/mingw32-srvany-1.1-4.fc38.noarch.rpm

alien -d srvany.rpm

dpkg -i *srvany*.deb

The OVF tool (ovftool) must be installed on the destination KVM hosts if the hosts should export VM files (OVF) from vCenter. If not, the management server exports them (the management server doesn't require ovftool installed).

Steps to install ovftool

Download the ovftool from https://developer.broadcom.com/tools/open-virtualization-format-ovf-tool/latest

unzip VMware-ovftool-4.6.3-24031167-lin.x86_64.zip -d /usr/local/

#create a soft link

ln -s /usr/local/ovftool/ovftool /usr/local/bin/ovftool

If you are hitting the following error when running ovftool, install the dependecy

./ovftool.bin: error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory

dnf install libnsl

Usage

In the UI, Virtual Machines to import from VMware are listed in Tools > Import-Export Instances section, selecting:

.. cssclass:: table-striped table-bordered table-hover

Select Import-Export Source Hypervisor	Action
VMware	Migrate existing instances to KVM

Selecting the Destination cluster

CloudStack administrators must select a KVM cluster to import the VMware Virtual Machines (right side of the image above). Once a KVM cluster is selected, the VMware Datacenter selection part is displayed.

Selecting the VM from a VMware Datacenter

CloudStack administrators must select the Source VMware Datacenter:

• Existing: The existing zones are listed, and for each zone, CloudStack will list if there is any VMware Datacenter associated with it. In case it is, it can be selected.
• External: CloudStack allows listing Virtual Machines from a VMware Datacenter that is not associated with any CloudStack zone. To do so, the vCenter IP address, the datacenter name, and username and password credentials are needed to log in to the vCenter. To import from a standalone VMware host, you can use the default datacenter name (ha-datacenter or other) along with the host credentials (Only stopped VMs are supported).

Once the VMware Datacenter is selected, click on List VMware Instances to display the list of Virtual Machines in the Datacenter. You must then choose the VMware Instance for import and click on Import Instance.

Converting and importing a VMware VM

Note

CloudStack allows importing Running Linux Virtual Machines, but it is generally recommended that the Virtual Machine to import is powered off and has been gracefully shut down before the process starts. In case a Linux VM is imported while running, it will be converted in a "crash consistent" state. For Windows Virtual Machines, it is not possible to import them while running, they must be shut down gracefully so the filesystem is in a clean state.

Note

You can configure the parallel import of VM disk files on KVM host and management server, using the global settings: threads.on.kvm.host.to.import.vmware.vm.files and threads.on.ms.to.import.vmware.vm.files respectively.

In the UI import wizard, administrators can select:

• (Optional) A KVM host to perform the conversion (must have virt-v2v installed). In case it is not set, then a KVM host is randomly selected.
• (Optional) A KVM host to import the converted files into CloudStack (this host must have access to the temporary conversion storage in order to move the converted files to the destination storage). In case it is not set, then a KVM host is randomly selected.
• (Optional) Extra parameters: in case the global setting convert.vmware.instance.to.kvm.extra.params.allowed (disabled by default) is enabled, then administrators are allowed to pass extra parameters for the virt-v2v conversion command. This setting must be set along with the setting convert.vmware.instance.to.kvm.extra.params.allowed.list (empty by default) which indicates the list of parameters that CloudStack will accept for passing to the virt-v2v conversion command on the KVM hosts.

Since version 4.22 it is possible to indicate converting to storage pool directly (not using temporary storage for conversion). This is set to false by default, in which case a temporary conversion storage is used.

• When set to false (temporary storage used), then administrators must select a Temporary destination storage. The default is Secondary Storage, but if using Primary Storage - only NFS pools are supported.
• When set to true (not using temporary storage), then administrators must select the destination storage pool. The supported storage pools are: NFS, Local Storage and SharedMountPoint storage pools, under the following assumptions:

• The KVM host for conversion must be selected and must have access to the destination storage
• The KVM host for importing must be selected and must have access to the destination storage
• In case of Local storage, the selected KVM host for conversion must be the same as the KVM host for importing

Since version 4.22.1 it is possible to select the Guest OS for the VM to be imported, based on the source VMware VM Guest OS.

• When CloudStack has Guest OS mappings for the source VMware Guest OS VM, then the list of supported Guest OS is displayed and administratos can select one of them.
• In case there are no Guest OS mappings for the source VMware Guest OS VM, then the default import template Guest OS will be used.

The conversion is performed on a random (or explicitly chosen) KVM host (if the ovftools are installed), otherwise, the management server will export/copy the VM files (optionally, you can force this action to be done by the management server even the KVM hosts have the ovftools installed in it). Irrelevant if the KVM host or the management server performs the copy of the VM files (OVF), you can further either let CloudStack choose which KVM host should do the conversion of the VM files using virt-v2v and which host will import the files to the destination Primary Storage Pool, or you can explicitly choose these KVM hosts for each of the 2 mentioned operations.

When importing an instance from VMware to KVM, CloudStack performs the following actions:

• Export the VM files (OVF) of the instance to a temporary storage location (which can be selected by the administrator). The export is performed by a KVM host if ovftool is installed or management server (can be forced by the administrator, doesn't need ovftool installed on the management server). The existence of ovftool on KVM host is checked using ovftool --version command.
  • If the instance on VMware is in running state, we clone the instance on VMware and use the new cloned instance to export OVF files. The cloning process may take some time to complete and is used to ensure data consistency, disk consolidation, etc.
  • If the instance on VMware is in stopped state, we directly use the instance to export its OVF files.
• Converts the OVF on the temporary storage location to KVM using virt-v2v. CloudStack (or the administrator) selects a running and enabled KVM host to perform the conversion (of the previously exported OVF files) from VMware to KVM using virt-v2v. If the binary is not installed, then the host will fail to convert the Instance. In case it is installed, it will perform the conversion into the temporary location to store the converted QCOW2 disks of the instance. The virt-v2v conversion is a long-lasting process which can be set to time out by the global setting convert.vmware.instance.to.kvm.timeout. The conversion process takes a long time because virt-v2v creates a temporary instance to inspect the source VM and generate the converted disks with the correct drivers. Additionally, it needs to copy the converted disks into the temporary location.
• The converted instance (i.e. QCOW2 files) is then imported into the chosen KVM cluster. Administrator can choose the KVM host to perform the import or let CloudStack choose it. Only enabled cluster and enabled hosts are considered.

Note

Please do not restart the management servers while migration is in progress as it will lead to the interruption of the process and you will need to start again.

Note

As mentioned above, the migration/conversion process uses an external tool, virt-v2v, which supports most but not all the operating systems out there (this is true for both the host on which the virt-v2v tool is running as well as the guest OS of the instances being migrated by the tool). Thus, the success of the import process will, almost exclusively, depend on the success of the virt-v2v conversion. In other words, the success will vary based on factors such as the current OS version, installed packages, guest OS setup, file systems, and others. Success is not guaranteed. We strongly recommend testing the migration process before proceeding with production deployments.

Note

The resulting imported VM uses the default Guest OS type: CentOS 4.5 (32-bit). After importing the VM, please Edit the Instance to change the Guest OS Type accordingly.

VM Import Tasks

Since version 4.22 administrators can monitor the VMware to KVM migration jobs. The new section is displayed on Tools > Import-Export Instances > Migrate existing instances to KVM > VM Import Tasks:

The tasks can be filtered by state: Completed, Running or Failed, or listing all the tasks.