VMware Fault Tolerance fails to turn on in a two node cluster

 

Symptoms

• VMware Fault Tolerance (FT) is configured and functional for virtual machines in a two node cluster.
• FT is turned off so that the primary virtual machine can be vMotioned to a different host in the cluster.
• Attempts to turn on FT after vMotioning fail with the errors similar to:

The virtual machine is running in a monitor mode that is incompatible for Fault Tolerance.

The Fault Tolerance configuration of the entity <VM name> has an issue: The virtual machine's current configuration does not support Fault Tolerance.

Purpose

Running FT protected virtual machines in a two node cluster is supported. Problems can occur when there is a need to vMotion the primary virtual machine from one host to the other. As the primary and secondary virtual machines cannot reside on the same host, FT must be turned off so that the secondary virtual machines is destroyed. The primary virtual machines can then be vMotioned to the other host.

This article provides steps to prevent the monitor mode from changing during vMotioning that causes FT to fail.

Resolution

This issue occurs if the monitor mode changes during the vMotion process. FT requires the monitor mode be set to Use Intel VT-x/AMD-V for instruction set virtualization and software for MMU virtualization for the monitor mode to not change during the vMotion process.

The default setting for the virtual machine monitor mode is Automatic and FT sets the monitor mode appropriately behind the scenes. If the hosts in the cluster support the Use Intel VT-x/AMD-V for instruction set virtualization and Intel EPT/AMD RVI for MMU virtualization option, the monitor mode is changed to this during the vMotion process.

To set the monitor mode explicitly to Use Intel VT-x/AMD-V for instruction set virtualization and software for MMU virtualization:

Note: In some instances, the virtual machine needs to be powered off in order to change the monitor mode.

1. Right-click the virtual machine in question and choose Edit Settings.
2. In the virtual machine Properties window, click Options and select the CPU/MMU Virtualization option under the Advanced heading.
3. Select the radio button next to Use Intel VT-x/AMD-V for instruction set virtualization and software for MMU virtualization.
4. Click OK.
5. For the setting to take effect, the virtual machine needs to be power cycled or vMotioned to another host. When this is complete, FT can be turned on for the virtual machine.

Source :-

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

Unpresenting a LUN in ESXi 5.x

Purpose

This article provides steps on how to unpresent a LUN from an ESXi 5.x host.

Resolution

Removing a LUN in ESX/ESXi 4.x is complex. Improvements have been made in ESXi 5.x to streamline the procedure to make it easier for Administrators to remove LUNs.

Unpresenting a LUN Checklist

Before unpresenting a LUN, ensure that:

• If the LUN is being used as a VMFS datastore, all objects (such as virtual machines and templates) stored on the VMFS Datastore are unregistered or moved to another datastore.
  
  Note: All CD/DVD images located on the VMFS datastore must also be unregistered from the virtual machines.
  
• The datastore is not part of a datastore cluster. For more information on datastore clusters, see the vSphere Resource Management Guide.
• The datastore is not managed by Storage DRS. For more information on Storage DRS, see the vSphere Resource Management Guide.
• Storage I/O Control is disabled for the datastore. For more information, see Managing Storage I/O Resources in thevSphere Resource Management Guide.
• The datastore is not used for vSphere HA heartbeat.
• No third party scripts or utilities running on the ESXi host can access the LUN in question. If the LUN is being used as a datastore, unregister all objects (such as virtual machines and templates) stored on the datastore.
• If the LUN is being used as an RDM, remove the RDM from the virtual machine. Click Edit Settings, highlight the RDM hard disk, and select Remove. Ensure that Delete from disk is selected and click OK.
  
  Note: This destroys the mapping file, but not the LUN content.
  
• Check if the LUN/Datastore is used as the persistent scratch location for the host. For more information on persistent scratch, see Creating a persistent scratch location for ESXi (1033696).
  
  This PowerCLI script can be used to check the current scratch location:
  
  $vcServer = "vCenter01"
  $cluster = "CL01"
  $esxCred = Get-Credential
  Connect-VIServer $vcServer | Out-Null
  #Connect to ESX hosts in cluster
  foreach ($esx in Get-Cluster $cluster | Get-VMHost) {
  Connect-VIServer $esx -Credential $esxCred | Out-Null
  Get-VMHostAdvancedConfiguration -Name "ScratchConfig.ConfiguredScratchLocation"
  }

