Eric Sloof

The diagram at left should be familiar to most. When using 1GigE NICs, ESX hosts are typically deployed with NICs dedicated to particular traffic types. For example you may dedicate 4x 1GigE NICs for VM traffic; one NIC to iSCSI, another NIC to vMotion, and another to the service console. Each traffic type gets a dedicated bandwidth by virtue of the physical NIC allocation. 

Moving to the diagram at right … ESX hosts deployed with 10GigE NICs are likely to be deployed (for the time being) with only two 10GigE interfaces. Multiple traffic types will be converged over the two interfaces. So long as the load offered to the 10GE interfaces is less than 10GE, everything is ok—the NIC can service the offered load. But what happens when the offered load from the various traffic types exceeds the capacity of the interface? What happens when you offer say 11Gbps to a 10GigE interface? Something has to suffer. This is where Network IO Control steps in. It addresses the issue of oversubscription by allowing you to set the relative importance of predetermined traffic types. 

NetIOC is controlled with two parameters—Limits and Shares.

Limits, as the name suggests, sets a limit for that traffic type (e.g VM traffic) across the NIC team. The value is specified in absolute terms in Mbps. When set, that traffic type will not exceed that limit *outbound* (or egress) of the host.

Shares specify the relative importance of that traffic type when those traffic types compete for a particular vmnic (phyiscal NIC). Shares are specified in abstract units numbered between 1 and 100 and indicate the relative importance of that traffic type. For example, if iSCSI has a shares value of 50, and FT logging has a shares value of 100, then FT traffic will get 2x the bandwidth of iSCSI when they compete. If they were both set at 50, or both set at 100, then they would both get the same level of service (bandwidth).

There are a number of preset values for shares ranging from low to high. You can also set custom values. Note that the limits and shares apply to output or egress from the ESX host, not input.

Remember that shares apply to the vmnics; limits apply across a team.

The vSphere 4.1 vMotion enhancements significantly reduce the overall time for host evacuations, with support for more simultaneous virtual machine migrations and faster individual virtual machine migrations. The result is a performance improvement of up to 5x for an individual virtual machine migration and support for four to eight simultaneous vMotion migrations per host, depending on the vMotion network adapter (1GbE or 10GbE respectively).

The VMware knowledge base contains some useful articles regarding the new vSphere 4.1 release.

• Using Tech Support Mode in ESXi 4.1
• Troubleshooting ESXi 4.1 Scripted Install errors
• Recreate vSphere 4.0 lockdown mode behavior in vSphere 4.1
• vCenter Server 4.1 fails to install or upgrade with the error: This installation package is not supported by this processor type
• Migrating to the vCenter Server 4.1 database
• Update Manager 4.1 patch repository features
• Lockdown mode configuration after upgrading from ESXi 4.0 to 4.1
• Changes to VMware Support Options in vSphere 4.1
• Securing Credentials in vMA 4.1
• Overview of Active Directory integration in ESX 4.1 and ESXi 4.1
• ALUA parameters in the output of ESX/ESXi 4.1 commands
• USB support for ESX/ESXi 4.1

With the release of vSphere 4.1, storage IO Control allows cluster-wide storage IO prioritization. This allows better workload consolidation and helps reduce extra costs associated with over-provisioning. Storage IO Control extends the constructs of shares and limits to handle storage IO resources. The amount of storage IO that is allocated to virtual machines during periods of IO congestion can be controlled, which ensures that more important virtual machines get preference over less important virtual machines for IO resource allocation.

When Storage IO Control on a datastore is enabled, ESX/ESXi begins to monitor the device latency that hosts observe when communicating with that datastore. When device latency exceeds a threshold, the datastore is considered to be congested and each virtual machine that accesses that datastore is allocated IO resources in proportion to their shares and is set per virtual machine. The number can be adjusted for each based on need. Low priority VMs can limit IO bandwidth for high priority VMs and storage allocation should be in line with VM priorities.

This feature enables pre-datastore priorities/shares for VM to improve total throughput and has Cluster level enforcement for shares for all workload accessing a datastore. Configuring Storage I/O Control is a two-step process:

1. Enable Storage I/O Control for the datastore.
2. Set the number of storage I/O shares and upper limit of I/O operations per second (IOPS) allowed for each virtual machine. By default, all virtual machine shares are set to Normal (1000) with unlimited IOPS.

