Surgient Success

Is there option to deploy server configurations on ESX4 hosts for version4 VM's(esx3.5 compatible) basically we have VM's created under ESX3.5 which we would like to run under ESX4 servers without upgrading the virtual hardware

Virtual machines created under ESX 3.5 are have virtual hw version 4 and VMDK version 4.  VMDK version 4 disks running under a virtual hw version 4 VM created on ESX4 can still see differences with PCI bridge devices requiring Plug-n-Play updates, e.g. new network adapters.  Also VMs running under ESX4 should have the recommended ESX4 VMware Tools. 

For these reasons you, you cannot avoid virtual hardware changes when VMDKv4 disks are provisioned under ESX4.  ESX 3.5 VMs imported by their .vmx config files on ESX4 would not see hardware changes but we don't import machines, we import VMDKs which are then deployed into reserved VMs.  Those VMs would have virtual hardware differences.  Once you update a VMDKv4 image with ESX4 hardware changes, can you use the image without further updates on both ESX 3.5 and 4.0.

Does this mean that VM's created under ESX3.5 cannot be used under ESX4 unless they are upgraded? The main reason for the question is that we need to be able to keep the VM from changing no matter what host they power on. Currently certain linux VM's do not see the eth interfaces in the right order and/or Windows VM's with TechNet licenses want to re-authenticate. We don't have this issue if we keep them as v4 under ESX4. --cheers

Pablo Mestre:

Does this mean that VM's created under ESX3.5 cannot be used under ESX4 unless they are upgraded? The main reason for the question is that we need to be able to keep the VM from changing no matter what host they power on. Currently certain linux VM's do not see the eth interfaces in the right order and/or Windows VM's with TechNet licenses want to re-authenticate. We don't have this issue if we keep them as v4 under ESX4.

Try this test outside of Surgient: take a VMDK file from a VM built on ESX 3.5 and go through the new machine wizard in the vSphere 4 client and create a v4 machine on ESX 4 using the VMDK file from ESX 3.5.  Add a snapshot to protect your VMDK from changes, then boot the machine.   You will see the same virtual hardware changes I'm describing.  This is because v4 a machine created on ESX 3.5 is not the same as a  v4 machine created on ESX4.  As part of provisioning to ESX4, we're attaching the same VMDK to multiple VMs and those machines are created on ESX 4.  If you take that ESX4 v4 machine back to a ESX 3.5 machine you may see more hardware changes.  Note the difference between a VM and a VMDK file.  An ESX 3.5 VM imported into ESX4 can retain its original hardware characteristics but that is not easily possible sharing the VMDK to multiple VMs in a dynamic deployment environment.

Separately, Windows activation is controlled by several factors including host CPU type, RAM, volume id, and BIOS.  Depending on the version of Windows WGA/SPP, you can avoid activation issues in XP/2003 by using volume-licensed media and keys.  Volume-licensed media does not trigger reactivation based on hardware changes.  For Vista/2008 and later, enterprise-licensed media can be activated by a license server and does not require manual intervention.  The Windows license server can be in the image itself for isolated environments.  Retail and non-volume product keys and media may not be suitable for use in a virtual environment and may in some cases violate Microsoft licensing terms.

As for the VMDK update requirements, the VMware Tools are a general update requirement as recommended by VMware.

Windows: virtual network adapters configured for DHCP will plug-n-play detect either under ESX 3.5 or 4.0 without manual intervention.

On Linux, virtual adapters configured for DHCP will be autoconfigured by kudzu after hardware detection, equivalent to PnP on Windows.

Ideally for sharing VMDKs (not VMs) across 3.5 and 4.0, you would use all network adapters configured for DHCP.  Where that is not possible, the VMDK would need to be created on one version and booted once and configured in a new VM on the other version.  A VMDK image exposed to the virtual hardware in a new VM of both ESX versions will not require further configuration deployed to either.  This includes static addresses and ethernet adapter ordering.  The alternative is to clone VMDKs and keep separate 3.5 and 4.0 VMDK files in the library, or use homogenous ESX versions in your deployment pools.