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.