Duncan Epping        : Storage IO Control, the movie
Scott Drummonds    : Storage IO Control
VirtualMiscellaneous : Storage IO Control - SIOC

John Troyer and Luke Kilpatrick of VMware's Social Media Team give a full demonstration of the features and use of the VMworld 2010 Backpack.

Get your very own VMworld 2010 Backpack by registering and attending VMworld 2010 at the Moscone Center, San Francisco, August 30th - September 2nd or at the Bella Center, Copenhagen, October 12th -- 14th - http://bit.ly/bc9sqO

Fellow vExpert Eric Siebert has written a great article about affordable storage solutions which can be used as shared storage for VMware vSphere. In his article he sums up all the vendors followed by a nice comparison chart with things like the numbers of bays, support for iSCSI or NFS, the number of network connections and capacity. So check out his article with affordable shared storage options.

• Drobo
• Hewlett-Packard
• Iomega
• Netgear
• QNAP
• Synology
• Thecus

http://searchstorage.techtarget.com.au/articles/42004-VMware-vSphere-shared-storage-guide

Every once in a while you will experience problems that only can be fixed by visiting the ESX console, at least I do. When you finally have found the IP address or hostname and you’re using your favourite browser to load the MKS java applet, the information is scrolling fast and your keyboard isn’t mapped correctly. These two problems can be fixed easily, you have to fix the real problem yourself. :-)

First let’s start with the scrolling problem. When you issue a command like esxcfg-vswitch because you want to check out your vSwitch configuration, you only see the last part and can’t scroll back. You might want to redirect the outcome of your command into a file and use nano to walk through it.

esxcfg-vswitch -l >> network.txt
nano network.txt

This type of redirection pipes the output into the file network.txt.  The difference between this and the single-'>' redirection is that the old contents (if any) of network.txt are not erased.  Instead, the esxcfg -l output is appended to the file.

The second problem I have experienced a lot it an incorrect mapping of the keyboard. This problem can be easily fixed by loading a different keyboard translation table. The program loadkeys reads the file or files specified by filename.... Its main purpose is to load the kernel keymap for the console. 

Loadkeys us will do the trick.

Fellow vExpert Jakub Felinski over at the weblog “Virtualization in Practice” has posted a really nice article about using Nagios to monitor a VMware vSphere environment. Nagios is a popular open source computer system and network monitoring software application. It watches hosts and services, alerting users when things go wrong and again when they get better. Jacub has added all the necessary VMware modules to the Nagios virtual appliance which can be downloaded in OVF format at his website. He also created a description with the configuration changes at ESX level, it’s real easy to get it up and running. The original Polish article with download link can be found here and the Google translation can be found here.

By default, each ESX host gets a set of basic tests which include:

•  CPU usage
•  Disk latency (read write)
•  Hardware sensors
•  Disk operations canceled
•  State of network cards
•  Memory swapping
•  Free space in each Datastore

VMware vCenter Configuration Manager's (formerly EMC Ionix Server Configuration Manager) policy-driven automation detects deep system changes and identifies whether that change is within policy - an expected and acceptable behavior based on industry, regulatory, or your own self-defined best practices - or whether that change has created a compliance violation or security vulnerability.

http://www.vmware.com/products/configuration-manager/

Automate configuration management across virtual and physical servers, workstations, and desktops with VMware vCenter Configuration Manager. Increase efficiency by eliminating manual, error-prone and time-consuming work.

• Avoid configuration drift by automatically detecting and comparing changes to policies
• Maintain continuous compliance with out-of-the box templates and toolkits
• Automate and optimize server provisioning and application stack deployment in the datacenter

Also take a look at:

VMware vCenter Application Discovery Manager

Quickly and accurately map your application dependencies to accelerate datacenter moves, precisely plan infrastructure consolidations and confidently virtualize your business critical applications.

VMware Service Manager

VMware Service Manager develops a 100% web architected solution that automates IT Service Management processes in enterprise organizations.VMware Service Manager is independently verified to the highest level of ITIL compatibility for Incident Management, Problem Management, Change Management, Release Management, Configuration Management, Service Level Management and Availability Management.