Wednesday, 12 September 2018

vSphere Networking



vSphere Networking Basics-Part1



In this two part series, I discuss some of vSphere’s networking aspects, something you probably have come across when using VMware software. In this first part, I’ll talk mainly about the vSphere Standard Switch (vSS) in context of setting one up and configuring it on a standalone ESXi host (not managed by vCenter Server). I’ll also go over VMkernel adapters, port groups and some of the standard switch settings.
In the second part, I’ll introduce another type of virtual switch called the vSphere Distributed Switch which is only available one vCenter Server has been installed.

The vSphere Standard Switch


A vSphere Virtual Switch, allows a number of virtual machines connected to it to communicate with one another, pretty much like their physical counterparts would when connected to a physical switch. In addition, the vSS bridges virtual networks to physical ones using the ESXi host’s network cards,  on which the vSS has been created, as uplink ports to a physical switch.
By default, a standard switch is automatically created when you install ESXi. This is labelled vSwitch0 as per Figure 1.
Note: An uplink port is simply a designated port on a networking device such a switch or a router that connects or cascades one piece of networking equipment to another. Figure 1 shows how the two physical adapters – labelled 3 – on the ESXi host set up for this post have been designated as uplink ports.





Figure 1 – vSwitch0 is automatically created when ESXi is installed.

Looking closely at Figure 1, you should also notice the headings Virtual Machine Port Group and VMkernel Port denoted by 1 and 2 respectively. I’ll explain what these mean in the upcoming sections.

Port Groups


A port group, as the name implies, is a grouping of switch ports. By applying a network policy to a port group, one can enforce security and traffic shaping rules. Additionally, if you have VLANs set up on your physical switches, you can assign a VLAN ID to a port group such that any vm on it will, for all intents and purposes, reside on that specific VLAN.
When you create a network enabled virtual machine, you are in fact connecting its virtual adapters to one or more port groups. Figure 2 illustrates this aspect. The vm properties, including the selected port group, are shown on the left-side of Figure 2 while the switch settings – where port groups are defined – are shown on the right. In this instance, I created two vSphere standard switches each having a distinct port group. Notice how each switch has its own dedicated uplink (vmnic0 and vmnic1).
TIP: If there’s a need to isolate one or more virtual machines from the rest of the  network, whether physical or virtual, you can simply create a standard switch with no specified physical adapters (uplinks). Any virtual machine placed on the switch’s associated port group will still be able to talk to any other vm on the same port group but will be completely cut off from other networks. Such a setup comes in handy whenever you need to replicate, say, a live environment in keeping with the same layer 3 addressing (IPv4/6) but without impacting any of the production systems.





Figure 2 – Assigning a vm to a port group (Left) and port groups created on a standard switch (right).


The VMkernel


The VMkernel network interface, adapter or port is basically a service provider used by the ESXi host to communicate with the outside world and the rest of the VMware based infrastructure. VMkernel adapters are created according to the type of services required be it vMotion, Fault Tolerance, Management or perhaps vSAN. A list of services necessitating of a VMkernel are depicted under Services in Figures 3 and 4.  A VMkernel is assigned an IP address using either DHCP or one which is assigned manually, the latter option being, in my opinion, the most sensible one.
By default, vmk0 is the first VMkernel adapter created which is enabled for management traffic. Interestingly enough, you’ll still be able to connect to ESXi if Management is ticked off.





Figure 3 – Using the VMware Host Client on ESXi 6U2 to manage a VMkernel.







Figure 4 – Using the C# vSphere client to manage a VMkernel.


After creating a VMkernel you’ll come across something that looks like a port group but not quite. This is in fact a port. Depending on the tool used to create it, things can get somewhat confusing. For instance, when using the C# vSphere client, you’d be forgiven for thinking that the VMkernel is in fact a port group since the same icon is used for both (Figure 5).





Figure 5 – VMkernel properties as viewed from the C# vSphere client


vSphere Networking Maximums


