VM Junkie

June 29, 2010

HP Client Virtualization Reference Architectures

Filed under: bladesystem, hp, vdi, view, vmware — Justin Emerson @ 2:36 pm

One of the great things that came out of HP Tech Forum last week was the official announcement of HP’s various reference designs around their VDI solutions. The hub at HP’s website is here, as of right now only the VMware View architecture PDF is up but the XenDesktop ones are coming (one for XenServer, the other for Hyper-V). Some aspects of this reference design were announced all the way back at VMworld 2009 and are only now coming to fruition. This is mostly because of this bad boy:

HP P4800 BladeSystem SAN

These are the building blocks of the HP P4800 Blade-based SAN solution. HP took their SAN/IQ software and loaded it directly on blade servers, which then attach to external SAS-attached storage to create a 10GBit iSCSI SAN inside the blade chassis. No 10GBit core or switches required! The P4800 is designed specifically for VDI solutions and currently is only available for that kind of solution (although there’s nothing stopping you from using it as a general purpose iSCSI SAN, it’s not recommended because the I/O patterns for VDI and normal server workloads are very different).

This is HP’s flagship VDI design. Going forward there will be more reference designs for smaller deployments, going all the way down to Micro-Branch type deployments with just two servers and no dedicated shared storage but still full redundancy. All are based on the P4000 SAN.

So I’m not trying to make this an advertisement here (although I do think it’s really cool), the reason I’m linking to this is that HP has done a ton of validation and testing around the solution and have provided some great numbers around storage requirements per user for VDI environments. They’ve broken down users into Task, Productivity, and Knowledge workers. According to their numbers, on average these will take 6, 9, and 22 IOPS respectively to support. This can be very demanding on your SAN, and the #1 hardware design related problem users run into is sizing their VDI environments based on capacity and not on performance. These sizing guidelines should help anyone looking to architect a good VDI solution.

February 2, 2010

How to fix PCoIP VRAM issue with PowerShell, t5545 supports PCoIP now

Filed under: hp, powershell, thinclients, vdi, view, vmware — Justin Emerson @ 4:46 pm

Hi folks! Been a while, but I have a couple nifty tidbits here for you all:

A lot of folks have been having trouble with getting VMware View’s PCoIP to work in higher resolutions. This is caused by your Virtual Machine not having enough VRAM to power higher resolutions (since unlike RDP, PCoIP is using the “physical” video card of your Virtual Machine, as opposed to a virtual video device like RDP). There have been several workarounds:

  • Reset (not reboot) each VM once after it’s deployed. This is because when View clones your template, it fixes the VRAM issue but the VM is already powered on so the setting change won’t take effect until you restart the VM Monitor process. Reset does this. This was outlined in this XTRAVIRT KB article.
  • The better fix is to set your template’s VRAM properly. This is easier said than done, because there are bugs in the vSphere Client’s video settings dialog box that causes some settings (like the number of monitors) not to be written to the VMX file. So the only way to do this reliably has been to add the VM has an Individual Desktop in View Manager and have it do the settings properly. This was outlined at this That’s my View blog post.

That last one is obviously ideal, but it’s a pain and a waste of time to go through creating the pool. Even worse, if you made the mistake of building a pool out of the VM already, the View Manager prevents you from using the template VM as the source for an Individual Desktop!

So I wrote this PowerShell function that, when you feed it a VM object, will correctly set the VM to have enough Video RAM and display ports for 2 Monitors, each running at the max resolution of 1920×1200.

