Hello, Everyone and Happy New Year!
Speaking of “New Year”, I had read within our Citrix Discussion Forums where a few Citrix Community members reported difficulty with installing Service Pack 1 for XenServer 6.2. I had such a great experience in my own tests that eventually, well: I wrote about it on December 31, 2013 – here (Blogs.Citrix.com) and also within the Citrix Discussion Forums.
Thanks to a suggestion by one of our community members, I have updated my original article: formatting, adding more details and using spell check (aren’t we using 1984’s Doublespeak already?), but most importantly, I am providing emphasis on a successful patch/service pack installation and how to work around some of the items a few community members have faced.
I’d like to call “Mathematically Improbable, but Possible Side Effects”. The Community Member – you know who you are and I thank you – suggested an “Appendix”. Structurally, this person is right, but for the sake of redundancy I will link these two articles together and add the following as an Appendix to the original article.
So, let’s get to the circumstances that can cause the ambiguous “PATCH NOT INSTALLED” error (or similar error) message when applying XS62ESP1 and how to avoid/correct this.
0. Eject all ISO images from VMs and ensure Syslog is set to “local” – not a remote collector
This has been added thanks to work with clients and information provided by the community. In short, before applying a patch one wants all mounted ISO images to be ejected. Likewise, Syslog preferences should be set to local (specific to the 6.2 SP1 patch).
To eject all ISO images that may be mounted, execute:
xe vm-cd-eject --multiple
There may be error messages reported, but these are GOOD because that means a VM had NO ISO MOUNTED. Lastly, XenCenter/XenServer offers the ability to remote log all syslog messages. Make sure – before applying a patch – that this option is disabled and set to “LOCAL”. This can be done by selecting your XenServer in XenCenter and selecting “Properties”. Under “Log Destination”, ensure this option is set to “LOCAL”.
1. XenCenter is showing I have older XenServer patches to apply?
This is the most complex one to address, but I have only dealt with it twice and read about it once.
In short, this seems to be due to the fact that XenCenter was not updated before applying XenServer 6.2 SP1 to a stand-alone server or Pool. The version of XenCenter that should be installed before applying Service Pack 1 to XenServer 6.2 is specifically version 6.2 Build 1377.
The solution is to shutdown XenCenter, download the latest XenCenter (for XenServer 6.2 SP1). After doing so, you then need to gain access to the command line of your Pool Master or Stand-Alone host. Run the following command to find out the UUIDs of, for example, the XenServer 6.1 patches that are being reported as “need to be installed” or “will be installed on reboot” (even though they won’t because they are not technically there – I am also using XS61 as an example for this could be XS602 or XS56, etc):
xe patch-list | grep XS61 -B 1
The output should be similar to:
-- uuid ( RO) : d9c753b9-a15b-4a31-897b-97fdae609031 name-label ( RO): XS61E009 -- uuid ( RO) : 8b0518d8-3610-4b7f-8a31-0e02718d2f9f name-label ( RO): XS61E013
Now, from the Pool Master or Stand-Alone server, take each UUID that you see from the output and execute:
xe patch-destroy uuid=d9c753b9-a15b-4a31-897b-97fdae609031 <--- UUID of one of the "older/irrelevant" patches
Repeat the process until the “xe patch-list” command shows no more of the “older version” patches. XenCenter should now quit worrying about irrelevant patches from older versions.
2. “File System on Control Domain Full” / Disk Space
Checking each host for available disk space is key. There is intelligence being added to patch installation to check disk space, however if installing from the command line or through XenCenter it is possible to run out of disk space. The SP1 update – for me – went fine with 1.4Gig of free space. However, I cleaned old patches out of /var/patch as well as any “older logs” from /var/log to ensure I had disk availability.
To recover from a failed patch install due to lack of disk space:
- Free disk space
- Clear logs
- Destroy the SP1 (or all patches associated with 6.2)
So, from the command-line, you can execute the following on the host in question since the Service Pack 1 patch contains a roll up of all previous patches::
cd /var/patch/ rm -rf *
cd /var/log/ rm -rf *gz
xe patch-list | grep uuid
xe patch-destroy uuid=<strong><uuid for each UUID listed from the above command></strong>
Once completed, re-apply the Service Pack (again, make sure that the latest version of XenCenter is installed first).
3. Upgrading from a previous version of XenServer…
If upgrading from a previous version of XenServer to XenServer 6.2, do not apply 6.2 hotfixes. Instead, download the latest XenCenter and apply Service Pack 1.
This is based on one rare instance where a handful of 6.2 patches were applied and then the application of Service Pack 1 failed. This is most likely due to the disk space needed, but again – if upgrading to 6.2, upgrade to the Vanilla version and then apply Service Pack 1 after upgrading XenCenter.
And this is from my Virtual Desktop to you.