Posts Tagged ‘update 2’
ESX 4.0 Update 2 Released. Connection Problems with PCoIP Virtual Desktops
VMware announced the U2 (update 2) release of ESX 4.0, and unfortunately early adopters quickly discovered VMware View virtual desktop connections using the PCoIP protocol were failing. This post provides some quick info on both the new release and the new VDI problem it creates.
UPdate 2 Info
VMware ESX 4 Update 2 is available for download here. The following is a cut and paste of What’s New from the Release Notes:
- Enablement of Fault Tolerance Functionality for Intel Xeon 56xx Series processors— vSphere 4.0 Update 1 supports the Intel Xeon 56xx Series processors without Fault Tolerance. vSphere 4.0 Update 2 enables Fault Tolerance functionality for the Intel Xeon 56xx Series processors.
- Enablement of Fault Tolerance Functionality for Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors— vSphere 4.0 Update 1 supports the Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors without Fault Tolerance. vSphere 4.0 Update 2 enables Fault Tolerance functionality for the Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors.
- Enablement of IOMMU Functionality for AMD Opteron 61xx and 41xx Series processors— vSphere 4.0 Update 1 supports the AMD Opteron 61xx and 41xx Series processors without input/output memory management unit (IOMMU). vSphere 4.0 Update 2 enables IOMMU functionality for the AMD Opteron 61xx and 41xx Series processors.
- Enhancement of the esxtop/resxtop utility— vSphere 4.0 Update 2 includes an enhancement of the performance monitoring utilities, esxtop and resxtop. The esxtop/resxtop utilities now provide visibility into the performance of NFS datastores in that they display the following statistics for NFS datastores: Reads/s, writes/s, MBreads/s, MBwrtn/s, cmds/s, GAVG/s(guest latency).
- Additional Guest Operating System Support— ESX/ESXi 4.0 Update 2 adds support for Ubuntu 10.04. For a complete list of supported guest operating systems with this release, see the VMware Compatibility Guide.
- Resolved Issues – In addition, this release delivers a number of bug fixes that have been documented in the Resolved Issues section.
PCoIP Connections Issue
The following cut and paste is from the VMware KB Article Upgrading VMware Tools in a virtual desktop causes PCoIP connections to fail: Read the rest of this entry »
Changing NTP Server in ESX 3.5 fails with error “failed to change host configuration”
I ran into another ESX configuration issue this week that seems to continue to hang around even though it was identified quite a long time ago. After a fresh install of two different ESX 3.5 Update 2 servers (installed from the 110268 build .iso), I was configuring NTP time sync from the VI Client (installed from the VirtualCenter 2.5 Update 3 119825 build .iso) and was unable to change the NTP server. The error message window told me “failed to change host configuration”. Most frustrating to me is the fact that I have been able to change the NTP configuration from the VI client in past versions of ESX 3.5.
I was able to manually change the NTP configuration by digging out the related recommendations from the VMTN Communities thread VMware Communities: ESX 3.5 – Time Configuration = “Failed …. I have summarized my resolution steps in the rest of this post. Note that I did not have to modify all of the files and settings (steptickers, esx firewall) as previously required (and scripted) when manually changing NTP sync in ESX version 3.0.X.
Early in the VMTN thread was the advice: Read the rest of this entry »
Latest Update on AUG 12 BUG confirms ESX/ESXi 3.5 VM reboots still required
I just received the third VMware email customer update about the August 12 time bomb bug. Unfortunately, this email informs customers that the effort to find a resolution where VM reboots could be avoided has not produced a reliable process. The email does indicate that the express patches are working properly and are compatible with VMware Update Manager. Also, The previously set deadline of 6 PM PST today (AUG 13) for the download availability of the corrected ESX/ESXi update 2 install media is still on schedule.
Here’s the body of the entire email as I received it: Read the rest of this entry »
Express Patches released for VMware AUG 12 time bomb BUG
Based on the email I received from VMware at 1:14 am EST last night, the express patches for the ESX 3.5 and ESXi 3.5 Update 2 product expiration bug have been released and are available for download. This availability would have been 10:14 pm PST and slightly later than the 9:00 pm promised deadline. This is still impressive customer response in my opinion as the ESX team is no doubt working around the clock to provide a fix around the world. VMware’s next deadline is 6 pm PST tonight (August 13) to provide the reissued upgrade media.
There are now 3 KB articles related to this bug:
- Fix of virtual machine power on failure issue, refer to KB 1006716
- For VI 3.5, refer to KB 1006721 for deployment consideration and instruction
- For VI3.5i, refer to KB 1006670 for deployment consideration and instruction
The whole email is copied at the end of this post, but here is the important information from the email about the express patches:
We have released the express patches for the product expiration issue. Please
go to http://www.vmware.com/go/esxexpresspatches for more information.1. What do the express patches do?
There are two express patches: one for ESX 3.5 Update 2 and one for ESXi 3.5
Update 2. They are specifically targeted for customers who have installed or
fully upgraded to ESX/ESXi 3.5 Update 2 or who have applied the
ESX350-200806201-UG patch to ESX/ESXi 3.5 or ESX/ESX 3.5 Update 1 hosts. For
customers who haven’t done either, these express patches should not be applied.To be noted is that these patches have been validated to work with esxupdate.
However, testing with the VMware Update Manager is still under way. In
subsequent communications, we will provide confirmation whether the patches work
with VMware Update Manger or if a re-spin is required.We are currently testing an option to apply the patch without requiring
VMotion or VM power-off and re-power-on at the point of patch application. To
immediately refresh vmx on the VM, one can VMotion off running VMs, apply the
patches and VMotion the VMs back. If VMotion capability is not available, VMs
can be powered off before the patches are applied and powered back on
afterwards.
The following is the email I received from VMware in it’s entirety. Read the rest of this entry »
Patch for ESX 3.5 U2 BUG promised by 6:00 PM today
I just received word that the following email is being sent (or will be sent) to all ESX 3.5 and ESXi 3.5 customers likely to be impacted by the Aug 12 time bomb BUG. I assume the 6:00 pm deadline is PST as VMware’s headquarters is in Palo Alto, California?
Dear VMware Customers,
Please find the latest update about the product expiration issue. From this point on, we’ll provide an update every two hours. Thanks.
Problem:
An issue has been discovered by many VMware customers and partners with ESX/ESXi 3.5 Update 2 where Virtual Machines fail to power on or VMotion successfully. This problem began to occur on August 12, 2008 for customers that had upgraded to ESX 3.5 Update 2. The problem is caused by a build timeout that was mistakenly left enabled for the release build.
Affected Products:
- VMware ESX 3.5 Update 2 & ESXi 3.5 Update 2
- Reports of problems with ESX 3.5 U1 with the following 3.5 Update 2 patch applied.
1. ESX350-200806201-UG
- No other VMware products are affected.
What has been done?
August 12 BUG in ESX 3.5 Update 2
I just ran across this rapidly growing thread in the VMware Community forums. Apparently, the date August 12, 2008 is literally a bug in ESX 3.5 Update 2. If you have already upgraded be prepared to experience the following issues as described at VMware Communities: BIG bug in ESX 3.5 Update 2 – If you’re … (check this thread for the latest as it is updating frequently as of this posting):
The bug:
Starting this morning, we could not power on or VMotion any of our Virtual Machines. The VI Client threw the error “A general system error occurred: Internal Error”.
Further digging lead us to messages like this one in /var/log/vmware/hostd.log, and the log file for any virtual machine we tried to power on or VMotion:
Aug 12 10:40:10.792: vmx| http://msg.License.product.expired This product has expired.
Aug 12 10:40:10.792: vmx| Be sure that your host machine’s date and time are set correctly.
Aug 12 10:40:10.792: vmx| There is a more recent version available at the VMware Web site: “http://www.vmware.com/info?id=4″.
A call to tech support confirmed this as a known problem with a temporary workaround.The work-around: Read the rest of this entry »









