XenDesktop 7 Pt 3: Install VDA

This installment of the XenDesktop installation series will show you how easy it is to install the XenDesktop 7 VDA (Virtual Delivery Agent). The VDA can be installed on client VMs, servers (for XenApp), or physical PCs if you want to remote high-powered 3D graphics. It contains the ‘secret HDX sauce’ that is used to deliver the HDX experience to the Citrix Receiver.

XenDesktop 7 Series

Part 1: Role Installation
Part 2: Configure Desktop Studio Site
Part 3: Install VDA
Part 4: Create Machine Catalog
Part 5: Configure StoreFront
Part 6: Create Delivery Group
Part 7: Receiver Configuration
Part 8: Install Server VDA
Part 9: Create Server Machine Catalog
Part 10: Create Application Delivery Group

XenDesktop 7 VDA Installation

1. I logged into my Windows 7 master VM, mounted the XenDesktop ISO, and started the installer. This time we want to install the Desktop Delivery Agent. The installer also clearly shows you the OS I’m running the installer on is incompatible with the server roles, such as Citrix Director. Very nice to quickly see what I can and can’t install on a particular OS without having to refer to documentation. Very nice touch!

6-30-2013 8-26-52 PM

2. Now I have to decide if I want this VM to be a master image, or just provide remote access. Since we are doing VDI, I left the default option.

6-30-2013 8-28-50 PM

3. If I were installing the VDA on a high powered physical workstation and needed to remote 3D professional graphics, such as AutoCAD, then I would install HDX 3D Pro. Since this is a VM, I’ll choose the standard VDA.

6-30-2013 8-31-32 PM

4. I’ll let the installer install the Citrix Receiver into the image as well. That way I can access XenApp apps down the road, if I want.

6-30-2013 8-32-50 PM

5. Here we have to enter the desktop delivery controller name(s). If you are using a NetScaler to load balance your controllers you could enter that FQDN here. In my case I’ll just enter the controller’s FQDN. A nice touch here is a Test button, to validate the server name is correct. Yet another way Citrix is help ensuring a successful deployment.

6-30-2013 8-36-51 PM

6. The VDA has a few features you can select from. I want the whole nine yards, so I chose all of them.

6-30-2013 8-39-25 PM7. Just like in the server role installation, Citrix provides you a full list of firewall ports that are needed.

6-30-2013 8-40-59 PM

8. A summary screen is then displayed, and the VDA starts installing. At the end you should have a successful message.

6-30-2013 9-25-41 PM

Now that the VDA is installed, we can proceed to making a machine catalog and provision some VDI VMs. Stay tuned for Part 4!

CloudVolumes Pt 4: Testing the AppStack

This is the fourth installment of my CloudVolumes spin around the block. So far the installation as has been quick, encountered no product problems, and the experience seems polished even for a v1.0 product. Given my good experience thus far, I can’t wait to see CloudVolumes AppStack in action. Can I really instantly provision Office 2013 or browsers extensions to a running VM, or will I get a blue screen of death? Read on. If you want to start back at the beginning of this series, go here.

To recap we’ve created an AppStack of Office 2013, Adobe Reader IX, Java 7 update 25, and Adobe Flash Player 11. These are very common products probably in many golden images, and they often get regular security updates. My browser of choice is Internet Explorer 10, so let’s see how CloudVolumes handles browser-plugins.

Assigning an AppStack

Since we created an AppStack I now have to assign it, otherwise it won’t be of any use to me. The assignment process is very straight forward and completely AD integrated. First I locate my AppStack in the console and click Assign. I can then pick from a variety of AD objects (users, groups or computers) to assign the AppStack to. In today’s world we are moving away from device-centric application management to user-centric (the apps follow the user around), so I decided to select my administrator account. Next you check the box next to my user account. If I was doing an AppStack for a server then I’d of course pick a computer account.

CloudVolumes AppStack assignment