Before I move on, I’m going to list a few vSphere 6.0 maximums related to standard switches. You will find the full list here.
  • 512- Port groups per standard switch.
  • 1016 – Maximum active ports per host.
  • 4096 – Total virtual network switch ports per host.
  • 4088 – Virtual network switch creation ports per standard switch .

Creating a virtual standard switch


There are a number of ways to create a standard switch. These include PowerCLI, ESXCLI, the standard and Web vSphere clients and the recently introduced VMware Host Client assuming you’ve made the transition to ESXi 6.0 update 2. Here’s a quick rundown.

ESXCLI

Use something like putty to SSH to the ESXi host and run the following command to create a 24 port switch called myVSS.

PowerCLI

Connect to the ESXi host using the Connect-VIServer cmdlet and then issue the following to create the same switch as per the ESXCLI command.
Note: Starting with ESX 5.5, switches are created elastic meaning there is no need to specify the number of ports since these are added dynamically as required. I’ve included the parameter just for completeness sake. In fact in the case of PowerCLI the ports parameter is completely ignored.

Thick vSphere Client

When using the vSphere clients, simply highlight the ESXi host on which you want to create the switch, change over to the Configuration tab and click on Add Networking as shown in Figure 6-9.  Next, choose Virtual Machine (if this is not misleading, I don’t know what is) binding it to a physical nic as well as creating a new port group for it.





Figure 6 – Adding a new vSwitch using the vSphere client







Figure 7 – Choosing Virtual Machine to create a virtual switch







Figure 8 – Binding the virtual switch to a physical nic on the ESXi host (uplink)







Figure 9 – Assigning a port group label and VLAN ID


VMware Host Client

If you have ESX 6.0 U2 (or have installed the fling) you can also use the VMware host Client to create a standard switch. Once you log in, select Networking from Navigator and switch to the Virtual Switches tab. Click on Add standard virtual switch and fill in the details. It’s as simple as that.





Figure 10 – Using the VMware Host Client to create a standard switch







Figure 11 – Finalizing a standard switch using the VMware Host Client


Configuring a standard switch


For this section I’ll be using the C# vSphere client and an ESXi 6.0 U2 setup. Just as a reminder, vSwitch0 is created automatically as part of the ESXi installation process.
To view the switch’s configuration, highlight the host’s IP address or hostname, select the Configuration tab and select Networking under Hardware. Click on Properties as shown in Figure 6.





Figure 12 – Viewing the configuration of a stand switch


On the next screen you’ll find 2 tabs, one called Ports (probably for lack of a better name) and another called Network Adapters. I’ll start with the latter since I’ll refer to it later on. This is basically where you will bind the physical ESXi host’s network cards to the virtual switch. Binding two or more nics will provide for link aggregation and failover options.





Figure 13 – An ESX’s network cards used as uplinks by the virtual switch


Under the Ports tab – as far as vSwitch0 is concerned – you’ll find three items created automatically when ESXi was first installed. These are the vSwitch configuration, a default port group and a VMkernel. You’ll be able to add other port groups and VMkernels using the Add button at the bottom of the vSwitch properties window.





Figure 14 – Viewing the vSwitch properties such as the number of ports and MTU size


Once again, things can get a little bit confusing depending on the client or method used to create and manage networking. As shown in Figure 15, you’ll need to select Virtual Machine as the connection type if you want to create a new port group.





Figure 15 – Creating a new port group


To view the virtual switch settings, just click on the Edit button. Here you’ll find 4 tabs related to the switch’s network policy comprising various options and settings that govern both the switch and how it handles traffic. Again, depending on the tool used, some options may or may not be available. For instance, NIC Teaming is unavailable when using the VMware Host Client (at least, I wasn’t able to find it listed anywhere).





Figure 16 – Viewing the vSwitch settings using the VMware Host Client – No NIC Teaming option


Standard Switch Settings and Policies


The switch’s configuration is accessed by clicking on the Edit button while the vSwitch configuration item is highlighted. This brings up a window with the previously mentioned tabs. Keep in mind that the settings and options set at the vSwitch level will percolate down to every other item in the configuration list. That said, an override option is available for each and every item.





