Home > Blogs > VMware vSphere Blog > Monthly Archives: September 2012

Monthly Archives: September 2012

Does XenApp (or VDI) on vSphere 5.x Still Require a HIMP Adjustment?

Does XenApp (or VDI) on vSphere 5.x Still Require a HIMP Adjustment?

Short Answer: No – This adjustment is only required under vSphere 4.x.

Background:

Some time ago, a 3rd party project compared hosting platforms for XenApp and found vSphere 4.x to be deficient.  After some analysis with the 3rd party, the following guidance was generated:

ESX provides fine-grained CPU scheduling that, among other things, enforces resource settings like CPU reservations, limits, and shares. Based on those settings, the scheduler determines if a VM has fallen behind in the amount of CPU time it should have received. Should the VM indeed be behind, attempts are made to help it catch up, usually by scheduling it more frequently.

If the processor has hyper-threading, however, scheduling more frequently does not guarantee that the VM will catch up. This is because the amount of CPU resources received by the vCPU is affected by the activity on the other logical processor on the same physical core. To guarantee the vCPU that is behind can catch up, ESX will sometimes not schedule VMs on the other logical processor, effectively leaving it idle.

In the case of the Intel Xeon 5500 series (and other modern hyper-threaded) processors, not scheduling on a logical processor may have a measurable impact on the overall throughput of the system. As a result, in systems that:

  • have more than 50% CPU utilization, and
  • are very close to exactly committed (number of vCPUs = number of pCPUs +/- 25%), and
  • and have particular kinds of bursty CPU usage patterns

we have observed a throughput drop of up to 15% when this fairness algorithm takes effect.

Reference: KB1020233

So altering the default HaltingIdleMsecPenalty (aka HIMP) became a practice when those ESXi instance were hosting XenApp.

You notice a small entry on the above KB article that now says:

Note: This issue does not affect ESXi 5.0.

So the question becomes – why?  What’s changed under ESXi 5.x?

Two major changes (thanks to Seongboem in our Perf-Eng team for this explanation):

  1. The VMware scheduler now detects the situation where utilizing both HT threads is harmful to fairness and in response lets one HT thread idle.  This is good for fairness but bad for CPU utilization.  As such, the detection mechanism has becomes more accurate in vSphere 5.x, especially for workloads like XenApp and VDI.
  2. The charging model has changed in vSphere 5.x such that utilizing both HT threads is favored in terms of fairness.  This reflects recent HT improvement where utilizing both HT shows meaningful benefit.  Older generations of HT architecture showed little or no improvement for industry standard workloads but Nehalem and later showed measurable benefit.

So while our solution team’s best practice guide is not yet updated to reflect this change for vSphere 5.x, all the other practices and considerations should still be adhered to.

Citrix XenApp on vSphere Best Practices Guide

X-Large Edge Gateways and vCD

One of the outstanding enhancements provided in the vCloud Director 5.1 release was the ability to select between two different deployment models of the Edge Gateway.  It is now possible for you to deploy the Edge Gateway in a Compact or Full model, with the difference between the two being the performance they provide and the amount of resources they utilize.

But did you know there is a third Edge Gateway deployment model called X-Large?

If you use your vSphere Client and under the Network Virtualization tab for the Datacenter Object you try to add a Edge Gateway, you’ll see that there are three possible selections:

If you’ve already deployed vCloud Director 5.1 however, you may notice that you are only able to select between the Compact and Full models.  What happened to the X-Large model?

The answer is pretty simple: The X-large model of deployment for the Edge Gateway is not supported with vCloud Director 5.1 currently.  As the picture above shows, the X-Large deployment model has some limitations, such as a lack of SSL VPN support.

Can you possibly get this super-sized Edge Gateway to work?  Possibly.  Again though, it is not supported at the current time with vCloud Director 5.1.

Introducing the VIB Author Fling

I’m very excited to announce the new vibauthor fling.  This fling is hot off the press and provides the capability to create custom vSphere Installation Bundles (VIBs).  Prior to this fling the VIB authoring tools were only available to VMware partners, this fling now extends this capability to everyone.

There are a couple of use cases for creating custom VIBs.  For example, if you are using Auto Deploy and you need to add a custom firewall rule to your host, or you need to make a configuration change that can’t be made using Host Profiles.

