Originally, it was possible to access the QEMU console from within a VNC viewer window, by pressing Ctrl-Alt-1.  Since this made for a major security breach - users are able to mount any file on Dom0 this way, the feature has been disabled in recent Xen releases.  That makes for a major problem, since mounting, ejecting and changing CD’s in Windows seems only possible by rebooting the Virtual Machine.

After a bit of trial and error, we came to a solution that allows the mounting and ejecting of CD’s from within Windows:

In your Xen guest config file, you must specify an empty CD device - since without it Windows will fail to recognize a CD-rom device:

Mounting a CD-rom

Execute xm block-list to view the configured bloack devices for your Xen guest:

Note the cdrom’s device number and detach it from the guest. Use the –force switch, else detaching will fail.

Now reattach the device with the correct path specified ( phy:/dev/cdrom, file:/path/to/some/iso, … ):

Unmounting a CD-rom

Eject the cdrom from Windows by right-clicking on its icon and selecting ‘Eject’.

Eject the cdrom physically from Dom0 if needed:

Remounting a CD-rom

Now’s the fun part: it appears that if you try to remount exactly the same backend device, e.g. /dev/cdrom, the Windows HVM guest will not be signalled that a new device has been inserted.  A workaround for this is to attach and to detach another device first - any will do, as long as it’s different:

Then attach your new device:

Since XenServer and XenEnterprise do not support installing the operating system on an MD software RAID device during the installation, you’ll have to undertake a few steps afterwards if you want to mirror your boot disks.

This article is largely based on Harry de Jong’s solution, as posted on the XenSource forums, with a few differences:

• There’s no need to copy mdadm.static from another server to the Xen host;
• The initrd ramdisk’s configuration is a bit simpler;
• There’s no need to swap the physical disks, which means the procedure can be accomplished remotely.

Create identical partitions to your boot disk /dev/sda on your second disk /dev/sdb

If /dev/sda looks like this:

/dev/sdb should look like this:

Do not forget to set the partition type to ‘fd’ (Linux RAID autodetect) instead of the default 83 (Linux).

Create the necessary device nodes

Create your MD RAID 1 arrays (with missing disks)

/dev/sda2 is just an empty, unmounted partition used by XenServer for upgrades.

Copy the Xen Storage Manager data over to RAID

Replace the uuid in the vgextend line above with the uuid of your own Xen SR.  Use ’sm info’ to display your SR’s uuid.

Remove /dev/sda3 from the SR volume group and add it to the RAID array

Mount /dev/md0 and copy the filesystem to it

Make a new initrd ramdisk containing the MD RAID drivers

Modify /mnt/etc/fstab so the system will mount / from /dev/md0 instead of LABEL=/-main.  Replace "LABEL=/-main" by "/dev/md0".

Create a new boot image and uncompress it:

Since mkinitrd looks at /etc/fstab to determine what device the root volume is on, it has now added the necessary raid drivers to the new boot image.

Uncompress the current ramdisk and add the raid drivers to it

Now add the raid module from the new ramdisk and modify the init file:

Add the following lines before the second line containing "/sbin/udevstart":

Add the following lines before the line containing "echo Creating root device":

Note: if you’ve created other MD raid devices, add a ‘raidautorun’ statement for them as well.

Copy the new ramdisk to the /mnt/boot folder and add modify GRUB’s boot menu

Replace "root=LABEL=/-main" by "root=/dev/md0" in all menu entries.

Unmount /dev/md0

Set up the Master Boot Record on /dev/sdb

Modify GRUB’s boot menu to boot from the second disk

Replace the line in the first XenServer entry that says "root (hd0,0)" with "root (hd1,0)". Also replace "root=LABEL=/-main" by "root=/dev/md0" in all menu entries.  This will allow you to boot from /dev/md0 instead of /dev/sda.  In case something goes wrong, you could always reboot using one of the other entries, which still point to /dev/sda.

Reboot

If all goes well, you should see your system mounting /dev/md0 as the filesystem root.  If not, reboot using one of the other GRUB menu entries and check out the previous steps.

Change /dev/sda’s partition types from Linux to Linux RAID autodetect

The result should be something like this:

Add the missing partitons to the RAID arrays

Then wait for the sync to complete:

Copy the running RAID setup to /etc/mdadm.conf

Be sure to add a line ‘DEVICE partitions’ at the top of /etc/mdadm.conf if you want to define MD devices that span a whole disk instead of just a partition.  Without this line, MD won’t be able to detect your drives as MD components at boot.

That’s it!