function Set-VRamSize ($vms)
	$vmviews = $vms | Get-View

    $vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec

    $line1 = New-Object VMware.Vim.optionvalue
    $line2 = New-Object VMware.Vim.optionvalue
    $line3 = New-Object VMware.Vim.optionvalue
    $line4 = New-Object VMware.Vim.optionvalue

    $vmConfigSpec.extraconfig += $line1
	$vmConfigSpec.extraconfig += $line2
	$vmConfigSpec.extraconfig += $line3
	$vmConfigSpec.extraconfig += $line4

	$deviceSpec = New-Object VMware.Vim.VirtualDeviceConfigSpec
	$videoCard = New-Object VMware.Vim.VirtualMachineVideoCard
	$videoCard.numDisplays = 2
	$videoCard.videoRamSizeInKB = 36000
	$videoCard.Key = 500
	$deviceSpec.device += $videoCard
	$deviceSpec.operation = "edit"

	$vmConfigSpec.deviceChange += $deviceSpec
	foreach($vm in $vmviews){

The script is also available on my Sky Drive.

In related news, the HP t5545 (along with a slew of other Linux-based Thin Clients) now supports PCoIP using the new client that you can download here.

September 2, 2009

VMworld session DV3260 – Protocol Benchmarking and Comparisons

Filed under: citrix, vdi, view, vmware, vmworld — Justin Emerson @ 11:06 pm

I arrived to this session a bit late as well (noticing a theme here?) but a lot of the basics of this session were very similar to one last year on remote user experience in virtual desktops.

The gist of it is VMware has done some internal benchmarking using the PCoIP beta code (not final!) on vSphere and compared it to PortICA 2.1 – not the newest with HDX stuff, this was asked in a question pretty early and they were (deservedly) given some guff for that – and RDP (to an XP VM so only RDP 5.1).

They talked forever about their testing methodology. Essentially they tested three things:

  • A synthetic benchmark they created in-house called RPerf (which I saw last year in the similar session) that basically exercises a display protocol in as low-impact a way as possible to the underlying host (so you can measure how much CPU/memory the protocol takes and not how much CPU/RAM running the benchmark takes)
  • A 320×240, 25fps video with mixtures of different types of video that range from fairly static, pans, zooms, areas of motion on still backgrounds, and random static.
  • An AutoIT-based workload that tests actual VM performance in addition to the connection protocol.

The results were pretty favorable to PCoIP. In many cases it wasn’t the fastest, but it was never the worst. Sometimes it would barely lose to RDP in the LAN case, and barely lose to PortICA on the WAN case. It was never far behind the in any of the tests they showed results for, and in many cases was the fastest. The other big benefit was PCoIP had lower overhead in CPU and RAM than either PortICA or RDP. Tests were run entirely with the software PCoIP implementation – no hardware.

July 10, 2009

Using the HP t5545 Thin Client with VMware View

Filed under: hp, thinclients, vdi, view, vmware — Justin Emerson @ 2:22 pm

This is my first in a series of articles outlining how to setup various Thin Clients with VMware View.

One of my favorite thin clients as of late is the HP t5545. It’s a very inexpensive thin client with a lot of great features – local web browser, full VMware View support, Multimedia redirection, USB redirection, and more. Up until recently, however, getting all that to work was a bit of a challenge. (more…)

July 2, 2009

Using HP RGS with VMware View 3.1

Filed under: rgs, vdi, view, vmware, vSphere — Justin Emerson @ 3:26 pm

So as I’m sure many people are aware, VMware will be shipping a protocol in the near future (with View 4, most likely) called PC-over-IP. In the meantime, however, VMware View 3.1 has included support for HP Remote Graphics Software, which provides a similar experience today (albeit not for free). VMware hasn’t come out with tiering or pricing for View 4 yet, and since customers today may require this kind of functionality, I think it’s wise for people to test out how well it works.

First, a disclaimer. In the release notes for View 3.1, VMware states the following policy:

View Client can now use HP Remote Graphics Software (RGS) as the display protocol when connecting to HP Blade PCs, HP Workstations, and HP Blade Workstations. The connection is brokered by View Manager. HP RGS is a display protocol from HP that allows a user to access the desktop of a remote computer over a standard network. VMware View 3.1 supports HP RGS Version 5.2.5. VMware does not bundle or license HP RGS with View 3.1. Please contact HP to license a copy of HP RGS software version 5.2.5 to use with View 3.1. This release does not support HP RGS connections to virtual machines.

So be aware that VMware does not support running RGS Senders in Virtual Machines. That said, HP does support it, and the plan was prior to View 3.1’s launch to have this fully supported by both parties. From what I heard, issues at the last minute caused them to push this off. As a result, if you try to create a pool using VirtualCenter VMs (i.e. an Individual Desktop with VirtualCenter VM selected, any kind of Automated Desktop Pool, or a Manual Desktop Pool with VirtualCenter VM selected) RGS does not show as an available default protocol. (more…)

April 24, 2009

Virtualization in Windows 7: XP Mode

Filed under: hyper-v, microsoft, vdi, view, vmware — Justin Emerson @ 6:22 pm

Hopefully some of you have seen the exciting news about Microsoft’s “secret feature” in Windows 7 that’s been kept under wraps: built-in hosted virtualization of a Windows XP desktop. As an add-on feature in the Business-targeted versions of Windows 7, you can run a virtual applications in a virtual machine running Windows XP, but using seamless windows on your main desktop. This is similar to what VMware Fusion does with their “Unity” mode on Macs. This is a very interesting development, but not totally unsurprising. Running apps in a VM for compatibility is an old strategy, and it’s interesting to see Microsoft including this in their product. But what does it mean for VDI?

Once the various VDI vendors start supporting Windows 7 as a Virtual Desktop, how will XP Mode be supported? Paul’s article describes that the feature will require hardware virtualization assist technology, which could mean that it won’t work as a VM-in-a-VM…

But what if we took this a step further? Why couldn’t Microsoft (or for that matter, VMware) use this technology in a VDI solution to provide simultaneous desktops to a particular user? What if, when a user logs in, they are logged into two desktops at once, and when they launch applications, they appear on their delivered desktop? These desktops would both be hosted on the same hypervisor (ESX, Hyper-V, whatever) but delivered with one seamless desktop. And the interesting thing is, VMware could do this today with their technology by combining ESX for VM hosting and Fusion’s Unity code. And how much do you want to bet this will be a feature of Microsoft’s Remote Desktop Services in Windows Server 2008 R2?

Interesting times we live in!

April 1, 2009

Making a Thin Client on Fat Hardware: Part 2

Filed under: microsoft, vdi, view, vmware — Justin Emerson @ 6:24 pm

This is a continuation of my last blog post.

Feel free to take a look around WinFLP at this point if it’s your first time. You’ll notice that the Start Menu is a lot more spartan than a normal XP installation. This is good because that’s less junk we need to rip out. The other benefit is that the whole install in my case takes less than 700MB, and that’s including the page file!

Now that we have WinFLP installed, we need to do some basics. First, you should download and install Service Pack 3 for WinFLP. This is a different package from the standard XP SP3 one – if you try to run the wrong one it will say it’s for the wrong version. After SP3, install Windows Updates. I recommend not installing Internet Explorer 7, just because it will add to the size of your image and potentially consume more RAM. And remember, we won’t be running IE on this machine anyway once we’re done. I would also recommend turning on automatic updates, because you want these devices to be as unmanaged as possible, so letting them auto-update at 3AM will make your life easier.


March 25, 2009

Making a Thin Client on Fat Hardware: Part 1

Filed under: vdi, view, vmware — Justin Emerson @ 4:17 pm

I’m the VDI expert at the company where I work, so I do an awful lot of VMware View deployments for customers. Today I just finished my seventh of the year, and I’m scheduled to start another one on Friday.

One of the key issues that comes up in deployments is what to use for your edge device – that is, the device that sits in front of the user. A lot of customers have invested a bunch in their desktops, and while they want to get away from managing them, they’re not too keen on just throwing out everything and replacing everything with Thin Clients.

Usually this is a budgetary thing – not a technical limitation. I love Thin Clients, and I recommend them for all customers going forward. But it does make some sense to try and wring out as much life as you can from your existing hardware. So how can we utilize existing PCs in a way that makes them unmanaged devices suitable for a thin client-like deployment? I have several solutions for customers that I discuss, and I thought I’d share some of them here.


January 29, 2009

Installable View Client hangs after connection

Filed under: vdi, view, vmware — Justin Emerson @ 11:13 am

I had been running into this problem during the View Manager 3 Beta and it was still hanging around, albeit in a less annoying fashion in the final version. I finally figured out what was causing this: the ThinPrint services.

After connecting to your Virtual Desktop using the installable View Client, you’ll log in, the system will start its post-logon processes, and then will just sit there and hang for sometimes a good 15 to 20 seconds. After that, everything will be fine. Why?

During this period, the ThinPrint services in the VM start up and try to connect to all the local printers on your machine. If you’re connecting from a system with 3+ local printers (local meaning not network print queues, i.e. TCP/IP port printers count as local) this process can take a very long time. It gets even worse if the printer you have locally attached is a TCP/IP printer which is missing (i.e. your home printer and you’re in the office).

Solution? Delete unnecessary printers on the system you’re connecting from, or when you install the View Client do not install the ThinPrint component.

January 20, 2009

VMware View article at BrianMadden

Filed under: thinapp, vdi, vmware — Justin Emerson @ 1:27 pm

Roland van der Kruk over at BrianMadden.com has been writing up some articles about VMware View, his latest one has some conclusions at the end which I wanted to take issue with:

  1. Providing linked clones to users that have full control to the system, resulting in user initiated changes to the OS like copying data, removing it, etc., will end up in a system disk that eventually has a bigger size than if the OS was provided to the user without the linked cloning technology.
    This is not the case. The way a linked-disk in VMware ESX works is that the linked disk can only grow to the maximum size of the hard disk it was based off of. So a 20GB system disk fully provisioned is 20GB, and the maximum size of a thin-provisioned disk is 20GB. If Roland would like to test this, just use IOMeter to write a giant file to your system disk and see the size increase and stop.
    At the same time, you can specify at what size to automatically recompose a VM, so if it grows over, say 10GB you can automatically recompose it.
  2. If a View Administrator decided to refresh the OS because he added some hotfixes or extra software, all user modifications to the OS are deleted. In fact the System Disk is simply deleted and a new linked clone is generated off the new state of the ‘master image’.
    This is correct, but this is clearly outlined in the documentation. The purpose of the User Data Disk (or just using Roaming Profiles of some kind) is to keep the user’s profile persistent between Recompositions. As for how you handle Applications, see below.
  3. What ‘Persistent desktop’ actually means is that the state of a disk provided by a View Administrator is ‘persistent’. A desktop can be made persistent by recomposing or (scheduled) refreshing the deployed linked clones, resulting in exactly the state that a View Administrators expects it to be. From the view of end users using Linked Cloned Desktops, no persistence can actually be guaranteed, because all user actions will be undone by ‘Desktop Refresh’ or ‘Desktop Recompose’.
    This is only half-true. Any persistence made in user space are guaranteed by the recomposition. If it’s a change made to HKEY_CURRENT_USER, or to anything in Documents and Settings, it will be persistent across recomposition or refreshes.
  4. As soon as user modifications to the System Disk need to be persistent, no linked clone technology should be used. Instead, 1-on-1 desktops need to be provided, in which deployment tools like SCCM or Altiris will have to be available to maintain the system.
    This exact reason is why you cannot purchase View Composer without purchasing ThinApp. In order to make sure applications persist between rebuilds, as well as application settings and such, you need to use ThinApp (or at least some kind of Application Virtualization technology).

View Composer deployments do not make sense unless the base operating system is disposable. You have 4 components in any desktop:

The Desktop Blob

The Desktop Blob

User Data is handled by Roaming Profiles or the User Data Disk. Applications need to be either disposable (you can throw them out because they are stateless) or through App Virtualization. The hardware is just a VM hardware which is always identical or easily changeable. If those three things are taken care of, the OS itself is disposable, so a desktop recomposition should have no negative effects.

I will agree that View Composer is not perfect, but I think it’s come closest to the best possible solution available so far. That being said, you can ignore the whole recomposition options entirely and just use thin provisioned desktops, but they will grow over time just due to the way Windows writes to the filesystem.

On the upside, there is a really great session from VMworld which talks about performance and best practices for VDI which contains information on modifications you can make to a default Windows XP installation to reduce the amount of space that will be used by the OS at idle. Check out Slide 39 on the PDF.

Create a free website or blog at WordPress.com.