VMware released vSphere 5.1 at VMworld 2012 in San Francisco and with any new product release there are usually bumps on the road, compatibility issues and things that just don’t work. VMware vSphere 5.1 is no exception.
I have been part of many beta tests for other companies as well as several vSphere editions going back to 3.x. Not every configuration and product can be tested. The beta process does catch a lot of issues. The day software goes live without any issues every time, a lot of people will be without work..
I have decided to catalog a few of the known issues with the vSphere 5.1 release.
Perhaps the larges issue is that VMware View and vSphere 5.1 are not compatible yet.
Last Updated 09/30/2012
VMware vSphere 5.1 is not currently supported with any versions of VMware View.
Do not upgrade vSphere above the supported versions listed in the VMware View 5.1 Release Notes.
vSphere 5.1 is in the process of being certified against VMware View. To be alerted when this article is updated, click Subscribe to Document on the link above in the actions box
Read Chad Sakacc’s post for more details. vSphere 5.1 support on Cisco UCS, the VMEM needs a new vSphere 5.1 specific .vib.
VMware complied several of the 5.1 KB articles in a recent blog post on VMware Support Insider blog
More VMware vSphere 5.1 KB articles ** Added 9/17/2012 **
VMware has compiled more vSphere 5.1 KB articles that you may have missed. This one features a few of the Single Sign-On (SSO) issues that have been common for some of you
From the VMware KB article: Follow the link for resolution
- After upgrading to vCenter Server 5.1, the VMware VirtualCenter Server service fails to start
- The VMware VirtualCenter Server service will not successfully stop or start.
- The vpxd log files show the following:
- The final log in the vpxd.log file shows:
CoreDump: Writing minidump
- You see a backtrace near the very bottom of the vpxd.log file which begins with the following:
2012-09-13T11:53:46.802+02:00 [04468 info ‘vmmoVm’ opID=SWI-c5103928] [VmMo::SetComputeCompatibilityDirty] vm vm-5345 is marked dirty
2012-09-13T11:53:46.786+02:00 [05112 warning ‘win32vpxdOsLayer_win32’ opID=SWI-56f04b9c] [VpxUnhandledException] Backtrace
This issue only impacts the start/re-start time for vCenter Server. It does not affect the ongoing operations after vCenter Server has started. In fact, due to improvements to the vCenter Server database, the use of vSphere Web Client, the Inventory Service cache, customers will notice significant performance improvements in vCenter Server 5.1.
Sphere 5.1 changes the behavior of VAAI Hardware Accelerated Locking (aka ATS) to no longer work with transient (sometimes on/sometimes off) ATS behavior, and older (i.e. non-current) versions of Enginuity will fail to create VMFS-5.
PowerPath/VE customers, hold off vSphere 5.1 upgrades (GA was yesterday). Hotfix P02 from EMC is in days, and so is the expected VMware fix, follow the above link for more details on Chad Sakac’s blog post
VMware vSphere 5.1 and Synology DSM 4.1 ** Blog updated on 9/18/2012 **
Kendrick Coleman found an issue with the most recent release of DSM 4.1 and vSphere 5.1
It’s possible to mount both NFS and iSCSI datastores, but when you try to build or power on a VM, everything begins to halt when it needs to write to disk. If everything runs in memory (like mounting an ISO and beginning an OS installation), but when it comes to install the OS to disk, it begins to crawl. I checked the vmkernel log and here is what is shown. You can see that after I power on the VM, it gets binded to a port but when it tries to read from disk, there are all sorts of errors
I personally ran into this issue when upgrading my lab – see Update Manager 5.1 Release Notes
CA Signed SSL Certificates may cause trouble with the upgrade process of vCenter.
From Michael Webster’s blog at http://longwhiteclouds.com/
I have heard unconfirmed reports of difficulties with the upgrade process of vCenter particularly with registering Inventory Service and SSO with vCenter when using CA Signed SSL Certificates. As I’m using CA Signed Certificates in my lab environment I will update this article when I have completed my upgrade.
ESXi cannot distinguish between thick provision lazy zeroed and thick provision eager zeroed virtual disks on NFS datastores with Hardware Acceleration support
When you use NFS datastores that support Hardware Acceleration, the vSphere Client allows you to create virtual disks in Thick Provision Lazy Zeroed (zeroedthick) or Thick Provision Eager Zeroed (eagerzeroedthick) format. However, when you check the disk type on the Virtual Machine Properties dialog box, the Disk Provisioning section always shows Thick Provision Eager Zeroed as the disk format no matter which format you selected during the disk creation. ESXi does not distinguish between lazy zeroed and eager zeroed virtual disks on NFS datastores.
If you are having issues with IPXE and AutoDeploy please read Gabe’s Virtual World
VMware Support Insider: ALERT: Full disk on vShield Edge 5.1.x fails with error: VIX_E_DISK_FULL ERROR
VMware has become aware of an issue whereby vCloud Networking and Security 5.1 release can go into an Edge disk full state approximately 14 days after the first edge is deployed.
- In vCloud Director, attempting a reconfig fails with this error:VIX_E_DISK_FULL
- In vCloud Director, when looking at Edge Gateways, you receive this error:Edge VM backing the edge gateway is unreachable
For further updates and more information on this alert, refer to KB article:
Full disk on vShield Edge 5.1.x fails with error: VIX_E_DISK_FULL ERROR (2035939).
As with any upgrade please carefully consider especially before implementing in production. Reach out to your partners and trusted advisers for guidance so they can evaluate your environment to minimize issues.