Lets Design, Implement and do Administration of ESX3

Virtualization with VMWare Infrastructure 3.0

Archive for the ‘iSCSI’ Category

Resource Mgmt Guide -03

Posted by Preetam on March 31, 2007

VMHA & Special Situations:

If you power off host, VMs on that host restarts on other host

When you are in the middle Vmotion & target or source fails

  • If target fails: VMs will be powered on source
  • If source fails: VMs will be powered on target
  • If both target & host fails VMs will be powered on 3rd host.

Cluster turns red if current failover capacity is less than configured capacity, however if you turn of strict admission control, cluster won’t turn red.

In case cluster turns red, HA fails over VMs with high priority first, so consider giving high priority to VMs, which are important to your organization.

By default VMs are shutdown on isolated host, this shutdown is not graceful.

When add host to the cluster, host has to communicate with primary host in the same cluster to complete configurations. When first host is unavailable or is removed, secondary host becomes primary. In case when all the hosts are unavailable, you won’t be able to add cluster to host. In this situation, you must disconnect all hosts that are not responding before you can add new host.

When a host is manually disconnected from Virtual center, it also not computed for current failover capacity. Because the status of the host is not know and Virtual center is not communicating with that host, HA cannot use it as a guaranteed failover target. Also same decision is taking by virtual center for host, which is not responding.


However Host disconnected from Virtual center and Host not responding are quite different.

NB:The VirtualCenter Server tries to reconnect to a managed host if the connection is lost. You can define how long VirtualCenter tries to re-establish the connection. This feature is not available When the VI Client is connected directly to an ESX Server. Host not responding means Virtual center no longer recieves Heart Beat. This could be because host has failed or Virtual center agent has crashed. Host failure detection occurs every 15 seconds, if there is no response within 12-14 secs window, Host declares itself isolated. However during the same interval default isolation response applies on VMs, which is shutting down VMs. However if the network is restored in the same window VMs are shutdown but not failed over. BUT If the Network is restored before 12 sec, Host is not considered as isolated.

If the isolated host has SAN access, it retains disk locks on the VM files and attempt to failover the virtual machine to another host fails. VMFS disk locking prevents simultaneous write operations to the virtual machine disk files and potential corruption. It is not true for iSCSI and NAS storage, host might lose access to its disk and loose disk locks, even if the network connection is restored later on. These VMs may be creating and consuming network I/Os there it is recommended that you keep default isolation response unchanged when your storage is on iSCSI or NAS.

If more than one host goes down, VMs on the host will restart on another based on the re-start priority set on VMs, and this priority is per-host basis, depending upon which host fails first. It applies to isolation response.

Cluster can turn yellow if DRS is overcommitted and it can turn red if DRS or HA violation occurs

Cluster is valid unless some things make cluster overcommitted or invalid.

  • Host fails, DRS becomes overcomitted i.e. turns Yellow


E.g. If you have cluster 12 GHz resources, divided among 3 hosts. All three host are having VMs consuming 10 Ghz resource divided into three resource pool RP1(3GHz),RP2(3GHz),RP3(4GHz) respectively. If one of the host goes down, capacity left is 8 GHz and also We shutdown 2 VMs, so effectively cluster will be able to run VMs because we have 8 GHz capacity and each VM is reserved to use only 8 GHz but resource pool reservation won’t be met. This makes cluster Yellow.



When you use particulary large VM e.g 8 GB, then make sure atleast there is one host which will be able to individually run VMs rather than jointly.

A DRS cluster can be invalid if Virtual Center becomes unavailable and you power on VM using a VI client connected directly to an ESX server hosts. You can resolve red DRS cluster problem either by powering off one or more VMs, moving VMs to parts of the tree that have sufficient resources, or editing resource pool setting.

HA cluster can become red when number of VMs powered on Exceeds the failover requirements, i.e. current failover capacity is smaller than configured failover capacity.

DRS behaviour is not affected if a cluster is red because of an ha issue.