One word of caution however, the ability to create custom VIBs does come with some responsibility.  If you plan to create your own VIBs here are a few things to keep in mind:

  1. VIBs provided by VMware and trusted partners are digitally signed, these digital signatures ensure the integrity of the VIB.  Custom VIBs are not digitally signed.  Be careful when adding unsigned VIBs to you ESXi hosts as you have no way of vouching for the integrity of the software being installed.
  2. Before adding a custom VIB you will need to set your host’s acceptance level to “Community Supported”.   When running at the community supported acceptance level it’s important to understand that VMware support may ask you to remove any custom VIBs.   Here’s the formal disclaimer:

IMPORTANT If you add a Community Supported VIB to an ESXi host, you must first change the host’s acceptance level to Community Supported. If you encounter problems with an ESXi host that is at the CommunitySupported acceptance level, VMware Support might ask you to remove the custom VIB, as outlined in the support policies:”

 

If you are not familiar with VIBs I recommend you start with a quick review of this blog: http://blogs.vmware.com/esxi/2011/09/whats-in-a-vib.html

With that, I know several folks have been chomping at the bit to create their own custom VIBs so I’ve attached a short tutorial that shows how to use the vibauthor tool to create a  VIB to add a custom firewall rule.

Enjoy!

vibauthor-how-to-v0.1

Can’t connect to the vCloud Director 5.1 Virtual Appliance? Try this…

It’s come to our attention that some folks may be having an issue after they deploy the vCloud Director 5.1 Appliance where they are unable to connect to the vCloud Director user interface or find that they can not connect to a remote console for the deployed VMs.  While we are still investigating the root cause of this issue, the following describes a fix that should help you get up and running.

To begin, first log into the vCloud Director console. Remember that by default in the vCloud Director 5.1 Appliance, the username is root and the password is vmware for accessing the console. Using a text editor, such as vi, edit the /etc/sysctl.conf file. For example:

# vi /etc/sysctl.conf

Find the line for net.ipv4.conf.all.rp_filter and change the value from a 1 to a 0.

Save the file and then run the command:

# sysctl –p

Then try again to access the vCloud Director Appliance through your web browser or connect to the console of a deployed VM.  You should be presented with the vCloud Director user interface or console, as expected.