Getting the NAA ID of the LUN to be removed

From the vSphere Client, this information is visible from the Properties window of the datastore.

From the ESXi host, run the command:

# esxcli storage vmfs extent list

The output is similar to: 

Volume Name VMFS UUID                           Extent Number Device Name                           Partition
----------- ----------------------------------- ------------- ------------------------------------  ---------
datastore1  4de4cb24-4cff750f-85f5-0019b9f1ecf6             0  naa.6001c230d8abfe000ff76c198ddbc13e        3
Storage2    4c5fbff6-f4069088-af4f-0019b9f1ecf4             0  naa.6001c230d8abfe000ff76c2e7384fc9a        1
Storage4    4c5fc023-ea0d4203-8517-0019b9f1ecf4             0  naa.6001c230d8abfe000ff76c51486715db        1
LUN01       4e414917-a8d75514-6bae-0019b9f1ecf4             0 naa.60a98000572d54724a34655733506751        1
Make a note of the NAA ID of the datastore, as this information is required later. 

Note: Alternatively, you can run the esxcli storage filesystem list command, which lists all file systems recognized by the ESX host.

Unpresenting a LUN from vSphere Client

To unpresent a LUN from an ESXi 5.0 host using vSphere Client:

1. If the LUN is an RDM, skip to Step 2. Otherwise, in the Configuration tab of the ESXi host, click Storage. Right-click the datastore being removed, and click Unmount.
   
   A Confirm Datastore Unmount window appears. When the prerequisite criteria have been passed, click OK.
   
   Note: To unmount a datastore from multiple hosts, from the vSphere Client select Hosts and Clusters, Datastores and Datastore Clusters view (Ctrl+Shift+D). Perform the umount task and select the appropriate hosts that should no longer access the datastore to be unmounted.
   
2. Choose the Devices View (Under Configuration > Storage):
   
   
   
3. Right-click the NAA ID of the LUN (as noted above) and click Detach. A Confirm Device Unmount window is displayed. When the prerequisite criteria have been passed, click OK.
   
   Note: If you choose the Delete option after unmounting the LUN, it will delete all data from the LUN and remove the partition table from it.
   
4. Under the Operational State of the Device, the LUN will be listed as Unmounted.
5. The LUN can now be unpresented from the SAN. For more information, contact your storage array vendor.
6. Perform a rescan on all ESXi hosts which had visibility to the LUN. The device is automatically removed from the Storage Adapters.

When the device is detached, it stays in an unmounted state even if the device is represented (that is, the detached state is persistent). To bring the device back online, the device needs to be attached.

If the device is to be permanently decommissioned from an ESXi servers(s) , you may have to manually remove the NAA entries from the host configuration by issuing these commands:

1. To list the permanently detached devices:
   
   # esxcli storage core device detached list
   The output is similar to:
   
   Device UID                            State
   ------------------------------------  -----
   naa.50060160c46036df50060160c46036df  off
   naa.6006016094602800c8e3e1c5d3c8e011  off 
   
2. To permanently remove the device configuration information from the system:
   
   # esxcli storage core device detached remove -d NAA_ID
   
   For example:
   
   # esxcli storage core device detached remove  -d naa.50060160c46036df50060160c46036df

Unpresenting a LUN from the command line 

To unpresent a LUN from an ESXi 5.0 host from the command line:

