Do not use both ESX and ESXi hosts in clusters with fault tolerant virtual machines (1013637)

Details

ESX hosts may become incompatible with ESXi hosts for VMware Fault Tolerance (FT) purposes after they are patched, even if they are patched to the same level.

 

In particular, ESX 4.0 and ESXi 4.0 hosts with patches ESX400-200906401-BG (ESX) and ESXi400-200906401-BG (ESXi) become incompatible and can no longer run a Primary and Secondary virtual machine of the same FT pair.

Solution

When creating a cluster that contains fault tolerant virtual machines, the cluster should consist of all ESX hosts or all ESXi hosts and not a mix of ESX and ESXi hosts.

 

If you have a mixed cluster, the ESX hosts and ESXi hosts might become incompatible for VMware Fault Tolerance purposes. There is less flexibility in running fault tolerant virtual machine pairs in the cluster, and it may also mean that a compatible host for starting a new Secondary virtual machine cannot be found if a host in the cluster fails.

 

Note: In vSphere 5.0, at least two FT-certified hosts running the same FT version or host build number is needed. For more information about Cluster Requirements for Fault Tolerance in vSphere 5.0, see Fault Tolerance Checklist in the vSphere Availability Guide.

 

Source:-

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

Why vMotion Enabled vmkernel port is required for FT?

Preferably, each host has separate 1 GbE NICs for FT logging traffic and VMotion. The reason for recommending separate NICs is that the creation of the Secondary VM is done by migrating the Primary VM with VMotion. This can produce significant traffic on the VMotion NIC and could affect VMware FT logging traffic if the NICs are shared.

Backing up and restoring ESXi configuration using the vSphere Command-Line Interface and vSphere PowerCLI (2042141)

Purpose

This article provides the steps to back up and restore the configuration of an ESXi host using the vSphere Command-Line Interface (vSphere CLI) and vSphere PowerCLI.

Resolution

Backing up ESXi host configuration data

Using the vSphere CLI

To back up the configuration data for an ESXi host using the vSphere CLI, run the command:

vicfg-cfgbackup --server=ESXi_host_IP_address --username=root -s output_file_name
If you are using vSphere CLI for Windows, run this command:

vicfg-cfgbackup.pl --server=ESXi_host_IP_address --username=root -s output_file_name


Where ESXi_host_IP_address is the IP address of the ESXi host and output_file_name is the name of the backup file you will create.

Note: From vSphere CLI for Windows, ensure you are executing the command from C:\Program Files\VMware\VMware vSphere CLI\bin

For example:
vSphere CLI:

vicfg-cfgbackup --server=10.0.0.1 --username=root -s ESXi_test1_backup.txt


vSphere CLI for Windows:

vicfg-cfgbackup.pl --server=10.0.0.1 --username=root -s ESXi_test1_backup.txt

Note:

Use the --password=root_password option (where root_password is the root password for the host) to avoid being prompted for the root user password when you run the script.

A backup text file is saved in the current working directory where you run the vicfg-cfgbackup script. You can also specify a full output path for the file.


Using the vSphere PowerCLI

To back up the configuration data for an ESXi host using the vSphere PowerCLI, run the command:

Get-VMHostFirmware -VMHost ESXi_host_IP_address -BackupConfiguration -DestinationPath output_directory

Where ESXi_host_IP_address is the IP address of the ESXi host and output_directory is the name of the directory where the output file will be created.

For example:

Get-VMHostFirmware -VMHost 10.0.0.1 -BackupConfiguration -DestinationPath C:\Downloads

Note: A backup file is saved in the directory specified with the -DestinationPath option.

Using the ESXi Command Line

To synchronize the configuration changed with persistent storage, run the command:

vim-cmd hostsvc/firmware/sync_config

To backup the configuration data for an ESXi host, run the command:

vim-cmd hostsvc/firmware/backup_config

Note: The command should output a URL in which a web browser may be used to download the file. The backup file is located in the/scratch/downloads directory as configBundle-<HostFQDN>.tgz

Restoring ESXi host configuration data

Using the vSphere CLI

Note: When restoring configuration data, the build number of the host must match the build number of the host that created the backup file. Use the -f option (force) to override this requirement.

To restore the configuration data for an ESXi host using the vSphere CLI:

