Please don’t do this (v2v and p2v requests that are wrong)

Using v2p to get around Oracle support contracts

Problem: Oracle won’t support the database in a virtualized environment. If you report a bug, they’ll ask you to reproduce it on a supported (ie. physical) machine.

Wrong solution: We’ll run Oracle in a VM. When we run into trouble, we’ll use a V2P tool to convert the virtual machine to a physical machine!

Why this is wrong: Conversion involves copying the disks, ripping out device drivers, adding new device drivers, fiddling with configuration files, doing resize ops on filesystems, and reinstalling the boot loader. These are (a) slow, (b) very intrusive, and (c) liable to break. This is all a recipe for turning a small disaster (ie. my database is down) into a very big disaster (my database is still down and the hairy support “solution” took 6 hours and didn’t work).

Good solution: Oracle are probably right that you shouldn’t try to run your database virtualized. But assuming you want to ignore that advice, put your database and its files onto a separate SAN LUN. When you need support, detach the LUN from the virtual machine and reattach it to a physical machine. This operation should be instantaneous and doesn’t involve any modification of the data.

Using p2v and v2p to test upgrades

Problem: It’s not easy to test an upgrade on a production physical machine.

Wrong solution: Virtual machines let you snapshot, test your upgrade on the snapshot, and if it’s bad you just throw away the snapshot. Therefore to test our upgrade, we’ll convert the physical machine to virtual (P2V), do the test, and if it works we’ll convert it back to a physical machine (V2P)!

Why this is wrong: Conversion involves a slow disk copy and a very intrusive set of modifications to the configuration. P2V followed by V2P is not a symmetric operation that leaves you with an identical machine. More than likely it’ll simply break the machine, and if it doesn’t, then drivers could be less than optimal after the conversion. Plus (unlike with virtualized environments) your physical machine is a one-of-a-kind system, and if you break it with a hairy set of P2V and V2P operations you can’t just roll back to a previous snapshot.

Good solution: Virtualize your workloads! If you don’t want to do that, use a filesystem like btrfs/ZFS that lets you do cheap snapshots, or use the snapshot feature of your SAN. In any case, always arrange your production environment so that you have a staging mirror on which to do tests before you deploy anything to production, and have a tested back-out plan.

Using multiple v2v steps

Problem: We don’t have a conversion tool that can do (eg.) Citrix Xen to KVM in one step.

Wrong solution: We found something on the web that can do Citrix to VMware, and Red Hat have a great tool for doing VMware to KVM, so we’ll just run one after the other!

Why this is wrong: Conversion involves a large set of intrusive changes on the guest such as installing device drivers for the particular target hypervisor. Doing this in two steps means you go through two rounds of intrusive changes to your guest, and it’s unlikely that anyone has tested both together. Most likely it’ll break, or leave your guest with conflicting device drivers.

Good solution: Sorry, but at the moment there isn’t a good solution, but that doesn’t mean you should use the bad solution. It could be your best bet is to reinstall the guest from scratch on the target VM.

P2V and V2V: new release

Matt has just released virt-p2v and virt-v2v 0.8.5. Packages will be available in Fedora 16 updates-testing shortly. Read this for the full instructions:

https://www.redhat.com/archives/libguestfs/2011-December/msg00061.html

virt-p2v, virt-v2v in Fedora 14+

I have built latest virt-p2v and virt-v2v packages for Fedora 14, 15, 16 and Rawhide. These are highly experimental and may not work, but please help us to try them out.

virt-p2v Rawhide
virt-p2v F16
virt-p2v F15
virt-p2v F14

virt-v2v Rawhide
virt-v2v F16
virt-v2v F15
virt-v2v F14

For virt-p2v you have to run virt-p2v-image-builder. For more details see the virt-p2v and virt-v2v home page.

If you find problems, join us on #libguestfs on FreeNode, or post to the virt-tools mailing list.

New virt-p2v and virt-v2v page

I’ve added a virt-p2v and virt-v2v page describing the new version and where to get all the sources etc.

libguestfs, virt tools, virt-v2v, virt-p2v Summit video

The video is up here. It’s only available to Red Hat subscribers. You’ll need an RHN account of some sort for access.

The handouts which go with the talk are here.

Thanks to Sean Huck who did a good job editing the video into shape.

Red Hat Summit: hand-outs for our talk

Thanks to everyone who came to our Summit talk this year. We must have had over 200 people there.

There will be a video — it’s not up yet.

In the meantime, here are the hand-outs which contain background, documentation and worked examples. Both are PDFs:

• My hand-out (libguestfs, virt tools)

• Matthew Booth’s hand-out (virt-v2v, virt-p2v)

Reminder: Summit talk on libguestfs, virt-v2v

Anyone who’s coming to the Red Hat Summit next week (Boston USA, May 3-6), please remember to drop in at our talk on libguestfs, the virt tools, virt-v2v and virt-p2v. It’s on Wednesday morning at 11.30am.

I will be live demonstrating guestfish, virt-resize and more. Matt will be showing us virt-v2v and the new version of virt-p2v that he has written.

To head off the expected question: Will the slides be available after the talk? Mine won’t because I don’t really “do” slides. However there will be a handout available (either on this blog or on the summit web pages or both) which covers all the background material and contains additional worked examples and exercises. We are hoping the talk will also be videoed like last year.

New virt-p2v screenshot

Poor man’s P2V

(P2V = physical to virtual, taking a physical machine and converting it into a virtual machine)

What happens when you have an old server sitting in the corner — the hardware is flaky and you need to set up a virtual equivalent ASAP, but no one can remember how that old server is configured? People will sell you very expensive software to solve this problem for you.

But if you have some time and patience you can do P2V conversions by hand for free, and it’s not too hard. Here’s how.

First of all, grab a bootable Linux rescue CD. A Fedora CD in rescue mode will do just fine, but choose any Linux CD that you’re happy with.

Now you boot your machine from the CD, so that we are in a modern, Linux-based OS. From the Linux command line you will see the physical disks in the machine like /dev/sda or /dev/hda (check /sys/block).

All you do is take each physical disk in turn and copy it complete over to your virtualization host. Just do:

dd if=/dev/sda | ssh root@virthost 'cat > /var/lib/libvirt/images/guest.img'

That makes a block-for-block identical copy of the hard disk, and it usually takes several minutes to an hour to copy everything across, depending how fast the old server and the network is.

Now over to your virtualization host, how do you boot this?

With very recent versions of virt-install there is a virt-install --import option that you can use to import disk images directly.

Alternately, write a libvirt XML configuration file for the virtual machine. It’s usually best to start off with an existing XML configuration, so just pick another guest at random and do virsh dumpxml foo. Take that output, modify it suitably, make sure it’s full virt (“hvm”), and boot using:

virsh define guest.xml

Now at this point it may not in fact boot. You might need to edit a few things inside the virtual machine disk image, typically /etc/fstab, maybe install a new kernel, perhaps edit the network configuration.

Step forward: guestfish and virt-edit.

$ guestfish -i guest.img
$ virt-edit guest.img /etc/fstab

(Note: I am the author of virt-p2v which is currently in a big version 2.0 rewrite).