Installing the 3.2 XenEnterprise Admin Console on OSX

So, Enterprise 3.2 came out at the beginning of the month, and it mentions that a new way of using fonts is included in the console, so I have to upgrade if I actually want to see the text console for my Linux VMs. The thing is that some additional tweaking is necessary. Here are my upgraded instructions, but these only apply to version 3.2 of the console:

Here are the steps to get your XenEnterprise Administrative Console running on OSX 10.4.9:

• You need to install Java version 6, so get your Apple Developper Account (here to get one), and navigate their site:
  
  developer.apple.com -> Login -> Downloads -> Java -> Java SE 6.0 Release 1 DP6 (Disk Image)
  
  
  The file you need to get is called javase6release1dp6.dmg
  The release notes are here


• Install Java SE 6.0 on your OSX


• From the XenEnterprise Linux Clients CD, transfer the files /client-install/xenserver-client-3.2.0-2004.noarch.rpm and xenserver-client-jars-3.2.0-2004.noarch.rpm to a Linux box.


• On the Linux box, run rpm2targz on both those files, this will create .tar.gz archives of these .rpm files.


• Transfer those two .tar.gz files to your Mac


• On the Mac:

  cd /
  
  sudo tar -xzvf ~user/xenserver-client-3.2.0-2004.noarch.tar.gz
  
  sudo tar -xzvf ~user/xenserver-client-jars-3.2.0-2004.noarch.tar.gz
  
  cd /opt/xensource/xenserver-client/bin



• Edit the file xenserver-client.sh and change:

  ${BASEDIR}/jre/bin/java \

  to

  /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Commands/java \
  -XX:+UseTLAB \



• Start the ./xenserver-client.sh script.

Installing the XenEnterprise Admin Console on OSX

Here are the steps to get your XenEnterprise Administrative Console running on OSX 10.4.8:

• From the XenEnterprise CD, transfer the files /client-install/xenserver-client-3.1.0-1332.i386.rpm and xenserver-client-jars-3.1.0-1332.i386.rpm to a Linux box.


• On the Linux box, run rpm2targz on both those files, this will create .tar.gz archives of these .rpm files.


• Transfer those two .tar.gz files to your Mac


• On the Mac:



cd /
sudo tar -xzvf ~user/xenserver-client-3.1.0-1332.i386.tar.gz
sudo tar -xzvf ~user/xenserver-client-jars-3.1.0-1332.i386.tar.gz
cd /opt/xensource/xenserver-client/bin



• Edit the file xenserver-client.sh and change:



${BASEDIR}/jre/bin/java \





to





/usr/bin/java



• Start the ./xenserver-client.sh script.

The linux text console is not functional as it shows yellow blocks instead of actual letters. My guess is that it is referring to an non-existant font on OSX.

Migrating VMs from Xen to XenEnterprise

As a reseller, it's only normal to run the product you are reselling. The problem is that we've been running our production servers on Xen3 for the last few years and XenSource do no include a migration from Open Source Xen to their commercial offering.

So I have to make up my own.

First, some reverse engineering: XenEnterprise provides a VM export and import function. The "format" of an export is:

<VM export name>/ova.xml   (config file)
<VM export name>/<disk>/chunk-00000000<n>.gz   (disk chunks)

One of the problems you face is that each chunk is a maximum raw size of 1000000000 bytes, and then is run through gzip. Here's how you can generate your own chunks from your current block device. All of this article's commands are being done on my ORIGINATING Xen server, not the destination XenEnterprise server.

cd /tmp
mkdir myvm
cd myvm
mkdir hda3
cd hda3
dd if=/dev/gnbd/FC4 of=chunk-000000000 count=1000000 bs=1000
gzip chunk-000000000
dd if=/dev/gnbd/FC4 of=chunk-000000001 count=1000000 skip=1000000 bs=1000
gzip chunk-000000001
dd if=/dev/gnbd/FC4 of=chunk-000000002 count=1000000 skip=2000000 bs=1000
gzip chunk-000000002

and so on until you have copied your whole block device. Keep note of the raw length of that last chunk, since we will need to tell the config file the raw length of the block device we want at the other end. Another way to know the length of the block device is to do:

dd if=/dev/gnbd/FC4 of=/dev/null

and the very last line will say something like:

2306867200 bytes (2.3 GB) copied, 211.411 seconds, 10.9 MB/s

So, in my case, the block device was 2306867200 bytes in length.

