VM Junkie

March 9, 2011

View Client for iPad out – limitatons & caveats

Filed under: view, vmware — Justin Emerson @ 8:55 am

So a couple posts ago you may recall I made the following statement:

There’s also a few cool bits under the hood that make it work a bit better with things like Teradici’s new firmware 3.3 for their zero clients, as well as some enhancements that will become obvious in the next month or so when another client becomes available (which I’m not sure I can talk about publicly in detail).

What I was referring to, as you may now guess, is enhancements that make the iPad client work. Please note that the iPad client (which has been posted about many times in the last few hours alone since it launched, even on mainstream tech blogs like Engadget) only supports View Agents running View 4.6 or newer. Also, while it does support the Security Server, because the iPad client is PCoIP only (no RDP support) it means if you want to avoid using a VPN on your iPad you will also need the new View 4.6 security server.

Another important note is that this signals the first time that you have seen a View client which is separately released from a particular version of View. The version number on the iPad client is 1.0.1 – not 4.6. This is the start of a larger trend around View client releases: you should see them become more decoupled from the releases of the View Manager infrastructure components.

Now I just wish I had an iPad. =)


March 7, 2011

Windows 7 SP1 support in View

Filed under: view, vmware — Justin Emerson @ 9:12 am

Some updates for those on the bleeding edge.

When VMware first published the release notes for View 4.6, the following line was in the What’s New section:

  • Experimental support for Microsoft Windows 7 SP1 RC operating systems

Since that time, the release notes have been updated to the following:

  • Support for Microsoft Windows 7 SP1 operating systems

This is a very important change. When the View 4.6 bits shipped and the release notes were published, Windows 7 SP1 was not fully GA (only limited availability) and therefore the official support statement had to be experimental. Once the bits were generally available, VMware updated the release notes to confirm full support. I have also personally confirmed with the View Product Manager that Windows 7 SP1 is fully supported.

Also of note: while View 4.5 does not officially support Windows 7 SP1, this KB article outlines some View 4.5 patches which will make it work. Note that while it does not explicitly call out Windows 7 SP1, the incompatibility between SP1 and View 4.5 is the same – these patches are rolled up into SP1 and therefore SP1 has this issue. Note that there are some limitations around Local Mode, however.

February 25, 2011

View 4.6 and ThinApp 4.6.1 are out!

Filed under: thinapp, view, vmware — Justin Emerson @ 1:29 am

Good news, everyone!

After an agonizing wait for some of us in the know, View 4.6 is finally out as of an hour ago. This is not a super-huge release, but rather an incremental release that fixes a lot of bugs, but does add a couple pretty important features:

  • The Security Server can now proxy PCoIP connections. This was semi-announced as a feature back when Mark Benson made this post on the Office of the CTO blog.
  • (Experimental) Windows 7 SP1 support. Note that View 4.5 is not compatible with Windows 7 SP1, so don’t go deploying it to all your View desktops before upgrading your View Agents to 4.6!
  • USB improvements. Now (if you’re crazy) you can sync iPods over View’s USB redirection.

There’s also a few cool bits under the hood that make it work a bit better with things like Teradici’s new firmware 3.3 for their zero clients, as well as some enhancements that will become obvious in the next month or so when another client becomes available (which I’m not sure I can talk about publicly in detail).

So with that out of the way, what’s missing? Unfortunately, profile integration, such as any technology from the RTO acquisition, is still not included in View 4.6. We can only hope in the meantime that when the next major version of View comes out, we will see it or something like it included. In the interim, we’ll have to rely on solutions like LiquidwareLabs ProfileUnity, AppSense, or others.

And also as per usual, the new View release is accompanied by a release of VMware ThinApp, although in this case an even more minor update from 4.6 to 4.6.1. Primarily this release adds better support for Office 2010 and virtualized IE7 and IE8, but you can read the official VMware blog posting about it here.

September 9, 2010

View 4.5 is out – Premier includes vShield Endpoint

Filed under: view, vmware — Justin Emerson @ 8:40 pm

Yes, View 4.5 is out, you can read more about it here on the official View blog. But there’s something important I wanted to point out that a lot of people have so far overlooked, probably because I don’t think VMware ever announced they were doing this until now. At least this is the first I heard of it, but maybe that’s not saying much.

View 4.5 Premier edition (the good one) includes vShield Endpoint protection for all your desktop VMs. This means there is now AntiVirus and Malware protection offload included with the product at no additional charge. If you already own View Premier you now get this for free. That’s a big deal!