1. If the LUN is an RDM, skip to step 4. Otherwise, to get a list of all datastores mounted to an ESXi host, run the command:
   
   # esxcli storage filesystem list
   
   The output, which lists all VMFS datastores, is similar to:
   
   Mount Point                                       Volume Name UUID                                Mounted Type         Size         Free
   ------------------------------------------------- ----------- ----------------------------------- ------- ------ -----------  -----------
   /vmfs/volumes/4de4cb24-4cff750f-85f5-0019b9f1ecf6 datastore1  4de4cb24-4cff750f-85f5-0019b9f1ecf6    true  VMFS-5   140660178944   94577360896
   /vmfs/volumes/4c5fbff6-f4069088-af4f-0019b9f1ecf4 Storage2    4c5fbff6-f4069088-af4f-0019b9f1ecf4    true  VMFS-3   146028888064    7968129024
   /vmfs/volumes/4c5fc023-ea0d4203-8517-0019b9f1ecf4 Storage4    4c5fc023-ea0d4203-8517-0019b9f1ecf4    true  VMFS-3   146028888064  121057050624
   /vmfs/volumes/4e414917-a8d75514-6bae-0019b9f1ecf4 LUN01       4e414917-a8d75514-6bae-0019b9f1ecf4    true  VMFS-5   146028888064   4266131456
   
2. Unmount the datastore by running the command:
   
   # esxcli storage filesystem unmount [-u <UUID> | -l <label> | -p <path> ]
   
   For example, use one of these commands to unmount the LUN01 datastore:
   
   # esxcli storage filesystem unmount -l LUN01
   # esxcli storage filesystem unmount -u 4e414917-a8d75514-6bae-0019b9f1ecf4
   # esxcli storage filesystem unmount -p /vmfs/volumes/4e414917-a8d75514-6bae-0019b9f1ecf4
   Note: If the VMFS filesystem you are attempting to unmount has active I/O or has not fulfilled the prerequisites to unmount the VMFS datastore, the vmkernel logs show this error:
   
   WARNING: VC: 637: unmounting opened volume ('4e414917-a8d75514-6bae-0019b9f1ecf4' 'LUN01') is not allowed.
   VC: 802: Unmount VMFS volume f530 28 2 4e414917a8d7551419006bae  f4ecf19b 4 1 0 0 0 0 0 : Busy
   
3. To verify that the datastore has been unmounted, run the command:
   
   # esxcli storage filesystem list
   
   The output is similar to:
   
   Mount Point                                       Volume Name UUID                                Mounted Type         Size         Free
   ------------------------------------------------- ----------- ----------------------------------- ------- ------ -----------  -----------
   /vmfs/volumes/4de4cb24-4cff750f-85f5-0019b9f1ecf6 datastore1  4de4cb24-4cff750f-85f5-0019b9f1ecf6    true  VMFS-5   140660178944   94577360896
   /vmfs/volumes/4c5fbff6-f4069088-af4f-0019b9f1ecf4 Storage2    4c5fbff6-f4069088-af4f-0019b9f1ecf4    true  VMFS-3   146028888064    7968129024
   /vmfs/volumes/4c5fc023-ea0d4203-8517-0019b9f1ecf4 Storage4    4c5fc023-ea0d4203-8517-0019b9f1ecf4    true  VMFS-3   146028888064  121057050624
                                                    LUN01       4e414917-a8d75514-6bae-0019b9f1ecf4   false  VMFS-unknown version    0     0
   Note that the Mounted field  is set to false, the Type field is set to VMFS-unknown version, and that no Mount Point exists.
   
   Note: The unmounted state of the VMFS datastore persists across reboots. This is the default behavior. However, it can be changed by appending the --no-persist flag.
   
4. To detach the device/LUN, run this command:
   
   # esxcli storage core device set --state=off -d NAA_ID
   
5. To verify that the device is offline, run this command:
   
   # esxcli storage core device list -d NAA_ID
   
   The output, which shows that the status of the disk is off, is similar to:
   
   naa.60a98000572d54724a34655733506751
      Display Name: NETAPP Fibre Channel Disk (naa.60a98000572d54724a34655733506751)
      Has Settable Display Name: true
      Size: 1048593
      Device Type: Direct-Access
      Multipath Plugin: NMP
      Devfs Path: /vmfs/devices/disks/naa.60a98000572d54724a34655733506751
      Vendor: NETAPP
      Model: LUN
      Revision: 7330
      SCSI Level: 4
      Is Pseudo: false
      Status: off
      Is RDM Capable: true
      Is Local: false
      Is Removable: false
      Is SSD: false
      Is Offline: false
      Is Perennially Reserved: false
      Thin Provisioning Status: yes
      Attached Filters:
      VAAI Status: unknown
      Other UIDs: vml.020000000060a98000572d54724a346557335067514c554e202020
   
   Running the partedUtil getptbl command on the device shows that the device is not found.
   
   For example:
   
   # partedUtil getptbl /vmfs/devices/disks/naa.60a98000572d54724a34655733506751
   
   Error: Could not stat device /vmfs/devices/disks/naa.60a98000572d54724a34655733506751- No such file or directory.
   Unable to get device /vmfs/devices/disks/naa.60a98000572d54724a34655733506751
   
