Importing VMs to KVM with virt-v2v

virt-v2v is a handy tool used to convert VMs from Xen, VMware and Hyper-V to KVM. In this post we’ll step through importing an OVA file for use on libvirt. This is a very narrowly scoped example, but the concepts are applicable to a wide range of conversions. Check the man page for a complete list of input and output options.

Consider the common scenario of a management appliance VM. It is a simple way to distribute complex software, but not all vendors can support all hypervisors. A common solution is to export the original VMs to an open standard such as OVA, then users can import the OVAs into their hypervisor.

Defining a pool for appliances

The hypervisor stores VM image files in pools. A dedicated pool will help keep VMs separate logically and/or physically. For example, the new pool could live on a different storage device. If you are going to use an existing pool, you can skip ahead to “Importing”.  

Check to see what pools are available on your hypervisor:

# virsh pool-list
Name                 State Autostart
-------------------------------------------
default               active yes

To create a separate pool called Appliances make the target directory, create and start the pool. Lastly, set it to start automatically:

# mkdir /var/lib/libvirt/Appliances
# virsh pool-define-as Appliances --type dir \
      --target /var/lib/libvirt/Appliances
# virsh pool-start Appliances

# virsh pool-autostart Appliances

Check the status of the new pool:

# virsh pool-list
Name                 State Autostart
-------------------------------------------
Appliances           active yes
default              active yes

Importing

Place the OVA file in a location that is accessible from the hypervisor. In this example the appliance is /root/third_party_appliance.ova. This is the command we’ll use:

# virt-v2v \
     -i ova /root/third_party_appliance.ova \ 
     -o libvirt -of qcow2 \
     -os Appliances -n default

The options read as:

• “-i ova /root/third_party_appliance.ova” ==  “input is an ova file called /root/third_party_appliance.ova”

• “-o libvirt -of qcow2” == “output a libvirt VM in a qcow2 file format”

• “-os Appliances” == “place the output VM in the Appliances pool”

• “-n default” == “configure the VM to use the default network”

This could take a while depending on the speed of the hypervisor and the size of the input VM. The output gives plenty of relevant feedback.

[   0.0] Opening the source -i ova third_party_appliance.ova
[   0.1] Creating an overlay to protect the source from being modified
[   0.1] Initializing the target -o libvirt -os Appliances
[   0.1] Opening the overlay
[  13.7] Inspecting the overlay
[  14.6] Checking for sufficient free disk space in the guest
[  14.6] Estimating space required on target for each disk
[  14.6] Converting Windows 7 Enterprise to run on KVM
[  15.0] Mapping filesystem data to avoid copying unused and blank areas
[  15.4] Closing the overlay
[  15.6] Checking if the guest needs BIOS or UEFI to boot
[  15.6] Assigning disks to buses
[  15.6] Copying disk 1/1 to /var/lib/libvirt/Appliances/third_party_appliance-sda (qcow2)
   (100.00/100%)
[ 132.3] Creating output metadata
Pool Appliances refreshed
[ 132.5] Finishing off

Once the import is finished, start the appliance VM and check its status:

# virsh start third_party_appliance
Domain third_party_appliance started

# virsh list --all
Id    Name                        State
----------------------------------------------------
12    third_party_appliance            running
-     cfme_demo                        shut off
-     Fedora27-test                    shut off

The process is quite simple once you break down the options. As mentioned above, the same techniques could be used for more complex conversions. The main page has examples for migrating VMs from an existing virtualization infrastructure into Red Hat Virtualization or Red Hat OpenStack Platform.

Tim Quinlan (RHCE, RHCVA) is a Technical Account Manager (TAM) in the US Central region. Since 1996, he has applied Linux geekery in a wide array of industries including retail, energy, rail control and manufacturing before coming to Red Hat.   

A Red Hat Technical Account Manager is a specialized product expert who works collaboratively with IT organizations to strategically plan for successful deployments and help realize optimal performance and growth. The TAM is part of Red Hat’s world-class Customer Experience and Engagement organization and provides proactive advice and guidance to help you identify and address potential problems before they occur. Should a problem arise, your TAM will own the issue and engage the best resources to resolve it as quickly as possible with minimal disruption to your business.

Connect with TAMs at a Red Hat Convergence event near you! Red Hat Convergence is a free, invitation-only event offering technical users an opportunity to deepen their Red Hat product knowledge and discover new ways to apply open source technology to meet their business goals. These events travel to cities around the world to provide you with a convenient, local one-day experience to learn and connect with Red Hat experts and industry peers.