Memory Leakage

Memory Leak

A memory leak is like a virtual oil leak in your computer. It slowly drains the available memory, reducing the amount of free memory the system can use. Most memory leaks are caused by aprogram that unintentionally uses up increasing amounts of memory while it is running. This is typically a gradual process that gets worse as the program remains open. If the leak is bad enough, it can cause the program to crash or even make the whole computer freeze.

The most common reason programs have memory leaks is due to a programming error where unused memory is not allocated back to the system. This means the amount of RAM the program uses is always growing. Therefore, the program is constantly "leaking" memory. A memory leak may also be caused by a program that requests new memory too frequently, instead of using available memory. This means each time more memory is requested, the program takes up additional RAM instead of using memory that has already been made available to the program.

Fortunately, memory leaks are not as messy as oil leaks and can be more easily fixed. Software development applications often include debuggers that can check programs for memory leaks. Once the source of the leak is found, the programmer can modify the code so that the program uses memory more efficiently. If you are using a program that has a memory leak, you can temporarily fix the problem by simply quitting the program and opening it again. Once the program has been quit, the memory is automatically allocated back to the system. Of course, if the leak continues to be a problem, the best solution is to let the developer know about the issue so it can be fixed.

Difference Between VMFS 3 and VMFS 5

This post explains you the major difference between VMFS 3 and VMFS 5. VMFS 5 is available as part of vSphere 5. VMFS 5 is introduced with lot of performance enhancements. Newly installed ESXi 5 will be formatted with VMFS 5 version but if you have upgraded the ESX 4 or ESX 4.1 to ESXi 5, then datastore version will be VMFS 3 only. You will able to upgrade the VMFS 3 to VMFS 5 via vSphere client once ESXi upgrade is Complete. This posts tells you some major differences between VMFS 3 and VMFS 5

Capability	VMFS 3	VMFS 5
Maximum single Extend size	2 TB  less 512 bytes	64 TB
Partition Style	MBR (Master Boot Record) style	GPT (GUID Partition Table)
Available Block Size	1 MB/2MB/4MB/8MB	only 1 MB
Maximum size of RDM in  Virtual Compatibiltiy	2 TB  less 512 bytes	2 TB  less 512 bytes
Maximum size of RDM in  Phsical Compatibiltiy	2 TB  less 512 bytes	64 TB
Supported Hosts versions	ESX/ESX 3.X, 4.X & 5.x	Only ESXi 5 is supported
Spanned Volume size	64 TB (32 extends with max  size of extent is 2 TB)	64 TB (32 extends with  any size combination)
Upgrade path	VMFS 3 to VMFS 5	Latest Version. NO upgarde  available yet.
File Limit	30,000	100,000
Sub-Block size	64 KB	8 KB

What about VMware Virtual Machine hardware versions

I often get the question: “What Virtual Machine hardware version do I need?”.

It depends on the features you need. If you want for example use the “Changed Blocked Tracking (CBT)” feature, you need at least hardware version 7.

In ESX 3.x hardware version 4 is introduced, in vSphere 4.x hardware version 7 is introduced and in vSphere 5 hardware version 8 is introduced. Here is an overview of the hardware version and the features they have:

Hardware version	Features	Products
8	- Up to 32 vCPUs per VM - Maximum 1 TB RAM per VM - 3-D graphics and high-definition audio - Smart-card reader support - USB 3.0 devices are supported - Improved network driver for the E1000e network adapter, provided by VMware tools - Greater resources are available with vCloud Director 1.5	Hardware version 8 is the default for new VM in: - ESX 5.x - Fusion 4.x - Workstation 8.x - Player 4.x
7	- Serial Attached SCSI (SAS) virtual device for Microsoft Cluster Service — Provides support for running Windows Server 2008 in a Microsoft Cluster Service configuration. - IDE virtual device — Ideal for supporting older operating systems that lack SCSI drivers. - VMXNET Generation 3.VMXNET is optimized for performance in a virtual machine - Virtual Machine Hot Plug Support— Provides support for adding and removing virtual devices, adding virtual CPUs, and adding memory to a virtual machine without having to power off the virtual machine. - Change Block Tracking (CBT) support. Incease VADP backups	Hardware version 7 is the default for new VM in: - ESX 4.x - Fusion 3.x - Fusion 2.x - Workstation 7.x & 6.5 - Player 3.x - Server 2.x
4		Hardware version 4 is the default for new VM in: - ESX 3.x - ACE 2.x - Fusion 1.x - Player 2.x
3		Hardware version 3 is the default for new VM in: - ESX 2.x - GSX Server 3.x