6. The LUN can now be unpresented from the SAN. For more information, contact your storage array vendor.
7. To rescan all devices on the ESXi host, run the command:
   
   # esxcli storage core adapter rescan [ -A vmhba# | --all ]
   
   The devices are automatically removed from the Storage Adapters.
   
   Note: A rescan needs to be run on all hosts that had visibility of the removed LUN.
   
   Note: When the device is detached, it stays in an unmounted state even if the device is represented (that is, the detached state is persistent). To bring the device back online, the device needs to be attached. To do this via the command line, run the command:
   
   # esxcli storage core device set --state=on -d NAA_ID
   
8. If the device is to be permanently decommissioned from an ESXi servers(s), (that is, the LUN has been destroyed), remove the NAA entries from the host configuration by issuing these commands:
   
   
   1. To list the permanently detached devices:
      
      # esxcli storage core device detached list
      
      The output is similar to:
      
      Device UID                            State
      ----------------------------  -----
      naa.50060160c46036df50060160c46036df  off
      naa.6006016094602800c8e3e1c5d3c8e011  off 
      
      
   2. To permanently remove the device configuration information from the system:
      
      # esxcli storage core device detached remove -d NAA_ID
      
      For example:
      
      # esxcli storage core device detached remove  -d naa.50060160c46036df50060160c46036df
   
   The reference to the device configuration is permanently removed from the ESXi host's configuration.

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

Upgrading from ESX 4.x to ESXi 5.0 using the interactive installer

Upgrading to ESXi 5.0 using Update Manager 5.0

USB support for ESX/ESXi 4.1 and ESXi 5.0

ESX/ESXi 4.1 and ESXi 5.0 supports USB device passthrough from an ESX or ESXi to a virtual machine.

 

This article provides information on:

• USB device passthrough requirements and limitations
• How to add a USB controller and a USB device.

For More Info Check this KB article:-

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

What is a Virtual Machine and What are the Components of a VM?

What is a virtual machine?

A virtual machine is a tightly isolated software container that can run its own operating systems and applications as if it were a physical computer. A virtual machine behaves exactly like a physical computer and contains it own virtual (that is, software-based) CPU, RAM hard disk and network interface card (NIC).

What are the components of a virtual machine?

A virtual machine is composed of several processes or userworlds that run in the VMkernel. Combined, the processes collectively make up a group. The following is a summary of components of a virtual machine:

• Virtual Machine Executable (VMX) process - A process that runs in the VMkernel that is responsible for handling I/O to devices that are not critical to performance. The VMX is also responsible for communicating with user interfaces, snapshot managers, and remote console.
• Virtual Machine Monitor (VMM) process - A process that runs in the VMkernel that is responsible for virtualizing the guest OS instructions, and manages memory. The VMM passes storage and network I/O requests to the VMkernel, and passes all other requests to the VMX process. There is a VMM for each virtual CPU assigned to a virtual machine.
• Mouse Keyboard Screen (MKS) process - A process that is responsible for rendering the guest video and handling guest operating system user input.

Check this KB article for more info:-

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

Renaming a virtual machine and its files

A virtual machine's files may be renamed during a disk migration operation, such as Cold Storage Migration, or by manually renaming them in-place from the ESX/ESXi console. Select your preferred method.
Alternatively, a virtual machine could be cloned to a new virtual machine using the Clone method in vCenter Server or using vCenter Converter, and deleting the old virtual machine.

For More Info Check this KB Article:-
http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1029513

vSphere5 Storage vMotion does not rename virtual machine files on completing migration

This is a known issue affecting vSphere 5.0 and is scheduled to be resolved in a future update.

