For the oVirt project the end product distributed to users consists of a LiveCD image to serve as the ‘managed node’ for hosting guests, and a virtual machine appliance to serve as the ‘admin node’ for the web UI. The excellant Fedora LiveCD creator tools obviously already deal with the first use case. For the second though we don’t currently have a solution. The way we build the admin node appliance is to boot a virtual machine and run anaconda with a kickstart, and then grab the resulting installed disk image. While this works it involves a number of error-prone steps. Appliance images are not inherantly different from LiveCDs – instead of a ext3 filesystem inside an ISO using syslinux, we want a number of filesystems inside a partitioned disk using grub. The overall OS installation method is the same in both use cases.
After a day’s hacking I’ve managed to re-factor the internals of the LiveCD creator, and add a new installation class able to create virtual machine appliances. As its input it takes a kickstart file, and the names and sizes for one or more output files (which will act as the disks). It reads the ‘part’ entries from the kickstart file and uses parted to create suitable partitions across the disks. It then uses kpartx to map the partitions and mounts them all in the chroot. The regular LiveCD installation process then takes place. Once complete, it writes a grub config and installs the bootloader into the MBR. The result is one or more files representing the appliance’s virtual disks which can be directly booted in KVM / Xen / VMware.
The virt-image tool defines a simple XML format which can be used to describe a virtual appliance. It specifies things like minimum recommended RAM and VCPUs, the disks associated with the appliance, and the hypervisor requirements for booting it (eg Xen paravirt vs bare metal / fullvirt). Given one of these XML files, the virt-image tool can use libvirt to directly deploy a virtual machine without requiring any further user input. So an obvious extra feature for the virtual appliance creator is to output a virt-image XML description. With a demo kickstart file for the oVirt admin node, I end up with 2 disks:
-rwxr-xr-x 1 root root 5242880001 2008-02-17 14:48 ovirt-wui-os.raw
-rwxr-xr-x 1 root root 1048576001 2008-02-17 14:48 ovirt-wui-data.raw
And an associated XML file
<image>
<name>ovirt-wui</name>
<domain>
<boot type='hvm'>
<guest>
<arch>x86_64</arch>
</guest>
<os>
<loader dev='hd'/>
</os>
<drive disk='ovirt-wui-os.raw' target='hda'/>
<drive disk='ovirt-wui-data.raw' target='hdb'/>
</boot>
<devices>
<vcpu>1</vcpu>
<memory>262144</memory>
<interface/>
<graphics/>
</devices>
</domain>
<storage>
<disk file='ovirt-wui-os.raw' use='system' format='qcow2'/>
<disk file='ovirt-wui-data.raw' use='system' format='qcow2'/>
</storage>
</image>
To deploy the appliance under KVM I run
# virt-image --connect qemu:///system ovirt-wui.xml
# virsh --connect qemu:///system list
Id Name State
----------------------------------
1 ovirt-wui running
Now raw disk images are really quite large – in this example I have a 5 GB and a 1 GB image. The LiveCD creator saves space by using resize2fs to shrink the ext3 filesystem, but this won’t help disk images since the partitions are a fixed size regardless of what the filesystem size is. So to allow smaller the appliance creator is able to call out to qemu-img to convert the raw file into a qcow2 (QEMU/KVM) or vmdk (VMWare) disk image, both of which are grow on demand formats. The qcow2 image can even be compressed. Wtth the qcow2 format the disks for the oVirt WUI reduce to 600 KB and 1.9 GB.
The LiveCD tools have already seen immense popularity in the Fedora community. Once I polish off this new code to be production quality, it is my hope that we’ll see similar uptake by people interested in creating and distributing appliances. The great thing about basing the appliance creator on the Live CD codebase and using kickstart files for both, is that you can easily switch between doing regular anaconda installs, creating Live CDs and creating appliances at will, with a single kickstart file.
Way back in Fedora Core 5, we introduced the libvirt management library for virtual machines. Shortly thereafter in Fedora Core 6 we introduced Virtual Machine Manager (aka virt-manager) desktop application. In Fedora Core 7 we introduced KVM as a virtualization technology. In Fedora 8 we introduced secure remote management of virtual machines using TLS/x509, further enhanced to support Kerberos in Fedora 9. Meanwhile the FreeIPA project has been busy working to integrate Kerberos and LDAP (Fedora Directory Server).
Clearly the time has come to move beyond managing handfuls of virtual machines with a desktop application, and take full advantage of all the infrastructure we’ve painstakingly prepared. To move to a web-based management capable of scaling from a handful of machines, up to an entire data center, allowing administration from any client OS whether Linux or Windows or Mac OS-X.
It is time for oVirt.
Quoting Hugh’s announcement
oVirt is:
* A small OS image that runs libvirt and hosts virtual machines
* A Web-based virtual machine management console
oVirt goals:
* Empower virtual machine owners without giving up control of
hardware
* Automate virtual machine clustering, load balancing, and SLA
maintenance
* Simplify management of large numbers of machines
* Work across platforms and architectures
oVirt uses:
* A kerberos/LDAP server for authentication and authorization
(oVirt ships with FreeIPA)
* DNS/DHCP services on the local LAN -- or provides them for oVirt
hosts over a private network if desired
* Libvirt for virtual machine management, storage management, and
secure remote communication
* collectd for stats gathering and monitoring
* Rails for rapid, flexible development
oVirt mailing list: http://www.redhat.com/mailman/listinfo/ovirt-devel
oVirt IRC: irc.freenode.net/#ovirt
oVirt website: http://ovirt.org
Fedora 9 (current rawhide) is providing the underlying OS distribution for both the “managed nodes” running guests, and the management application itself. We’re targetting libvirt as the mangement API, to avoid being tied into any single virtualization technology, though KVM is our current technology of choice due to its clean integration with the Linux kernel, and its ever improving performance.
The new GTK-VNC 0.3.3 release was made available over the weekend. This was primarily a bug fix release dealing with yet more UltraVNC compatability issues, a few crash scenarios, improved key-state tracking to deal with annoying GTK behaviour where it fails to send you ‘release’ events during key-repeat, and ability to reset modifier state when the widget looses focus to avoid the server thinking Alt/Ctrl are stuck ‘on’.
We also have an EXPERIMENTAL web browser plugin for firefox. Before you go and install this, remember I’m saying this is EXPERIMENTAL. We’re not recommending anyone use this outside the lab yet because there needs to be a proper security audit of our protocol handling, and some more thought about how plugin security should work. Needless to say the build is disabled by default for now.
More interestingly though, is that the dev tree of GTK-VNC now has support for scaling the VNC display. We didn’t fancy writing pixmap scaling code, so for this we’re integrating with GtkGExt and OpenGL to get hardware accelerated scaling. The performance is pretty decent – Anthony tells me he’s been able to watch a DVD over VNC with scaling active. Sadly I’m stuck with the non-accelerated radeon driver in my laptop for now, so CPU usage is considerable. Still, its nice to be able to go “full screen” and have it use all screen real estate even when the remote desktop resolution doesn’t match the local desktop resolution.
You may recall my announcement of our plans for Fedora 9 Xen kernels. The 5 second summary is that we’re throwing away the current Xen kernels, and writing Xen support on top of paravirt_ops, for both DomU and Dom0, and both i386 & x86_64. Hugely ambitious given the limited time scales involved and the fact that only i386 DomU was working when we started this project.
Just minutes ago, after many many weeks work, Stephen Tweedie reached a very important milestone – the first kernel build capable of fully booting on Dom0, including the IOAPIC & DMA support neccessary to run real hardware drivers – ie the ability to access your real disks once the initrd is done :-)
(10:22:13 AM) sct: It boots
(10:22:14 AM) sct: It runs
(10:22:16 AM) sct: I can ssh into it
(10:22:50 AM) sct: [root@ghost ~]# dmesg|grep para
(10:22:50 AM) sct: Booting paravirtualized kernel on Xen
(10:22:50 AM) sct: [root@ghost ~]#
It is beginning to look like we might actually succeed in our goals in time for Fedora 9 – congrats due to Stephen & the rest of the team working on this !