Thursday, April 15, 2010

Libvirt snapshotting support

One of the oft-requested features for libvirt has been snapshotting support; that is, the ability to take a snapshot of a virtual machine at a point in time, and then later on go back in time to that snapshot. It's a pretty neat feature to see in action, and under the hoods there is a lot of trickery going on to make it work. I'm pleased to say that as of libvirt 0.8.0, we have snapshotting support for qemu/kvm, Virtualbox, and ESX in the main libvirt API's.
The design of the API's went through many iterations, until we finally settled on an API that seems to fit the snapshot model of most of the hypervisors pretty well. To take a snapshot, virDomainSnapshotCreateXML() is used with an appropriate virDomainPtr and snapshot XML. The snapshot XML looks like:

<domainsnapshot>
<name>XYZ</name>
<creationdate>...</creationdate>
<description>...</description>
<state>running</state>
<domain>
<uuid>XXXXX-XXXX-XXXX-XXXX-XXXXXXXXX</uuid>
</domain>
<parent>
<name>ABC</name>
</parent>
</domainsnapshot>

However, when creating a snapshot, only the <name> and <description> tags are settable by the user. All of the other fields are ignored and filled in by the libvirt driver at the time the snapshot is actually created. The <domainsnapshot> XML is pretty straightforward, but I'll describe the fields here.

<name> is a unique identifier for this snapshot for this domain. It's what will be used later on to lookup the snapshot to perform operations with it or on it. If the <name> is not specified at snapshot creation time, then libvirt will make one up.

<creationdate> is the time, in seconds since the Unix epoch, that the snapshot was created at. This is read-only and is automatically filled in by libvirt when the snapshot is created.

<description> is a user-editable field that can contain any unique identifying information the user wants to store along with the snapshot. If this is blank at snapshot creation time, it remains empty.

<state> is the state of the domain (running, offline, paused, etc) at the time the snapshot was taken. When a user reverts to a particular snapshot, the domain's state will be set to this state.

<domain><uuid> is the UUID corresponding to the domain that this snapshot is taken against.

<parent><name> is the name of the parent of this snapshot (if any). This tracks the parent/child relationship in "trees" of snapshots. It is important information to know when deleting snapshots, as deleting a parent snapshot has interesting repercussions for children (see virDomainSnapshotDelete() below).

Once you've created a snapshot, you can lookup the snapshot by name, query all of the snapshots for a domain, or get the currently running snapshot for a domain. At some point in the future, the user will probably want to revert back to the snapshot he has taken. To do this, a handle to the domain snapshot must be obtained with virDomainSnapshotLookupByName(). Once the handle is obtained, the domain can be reverted to the point-in-time of that snapshot by calling virDomainRevertToSnapshot(). This is pretty cool to see in action; the domain is running along, and the moment virDomainRevertToSnapshot() is called, the domain instantly travels back to the past!

Finally, I'll talk a bit about deleting snapshots. Once a user is done using a snapshot, they may want to delete that snapshot. In the simple case of a snapshot without children, a call to virDomainSnapshotDelete() will remove all traces of the snapshot. If a snapshot does have children, then things get more interesting. First, if the VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN flag is passed to virDomainSnapshotDelete(), then the current snapshot and all children of this snapshot are deleted. Second, if VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN is *not* passed, but this snapshot does have children, then all changes that are present in the to-be-deleted parent are automatically merged into the children. If you think about it, this is necessary to keep the children viable.

That's some of the fun stuff going on in libvirt. If you have questions, comments, or problems with this feature, please feel free to contact the libvirt mailing list at libvirt-users@redhat.com or libvirt-devel@redhat.com.

Monday, April 5, 2010

Ubuntu 9.10 runlevel 3

With upstart and grub2 in Ubuntu 9.10, the way to configure the default runlevel has drastically changed. I'm just writing a quick blog post so I don't forget:

1) Edit /etc/default/grub and make GRUB_CMDLINE_LINUX_DEFAULT look like:

GRUB_CMDLINE_LINUX_DEFAULT="text"

2) Run "sudo update-grub"

3) Edit /etc/inittab, and make it look like:

id:3:initdefault

That should be enough to force Ubuntu 9.10 to boot into runlevel 3