VM /ETC

Posts Tagged ‘patch’

Tom Howarth, VMware Communities Moderator and blogger at PlanetVM.net, posted this week how he was informed by a developer of a virtualization backup vendor about a scenario involving reverting to an ESX snapshot that results in corrupted incremental backups when using vSphere’s Change Block Tracking (CBT). Howarth’s post Major issue with Change Block Tracking recounts his conversation and exploration of the problem with the developer. In summary, Howarth reported “there is a major issue with the way VMware handles the indexing of the ChangeID.”

Almost a week later and after a flurry of comments from most of the vendors leveraging CBT for virtual machine backups, VMware has published a KB article on the subject.

VMware KB: Reverting to a pre-existing snapshot under specific conditions can cause incremental backups based on CBT (Changed Block Tracking) to become inconsistent

The KB Article describes the exact scenario that causes the problem:

Read the rest of this entry »

This post is just a quick how to reference for manually changing the VMware Update Manager (VUM) patch repository download location. Admins usually need to do this when the vCenter server is low on disk space on the partition that VUM was originally installed on, but there is a second partition that has enough capacity. To move the VUM patch repository follow the following steps found in the VUM Administrators Guide:

When you install Update Manager, you can select the location for downloading patches. To change the location after installation, you must manually edit the vci-integrity.xml
file.

Procedure

1. Log in to the Update Manager server as an administrator.
   
2. Stop the Update Manager service.
   
   1. Right-click My Computer and click Manage.
      
   2. In the left pane, expand Services and Applications and click Services.
      
   3. In the right pane, right-click the VMware Update Manager Service and click Stop.
      
3. Navigate to the Update Manager installation directory and locate the vci-integrity.xml file.
   
   1. The default location is C:\Program Files\VMware\Infrastructure\Update Manager.
      
4. Create a backup copy of this file in case you need to revert to the previous configuration.
   
5. Edit the file by changing the following fields:
   
   1. yournewlocation
   2. The default patch download location is: C:\Documents and Settings\All Users\Application Data\VMware\VMware Update Manager\Data\
      
   3. The directory path must end with \.
      
6. Save the file in UTF-8 format, replacing the existing file.
   
7. Copy the contents from the old patchstore directory to the new folder.
   
8. Restart the Update Manager service.
   

One of my popular posts on VM /ETC has been Best Practices for ESX Host Partitions. Now with vSphere, VMware has changed the recommended ESX 4 Service Console partitioning slightly. So, consider this post an update to the first one. As in the past, I’ve taken this information from the VMware Partner services delivery IP available to partners on VMware Partner Central. Specifically I am taking information from the vSphere Essentials PoC delivery guide(s) found in the vSphere 4 Services Kit.

Quoting myself from the first post, some things are still worth mentioning up front:

“Installing ESX is fast and simple. By default you could click through the installer GUI changing only your local time zone and end up with a stable, dependable host. However, there are some recommended partitioning best practices that should be followed in order to make sure you minimize possible future headaches and create a repeatable and scalable environment.”

When you install ESX 4 you should choose Advanced for the installation type so you can delete the default partitioning shown in the following screen shot:

After deleting / changing the default s you can then create custom partitions as recommended.

Read the rest of this entry »

Admins of heavily consolidated VMware VI 3 Clusters should make plans as soon as possible to download Update 5 of VMware vCenter Server to take advantage of increased performance and scalability. The latest update to vCenter 2.5 was released on July 10 and boasts improvements to support fail over management of up to 80 VMs per ESX/ESXi host in a HA (High Availability) Cluster.

The following details were taken from the VMware VirtualCenter 2.5 Update 5 Release Notes:

What’s New

Support for High Consolidation in VMware HA Clusters – VirtualCenter 2.5 Update 5 includes significant performance and scalability improvements to VMware HA. Use VirtualCenter 2.5 Update 5 for environments with more than 35 virtual machines (VMs) per host in an HA cluster.

For information on the ESX Server host settings required for this scalability improvement, see ESX Server host settings required for environments with up to 80 virtual machines per host in an HA Cluster (KB 1012002).

Upgrading or Migrating to VirtualCenter 2.5 Update 5

This release supports upgrading from VirtualCenter 1.4.1, VirtualCenter 2.0.2 (including Update 1, Update 2, Update 3, Update 4, and Update 5), VirtualCenter 2.5, VirtualCenter 2.5 Update 1, VirtualCenter 2.5 Update 2, VirtualCenter 2.5 Update 3, or VirtualCenter 2.5 Update 4, to VirtualCenter 2.5 Update 5. Review the detailed upgrade and migration instructions and guidelines that are provided in the Upgrade Guide.

Following the above link to KB 1012002 explains that upgrading vCenter 2.5 to U5 is just the start. VI 3 admins also need to make some additional configurations on ESX/ESXi hosts to achieve the 80 VMs per host improvements.

“Starting with the VirtualCenter 2.5 Update 5 release, an ESX Server host in an HA cluster can support up to 80 virtual machines. For all virtual machines to power on on other hosts in the cluster, if hosts within the failover capacity limit fail, you need to ensure that the following parameters in the ESX Server hosts are set with the following values:

Read the rest of this entry »

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. Read the rest of this entry »

A new patch for VMware ESX 3.5 Update 3 was released last week that fixes the previously reported iSCSI and FC Alert – “Queue for device has been blocked” issue. The fix was part of a bundle of patches released for ESX 3.5, ESXi 3.5 and ESX 3.0.x products.

Duncan’s summary post over at yellow-bricks.com pointed me to the new VMware KB article specific to the patch with the I/O alert fix: VMware ESX 3.5, Patch ESX350-200901401-SG: Updates VMkernel, VMX, and hostd

Upon reading the KB article I noticed that the VI Client NTP configuration issue I have posted about, and continue to run into, has also been fixed.

Read VMware’s KB for all “the other issues” corrected along with some information about applying the patches with or without Update Manager.

Some VM /ETC readers may remember a weekly series of posts I was doing earlier this year – “things that make you go hmmm“. Well, the August 12 ESX/ESXi 3.5 Update 2 BUG definitely deserves a resurrection of that series and a post all to itself. Although this topic is still a little too sensitive to be humorous today, I’ve included a mix of comic and serious links. Hopefully we can all look back and at least chuckle about these events sometime in the future. So, here is a sampling of of the various reactions and opinions on the VMware time bomb bug from around the internet. Laugh if you can. After all, it’s Friday … Read the rest of this entry »