Archive for the ‘Virtualisation’ Category

Citrix XenServer XS62E015 update failing to apply

Monday, June 16th, 2014

If you’re using XenServer 6.2, you may have some problems installing the XS62E015 update from CTX140808.

You go through the normal update procedure – download XS62E015.zip from the CTX140808 Citrix knowledge base article, extract it and upload the XS62E015.xsupdate file to the pool, then apply UUID c8b9d332-30e4-4e5e-9a2a-8aaae6dee91a to the pool, which promptly fails with:

The uploaded patch file is invalid. See attached log for more details.
log: error parsing patch precheck xml: expected one of these character sequence: “required”, found “error” line 4

It turns out that Citrix issued two updates for the same issue – one for Citrix XenServer 6.2 without SP1 installed and one for Citrix XenServer with SP1 installed. The slight snag is that both of these updates show up in the list of available updates in Citrix XenCentre and the knowledge base articles don’t mention that the two updates patch the same problem, but in two different version of Citrix XenServer.

If you are running Citrix XenServer 6.2 with SP1 installed, then you need to install the XS62ESP1003 update from CTX140416 (UUID c208dc56-36c2-4e91-b8d7-0246575b1828). Once XS62ESP1003 has been installed, XS62E015 will also show up in the list of installed updates.

XenConvert fails to import OVF to XenServer

Saturday, January 11th, 2014

I recently ran into a problem when trying to P2V a server with the Citrix XenConvert tool.

XenConvert would successfully create the local VHD file for the disk image as well as the OVF file for the server and then copy them to XenServer, however at the vert last hurdle (actually importing the OVF into XenCenter), it would then fail with a rather unhelpful “Failed to import the OVF Package” message.

The relevant part of the XenConvert.txt log would look something like this:

Physical to OVF Package stopped at <date/time>
Physical to OVF Package lasted <duration> seconds
Source is <path>.
Destination is <XenServer IP>.
OVF to XenServer started at <date/time>
Importing OVF Package…
Failed to import.
Failed to import the OVF Package.
OVF to XenServer stopped at <date/time>
OVF to XenServer lasted <duration> seconds
Physical to XenServer stopped at <date/time>
Physical to XenServer lasted <duration> seconds

It turns out that the OVF package has in actual fact been successfully imported in to XenServer, it’s just that for whatever reason XenCovert fails to remove the “hidden” flag from the resulting Virtual Machine.

You can see the hidden Virtual Machine in XenCenter by selecting “Hidden Objects” from the “View” menu.

In order to make the virtual machine permanently visible, you need to switch to the console and find the UUID of the virtual machine using:

xe vm-list

Once you have the UUID, you can remove the “hidden” flag from the virtual machine with the following command:

xe vm-param-remove uuid=<UUID> param-name=other-config param-key=HideFromXenCenter

Obviously you need to replace “<UUID>” with the UUID that you found in the output of the vm-list command.

You should now have a normal, fully functioning Virtual Machine which you can see without “Hidden Objects” enabled in XenCetner.

OpenVZ reboot loop

Thursday, January 2nd, 2014

I recently encountered a strange reboot loop with a server running OpenVZ.

When booting the server, the host would come up and start the process of booting the containers, then at some point during the boot process it would reboot without any errors.

I managed to break the reboot loop by quickly SSHing in to the host node whilst it was starting the containers and disable the “vz” service so that it wasn’t started at boot time:

chkconfig vz off

On the next reboot, this broke the reboot loop and allowed me to get in via SSH and look around the system properly.

The only hint that I had to go on was that whilst most of the containers brought up during the boot sequence said “starting container”, the container immediately prior to the unexpected reboot said “restoring” instead.

This prompted me to look in the “/vz/dump/” folder, where I found a file called “Dump.” (Obviously was the container ID of the container which was being restored instead of started).

Simply removing this dump file allowed the “vz” service to be started without causing a reboot and everything started working as normal.

The only thing left to do at this point is to remember to enable the “vz” service again so that it will start during the next system boot:

chkconfig vz on

Citrix XenServer boot from CD/DVD

Sunday, September 8th, 2013

If you’re using Paravirtualised (PV) guest Virtual Machines on Citrix XenServer, then it’s not immediately obvious how to boot the guest from a CD/DVD should you need to. In the “Boot Options” tab of the Properties for the Virtual Machine, the “Boot Device” drop down menu will be greyed out, with no obvious way of enabling it.

The actual method of booting a Virtual Machine from a CD/DVD is a little less obvious – go to the Virtual Machine in question, switch to the console tab and select the CD/DVD from the drop down list at the top. Make sure that the Virtual Machine is shutdown, then click on the “VM” menu, then “Start/Shut down” and select “Start in Recovery Mode”. The Virtual Machine will now boot from whichever CD/DVD you’ve selected.