Verifying ESX/ESXi virtual machine file integrity

Symptoms

• Unable to power on the virtual machine
• Powering on the virtual machine fails
• You see one of these errors:
  • A file was not found.
  • Operation not allowed in the current state
• The <vmname>.vmdk file does not exist, but the <vmname-flat>.vmdk file exists.
• Deleting snapshot fails with the error:
  
  ASSERT /build/mts/release/bora-39823/bora/vmx/snapshot/snapshot_vmx.c:752
• VMFS volume becomes inaccessible due to file system corruption

Purpose

This article describes the various files that make up a virtual machine running on an ESX host. It also provides information on how the integrity of these files may be compromised and the various means of resolving the resulting problems.

Resolution

Types of files

Before ensuring virtual machine file integrity, be aware of the various files that make up a virtual machine running on an ESX host.

VMX File

The VMX file is the primary configuration file of a virtual machine. Every aspect of your virtual machine is detailed in the VMX file, and any virtual hardware assigned to your virtual machine is present here. Here is an example entry for a virtual floppy drive: 

floppy0.startConnected = "false"
floppy0.clientDevice = "true"

Each time you create a new virtual machine using the New Virtual Machine Wizard, the VMX file is appended to with each question you answer regarding the guest operating system, disk sizes, and networking.

VMXF File

This is a supplemental configuration file for virtual machines.

VMDK and -flat.VMDK Files

The <vm_name>-flat.vmdk files store the content of the virtual machines actual hard disk drives. Earlier versions of ESX used the extension .dsk for the virtual disk files.

The <vm_name>.vmdk files are the disk descriptor files. This file contains all the information about the associated flat file.

VMDK Delta Files

The <vm_name>-######.vmdk files store the content of the virtual machines disk from the time the snapshot was created.

The <vm_name>-######-delta.vmdk files are the disk descriptor files. This file contains all the information about the associated delta flat file.

The files tell you the CID of the file, the parent CID of the file, and the type and size of the file amongst other things.

This information can be very useful depending on what type of issue you are troubleshooting. It is especially useful when troubleshooting problems with snapshots.

VMSD File

This is a centralized file for storing information and metadata about a snapshots of a virtual machine.

VMSN File

This is the file which stores the state of a snapshot.

NVRAM File

This file contains the BIOS of the virtual machine.

Log Files

The vmware(-x).log files keep a log of key virtual machine activity. This file can be useful in troubleshooting if you encounter problems.

Renaming a virtual machine

Renaming your virtual machine can create inconsistencies that can cause issues. 

To correctly rename a virtual machine:

Note: Avoid spaces, brackets, or non UTF-8 characters when naming virtual machines and their associated files.

1. Commit any snapshots.
2. Shutdown the virtual machine.
3. If you are using vCenter Server, remove the virtual machine from the inventory but do not delete the files from disk.
4. Connect to the ESX host on which the virtual machine resides over SSH. For more information, see Opening a command or shell prompt (1003892). 
5. Unregister the virtual machine.
   • For ESX, run this command:
     
     vmware-cmd -s unregister <path to config file>
     
     Where <path to config file> is the path to the configuration file as determined by the vmware-cmd –l command. For more information on the vmware-cmd –l command, see the VMware Scripting API. 
     
     For example:
     
     vmware-cmd -s unregister '/vmfs/volumes/storage1/vm1/vm1.vmx'
   • For ESXi:
     1. Log in to the ESXi host where the virtual machine is registered. For more information, see:
        • Tech Support Mode for Emergency Support (1003677) for ESXi 3.5 and ESXi 4.0 
        • Using Tech Support Mode in ESXi 4.1 and ESXi 5.x (1017910) for ESXi 4.1 and above.
     2. Unregister the virtual machine with the CLI commands:
        
        Note: The getallvms command should return the vmid of the virtual machine to be unregistered.# vim-cmd vmsvc/getallvms
        # vim-cmd vmsvc/unregister vmidAlternatively, unregister the virtual machine from vCenter Server inventory. To unregister, right-click the virtual machine and choose Remove from Inventory.
        
        
6. Rename the folder, .vmx file, and .vmdk (+ flat) file to match the new name:
   
   mv /vmfs/volumes/storage1/vm1/ /vmfs/volumes/<perhaps new storage?>/NewVM/
   cd /vmfs/volumes/<perhaps new storage?>/NewVM/
   mv vm1.vmx NewVM.vmx
   mv vm1.vmdk NewVM.vmdk
   mv vm1-flat.vmdk NewVM-flat.vmdk
   
   See Note below for alternative command for renaming the VMDK file: vmkfstools -E <oldName>.vmdk <newName>.vmdk