Figure 17 – Settings set at the vSwitch level propagate downwards


Let’s go over the settings / option found under each tab.

General

Here you’ll set the number of switch ports required (max. 4088) and the MTU (Maximum Transmission Unit) size. The latter is generally changed if jumbo frames are enabled on your networks.





Figure 18 – General settings for a vSwitch


Security

Under the Security tab, you’ll find 3 settings defining the security policy for the switch.





Figure 19 – Security settings for a vSwitch

The settings available are as follows;
  • Promiscuous Mode – If set to accept, any vm on the switch having a virtual adapter in promiscuous mode will be able to eavesdrop on all the traffic passing through the switch.
  • MAC Address Changes – Determines what happens when the MAC address of a network adapter on a vm is changed. If set to Reject, all traffic emanating from the vm is dropped when the MAC address supplied does not match that found in the vm’s vmx configuration file.
  • Forged Transmits – If set to reject, frames with spoofed source MAC addresses will be dropped.

Traffic Shaping

The traffic shaping policy, if enabled, regulates bandwidth and burst size on the switch. This may come in handy when a number of port groups are created on the switch and you wish to apply a traffic utilization baseline across all port groups. Yet again, such a policy can be overridden if required for each and every port group.





Figure 20 – Traffic shaping settings for a vSwitch


NIC Teaming, Failover and Load Balancing

If you have 2 or more physical ESXi nics bound to a virtual switch, you will be able to increase bandwidth availability using either Ether Channel or Link Aggregation Control Protocol (LACP). This may require familiarity with some advanced networking concepts (depending on your background) which I’m not going to discuss here. However, this is a great article which goes into great depth on how to configure ESXi to leverage LACP and EtherChannel as implemented on Cisco and HP switches.
Under the NIC Teaming tab you’ll find a number of failover options. In the example below, I have two physical nics set up as Active Adapters. This ensures that the uplink is maintained if any one adapter goes offline. I could also move one adapter to the Standby Adapters group. When you do this, the standby adapter will only become active when all the nics within the Active Adapters group fail.
For a complete listing of the available NIC Teaming, Failover and Load Balancing options please visit here.





Figure 21 – Teaming and Failover vSwitch settings


Configuring a port group


Most of the settings just covered equally apply when configuring a port group, the main difference being those found under the General tab.





Figure 22 – Setting the port group name and VLAN ID


The Network Label setting is self-explanatory. This is the name you assign to the port group and is what you see listed when you connect a vm’s virtual adapter to a network. The VLAN ID setting is on the other hand slightly more interesting albeit optional. If you have VLANs set up on your physical switches, ESXi operates in 3 different ways to take VLANs into account, these being;
  • External Switch Tagging (EST) – This is required when VLAN tagging of packets is performed on the physical switch. The ESXi host’s network adapters are in this case connected to access ports on the physical switch. The VLAN ID must be set to 0.
  • Virtual Switch Tagging (VST) – Contrary to EST, all VLAN tagging is carried out by the virtual switch before leaving the host. Host network adapters must be connected to trunk ports on the physical switch. Port groups connected to the virtual switch are assigned a VLAN ID between 1 and 4094.
  • Virtual Guest Tagging (VGT) – With VGT, all VLAN tagging is done by the virtual machine. VLAN tags are preserved between the virtual machine networking stack and external switch when frames pass to and from virtual switches. Host network adapters must be connected to trunk ports on the physical switch. For a standard switch the VLAN ID of port groups with VGT must be set to 4095.

Configuring a VMkernel


There are 2 main aspects to configuring a VMkernel, its IP address and the services it provides. Under the General tab you can specify a name for the VMkernel, the services provided as well as an MTU value if you’re using anything other than the default value of 1500. Under the IP Settings tab you’ll find settings for the IP address and network mask. The remaining tabs are again identical to the ones previously covered with all the settings being inherited but which can nevertheless be overridden.





Figure 23 – Setting up a VMkernel







