Moving to KVM from VMware [day 19 of 20-days-of-posts series]

I'm a long time VMware Workstation user. I've been using the product since VMware Workstation version 5.

I use VMware for various purposes, including:

• gaining experience with middleware products -- such as installing Oracle RAC across multiple instances, practicing concepts of load balancing, failover and replication
• setting up development environments for compiling and debugging in heterogeneous environments (OS X for apple development, emulators for android, etc)
• for running legacy Windows-only applications (the list grows shorter by the day)

I've tried to make the transition to the open-source KVM (Kernel-based Virtual Machine) as seamless as possible.

As a product offering, VMware is a much more mature (well, given it has many years on KVM) and more user friendly experience. With that said, the potential for KVM long-term is very interesting to me. It does have the possibility and movement to eventually eclipse VMware.

As I go along, I've tried to make things as close to resembling the ease of VMware as close as possible.

KVM vs Qemu

You'll see the two terms often intermixed. Qemu came first and uses emulation to power virtual machines. KVM uses isolation but there is no emulation --guest are isolated from eachother and from the host, but the processing is routed through the same kernel that boots up your Linux host [if you haven't realized yet, KVM is a Linux-only solution -- images from VMware can be exported to KVM and vice-versa]. KVM also requires your have a CPU that supports virtualization (vx-d) -- which also means your host needs to be 64bit (although not all 64bit systems have virtualization support).

Installation:

One of the advantages of KVM over VMware is the ease of installation. The Kernel automatically always contains the most up-to-date drivers for KVM. Unlike with VMware where kernel updates often require hacking VMware kernel modules to make them compatible with Kernel changes, any new Kernel will always contain everything needed to start using KVM.

To install KVM in a Debian-based distribution, use apt-get and install kvm:

sudo apt-get install kvm

To install a GUI based manager install virt-manager:

sudo apt-get install virt-manager

To get a lot of the ease-of-use features that VMware has, such as copy-and-paste between host and guest, install Spice Guest tools in the guest system.

http://www.spice-space.org/download/binaries/spice-guest-tools/

To make use of these host and guest integrated tools (which closely resemble VMware guest tools), you'll need to make the following changes in the KVM configuration for the guest image:

• change Video type to QXL
• add Controller Virtio Serial, model Default
• change Display to spice

Issues:

Some of the issues I've noted:

• USB Default vs USB 2 support

The default USB controller will default to USB 1.1 support. You need to remember to change it from USB Default to USB 2. A caution about USB 2 support -- you won't be able to pause the guest (memory to disk file) for a guest using this controller type. You'll get some obtuse error, but the origin of the error is traced back o the USB 2 controller supplied with KVM.

The USB 2 support is limited to Windows 7 or later guests, including Linux.

 It is almost best to delete USB altogether if you are not planning on plugging in USB devices into the guest.

• Forget about iOS device support with iTunes

No matter of fiddling with drivers will get iTunes to successfully detect your iOS device. The OS will see the device, you'll see the device drivers are loaded, but no matter how much you fiddle with it, iTunes will simply never see the iOS device even if the OS has no issue seeing the device. Use VMware if you need to manage iOS devices.

• Forget about hoping to install OS X

It is a well known fact that the support is simply not there to correctly boot up a OS X guest. The issues are many and never ending. Perhaps someday. Use VMware if you need to install OS X.

• Remember to select Architecture i686 if you are installing a 32bit guest

If you are using a 32bit guest, there is no need to have the architecture type as x86_64. Having it set to x86_64 will simply prevent you from loading the image on a 32bit guest without hacking the configuration file to force i686 support.

• Pausing a guest (memory to disk) will often render spice tools useless

Pausing a guest and resuming it at a later time has some lingering problems. Most often the instance will freeze. It is not a hard freeze, and pausing and unpausing the image sequentially will cause the virtual machine to kick back in. However, the spice tools (to copy and paste between guest and host) tend to stop working (until after system reboot)

Snapshots:

KVM has a concept of snapshots that are not the same as VMware.

