Archive for the ‘Windows7’ Category

h1

Microsoft Update Kills vSphere Client

June 11, 2010

Got a problem running vSphere Client today? Seeing the following pop-up when trying to access your VMware stack?

Error parsing the server...Login doesn’t really continue, but in fact, ends with the following error:

The type initializer for...

Your environment has not been hacked! It’s a problem with your most recent Windows Update, introducing a .NET exception that your “old” version of VMware vSphere Client can’t handle. While you can uninstall the offending patch(es) to resolve the problem, the best remedy is to login to VMware’s site and download the latest vSphere Client (VMware KB 1022611).

By the way, if you’re vSphere Client is old enough to be affected (prior to Update 1), you might need to scan your vSphere environment for updates too. If you have SnS, run over to VMware’s download page for vSphere and get the updated packages, starting with the vSphere Client: you can find the installable Client package with the vCenter Server Update 2 downloads.

h1

ESXi Patches fix VSS, NTP and VMkernel

June 3, 2010

Two patches were made available on May 27, 2010 for ESXi 4.0 to fix certain bugs and security vulnerabilities in the platform. These patches are identified as ESXi400-201005401-SG and ESXi400-201005402-BG.

The first patch is security related and requires a reboot of the ESXi host:

This patch fixes a security issue. The updated NTP daemon fixes a flaw in the way it handled certain malformed NTP packets. The NTP daemon logged information about all such packets and replied with a NTP packet that was treated as malformed when received by another ntpd. A remote attacker could use this flaw to create an NTP packet reply loop between two ntpd servers through a malformed packet with a spoofed source IP address and port, causing ntpd on those servers to use excessive amounts of CPU time and fill disk space with log messages. The Common Vulnerabilities and Exposures Project (cve.mitre.org) has assigned the name CVE-2009-3563 to this issue.

ESXi 4.0 hosts might stop responding when interrupts are shared between VMkernel and service console. You might also observe the following additional symptoms:

  • Network pings to the ESXi hosts might fail.
  • Baseboard management controllers (BMC) such as HP Integrated Lights-Out (iLO) console might appear to be in a non-responsive state.

– VMware KB Article, 1021041

An interesting note is the reference to the service console in ESXi, however the sharing of interrupts between ESX drivers and the service console has long been a problem in ESX (not ESXi since there is no service console)… The second patch does not require a reboot, although it includes an update to VMware Tools which could impact uptime on affected virtual machines (Windows Server 2008 R2 and Windows 7). The KB article says this about the patch:

The VMware Snapshot Provider service is not listed in the Services panel. The quiesced snapshots do not use VMware Tools VSS components in Windows Server 2008 R2 or Windows 7 operating systems. This issue is seen when the user or backup software performs a quiesced snapshot on virtual machines on ESXi 4.0 hosts. This patch fixes the issue.

– VMware KB Article, 1021042

Since VSS quiescence is at issue here, DR snapshots and backups relying on VMware Data Recovery may be unreliable without the new VMware Tools installed. If your systems rely on VMware Data Recovery APIs for backup, this patch should be considered mandatory.

h1

vSphere 4, Update 1 and ESXi

November 30, 2009

On November 19, 2009 VMware released Update 1 for vSphere 4.0 which, among other bug fixes and errata, adds the following new features:

  • ESX/ESXi
    • VMware View 4.0 support (previously unsupported)
    • Windows 7 and Windows 2008 R2 support (previously “experimental”) – guest customizations now supported
    • Enhanced Clustering support for Microsoft Windows – adds support for VMware HA and DRS by allowing HA/DRS to be disabled per MSCS VM instead of per ESX host
    • Enhanced VMware Paravirtualized SCSI support (pvSCSI boot disks now supported in Windows 2003/2008)
    • Improved vNetwork Distributed Switch performance
    • Increased vCPU per Core limit (raised from 20 to 25)
    • Intel Xeon 3400 (uni-processor variant of the Nehalem)
  • vCenter Server
    • Support for IBM DB2 (Enterprise, Workgroup and Express 9, Express C)
    • Windows 7 and Windows 2008 R2 support (previously “experimental”) – guest customizations now supported
  • vCenter Update Manager
    • Does not support IBM DB2
    • Still no scan or remediate for Windows Server 2003 SP2/R2 64-bit, Windows Server 2008 or Windows 7
  • vSphere Client
  • vSphere Command-Line Interface
    • allows the use of comma-separated bulletins with –bundle option in “vihostupdate”