7. Edit the .vmx file to reflect the name of the new descriptor file.
   
   Locate the scsi0:0.fileName line. It appears similar to:
   
   scsi0:0.fileName = "vm1.vmdk"
   The edit appears similar to:
   
   scsi0:0.fileName = "NewVM.vmdk"
8. Save the file and exit.
9. Edit the .vmdk file to reflect the name of the new flat file.
   
   Locate the Extent description section of the .vmdk file. It appears similar to:
   
   # Extent description
   RW 8388608 VMFS "vm1-flat.vmdk"Edit this to:
   
   # Extent description
   RW 8388608 VMFS "NewVM-flat.vmdk"
10. Register the virtual machine.
11. • For an ESX host run the command:
      
      vmware-cmd -s register <path to config file>
      Where <path to config file> is the path to the configuration file determined by the ‘vmware-cmd –l’ command.
      
      For example:
      vmware-cmd -s register '/vmfs/volumes/<perhaps new storage?>/NewVM/NewVM.vmx'
    • For an ESXi host, see Registering or adding a virtual machine to the inventory on vCenter Server or on an ESX/ESXi host (1006160).
12. Add the virtual machine back into vCenter Server inventory using the vSphere/VMware Infrastructure Client by browsing the data store, finding the .vmx file, right-clicking and adding it to inventory.

Note: There are some additional files that you may want to rename such as the .vmxf and the swap file name. Both of these are referenced from the .vmx file. If you decide to change either of these file names, ensure you update the .vmxfile while you are completing step 7 in the instructions.

To rename a VMDK file, you can also use the command:

vmkfstools -E <oldName>.vmdk <newName>.vmdk

This command renames the content file (-flat.vmdk ) and also all references inside the metadata file (.vmdk). Ensure to update your virtual machines .vmx file after completing this step.

Corrupt VMX File

Issues with a virtual machine's .vmx file can prevent it from being powered on. You may also see these errors:

• Error when deleting a snapshot: ASSERT /build/mts/release/bora-39823/bora/vmx/snapshot/snapshot_vmx.c:752
• Error when attempting to power on a virtual machine: "operation not allowed in the current state"  

For more information on .vmx files, see Validating the .vmx settings of a virtual machine (1003748).

If you suspect your .vmx file is preventing your virtual machine from starting, you can rebuild your virtual machine with a clean .vmx file.

To rebuild a virtual machine:

1. Connect to vCenter Server or your ESX host directly with the vSphere Client.
2. Remove the virtual machine from the inventory.
3. Right-click your ESX host and choose New Virtual Machine.
4. Select the Custom option.
5. Create the virtual machine with the same configuration it had before the migration.
6. When you get to the Select a Disk section, choose to Use an existing virtual disk, and point to the original.vmdk file(s).
7. Finish the creation of the virtual machine.
8. Power on the virtual machine.

If your .vmx file has become corrupted, or the contents are missing, you can also rebuild the .vmx file if you still have the vmware.log file from the last time it booted correctly.

When viewing the log file of the virtual machine, search for the '--- CONFIGURATION' section. The .vmx files is below.

You can copy this text to a text editor to create a working configuration file.

Note: Do not use an editor that inserts formatting that ESX does not understand (such as Wordpad). If possible, complete the editing on the ESX host.

The entries in the log file appear similar to:

Feb 28 18:11:47.799: vmx| DICT config.version = 8
Feb 28 18:11:47.799: vmx| DICT virtualHW.version = 4
Feb 28 18:11:47.799: vmx| DICT floppy0.present = TRUE

Remove the preceding section so it becomes:

config.version = 8
virtualHW.version = 4
floppy0.present = TRUE

Save it with the same name as the corrupted file and the replace the corrupted version.

Corrupt VMDK File

Issues with the VMDK file of a virtual machine can prevent it from being powered on. You may see the error: 

Failed to power on a file was not found

This error may occur when the VMFS3 virtual disk descriptor (.vmdk ) files are missing. There are no <vmname>.vmdkfiles. Only <vmname-flat>.vmdk files exist.

You can also see this error if the Extent description section of the .vmdk file is incorrect. The log files show messages similar to:

Unable to find file

The system cannot find the file specified.

For more information on re-creating a missing descriptor file, see Recreating a missing VMDK (header) file (1002511).

VMFS Corruption