Figure 24 – Assigning an IP address and subnet mask to a VMkernel


Conclusion


This concludes the first part of the series. I think I covered the salient aspects of vSphere standard switches and even though there’s probably more that can be said, I need to draw a line somewhere lest this ends up being one ginormous post. Further details are to be found under the Networking section on the vSphere 6.0 documentation site.





vNIC

This Virtual Network Adapter is used by Virtual Machines to communicate with other network devices in Virtual or Physical environment.
VMKNIC
Its a specialized Vmware Paravirtualized adapter used by Vmkernel TCP/IP stack. This Specialized adapter has its own MAC address and used to connect the Vmkernel to services that it provides.
Vmkernel NIC provides mainly 5 services :
    1. Management Connectivity
    2. IP Storage
    3. NFS connectivity
    4. vMotion
    5. Fault Tolerance

VSWIF

Its again a specialized Paravirtualized adapter similar to vmxnet that was used only by the ESX service console in ESX Product. Since Service Console has been removed in ESXi so vswif doesn’t exist anymore.

VPORT

vPorts on a virtual switch provide logical connection points among virtual devices and between virtual and physical devices. You can think of them as virtual RJ-45 connectors.
Each virtual switch can have upto 1016 active ports with a max limit of 4096 ports per switch.

PORTGROUPS

Portgroups are templates used to configure persistent network policies for virtual ethernet adapters. Group of Virtual Machine share common network configuration can be mapped same Portgroup.

UPLINKS

Physical Ethernet Adapter referred as Uplink in Virtual Networking. Uplink serve as bridges between Virtual and Physical Network. Virtual Ports of vSwitch connected to Uplinks are called Uplink Ports.
A Single ESX host can have maximum of 32 uplinks.

vSPHERE STANDARD SWITCH

vSphere Standard vSwitch is layer2 software switch that resides in Vmkernel and provides traffic management for Vms and Vmkernel traffic. Control plane and IO Plane sits in ESXi Host only so user needs to manage standard vSwitches individually. In Short, there is no centralized management for vSphere Standard Switches.

VSPHERE DISTRIBUTED SWITCH

Vsphere Distributed Switch is centralized Layer2 switch provides traffic management for Vms and Vmkernel traffic. Distributed switches are centralized switch spans across multiple ESXi hosts. This Distributed switch can only be managed by vCenter Server.

ESXi Log File Locations

ESXi Log File Locations





ESXi records host activity in log files, using a syslog facility.

Component
Location
Purpose
VMkernel
/var/log/vmkernel.log
Records activities related to virtual machines and ESXi.
VMkernel warnings
/var/log/vmkwarning.log
Records activities related to virtual machines.
VMkernel summary
/var/log/vmksummary.log
Used to determine uptime and availability statistics for ESXi (comma separated).
ESXi host agent log
/var/log/hostd.log
Contains information about the agent that manages and configures the ESXi host and its virtual machines.
vCenter agent log
/var/log/vpxa.log
Contains information about the agent that communicates with vCenter Server (if the host is managed by vCenter Server).
Shell log
/var/log/vpxa.log
Contains a record of all commands typed into the ESXi Shell as well as shell events (for example, when the shell was enabled).
Authentication
/var/log/auth.log
Contains all events related to authentication for the local system.
System messages
/var/log/syslog.log
Contains all general log messages and can be used for troubleshooting. This information was formerly located in the messages log file.
Virtual machines
The same directory as the affected virtual machine's configuration files, named vmware.log and vmware*.log. For example, /vmfs/volumes/datastore/virtual machine/vwmare.log
Contains virtual machine power events, system failure information, tools status and activity, time sync, virtual hardware changes, vMotion migrations, machine clones, and so on.

Tuesday, 11 September 2018

How to backup vcenter appliance 6.5 embedded postgres database

How to Backup vCenter Appliance 6.5 Embedded Postgres Database



