Forthcoming improvements in Xen, libvirt & virt-manager for Fedora users

Now that the RHEL-5 work for Xen / libvirt / virt-manager is (mostly) out of the way, focus is switching from bug fixing / stablization back to aggressive feature development. So what’s on the cards wrt to virtualization in Fedora 7 and beyond?

First you’ll notice I said ‘virtualization’, not simply Xen. Ever since Daniel Veillard started the libvirt project just over a year ago, the intention has been to support multiple backend implementations. Since there’s alot of buzz (hype) around KVM, a QEMU based driver for libvirt is the obvious target for the first non-Xen libvirt backend. This will support both the regular emulated mode (for all QEMU architectures), and KVM accelerated mode (for x86). It is still at a very early prototype stage of development, but things are going well and the goal is to get a working release of it ready in time to be included in Fedora 7. This will be a significant step forward for Fedora (and open source virtualization tools in general), because for the first time it will enable use of a single consistent toolset (virsh, virt-install and virt-manager) whether you’re managing VMs under Xen, KVM or QEMU.

In the very near future Fedora 7 test-1 will be available. This already has a number of significant improvements included. Despite all the buzz about KVM, Xen is the still by far the best choice for real world deployment, simply because of the huge amount of development & testing work that’s gone into it. Thus in Fedora 7 test1, Xen has already been upgraded to the newer 3.0.4 release, which improves fullvirt stability significantly and brings in support for inactive domain management. With the corresponding updates to libvirt & virt-install already in test-1, virt-manager can now display a list of all inactive guest VMs and provide the option of booting them straight from the UI. No more need to switch to the command line & run ‘xm create’ – which addresses what was probably the #1 virt-manager feature request from Fedora Core 6. Indeed, I’m planning to also make an updated virt-manager available to FC6 users because this is such a useful feature.

Moving onto the guest install process for virt-install/virt-manager…. The current install process for paravirt guests only supports Fedora or RHEL distros, done over NFS/HTTP/FTP. Conversely fullvirt installs allowed any distro, but only from local ISO image / CDROM. The goal is to broaden the options for both paravirt & fullvirt installs. So for paravirt we’re going to make it possible to do installs of distros in the SuSE family, while for fullvirt we’re going to make it possible to start install straight from the network. Basically no need to download the mini boot.iso separately – just point virt-manager at the NFS/HTTP/FTP site URL and as with paravirt it will auto-download the neccessary boot.iso image.

This is just a very small sampling of what’s going on in the virtualization world in Fedora. Things I’ve not even talked about include….

• Work by Mark to provide sane virtual networking for any guest VM, whether its running under Xen, QEMU and KVM
• Work by Rich Jones to develop a secure remote management daemon for libvirt. This will enable secure (SSL/TLS encrypted and authenticated) remote management for any virtualization backend supported by libvirt.
• All the other projects relating to virtualization & OS management under development by the Red Hat Emerging Technologies engineering group.

Oh, did I mention the ‘virsh’ tool already ? In Fedora Core 6 there was not much of a compelling argument to use it, because you still needed ‘xm’ to be able to run ‘xm create’. In Fedora 7 though, there will be no need to use ‘xm’ any more, with ‘virsh’ being the recommended tool. It has a number of advantages:

• Support for any virtualization driver included in libvirt – so the same tool can manage Xen, QEMU and KVM virtual machines.
• Ability to run as an ordinary unprivileged user in read only mode
• Lower overheads – it is written in C, and thanks to the libvirt proxy, it can use the low level hypercall interface, bypassing XenD for performance critical operations.