One of the killer features of the product is the ability to assign an AppStack to a running VM with a logged-in user (i.e. instantly provision apps). The apps should appear in mere seconds, ready for immediate usage. Seems almost too good to be true. Does it work?

6-30-2013 6-27-21 AM

I logged into my Windows 7 x64 VM and looked at the start menu, prior to assigning the AppStack. As you can see it’s a very bare bones install, and there’s no Office or Adobe Reader. Also, my desktop has no application icons on it.

6-30-2013 6-29-19 AM

Testing CloudVolumes AppStack

Now comes the moment of truth..I click the Assign button and eagerly listen to my QNAP and watch the VM for signs of life..or death. And do I get a blue screen of death, does the console crash, or does my AppStack magically appear in seconds on my desktop? After ~7 seconds of QNAP and vCenter activity, appearing on my desktop is the AppStack! Did not have to even log out….I’m amazed.

6-30-2013 6-45-23 AM

Anyone can make icons appear on the desktop, but let’s look at Add/Remove software. Yup..I see all of the programs in my AppStack.

6-29-2013 9-07-58 PM

But do they launch?

6-30-2013 6-47-51 AM

Word 2013

How about those pesky IE plug-ins? That looks pretty normal…except..wait..where’s Flash Player? Hmmmmm

6-30-2013 6-51-45 AM

Let’s try and watch a YouTube video clip to see what happens..maybe it’s just a cosmetic issue. Viola…Flash Player DOES work. I also went to various other Flash Player test sites and everything worked as expected. Note to self: Don’t try and watch Flash videos via the ESXi console. It will bomb after a few seconds, totally unrelated to CloudVolumes. RDP into your test VM to try out Flash or use your VDI solution.

6-30-2013 7-06-13 AM

Let’s try out Java. IE prompted me to allow the Java plug-in, and after acknowledging a Java application security warning, all is well! I actually realized after my testing that the VM I provisioned the AppStack to was using IE 9, but my AppStack master VM had IE. But the plug-ins worked. I then updated my production VM to IE 10, rebooted, and the plug-ins continued to work. So the browser plug-ins seem fairly resilient to IE version changes.

 6-30-2013 7-11-46 AM

Needless to say I was very impressed that everything worked just like in the videos. Through some further testing with Office 2013 I did run into one issue. If I tried to use some of the built-in templates that get downloaded from the internet I got a font error as shown below. The template still opens up, just minus the custom fonts. Other than this font error, all the Office functionality I tested worked flawlessly.

6-30-2013 8-13-09 AM

Now that we have a working CloudVolumes AppStack, how does one update the AppStack with newer versions of the app or add additional apps? Stay tuned for Part 5.

CloudVolumes Pt. 3: Create AppStack

Welcome to Part 3 of installing and configuring CloudVolumes. In Part 1 I provided a short introduction on what CloudVolumes is and started the management console installation process. In Part 2 I configured basic settings such as Active Directory, vCenter, and datastores. Now we are ready to install the CloudVolumes agent and build a CloudVolumes AppStack of Office 2013 and a few other applications.

I mounted the CloudVolumes ISO image and started the agent installation on my AppStack packaging Windows 7 x64 VM. The only two questions I had to answer was the CloudVolumes Manager address and the port. There wasn’t a button to validate the agent could talk to the manager (hint, feature request). After the agent installed I had to reboot the VM. As we will later find out, due to a network configuration error on my part the agent was unable to contact the manager, hence the need for a ‘validation’ button of some sort.

CloudVolumes Agent

Creating a CloudVolumes AppStack

Here comes the exciting part! We now have a VM which we can install our applications and start building up AppStacks. The following two warnings are included in their admin guide:

Important: The provisioning of AppStacks must be performed on a clean base image; that being a VM that resembles as closely as possible the target environment to which you later plan to deploy the AppStack. For example, the provisioning VM and target should be at the same patch and Service Pack level and, if applications are included in the base image, they should also be in the provisioning VM.