When a VMFS volume becomes inaccessible due to file system corruption, you may be able to migrate your running virtual machines off the filesystem. Powered off virtual machines are inaccessible.

Note: This process works if the disk blocks used for the virtual disks haven't been corrupted and the operating system is Microsoft Windows.

To migrate your virtual machine:

1. Ensure you have sufficient disk space on another VMFS volume to clone the virtual machine.
2. Connect to the virtual machine using remote desktop.
3. Download and install VMware converter inside the virtual machine.
   
   This can also be downloaded to your own laptop, desktop, or another virtual machine as long as you have network access to both the source and destination.
4. Run Converter and select Physical Machine and Local Machine.
5. Choose an ESX Server host as a destination and select a healthy VMFS.
6. Follow the wizard and wait for the process to complete.

Note: Do not you power-off or restart the virtual machine. When powered-off, the virtual machine cannot start again as the files become inaccessible.

If the operating system is not Microsoft Windows, you can use native system tools to copy the whole image to a network share.

For example, on Linux:

# dd if=/dev/sda of=/mnt/nfs/sda.dd.gz bs=1024k

You must create a new virtual machine and boot it from CD to Linux rescue mode and restore the image:

# dd if=/mnt/nfs/sda.dd of=/dev/sda bs=1024k

Note: This method creates only crash consistent image.

Source:-
http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1003743

Poor mouse performance on Windows 2008 R2 virtual machine or a Windows 7 virtual machine

Symptoms

• Poor mouse performance on Windows 2008 R2 or Windows 7 virtual machine
• Mouse movement is not smooth
• Mouse movement is slow or choppy

Cause

The virtual machine is using the SVGA video driver supplied by VMware Tools. However, it is not the WDDM video driver.

Resolution

Update the driver for the video card to use the WDDM driver that is available when VMware Tools is installed. The virtual machine must be at hardware version 7 or 8 to use the WDDM driver. For additional information, see WDDM and XPDM graphics driver support with ESX 4.x, ESXi 5.x, Workstation 7 and 8, and Fusion 3 and 4 (1016770).

To update the driver for the video card to use the WDDM driver:

1. Right-click the desktop and click Screen resolution.
2. Click Advanced Settings.
3. Click Properties.
4. Click the Driver tab.
5. Click Update Driver.
6. Click Browse my computer for driver software.
7. Enter this location or click Browse and navigate to it:
   
   C:\Program Files\Common Files\VMware\Drivers\wddm_video
   
8. Click Next. The driver is installed and you see a screen confirming that Windows has finished installing the driver for VMware SVGA 3D.
9. When prompted, reboot the virtual machine to enable the new video driver.

Additional Information

For additional information about troubleshooting SVGA drivers, see  Troubleshooting SVGA drivers installed with VMware Tools on Windows 7 and Windows 2008 R2 running on ESX 4.x (1011709).

See Also

• Troubleshooting SVGA drivers installed with VMware Tools on Windows 7 and Windows 2008 R2 running on ESX 4.x
• WDDM and XPDM graphics driver support with ESX 4.x, ESXi 5.x, Workstation 7 and 8, and Fusion 3 and 4

Source:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2004145

The balloon driver, vmmemctl, is unaware of pinned pages

Details

The balloon driver shipped with VMware Tools is not aware of a guest operating system's pinned pages (sometimes called locked pages). If the maximum balloon size is not adjusted to account for pinned pages, the balloon might over-inflate, causing an out-of-memory condition within the guest operating system.

For example, in ESX Server 3.0.1 the default maximum balloon size is 65% of the guest memory. If, due to pinned pages, less than 65% of the guest memory is available to be reclaimed, the guest might experience out-of-memory errors if the balloon driver attempts to reclaim more memory than is available.

How do pages become pinned?

Certain applications benefit from having their memory pinned so that the operating system does not attempt to swap this memory to disk. The administrator of a Windows system can allow pages to be pinned using the Lock pages in memorypermission. Windows applications can then use the VirtualLock() function. Linux applications can use mlock(2) or theMAP_LOCKED flag with mmap(2) to pin pages. Other operating systems have similar functionality. Large (2MB or 4MB) pages are typically pinned by default.

You should consider implementing the solution described below if both of these conditions are true:

• you overcommit memory on your host
• your guest environment pins memory

Solution

The administrator of a system using pinned pages should specify the maximum balloon size (in megabytes) using thesched.mem.maxmemctl parameter in the virtual machine's .vmx configuration file. This overrides the system-wide default.

