Great news!

I am by no means an analyst, but to me this shows VMware’s taking desktop virtualization seriously by differentiating it from its core products and making a dedicated certification track.  Citrix has done this for a while with their Citrix Certified Administrator certifications for XenDesktop as they recognized the importance of differentiating that technology from their other offerings.  VMware’s three level desktop certification track shows VMware recognizes they need to build the skill set and acknowledge those that have developed an expertise in delivering their VDI solution.

I also think this brings up an important point about desktop virtualization that I’ve seen as a larger trend in the industry.  That is, the folks that know how to do server virtualization are not automatically the same folks who should be doing desktop virtualization.  Just because someone has a VCP certification doesn’t mean they know how to deploy VMware View (or XenDesktop for that matter).  Desktop virtualization requires a different skillset and creating certifications specifically for this technology shows VMware acknowledges this as well.

I think VMware has made the right move here in creating a seperate certification track for those that focus on desktop virtualization.  It should help both acknowledge those that are experts in desktop virtualization as well as improve the overall design, implementation, and delivery of their desktop virtualization products.

Today I decided to take that concept and extend it to systems that you might manage alongside your VI3/vSphere environment.  Storage management seemed like the obvious first choice.

I created an XML file called EqualLogic.xml in C:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Plugins\SAN Management.  The contents of the file are as follows (you would replace the <url> section with the IP or DNS name of your SAN):

<scriptConfiguration version=”1.0.0″>
<key>EqualLogic</key>
<description>EqualLogic SAN Management</description>
<view parent=”Inventory.HostSystem”>
<title locale=”en”>EqualLogic</title>
<url>http://10.1.97.30</url>
</view>
</scriptConfiguration>

This gave me a nice way to manage my SAN from the same interface that I use to manage my vSphere environment.  It is simply opening a browser window within the vSphere Client and letting me manage the SAN.

The code above will make the EqualLogic tab visible only when clicking on an ESX/ESXi host.  If you wanted to extend that to other objects, you can simply adjust the “<view parent=” section.  For example, to also make this available at the cluster level you would include the following:

<view parent=”Inventory.Cluster”>
<title locale=”en”>EqualLogic</title>
<url>http://10.1.97.30/</url>
</view>

Similarly you could add Inventory.Global, Inventory.VirtualMachine, Inventory.Datacenter, etc.

This is a really simple way to make it easy to manage any web interface (not just EqualLogic) from within the vSphere/VI Client.  It’s not a new trick and has been out there for a while but I had never used it for this until today.

In my recent post on the effects of ASLR in vSphere the comments turned into a discussion about TPS on modern processors. And there are countless posts about this issue on the VMTN forums where folks are looking for a fix. In reality nothing is broken and there is no need to fix the issue.

VMware has published a KB article that gives more information on TPS with Nehalem processors and why it appears TPS isn’t working (this affects modern AMD processors also). The short version is that TPS uses small pages (4K), and Nehalem processors utilize large pages (2MB). The ESX/ESXi host keeps track of what pages could be shared, and once memory is over-comitted it breaks the large pages into small pages and begins sharing memory.

Many people think this is a bug in ESX that needs to be fixed. This likely started because when vSphere 4 was released there was a bug around memory usage on ESX hosts with Nehalem processors. In reality the bug was that vCenter was triggering high memory usage alarms for virtual machines running in this configuration. Nothing was actually wrong but because the host was using all of the assigned memory for the VM, vCenter was incorrectly triggering the alarm. That behavior has since been fixed with a patch and is no longer an issue.

So what does this actually look like? When a VM is powered up on an ESX host with Nehalem processors, the amount of host memory in use will not drop down as the VM uses less memory or becomes idle. Those of us that have been using ESX for a long time likely found this scenario disturbing.

From vSphere Client (red highlighted section shows guest taking all of the 2GB assigned memory, yet memory usage in the guest is very low):

From esxtop (red highlighted section shows almost no memory being shared with page sharing):

The above screenshots show a host that is under-committed on memory and so no page sharing is occurring.  If the host gets over-commited page sharing kicks in automatically by breaking up large pages into small pages.  You can force the use of small pages on all guests all the time by changing the value of the advanced option Mem.AllocGuestLargePage to 0.  I don’t really see any reason to do this – remember that TPS isn’t broken and what you see in the above screenshots is normal and expected.

Once host memory is over-committed (or if you use the advanced option), memory sharing kicks in and things look like they normally do when page sharing is taking place.

From the vSphere Client (red highlighted section shows guest taking very little of the assigned 2GB memory as page sharing has kicked in):