Provisioning should be done on a VM that did not have any AppStacks previously assigned to it. If there were any AppStacks assigned to the VM, that VM should be rebooted before provisioning a new AppStack.

Back in the management console I clicked on Create AppStack.

6-29-2013 7-18-19 PM

The console had been sitting idle for an hour, and as soon as I clicked on the button I saw two red warnings for a split second and it booted me out to the login screen. I thought oh crap, a bug. I logged in again and this time the wizard came up so clearly it was just a timeout issue and the warning needs a little tweaking. I decided to go for broke, and try Office 2013 Professional Plus as my first AppStack.

CloudVolumes AppStack

After the wizard completed I now saw an unprovisioned AppStack. I do have one grip about this screen. In the VMDK filename it puts exclamation points in for spaces, which I think is a bit odd. It would make it a lot more readable to use an underscore or hyphen, IMHO. VMFS can support spaces, so not sure why they need to substitute characters.

6-29-2013 7-23-54 PM

Clicking on Provision brought up a screen where it should list all computers that have the CloudVolumes stack installed. This list was empty. Since my name resolution in my home lab is a bit unique, I figured it was a DNS problem. I fixed that problem, but the VM still wasn’t registering with the manager. I looked on the Win7 VM logs and could find no CloudVolumes error messages. I tried to telnet to port 3000 and that worked, so I knew it wasn’t a firewall problem.

After poking around in the console a bit I found the System Messages tab. Apparently, the provisioning VM needs to be joined to the domain. Probably makes sense, but I wasn’t sure if the VM should be as pristine as possible. It would be most helpful if during the agent installation it provided a warning, and also logged error messages in the application log on the Win7 machine about not being domain joined. After I joined the computer it immediately appeared in the CloudVolumes console.

6-29-2013 7-42-55 PM


6-29-2013 7-45-13 PM

I re-ran the AppStack provisioning wizard and came to the screen below. I clicked on the computer name (without clicking the radio button) and it immediately changed to the computers tab. That threw me for a loop, until I figured out I had to click on the radio button to actually provision the application. Minor usability issue.

6-29-2013 7-48-19 PM

Click the radio button then click Provision to get:

6-29-2013 7-51-18 PM

In the Windows 7 provisioning VM I got this pop-up:

CloudVolumes provisioning

So I then mounted the Office 2013 Professional Plus ISO, and ran through the whole install. I also ran Windows update to get it fully patched. While that was running for a while I decided to look at the Win7 VM properties. As you can see CloudVolumes mounted a second VMDK to the VM, which is where all of the application bits are being written.

6-29-2013 7-54-34 PM

During the AppStack capture process I had an “Oh crap” moment. I forgot to take a snapshot of the VM prior to doing the Office 2013 capture. I checked the snapshot history, and no snapshots were present. So I thought to myself I’ll have to rebuild my VM for the next AppStack. Because of what I thought was a mistake on my part I also decided to bundle in Flash Player, Acrobat Reader and Java in this AppStack. I was very curious how browser plug-ins worked, if at all, with CloudVolumes.

After Office 2013 installed I ran Windows update so that it was fully patched. The VM rebooted, and the CloudVolumes agent reminder that I was in provisioning mode was still on the screen. Next up was Flash Player 11, Adobe Reader 11, and Java 7 update 25. After those programs were done installing I clicked on the OK button to end provisioning. The VM rebooted, and after I logged in I got this successful message:
6-29-2013 8-22-15 PM

To my delight I saw that the VM was returned to the pre-AppStack creation state! No Office, no Flash player, no Adobe Reader, no Java. I thought sweet….I didn’t screw up after all! Pretty neat. Back in the Manager console I see the Status is now Enabled, and it even shows how long I took to provision the AppStack.

CloudVolumes AppStack

I wondered what the CloudVolumes datastore looked like and how big the VMDK was, so I browsed to the datastore and found a 4.2GB VMDK.