Considerations before upgrading the hardware version of the VM:

- Important to know is that upgrading the hardware version of the VM requires downtime!

- Virtual machines with hardware version 7 can only run on ESX(i) 4.x and ESXi 5.x. Virtual machines with hardware version 8 can only run on ESXi 5.x

- When you upgrade from virtual hardware version 4 to version 8, the upgrade is reversible if you take a virtual machine backup or snapshot before performing the upgrade.

- To automate this process, consider using Update Manager for virtual machine upgrades

- Update Manager takes automatic snapshots before performing virtual machine upgrades

- Be sure to upgrade first the VMware tools of the VM.  I you upgrade the virtual hardware before you upgrade VMware Tools, the virtual machine might lose its network settings

- Verify that all VMs and .VMDK files are stored on VMFS3, VMFS5 or NFS volumes

Steps in the hardware version upgrade process:

- Do an inventory on the current hardware and VMware tools versions. This can be done for example by using the vCenter client, RVtools utility or PowerCLI

- Install or upgrade the VMware tools (reboot required)

- Power on the VM

- Before upgrading create a backup or snapshot of the VM

- Backup the NIC IP settings with the VMUpgradeHelper.exe command. More information can be found here

- Power off the VM

- Upgrade Virtual Hardware

- Start VM  (reboot after the new hardware is discovered)

- Check if all the IP addresses are correct

Downgrade methods:

There is no button in vCenter to revert back to an earlier Hardware version. Here are two methods to go back to an earlier version of the hardware version:

- Create before upgrading the hardware version a snapshot when the VM is powered down.

- Using VMware Converter

Upgrading issues to know about:

- Upgrading virtual hardware in ESX 4.x may cause Windows 2008 disks to go offline (more information can be found here)

- After a hardware version upgrade the configuration can be messed up on  for example Microsoft ISA, Microsoft NLB clusters and RSA servers

- After upgrading a Windows virtual machine from hardware version 4 to hardware version 7, virtual NIC settings (such as static IP configuration) are lost. Make sure you backup the VM IP settings with the VMUpgradeHelper.exe command. More information can be found here

================================================

You've probably seen it; when you create a new virtual machine under vSphere, you're asked to choose a hardware version
Version 4
Runs on ESX 3.0 and later – including vSphere – VMware Server 1.0 and later.
Recommended when you're sharing storage with ESX 3 or 3.5 machines.
Use if you need to migrate virtual machines back to ESX 3.x for anything.
Version 7
Runs on vSphere 4.0 and later as well as VMware Server 2.0.
Use when you don't need to migrate machines back to ESX 3.x servers. You cannot run version 7 virtual guests under versions of ESX prior to 4.0.
The table below shows you the primary differences between the two virtual hardware versions.
 Version 4Version 7Default for vSphere 4.0+NoYesDefault for ESX 3.5x and lowerYesN/ARAM65 GB255 GBVirtual CPUs48Microsoft cluster supportNoYesNICs/VM410USB supportNoYesHot plug RAM/processorsNoYes
 In order to upgrade a virtual machine from version 4 hardware to version 7 hardware, you need to first install the latest VMware Tools.