In vCenter Server appliance 6.5 Management Interface (VAMI) page, We have option to backup the vCenter server appliance but it backups entire vCenter data including database but how to backup only the vCenter embedded postgres database to protects the data stored in your database. The backup of the vPostgres database is not required when performing a backup using a supported method. Image-based backup and restore is the only solution supported for performing a full, secondary appliance restore. VMware provides a Python based scripts which allows to backup  the embedded postgres database of vCenter Server appliance 6.5. In this article, I am going to explain the detailed step by step procedure to Backup vCenter Appliance 6.5 Embedded Postgres Database using the python script. I am going to taking reference of the VMware KB article 2091961.This article is only supported for backup and restore of the vPostgres database to the same vCenter Server or vCenter Server Appliance. Use of image-based backup and restore is the only solution supported for performing a full, secondary appliance restore. 

NOTE: This is tested only in Lab environment. Always consult with VMware GSS incase you need to recover your Embedded Potsgres database. VMware GSS should be consulted prior to attempting as it could result in an unusable vCenter Server Appliance.

Backup vCenter Appliance 6.5 Embedded Postgres Database

Download the python script “2091961_linux_backup_restore.zip” from VMware KB article 2091961. and copy the Zip file to the vCSA appliance using WinsCP connection to VCSA



Unzip the donwloaded python script ZIP file using the below command

unzip  2091961_linux_backup_restore.zip




Make a backup_lin.py executable using the below command

chmod 700 backup_lin.py


Run the backup_lin.py file and provide the location for the backup file. In my case, I have provided the location for the backup file in /root/backups and file name for backup file as “vcsa_postgres_VCDB_10042017.bak”. Execute the below command to run the python script.

python /root/backups/backup_lin.py -f /root/backup/vcsa_postgres_VCDB_10042017.bak
Validate that the backup file is created in the specified location using “ls -l” command



Basic command for interact vcsa 6.5 with external vpostgres database server

6 Basic Commands to Interact with VCSA 6.5 Embedded VPostgres Database



 vSphere 6.5 makes the vCenter Server Appliance the fundamental building block of a vSphere environment. The core vSphere architecture is built around this easy to deploy and manage approach that reduces operational complexity by embedding key functionality into a single location. Since  most the new features such as vCenter 6.5 Native HA ,etc are only available with vCenter Server appliance. It is important to learn to manage and troubleshoot the VCSA 6.5 and VCSA 6.5 Embedded VPostgres Database. In this article, I am going to explain the basic commands to interact with VCSA 6.5 Embedded VPostgres Database in the simplified way.

5 Basic commands to interact with VCSA 6.5 Embedded VPostgres Database

1.Read VCSA 6.5 Embedded Database Configuration Information

Connect to the SSH of VCSA 6.5 and Execute the below command to read the VCSA 6.5 embedded database configuration information.

less embedded_db.cfg


It displays the embedded database configuration information such as DB Type, DB Server name. DB port, DB instance name , DB user name and also PG User Password in Quotes. This information are needed when you need to manage and troubleshoot the VCSA 6.5 Embedded VPostgres Database from outside the server.



2. Connect to the VCDB from the vCenter Server Appliance 6.5 BASH Shell

Execute the below command to connect to VCSA 6.5 Embedded VPostgres Database (VCDB) from the SSH of VCSA appliance

/opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres
It also displays the PSQL version and build information details. Once you have connected to the Postgres database. You will get the propmt of “VCDB=#”



3. List all databases instance information

Execute the below command in “VCDB=#” prompt  to list all the database instances running on the VCSA 6.5 Embedded VPostgres Database.

\l+
It displays the instance name along with owner information, access privileges ,size and tablespace,etc.





4. List all the tables of VCDB embedded database

Execute the below command in  “VCDB=#” prompt  to list all the database tables running on the VCSA 6.5 Embedded VPostgres Database along with its size information.

\d+


5. List all the functions of VCDB embedded database

Execute the below command in  “VCDB=#” prompt to list all the functions running on the VCSA 6.5 Embedded VPostgres Database.

\df


You can also run the Run SQL Statements using Standard SQL syntax.

SELECT * FROM VPX_VERSION; SELECT * FROM VPX_HOST;