6-29-2013 8-48-20 PM

Now all I needed to do was install the agent into my “production” Windows 7 x64 VM, assign the AppStack, and see if the magic worked! Check out Part 4 to see how to assign an AppStack and see if this really works….or not.

CloudVolumes Pt 2: Manager Config

In Part 1 of “Installing CloudVolumes” I covered the basic concept of what CloudVolumes does, and we provisioned a Windows Server 2008 R2 VM for their management console. We are now ready to configure the CloudVolumes Manager console to interface with AD, vCenter, and setup the vSphere datastores. So far the CloudVolumes installation has been smooth and extremely easy.

As a quick refresher I’m now staring at the image below on my CloudVolumes Manager VM.

Configuring CloudVolumes Manager


I clicked on Get Started, and next up was uploading my evaluation license key. That was super easy, and clearly shows what I’m licensed for and when my evaluation expires.

CloudVolumes license

Next up was to configure Active Directory. Again, this was very simple, and I’m very glad to see that it supports LDAP over SSL. Since this is just a test environment I didn’t create a service account, but in production I would.

6-29-2013 5-39-15 PM

Next it wanted to know who should be a CloudVolumes administrator. In my test environment I selected Domain Admins, but in production I’d create a delegated group.

6-29-2013 5-41-15 PM

Next I had to configure the hypervisor credentials. Again, because this is a quick test I just used my domain admin account. In production I’d create a CloudVolumes service account and configure the proper rights in vCenter. In this case I’m using a vCenter 5.1 U1 instance. It may come as a shock to some, but I hadn’t yet configure vCenter for trusted SSL certificates (did a fresh install this morning). CloudVolumes didn’t complain about any certificate issues (which I would hope it would if the cert was self-signed).

6-29-2013 5-43-04 PM

The last configuration task is to setup the datatores. What is nice about this screen is that I can specify different datastores for the AppStacks and the writeable volumes. That’s a great feature, so that you could use data tiering. Perhaps put the AppStacks on higher speed storage for quick access, and put the writeable volumes on somewhat slower mass storage. I think they said you can also use Datastore clusters, but I didn’t have one configured to try that out.

What’s also nice on this screen is that it tells you if the datastore is local or shared among hosts. Of course if you use local storage only VMs on that host could access the AppStack or writeable volume.

6-29-2013 5-46-23 PM

A nice summary screen is shown after all of that work.

6-29-2013 5-50-36 PM

In Part 3 we will install the CloudVolumes agent in my Windows 7 64-bit VM, so we can start capturing applications. So far I haven’t run into any hitches, and the installation guide they provide walks you through the entire process with a plethora of screenshots.

CloudVolumes Pt 1: Intro and Installation

CloudVolumesLast weekend I was catching up on my RSS feeds with Feedly (great Google Reader replacement BTW), and stumbled on an article on Brian Madden’s site about a new way to enable non-persistent VDI. In that article, and accompanying video, they demoed a stack of software that I found very interesting. They discussed Atlantis Computing ILIO, CloudVolumes and Immidio.

I’m actually using ILIO in my current VDI architecture, so I was quite familiar with the performance (which is great!). But I had never heard of CloudVolumes. CloudVolumes is a startup and their v1.0 product went GA within the last two months. Immidio is somewhat similar to AppSense, and provides user environment personalization/control.

What I found particularly compelling about CloudVolumes was the ability to live add applications to running VMs (client and server OS), and just store one copy of the app that thousands of VMs could share. Big space savings! “Hot adding” apps literally appeared in seconds on the desktop when the administrator assigned them to a running VM. Check out the videos on Vimeo for demos.

What the product could enable is the use of non-persistent VDI base VMs which run from a single golden image, yet to the user seem persistent. There’s an ability for the user to install their own apps (which you can disable), and retain personalized information. So you could have a pool of non-persistent VMs, assign CloudVolume “AppStacks” to a user, and when the user gets their random VM it gets assembled on the fly with their applications and personal data (if enabled).

