Access Flow, Enterprise Virtualization!
Open Employment Positions | Technical Blog
Site Search
       NewsLetters
 
VirtualMan’s Technical Corner
By Gary Lamb

Check ESX patch levels before March 11th

Extended daylight-savings time this year will begin on March 11th at 2:00 a.m. in the United States.   This is three weeks earlier than usual.   This update is very important if you are syncing the time from your hosts to your guest VM’s.   To ensure your ESX servers properly account for daylight-savings time in 2007, make sure they are running at least the following patch / build numbers:

    o VMware ESX Server 2.0.2 Upgrade Patch 3 (build 33518 or later)
    o VMware ESX Server 2.1.3 Upgrade Patch 3 (build 33524 or later)
    o VMware ESX Server 2.5.3 Upgrade Patch 5 (build 34512 or later)
    o VMware ESX Server 2.5.4 and later (build 32233 or later)
    o VMware ESX Server 3.0.0 and later (build 27701 or later)
    o VMware ESX Server 3.0.1 and later (build 32039 or later)

More information on these updates and links for download can be found in VMware Knowledge Base document Doc ID: 8695824.   These updates also contain bug, feature, and security updates that you should be running if you are not yet.

In-Place Upgrades of ESX 2.5 to ESX 3

We have recently found two undocumented issues during two separate in–place upgrades of standalone ESX 2.5 hosts to ESX 3.   Neither of these issues were identified by the ESX 3 pre-upgrade Perl script or identified in the release notes.

1. A VMFS 3 volume with a 1 mb block size only support file sizes up to 250 MB.   This is substantially smaller the 500 MB files supported by a VMFS 2 volume with 1 mb (default) block size.   This creates a problem if you are upgrading from ESX 2 to ESX 3 and have vmdk files larger than 250 MB.   The ESX upgrade will complete without problem a “file to large” error will result when you try to upgrade the volume from VMFS 2 to VMFS 3.

If this is volume is in a cluster with other ESX 2.x hosts you can migrate off or delete the large vmdk file.   If you are on a standalone host or in a cluster with no other ESX 2.x hosts you have read-only access to the VMFS 2 volume and cannot delete or migrate off the large vmdk file.   The VMFS 2 volume has to be destroyed and replaced with a VMFS 3 volume.   To prevent data loss you will need to copy all of the vmdk files to another volume or recover them from tape.

2. ESX 3 upgrades need a /vmimages directory large enough to copy the install image to.   An ESX3 upgrade will not complete in the /vmimages directory is too small.   If /vmimages cannot be expanded because it is not a separate volume or if there is not enough free space a full install of ESX 3 (without overwriting the VMFS volumes) will be necessary.

Kickstart for Automating ESX Deployments

AccessFlow has worked with multiple clients to enable automated rollout of VI3 Starter to scores to hundreds of servers.   This easily customized capability can also be utilized to deploy VI3 Standard or Enterprise to large numbers of servers.   If you’d like our assistance in simplifying your ESX deployment, please send me an email at glamb@accessflow.com, or contact your AccessFlow virtual account manager.

      Gary
AccessFlow - Enterprise Virtualization | Disaster Recovery | Virtual Machine (VM) Optimization