Sam writes
Per a limitation in Xen, Xen guests have no support for USB at all. Many people wondered how guest domains would handle a USB thumbdrive. Short answer: they wont.
This isn’t the entire truth. For paravirtualized guests it is possible to do device hot plug with virtual disks. So a USB thumbdrive plugged into the host could be mapped into the guest as a virtual disk. If run locally on Dom0, I could imagine virt-manager listening in to DBus events from HAL about newly inserted USB storage devices. The user could be prompted to map the device through to a particular guest – if we remember the device’s UUID (universal unique identifier) we could automatically map it through to the same guest on subsequent insertion. The tricky aspect to all of this though is of course the removal process. The user would have to remember to umount the device in the guest before virt-manager in Dom0 unmapped it from the guest, finally enabling the user to physically remove it. Oh, we’d also have to figure out how to block GNOME volume manager from automatically mounting it in the host. So while there’s no direct USB support, it could be fun to hack up some form of integration between HAL, virt-manaager and Xen paravirt guests to deal with USB storage hotplug.
On the other hand if someone did want to write a virtual USB split front/back device driver for Xen, that’d be excellant too. Although far from trivial…
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.
Hugh Brock, Jeremy Katz and myself have been working hard on various aspects of the Xen GUI management tools. Jeremy’s re-factored the xenguest-install.py script from Fedora Core 5 into a formal python module / library API called ‘xeninst’ which should be appearing in rawhide fairly soon. Hugh, meanwhile has been tackling the Xen guest installation problem from the UI side, producing a wizard for the virt-manager app to collect the info neccessary provision new guest instances. Today we reached the major milestone of connecting the wizard to the xeninst libray and were able to perform a (near) end-to-end graphical install of a guest OS. With seemless progression from the data collection wizard, to the embedded VNC (or serial) console in virt-manager, installation of Xen guest operating systems in a Fedora host ought to become a whole lot more friendly RSN. A few days more bug fixing / tidying up loose ends and we’ll release another snapshot virt-manager and make re-try pushing RPMs into rawhide for wider testing. Today also saw a major new release of libvirt providing much better support for hardware assisted virtualization (aka HVM / VT), automated testing via the mock hypervisor driver, and a plethora of bug fixes / minor feature enhancements.
I had a couple of hours spare, so I put together a set of Perl bindings
for libvirt. I’m currently calling the module Sys::Virt which seems to
be the most appropriate location in the CPAN namespace, but I’m open to
suggestions if people think that sucks. I’ve currently got near 100%
coverage of the C APIs, but not exposed all the static constants yet.
There are a couple of trivial example programs illustrating use of the
API for extracting info about domains.
For now you can grab a snapshot of the source for the binding using
Mercurial from the URL http://hg.berrange.com/libraries/sys-virt/. When I’ve tested it more completely I’ll upload it to CPAN.