Now that the bits are out and I can actually start posting stuff about it hopefully you’ll see some more content around View 4.5 in the coming days.

August 31, 2010

VMworld session DV7907: View Reference Architecture

Filed under: Uncategorized, view, vmworld — Justin Emerson @ 12:34 pm

Session is around updating the reference architecture for View 4.0 to View 4.5.

  • Goal of View is to delivery Consumer Cloud experience for the Enterprise.
  • Goal of the 4.0 reference architecture was to simulate a realistic desktop workload, validate 2,048 users.
  • Session turning into a pitch for UCS very quickly…
  • Now they’re off to talk about RAWC, which is really old news. New version of RAWC supports simulating workloads on Win7. Still can only simulate a preselected set of apps, no custom app load testing. You can learn more about rock on its Youtube channel.
  • View 4 reference architecture was run on UCS, CX4, vSphere 4.0 and WinXP SP3.
  • Just released – Win7 optimization guide, includes a BAT file that optimizes the VM for you! Already found it here.
  • Going through all the stuff they had to do to the Storage to make it perform. Wouldn’t it have been nice if it was on virtualized storage and you didn’t have to worry about RAID groups and all that crap? 🙂
  • View 4.0 Reference architecture they got up to 16VMs/core. I think this is super aggressive and I don’t recommend customers size for this #.
  • Finally we get to View 4.5 stuff! Talking about the new Tiered storage capabilities of View 4.5
  • They’re putting SSDs in each physical server… again more Cisco specific stuff. I think sticking SSDs in every server drives up the cost too much. Plus wouldn’t it kill vMotion.
  • They did the View 4.5 test with a single non-persistent pool.
  • They see CPU being a bottleneck on optimized Win7 32b deployments… but they were only giving each Win7 VM 1GB of RAM.
  • During the Q&A, asked about HA/VMotion. This reference architecture doesn’t allow for VMotion or HA. And Non-Persistent pools require some sort of 3rd party profile management to make it work. If you want to take a system down you’ll have to do it after hours. Don’t like it! I’ll stick with SANs to give full functionality instead of neutering 1/2 the Enterprise functionality.

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.

March 3, 2010

Anatomy of the DevTap bug (PC over IP)

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

Hello all, thought I’d post a little interesting info here.

In ESX 4.0 update 1 (with no patches), there is an interesting bug that affects PCoIP connections on View. I thought I’d illuminate a little information about this bug as I think it does a good job of illustrating how the PCoIP software sender works with VMware’s underlying hypervisor.

In VMware ESX 3.5 Update 4 and vSphere 4.0 Update 1, there is a virtual device that’s part of each VM’s hardware called DevTap. DevTap is a way for other processes to “tap” into the device layer – specifically video and audio. In the case of PCoIP, it’s used to do screen scraping (for the PCoIP sender) as well as audio. You can see an example of this by looking at Device Manager when you connect to a VM with PCoIP:

The audio stuff isn’t terribly interesting, but what it does with the information attained from the video card is.

As described in Scott Davis’s blog article here, PCoIP will use different kinds of codecs for different types of objects. It will also prioritize things like the currently selected window. But how does it obtain this information?

Most remote display protocols either run in the Presentation layer or they scrape data directly from the video buffer. An example of the former is RDP – it reads the data that is supposed to be drawn and draws it to a virtual video device. This is why you can run RDP in a higher resolution than the physical video card on the machine could. An example of the latter would be VNC, which reads the data that’s in the video card’s frame buffer and sends that over the wire. RDP’s advantage in this case is it gets data earlier on in the drawing process, so it can be more descriptive with lines and shapes (write text here, draw a circle here) whereas VNC can only go by what’s already been drawn, so it has to work with bitmaps and images, not instructions on what to draw. On the other hand, because VNC is only scraping the screen, it’s completely platform independent. That’s why you can get VNC Servers for Windows, MAC, Linux… practically anything.

PCoIP is somewhere in the middle. The actual protocol itself was originally a pure hardware solution, so at its core PCoIP is a screen scraping solution like VNC. The difference is PCoIP has many different algorithms it can use to encode different parts of the screen, and so there is a lot of work that’s done to figure out what the best codec to use it for a particular region of the screen. Again, see the linked blog article above for details on this. VMware’s software implementation, though, is Windows only and will not work except on a Virtual Machine running on ESX 3.5u4+ or 4.0u1+. This is because the screen scraping is actually being given “hints” farther up in the stack. One of the interesting behaviors of PCoIP is that it’s aware of where you mouse cursor is and what your selected window is. This means that the window in focus will get updates faster and at a higher priority than background elements. How does it know what you’re doing? That’s from the hints being sent to the PCoIP sender from the View Agent, which does have information from the Presentation Layer.

