This Time Self-Hosted
dark mode light mode Search

Free virtualisation – not working yet

If you’ve been following my blog for a while you probably remember how much I fought with VirtualBox once it was released to get it to work, so that I could use OpenSolaris. Nowadays, even with some quirks, VirtualBox Open Source Edition is fairly usable, and I’m using it not only for OpenSolaris but also for a Fedora system (which I use for comparing issues with Gentoo), a Windows install (that I use for my job), and a Slackware install that I use for kernel hacking.

Obviously, the problem is that the free version of VirtualBox come with some disadvantages, like not being able to forward USB devices, having limited type of hardware to virtualise and so on. This is not much of a problem for my use, but of course it would have been nicer if they just open sourced the whole lot. I guess the most obnoxious problem with VirtualBox (OSE at least, not sure about the proprietary version) is the inability to use a true block device as virtual disk, but rather having to deal with the custom image format that is really slow at times, and needs to pass through the VFS.

For these reasons Luca suggested me many times to try out kvm instead, but I have to say one nice thing of VirtualBox is that it has a quite easy to use interface which allows me to set up new virtual machines in just a few clicks. And since nowadays it also supports VT-x and similar, it’s not so bad at all.

But anyway, I wanted to try kvm, and tonight I finally decided to install it, together with the virt-manager frontend; although there are lots of hopes for this, it’s not yet good enough, and it really isn’t usable for me at all. I guess I might actually get to hack at it, but maybe this is a bit too soon yet.

Continue reading on my blog for the reasoning, if you’re interested.
One thing I really dislike of the newer versions of VirtualBox is that it went the VMware route and decided to create its own kernel module to handle networking. They said it’s for performance reasons but I’d expect the main reason is that it would allow them to have a single interface between Linux, Windows, Solaris and so on. The TUN/TAP interface is Linux-specific so supporting that together with whatever they have been doing on the other operating systems is likely a cost for them. Although I can understand their reasoning, it’s not that I like it at all. More kernel code means more code that can crash your system, especially when not using the Open Source Edition.

Interestingly enough, the RedHat’s Virtual Machine Manager is instead doing its best to avoid creating new network management software, and uses very common pieces of software: dnsmasq as DHCP server, the Linux kernel bridging support, and so on. This is very good, but it also poses a few problems: first of all, my system already runs a DHCP server, why do I have to install another? But it’s not just that; instead of creating an userspace networking bridging software, like VirtualBox does, it tries to use what the kernel provides already, in the form of the bridging support and iptables to forward requests and create NAT zones. This is all fine and dandy, as it reduces the feature duplication in software, but obviously requires more options to be enabled in kernels that might not otherwise have it enabled at all.

As it happens, my system does have bridging support installed, but not iptables nor masquerade targets and similar. Up to now I never used them so it had no reason to be there. I also sincerely can’t understand why it does need it if I don’t want a NAT, but it doesn’t seem to allow me to set up the network myself. Which would include me being able to just tell it to create a new interface and add it to a bridge I manage myself, leaving to me all the details like dhcp, and thus not requiring iptables at all.

Also, even though there is a way to configure an LVM-based storage pool, it does not seem to allow me to choose directly one of the volumes of that pool when it asks me what to use as a virtual disk. Which is kinda silly, to me.

But these are just minor annoyances, there are much bigger problems: if the modules for kvm (kvm and kvm-amd in my system) are not loaded when virt-manager is loaded, it obviously lack a way to choose KVM as hypervisor. This is nice, but it also fails to see that there is no qemu in the system, and tries to use a default path, that is not only specific to RedHat, but also very not existing here (/usr/lib64/xen/bin/qemu-dm, on x86-64, just checking the uname!), returning an error that the particular command couldn’t be found. At least it should probably have said that it couldn’t find qemu, rather than the particular path. It would have also been nice to still allow choosing kvm but then telling that the device was missing (and suggested loading the modules; VirtualBox does something like that already).

To that you have to add that I haven’t been able to finish the wizard to create a new virtual machine yet. This because it does not check the permission to create the virtual machine before proposing you to create one, so it let you spend time to fill in the settings in the wizard and then fails telling you don’t have permission to access the read/write socket. Which by default is accessible only by root.

