With vCenter 5 came the release of the the vCenter Server Virtual Appliance. This move was applauded by many due to the fact that VMware made the first step in the direction of removing their dependency on Microsoft’s Windows OS and finally making the move to a Linux based platform.
If you would ask me (and this is my personal opinion – not based on concrete info) the days of a Windows based vCenter server are numbered, if not in the next version – then the one after that – there will only be a Linux Virtual appliance. It makes complete sense.
But here is where I find lies an issue – which could become quite a serious problem.
VMware have announced that they will no longer be using Update Manager for patching the Guest OS – which I think is quite logical. VMware should concentrate on what they do best – and that is the virtualization stack. Shavlik, WSUS, Landesk (just to name a few) do a pretty good job for providing patches to guest operating systems and their underlying applications.
But what about the vCenter Server appliance? Who should be the one to patch that?
I put in a Support Request yesterday with with the following question
Patch Update for vCenter virtual appliance
The virtual appliance is installed on top of OpenSuse 11 SP1. Since it was released almost 2 years ago and since then there have been a number of bug fixes and security patches released.
Who is the responsible to apply these patches? VMware? Me the customer? If you when will these patches be released? If it is me the customer is there a list of approved patches by VMware that will assure I will not break anything?
In addition when will an updated version of the appliance be released so that it matches the one released for Windows?
The answered I received today – was what I expected.
As a follow up from our phone conversation - with regards to your question of patching the Guest OS of the vCenter Appliance - we would advise to not patch the guest OS directly. However VMware would recommend to apply any vCenter Appliance patches as they are released and if there are Guest OS patches required, they will be included in the Appliance patches.
Maybe there were no patches released for the Operating system you might ask?
I went to the Novell Patch Finder to check to see what patches were released for the OS. I selected only the Mandatory patches that were released after August 23 2011 (I will explain why this date in a moment), and lo and behold – yes there were patches – a whole lot of them (210).
To clarify a few things about how I got to my data.
This is the kernel of the vCenter appliance:
localhost:~ # uname –a
Linux localhost.localdom 2.6.32.29-0.3-default #1 SMP 2011-02-25 13:36:59 +0100
x86_64 x86_64 x86_64 GNU/Linux
The Linux version of the vCenter appliance
localhost:~ # cat /etc/issue
Welcome to SUSE Linux Enterprise Server 11 SP1 for VMware (x86_64) - Kernel \r (\l).
Why did I choose the date of August 23, 2011?
Here is the list of the last 15 RPM’s installed on the vCenter appliance.
localhost:~ # rpm -qa --queryformat '%{installtime} (%{installtime:date}) %{name}\n' | sort -n | tail -15
1314096829 (Tue Aug 23 10:53:49 2011) oracle-instantclient11.2-odbc
1314096829 (Tue Aug 23 10:53:49 2011) vmware-studio-vami-service-services
1314096831 (Tue Aug 23 10:53:51 2011) VMware-sps
1314096834 (Tue Aug 23 10:53:54 2011) VMware-vpxd-agents-eesx
1314096836 (Tue Aug 23 10:53:56 2011) stunnel
1314096836 (Tue Aug 23 10:53:56 2011) syslog-collector
1314096837 (Tue Aug 23 10:53:57 2011) VMware-vpxd-agents-esx3
1314096838 (Tue Aug 23 10:53:58 2011) vmware-open-vm-tools-kmod
1314096839 (Tue Aug 23 10:53:59 2011) vmware-open-vm-tools-common
1314122043 (Tue Aug 23 17:54:03 2011) vmware-studio-vami-login
1314122043 (Tue Aug 23 17:54:03 2011) vmware-studio-vami-service-core
1314122044 (Tue Aug 23 17:54:04 2011) vmware-studio-vami-service-system
1314122045 (Tue Aug 23 17:54:05 2011) vmware-studio-vami-service-network
1314122046 (Tue Aug 23 17:54:06 2011) vmware-studio-appliance-config
1314122047 (Tue Aug 23 17:54:07 2011) vmware-studio-vami-service-update
VMware say that I should not patch the Guest OS. You might say that not all those 210 patches are relevant. Most probably yes – that is true. But there are several that are relevant – very relevant.
Take for example the Linux Kernel.
The current Kernel is 2.6.32.29-0.3-default
The kernel has been updated 4 times
- 01 Sep 2011 - Linux kernel 5055 x86-64
- 07 Oct 2011 - Linux kernel 5223 x86-64
- 13 Dec 2011 - Linux kernel 5511 x86-64
- 06 Feb 2012 - Linux kernel 5732 x86-64
These are not minor security patches and holes. These are security updates for the kernel.What would your auditor tell you if you had not installed a patch on a Server of yours for over 18 months?
Would you leave your ESX Servers unpatched for 18 months?
Then my question to you all – and to VMware …
Why is it acceptable to not update the central (and some might say – the most important) component of my virtual infrastructure against known security vulnerabilities??
If you pass over the responsibility to me (the admin) to update my Windows vCenter – then you should either do the same for the vCenter Appliance – or VMware should be the one to provide the patches (regularly!!) – but not leave it in a state that leaves it vulnerable.
I do think that providing your customers with virtual appliance means that you should maintain that appliance – including all aspects – your software and the underlying operating system as well.
Did we all think this through when going to the virtual appliance model? Who is the responsible party for the Guest OS ? The vendor? You? And if so what should the patch cycle policy be? Once in 8 months is not a good track record.
Going the way of using Update Manager to patch the Virtual Appliance will probably be the way to go, but that will still have its implications as well.
Oh yes – one more thing.. Same goes for vCloud appliance, Orchestrator, vCOPS, CapacityIQ, ADM, the vFabric family?
I would be very interested in hearing your thoughts on this..