Top 15 Vmware Drs Interview Questions You Must Prepare 19.Mar.2024

VM automation level can override cluster automation level. From a VM prospective there are 5 automation levels.

These are:

  1. Fully Automated: Load balance and Initial placement will be done by DRS automatically
  2. Partially Automated: Load balance of the VM will be done manually but initial placement will be done automatically
  3. Manual: VM migration as part of Load balancing and initial placement will be both manual. DRS will only generate recommendation for that VM and administrator has to manually approve this recommendation.
  4. Default: VM will inherit the DRS automation level as defined at the cluster level.
  5. Disabled: DRS will not perform any actions on that VM.

If a mandatory rule is configured on a cluster then it can put following limitations:

  1. Limit DRS to select hosts for load balancing
  2. Limit HA to select host for failover
  3. Limit DPM to select host to power off

It can affect ability of DRS to defragment the cluster resources. At the time of failover HA can seeks assistance for DRS and can ask to defragment resources if a single host is not able to provide adequate resources for failover.

If a migration will cause violation of must rule then that migration will be cancelled by DRS.

IF DPM is trying to put a host in sleep mode for power saving but migration of VM’s running on this host can cause a must rule violation, it will prevent DPM to put that host in sleep mode.

If HA is trying to restart VM’s after a host failure but if restart of some VM’s on a particular host can cause must rule violation then HA will either restart those VM’s on some different host or could not restart them at all if no suitable host is available for failover.

Following are the factors which affect the DRS recommendations:

1- VM size and Initial Placement: When a new VM is created or a VM is powered on, DRS selects a host where this VM should be initially placed. DRS prefers the registered host as long as placement of that VM on this host will not cause cluster imbalance.

During placement of such VM’s DRS uses a worst case scenario because it doesn’t have historical data for that VM. DRS assumes both CPU and memory demand of this VM is equal to its configured size.

Oversized VM’s can temporarily cause cluster imbalance and can cause unnecessary migrations of active VM’s.

2- PollPeriodSec (Length of DRS Invocation): The default value of PollPeriodSec is 300 seconds. Range of PollPeriodSec is 60 sec to 3600 sec. shortening this period will cause increase in vCenter overhead as cluster imbalance will be calculated frequently.

Increasing this value decreases the frequency of cluster balance calculation and can leave your cluster imbalanced for longer period of times but allows for larger number of vMotions due to long invocation interval.

3- Simultaneous vMotion: vSphere 5.1 allows 8 concurrent vMotions on a single host with 10GbE capabilities. For 1GbE, 4 concurrent vMotion can takes place. Also multi-NIC vMotion is supported in vSphere 5.1 so multiple active NICs and their combined bandwidth can be used for migration of a VM. In such environment VM’s will be migrated quickly and cluster can be balanced in less time.

4- Estimated Total Migration Time: The migration time depends on variables like source and destination host load, active memory usage of VM, link speed and available bandwidth+ latency of the physical network used by vMotion Portgroup.

No DRS will not work if vCenter Server is down.

DRS depends upon vCenter server for information like current power state of virtual machines, change in power state of any VM, number of datastores to which Esxi hosts are connected and the memory and cpu configurations of a VM.

DRS will use all these information while calculating the load on the cluster and proposing migration recommendations when a cluster needs to be balanced.

VM-VM affinity: This is useful when you require that 2 of your VM’s should always run together on an Esxi host. For E.g. Keeping front-end and back-end server of an application on same ESXi host to reduce network latency between the 2 VM’s.

Another use case will be running together same types of VM’s which are having same type of applications so as to get max benefits of transparent page sharing (TPS)

VM-VM anti-affinity: This is useful when you don’t want that 2 of your VM should run together. Keeping servers providing same kind of services on different host will provide resiliency

For Example: You will not want your DC and ADC run together on same Esxi host because if that Esxi host goes down it can severely impact your environment as both DC and ADC server has gone down together.

Another use case will be running web-server farms or clustered DB-servers in a virtualized environment.