1. Power off all virtual machines that are running on the host that you want to restore.
2. Log in to a server where the vCLI is installed.
3. Run the vicfg-cfgbackup script with the -l flag to load the host configuration from the specified backup file:
   
   vSphere CLI:
   
   vicfg-cfgbackup --server=ESXi_host_IP_address --username=root -l backup_file
   vSphere CLI for Windows:
   
   vicfg-cfgbackup.pl --server=ESXi_host_IP_address --username=root -l backup_file
   
   Where ESXi_host_IP_address is the IP address of the ESXi host and backup_file is the name of the backup file to use for the restore.
   
   For example:
   
   vicfg-cfgbackup --server=10.0.0.1 --username=root -l ESXi_test1_backup.txt
   vSphere CLI for Windows:
   
   vicfg-cfgbackup.pl --server=10.0.0.1 --username=root -l ESXi_test1_backup.txt
   
   Notes:
   
   • When you run this command, you are prompted for confirmation before proceeding. You can override this safety feature using the -q option.
   • Use the --password=root_password option (where root_password is the root password for the host) to avoid being prompted for the root user password when you run the script.

To restore an ESXi host to the stock configuration settings, run the command:

vicfg-cfgbackup --server=ESXi_host_IP_address --username=root -r

For example:

vicfg-cfgbackup --server=10.0.0.1 --username=root -r

Using the vSphere PowerCLI

Note: When restoring configuration data, the build number of the host must match the build number of the host that created the backup file. Use the -force option to override this requirement.

1. Put the host into maintenance mode by running the command:
   
   Set-VMHost -VMHost ESXi_host_IP_address -State 'Maintenance'
   
   Where ESXi_host_IP_address is the IP address of the ESXi host.
   
2. Restore the configuration from the backup bundle by running the command:
   
   Set-VMHostFirmware -VMHost ESXi_host_IP_address -Restore -SourcePath backup_file -HostUser username -HostPassword password
   
   Where ESXi_host_IP_address is the IP address of the ESXi host, backup_file is the name of the backup bundle to use for the restore, and username and password are the credentials to use when authenticating with the host.
   
   For example:
   
   Set-VMHostFirmware -VMHost 10.0.0.1 -Restore -SourcePath c:\bundleToRestore.tgz -HostUser root -HostPassword exampleRootPassword

Using the ESXi Command Line:

Note: When restoring configuration data, the build number of the host must match the build number of the host that created the backup file.

1. Put the host into maintenance mode by running the command:
   
   vim-cmd hostsvc/maintenance_mode_enter
   
2. Copy the backup configuration file to a location accessible by the host and run the command:
   
   In this case, the configuration file was copied to the host's /tmp directory. For more information, see Using SCP to copy files to or from an ESX host (1918).

vim-cmd hostsvc/firmware/restore_config /tmp/configBundle.tgz

Note: Executing this command will initiate an automatic reboot of the host after command completion.

Additional Information

For more information, see:

• Backing Up Configuration Information with vicfg-cfgbackup in the vSphere 5.1 Command Line Documentation
• Get-VMHostFirmware in the vSphere PowerCLI Reference
• Set-VMHostFirmware in the vSphere PowerCLI Reference

To be alerted when this article is updated, click Subscribe to Document in the Actions box.

See Also

 

Using SCP to copy files to or from an ESX host (1918)

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

 

Supported vCenter Server high availability options (1024051)

Purpose

This article provides information about supported high availability options for VMware vCenter Server.

Resolution

High availability for VMware vCenter Server can be primarily implemented using VMware vCenter Server Heartbeat, VMware High Availability (HA), and Fault Domain Manager (FDM) for vCenter Server 5.x. While VMware vCenter Server Heartbeat provides deep and comprehensive levels of protection against unplanned and, in some cases, planned vCenter Server downtime, VMware HA/FDM is a good alternative for vCenter Server instances running on a virtual machine. VMware HA/FDM provides robust general-purpose protection against hardware and operating system failures.

 

You may choose to protect VMware vCenter Server using third-party clustering solutions including, but not limited to: 

• MSCS (Microsoft Cluster Services) 
• Microsoft SQL Server 2012 AlwaysOn
• VCS (Veritas Cluster Services)

VMware does not certify these third-party solutions. VMware will offer best effort support for any issues encountered with an environment that uses third-party solutions for protecting against VMware VirtualCenter downtime. However, if your issue is determined to be related to the third-party clustering solution, VMware will refer to our third-party software policy. For more information, see the VMware third-party hardware and software support policy.