After it gets the hints and knows where stuff is, the PCoIP sender service then accesses the DevTap device to read the contents of the video buffer. This has the effect of being able to see what’s coming out of the “virtual monitor” in a way that’s more efficient than reading directly from the frame buffer. This is why the software PCoIP sender is only available in a VM – because it needs the DevTap device to access the virtual monitor.

Once the PCoIP connection is made, a “monitor blanking” command is sent to the virtual monitor so that someone with the vSphere client can’t snoop on someone’s virtual machine. Unfortunately, this is where the bug comes in. Sometimes, when the monitor blanking command is issued, or when you resize your PCoIP window and it changes the resolution of the VM, the DevTap device crashes. This is so bad that the only way to recover from it is to kill the VM’s process, or reboot the ESX host. Resetting or Powering off the VM will hang at 95%, as outlined in this forum thread. A user in that thread recently said that the newest patches for ESX 4.0u1 in January may fix this bug, however I’ve seen it occur after installing this patch, and indeed at VMware Partner Exchange they were still fighting this bug in the View lab sessions, so I’m not sure if it’s resolved yet. It is, however, a very rare occurrence so I wouldn’t lose much sleep over it. I just thought that outlining the cause of this bug would be good opportunity to explain some of the reasons why PCoIP is so clever.

DISCLAIMER: I am not a VMware engineer. Some of this information has been obtained from sources in bits and pieces, and some of it was just from deduction and putting the pieces together. The definitive source for all info on PCoIP is Warren Ponder, whose blog is here.

UPDATE: And as of today (March 3rd) VMware JUST release a series of patches for ESX and ESXi 4.0, one of which fixes this particular bug. From the KB article:

Changing the resolution of the guest operating system over a PCoIP connection (desktops managed by View 4.0) might cause the virtual machine to stop responding.
Symptoms: The following symptoms might be visible:

  • When you try to connect to the virtual machine through a vCenter Server console, a black screen appears with the Unable to connect to MKS: vmx connection handshake failed for vmfs {VM Path} message.
  • Performance graphs for CPU and memory usage in vCenter Server drop to 0.
  • Virtual machines cannot be powered off or restarted.

So get patchin’ folks!

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.

December 10, 2009

View 4 & PCoIP – a few problems

Filed under: view, vmware, vSphere — Justin Emerson @ 9:15 pm

So I’ve been doing my first customer deployment of View 4 lately, and there have been quite a few gotchas that I’ve noticed so far…

The first, and biggest, is that I just can’t get View Composer to reliably clone machines. About 50% of the time, the VM will have an Error in View Manager that says “View Composer agent initialization state error (6): Unknown failure (waited 0 seconds) and the only way to fix it is to reset the VM manually or refresh it. I ran into similar issues during the Beta and what I’m seeing here is pretty nasty. It’s a very similar issue to what is outlined in this VMware KB article. However, the resolution in the KB article has so far not fixed the issue for this customer. The error will not clear on its own, and can even reoccur after a reset.

We’ve also had several issues with PCoIP so far. The most critical is we’ve had virtual machines lock up so bad after trying to connect to them with PCoIP that I had to kill the VM from the service console with kill -9. Other issues are that PCoIP doesn’t work with ThinPrint (so you get no printer redirection except through USB redirection), no folder redirection (which was to be somewhat expected since that’s provided by RDP), and the biggest issue is no tunneled connections. Much like RGS connections, PCoIP connections go directly to the VM. This has important implications, such as the Security Server is now useless except for RDP.

While I definitely think View 4 is a HUGE step forward from View 3, it still has a lot of things I think are pretty rough edges. Add that to a lot of the issues with vSphere Update 1 (well documented by Mike Laverick) and it looks to me like View 4 really was released too soon. That said, I think it’s a great start and bodes really well for the direction VMware is headed.

View Composer agent initialization state error (6): Unknown failure (waited 0 seconds)

December 9, 2009

Fix for LSI Logic Issue

Filed under: view, vmware — Justin Emerson @ 8:00 am

It appears that those having the issue I described in my previous blog post (myself included) were experiencing this issue because we were using a newer, unsigned driver for the LSI Logic controller. VMware actually recommends (in this KB article) that you use the WHQL driver which is available here. Doing so fixes the issue. Thanks to several folks in this VMware Communities thread for the resolution!

Older Posts »

Blog at WordPress.com.