Posted by: ITKE
when relevant content is
added and updated.
when relevant content is
added and updated.
The new version of virt-manager shows the direction that the Fedora team (and consequently Red Hat) is taking with it’s GUI virtualization management tool, and it looks very promising. One of the most interesting things about it is its ability to manage multiple virtualization technologies. On first load, it asks what virtualization backend you want to attach to – Xen or QEMU. For those who don’t know, QEMU is an open source machine emulator for running fully virtualized operating systems, and is what Xen’s code for fully virtualized guest OSes is based on. I imagine it will also manage KVM, although I didn’t install and test it (or the QEMU management, for that matter.) That said, I found it encouraging to see the evolution of libvirt, the underlying abstraction layer that allows a single tool to manage multiple virtual machine mechanisms.
Virt-manager offers several new features to ease management of a server. In the past, one of the tougher things to do with Xen has been to set up the underlying networking layer for the virtual environment, since all the work had to be done at the command line through a variety of scripts and config files. Virt-manager eases this pain with a new “Host Details” configuration page, which includes simple forms and wizards to help set up networking for the virtual environment. In addition, all the hardware settings for a virtual machine are now configurable through updates to the previous “Virtual Machine Details” screens (for each specific guest OS,) including virtual disks, virtual SMP, memory, and network config. These new tools become particularly important when you discover the mechanism for storing virtual machine configuration details is now through a database, rather than text files.
The Not So Good, but Necessary
The Fedora team has followed the Xensource model and begun to store all VM configuration details in a database, referred to as xenstore. This enables the rest of the tools to use one consistent resource for reading configuration details, but also serves to complicate configuration changes. For example, virt-manager now shows all configured virtual machines, whether they are running or not (it used to only show running ones,) which enables starting of paused or off virtual machines from within the tool. The bummer is that a complex configuration requires the manipulation of the database through a series of command line tools. Fedora team has eased this a bit through virsh (a command line tool that leverages libvirt,) through which you can perform the command:
virsh dumpxml [vm name] >diskfile.xml
to get an editable xml representation of the vm configuration. Once the file has been edited, the changes can be applied through the issuance of:
virsh define diskfile.xml
The configuration options are nearly identical to former Xen configuration, only represented in xml, so anyone familiar with Xen will have no problem making the appropriate changes and applying them back to the database. In addition, you can still use the standard Xen “xm” commands with a config file to create/start a vm, but these won’t be added to the database, so when they stop, they disappear from virt-manager.
Fedora 7 is based on Xen 3.1 RC7 (sort of) which should enable new features, such as 32bit paravirtualized guests on 64bit hosts, native 64 bit guests, and the like. You might wonder why it doesn’t include the final 3.1 release – this is due to Fedora’s development freeze occurring prior to the release of the final Xen 3.1. As a result, you end up with a kernel that has much of the 3.1 feature set, but not all of it. For example, I tried a variety of methods to start up a 32bit vm on a 64 bit host – from installing directly, to installing on a 32bit host and copying, to migrating from a 32bit host to a 64bit host – all with the same result: instant death of the 32bit vm. After contacting the fedora-xen mailing list, I discovered that the current Xen kernel in Fedora 7 only has a subset of the 3.1 feature set, and that the next updated kernel (which I’m sure will arrive very soon) will have the remaining pieces. It would have been nice if there was some mention of that in the release notes.
Overall, the tools for Xen management are coming along quite nicely, actually developing a bit faster than I expected, and Fedora 7 is a great place to try them out. They will certainly ease Xen management (and other virtualization technologies on Linux, for that matter) in the future and I look forward to taking advantage of them when they make their way into RHEL 5.1.