Recently in todo Category

Working more on troubleshooting, which is, as you might gather, an enormous chapter.  I'm not saying that Xen doesn't work -- I'm just saying that you have to define 'work' carefully.

Anyway.  Not that I am bothered.  It's a lovely day.

Really, right now we're thinking about adding a bit on the vm.overcommit_memory and overcommit_ratio sysctls, and how they can be used to improve Xen's stability.  The idea is that, if we make it impossible for the VM subsystem to overcommit memory, the oom-killer should never run.  This will lead to improved stability, since the oom-killer has a regrettable habit of killing sshd.

We need to test that assertion, though, and that sounds suspiciously like work.

Have I mentioned I don't really like Ubuntu?  For some reason Xen's network-bridge script kills my networking, even though I'm connected just fine without.  First let's discuss how I fixed it (since I like to cut to the happy ending whenever possible).

What fixed it eventually was adding to /etc/network/interfaces:

iface eth0 inet dhcp

This let ifup handle eth0.  I'm not sure why the non-Xen kernel was able to deal with the absence of this line, or indeed why the Xen kernel wasn't.  Perhaps it is a red herring.

Then I restarted network-bridge (with sh -x) and noted that its output was a bit more sensible, but I still wasn't connected.  Eventually I noticed that I had two default routes, one via peth0 and one via eth0.  So I ran:

ip route del default dev peth0

And I'm connected.  Adding that last bit to a script, or hacking network-bridge's transfer_routes() function to figure out why it's leaving two routes and fixing it, would be pretty trivial.

Network-bridge, the default Xen network backend, doesn't care what sort of data it's sending -- as far as it's concerned, they're Ethernet frames.  There's a special case for IPv4 and the antispoof rules, but that's it.  Other protocols, like IPv6, will "just work," and there's no current provision for Xen to inspect packets.  (Although it wouldn't be that hard to add, building on the IPv4 support.)

I need to write a blurb about paravirt_ops and what that means for upstream Linux Xen support.  I don't think there are any administrator-visible changes (other than possibly better distro packaging,) but I'm not entirely certain.  (I also have no idea where it'd go, but that's another issue entirely.)

Part of it is just that any term thrown around on the mailing list so much has got to be important, right?  Maybe someone should do a concordance script to find common and significant terms in mailing lists.

I think Xen's PCI passthrough support has been dramatically updated since we wrote about it previously.  Accordingly, we too will update dramatically!

(A review: the PCI passthrough allows the administrator to forward a PCI device to a domU.  Once upon a time it was necessary to boot with the PCI device hidden from the dom0 -- this may no longer be the case.  Hard to say.)

Of course, if we had some VT-d hardware we could test that, too.  *sigh*

Checked out the xen-3.2-testing.hg repo.  Was considering xen-unstable, but it's too unstable for me.  I wonder what the Xen uses openSSL and PAM for.  It's probably related to the remote management and XenAPI stuff -- but it's hard to say.

Working on compiling a kernel the "ubuntu way."  Just realized I need some kind of baseline, so I've also installed the Ubuntu Xen package.  Time to reboot.

Decided to cut out the "checkpoint" section from migration, on the grounds that we couldn't get it to work.  Maybe we'll get it to work soon?

In the meantime, here it is!

Checkpointing a Domain with xm save

As we mentioned previously, xm save halts a domain in the process of writing its internal state to a save file, and rebuilds it entirely when the save file is restored. With recent versions of Xen, however, the save command supports an option to keep the machine running after it's been saved - a feature called "checkpointing."

Checkpoint a domain thus:

# xm save -c <domain> <checkpoint file>

After the checkpoint's been saved, the domain will continue running.

Although the principle of checkpointing seems simple, it's tricky to actually get it to work in practice. The problem is that the running domain will continue to modify its storage, which causes the saved state to be out of sync with the backing store.

To avoid this problem, you can use a script that hooks into Xen's external device migration framework to checkpoint the domain storage during the save process, as described in the textbox.

[textbox title: Device Migration Hooks]

Xen includes the option of calling an external device migration script at each step of a save or migrate. Although the feature was originally added for the sake of TPM migration, it's since been extended to migrating arbitrary devices.

Enable the external-device-migrate script by setting the external-migration-tool directive in /etc/xen/xend-config.sxp. Most likely you'll want to set (external-migration-tool 'external-device-migrate') and let that script source appropriate scripts for external devices.

[end textbox]

More todo!  (The copyediting phase is, after all, the best time to add new sections.)

I want to nail down in my mind, for certain and absolute, whether it is possible to control xen remotely, and if so, how.  Virt-manager seems to allow it, but I haven't found the knobs to twiddle that make it work.  This would be useful to allow, for example, a centralized console server for the customer domains.

This is probably related to the XenAPI in some way.

This one's a reminder -- we're considering pulling the firewalling bits out of the hosting chapter, expanding them, and putting them into a discussion of dom0 firewalling in the networking chapter.  The idea is that there are substantiative differences between firewalling in the Xen case and in the ordinary case -- with Xen, we want to firewall the dom0 but let the domUs have unfiltered access to the network.

Discussion of shaping will most likely still go in hosting.

Even though storage is technically kind of finalized, I want to add a few lines on falling through to custom block devices.  (There's already a brief discussion, but a more concrete example might help.)

We could refer to the block-iscsi script described at http://lists.xensource.com/archives/html/xen-devel/2007-11/msg00782.html