The reason for this change is documented here (http://www.novell.com/support/kb/doc.php?id=7007649).  You’ll also note that you can set this attribute to a ‘2’, which may be more suitable in certain environments.

Again, investigation of this issue is still underway.  Once that concludes, there might be a different solution that is provided.

Identifying Non-Default Advanced & Kernel Settings Using ESXCLI 5.1

I recently came across a very cool tidbit from one of our GSS Engineers Daniel de Sao Jose about a new option in ESXCLI 5.1 which allows you to list out all ESXi advanced and kernel settings that have non-default values configured. This can come in handy when you are troubleshooting and trying to find out what advanced settings were changed on a host or if you need to capture the list of changes for documentation purposes or for creating a script to apply to other hosts.

To list all ESXi Advanced Settings, you would run the following command (4.x & 5.x):

esxcli system settings list

To list only ESXi Advanced Settings that have changed from the system defaults, there is now a new option called [ --delta | -d ] in ESXCLI 5.1 which can be specified with the list operation (ESXi 5.1 only):

esxcli system settings advanced list -d

Path: /UserVars/SuppressShellWarning
Type: integer
Int Value: 1
Default Int Value: 0
Min Value: 0
Max Value: 1
String Value:
Default String Value:
Valid Characters:
Description: Don’t show warning for enabled local and remote shell access

In the example above, we can see that the /UserVars/SuppressShellWarning setting has been changed from the system default of 0 (false) to 1 (true).

To list all ESXi Kernel Settings, you would run the following command (4.x & 5.x):

esxcli system settings advanced kernel list

To list only ESXi Kernel Settings that have changed from the system defaults, there is also a new option called [ --delta | -d ] in ESXCLI 5.1 which can be specified with the list operation (ESXi 5.1 only):

esxcli system settings advanced kernel list -d

Name                  Type   Description                 Configured  Runtime  Default
—————        —-    ————————-  ———-     ——-      ——-
smallFontForTTY  Bool  Use 50-line font for tty.  true           FALSE     FALSE

In the example above, we can see that the smallFontForTTY setting has been changed from the system default of false to true.

The next time you are stuck wondering what ESXi Advanced or Kernel settings you might have changed, you now have a very easy way of figuring out the specific settings and their configured value and defaults.

Get notification of new blog postings and more by following lamw on Twitter:  @lamw

A tweet says more than a 1000 words

Sometimes a 140 character tweet says more than a 1000 words…

If you are not using it today, enable it… it could also save your weekend!

vCenter Single Sign-On Part 1: what is vCenter Single Sign-On?

Confused with what vCenter Single Sign-On is?

I was until I dived in and found answers which I will do my best to explain here.

vCenter Single Sign-On is a new feature of vSphere 5.1 that is not just an authentication broker but also a security token exchange providing a more secure way of accessing your vSphere solutions. What that means is that when you previously logged into vCenter Server, you were authenticated with the provided username and password against the Active Directory configured for vCenter Server. With vSphere 5.1 and vCenter Single SIgn-On you no longer log directly into vCenter Server but with a security domain defined by your vSphere environment. When logging in to vSphere 5.1 you actually pass authentication to the  vCenter Single Sign-On server which can be configured with multiple identity sources like Active Directory and OpenLDAP and on successful authentication, your username and password is exchanged for a security token which is then used to access the vSphere components like vCenter Server and vCenter Orchestrator etc.

SSO

Although vCenter SIngle Sign-On is an additional component in the vSphere suite, a critical component that is required before any other vSphere 5.1 component is installed or upgraded, it actually doesn’t necessarily mean you need to re-architect your vSphere environment. You can use vSphere just as you have been from years past and vCenter Single Sign-On will fit right on in just as an additional service local too or separate from vCenter Server.

NewImage

Where some of the confusion comes from I believe is with the added benefits that vCenter Single Sign-On can bring  when administering multiple vSphere environments. When installing vCenter Server you have the choice to specify or install a vCenter Single Sign-On server providing the ability to add multiple vCenter Servers and their components to a centralized vCenter Single Sign-On source. This provides a single pane of glass view across all vCenter servers, 5.0 and higher for administration as well as the ability to define queries that can be searched across multiple vCenter Servers without the requirement of Linked Mode used in the past.

Now this maybe seen as a single point of failure, a critical one at that when talking authentication but vCenter Single SIgn-On can be configured in a clustered or multisite deployment to help with availability.

Clustered deployments are with multiple instances of vCenter SIngle Sign-On are deployed, one is defined as a primary instance the remainder as slaves and all share a single database instance and placed behind a third party load balancer can provide redundancy or high availability of the vCenter Single Sing-On solution. This typically is local to a single site however if geographical sites are used with multiple vCenter servers, you can still utilize a central clustered environment, however a multisite configuration is recommended.

Multisite deployments are  where a local replica is maintained at remote sites of the primary vCenter Single SIgn-On instance. vCenter Servers are reconfigured to use the local vCenter SIngle SIgn-On service and reduce authentication requests across the WAN. Multisite deployments do drop the support of single pane of glass views unless Linked Mode is utilized and multisite deployments are actually required to maintain Linked Mode configurations where roles, permissions and licenses are replicated between linked vCenter servers. Linked mode will re-enable single pane of glass views across multisite instances.

I hope this was informative

vCenter Single Sign-On – Part 2: Deployment Options
vCenter Single Sign-On – Part 3: Availability
vCenter Single SIgn-On – Part 4: Pre Install Requirements

What’s New in VMware vCloud Networking and Security 5.1

With the release of vCloud Networking and Security 5.1 product, VMware brings the leading software defined networking and security solution that enhances operational efficiency, provides agility and is extensible to rapidly respond to business needs.

I just want to provide you some overview on how vCloud Networking and Security product brings the flexibility to the network and security aspects of the datacenter and point you to the resources where you can get more information.

There are different components of this solution. The first one addresses the networking challenge by providing a simpler approach of creating an abstracted logical network. In the vSphere infrastructure, you are already familiar with the process of creating virtual switches and associated port groups to build a virtual logical network. This process of creating virtual network is quick and easy because it is software defined. However, the virtual switch constructs are still dependent on the physical network configuration. For example, if you create a new port group on a virtual switch to support a new application that needs isolation from other applications, you have to configure VLAN on the port group and also on the physical switches. So first, you need to work with the networking team before you can create this new port group and deploy application. This process might take days or weeks. With VDS + VXLAN, we create a new abstracted network, also called as an overlay network, that can be created or torn down with few clicks. Since this network is abstracted from the physical network topology, you don’t have to worry about re-configuring your physical network infrastructure. This allows administrators to provision isolated networks on-demand for their new applications or tenants.

The second component addresses the network services aspects. Once you create logical networks, you now would like to provide network services such as load balancers, DHCP services, Firewall, NAT services etc to the devices or workloads connected to these logical networks. The Edge and App virtual appliances will provide flexible on-demand network services to these logical networks.

The Third component addresses the extensibility of the solution through an open architecture with industry-standard APIs. This extensibility enables freedom of choice and avoids vendor lock-in. The solution allows third-party service insertion and thus organizations can easily take advantage of new technology, integrating operational workflows with existing systems and procedures. For example, you can deploy best of breed load balancing service from your vendor of choice. There are three different integration points – Within a virtual machine, at the edge of the virtual machine, and the edge of the virtual network.

Finally, the fourth and last component is the management and operation of this complete solution. VMware provides simplified management and operation through the advanced capabilities of VDS, where network administrators have access to familiar troubleshooting and monitoring features such as NetFlow, Port Mirroring, and SNMP MIBS. On the security front the APP and Edge Firewall are tightly integrated with vCenter Server Objects such as cluster, port groups, vAPP etc. This integration makes rule creation faster and less error prone than legacy approaches that require administrators to manually create and maintain IP address–based objects.

For more details on the vCloud Networking and Security 5.1 product,  I would encourage you to visit the website here

Also, for details on VDS you can read the What’s new paper

Get notification of these blogs postings and more VMware Networking information by following me on Twitter:  @VMWNetworking

Technical paper: “VMware vCloud Director Resource Allocation Models” available for download

Today the technical paper “VMware vCloud Director Resource Allocation Models” has been made available for download on VMware.com.

This whitepaper covers the allocation models used by vCloud Director 1.5 and how they interact with the vSphere layer. This paper helps you correlate the vCloud allocation model settings with the vSphere resource allocation settings. It provides insight on the distribution of resources on both the vCloud layer and vSphere layer and illustrates the impact of various allocation model settings on vSphere admission control. The paper contains a full chapter about allocation model in practice and demonstrates the effect of using various combinations of allocation models within a single provider vDC.

Please note that this paper is based on vCloud Director 1.5

http://www.vmware.com/resources/techresources/10325

What’s New in vCenter Server Heartbeat v6.5

With all the recent announcements around vSphere 5.1 you probably didn’t see the updated release of vCenter Server Heartbeat v6.5.

 

What’s New

The following information provides highlights of some of the enhancements available in this release of vCenter Server Heartbeat 6.5

Note: The features available depend on the version of vCenter Server installed.

Features

  • Support for vCenter Server 5.1 — This release of VMware vCenter Server Heartbeat now provides support for vCenter Server 5.1
  • Support for VIEW Composer 3.0 — This release of VMware vCenter Server Heartbeat now provides support for VIEW Composer 3.0 deployed local to vCenter Server or separate.
  • Enhanced Setup — This release of VMware vCenter Server Heartbeat provides for more automation during setup resulting in fewer user steps and easier configuration.
  • Administer VMware vCenter Server Heartbeat via vSphere Web Client — You can now install a vSphere Web Client Plug-in to administer VMware vCenter Server Heartbeat directly from the vSphere Web Client Heartbeat tab.
  • Network Isolation — VMware vCenter Server Heartbeat now provides a safeguard to prevent Split-brain in the event of loss of both channel and public visibility of the active server.
  • vCenter Role Based Permissions — The vCenter Server Heartbeat vSphere Web Client supports View Only and Administrator roles.
  • Editing Protected Services — vCenter Server Heartbeat Console now allows you to perform a single operation to configure the actions to take upon failure for all protected services.
  • Support for Microsoft SQL Server 2012 — This release of VMware vCenter Server Heartbeat provides support for Microsoft SQL Server 2012.

 

Resources

http://www.vmware.com/products/vcenter-server-heartbeat/overview.html

http://www.vmware.com/files/pdf/products/vCenter/VMware-vCenter-Server-Heartbeat-Datasheet.pdf

http://www.vmware.com/support/pubs/heartbeat_pubs.html