Authorized VMware users can download the necessary updates for vSphere Update 1 directly from VMware. For ESX and ESXi, updates can be managed and installed from the vCenter Update Manager within the vSphere Client. In addition to the normal backup procedure and those steps recommend by VMware, the following observations may be helpful to you:

  • DRS/HA cluster members CAN be updated auto-magically, however we observed very low end-to-end success rates in our testing lab. We recommend the following:
    • Manually enter maintenance mode for the ESXi server
    • Manually stage/remediate the patches to avoid conflicts
    • Manually re-boot ESXi servers if they do not reboot on their own
    • Re-scan patches when re-boot is complete, to check/confirm upgrade success
    • Manually recover from maintenance mode and confirm HA host configuration
  • For the vSphere Client on Windows 7, completely remove the “hacked” version and clean-install the latest version (download from the updated ESX/ESXi server(s))

SOLORI’s Notes: When upgrading ESXi “auto-magically” we experienced the following failures and unwanted behavior:

  • Update manager failure to stage pending updates and upgrades correctly, resulting in a “time-out” failure. However, updates are/were applied properly after manual reboot.
  • DRS/DPM conflicts with upgrade process:
    • inadequate time given to servers for servers to recover from sleep mode
    • Hosts sent to sleep while updates being evaluated, causing DRS to hold maintenance mode while sleeping hosts awakened, resulting in failed/time-out update process
  • Off-line VMs and templates not automatically migrated during update (maintenance mode) process causing extended unavailability of these assets during update

Additional Notes: Directed to the question of which updates/patches may or may not be “rolled-up” into this update, the release notes are very clear. However, for the sake of convenience, we repeat them here:

Patch Release ESX400-Update01 contains the following individual bulletins:

ESXi 4.0 Update 1 also contains all fixes in the following previously released bundles:

Patch Release ESX400-200906001
Patch Release ESX400-200907001
Patch Release ESX400-200909001

h1

vSphere Client in Windows7

September 4, 2009

Until there is an updated release of the VMware vSphere Client, running the client on a Windows7 system will require a couple of tricks. While the basic process outlined in these notes accomplishes the task well, the use of additional “helper” batch files is not necessary. By adding the path to the “System.dll” library to your user’s environment, the application can be launched from the standard icon without further modification.

First, add the XML changes at the end of the “VpxClient.exe.config” file. The end of your config file will now look something like this:

  <runtime>
    <developmentMode developerInstallation="true"/>
  </runtime>
</configuration>

Once the changes are made, save the “VpxClient.exe.config” file (if your workstation is secured, you may need “Administrator” privileges to save the file.) Next, copy the “System.dll” file from the “%WINDOWS%\Microsoft.NET\Framework\v2.0.50727” folder on an XP/Vista machine to a newly created “lib” folder in the VpxClient’s directory. Now, you will need to update the user environment to reflect the path to “System.dll” to complete the “developer” hack.

To do this, right-click on the “Computer” menu item on the “Start Menu” and select “Properties.” In the “Control Panel Home” section, click on “Advanced system settings” to open the “System Properties” control panel. Now, click on the “Environment Variables…” button to open the Environment Variables control panel. If “DEVPATH” is already defined, simply add a semi-colon (“;”) to the existing path and add the path to your copied “System.dll” file (not including “System.dll”) to the existing path. If it does not exist, create a new variable called “DEVPATH” and enter the path string in the “Variable Value” field.

System-Properties-Environment-Panel-Windows7

The path begins with either %ProgramFiles% or %ProgramFiles(x86)% depending on whether or not 32-bit or 64-bit Windows7 is installed, respectively. Once the path is entered into the environment and the “System.dll” file is in place, the vSphere Client will launch and run without additional modification. Remember to remove the DEVPATH modification to the environment when a Windows7 vSphere Client is released.

Note that this workaround is not supported by VMware and that the use of the DEVPATH variable could have unforseen consequences in your specific computing environment. Therefore, appropriate considerations should be made prior to the implementation of this “hack.” While SOLORI presents this information “AS-IS” without warranty of any kind, we can report that this workaround is effective for our Windows7 workstations, however …