You can leverage native VDI products to create and maintain your VMs, such as VMware Composer and XenDesktop MCS/PVS. This is different from some competing solutions that use their own technology to assemble a desktop and bypass native VDI image management. Personally I’d lean towards native VM image management tools that VMware and Citrix provide.

Frankly, all of this sounded almost too good to be true. And the company says the technology is coming to physical computers as well, but declined to give a public timeframe when that might happen. This isn’t a VDI only solution either, as they tout providing support for server workloads such as SQL, IIS and XenApp. Instantly assign an “AppStack” to your XenApp server, so they claim, and provision dozens of apps with a few clicks.

Anyone that has worked with me knows I don’t hold back with vendors and giving candid input on how their product really sucks (a lot really do suck), or is really awesome. So I wanted to put their technology to the test and see for myself whether it really works as well as they tout. It’s only a 1.0 product, so I’ve tempered my expectations and expect a few rough edges. I shot the company over a list of 20+ questions which we discussed in a conference call this past week. Given their answers, I felt it was worth trying out in my personal lab to see if it’s spectacular or a flop. I have yet to use the product, so I’m blogging about this as I do my first install and I honestly don’t know what the end result will be.

Basic CloudVolumes Installation

I reviewed the system requirements and found that the CloudVolumes Manager was supported on Windows Server 2008 R2, vSphere 5.0 or later, and worked with IE 9, 10 and FireFox 10, 11. Support for Windows Server 2012 and Hyper-V were not available in this version. For the CloudVolumes agent it supports Windows 7 32-bit, Windows 7 64-bit, and Windows Server 2008 R2. No official fully tested support for Windows 8 or Windows Server 2012, although the company did say it “should” work but hasn’t gone through the full QA cycle. A remote SQL database is optional and only needed when deploying multiple Cloud Manager environments.

I provisioned a Windows Server 2008 R2 VM for the CloudVolumes Manager, and created two Windows 7 x64 VMs. One was a “clean” master that will be used to create the AppStacks and the other will be a target computer. At this point I didn’t want to yet stand up VMware View or XenDesktop, since I wasn’t even sure how well the product would work.

Next up, which I found a little strange, is the need to copy a .zip file to a VMware Datastore then run an unzip and convert command to create their special VMDK files. Normally I’m used to deploying OVA files to create VMs/VMDKs. But the process was easy enough, and just required SSH to be turned on the ESXi host to run the script. The result was the following directory structure on my datastore.

6-29-2013 4-30-51 PM

Now that the VMDK files were ready (NO VMs were created or harmed during this process), I moved over to my Windows Server 2008 R2 server so I could install the CloudVolumes manager.  I started the installation wizard, chose the Manager role, and it then proceeded to install SQL express (or you could point it to an existing SQL server). The installer finished without any problems, and I then launched the CloudVolumes Manager console in IE 10.


That’s it for Part 1 of my CloudVolumes installation. At this point my Windows 7 packaging VM is patching, and I un-installed my regular baked-in apps so that it’s as clean as possible. In Part 2 we configure licensing, Active Directory, vCenter credentials, and datastores. Check it out!

VMware View 5.1 Installation Part 2 – View Composer

This series includes:
VMware View 5.1 Installation Part 1 – View Connection Server

This is the second installment in the VMware View 5.1 installation and configuration series. The first part covered the installation of View connection server and its SSL certificate. This post covers the optional component, View Composer 3.0. Composer is part of the View Premier bundle, and allows you to deploy link-clones for stateless VDI.

Unlike the Connection server, the View Composer 3.0 requires a SQL database back-end. Unfortunately, View Composer does NOT support Windows authentication if the SQL server is not on the Composer server. This is disappointing, as SQL authentication is not secure and other VMware products fully support Windows authentication to SQL such as vCenter, VUM, and UMDS. I would strongly uge you configure SQL transport encryption so that the weak SQL authentication is wrapped in SSL. For some guidance on configuring SQL SSL, check out this article.

