Firstly, it's important to be aware that XenServer isn't all that happy being installed on these devices. After you install, you must boot back up on the XenServer CD and then (using ALT-F2) drop to a command line. To get XenServer to boot on USB do the following:
- From the command line do this:
- # cat /proc/partitions
- this tells you what partitions there are that XenServer can see. Typically you will see /dev/sda and it's children - /dev/sda1, /dev/sda2 etc. We want /dev/sda1
- # mkdir /target
- create a temporary location so we can change our root directory
- # mount -t ext3 /dev/sda1 /target
- mount our existing /dev/sda1 partition to /target, giving us access to the files
- # mount proc /target/proc -t proc
- we need a proc filesystem!
- # mount sysfs /target/sys -t sysfs
- and a sysfs
- # mount --bind /dev /target/dev
- and of course somewhere for devices to be found
- # chroot /target
- change to the /target install of the system (chrooting means we are running now under the actual XenServer install, not the boot cd live filesystem)
- # cd /boot
- # ls –al
Now we need to actually tell the kernel of our installed XenServer to add USB support to it so it'll boot. Up until this point, the system will just hang, unable to find a filesystem.
- # mv initrd-lots.of-numbersxen.img initrd-lots.of-numbersxen.img.old
- this backs up the initrd ing
- # mkinitrd --with-usb initrd-lots.of-numbersxen.img lots.of-numbersxen.img
- make sure you replace lots.of-numbers with the actual kernel version. It could look like this: 2.6.18-53.1.13.el5.xs4.1.0.254.273
- # exit
- # sync
- # reboot
At this stage we are finished and the server will reboot and actually get into XenServer. After patching the pool, or indeed, the server by itself, you may need to apply the initrd update again, but with the new kernel number.
While this was cumbersome to do, particularly because I had to do it six times - 3 for initial install, 3 again after SP1 was applied, it wasn't hard to do, or particularly time consuming. I found that I had to do this for both USB drives and on the SD Card. The SD Card was significantly slower than USB. The key difference between the two was that the USB, after some magical, indeterminate time, would lose it's filesystem! XenCenter would lose connectivity to it, and the console interface was non-functional - unable to find "root"! A reboot fixed this, but these are supposed to be on all the time with minimal service loss. That was when I turned to the SD Card idea. These servers had been running an awful install of VMware 4.1 on SD Cards so I thought they would just work. Sadly, it was not to be. Once again, I'd lose connectivity to the server, but this time, I was able to get the xsconsole to respond and reboot the machine. Totally unacceptable though. I don't have time to test with this system - it's supposed to be production! At any rate, I've purchased disks and installing them. If anyone has experienced this and knows the answer - I'd love to hear it!
