Yesterday and today VMware released an unusual Update for vCenter (and VCSA) titled “5.0 Update 1a” as well as couple regular bug fixes and security patches for ESXi 5 hosts.
Update Aug 20 2012: VMware recently released vCenter 5.0 Update 1b, which replaces 1a due to some issues with Oracle databases. Apart from that, there seem no other new fixes that weren’t present in 1a already. So if you’re on 1a already with a non-oracle database, there is no real need to upgrade to 1b.
VMware vCenter Server 5.0
Update 1a – a as in accident? Update 1b – b as in bummer
Grab the official release notes here:
It’s the first time VMware officially released such an official out-of-band update for vCenter with a small set of fixes and enhancements, I was quite surprised too. As expected of such a minor update, it doesn’t provide any significant new features. Adding support for using vCenter with some very specific Oracle version, or switching from DB2 to PostgreSQL for the VCSA? Ok, next please.
Much more interesting and probably the reason why they made this move in the first place, are a couple of bugs this update fixes. One of them is the infamous Storage vMotion dvSwitch issue for which until now the workaround meant some manual labor or running scripts after each Storage vMotion (including SDRS).
The other fixes don’t seem particulary interesting, but I’m glad VMware finally fixed the Storage vMotion issue.
Oh joy, installing another complete vSphere Client of a whooping 350MB for just a few vCenter-side fixes! Not speaking of the actual vCenter “update” process which is essentially a whole reinstall of the new version every time.
Will VMware ever offer a proper patching method for this? Praying seems to be the only hope left.
New set of ESXi 5 patches – (a as in) adhering to a patchday policy?
Note: You do not need the above mentioned 5.0 U1a vCenter for these ESXi patches.
Less unusual appears to be the release of a series of new ESXi 5 patches for both, security and bug fixing reasons. It’s been almost exactly a month (hello patchday) since the last security patch, which was a really important one, but luckily these two new security patches for a libxml 3rd party component and a stability issue in the VMware Tools don’t seem that critical to require your immediate attention (rated important by VMware).
I will highlight a few fixes and points from the patch notes I personally deem important:
– VMware ESXi 5.0, Patch ESXi500-201207101-SG: Updates esx-base
>This patch updates the esx-base VIB to incorporate an important libxml2 security update.
– VMware ESXi 5.0, Patch ESXi500-201207102-SG: Updates tools-light
>This patch updates the tools-light VIB to resolve a stability issue in VMware Tools.
The full advisory that came with the first patch is available here: http://www.vmware.com/security/advisories/VMSA-2012-0012.html
Other bug fixing patches:
– VMware ESXi 5.0, Patch ESXi500-201207401-BG: Updates esx-base
>PR 831801: The default value of FIN_WAIT_2 timer was erroneosly set to TCPTV_KEEPINTVL * TCP_KEEPCNT = 75* 0x400. This discrepancy results in the socket at FIN_WAIT_2 state to exist for a much longer time and if multiple such sockets are accumulated, they might impact new socket creation.
>PR 835040: An ESXi host might not respond or get disconnected due to the esx.conf file being locked. This might happen because when updating the ESX configuration (esx.conf configuration file) a lock file /etc/vmware/esx.conf.LOCK is created and it is linked to the process attempting to lock the file. If the link (known as a symlink) is not valid then it prevents the esx.conf from being unlocked.
>PR 838922: An ESXi host might not restart UDP logging after a temporary interruption that might be caused by target server reboot or network UDP package being lost.
>PR 838946: During the installation of Windows Server 2012 or Windows 8 64-bits virtual machine, the virtual machine displays a black screen with a loading icon and stops responding during the start-up process.
>PR 848382: An ESXi host might become unresponsive with a purple diagnostic screen (PSOD) that displays messages similar to the following if any changes are made to BufferCache.HardMaxDirty.
>PR 866810: On Dvportgroup, a promiscuous port might not work in promiscuous mode if the DVMirror sessions are reconfigured.
>PR 855177: If you configure the loghost of syslogd incorrectly via esxcli or edit the /etc/vmsyslog.conf file directly followed by syslog reload, syslogd might terminate abruptly. You might notice the following symptoms with this issue:
– VMware ESXi 5.0, Patch ESXi500-201207402-BG: Updates tools-light
>PR 751508: Windows Vista and later versions of Windows do not recommend allowing services to be interactive; however, VMware Tools Service is installed as an interactive service.
– VMware ESXi 5.0, Patch ESXi500-201207403-BG: Updates scsi-mptsas
– VMware ESXi 5.0, Patch ESXi500-201207405-BG: Updates misc-drivers
– VMware ESXi 5.0, Patch ESXi500-201207406-BG: Updates net-e1000
Just your usual driver updates with no detailed info of the last 3 here.
You can install VMware Tools updates without maintenance mode or reboots btw. since it effectively only overwrites the Tools ISO images in /vmimages/tools-isoimages. Note that ESX(i)4 patches are also pending to be released. As per VMware support for a case we have open, I also expect a real vCenter and ESXi 5.0U2 to be released soon-ish. Maybe around VMworld 2012 and with the potential release of vSphere 5.1?