VirtualCenter 2.5 Update 6 Fixes Data Browser Large File Upload Error; Updates JRE And Apache Tomcat; Supports Firefox; Adds New OS Customizations
I haven’t always covered all the vCenter, VirtualCenter, and ESX/ESXi updates in the past. Several updates have been released since the last time I did. VirtualCenter 2.5 Update 6’s announcement caught my attention because of a fix to uploading files with the datastore browser. This issue has been reported in one of the longest comment threads here at VM /ETC. More on that later in this post, but I received the following email notification that VMware VirtualCenter 2.5 Update 6 was released:
VMware VirtualCenter 2.5 Update 6 is Generally Available
We are pleased to inform you that VMware VirtualCenter Server 2.5 Update 6 (English and localized) is generally available as of late night January 29, 2010.
VirtualCenter 2.5 Update 6 provides the following improvements:
- Guest Operating System Customization Improvements
- Support for Firefox 3.x Browsers with VirtualCenter Web Access
- Bug and security fixes
For details regarding the new fixes and improvements, please refer to the release notes.
VirtualCenter Server 2.5 Update 6 is available for download.
For details regarding compatibility, please view vSphere Compatibility Matrixes.
VMware Infrastructure Product Management Team
Some of the highlights for me when reading the Release Notes are:
The VMGuy has the scoop on all the VMware releases tonight! VMware has also made available an updated version of the GUI based virtual machine (VM) backup and restore plugin for vCenter 4, VMware Data Recovery 1.1 (VDR). Download it here and check the check the Release Notes here.
VMware is saying VDR has improved performance and progress information during intgregity checks, enhanced CIFS support, and that the previous experimental support status for File Level Restores of Windows VMs has been elevated to full support.
Although I could find no mention of it on the VDR web page, the data sheet, or in the new Release Notes, VDR was originally targeted for virtual infrastructure that hosted up to 100 VMs. I’m not sure if this VMware support limitation is still in effect or not.
Still, combined with the already built in de-duplication of VDR VM backups, SMBs have a great VCB alternative that continues to improve.
I am a little late relaying this important security vulnerability found in basically all VMware products. VMware publicly resolved this concern with patches and new product versions released as of April 10, 2009. I strongly suggest reviewing VMware’s Security Advisory VMSA-2009-0006 and upgrading or patching your respective product(s) as needed.
Some brief info and overview of the problem from the VMSA:
3. Problem Description
a. Host code execution vulnerability from a guest operating system
A critical vulnerability in the virtual machine display function might allow a guest operating system to run code on the host.
This issue is different from the vulnerability in a guest virtual device driver reported in VMware security advisory VMSA-2009-0005
on 2009-04-03. That vulnerability can cause a potential denial of service and is identified by CVE-2008-4916.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2009-1244 to this issue.
The following table lists what action remediates the vulnerability (column 4) if a solution is available. Continue reading
VMware’s release of ESXi Update 4 (U4) has apparently restricted Remote Command Line Interface (RCLI) administration of the free version of ESXi again. I followed a link in a tweet today from fellow vExpert William Lam which led me to a VMware Communities thread titled ESXi 3.5u4 is out, does the RCLI still have r/w access for the free version?. In this thread Dave Mishchenko reports:
“I tried vicfg-advcfg and vicfg-snmp and both failed to write ( Failed : fault.RestrictedVersion.summary). They worked fine to read configuration.”
Of course, the licensed version of ESXi U4 will allow remote read and write access.
Readers may recall that remote read and write access to free ESXi U3 via the RCLI was announced here on VM /ETC and then quickly reported as a mistake that VMware would “fix” in an upcoming version.
I find it hard to believe VMware will not allow remote configuration of it’s free version. Seems to me that free hypervisor alternatives from Microsoft and Citrix would warrant a competitive justification. Besides, vCenter offers the real, GUI based ease of administration. Why not allow command line read and write access to the free ESXi version?
William ends the thread with a thought worth considering:
“Too bad to hear, looks like if users are happy with their r/w access with the RCLI, they may not want to upgrade to U4 just yet.”
VMware has released Update 4 (U4) of ESX and ESXi. There are some new features available with these latest builds, so check out the Release Notes of each product (linked below).
Although there are a lot of new enhancements, probably the biggest surprise for me was the experimental support for PXE booting ESXi U4. PXE boot allows stateless servers without local hard drives. For a “how to” on PXE booting ESXi 3.5 U4 check out VMware KB Article 1008971
“The main benefit of PXE booting ESX Server 3i version 3.5 Update 4 is that it allows you to run the deployment on systems with no disk or other local persistent storage. Furthermore, PXE booting greatly simplifies both the booting and upgrading processes. Therefore, scaling to many machines is greatly facilitated. No manual installation steps are necessary when the system is fully-realized.”
This sounds like an obvious Cloud enabling technology to me!
In the past, Chris Wolf and Mike Dipetrillo both gave us glimpses of a PXE boot future for ESXi. As both bloggers have described, it appears VMware architect Lance Berc is the man to thank for this new feature. Check out their posts for more info on what is possible and how it is done.
Another major enhancement of Update 4 in my opinion is the expanded and improved Enhanced VMXnet virtual network driver. Improved network performance is now possible for the 32 bit versions of Windows Server 2003 as well as Windows XP. Update 4 appears to make my recent post on enabling the VMXnet driver obsolete!
I’ll highlight (using cut and pastes) what else caught my attention from the Release Notes of both ESX and ESXi in this rest of this post. Continue reading
|I’ve already mentioned the new ESX 3.5 Update 3 release in my post about the VMDK Recovery Tool, but here’s a copy of the official email announcement I received from VMware tonight.|
Jeez, I was just getting used to Update 2!
Did you take the time to plan for VMware Update Manager (VUM) when designing your virtual infrastructure architecture? Planning focus is usually on VirtualCenter (VC) server’s requirements, but then, in my experience, Update Manager and it’s default local SQL 2005 Express database seem to be added on the VC server simply because the installer is prompted about VUM during the VC setup routine. This scenario can create a poor performing VUM implementation.
Recently on the VMware Performance Team’s VROOM blog, John Liang’s post titled VMware Update Manager Performance and Best Practices Paper Posted announced a new whitepaper that should be a must read for any virtual infrastructure administrator preparing to use (or already using) VUM. The .pdf is a 14 page discussion on the topics that impact VUM such as performance, networking, resource consumption, and even virus scanning.
I find a few of these recommendations interesting, and the whitepaper leaves me wondering how common using VUM for virtual machine OS patching really is. I’ve created two informal polls, so please take a second to complete them and maybe we can get a quick gauge on how VUM is commonly implemented.
[poll id=”2″][poll id=”3″]
The whitepaper is a quick, informative read that I strongly encourage, but the following list of best practices was copied from the whitepaper’s Conclusion section.