virt-v2v is a small program for converting guests from VMware or Xen, to run on KVM, RHEV-M or OpenStack. For RHEL 7.1, I am rewriting and enhancing virt-v2v, so it’s much faster and easier to use.
To install, follow the instructions here for setting up the yum repository, and then you can do:
yum install virt-v2v
To use it, start with the manual here that has lots of examples and the full reference documentation.
I was asked about this today and realized it’s not very well documented in the virt-builder manual page. So here goes.
Firstly you have to (as root) drop in the file
[local] uri=file:///home/YOUR_USERNAME/builder/index proxy=off
As non-root, create the
~/builder directory (you can of course put the repository somewhere else). Drop in the disk image — in the example below it’s called
os-image-1.xz, and next to it the following
[os-1] name=OS-1 arch=x86_64 file=os-image-1.xz checksum[sha512]=place the sha512sum of the compressed file here format=raw size=place the uncompressed virtual size of the disk image here compressed_size=place the compressed size of the disk image here expand=/dev/sda3 notes=My wonderful cloud OS, version 1
You only need the
expand field if you want image resizing to work (ie. the virt-builder
--size option), and other fields are documented in the manual. To get the uncompressed virtual size of a disk image, use
Other cloud image formats like qcow2 or uncompressed raw are possible, but you’ll need to read the manual closely and experiment a bit.
Itanium was Intel’s attempt to cause all other workstation processor manufacturers to run around like Chicken Little until they ran themselves out of business. It worked surprisingly well. In the end, HP put down Alpha and PA-RISC, and MIPS sold itself for $100m.
But enough history, Itanic might have failed in the marketplace, but that means you can pick up servers on eBay for £58 (and that includes tax and delivery — all 22 kg of it).
Above: Three 64 bit servers you probably don’t own: X-Gene (ARM 64 bit), HP Itanium RX2620, Mac G5 (PPC64)
This server has no hard drive, and requires UltraSCSI 320 disks,
so I’m going to try PXE booting it [see below] into RHEL 5 and see if I can use a ram disk (it has a very generous 16 GB of RAM), or failing that, use a USB disk.
The interior is not that interesting as most of the important bits are covered up with ducting to push the incredibly noisy airflow to the right places:
On the back:
- Dual power supplies!
- Dual 1 GbE, plus one 100 Mbps ethernet!
- 3 serial ports! I’ve never seen that excessiveness on a server before.
The machine has dual CPUs running at 1.6 GHz and 16 GB of RAM. It was almost worth the cost just for the RAM.
I tried fairly hard to get it to PXE boot into ELILO, but it wasn’t having any of that, so now I’m downloading the RHEL 5.10 DVD.
If you ever used the old version of virt-v2v, our software that converts guests to run on KVM, then you probably found it slow, but worse still it was slow and could fail at the end of the conversion (after possibly an hour or more). No one liked that, least of all the developers and support people who had to help people use it.
A V2V conversion is intrinsically going to take a long time, because it always involves copying huge disk images around. These can be gigabytes or even terabytes in size.
My main aim with the rewrite was to do all the work up front (and if the conversion is going to fail, then fail early), and leave the huge copy to the last step. The second aim was to work much harder to minimize the amount of data that we need to copy, so the copy is quicker. I achieved both of these aims using a lot of new technology that we developed for qemu in RHEL 7.
Virt-v2v works (now) by putting an overlay on top of the source disk. This overlay protects the source disk from being modified. All the writes done to the source disk during conversion (eg. modifying config files and adding device drivers) are saved into the overlay. Then we qemu-img convert the overlay to the final target. Although this sounds simple and possibly obvious, none of this could have been done when we wrote old virt-v2v. It is possible now because:
- qcow2 overlays can now have virtual backing files that come from HTTPS or SSH sources. This allows us to place the overlay on top of (eg) a VMware vCenter Server source without having to copy the whole disk from the source first.
- qcow2 overlays can perform copy-on-read. This means you only need to read each block of data from the source once, and then it is cached in the overlay, making things much faster.
- qemu now has excellent discard and trim support. To minimize the amount of data that we copy, we first fstrim the filesystems. This causes the overlay to remember which bits of the filesystem are used and only copy those bits.
- I added support for fstrim to ntfs-3g so this works for Windows guests too.
- libguestfs has support for remote storage, cachemode, discard, copy-on-read and more, meaning we can use all these features in virt-v2v.
- We use OCaml — not C, and not type-unsafe languages — to ensure that the compiler is helping us to find bugs in the code that we write, and also to ensure that we end up with an optimized, standalone binary that requires no runtime support/interpreters and can be shipped everywhere.
There haven’t been too many updates around here for a while, and that’s for a very good reason: I’ve been “heads down” writing the new versions of virt-v2v and virt-p2v, our tools for converting VMware and Xen virtual machines, or physical machines, to run on KVM.
The new virt-v2v [manual page] can slurp in a guest from a local disk image, local Xen, VMware vCenter, or (soon) an OVA file — convert it to run on KVM — and write it out to RHEV-M, OpenStack Glance, local libvirt or as a plain disk image.
It’s easy to use too. Unlike the old virt-v2v there are no hairy configuration files to edit or complicated preparations. You simply do:
$ virt-v2v -i disk xen_disk.img -o local -os /tmp
That command (which doesn’t need root, naturally) takes the Xen disk image, which could be any supported Windows or Enterprise Linux distro, converts it to run on KVM (eg. installing virtio drivers, adjusting dozens of configuration files), and writes it out to
To connect to a VMware vCenter server, change the
-i options to:
$ virt-v2v -ic vpx://vcenter/Datacenter/esxi "esx guest name" [-o ...]
To output the converted disk image to OpenStack glance, change the
-o options to:
$ virt-v2v [-i ...] -o glance [-on glance_image_name]
A talk by Jon Masters:
All the Fedora Flock 2014 talks are here: https://www.youtube.com/channel/UCQIXiF6fxPCtHw_XwHFq6nA