6. Exit from PSQL command prompt

Execute the below command to quit psql command prompt and return to VCSA 6.5 bash shell

\q




What is new in vsphere 6.5

Vsphere 6.5
vSphere 6.5 -What’s New with vCenter 6.5?

vSphere 6.5 released with lot of new features that most of them were waiting for. vSphere 6.5, the latest version of its industry-leading virtualization platform.  This new release of vSphere features a dramatically simplified experience, comprehensive built-in security, and a universal app platform for running any app. vSphere 6.5 makes the vCenter Server Appliance the fundamental building block of a vSphere environment. The core vSphere architecture is built around this easy to deploy and manage approach that reduces operational complexity by embedding key functionality into a single location. This article we will talk about what’s New with vCenter 6.5 in detail. vCenter 6.5 now have exclusive new feature sets added with the release of vSphere 6.5:

VMware Update Manager (VUM) is now part of the vCenter Server Appliance

vCenter Server Native High Availability

Built-in vCenter Backup  & Restore

Migration from Windows vCenter to vCenter Server appliance

Improved vCenter Server Appliance Management

What’s New with vCenter 6.5 ?

VMware Update Manager (VUM) is now part of the vCenter Server Appliance

This was one of the biggest expectation from most of the customers. With early ve rsion of vSphere, we need to depend on the seperate windows server to install and manage VMware Update Manager (VUM) eventhough you uses vCenter appliance. It was one of last dependency on the Windows platform to use windows server for vCenter. With vSphere 6.5, VMware update manager is part of vCenter Server appliance. Wonder feature is it also supports the migration of existsing VUM baselines and updates to the vCenter server appliance 6.5.During the migration process the vCenter configuration, inventory, and alarm data is migrated by default.

vCenter Server native High Availability (vCenter Server Appliance only)

Most of the customers are looking to ensure the high availability of vCenter server using various ways such as enabling HA, FT, vCenter heartbeat and even with the help of Microsoft Clustering (MSCS). With the release of vSphere 6.5, It supports native high availability of vCenter server. This will be only available for vCenter server appliance and not for windows based vCenter Server. This clearly stats that high push for vCenter server appliance from the VMware.

This Native high availability solution consists of Active-passive deployment along with wintness nodes,which are clone from the existing vCenter server.

Failover will happen within the vCenter HA cluster will occur in case of host and hardware failure and also during when particular key services failure. RTO of 5 minutes is expected with the initial release of vCenter HA. We will talk more about vCenter HA once vSphere 6.5 is publicly available to download



Built-in vCenter Backup & Restore

With vCenter 6.5, You will be able to backup and restore your vCenter server appliance with the help of built-in backup and restore option.

Enables the users to backup the vCenter server and Platform services controller (PSC) appliances directly from the VAMI or API. It also backup both VMware Update Manager and Auto Deploy running embedded with the vCenter appliance.

This backup fully supports vCenter Server Appliances with embedded and external Platform Services Controllers.

This built-in vCenter backup and restore allows you to backup vCenter and PSC using the industry-standard protocols such as SCP, HTTP(s) or FTP(S). You will be able to restore the vCenter server using the vCenter Server appliance installer ISO.

Migration from Windows vCenter to vCenter Server appliance

With the release of vSphere 6.0 update 2m, migration of windows based vCenter server 5.5 and 6.0 to vCSA is supported If you are running with windows based vCenter Server 6.0, You will be able to migrate to vCenter Server appliance using this migration tool. With vSphere 6.5, There are below improvements made on the migration tool which allows you to select the granular migration data:

Configuration

Configuration, events, and tasks

Configuration, events, tasks, and performance metrics

Improved vCenter Server Appliance Management

With vCenter server Appliance 6.5, There are lot of improved appliance management capabilities are added.

vCenter Server appliance management now exposes additional health and configurations.

User Interface now shows Network and Database statistics, disk space usage and health in addition to CPU and memory statistics.

This removes the dependency on command line for advanced statistics and troubleshooting.



Vmware DRS 6.5

