The virt-v2v Guide to Efficient VMware VM Migration

Running the virt-v2v conversion

Now we will look at the basic syntax and parameters for using virt-v2v.

Syntax of the virt-v2v command

Running virt-v2v requires primary parameters, which include the input method, where you will define the location and the access method for your source VM and the output method for its destination.

virt-v2v [OPTIONS] -i <INPUT_METHOD> [INPUT_ARGS] -o <OUTPUT_METHOD> [OUTPUT_ARGS]

Here are the main parts of the command:

• [OPTIONS]: Flags that modify the conversion. Common flags include:
  • -v: Verbose; prints detailed information about the conversion
  • -x: Enables XML parsing (often needed for vCenter URIs)
  • –password-file: Specifies a file containing the password for the source (e.g., vCenter, ESXi root)
• -i <INPUT_METHOD>: Specifies the source of the VM
• [INPUT_ARGS]: The name or URI of the VM you want to convert
• -o <OUTPUT_METHOD>: Specifies the destination or “output mode”
• [OUTPUT_ARGS]: Output configuration, such as specifying the storage pool (-osd) or network bridge (-ob)

Please note that these are not the only flags supported by the virt-v2v utility; it has multiple customizations that you can use for your specific use cases. You may wish to refer to the virt-v2v official documentation for the complete parameter list.

Explanation of input/output formats

For VMware to KVM conversions, these are the only input and output formats that you will have to remember.

Common input methods (-i)

Common output methods (-o)

Examples of converting from VMware to KVM

Once you have learned the basic syntax, you can now put it into practice and perform the conversion. As previously mentioned, there are two primary methods when converting and migrating from VMware to KVM: a direct connection to vCenter or ESXI host or an offline conversion from exported VM files.

Example 1: Direct access conversion (from vCenter/ESXi)

This method involves virt-v2v connecting directly to the VMware vCenter server to pull VM data over the network.

virt-v2v -ic "vpx://[email protected]/Datacenter/Host" "vm_guest" -o libvirt -osd default

Command breakdown:

• -ic vpx://: This is the input method:
  • -i specifies the input. The c is a helper flag that connects to the libvirt instance.
  • [email protected]/Datacenter/Host is the URI that points to the VM. You must specify the username, vCenter/ESXi host, datacenter, and cluster/host.
  • Authentication is required to connect to the VMware vCenter server. You may pass the password value at the time of conversion or using the –password-file <path> option.
• “vm_guest”: This is the hostname of the VM you want to convert.

For VM sources that are hosted in standalone ESXi hosts, all you have to do is change the input method prefix to esxi:// as follows:

virt-v2v -v -x -ic vpx "esxi://[email protected]/MyVM?no_verify=1" ...

Notice that the URI for ESXi connections contains additional strings at the end. The “?no_verify=1” flag is almost always required for standalone ESXi hosts, as they use self-signed SSL certificates by default. This flag tells virt-v2v to skip the certificate check.

If you are using a self-signed SSL certificate on your vCenter, you may also append the same flag to your vCenter VPX URI.

Example 2: Offline conversion

If you used the offline process and exported the VM to an OVF/OVA package, you can perform the conversion by defining the path where the VM files were exported, as shown below.

virt-v2v -v -x -i vmx /path/to/export/MyVM/MyVM.vmx  -o libvirt -osd default
virt-v2v -v -x -i ova /path/to/export/MyVM/MyVM.ova -o libvirt -osd default

Validating and testing migrated VMs

Now that you have finished the conversion process, you have to make sure that the migrated VMs are healthy. To help, this section has laid out a few best practices on post-migration validation steps that you can follow, but note that this may not be a complete list, and you may add more checks that align with the needs of your organization.

Boot verification

Start the VM and ensure that it boots up without any issues.

Network connectivity

Check that all network interfaces are detected and set up. Test both internal and external network connections using ping or similar tools.

For Windows guests, open the Device Manager console and verify that the virtio drivers are installed without any issues. If you see any device with a warning icon signified by a yellow exclamation mark, reinstall the virtio-win package.

Disk and file system integrity

Make sure all disks and volumes are present, and run file system checks to confirm data integrity.

Performance benchmarking

After the operation, immediately start monitoring VM metrics and observe if there is anything unusual with their utilization. If you have benchmarks collected before you started the migration, it is also good to compare just to make sure that the VMs haven’t degraded in performance after the platform move.

Limitations and troubleshooting

You should be aware that activities involving live workloads have a potential risk due to some limitations imposed by the tool. To assist, this section lists out commonly known limitations and issues reported by third-party vendors and administrators that you may also face during and after the operation. Like the previous section, this may not be a complete list, and edge cases may occur in your own experience.

Unsupported features

Certain VMware-specific features, like VMs with linked clones or VMDKs that are encrypted, are not supported for conversion.

Guest OS restrictions

Older operating systems that lack virtio support may require legacy device emulation, resulting in lower performance. On the other hand, newer operating systems that are supported by virt-v2v may not be properly converted when executed on an older RHEL 7 system. So always make sure to check the compatibility matrix before proceeding.

Dynamic disk configurations

Dynamically allocated or thin-provisioned disks may expand to full size during conversion, consuming additional storage, so plan your conversion accordingly, especially when doing offline conversion operations.

Licensing dependencies

Windows guests may require reactivation after migration due to hardware abstraction changes, so make sure that you double-check your VMs after conversion and prepare your environment for operating system reactivation.