For More Info Check this KB Article:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2008877 

Changing a forgotten root password on an ESX/ESXi host

Reinstalling the ESXi host is the only supported way to reset a password on ESXi.

For More Info Here is link of KB Article:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1317898

Disable and Change the default behaviour of Esxi and Active Directory Integration

As soon as domain is joined by the esxi then if in your active directory a group called "ESX Admins" is present then whatever the users are their in this group will automatically get the administrative rights on the esxi. So i am going to tell all of you how you can change this default behaviour that's given in this picture and You can even completely disable this functionality by setting the option  Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAddto false.

Removing the Administrator role from the group is initially successful, but rebooting the ESX/ESXi host grants the Administrative role again to the group if you will remove this group from esxi by directly connecting it. So the best practice is to change it to no access rather than removing it.
Hope this is Helpful for Everyone......Enjoy

Enable/Size/Disable memory compression cache

Memory compression is used to improve VM performance when you have memory overcommitment and is enabled by default.  ESXi will attempt to compress memory pages that can be sized down to 2kb.  By default, ESXi will use 10% of the allocated memory to the VMs on the host for memory caching, but can be changed using the advanced options below.

Must modify host advanced settings – Mem.MemZipEnable = 1 – enable or disable memory caching.

Must modify host Advanced Settings – Mem.MemZipMaxPct = (value specified in percentage between 5 and 100)

HT option in VM properties

So here is the explanation of these three options:-

Any – Default for all VM’s on a HT System . Virtual CPU of a VM can share cores with other Virtual CPU of the same VM as well Virtual CPU of other VM’s on the host.
None – Virtual CPU of a VM can never share core with other Virtual CPU of the same VM as well as Virtual CPU of other VM’s on the host.
Internal – Virtual CPU of a VM can share core only with other Virtual CPU of the same Virtual Machine.\

Cannot click vSphere Client Security Warning dialog buttons Erro

This is one of the Vmware KB Article:-

Cannot click vSphere Client Security Warning dialog buttons

Symptoms

• When logging in with the vSphere Client you see a Security Warning dialog with a message similar to:
  An untrusted SSL certificate is installed on "<hostname>" and secure communication cannot be guaranteed. Depending on your security policy, this issue might not represent a security concern. You may need to install a trusted SSL certificate on your server to prevent this warning from appearing.
  
• You cannot click any of the dialog buttons or move the dialog window.

Resolution

This issue occurs if:

• You have a Message of the Day configured for your vCenter Server.
  
  And
  
• You have Update Manager installed and have not acknowledged the Security Warning for it.
  
  And
  
• You have not acknowledged the Security Warning for your vCenter Server.

This issue occurs because the Update Manager Security Warning is underneath the Security Warning displayed from vCenter Server. Although you cannot view the dialog, it must be canceled before you can proceed.

To cancel the dialog underneath the first Security Warning, press Alt+F4. This cancels the first dialog window (that is not visible) and allows you to acknowledge the Security Warning.

To resolve this issue temporarily, remove the Message of the Day, then add it back after you acknowledge the Security Warnings.

Unable To Access User-Defined Storage Service

The problem lies in that the Web Client service conflicts with the Profile Driven Storage service.  I’m not sure if they use the same port numbers or if they just collide in memory space or something.  As long as the Web Client service is running, the Profile Driven Storage options cannot be configured on a Data Store.  The fix is somewhat simple:

1.  Open the Service console on your vCenter server.

2.  Find the VMware Web Client service.

3.  Stop or disable it.

4.  Restart VIClient.

Enable FT in Nested Environment

When I was studying for my VCP5 I created a little test envirment with ESXi and created two Virtual ESXi hosts a virtual vCenter server and an openfiler VM for shared storage. I am assuming that you have already created the Virtual network and enabled a vmkernel port to allow FT Logging between the two hosts

Now the issue I had was that FT was not supported with Virtual ESXi due to hardware limitations, to get round this I had to modify the configuration of my VM to allow it to run FT.

NOW THE IMPORTANT BIT, THIS IS NOT A SUPPORTED CHANGE, AND SHOULD ONLY!!!!!!! BE USED FOR TEST AND DEV AND NOT!!!!!!!! FOR PRODUCTION.