Let’s get started on installing VMware Composer 3.0:

1. If your SQL server is not co-located with your Composer 3.0 server, then make sure your SQL server allows mixed mode authentication. To verify the authentication mode open Microsoft SQL Server Management studio. In the Object Explorer right click on the SQL server name and select Properties. Then click on Security, and change the authentication mode to SQL Server and Windows Authentication mode. Restart the SQL services if you had to change the mode.

2. You need to create the View composer database. You can do this manually, or modify the script below to suit your sizing requirements and file paths. You can cut and paste the script below into the Microsoft SQL Server Management Studio, then click on Execute.

USE master
create database “SD01-vCenter Composer”
( name = ‘SD01-vCenter Composer’,
  filename = ‘K:Microsoft SQL ServerMSSQLDataSD01-vCenter_Composer.mdf’,
  size = 250MB,
  filegrowth = 25MB )
  log on
  ( name = ‘SD01-vCenter Composer log’,
    filename = ‘L:Microsoft SQL ServerMSSQLDataLogsSD01-vCenter_Composer.ldf’,
    size = 100MB,
    filegrowth = 10MB )
    COLLATE SQL_Latin1_General_CP1_CI_AS;

3. Since Composer uses SQL authentication, you need to create an account within SQL server. Pay close attention to the password policy, as it may default to require you to change password at next login, which is not what we want for a service account. Change the default database to the Composer database.

4. Next, we need to give the SQL account permissions to the Composer database. To do this we need to add a new user to the SQL database Give the SQL account db_owner permissions for the schema and database.

5. Switch over to what will be the View Composer server (could be your vCenter server, your View Composer server or a another server). Install the Microsoft SQL Native Client, then start the Composer installation and click through the wizard unitl you get to the database configuration. Click on ODBC DSN Setup then click on System DSN.

6. Click Add and on the next screen the SQL Server should be listed. Click Finish.

7. On the next screen fill in the DSN name you want to use, and the FQDN of the SQL server. Copy the name to the clipboard.

8. Select SQL Authentication then enter the SQL account credentials that you created in SQL server.

9. Change the default database to the Composer database that you created earlier.
10. Optionally configure strong SQL encryption, if you have configured your SQL server with a SSL certificate. Otherwise don’t enable encryption or the SQL client won’t be able to connect. Finish out the rest of the ODBC wizard.
11. Back in the Composer installation window, paste the DSN from the clipboard and enter the SQL account credentials.

12. If you are installing Composer on the same server as View Connection server, you should already have a SSL certificate installed if you followed my previous instructions here. If you are installing on the vCenter server or another server, then follow that link and do steps 1-7 to install a SSL certificate. Select the appropriate certificate by looking at the thumbprint.

To lookup the certificate thumbprint open a blank MMC, add the certificate snap-in for the computer account, then open the Details of the right  certificate and look for the Thumbprint value.

13. Wait for the installation to complete and reboot the server if prompted.
VMware View Composer 3.0 is now installed! The next article in this series will configure View Administrator.

XenDesktop 5.5 Resource Calculator

Of course after a weekend of creating my own spreadsheet to calculate my storage requirements for XenDesktop Andre Leibovici created a XenDesktop version of his View calculator. This is a great resource for sizing your storage, calculating IOPS, number of datastores, and other details. A sample of the fields is below.

If you are using XenDesktop MCS, this is a must-use calculator. He says a PVS version is coming as well, so if you aren’t a MCS user then check back with his site for an update.

Tips for measuring Windows 7 VDI IO Requirements

When sizing your storage subsystem for a VDI implementation, it’s extremely critical to understand how your VMs will behave and the resulting IO load. Miscalculate and you will suffer poor performance and angry users. Oversize your array and you will waste money. However, measuring your VM performance may not be as straight forward as you think.