In VMware, I've used snapshots often to create "reference points" for my VMs, so that at a later time I can easily "flash back" to the previous snapshot in time.

In KVM, a snapshot is a running instance that you can perform any changes on it that you want, but when you shutdown the instance, all the changes are lost.  So inessential,  if you want to play around and try something that is potentially destructive, you would use a snapshot so that your original VM is not affected.

VMware snapshots are very similar to VMware cloning. Cloning is supported in KVM, and therefore, there are manual means to emulating VMware's snapshot behaviour.

KVM - Creating snapshots using cloning: 

background information:

images are stored in /var/lib/libvirt/images

image configuratin files are stored in /etc/libvirt/qemu

qcow2 is the image type that I recommend using (easiest to clone, to extend, to manage etc)

0) Probably a good idea to close virt-manager.

1) Create a cloned copy of an image:

sudo qemu-img create -f qcow2 -b /var/lib/libvirt/images/<vm name>.qcow2 /var/lib/libvirt/images/<vm name>-<snapshot-name>.qcow2

2) Copy image configuration file:

cd /etc/libvirt/qemu/
copy <vm name>.xml <vm name>=<snapshot-name>.xml

3) Edit configuration file created in #2 by modifying the name of <vm name>.qcow2 to <vm name>-<snapshot-name>.qcow2

We won't bother changing the name of the VM. Doing so would require us to generate a new UUID, which has further complications. Since the expectation is that I'd only have one instance of a snapshot running at a time, this is not a problem. Likewise in VMware, you can only run one snapshot at a time.

Because we are not generating new UUID or modifying any other instance configuration, the snapshot would not require re-activation of a Windows guest.

4) Load the snapshot definition:

virsh define <vm name>-<snapshot-name>.xml

Start virt-manager (you could also load the image directly with a virsh start <vm name>-<snapshot-name>).  If you open the VM, you should see that the name is the same as the original, but if you look at the image file source, it should be <vm name>-<snapshot-name>.qcow2.  This would be the instance loaded when you start the instance.  If, instead, you want to load the original, you would run #4 again but providing the original .xml file.  Note that like snapshots in VMware, once you move back to an older snapshot, snapshots afterwards become out of date and invalid.  Therefore, if you are expecting to use multiple snapshots for an VM, you should fork them off the original instance and not off eachother.

The data stored in the image of a snapshot is the changes (delta) that is incurred compared to the source image.  Therefore, if you start your source image up and make changes to it, the deltas (or snapshots) may become invalid (you would get disk corruption errors starting up the snapshots).

Here's my way of managing images:

After creating a base image (consisting of an OS install), I just make enough modifications to get the instance working.  I would save this instance as <vm name>.

I create a snapshot called <vm name>-start.  I immediately make the original image, <vm name>.qcow2, write protected (chmod 444).  This would prevent any accidentally start ups.

I apply all my customizations and make <vm name>-start a good "starting image" for other images.  I would have all my standard applications that I would require regardless of what an image would be used for (such as installing chrome).  After I'm done, I would write-protect this image as well.

At this point I would make snapshots based off <vm name>-start.  I could make multiple, each signifying its own purpose.  I can swap between them by using the virsh define command.  Because all the snapshots are forked off <vm name>-start as long as I don't start that snapshot (or its parent), then I won't have any problems invalidating any of my snapshots.

If I have an instance called <vm name>-eclipse, which houses say an eclipse development environment, if I ever wanted to make a major change to it that I want to try out, such as an SDK upgrade, I can create a snapshot of this snapshot called <vm name>-eclipse-updated.  I can play around with the new snapshot, test things out, and decide at the end to either keep the snapshot or toss it out.  If I keep the new snapshot in replacement of the original, I go ahead and write-protect the <vm name>-eclipse so that I don't accidentally start it up again.

Because we are using qcow2, the images and their descendants will be relatively conservative on disk consumption (remember to not pre-allocate space) since the snapshots are all deltas of the original (duplication of data is a minimum).