Even though it’s obvious by the 0-prefix that the software is still not production-level, there are also a few notes on the way the interfaces are designed. While it’s a good idea to use Python to write the interface, since it allows a much faster test of the code and so on, and speed is not a critical issue here, as the work is carried out by C code in the background, every error is reported with a Python traceback, one of the most obnoxious things to do for users. In particular for the permission problem I just listed, the message is a generic error message: “Unable to complete install: ‘unable to connect to ‘/var/run/libvirt/libvirt-sock’: Permission denied’”; what is the user supposed to know here? Of course virtualisation is not something the user at the first tries with Linux is going to use, but still, even a power user might be scared by errors that appear this way and have attached a traceback (that most users would probably rationally link with “the program crashed” like bug-buddy messages, rather than “something wasn’t as the software expected”, which is what happened.

On a very puny level, instead, I have to notice that just pressing Enter to proceed to the next page on the wizard fails, and using ESC to close the windows too. Which is very unlike any other commonly-used software.

So to cut the post short now, what is the outcome of my test? Well, I didn’t get to test the actual running performance of KVM against VirtualBox, so I cannot say much about that technology. I can say that there is a long road ahead for the Virtual Machine Manager software to become a frontend half as good as VirtualBox’s or VMware’s. This does not mean that the software was badly written, at all. The software by design is not bad at all; of course it’s very focused on RedHat and less on other distributions, which explains lots of the problems I’ve noticed, but in general I think it’s going the right way. A more advanced setup for advanced users would probably be welcome by me, as well as an ISO images management like the one VirtualBox has (even better if you can assign an ISO image to be of a specific operating system, so that when I choose “Linux”, “Fedora” it would list me the various ISO for Fedora 8, 9, 10 and then have a “Other” button to take a different ISO to install, if desired.

I’ll keep waiting to see how it evolves.

Comments 5
  1. If i remember correctly, I was once able to add a block device as a disk to a VirtualBox VM using the command-line tool VBoxManage which comes with it.

  2. Maybe you should just try KVM without frontend? I’ve been a happy kvm user since before it entered portage and setting up new machines is as simple as creating a tap device, adding it to my bridge, creating the disk image and typing one command to start the vm.I can see why it would be nice to have some kind of interface, but I’m actually happy I don’t have to keep some application open to run my vms.

  3. I agree with Michael. The command line options are so simple, it hardly warrants a frontend. For my regular systems (like Windows), I just have a launcher for it on my panel.The user mode network stack is usually sufficient but if you need to be able to connect into the VM then a TAP device is needed. I have the following in my /etc/conf.d/net, which does the trick.bridge_br0=”eth0 kvm”rc_need_br0=”net.eth0 net.kvm”brctl_br0=”setfd 0″tuntap_kvm=”tap”config_br0=”dhcp”config_eth0=”null”config_kvm=”null”I then start kvm with the options -net nic -net tap,ifname=kvm,script=no. iptables shouldn’t be required for this but I’m a bit confused about what you said above. Brigding, by its definition, should never require iptables. It’s routing, which can be used to the same effect, that does require ip.

  4. With some limitations, you can use net-misc/usbip (available from Sunrise) to forward USB devices from the host to a Linux guest.

  5. Absolutely agree on that, KVM is not ready yet (nor virt-manager and its associated libvirt).Spoiler for your next posts: no reboot supported for KVM, browse button for an ISO doesn’t work, ISO does have to be on a storage volume (but it’s not documented; storage volumes didn’t even exist until recently), hangs *a lot* and leaves ssh’s tangling, cpu pegged at 200% with XP doing nothing, slow video emulation (and no guest drivers for that; at least, linux has virtio block drivers), no snapshot support, no live migration, xen pretty much borken (paravirtualization requires providing kernel and initrd instead of supporting pvgrub or pygrub), very limited networking options (no pci passthrough in libvirt, no tap interface, no *nothing*)… And *these* are just the ones which I could recall in a moment!I’ll give them the benefit of doubt though. Libvirt’s idea is quite good (abstracting out virtualization differences; it ran with an opensolaris dom0), it still has to mature a bit. Nevertheless Virtualbox is not up to the task for a server IMHO, though I didn’t try 2.1 yet (still on 1.6): commands are too long to type, disk clones have to be done with the machine offline, limited snapshots (no snapshot tree, nor cloning a particular snapshot, as in “base XP install + 3 different customizations”), and forwarding the gui with ssh and a flakey connection is quite unstable.I also have high expectations on sun xvm server (which should have an open source version); a cross between vmware esx and server, but without xp-only graphical client.(sorry about my rant, I’ve lost a *lot* of time lately trying out most of the virtualization solutions lately… Inspite of everything, I still swear on xen + “xm” above most other solutions. BTW *great* blog, it’s been on my rss via planet gentoo for a long while, and I don’t miss a single post ^_^).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.