Do this for each of your original VM's disks. Here's is what your directory tree will end up looking like:

# cd ..
# find ./myvm -print
./myvm
./myvm/hda3
./myvm/hda3/chunk-000000002.gz
./myvm/hda3/chunk-000000000.gz
./myvm/hda3/chunk-000000001.gz
./myvm/hda2
./myvm/hda2/chunk-000000000.gz

Now on to the config file. It is a simple XML file and just gives the receiving XenEnterprise an idea of the originating VMs disk layouts. Your config file will be called /tmp/myvm/ova.xml Here's mine:

<?xml version="1.0" ?>
<appliance version="0.1">
<vm name="vm">
<label>
MyVM
</label>
<shortdesc>
Fedora Core 4 test machine
</shortdesc>
<config mem_set="262144000" vcpus="1"/>
<hacks is_hvm="false" kernel_boot_cmdline="root=/dev/hda3 ro ">
<!--This section is temporary and will be ignored in future. Attribute is_hvm ("true" or "false") indicates whether the VM will be booted in HVM mode. In future this will be autodetected. Attribute kernel_boot_cmdline contains the kernel commandline for the case where a proper grub menu.lst is not present. In future booting shall only use pygrub.-->
</hacks>
<vbd device="hda2" function="swap" mode="w" vdi="vdi_hda2"/>
<vbd device="hda3" function="root" mode="w" vdi="vdi_hda3"/>
</vm>
<vdi name="vdi_hda2" size="134217728" source="file://hda2" type="dir-gzipped-chunks" variety="system"/>
<vdi name="vdi_hda3" size="2306867200" source="file://hda3" type="dir-gzipped-chunks" variety="system"/>
</appliance>

The mem_set is 256 megs, the function= can be anything, and I have no idea what the variety= means... Notice that source= doesn't actually match my real path. That's normal. The more observant of you will notice that I am actually migrating a swapfile as part of this import. Waste of time? Only you can say :-)

Now it is time for the actual import. To do this properly, you will need a statically linked file from the XenEnterprise server itself:

scp myxenterpriseserver:/opt/xensource/bin/xe /tmp/

You are now ready for the actual import. Nothing simpler:

/tmp/xe vm-import -u root -pw myrootpassword \
-h myxenenterpriseserver dir-name=/tmp/myvm/

The following lines tells you everything is honky-dory:

New VM uuid: 8453f105-bedd-4dbc-98fb-42b8b6605b44
Processing step 4/4 -
Import successful

You are now in good shape. Start your XenEnterprise Admin console and try to start up the new VM. If it bombs at kernel bootup, it is because the XenEnterprise guest initrd is incompatible with your VM. Don't despair, that's the subject of my next article...

Problems with booting Xen guests after going to version 3

If you are experiencing bootup problems with your Xen v3 guests, it may very be that you have not completely prepared your guests with the Xen v3 modules.

You see, with Xen v2, most people compiled their own kernels, both for the xen0/dom0 and xenU/domU. Most admins compiled in the ext3 support or necessary filesystem drivers directly into the XenU kernel, and were able to boot the Virtual Machines with no hiccups.
With Xen v3, the kernel is the same with both dom0 and domU, and everything is modular. Most admins even have to make sure to include a initrd to even boot their dom0. How do you do the same with the domU ??

Follow these two steps:

1. Add the following in your xmconfig file for that domU:
   

   ramdisk="/boot/initrd-2.6.18-1.2869.fc6xen.img"

   
   
2. Tar up the Xen modules, mount your domU image on a loopback and copy the modules to the domU image.
   

   cd /lib/modules
   tar -czvf ./2.6.18-1.2869.fc6xen-modules.tgz ./2.6.18-1.2869.fc6xen/
   mkdir /mnt/guest-os
   mount -o loop /someclient_image /mnt/guest-os
   cd /mnt/guest-os
   tar -xzvf /lib/modules/2.6.18-1.2869.fc6xen.tgz
   cd /
   umount /mnt/guest-os

   
   

That should be all, you should now be able to start your domU.
Note: This article takes for granted that your actual kernel name is vmlinux-2.6.18-1.2869.fc6xen :-) YMMV

Compiling XNU (OSX Kernel)

We are looking into getting OCF into the OSX kernel. That means we have to first be able to compile the XNU/Darwin kernel. I followed this howto.

Note a few points:

• Make sure to install GCC 3.3 on a OSX machine.