So to prepare the VM

In your vSphere Client select the VM, right click the VM and select EDIT SETTINGS

Click the Options Tab and the select Advanced > General

Now select the Configuration Parameters within the Advanced > General pane.

On the Configuration Parameters page, find the option replay.supported and change the value to true (if this does not exist add  it by clicking Add Row at the bottom of the configuration Parameters screen)

Then at the bottom of the Configuration Parameters page, click Add Row

In the name column type replay.allowBTOnly in the value column, type true

Then at the bottom of the Configuration Parameters page, click Add Row

In the name column type replay.allowFT in the value column, type true

Click OK twice from the Configuration Parameters screen.

From the vSphere Client, right click your VM and then select Fault Tolerance > Turn On Fault Tolerance and follow the instructions.

Hyper-threading on VMware vSphere Virtual Machine Properties

Hyper-threading :

Hyper-threading is an Intel-proprietary technology used to improve parallelization of computations. For each processor core that is physically present, the Operating System  addresses two logical processors, and shares the workload between them when possible. With Hyper-threading a single processor core can execute two independent threads simultaneously . Performance improvements on hyper-threaded machines are dependent on the application and work loads . We might see slight performance improvements in certain applications while certain application performance might degrade as cache is shared between logical processors .

To enable or not to enable Hyper-threading on Hypervisor hosts has always been a debatable question with no clear winners .  HT cannot double the performance of a processor but it can certainly help in improving the performance slightly depending on the work load .

I have tried to consolidate and mention some considerations that would help administrators decide if to enable / disable  HT .

Hyper-threading has to be enabled in BIOS as well as in ESX . By default , HT is enabled in ESX
ESX can intelligently determine if a system  is enabled for hyper-threading and can load balance evenly across all cores of a processor.
Logical processors or threads on the same core will have consecutive numbers such as ,  for example CPU 0 and CPU 1 are on the first core of a processor . This has to be taken into account if CPU Affinity settings are used for Virtual machines
VMs are preferentially scheduled on two different cores rather than two logical processors on the same core .
In ESX , Administrators will be able to define HT core sharing options for individual VM’s in Advanced CPU option available in Resources tab while selecting individual Virtual machine’s Settings . Three options that are available would be :

Any – Default for all VM’s on a HT System . Virtual CPU of a VM can share cores with other Virtual CPU of the same VM as well Virtual CPU of other VM’s on the host.

None – Virtual CPU of a VM can never share core with other Virtual CPU of the same VM as well as Virtual CPU of other VM’s on the host.

Internal – Virtual CPU of a VM can share core only with other Virtual CPU of the same Virtual Machine.
Never bind two CPU intensive VMs to two logical processor of same core as it will be difficult to meet the resource demands of these intensive workloads

To conclude , From my personal experience , we have never enabled Hyper-threading in VI3 environments. With VI4 , We have enabled HT in certain environments and although we do not see much improvement in terms of performance we don’t see negative impact as well .  Enabling / Disabling Hyper-threading is a decision that is left to the administrators to decide after carefully analyzing their environments and work loads that constitutes them . 

Virtual Network Adapter types in vSphere5

Only those network adapters that are appropriate for the virtual machine you are creating, are available configuration options in the Choose Networks window.

• Vlance — An emulated version of the AMD 79C970 PCnet32- LANCE NIC, an older 10Mbps NIC with drivers available in most 32-bit guest operating systems except Windows Vista and later. A virtual machine configured with this network adapter can use its network immediately.
• VMXNET — The VMXNET virtual network adapter has no physical counterpart. VMXNET is optimized for performance in a virtual machine. Because operating system vendors do not provide built-in drivers for this card, you must install VMware Tools to have a driver for the VMXNET network adapter available.
• Flexible — The Flexible network adapter identifies itself as a Vlance adapter when a virtual machine boots, but initializes itself and functions as either a Vlance or a VMXNET adapter, depending on which driver initializes it. With VMware Tools installed, the VMXNET driver changes the Vlance adapter to the higher performance VMXNET adapter.
• E1000 — An emulated version of the Intel 82545EM Gigabit Ethernet NIC. A driver for this NIC is not included with all guest operating systems. Typically Linux versions 2.4.19 and later, Windows XP Professional x64 Edition and later, and Windows Server 2003 (32-bit) and later include the E1000 driver.
  
  Note: E1000 does not support jumbo frames prior to ESX/ESXi 4.1.