As of vCenter Server 5.5 in vSphere 5.5, VMware introduced support for using Microsoft SQL Cluster Service for use as a back end database. Previously, using Microsoft SQL Cluster was not supported for any version of vSphere. For more information, see Enabling Microsoft SQL Clustering Service in VMware vCenter Server 5.5 (2059560).

 

Additional Information

• For more information about VMware vCenter Server Heartbeat, see the vCenter Server Heartbeat documentation.
• For more information about VMware High Availability, see the High Availability Guide.
• For more information about MSCS supportability, see Microsoft Cluster Service (MSCS) support on ESX/ESXi (1004617).

See Also

Microsoft Cluster Service (MSCS) support on ESXi/ESX (1004617)

 

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

Hot Add/Remove CPU & Hot Add Memory Supported OS

Here is the table of results I came up with:

	Memory hot add	Memory hot remove	CPU hot plug	CPU hot unplug
Windows Server 2003 STD x86
Windows Server 2003 STD x64
Windows Server 2003 ENT x86
Windows Server 2003 ENT x64
Windows Server 2008 STD x86	*
Windows Server 2008 STD x64	*		*
Windows Server 2008 ENT x86
Windows Server 2008 ENT x64			*
Windows Server 2008 DC x86
Windows Server 2008 DC x64
Windows Server 2008 R2 DC x64 (experimental support only)
* Reboot of guest OS required to recognize added hardware

Thanks to Jason Boche

Yellow Warning in ESXi Host Summary Tab "Quickstats on ESXi host is not Up-to-date" in vSphere 5.5?

When connecting to VMware vCenter Server 5.5 using the VMware vSphere Client or VMware vSphere Web Client, the Summary tab of the ESXi 5.5 host shows a yellow warning.

You see the error:

Configuration issues. "Quick stats on hostname is not up-to-date"
This issue does not occur if you connect directly to the ESXi host.

 

This issue is resolved in VMware vCenter Server 5.5.0b, available at VMware Downloads. For more information, see the vCenter Server 5.5.0b Release Notes.

To work around this issue when you do not want to upgrade, add these quickStats parameters to the Advanced Settings of vCenter Server:

• vpxd.quickStats.HostStatsCheck
• vpxd.quickStats.ConfigIssues

Note: Adding these parameters to vCenter Server does not affect future upgrades.

 

To add the quickStats parameters to the Advanced Settings of vCenter Server:

1. In the vSphere Web Client, navigate to the vCenter Server instance.
2. Select the Manage tab.
3. Select Settings > Advanced Settings.
4. Click Edit.
5. In the Key field, enter this key:
   
   vpxd.quickStats.HostStatsCheck
6. In the Value field, enter:
   
   False
7. Click Add.
8. In the Key field, enter this key:
   
   vpxd.quickStats.ConfigIssues
9. In the Value field, enter:
   
   False
10. Click Add.
11. Click OK.
12. Restart the vCenter Server services. For more information, see:
    
    
    • Windows-based vCenter Server – Stopping, starting, or restarting vCenter services (1003895)
    • vCenter Server Appliance – Stopping, starting, or restarting vCenter Server Appliance services (2054085)

 

 

 

To work around this issue in the event that vSphere Web Client is inaccessible, add these quickStats parameters to the vpxd.cfg file:

• <HostStatsCheck>false</HostStatsCheck>
• <ConfigIssues>false</ConfigIssues>

To add the quickStats parameters to the vpxd.cfg file:

1. Back up the existing vpxd.cfg file. Do not skip this step.
2. Open the the vpxd.cfg file using a text editor. For more information on using VI editor, see Editing files on an ESX host using vi or nano (1020302).
   
   By default, the vpxd.cfg file is located at:
3. • Windows-based vCenter Server – C:\ProgramData\VMware\VMware VirtualCenter\
   • vCenter Server Appliance – /etc/vmware-vpx/
4. Add these entries between the <vpxd>...</vpxd> tags:
   
   <vpxd>
   ...
      <quickStats>
         <HostStatsCheck>false</HostStatsCheck>
         <ConfigIssues>false</ConfigIssues>
      </quickStats>
   ...
   </vpxd>
5. Save and close the vpxd.cfg file.
6. Restart the vCenter Server services. For more information, see:
   
   • Windows-based vCenter Server – Stopping, starting, or restarting vCenter services (1003895)
   • vCenter Server Appliance – Stopping, starting, or restarting vCenter Server Appliance services (2054085)

Reference KB 2061008