A few months ago I posted a script here that let you dump basic IO performance stats for a VM on vSphere 4 and 5. But as you will see, the applications you load into your image and when you measure the performance has a significant impact on the collected metrics.

For my first round of tests I wanted to focus on the boot performance of Windows 7 64-bit. Booting can be one of the most taxing events (aside from full virus scans) on your VDI storage subsystem. Even if you stagger your VM boots over a few hours as a normal practice, what if you have a power outage or significant hardware failure and you need to rapidly power on hundreds of VMs? Will your storage array melt under the load? Will Windows boot so slowly that it will blue screen (hint: Windows 7 VMs should boot under 5 minutes to avoid problems.) SLAs play an important role here and you need to be mindful of them and verify they can be met.

The test environment is pretty basic and includes vSphere ESXi 5.0, XenDesktop 5.5, and Windows 7 64-bit. The IO measurements were performed over a five minute period after powering on the VM, and metrics were collected via my script. The measurements are only for boot IOs, as no user logged into the VM during the collection process. Tests were performed four times for each scenario and the results averaged. Five scenarios were tested:

  • Base Image: Windows 7 64-bit, Office 2010, VMware tools, joined to a domain
  • VDA Only: XenDesktop 5.5 Virtual Desktop Agent
  • VDA/Symantec: Citrix VDA and Symantec End Point Protection 12.1
  • Optimized: Quest vWorkspace Desktop Optimizer applied with all settings enabled except 15, 26, 27, 30; most VMware Windows 7 optimizations applied.
  • XenDesktop VM: VM created with XenDesktop 5.5 MCS from the optimized template

Drum roll for the results please!

As you can see in the table above, the base Win7 image required an average of nearly 15,000 IOs to boot. 15% of those IOs were writes, while the remainder were reads. Simply installing the XenDesktop VDA decreased the number of write IOs, but increased overall IOs by 17% over the base image. Next up is installing Symantec 12.1, and wow look at those numbers jump! 212% increase in IOs over the base image. Using the Quest and VMware recommended optimizations IOs dropped a bit, but nothing substantial.

What I found to be very interesting is what happened to the IOs when the optimized VM template was cloned by XenDesktop MCS and booted as part of a desktop pool. Zero changes were made to the VM, so the only difference is how the VM behaves when under the control of the Citrix Desktop Studio. Approximately 8000 more IOs are required during the boot process, and a lot more writes are taking place. I would not have guess that large of a delta, so this is an interesting find. The read/write ratio also drops to approximately 80/20.

So what does all of this mean? First, every environment is very unique and you should not use my results, or anyone elses, to estimate the IO load for your environment. Second, take your metrics from a provisioned VDI VM (VMware View, XenDesktop, etc.) and don’t just take measurements from your VM template. Third, booting a VM is very IO intensive and if you only size your storage for steady-state IOPS, then boot storms will cause you major headaches.

Depending on the script/method you use to gather the VM IOPS stats, VMware may not always return the read/write stats in the same fashion resulting in the same order, so you may see inverted data. From my observation this happens on a per-VM basis, even through reboots and power on/off cycles. So if your data looks odd, question it, don’t assume everything is legit.

Automate VMware VMX Security Lockdowns

When building vSphere VM templates best practices would recommend that a number of security lockdowns be incorporated into the template. There are a variety of sources for recommended lockdowns, such as the VMware vSphere 4.1 Hardening Guide. But what if you already have VMs in production that you need to lock down, or want a simple way to configure your VM template settings?

Using some PowerCLI examples I modified them and the result is the script below. The script is called with a single argument, which can be the name of a VM or a wildcard so you can do mass changes. As always, TEST, TEST, TEST! Before you lock down all the settings below, make sure you understand what they do and determine if you really want to disable the feature.