VMware DRS
vSphere 6.5 -What’s New with vSphere 6.5 HA & DRS

 This new release of vSphere features a dramatically simplified experience, comprehensive built-in security, and a universal app platform for running any app. As usual with the release of each vSphere version,It continues to provide the best availability and resource management features for business critical application workloads. vSphere 6.5 also added new and improved features. We will talk about new features available with vSphere 6.5 HA & DRS.

Proactive HA

vSphere HA Orchestrated Restart

Simplified vSphere HA Admission Control

Network Aware DRS

DRS Advanced options

What’s new with vSphere 6.5 HA?

Proactive HA

Vmware DRS 6.5

HA now also detect the hardware conditions of the ESXi host and allow you to evacuate the Virtual machines before the hardware issues cause an outage to VM’s with the help of Proactive HA. This work in conjunction with hardware vendors monitoring solutions to receive the health status of the hardware components such as memory, fans and power supplies. You can configure vSphere to respond according to the failure of hardware components.

If any hardware components is failed and it is marked as unhealthy by hardware monitoring, vSphere will classify the affected ESXi host as either moderately degraded or severely degraded based on the component failure. vSphere will place that affected ESXi host into new state called “Quarantine Mode”.

In the Quarantine Mode, DRS will not use the ESXi host for new Virtual machine placements and also DRS will attempt to evacuate the host as long as it would not cause performance issue. You can also configure proactive HA to place the degraded ESXi hosts into Maintenance mode which perform the vMotion of Virtual machine to other healthy ESXi hosts in the cluster.

vSphere HA Orchestrated Restart

With the help of vSphere 6.5 HA orchestrated Restart option, We can define the virtual machine to Virtual Machine dependency chains. These dependency rules are enforced when vsphere HA restart VM’s from the failed ESXi hosts. This option is really useful to recover the multi-tier applications that it needs to be brought up in particular order. for example, DB VM needs to brought first and followed by app VM and the by Web VM.

Simplified vSphere HA Admission Control

Lot of new improvements to vSphere 6.5 HA Admission control has been made for simplified administration. Admission control is used to set aside a calculated amount of resources that are used in the event of a host failure.

Cluster Resource Percentage : Simply define the Number of ESXi hosts tolerate for failures. vSphere HA will automatically calculate a percentage of resources to set aside by applying the “Percentage of Cluster Resources” admission control policy. It is automatically recalculated, if you have added or removed ESXi hosts in the cluster.


Possible Override : You can override the default CPU and memory settings if needed. This option also automatically recalculated if you add or removed ESXi host from the cluster based on its override Percentage.

Performance Degradation VMs Tolerate : vSphere Web Client will issue a warning if vSphere HA detects a host failure would cause a reduction in VM performance based on the actual resource consumption, not only based on the configured reservations. The administrator is able to configure how much of a performance loss is tolerated before a warning is issued.

What’s new with vSphere 6.5 DRS

Network Aware DRS

DRS will now consider the network bandwidth on the ESXi hosts before placing new Virtual machines on the ESXi host and also during VM migrations to the ESXi host. DRS will check Tx and Rx rates of the connected physical uplinks and avoids placing VMs on hosts that are greater than 80% utilized. It uses the network utilization information as the additional check to determine the destination ESXi is suitable for VM placement and migration. This option improves the DRS placement decisions.

DRS Advanced options

Some of the common advanced DRS settings are now configured from the UI for simpler administration.

VM Distribution: Enforce an even distribution of VMs. This will cause DRS to spread the count of the VMs evenly across the hosts.

CPU over-commitment: This is an option to enforce a maximum vCPU:pCPU ratios in the cluster. Once the cluster reaches this defined value, no additional VMs will be allowed to power on.


Memory Metric for Load Balancing: DRS uses Active memory + 25% as its primary metric when calculating memory load on a host. The Consumed memory vs active memory will cause DRS to use the consumed memory metric rather than Active. This is beneficial when memory is not over-allocated. As a side effect, the UI show the hosts be more balanced.