Also, keeping away 2 VM’s from each other which are very resource intensive to stop them from monopolizing resource usage.

Before disabling DRS it is recommended to delete all affinity and anti-affinity rules and then proceed. Because if rules are not deleted and DRS is disabled, rules will be still in affect and can affect cluster operations.

DRS uses a cost benefit risk approach to load balance a cluster. Before presenting the migration recommendations for a VM to load balance a cluster,

DRS calculates 3 things:

Cost: What will be the cost of migrating a VM from source to destination host? Cost here refers to the CPU and memory.

When a vMotion process in invoked on a VM, it reserves 30% of the cpu core (For 1 GB NIC) of that VM and 100% cpu core (For 10 GB NIC). This reservation is created on both source and destination host. This reserves resources can’t be allocated to any other VM while vMotion is in progress. This can put some pressure on an Esxi host when it is heavily loaded.

Benefits: What will be the resource benefit that an Esxi host will get after migrating a virtual machine to other Esxi ho st. If after the migration CHLSD value of the Esxi host comes down then DRS will consider that migration as benefit.

Risk: Risk accounts for possibility of irregular loads. Suppose a VM has inconsistent and spiky demands of resources, then migrating such VM’s is not a good move because may be at the time of migration VM resource demand was low but after completion of migration, VM’s resource demands suddenly increased. In this case it can cause the increase in destination Esxi hosts CHLSD and again DRS has to perform migration of that VM to bring down CHLSD of the Esxi host where that VM was migrated.

DRS recommends migrations if Benefit obtained due to a migration < cost associated with that migration.

VM-Host affinity: This is useful when you want that your VM should run on a particular Esxi host only.

For Example: running and oracle DB server which has socket based license. If your environment is having heterogeneous hosts than migrating such VM to a host which has different CPU configuration can violates your license and can cause trouble.

VM-Host anti affinity: This is useful when you want that a particular VM should not run on some particular Esxi hosts.

For Example: your environment has heterogeneous hosts and all the hosts don’t have Numa architecture and you want to get benefits of the vNuma inside your VM. In this case you would want your VM to run only on those servers which supports Numa.

If a new rule is conflicting with an old rule then new rule will be disabled automatically. DRS will prefer respecting the old rule.

The default invocation period is 300 seconds (5 minutes). But this can be changed via the configuration file vpxd.cfg.

We have to change the value of <pollperiodsec> as shown below:

<config>

<drm>

<pollperiodsec>

300

</pollperiodsec>

</drm>

</config>

Just change the value 300 to a custom value defined by you. The range of supported value is 60 secs to 3600 secs.

VPXA is the vCenter agent that runs inside Esxi hosts and it enables a 2 way communication between Esxi hosts and vCenter Server.

VPXA is responsible for:

  1. Keeping the status of Esxi and VM’s in sync
  2. It sends info to vCenter server when a VM’s power state is changed or a VM is vMotioned from one host to other.
  3. DRS uses this information which is presented by Esxi hosts to vCenter server for calculating the load balance and proposed migrations in case of cluster imbalance.

 To calculate the cluster imbalance, DRS compares the Current Hosts Load Standard Deviation (CHLSD) to Target Hosts Load Standard Deviation (THLSD) and if

CHLSD < THLSD

Cluster is considered as imbalanced.

CHLSD Calculation:

DRS computes Normalized Entitlement (NE) of each Esxi hosts and the standard deviation associated with it. NE is nothing but calculation of how much resources are currently utilized out of total resources. NE is calculated by summing up dynamic entitlements (usage) of all VM’s that are running on an Esxi host and diving this by Esxi host capacity.

So, NE= Dynamic Usage of all VM’s / Total host capacity

THLSD Calculation:

THLSD is derived from DRS migration threshold which is defined at the time of configuring DRS. Each threshold level sets different imbalance tolerance margin. The aggressive threshold sets a tight margin allowing for little imbalance, while conservative thresholds tolerates bigger imbalances.