• E1000e - This feature emulates a newer model of Intel gigabit NIC (number 82574) in the virtual hardware. This is known as the "e1000e" vNIC. e1000e is available only on hardware version 8 (and newer) VMs in vSphere5. It is the default vNIC for Windows 8 and newer (Windows) guest OSes. For Linux guests, e1000e is not available from the UI (e1000, flexible vmxnet, enhanced vmxnet, and vmxnet3 is available for Linux).
  
• VMXNET 2 (Enhanced) — The VMXNET 2 adapter is based on the VMXNET adapter but provides some high-performance features commonly used on modern networks, such as jumbo frames and hardware offloads. This virtual network adapter is available only for some guest operating systems on ESX/ESXi 3.5 and later.
  
  VMXNET 2 is supported only for a limited set of guest operating systems:
  
  
  • 32- and 64-bit versions of Microsoft Windows 2003 (Enterprise, Datacenter, and Standard Editions).
    
    Note: You can use enhanced VMXNET adapters with other versions of the Microsoft Windows 2003 operating system, but a workaround is required to enable the option in VMware Infrastructure (VI) Client or vSphere Client. See Enabling enhanced vmxnet adapters for Microsoft Windows Server 2003 (1007195) if Enhanced VMXNET is not offered as an option.
  • 32-bit version of Microsoft Windows XP Professional
  • 32- and 64-bit versions of Red Hat Enterprise Linux 5.0
  • 32- and 64-bit versions of SUSE Linux Enterprise Server 10
  • 64-bit versions of Red Hat Enterprise Linux 4.0
  • 64-bit versions of Ubuntu Linux
  In ESX 3.5 Update 4 or higher, these guest OS are also supported:
  
  • Microsoft Windows Server 2003, Standard Edition (32-bit)
  • Microsoft Windows Server 2003, Standard Edition (64-bit)
  • Microsoft Windows Server 2003, Web Edition
  • Microsoft Windows Small Business Server 2003

Note: Jumbo Frames are not supported in the Solaris Guest OS for VMXNET 2.

• VMXNET 3 — The VMXNET 3 adapter is the next generation of a paravirtualized NIC designed for performance, and is not related to VMXNET or VMXNET 2. It offers all the features available in VMXNET 2, and adds several new features like multiqueue support (also known as Receive Side Scaling in Windows), IPv6 offloads, and MSI/MSI-X interrupt delivery.
  
  VMXNET 3 is supported only for virtual machines version 7 and later, with a limited set of guest operating systems:
  
  • 32- and 64-bit versions of Microsoft Windows XP,7, 2003, 2003 R2, 2008, and 2008 R2
  • 32- and 64-bit versions of Red Hat Enterprise Linux 5.0 and later
  • 32- and 64-bit versions of SUSE Linux Enterprise Server 10 and later
  • 32- and 64-bit versions of Asianux 3 and later
  • 32- and 64-bit versions of Debian 4
  • 32- and 64-bit versions of Ubuntu 7.04 and later
  • 32- and 64-bit versions of Sun Solaris 10 U4 and later
  Notes:
• In ESX/ESXi 4.1 and earlier releases, Jumbo Frames are not supported in the Solaris Guest OS for VMXNET 2 and VMXNET 3. The feature is supported starting with ESXi 5.0 for VMXNET 3 only.
  
  For more information, see Enabling Jumbo Frames on the Solaris Guest OS (2012445).
• Fault Tolerance is not supported on a virtual machine configured with a VMXNET 3 vNIC in vSphere 4.0, but is fully supported on vSphere 4.1.

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

Prevent the Connection with ESXi Host from the Another vCenter Server

Enable the lockdown mode on ESXi host and then only whatever the current vCenter Server is that can manage the ESXi host no other vCenter can manage that ESXi host.