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.
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.
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.
Fix: http://dcinfrastructure.blogspot.com/2011/02/error-25127-setup-failed-to-upgrade.html
A pitty that the installer doesn’t detect it 🙁
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
No, read the full release notes… I only picked the things that stood out to me.
This is a big deal for us too. We’re still on 4.1 until it is fixed 😐
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/
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
I have found a bug I guess. Did anyone watched the Storage Views tab? It is broken here: “An internal error has occured”.
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.
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!
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.
@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?
@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.
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/
@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.
Is Vcenter server upgrade possible with VUM in ESXi5.0 Update 1?
what exactly is the fix for this i am running into the same issue u mentioned