Once the upgrade is complete, shut down the virtual machine.
Next, right-click the virtual machine you'd like to upgrade and choose Upgrade Virtual Hardware.
You will receive a warning indicating that the process you're about to undertake is irreversible and will make it impossible to run the virtual machine on older VMware products, such as ESX 3.5. Click the Yes button to proceed.
Once the virtual hardware upgrade process is complete, start the virtual machine. Once you do so and you log in, Windows (assuming that's your guest OS) will add the new drivers that are necessary to support t

You've probably seen it; when you create a new virtual machine under vSphere, you're asked to choose a hardware version

Version 4

• Runs on ESX 3.0 and later – including vSphere – VMware Server 1.0 and later.
• Recommended when you're sharing storage with ESX 3 or 3.5 machines.
• Use if you need to migrate virtual machines back to ESX 3.x for anything.

Version 7

• Runs on vSphere 4.0 and later as well as VMware Server 2.0.
• Use when you don't need to migrate machines back to ESX 3.x servers. You cannot run version 7 virtual guests under versions of ESX prior to 4.0.

The table below shows you the primary differences between the two virtual hardware versions.

	Version 4	Version 7
Default for vSphere 4.0+	No	Yes
Default for ESX 3.5x and lower	Yes	N/A
RAM	65 GB	255 GB
Virtual CPUs	4	8
Microsoft cluster support	No	Yes
NICs/VM	4	10
USB support	No	Yes
Hot plug RAM/processors	No	Yes

In order to upgrade a virtual machine from version 4 hardware to version 7 hardware, you need to first install the latest VMware Tools.

Once the upgrade is complete, shut down the virtual machine.
Next, right-click the virtual machine you'd like to upgrade and choose Upgrade Virtual Hardware.

You will receive a warning indicating that the process you're about to undertake is irreversible and will make it impossible to run the virtual machine on older VMware products, such as ESX 3.5. Click the Yes button to proceed.

Once the virtual hardware upgrade process is complete, start the virtual machine. Once you do so and you log in, Windows (assuming that's your guest OS) will add the new drivers that are necessary to support the new hardware.


Once the driver installation is complete, click Restart Now.

Troubleshooting common VMware ESX host server problems

Panicking at the onset of a high impact technical problem can cause impulsive decision making that enhances the problem. Before trying to troubleshoot any problem, pause and relax to approach the task with a clear mind, then address each symptom, possible cause and resolution appropriately.

In this series, I offer solutions for many common problems that arise with VMware ESXhost servers, VirtualCenter, and virtual machines in general. Let’s begin by addressing common issues with VMware ESX host servers.

Windows server administrators have long been familiar with the dreaded Blue Screen of Death (BSOD), which signifies a complete halt by the server. VMware ESX has a similar state called the purple screen of death (PSOD) which is typically caused by hardware problems or a bug in the VMware code.

Troubleshooting a purple screen of death When a PSOD occurs, the first thing you want to do is note the information displayed on the screen. I suggest using a digital camera or cell phone to take a quick photo. The PSOD message consists of the ESX version and build, the exception type, register dump, what was running on each CPU at the time of the crash, back-trace, server up-time, error messages and memory core dump info. The information won’t be useful to you, but VMware support can decipher it and help determine the cause of the crash.

Unfortunately, other than recording the information on the screen, your only option when experiencing a PSOD is to power the server off and back on. Once the server reboots you should find a vmkernel-zdump-* file in your server /root directory. This file will be valuable for determining the cause. You can use the vmkdump utility to extract the vmkernel log file from the file (vmkdump–l ) and examine it for clues as to what caused the PSOD. VMware support will usually want this file also. One common cause of PSOD’s is defective server memory; the dump file will help identify which memory module caused the problem so it can be replaced.

Checking your RAM for errors If you suspect your system’s RAM may be at fault you can use a built-in utility to check your RAM in the background without affecting your running virtual machines. The RAM check utility runs in the VMkernel space and can be started by logging into the Service Console and typing Service Ramcheck Start.

While RAM check is running it will log all activity and any errors to the /var/log/vmware directory in files called ramcheck.log and ramcheck-err.log. One drawback, however, is that it’s hard to test all of your RAM with this utility if you have virtual machines (VMs) running, as it will only test unused RAM in the ESX system. A more thorough method of testing your server’s RAM is to shutdown ESX, boot from a CD, and run Memtest86+.

Using the vm-support utility If you contact VMware support, they will usually ask you to run the vm-support utility that packages all of the ESX server log and configuration files into a single file. To run this utility, simply log in to the service console with root access, and type “vm-support” without any options. The utility will run and create a single Tar file that will be named “esx—..tgz”. You can send it via FTP to VMware support. Make sure you delete the Tar file from the ESX Server once you are done to save disk space.

Alternatively, you can generate the same file by using the VMware Infrastructure Client (VI Client). Select Administration, then Export Diagnostic Data, and select your host (VirtualCenter data optional) and a directory on your local PC to store the file that will be created.

Using log files for troubleshooting Log files are generally your best tool for troubleshooting any type of problem. ESX has many log files. Which ones you should check depends on the problem you are experiencing. Below is the list of ESX log files that you will commonly use to troubleshoot ESX server problems. The VMkernel and hosted log files are usually the logs you will want to check first.

• VMkernel- /var/log/vmkernel – Records activities related to the virtual machines and ESX server. Rotated with a numeric extension, current log has no extension, most recent has a “.1″ extension.
• VMkernel Warnings- /var/log/vmkwarning – Records activities with the virtual machines, a subset of the VMkernel log and uses the same rotation scheme.
• VMkernel Summary- /var/log/vmksummary – Used to determine uptime and availability statistics for ESX Server; readable summary found in /var/log/vmksummary.txt.
• ESX Server host agent log- /var/log/vmware/hostd.log – Contains information on the agent that manages and configures the ESX Server host and its virtual machines. (Search the file date/time stamps to find the log file it is currently outputting to, or open hostd.log, which is linked to the current log file.)
• ESX Firewall log- /var/log/vmware/esxcfg-firewall.log – Logs all firewall rule events.
• ESX Update log- /var/log/vmware/esxupdate.log – Logs all updates done through the esxupdate tool.
• Service Console- /var/log/messages – Contains all general log messages used to troubleshoot virtual machines or ESX Server.
• Web Access- /var/log/vmware/webAccess – Records information on web-based access to ESX Server.
• Authentication log- /var/log/secure – Contains records of connections that require authentication, such as VMware daemons and actions initiated by the xinetd daemon.
• Vpxa log – /var/log/vmware/vpx – Contains information on the agent that communicates with VirtualCenter. Search the file date/time stamps to find the log file it is currently outputting to or open hostd.log which is linked to the current log file.

As part of the troubleshooting process, often times you’ll need to find out the version of various ESX components and which patches are applied. Below are some commands you can run from the service console to do this:

• Type vmware –v to check ESX Server version, i.e., VMware ESX Server 3.0.1 build-32039
• Type esxupdate –l queryto see which patches are installed.
• Type vpxa –v to check the ESX Server management version, i.e. VMware VirtualCenter Agent Daemon 2.0.1 build-40644.
• Type rpm –qa | grep VMware-esx-tools to check the ESX Server VMware Tools installed version – i.e., VMware-esx-tools-3.0.1-32039.

If all else fails, restart the VMware host agent service Many ESX problems can be resolved by simply restarting the VMware host agent service (vmware-hostd), which is responsible for managing most of the operations on the ESX host. To do this, log into the service console and type service mgmt-vmware restart.

NOTE: ESX 3.0.1 contained a bug that would restart all your VMs if your ESX server was configured to use auto-startups for your VMs. This bug was fixed in a patch for 3.0.1 and also in 3.0.2, but appeared again in ESX 3.5 with another patch released to fix it. It’s best to temporarily disable auto-startups before you run this command.

In some cases restarting the vmware-vpxa service when you restart the host agent will fix problems that occur between ESX and both the VI Client and VirtualCenter. This service is the management agent that handles all communication between ESX and its clients. To restart it, log into the ESX host and type service vmware-vpxa restart. It is important to note that restarting either of these services will not impact the operation of your virtual machines (with the exception of the bug noted above).

Fixing a frozen service console Another problem that can occur is your Service Console can hang and not allow you to log in locally. This can be caused by hardware lock-ups or a deadlocked condition. Your VMs may continue to operate normally when this occurs, but rebooting ESX is usually the only way to recover. Before you do that, however, try shutting down your guest VMs and/or using VMotion to migrate them to another ESX host. To do this, use the VI Client by connecting remotely via SSH or by using one of alternate/emergency consoles, which you can access by pressing Alt-F2 through Alt-F6. You can also press Alt-F12 to display VMkernel messages on the console screen.

If you are able to shutdown or move your VMs, then you can try rebooting the server by issuing the reboot command through the VI Client or alternate consoles. If not, cold-booting the server is your only option.

Lost network configurations The problem that can occur is that you may lose part or all of your networking configurations. If this happens, you must rebuild your network by using the ESX local service console, since you will be unable to connect using the VI Client. VMware has published knowledgebase articles that detailhow to rebuild your networking using the esxcfg-* service console commands and also how to verify your network settings.

Conclusion In this tip, I have addressed a few of the most common problems that can occur with VMware ESX. In the next installment of this series, I will cover troubleshooting VirtualCenter issues.

Link:

VMWare interview questions and answers – HA

What is  VMware HA?As per VMware Def

VMware® High Availability (HA) provides easy to use, cost effective high availability for applications running in virtual machines. In the event of server failure, affected virtual machines are automatically restarted on other production servers with spare capacityWhat is AAM in HA?

AAM is the Legato automated availability management.  Prior to vSphere 4.1, VMware’s HA is actually re engineered to work with VM’s with the help of  Legato’s Automated Availability Manager (AAM) software. VMware’s vCenter agent (vpxa) interfaces with the VMware HA agent which acts as an intermediary to the AAM software. From vSphere 5.0, it uses an agent called “FDM”  (Fault Domain Manager).

What are pre-requites for HA to work?

1.Shared storage for the VMs running in HA cluster
2.Essentials plus, standard, Advanced, Enterprise and Enterprise Plus Licensing
3.Create VMHA enabled Cluster
4.Management network redundancy to avoid frequent isolation response in case of temporary network issues (preferred not a requirement)

What is maximum number of primary HA hosts in vSphere 4.1?

Maximum number of primary HA host is 5. VMware HA cluster chooses the first 5 hosts that joins the cluster as primary nodes and all others hosts are automatically selected as secondary nodes.

How to see the list of Primary nodes in HA cluster?

View the log file named “aam_config_util_listnodes.log” under /var/log/vmware/aam using the below command

cat /var/log/vmware/aam/aam_config_util_listnodes.log

What is the command to restart /Start/Stop HA agent in the ESX host?

service vmware-aam restart

service vmware-aam stop

service vmware-aam start

Where to located HA related logs in case of troubleshooting?

/Var/log/vmware/aam

What the basic troubleshooting steps in case of HA agent install failed on hosts in HA cluster?

1. Check for some network issues

2. Check the DNS is configured properly

3. Check the vmware HA agent status in ESX host by using below commands

service vmware-aam status

4. Check the networks are properly configured  and named exactly as other hosts in the cluster. otherwise, you will get the below errors while installing or reconfiguring HA agent.

5. Check HA related ports are open in firewall to allow for the communication

Incoming port: TCP/UDP 8042-8045
Outgoing port: TCP/UDP 2050-2250

6. First try to restart /stop/start the vmware HA agent on the affected host using the below commands. In addition u can also try to restart vpxa and management agent in the Host.

service vmware-aam restart

service vmware-aam stop

service vmware-aam start

7. Right Click the affected host and click on “Reconfigure for VMWare HA” to re-install the HA agent that particular host.

8. Remove the affected host from the cluster. Removing ESX host from the cluster will not be allowed untill that host is put into maintenance mode.

9.Alternative solution for 3 step is, Goto cluster settings and uncheck the vmware HA in to turnoff the HA in that cluster and re-enable the vmware HA to get the agent installed.

10. For further troubleshooting , review the HA logs under /Var/log/vmware/aam directory.

What is the maximum number of hosts per HA cluster?

Maximum number of hosts in the HA cluster is 32

What is Host Isolation?

VMware HA has a mechanism to detect a host is isolated from rest of hosts in the cluster. When the ESX host loses its ability to exchange heartbeat via management network between the other hosts in the HA cluster, that ESX host will be considered as a Isolated.

How Host Isolation is detected?

In HA cluster, ESX hosts uses heartbeats to communicate among other hosts in the cluster.By default, Heartbeat will be sent every 1 second.

If a ESX host in the cluster didn’t received heartbeat for for 13 seconds from any other hosts in the cluster, The host considered it as isolated and host will ping the configured isolation address(default gateway by default). If the ping fails, VMware HA will execute the Host isolation response

What are the different types isolation response available in HA?

Power off –  All the VMs are powered off , when the HA detects that the network isolation occurs

Shut down – All VMs running on that host are shut down with the help of VMware Tools, when the HA detects that the network isolation occurs.If the shutdown via VMWare tools not happened within 5 minutes, VM’s power off operation will be executed. This behavior can be changed with the help of HA advanced options.

Leave powered on –  The VM’s state remain powered on or remain unchanged, when the HA detects that the network isolation occurs.

How to add additional isolation address for redundancy?

By default, VMWare HA use to ping default gateway as the isolation address if it stops receiving heartbeat.We can add an additional values in case if we are using redundant service  console both belongs to different subnet.Let’s say we can add the default gateway of SC1 as first value and gateway of SC2 as the additional one using the below value

1. Right Click your HA cluster

2. Goto to advanced options of HA

3. Add the line “das.isolationaddress1 = 192.168.0.1″

4. Add the line “das.isolationaddress2 = 192.168.1.1″ as the additional isolation address

What is HA Admission control?

As per “VMware Availability Guide”,

VCenter Server uses admission control to ensure that sufficient resources are available in a cluster to provide failover protection and to ensure that virtual machine resource reservations are respected.

What are the 2 types of settings available for admission control?

Enable: Do not power on VMs that violate availability constraints

Disable: Power on VMs that violate availability constraints

What are the different types of Admission control policy available with VMware HA?

There are 3 different types of Admission control policy available.

Host failures cluster  tolerates
Percentage of cluster resources reserved as fail over spare capacity
Specify a fail over host

How the Host Failures cluster tolerates admission control policy works?

Select the maximum number of host failures that you can afford for or to guarantee fail over. Prior vSphere 4.1, Minimum is 1 and the maximum is 4.

In the Host Failures cluster tolerates admission control policy , we can define the specific number of hosts  that can fail  in the cluster and also it ensures that the sufficient resources remain to fail over all the virtual machines from that failed hosts to the other hosts in cluster. VMware High Availability(HA) uses a mechanism called slots to calculate both the available and required resources in the cluster for a failing over virtual machines from a failed host  to other hosts in the cluster.

What is SLOT?

As per VMWare’s Definition,

“A slot is a logical representation of the memory and CPU resources that satisfy the requirements for any powered-on virtual machine in the cluster.”

If you have configured reservations at VM level, It influence the HA slot calculation. Highest memory reservation and highest CPU reservation of the VM in your cluster determines the slot size for the cluster.

How the HA Slots are Calculated?

How to Check the HA Slot information from vSphere Client?

Click on Cluster Summary Tab and Click on “Advanced Runtime Info” to see the the detailed HA slots information.

What is use of Host Monitoring  status in HA cluster?

Let’s take an example, you are performing network maintenance activity on your switches which connects your one of th ESX host in HA cluster.

what will happen if the switch connected to the ESX host in HA cluster is down?

It will not receive heartbeat and also ping to the isolation address also failed. so, host will think itself as isolated and HA will initiate the reboot of virtual machines on the host to other hosts in the cluster. Why do you need this unwanted situation while performing scheduled maintenance window.

To avoid the above situation when performing scheduled activity which may cause ESX host to isolate, remove the check box in ” Enable Host Monitoring” until you are done with the network maintenance activity.

How to Manually define the HA Slot size?

By default, HA slot size is determined by the Virtual machine Highest CPU and memory reservation. If no reservation is specified at the VM level, default slot size of 256 MHZ for CPU and 0 MB + memory overhead for RAM will be taken as slot size. We can control the HA slot size manually by using the following values.

There are 4 options we can configure at HA advanced options related to slot size

das.slotMemInMB – Maximum Bound  value for HA memory slot size
das.slotCpuInMHz – Maximum Bound value for HA CPU slot Size
das.vmMemoryMinMB –  Minimum Bound  value for HA memory slot size
das.vmCpuMinMHz –  Minimum Bound  value for HA CPU slot size

How the “Percentage of cluster resources reserved as failover spare capacity” admission control policy works?

In the Percentage of cluster resources reserved as failover spare capacity admission control policy, We can define the specific percentage of total cluster resources are reserved for failover.In contrast to the “Host Failures cluster tolerates admission control policy”, It will not use slots. Instead This policy calculates the in the way below

1.It calculates the Total resource requirement for all Powered-on Virtual Machines in the cluster  and also calculates the total resource available in host for virtual machines.
2.It calculates the current CPU and Memory Failover capacity for the capacity.
3.If the current CPU and Memory Failover capacity for the cluster < configured failover capacity (ex 25 %)
4.Admission control will not allow to power on the virtual machine which violates the availability constraints.

How the “Specify a failover host” admission control policy works?

In the Specify a failover host” admission control policy, We can define a specific host as a dedicated failover host. When isolation response is detected, HA attempts to restart the virtual machines on the specified failover host.In this Approach, dedicated failover hist will be sitting idle without actively involving or not participating in DRS load balancing.DRS will not migrate or power on placement of virtual machines on the defined failover host.

What is VM Monitoring status?

HA will usually monitors ESX hosts and reboot the virtual machine in the failed hosts in the other host in the cluster in case of host isolation but i need the HA to monitors for Virtual machine failures also. here the feature called VM monitoring status as part of HA settings.VM monitoring restarts the virtual machine if the vmware tools heartbeat didn’t received with the specified time using Monitoring sensitivity.

Cluster Maximums Item Maximum Cluster (all clusters including HA and DRS) 
Hosts per cluster 32
Virtual machines per cluster 3000
Virtual machines per host 512
Maximum concurrent host HA failover 31
 Failover as percentage of cluster 100%
 Powered on VMs per datastore in a HA cluster1 2048

Vmware hostd and vpxa

Vmware hostd and vpxa on ESXi 5.X

HOSTD

The vmware-hostd management service is the main communication channel between ESX/ESXi hosts and VMkernel. If vmware-hostd fails, ESX/ESXi hosts disconnects from vCenter Server/VirtualCenter and cannot be managed, even if you try to connect to the ESX/ESXi host directly. It knows about all the VMs that are registered on that host, the luns/vmfs volumes visible by the host, what the VMs are doing, etc. Most all commands or operations come down from VC through it. i.e, powering on a VM, VM vMotion, VM creation, etc.

Restart the management agent

/etc/init.d/hostd restart

VPXA 

It acts as an intermediary between VC and hostd. The vCenter Server Agent, also referred to as vpxa or the vmware-vpxa service, is what allows a vCenter Server to connect to a ESX host. Specifically, vpxa is the communication conduit to the hostd, which in turn communicates to the ESX kernel.

Restart the vpxa service

/etc/init.d/vpxa restart

Note:- If you have SSH enabled on your ESXi server these services can also be restarted and even if these are restarted by you then also your SSH session will not be impacted.

VPXD-It is Vcenter Server Service. If this service is stopped then we will not able to connect to Vcenter Server via Vsphere client.

VPXA-It is the agent of Vcenter server. also known as mini vcenter server which is installed on the each esx server which is managed by Vcenter server. What are the management action we are performing on top of the vcenter server. (Like:- Increasing/Decreasing RAM & HDD, Making any type of changes in cluster, doing vmotion. This agent collects all information from the vcenter server and pass this information to the kernal of the esx server.

HOSTD- This is the agent of ESX server, here VPXA pass the information to the HOSTD and hostd pass the information to ESX server.

In ESX, you have only hostd and (if you have vCenter) vpxa.

These are daemon (services) for remote management:

• hostd is used to remote management using VIC
• vpxa is used by vCenter (the vpxd part of vCenter) to remote manament

hostd is the daemon for direct VIC connection (when you use Virtual Infra Client (VIC) to connect to your ESX).

Also,

• vpxa is the VC agent (ESX side)
• vpxd is the VC daemon (VC side)