This script can be very handy for XenDesktop 5.0 deployments, as their MCS engine does not properly copy custom VMX settings from the template, so you are left with unsecured VMs. Use the wildcard feature to hit all of the VMs. Also note that many of the settings require the VM to be power cycled, not just rebooted, to read the new values.

Before you run the script you will of course need to use the connect-viserver command to establish a secure connection to vCenter or an ESX(i) host. After the connection is established you can then run the script and monitor the progress in the vCenter recent tasks pane.

# Configure client VM VMX security settings.
# Version 1.0, August 14, 2011
# Argument can be a single VM or a wildcard

$ExtraOptions = @{
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
Foreach ($Option in $ExtraOptions.GetEnumerator()) {
    $OptionValue = New-Object VMware.Vim.optionvalue
    $OptionValue.Key = $Option.Key
    $OptionValue.Value = $Option.Value
    $vmConfigSpec.extraconfig += $OptionValue

# Get all VMs per the argument

$VMs = get-VM $args[0] | get-view

foreach($vm in $vms){

vSphere 5 VDI Licensing Redux

Among the licensing kerfuffle surrounding vSphere 5.0, VDI users may have overlooked some interesting information that VMware posted about VDI and vSphere 5.0 today. Myself and other bloggers like Brian Madden have done some analysis on what vSphere 5.0 means for VDI, mostly for non-VMware products such as XenDesktop.

However, VMware’s blog post from today contains some very interesting information that I had not seen before. But before we get to that, let me quickly recap the two primary options for VDI on vSphere 5.0. (For more details see my blog post here.)

First, you can buy/use regular vSphere licenses and work within the vRAM entitlement limits. Depending on the number and size of VDI VMs, this may or may not be the best deal. Second, and new to vSphere 5.0 is the vSphere Desktop license which is sold in packs of 100 VMs for $6500. This removes the vRAM entitlement limit, but imposes other limits such as not running server OS VMs on the same hosts as VDI VMs. But overall, this is a better ROI as the per-VM costs are generally lower.

Now here’s the new information that I just learned about. According to a VMware FAQ in the blog today “Customers who purchased licenses for vSphere 4.x (or previous versions) prior to September 30, 2011 to host desktop virtualization, and hold current SnS agreements, may upgrade to vSphere 5.0 while retaining access to unlimited vRAM entitlement.”

Whoa…stop the train! Did I read that right? You can “violate” the vRAM limitations if you purchase vSphere 4.x licenses before Sept 30, 2011 for VDI? Yes, but what’s the catch? Well there are a couple, but they aren’t unreasonable. VMware states you must use a separate vCenter instance that is dedicated to VDI in order to re-purpose your vSphere 4.0 licenses for VDI and remove the vRAM caps. VMware states this is required, not optional. You also can NOT run general purpose (non-VDI) server VMs on the same hosts, but you could run VDI broker/monitoring VMs on the same hosts.

Now all the bloggers that did elaborate calculations for VDI can toss much of that work to the wind, recommend people deploy a dedicated vCenter server to manage VDI-only hosts, and be done with it. Companies just getting into VDI probably should go the vSphere Desktop SKU route, but it’s nice to know existing VDI customers aren’t left in the cold. You could need to pony up for an additional vCenter license, depending on your existing topology.

With XenDesktop in mind, this also makes some sense. Why? Who knows when Citrix will officially support vSphere 5.0 for XenDesktop. I would guess it will be several months after vSphere 5.0 code hits the streets. So you can dedicate a vCenter 4.x instance to XenDesktop, then migrate your other production servers to vSphere 5.0 on your schedule without worrying about XenDesktop impacts.

Along with the new entitlement increases announced today, I think the grandfathering of VDI only hosts into a vRAM entitlement free environment is a great gesture on VMware’s part. Thank you!

P.S. It’s not entirely clear to me if one leverages the vSphere Desktop licenses whether that also requires a separate vCenter instance or not. I suspect it does, unless there’s a way to tell vCenter a host is only for VDI usage.