How to update a single XenServer 6.2 host before adding it to a pool

You may find yourself in the position where you need to add a machine into a pool, a new host that is, and it's patching is well behind. Thankfully there is a relatively straightforward way to do this.

• You will need to have already downloaded and extracted the required files.
• On a computer with XenCentre installed run the following commands (assuming default install and Windows 7 / 8)
• Open a command prompt
• Win+r, then type cmd (or go to Start -> Run -> cmd and return)
• cd "C:\Program Files (x86)\Citrix\XenCenter"
• From here run: xe patch-upload -s server-ip -u root -pw secret-password file-name=c:\username\Downloads\XS62ESP1\XS62ESP1.xupdate and hit return. Make sure the items in italics is replaced with your actual details.
• Once this finished, you'll get a long string of characters appear and that's the patch UUID. Normally when updating a pool we make note of that, but I've found another way that works just as well.
• Download puTTY - it's an awesome terminal program and you should have it.
• Use puTTY to connect via SSH to your xenserver and get to the console. Alternatively, do this from the server console. At any rate, type the following commands and note the two UUID's they produce:
• # xe patch-list
• note the UUID of the patch
• # xe host-list
• note the UUID of the host
• # xe patch-apply UUID=patchUUID host-uuid=hostUUID and hit return. Once all the information stops flowing past and you're back to a # prompt type:
• # reboot
• if you're using puTTY, you can select the UUID's, the simply right click where you want them to be and puTTY will paste them out of the buffer. Very quick to do, rather than laboriously typing it out.

Once the machine reboots, continue to patch as applicable, and then add it to the pool.

Happy XenServering!

XenServer 6.2 - installed on a USB drive and installed on an SD Card

In this post I want to talk about recent experiences I've had with XenServer 6.2 on USB drives and SD cards. In a particular situation, I was forced initially down this path due to specific hardware and lack of appropriate drives. The upshot is that it was entirely unsuccessful and here is why:

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!