virtcfg/virtadm: making xVM guest administration easy

We’ve just pushed some of the code myself and John Levon had been working on over the past few months to opensolaris.org: virtcfg and virtadm. (I was hoping to get this pushed in time for Christmas, hence the photo, but alas!)

Taking their inspiration from zonecfg(1M) and zoneadm(1M), we wanted to provide command-line and interactive interfaces to creating and maintaining xVM guests on OpenSolaris that would be familiar to sysadmins already using zones.

We tried to go a little further, and include a useful templating system that allows users to easily reuse guest configurations, or components of guest configurations (disk configs, network configs, etc.)

On the back-end, they use libvirt to communicate with the xVM hypervisor, but our eventual goal with these tools was to have them work with the other forms of virtualisation available on OpenSolaris: LDOMs, VirtualBox, perhaps also Zones: we think that with our design, it would be possible to manage all of these forms of virtualisation – though for now, the code just supports xVM.

We don’t have firm plans to integrate this into OpenSolaris, but thought that the code’s now in a good enough state that it could be put up on opensolaris.org for developers to look at. Do send feedback to xen-discuss on opensolaris.org if you like the project, or feel like sending us patches or bug reports.

Here’s a quick snippet of me showing a guest configuration in virtcfg, adding a new disk, showing what guest templates we include out of the box, then booting the guest.

As a footnote, I’m actually moving on to other work in OpenSolaris – pkg(5): the Image Packaging System, so won’t be able to spend much time maintaining the part of the code I was previously responsible for (virtcfg), but I will try to keep a half an ear open to virtcfg issues.

We had that discussion when deciding to write these tools and John did quite an in-depth investigation into this. Here’s a summary of what he came up with:
We don’t believe libvirt is the right place to provision storage, configure networking or other host-specific things: it should just be a way to talk to the hypervisor and we’d prefer to use it just for that.
Also, it doesn’t have some concepts that we thought were worth modeling: runtime state vs. configuration state and temporary configuration changes vs. next-boot config vs. permanent configuration of guests, or keep details about what OS was originally installed.
Finally as I say, the user experience of the libvirt tools was not consistent with zoneadm/zonecfg (for example, ‘virsh edit guest’ brings up $EDITOR showing an xml file – we thought we could provide a better UI than that)