What is VAAI?

Posted on by Craig

This is more of a post for myself going over VAAI before I take my VCP 5 exam soon, so I wanted to get some pixels on the screen about VAAI.

VAAI stands for vSphere Storage API’s for Array Integration.  It has been around since vSphere 4.1 and is used to ‘pass’ storage related functions to the array rather than being performed by ESXi.

Some of the benefits from using VAAI are:

Hardware Accelerated Full Copy tasks such as power on VM’s or cloning VM’s are more efficient.

Hardware Accelerated Block Zeroing if you create a disk using ‘Thick Provisioned’ Lazy Zeroed, then the array will take the responsibility to write the zero’s instead of ESXi.

Thin Provisioning perhaps the most important one.  ESXi5 know’s that a LUN has been thin provisioned and can reclaim dead space.  Why is this important? Well imagine you put a 4GB ISO file onto a production VM to install a third party piece of software. After the software has been installed, you delete the ISO file, but how does the array know that the 4GB of space can be reclaimed? The operating system doesn’t tell ESXi5 or the array to reclaim the space as it’s no longer used, instead it comes from the T10 UNMAP command.

How do we know if our SAN is VAAI supported? If you go to Storage > Devices and look at the Hardware Acceleration Column, you are looking for ‘supported’.

We commonly use HP SAN’s and different levels of SAN Management Software will have VAAI support for example HP P4000, need SANiQ version 9 or above to support VAAI (9.5 is out).

Naturally, as we are all IT professionals we regularly update the firmware on all of our devices!

High Availabity for vMotion Across Two NIC’s

Posted on by Craig

When designing your vCentre environment, good practice is to associate two physical network adapters (uplinks) to your vMotion network for redundancy.

The question is does VMware use both uplinks in aggregation to give you 2GBps throughput in an Active/Active configuration? the answer to this is no.

In the above configuration we have two uplinks both Active, using the load balancing policy ‘route based on originating virtual port ID’ this means that the VMkernel will use one of the two uplinks for vMotion traffic.  The secondary active adapter will be used but only if the uplink vmnic4 is no longer available.

You might say this is OK, I’m happy with this configuration, I say how can we make it more efficient?

At the moment you will have a single Port Group in your vSwitch which is providing vMotion functionality (in my case it’s also doing Fault Tolerance Logging)

And the vSWitch has two Active Adapters

What we are going to do is rename the Port Group vMotionFT to vMotionFT1, go into the Port Groups properties and change the NIC Teaming setting to the following:

So what have we changed and why? First of all we have over ridden the switch failover order, we have specified that vmnic4 is now unused and that we are not going to ‘failback’ in the event of uplink failure.

You may think hold on Craig, why have you done this now we have no HA for our uplinks, well the next step is going to be adding another Port Group as follows:

VMkernel Select
Network Label vMotionFT2
Use this port group for vMotion Select
Use this port group for Fault Tolerance logging Do Not Select
IP Address 192.168.231.8 255.255.255.0

Once completed, we are now going to edit the Port Group vMotionFT2, go back into NIC Teaming and over ride the switch failover order and set vmnic1 to unused and no for failback.

So what have we achieved?

1. vSwitch1 has two active uplinks
2. vMotionFT1 Port Group is active and uses vmnic1 for vMotion & Fault Tolerance Logging
3. vMotionFT2 Port Group is active and uses vmnic4 for vMotion
4. We can perform two vMotions simultaneously using 1GB of bandwidth each
5. If we have an uplink hardware issue vMotion continues to work

ESXi Networking Part 3

Posted on by Craig

NIC Teaming

The load balancing on NIC teams in ESXi is based on number of connections (think Round Robin) on Windows Server 2003/2008.

Load balancing only occurs on outbound connections i.e. traffic from VM > vSwitch > LAN

ESXi has a number of load balancing options which are:

Route Based on the Originating Virtual Port ID

ESXi runs an algorithm to evenly balance the number of connections across multiple uplinks e.g. 10 virtual machines residing on one vSwith which contains two uplinks would means that each uplink has 5 virtual machines using it.

Once a VM is assigned to an uplink by the VMkernel it continues to use this until it is vMotioned to another ESXi Host or a uplink failure occurs.

Route based on the originating virtual port ID is the default setting in ESXi.