In general cluster enabled for HA and DRS must meet Vmotion requirements. If the hosts are not in the VMotion network, DRS can still make initial placement recommendations. Each host in the cluster must be able to resolve host and IP address of all other hosts in the clusters. To achieve this we can setup DNS on each host or fill in etc/hosts entries. For VMHA redundancy of Networking is higly recommended. Each host should have two nics. For Vmotion requirement processor must come from same vendor (Intel, AMD) and same processor fanmily to be compatible for migration with Vmotion. In most cases processor versions within same family are similar enough to maintain compatability. In some cases, processor vendors has introduced significant architectural difference within same processor family (Such as 64-bit ext and SSE3), Vmware identifies these exception if it cannot gurantee sucessfully migration. Vmotion does not currently support raw or undoable VMDKs or migration of clustered using MSCS.

For migration of VMs you have two option

  • Drag VM directly to the cluster object
  • Right-click VM name and choose migrate

For DRS-enabled cluster, migrating directly to host is not allowed because resource pools controls the resource.


Posted in Advance Concepts, DRS, iSCSI, VMHA, VMWare | Leave a Comment »

Resource Mgmt Guide -02

Posted by Preetam on March 31, 2007

If a host is added to the cluster, you can no longer create child resource in the host
While creation resource pools, and assigning limits, reservation, shares, if any of the value is not valid, you will see yellow triangle against resource pool.

E.g.You created a resource pool of 10GB, in that you create resource pool of 6 GB and again you try to create resource pool of another 6 GB and type is fixed, you will get yellow triangle

When you move VMs into new resource pool, VMs existing limits & reservations don’t not change. If shares value is customized, it is not changed as well, but it is set to normal.high, low % share value changes. Also unreserved resource values changes to reflect newly added reservations. That being said, if VMs reservations are not met by resource pool, move will fail

When you move hosts into cluster, depending upon what you choose like

  • DRS enabled
  • DRS disabled

Existing resource pools are affected accordingly, when you enable DRS on cluster, you have option of moving the entire tree of resource pool into new cluster or you have option to put this host’s VMs into the cluster’s root resources, when you enable second option, tree structure is changed to flat structure and all VMs & Resource pool becomes child of cluster root, instead of host, However when you happen to move out Host from the cluster, resource pool heirarchy is not moved, in short it becomes completely independent of host.

If DRS is disabled all resource pools are deleted and VMs become direct child of the cluster.

Also in Non-DRS cluster, there is no cluster-wide resource management based on the shares. Shares remain relative to host.

You can create cluster without special license, but you must have a license to enable a cluster for DRS or HA.

What happens to DRS & HA when Virtual center goes down?

HA – Continues to work and can still restart VMs on other hosts in case of failover; however information specific to VMs like cluster properties (priority or isolation response) is based on the state of the cluster before the virtual center goes down

DRS – No recommendations are made for resource optimization.

By default automation level (HA) is enabled at cluster level but you can customize it at VM level as well. Migration recommendation made by VMHA is based on the priority and associated reasons.

When in maintenance mode, the host does not allow you to deploy VMs, VMs that are running on maintenance mode continues to run, you either migrate them to another host or shutdown. When no VMs are running on the host, host’s icon changes to include under maintenance mode. If DRS cluster is in automation mode, all VMs are migrated to different host, when host moved to maintenance mode. This makes sense when other host fails and tries to failover VMs on this host which is in maintenance, being in maintenance mode it won’t allow any VMs. Also if host goes into maintenance mode VMHA will compute current failover capacity excluding host which are in maintenance mode. When host exist maintenance mode, failover capacity is again computed by VMHA.

When you allow VM to be started even if they violate availability constraints deselected (i.e. disable) you will also not able to

  • Reverting VMs to last snapshot
  • Change CPU/Memory reservations
  • Migration VM into the cluster

Posted in Advance Concepts, DRS, iSCSI, Limits, Reservations, Resource Pools, Resources, VMHA, VMWare | Leave a Comment »