Announcing a libvirt CIM provider

Posted: November 5th, 2007 | Filed under: libvirt, Virt Tools | No Comments »

For the short story, read the announcement. For the long story, read on…..

The libvirt project provides a hypervisor agnostic API for managing virtual machines (and their associated resources like their network & storage). The libvirt API has 3 core characteristics – simplicity – minimal code required to get useful work done; standard – the same API can be used across any virtualization backend; stable – guarenteed stable public API and XML descriptions across releases. In the short time it has been around, libvirt has proved impressively popular, finding its way in all the main Linux distributions, as well as Open Solaris. There are drivers in libvirt for Xen, QEMU, KVM, OpenVZ and soon Linux-VServer. If someones contributes VMWare, UML, and VirtualBox support we’ll basically have complete coverage for all common Linux virtualization platforms in a single open source API, usable by open & closed source apps alike (libvirt is LGPL licensed explicitly to enable use by closed source apps).

In the enterprise world, people like to form committees to come up with comprehensive standards to cover everything you can think of, and then go off and write multiple implementations of these standards ;-) For virtualization, the ‘standard’ is based around the DMTF / CIM specification. Pretty much since the start of the libvirt project, people have asked why we didn’t just implement the CIM APIs directly. We always wanted the core of our public APIs to be simpler to use though. At the same time, we recognise that some people really want to use a CIM API for their virtualization management tools. Thus we’ve always supported the idea of writing a CIM provider on top of libvirt. Not only would this mean only a single CIM provider implementation is needed for all of the virt platforms supported in libvirt, but it gives good interoperability between tools using libvirt vs CIM.

Over the past year & a half (or more), the Xen project has developed a CIM provider using the Xen-API as the underlying implementation. Indeed at one time this actually used libvirt instead of Xen-API, but back when the switch was made to Xen-API, KVM wasn’t around so the benefits of a hypervisor agnositic libvirt API were more hypothetical than tangible. KVM does eventually appear on the scene & sure enough, the topic of developing CIM providers for KVM soon comes up. KVM though doesn’t have any form of existing management API to deal with – a KVM guest is ‘managed’ by running a QEMU process, and killing it when you’re done. QEMU provides a mini admin shell for controlling various aspects of its behaviour. Turning this into a formal API is hard work – libvirt has already done it once and you don’t want to have to duplicate that :-)

At the recent KVM forum, IBM announced that they were going to develop a CIM provider based on libvirt, and release it to the open source community. Fast forward a few months and I’m happy to announce their plans have come to fruition. Furthermore, this is not just a 3rd party add-on, the CIM provider is to be a core part of the libvirt project & ecosystem. We’re collaborating on ideas, API requirements, hosting for our infrastructure (websites, SCM repos, mailing lists, IRC channels, etc) and above all working towards the common goal of providing state-of-the-art open source management APIs, capable of working across any virtualization platform.

VNC sessions on a 3-d spinning cube

Posted: November 5th, 2007 | Filed under: Gtk-Vnc, Virt Tools | 1 Comment »

In his recent blog posting on redirected direct renderering, Kristian happened to mention Clutter, a toolkit which allows you to do 3d graphics without first needing to acquire a PhD in OpenGL. I made a mental note to give it a try sometime.

On saturday I spent a few hours doing the major upgrade from Fedora 6 to Fedora 8 on my laptop & desktop (skipping F7). I did it the crazy way, just changing my YUM config files & letting it upgrade everything. I can’t say it was a painless process, but I do finally have two working boxes on F8 now. I also took the opportunity to switch my IBM T60p laptop over to the Avivo driver, instead of the VESA driver & which worked without a hitch.

Back on topic. After the upgrade to F8, I poked at the repos and found that (nearly) all the Clutter related bits are packaged & available to Fedora users already. There is just an annoying buildrequires missing in the python bindings spec file, which meant the RPM is missing the GTK & GST APIs for clutter. A quick rebuild fixed that issue. You may remember I’ve been working on a GTK widget for displayed VNC sessions. One evil thought, led to another even more evil thought, and thus I ended up writing a VNC viewer program which displays multiple VNC sessions on a spinning cube. To make it even more evil, I decided to not restrict it to a cube, and instead generalized to an arbitrary number of sides.

The results are spectacular, though a static screenshot doesn’t really do it justice…
VNC sessions on a 3d spinning hexagon

Ctrl+Alt+PageUp/PageDown lets you rotate to the previous/next session respectively. The mouse & keyboard events are fully plumbed in so you can actually interact with each session. In this example I just started 6 VNC server instances running TWM at 500×500 pixels, but they could have been real GNOME desktops too. The only issue is that I’ve not yet figured out how todo correct depth sorting of each desktops. You don’t notice this problem in the screenshot, since I’ve just got them all rendering at 50% opacity ;-) It is impressively slow & impressively fast at the same time. Slow because I’m using Avivo which doesn’t have any real 3d rendering support yet; fast because I’m amazed it is actually working at all :-)

Now to hook this all up into the next version of virt-manager….. just kidding ;-P