From esxtop (red highlighted sections show a large amount of shared memory and the host is over-commited on memory by 48%):

A quick note on the esxtop screenshot above – it was taken from a VDI environment where all workloads are identical so that explains the high amount of shared pages.  It was also overcommitted more than normal as it was taken during host maintenance.

I hope this clears up some of the confusion around TPS on modern Intel/AMD processors.  In short, don’t get hung up on the fact that TPS isn’t kicking in like it did with older processors.  Nothing is broken, TPS is working as expected, and it will kick in when you actually need it.

I’m working on a vSphere implementation using Dell EqualLogic SANs and wanted to configure Round Robin on all of my datastores. Dell has a great whitepaper on how to set this up, but unfortunately the document fails to mention one key thing: this doesn’t change the default path selection plugin (PSP) from Fixed to Round Robin.   That means that you’ll have to set the multipathing policy to Round Robin on all of your existing datastores and will have to remember to do that on all future datastores. When you’ve got multiple ESX hosts with lots of  datastores this can quickly become a pain.

Luckily there is a way to force the default multipathing policy to Round Robin. The following commands can be used to change the default PSP to Round Robin as well as configure round robin specifically for the EqualLogic provider.  These commands can be entered at the Service Console or via the vSphere CLI 4.0:

esxcli nmp satp setdefaultpsp –satp VMW_SATP_DEFAULT_AA –psp VMW_PSP_RR
esxcli nmp satp setdefaultpsp –satp VMW_SATP_EQL –psp VMW_PSP_RR
esxcli corestorage claimrule load
esxcli corestorage claimrule run

Note that “satp” and “psp” are preceded by two dashes and not a single dash as it appears in this blog post.

Once you enter those commands (no rebooting required) any volume you add, either new or existing, will use Round Robin MPIO by default.

Address Space Layout Randomization (ASLR) is a security feature that randomizes the position of data in memory, making it more difficult for attackers to predict where data can be found while in memory. This feature has been enabled in Windows since Windows Vista, and other operating system such as Linux and MacOS implement this in some form as well.

Since ASLR randomizes information in memory it makes sense that it would be more difficult for TPS to find identical memory pages and thus memory sharing would be reduced. But just how much of a difference does it make? I decided to try and find out. Here are the specs from my test environment:

Server: HP DL385 G1 (AMD Opteron 275)
ESX: 4.0.0 build 244038
Guest OS: Windows Server 2008 R2
Guest RAM: 2.5GB

All guests were cloned from the same template and have the same software installed. On guests TESTSRV1 and TESTSRV3, I left the default settings. On TESTSRV2 and TESTSRV4, I disabled ASLR using the following regkey:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
“MoveImages”=dword:00000000

In all of my testing, including leaving VMs idle and also running memory tests, I found no measurable difference in the amount of memory shared with TPS. I also looked at esxtop to see how much memory was actually being shared and I saw virtually no difference whatsoever between VMs that had ASLR enabled and those that had it disabled.

Host Memory Usage:

esxtop statistics:

The SHRD and SHRDSVD columns represent how much memory is being shared with TPS and the total memory savings. Clearly there is quite a bit of memory sharing going with or without ASLR enabled.

Why would this be the case since it makes sense that TPS would be hurt by ASLR? ASLR requires applications to “opt-in” to have their memory randomized, and I suspect that much of Windows 2008 R2 is not opted in. Perhaps applications will come out in the future that are written to take advantage of ASLR, but at the moment that doesn’t appear to be the case.

Of course this is by no means a definitive test as it wasn’t run with production systems and real users running real applications. That said, I think it shows that ASLR does not dramatically reduce the amount of memory shared with TPS. I did also look at production systems left at the default settings (ASLR enabled) and saw similar memory sharing gains. I’m curious if others have seen similar results in their environments, so drop me a line if you’ve done any similar testing.

More info:

What is ASLR (Wikipedia)
Interpreting esxtop statistics

FT is often compared to Microsoft Windows Failover Clusters, formerly Microsoft Cluster Server (MSCS), and in fact many have talked about how FT can replace Microsoft clustering altogether.  Rather than jump to conclusions like this, it is important to understand the use cases for both technologies.  In addition, there are several limitations to FT that need to be considered. Here are some important points to remember about FT:

1) FT only supports a single vCPU, limiting its usefulness for some applications (this will probably change in the future).

2) FT is meant to protect against host level failures only, such as physical server failures.

3) FT keeps protected virtual machines in complete lockstep, meaning whatever happens on the Primary VM also happens on the Secondary VM.  Why is this important to understand?  Guess what happens when the Primary VM bluescreens.

