Although only a minor version I do feel that it is worth mentioning and notifying people about. vSphere 5.0 Update 1 (click here for vCenter release notes and here for ESXi release notes) contains some cool enhancements. I listed the fixes or new features which I personally ran in to the last couple of months or which are worth implementing or important to list in specific scenarios. Especially the HA (FDM) fixes are welcome, but also the “disk.terminateVMonPDLDefault” enhancement was. I will write some more about that later today though.
vCenter Server 5.0 Update 1:
- Resolved: HA and DRS appear disabled when VM Storage profiles feature is enabled or disabled for a cluster.
When VM storage profiles feature is enabled or disabled for a cluster, it causes a discrepancy in HA and DRS cluster configuration. - Resolved: File-based FDM logging can be enabled inadvertently for ESX 5.x hosts in a mixed cluster with ESX 5.x and ESX 4.x hosts.
The default FDM logging behavior for ESX 5.x hosts is to use syslog, file-based logging is disabled. In a HA cluster with mixed of 5.x and pre-5.x hosts using DAS advanced option das.config.log.maxFileNum to increase number of log files on the pre-5.0 hosts will inadvertently enable file-based logging for ESX 5.x hosts. This can lead to ESX scratch partition to run out of space.
This issue is resolved in this release by introducing HA cluster advanced parameter “das.config.log.outputToFiles”. To enable file-based logging for ESX 5.x hosts, both “das.config.log.maxFileNum” need to configure to a value greater than 2 and “das.config.log.outputToFiles” is equal to “true”.
ESXi 5.0 Update 1:
- Resolved / New: No error message is logged when VMkernel stops a virtual machine on a datastore that is in PDL state
When a SCSI device goes into permanent device loss (PDL) state, all the virtual machines that use datastores backed by that SCSI device are affected. Some third party HA solutions incorporate a VMX option where disk.terminateVMOnPDLDefault is set to True. With this option the VMkernel stops such affected virtual machines. Starting with this release, when VMkernel stops affected virtual machines, a warning message similar to the following is logged in vmkernel.log once for each virtual machine. - New: Enablement of session timeout to ESXi Tech Support Mode (TSM)
After you log in to an ESXi host at the console and then log in to the Tech Support Mode (Mode) as root user and initiate a remote server console access session, a non-privileged user might obtain root access to the ESXi host, if the remote access session has not timed out or remains idle.Starting with this release, you can configure a session timeout to exit ESXi Tech Support Mode (TSM) as follows:- Log in to Tech Support Mode (Mode) as root user.
- Edit /etc/profile file to add TMOUT=<timeout value in seconds>.
- Exit Tech Support Mode (Mode).
vShield 5.0.1:
- New: vShield App High Availability enhancements automatically restarts vShield App or virtual machines if a heartbeat is not detected.
- New: Enablement of Autodeploy (Stateless ESXi) by providing vShield VIBs (host modules) for download from vShield Manager.
Pascal says
Nice to see that U1 is released finally. Hopefully the bugs with iSCSI on restart are solved also. Updating vcenter / esx is not a problem. Update Manager is generating a nice error: Error 25127. Setup failed to upgrade the VMware vSphere Update Manager database.
Matt Heldstab says
Pascal: We ran into that issue as well, but it was due to a password change on the SQL Authentication account used to connect to the Update Manager database. The Update Manager installer doesn’t let you input the username/password when installing the newer version of UM.
Going to \Program Files (x86)\VMware\Infrastructure\Update Manager\VMwareUpdateManagerUtility.exe allows you to update the password required for the upgrade.
Pascal says
Fix: http://dcinfrastructure.blogspot.com/2011/02/error-25127-setup-failed-to-upgrade.html
A pitty that the installer doesn’t detect it 🙁
Aaron says
Is that all that is fixed? I’d really love it if they got around to solving this:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2008877
Duncan Epping says
No, read the full release notes… I only picked the things that stood out to me.
Brandon says
This is a big deal for us too. We’re still on 4.1 until it is fixed 😐
Paul Braren says
Well, yes, tested a migration, and indeed, it doesn’t change the datastore to match renamed VMs, oh well.
At least the new VMware Tools does allow you to install the accelerated VMware video driver into Windows 8 Consumer Preview VMs, and manually patching is still simple, even without VUM.
http://tinkertry.com/vsphere-5-0-update-1-released/
Carlos says
Hello, I see that Vcenter Release notes mean that vCenter Server Appliance 5.0 Update1 will be available later this year. Its possible apply the Upadate patch in vsphere hosts managed by vCenter Server Appliance 5.0 (without update) ?! thanks
Pascal says
I have found a bug I guess. Did anyone watched the Storage Views tab? It is broken here: “An internal error has occured”.
Ramesh says
vxpd on vCenter appliance ( with embedded database) running 5.0 is crashing after upgrading the vSphere hosts managed by vCenter appliance to 5.0 update 1.
Helge S says
Another bug:
Standalone server ESXi 5.0 Update 1. No vCenter.
License: Free (perhaps others too are affected?)
VM auto startup doesn’t work anymore!
Tim says
I had the storage views error as well. In my case, changing the VirtualCenter Management Webservice to run under an account with DB access instead of Local System fixed the issue.
It seems that during the upgrade, this account was reset to Local System, as well as the Update Manager service when I upgraded it.
Kayser says
@Tim
Just upgraded yesterday and now experienced the Internal error issue for the StorageView.
Did you change the account to an AD account? We used the default setting of sytem account for the services and just assume the the connectiong is via the ODBC?
Tim says
@Kayser
Here’s two things you may want to check out.
According to the upgrade guide, if you use a remote SQL database with Win authentication, the db user and logged-in user at the time of installation must be the same. Pretty obvious there.
Another entry says that you cannot user the SYSTEM account if you are using the bundled db or SQL with Win auth.
I’d bet that if you log in to your SQL box and check out the Sec logs, you’ll see all kinds of failed login errors. You may consider changing your accounts/db permissions.
Benny says
What is about the Bug with more than 2 VMkernel Port at one vSwitch?
http://vmtoday.com/2012/02/vsphere-5-networking-bug-2-affects-management-network-connectivity/
Kayser says
@Tim — thanks. Yes, my SQL server is on a separate server (2008R2) however my SQL connection does not use win auth but uses SQL auth with full dbowner access.
Tushar0110 says
Is Vcenter server upgrade possible with VUM in ESXi5.0 Update 1?
rj says
what exactly is the fix for this i am running into the same issue u mentioned