• Get the building utilities pre-built here.


• Get the Xnu kernel tarball, either PPC or Intel.

So, all of this is rather straightforward, BUT I had install both GCC 4.0 and GCC3.3, and I think that XNU is allergic to GCC4.0

I ended up relinking all the /usr/bin/gcc, /usr/bin/c++, and such to their gcc 3.3 equivalent. Once done, the compile went rather well, until the very end and then ended up complaining about -lcc_kext not found. The trick is to modify makedefs/MakeInc.def and to change:

# 
# Default runtime libraries to be linked with the kernel
#
export LD_KERNEL_LIBS   = -lcc_kext

with

# 
# Default runtime libraries to be linked with the kernel
#
export LD_KERNEL_LIBS   = -L/usr/lib/gcc/darwin/3.3/ -lcc_kext

That's it.

Here are a few links that might interest you for understanding of building of the XNU kernel:
MacOSX Forge
OpenDarwin
O'Reilly
Building Intel xnu with darwinbuild

This kitchen needs a better synch

"It's always a distribution problem." And you can quote me on that ...

We are going more and more towards "Web 2.0" applications. This is compounding a problem. It was already hard enough to find applications that would permit data to be synched between multiple copies and locations. Road-warriors have had some success with synchronizing their desktops and their PDA. But our needs are becoming more complex. We need to be be as productive on the road as when we are sitting in our main office, and if T-Mobile would have you believe that Wifi is ubiquitous, the reality is not even close. I won't even discuss working on the plane or while waiting 4 hours at the Passport Office (guess where I am right now ...) Even if the planet was plastered with Wifi antennas, it would still be necessary to be off the 'net once in a while.

Road-warriors use their laptop a lot and being able to synch todo, calendars, contacts, and general notes, as been possible for Outlook users, and now OSX users via .Mac (which is total crap, IMHO). iSync is definitely a good idea, but falls a little short to synch things like RSS readers, outlines (think OmniOutliner), general folders, source code versions, iTunes libraries, blog drafts, multimedia libraries (think Delicious), IRC logs, keychains, and such.

Now compounding this is the fact that, more and more, applications must be accessed via the Internet; and that's the front-end itself... If Microsoft has its way, it will even be impossible to *use* your computer unless it reports back to Redmond's mothership to "validate" its license.

I cannot understand why no synchronization standards exist. I guess it is too complex of a problem.
Each app needs to document what it stores and how. It has to be in a structure that can take being modified by third party apps, say XML. The structure has to have time-stamps and IDs linked at the atomic level. Then we have to create a language in which we can express a structure to scan for and a sub-structure to modify in order to synch two repositories. Preferably, the app must support re-scanning of its databases or configuration/status files.

These are problems that have been solved for Calendar apps for the longest time. Now a calendaring app cannot survive unless it offers some form of iCal support and synchronization. Developers selling commercial-ware and share-ware need to realize that they can double their sales by integrating proper synchronization capabilities in their save formats. If your app can be used both on a laptop and a workstation, then this applies.

Using a corporate Wiki

One of things that has always nagged at me was that departments always had individuals that would horde information; the "kingdom builders". These would be particularly nasty in the Operations areas. Also, if you did hold of their official documents, and you found a problem with the doc, or the system had drifted away from the doc, it was close to impossible to change it yourself.

The epitome of this is the Portal. Portals were all the rage about 3 years ago. Corporate internal portals for the employees were seen as a way to get information to the employees of the company. In reality, it just gave a way for the executives and HR to slam corporate rules at the employees. At the very best, Portals were nice attempts at corporate memory but ended up being an ivory tower of management-approved sanitized libraries. They were a feel-good thing for management, but ended up being close to useless for workers to easily distribute information to other workers.

Enter the Wiki.

Wikis are great to partially address these situations. Documents written in the Wiki can be changed by anyone in the company, in real time, if any discrepancies are apparent. Anyone can create a new document/link. It is a great way to distribute knowledge inside the company, and a great way to maintain corporate memory. I believe that all Intranets should have a Wiki installed. If they don't get immediate traction, leave it there, it will grow into its own in time. At the very least, you will find that Operations will use it almost immediately to store Standard Operating Procedures docs (SOPs).

We use PMWiki. It is based on PHP, and uses rather simplistic Wiki formatting tags. It has some quirks that might force us to look at something else. We might code our own using TurboGears at some point.