todo: August 2008 Archives

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.