For example, consider a virtual machine with:

• 4GB guest memory
• 2GB pinned for a high-performance user application

In this example, you can specify sched.mem.maxmemctl = "1330" to limit the memory that the balloon driver will attempt to swap to the guest swap space. In this case, a value of 1330MB is used because it is about 65% of the 2GB that can safely be swapped to disk (this leaves some headroom for pinned pages belonging to the guest operating system).

This recommendation assumes you have followed the instructions in the Resource Management Guide for ESX Server. Specifically, "...be sure your guest operating systems have sufficient swap space." This swap space must be greater than or equal to:

(the virtual machine's configured memory size - its Reservation) + (the space required to accommodate the workload of the virtual machine)

Furthermore, the maximum balloon size set with sched.mem.maxmemctl must be less than or equal to the configured swap space in the guest operating system. See the Swap Space and Guest Operating System section in the Resource Management Guide for ESX Server for additional information.

Cannot install the vSphere HA (FDM) agent on an ESXi host

Symptoms

• HA fails to configure on an ESXi  host
• Installing HA (FDM) on an ESXi host in lockdown mode fails
• Unable to configure HA on an ESXi host.
• In the vSphere Client connected to vCenter Server, you see these errors:
  
  
  • Cannot install the vCenter agent service
  • vSphere HA agent cannot be correctly installed or configured.
• In the /var/run/log/fdm-installer.log file, you see entries similar to:
  
  fdm-installer: [5719] 2011-09-07 07:41:40: Logging to /var/run/log/fdm-installer.log
  fdm-installer: [5719] 2011-09-07 07:41:41: extracting vpx-upgrade-installer/VMware-fdm-eesx-3-linux-455964.tar.gz...
  [5719] 2011-09-07 07:41:41: exec rm -f /tmp/vmware-root/ha-agentmgr/upgrade
  [5719] 2011-09-07 07:41:41: status = 0
  [5719] 2011-09-07 07:41:41: exec cd /tmp/vmware-root/ha-agentmgr/vpx-upgrade-installer
  [5719] 2011-09-07 07:41:41: status = 0
  fdm-installer: [5719] 2011-09-07 07:41:41: Installing the VIB
  fdm-installer: [5719] 2011-09-07 07:41:41: Result of esxcli software vib install -v=/tmp/vmware-root/ha-agentmgr/vpx-upgrade-installer/vmware-fdm.vib: Connect to localhost failed: Permission to perform this operation was denied.
• If the ESXi host is in Lockdown mode before the upgrade when it re-connects to the vCenter Server after the upgrade the following error may be reported when HA attempts to re-configure: 
  
  unknown installer error

Cause

This issue occurs when the lockdown mode is enabled in the ESXi  host. The esxcli operations fail with the Permission to perform this operation was denied error.

Resolution

To workaround this issue:

1. Disable lockdown mode in the ESXi host. For more information, see  Enabling or disabling Lockdown mode on an ESXi host (1008077)
2. In vCenter Server, right-click the host and click Reconfigure HA.
3. After HA is reconfigured, you can re-enable lockdown mode.

Additional Information

Note: Issue was also found to occur when the /root partition on an ESXi 4.0 was showing as a 100% full. Freeing up space on the / partition, resolved the issue.

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2007739

Repeated characters when typing in remote console

Details

When typing into a remote console, you see unintended repeated keystrokes.

Solution

If you are using a wide-area or low-bandwidth connection, the time delay over the network may be long enough to cause the virtual machine to start auto-repeat.

To reduce these effects, increase the time threshold necessary for auto-repeat in the remote console.

1. Power off the virtual machine.
2. Add a line, similar to this, at the end of your virtual machine's configuration (.vmx) file:
   
   keyboard.typematicMinDelay = "2000000"
   The delay is specified in micro-seconds, so the line in the example above increases the repeat time to 2 seconds. This should ensure that you never get auto-repeat unless you intend it. 
   
3. Power on the virtual machine.

To make the changes using the vSphere Client:

• Power off the virtual machine
• Right click virtual machine select Edit Settings
• Click Options > General  > Configuration Parameters
• Click Add Row
• Under Name enter keyboard.typematicMinDelay  In the Value field  2000000
• Click OK
• Power on the virtual machine

Source:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=196

Balloon driver retains hold on memory causing virtual machine guest operating system performance issues

Details

• Balloon driver retains hold on memory, causing guest operating systems to start using swap space
• Virtual machine guest operating systems experience performance issues or failure
  

Solution

This issue is caused by a discrepancy between a virtual machine's memory allocation and reservation settings.

By default, a virtual machine's Resources > Memory > Limit > Unlimited box is selected, allowing the virtual machine full use of its allocation. Migrating a virtual machine from ESX 2.x to 3.x or 4.x may cause a carry-over of memory reservation that is smaller than the virtual machine's allocated memory (likely a customer-specific setting).

 

The variables for comparison in the .vmx files are memsize and sched.mem.max .

To check the .vmx values for the Virtual Machines:

1. SSH to the host(s)
2. Run this command to list the variables for comparison: 
• All versions:
  egrep "memsize|sched.mem.max" /vmfs/volumes/*/*/*.vmx | awk -F/ '{print $6}' | moreNote: This command can be run on any version but will not be allowed to access a Virtual Machine's .vmx file if it is powered on and running on another host.
  
• In ESX 3.x/4.x:
  
  for VMX in `vmware-cmd -l`; do echo $VMX:; egrep "memsize|sched.mem.max" $VMX; done;
  
  Note: This is useful to limit the list of VMs to the one host you are connected to via SSH.
  
• In ESXi 5.0:
  
  vm-support -V|sed 's/(Running)\|\|(Registered)//g'|xargs egrep "memsize|sched.mem.max"|more
  Note: This is useful to limit the list of VMs to the one host you are connected to via SSH.

If sched.mem.max is smaller than memsize, the balloon driver can start consuming memory (especially if the guest operating system application has periodic bursts of memory usage). However, this setting can cause the balloon driver to retain its hold on memory. If the guest operating system requires memory that is made unavailable by the balloon driver, the guest operating system starts using swap memory instead, which slows it down considerably.

 

To force the balloon driver to release its hold on memory and prevent the guest operating system from using swap space, use one of these options:

• Set the value of sched.mem.max to the allocated memory or greater.
• Select the virtual machine's Resources > Memory > Limit > Unlimited box.

Note: These changes do not require a restart of the virtual machine.

Source:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003470

Registering or adding a virtual machine to the inventory on vCenter Server or on an ESX/ESXi host

Purpose

This article provides instructions for registering or adding a virtual machine on vCenter Server/VirtualCenter or an ESX/ESXi host.

Resolution

You can register a virtual machine in vCenter Server/VirtualCenter or from a command line.

 

To register a virtual machine in vCenter Server:

1. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials.
2. If connecting to vCenter Server, click on the desired host.
3. Click the Configuration tab.
4. Click Storage.
5. Right-click on the appropriate datastore and click Browse Datastore.
6. Navigate to the folder named after the virtual machine, and locate the <virtual machine>.vmx file. 
7. Right-click the .vmx file and click Add to inventory. The Add to Inventory wizard opens. 
8. Continue to follow the wizard to add the virtual machine.

To register a virtual machine from a command line:

1. Log in as root to the ESX host with an SSH client.
2. Run the command:
   # vmware-cmd -s register <full path to virtual machine>\<virtual machine name>.vmx

To register a virtual machine from a command line on an ESXi host:

1. Log in as root to the ESXi host with an SSH client. For information on using Tech Support mode, see Using Tech Support Mode in ESXi 4.1 and ESXi 5.x (1017910).
2. Run the command:
   
   # vim-cmd solo/registervm /vmfs/volumes/datastore_name/VM_directory/VM_name.vmx

Additional Information

When registering a virtual machine, remember:

• A virtual machine should be registered on one ESX host at a time.
• If an ESX host is being managed by vCenter Server, perform any virtual machine registration through vCenter Server.
  
  Note: Bypassing vCenter Server to register a virtual machine may cause a mismatch between the ESX host and the vCenter Server inventory and may cause unexpected results.
  
• If you have an issue adding the Virtual Machine to inventory verify the Virtual Machine's file integrity. For additional information, see  Verifying ESX/ESXi virtual machine file integrity (1003743)

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006160

Hardware and firmware requirements for 64-bit guest operating systems

Purpose

This article explains the host machine hardware and firmware requirements for installing virtual machines with 64-bit guest operating systems.

Note: 64-bit guests are not supported for ESX versions 2.5.x and earlier.

For information about installing Guest Operating Systems, see the Guest Operating System Installation Guide.

Resolution

VMware's virtual machine monitor has traditionally used segmentation to provide isolation between the guest operating system and the virtual machine monitor. This is necessary because the guest operating system and virtual machine monitor share the linear address space.

To determine whether or not your CPU is suitable for running 64-bit guest operating systems, VMware distributes a free utility. You can download the tool from our web site: Processor Check for 64-Bit Compatibility .

Note: This utility is provided without support from VMware and does not require ESX/ESXi, VMware Server or VMware Workstation to perform the check.

ESX/ESXi, VMware Workstation, Player, and VMware Server require a 64-bit CPU to run a 64-bit guest operating system.

VMware Fusion requires a 64-bit processor to run a 64-bit guest operating system or to run any Mac OS Guest. Mac OS Guests require hardware virtualization (VT), which VMware supports only on 64-bit processors. The Intel Core Solo and Core Duo processors are 32-bit, but the Core 2 Duo and newer processors are 64-bit.

Additional Information

Note: The information supplied in this section applies to older product versions.

Workstation 5.5 - 6.x, Player, and VMware Server 1.x support virtual machines with 64-bit guest operating systems only on host machines that have one of these supported 64-bit processors:

• AMD Athlon 64, revision D or later
• AMD Opteron, revision E or later
• AMD Turion 64, revision E or later
• AMD Sempron, 64-bit-capable, revision D or later (experimental support)
• Intel EM64T VT-enabled processors (experimental support)

Note: In shopping for a processor that is compatible with Workstation or VMware Server 64-bit guests, you may be unable to determine the revision numbers of a given vendor's offering of AMD Athlon 64, Opteron, Turion 64, or Sempron processors. At this time, the only reliable way to determine whether or not any of these processors is a revision supported by VMware software is by noting the manufacturing technology (CMOS). Any of the AMD Athlon 64, Opteron, Turion 64, or Sempron processors whose manufacturing technology is 90nm SOI (.09 micron SOI) is compatible with Workstation or VMware Server 64-bit guests. Using this information, you should be able to determine — with the help of your vendor, or from the AMD web site — whether a particular Athlon 64 or Opteron processor model is compatible with Workstation or VMware Server 64-bit guests.

Note: The preceding link was correct as of June 21, 2012. If you find the link is broken, provide feedback and a VMware employee will update the link.

AMD

Segmentation support is missing from the initial AMD64 processors (that is, revision C and earlier) while running in long mode. As a result, AMD64 processors prior to revision D do not have an efficient mechanism for isolating the virtual machine monitor from 64-bit guest operating systems. A limited form of segmentation was reintroduced in long mode, in revision D AMD64 processors. As a result, AMD64 processors must be revision D or later to run 64-bit guest operating systems.

Note: Because AMD Opteron and Turion processors do not ship in revision D, AMD Opteron and Turion 64 processors must be revision E or later to run 64-bit guest operating systems.

When reading AMD's documentation, revisions may be given in decimal format (rather than hexadecimal format). For example, Revision F may also be referred to as Revision 15.

For more information about AMD64, see http://www.amd.com/us/products/technologies/64-bit-computing/Pages/64-bit-computing.aspx .

Note: The preceding link was correct as of June 21, 2012. If you find the link is broken, provide feedback and a VMware employee will update the link.

Intel

Intel CPUs require EM64T and VT support in the chip and in the BIOS.

Note: If VT is enabled on an ESX host, the vmx flag is found in /proc/cpuinfo.

Intel EM64T CPUs do not have segmentation support in long mode. If the Intel EM64T CPU is VT-capable, it comes with hardware virtualization support (Intel's Virtualization Technology). This hardware virtualization support allows VMware to work around the lack of segmentation, making it possible to run 64-bit guest operating systems on Intel EM64T VT-capable CPUs.

Notes:

• Firmware/BIOS support is required to enable Intel Virtualization Technology. Some systems (particularly laptops) do not have the necessary firmware/BIOS support to enable Intel Virtualization Technology, and cannot run 64-bit guest operating systems.
• In multi-processor systems, all processors must support compatible VT implementations. At a minimum, all processors must implement the same VMCS revision ID. In multi-processor systems with mixed processor steppings, 64-bit guest operating systems may not be supported.
• Many servers that include CPUs with VT support might ship with VT disabled by default, and VT must be enabled manually. If your CPUs support VT but you do not see this option in the BIOS, contact your system vendor to request a BIOS version that lets you enable VT support.

For additional information, see the VMware Communities article Trouble-shooting Intel VT-x Issues.

Source:-
http://kb.vmware.com/selfservice/microsites/microsite.do?cmd=displayKC&docType=kc&externalId=1003945&sliceId=1&docTypeID=DT_KB_1_1