I spent much of yesterday trying to get a XGT for Ubuntu Feisty working. What a PITA!
The main issues was that the XGT kernel defaults to 2.6.16.38-xs3.2.0.531.3960xen with XE 3.4 while the template is being built. Furthermore the templating systems functions by building a diskmount, and then untarring the files on to this. It doesn’t use grub and the resultant images are like old style Xen, where the guest domain kernel is loaded from the host. Usually workable, and to date the Dapper template I build has been fine. But for some reason the Feisty template could not setting the root filesystem correctly and keep using reiserfs; not very nice! Working out how the (temporary, says Xensource) XGT system works, wasn’t really something I looked forward too.

Thinking about it this morning I figured it was better to have my cake and eat it too!

While I had been building the Feisty template, I discovered after apt-getting libc6-xen and xen-image-2.6.19-4-server, and changing boot/grub/menu.lst appropriately that XenEnterprise would boot the Ubuntu image correctly into PV mode. The second bit of the receipe was remembering the OVA system.

So I re-created another default Feisty install, using the Windows 2003 HVM template method. Adjusted the system by install the xen base kernel image, fixed some details I like to arrange on my default installs; then ended up spending half an hour creating a firehol 1.256 deb as the version in Feisty (and Debian) was broken.

The first step was to export the Feisty template domain to a OVA directory:

After some minor description edits the ova.xml a simple import did the charm:

xe vm-import -h localhost -u root -pw ${password} dir-name=uft/

And just like that I had a working clone of the original template image. When you are building your template there a few issues to watch out for, the main being iftab. You also want to regenerate any ssh host keys if you’ve installed sshd into your template. Plus watch out for editing /etc/hosts and breaking sudo, this can be a real PITA in Ubuntu as there is no usually seperate root password.

There are a fewother resources to follow up later as well. Part of the puzzle is now putting together a generic deployment system for Ubuntu that edits details in the OVA before it is imported. Also, find out if this is a mechanism to setup the right network interfaces and additional disks from a command line import.

Finally, the primary issue with this method is that XenEnterprise does not allow you to do this via the UI. So it must be done via the command line. Maybe this is something worth chasing up with them in due course, once I’ve had a chance to see how XE4 works.