Route Based on Source MAC Hash

This is much like ‘route based on originating virtual port ID’ as the MAC address of the VM’s do not change and therefore they will continue to use the same connection path over and over.  The only way around this is to have multiple virtual NICs (vNIC’s) within the VM which will produce multiple MAC addresses.

Route Based on IP Hash

This uses the source IP and destination IP to create an Hash.  So on each new connection a different uplink path would be taken.  Naturally, if you are transferring large amount of data, the same path would be used until the transfer had finished.

When enabling ‘Route Based on IP Hash’ you will get an information bubble:

You need to ensure that all uplinks are connected to the same physical switch and that all port groups on the same vSwitch are configured to use ‘route based on IP hash’.

Use Explicit Failover Order

This isn’t really load balancing as the secondary active (vmnic1) uplink will only come into play if vmnic4 fails.

If you have an active and standby adapter, the same procedure applies.

On all Load Balancing policies it is set by default to notify switches, what does this actually mean? Well it means that the physical switches learn that:

– A vMotion occurs
– A MAC address is changed
– A NIC team failover or failback has occurred
– A VM is powered on

Virtual Switch Security

Virtual switch security has three different elements which are:

– Promiscuous Mode, this is where the vSwitch and/or Port Group can see traffic which is not for itself.
– MAC Address Changes, this is where the vSwitch and/or Port Group is interested if the incoming traffic into the vSwitch/Port Group has been altered.
– Forged Transmits, this is where the vSwitch and/or Port Group is interested if the outgoing traffic into the vSwitch/Port Group has been altered.

In all of the above configurations you have a choice to either Reject or Accept the traffic.

VMware recommends that all of these are set to reject.

However if you are using Network Load Balancing or devices with ‘Virtual IP Address’s’ such as Hardware Load Balancers often use an algorithm that produces a shared MAC Address which is different from the original source or destination MAC address and therefore can cause traffic not to pass.

If in doubt you can always turn all three to reject, however I would recommend letting the Server Team know first!

ESXi Networking Part 2

Posted on by Craig

VMkernel Ports

I mentioned in ESXi Networking Part 1 that the VMkernel network carries traffic for:

– vMotion
– iSCSI
– NFS
– Fault Tolerance Logging

VMkernel ports require an IP address, you can have more than one VMkernel network if you feel this level of redundancy is appropriate in your network.  Or you could have one VMkernel network for Management Traffic, Fault Tolerance Logging and vMotion (however I would recommend against this).

VM Ports

Virtual Machine port groups are quite different to VMKernel Ports as they do not require an IP address or an uplink (physical NIC) to work.  They work in exactly the same was an unmanaged physical switch, you plug it in and off you go!

VLAN

Using VLAN’s within ESXi generally is a must unless you have an abundance of physical NIC’s (the limit is 32 per ESXi Host).  VLAN’s provide secure traffic segmentation and reduce broadcast traffic across networks.

We can have multiple Port Groups per uplink if required.  When configuring VLAN’s these can be performed in one of three ways:

– VM Port Group, when adding a new port group you can specify the VLAN ID in the properties of the port group (most common).

– Physical Switch, you can ‘untag’ the uplink that the VM Port Group resides on which forces it into the VLAN ID specified on the physical switch (common).

– Virtual Guest Tagging, this is when the virtual machine is responsible for VLAN tagging.  From an ESXi perspective you need to use VLAN ID 4095 (uncommon).

The uplink that is connected to the physical switch must be configured as a ‘trunk port’ to enable the switch port to carry traffic from multiple VLAN’s at the same time.

Below is an example Standard vSwitch0, from my home LAB, this has one uplink and has three different VLAN’s in play.

VLAN  1 which is the default VLAN and is used by the VMKernel for Management Network purposes and also my Server2012 RC.

VLAN 2 holds my nested ESXi Hosts and vCentre Virtual Appliance.

VLAN 3 holds my iSCSI Storage Area Networks.

NIC Teaming

NIC teaming is used to connect multiple uplinks to a single vSwitch commonly for redundancy and load balancing purposes.

I have seen many NIC teams created with no thought for redundancy on the network card.

Incorrect NIC Teaming

In this configuration we have no resilience for network card failure.

Correct NIC Teaming

In this configuration we have resilience for network card failure.