4) FT VMs share the same virtual disk file, meaning a storage level failure affects both.

Microsoft Failover Clustering, on the other hand, can help protect against application and operating system level failures in addition to physical server failures.  Clusters also make it easier to patch the underlying operating system with minimal downtime.  Finally, FT has a limited set of hardware that it is compatible with (see this link to check if your system is compatible) so that may limit its usefulness for some organizations using older hardware.

All of that said, FT is a great feature and definitely has a place in your virtual infrastructure.  Best of all it is available in vSphere Advanced and above, making it an affordable feature that many organizations may already own.  So what are good use cases for FT over Microsoft clusters?  Here are some thoughts:

• Provide hardware level protection to applications that don’t natively support any clustering functionality.  There are many examples here – web servers, application servers, etc.
• Provide hardware level protection to applications where clustering support may be available but is either expensive or requires a special license.  Document management servers, indexers, etc., may make good candidates here.
• Provide extra protection against hardware failures for critical applications during specific business periods where downtime simply cannot be tolerated, such as accounting servers during end of month processing.
• Your specific virtual infrastructure configuration precludes you from using Microsoft clusters due to Microsoft or VMware supportability.

VMware FT is a great new feature that can help provide extra uptime to virtual machines in your environment.  It is available in most versions of vSphere and should definitely be considered as part of a virtual infrastructure design.  Just make sure you understand the use cases for it and don’t rule out Microsoft clusters where they are appropriate.

See also:

FT Frequently Asked Questions

Microsoft has made it possible to expand boot volumes easily and on the fly without downtime without the need for any additional tools.  In this example, we’ll expand the C: drive of a Windows 2008 virtual machine from 25GB to 30GB.

1. Expand the size of the virtual disk.

2. Launch Disk Management by right clicking on My Computer, selecting Manage, and then selecting Storage\Disk Management.  If you do not see the unallocated space, right click on Disk Management and select “Rescan Disks.”

3. Right click on the currently allocated (blue) space, and select “Extend Volume…” to launch the Extend Volume Wizard.

4. Select Next at the Wizard launch screen, and then confirm the amount of space to add to the volume.

5. Select Finish to extend the volume to the new size.

Removing administrator access to end users is unfortunately not enough.  For example, a user can open the VMware Tools tray icon and select the Devices tab, and from there can uncheck “NIC1″ and click Apply.  What happens?  You guessed it – the virtual NIC is disconnected and the user loses connection.  That’s bad in a virtual desktop environment since it will orphan the desktop and likely require a connection broker like XenDesktop to create another desktop but it is even worse on a XenApp server where the user potentially just disconnected dozens of other users as well.

This, and several other things found in the VMware Tools, can be dangerous to leave available to an end user even if they have no rights to the server itself.  To get around this, there are two approaches that make sense:

1) Remove access to the VMware Tools for end users.

2) Modify the VMX configuration file to prevent these actions.

I prefer the second method since it allows for more granular control over security, though if you’re interested in option one then you can read VMware’s KB article on the subject.  In order to prevent this at the VMX (virtual machine configuration file) level, simply add the following lines to the virtual machine(s) that you wish to protect (after powering it down):

isolation.device.connectable.disable = “true”
isolation.device.edit.disable = “true”

To see how to add one of these values to the VMX file via PowerShell and PowerCLI, it would look something like this:

$vm = Get-View (Get-VM NameofVM).ID
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.extraconfig += New-Object VMware.Vim.optionvalue
$vmConfigSpec.extraconfig[0].Key=”isolation.device.connectable.disable”
$vmConfigSpec.extraconfig[0].Value=”true”
$vm.ReconfigVM($vmConfigSpec)

There are many other security parameters that can be set in the VMX file that are covered in VMware’s Security Hardening document (PDF).  The document covers this and many other common security best practices for virtual machines.  As always, test any change you make (especially the script above) before putting anything into production.

Microsoft stuns Linux world, submits source code for kernel

In an historic move, Microsoft Monday submitted driver source code for inclusion in the Linux kernel under a GPLv2 license. The code consists of four drivers that are part of a technology called Linux Device Driver for Virtualization.

Microsoft Linux Move Puts Pressure on VMware

Microsoft’s historic embrace of Linux technology could have wide-reaching impacts on the virtualization market and Microsoft’s rival VMware.

By allowing greater ability to run Linux on the Hyper-V virtualization platform, Microsoft is making a compelling case that it could be the virtualization vendor of choice for consolidation of Windows and Linux applications, says Gartner analyst George Weiss.