Geek Week VDI Day 2: VMware View 4 Summary

Day 2 of Geek Week VDI was actually our first day of filming, and after assembling the room until midnight the night before we were hoping everything worked well enough to not stay until midnight again.

This post, like all five Geek Week: VDI wrap-up posts, was co-written by Brian & Gabe.

Day 2 of Geek Week VDI was actually our first day of filming, and after assembling the room until midnight the night before we were hoping everything worked well enough to not stay until midnight again (Gabe got up at 6:00 AM Omaha time to fly to San Francisco where Brian picked him up and took him to the office to start working. For those keeping score at home, that's 6:00 AM to 2:00 AM Central time).  We sort of looked at it as an extended live demo, and we know how well those tend go :)

VMware View core component installation

We kicked off the day installing the core components of VMware View on to our lab servers. We'd pre-installed ESX the night before, and we continued using our supporting infrastructure on the Hyper-V server.

First, we installed View Composer, which is what adds linked clone capabilities to vCenter and ESX. Since we already had a SQL server set up in the lab, installation was pretty straightforward.  There is about five minutes of waiting, which we found out was because the installer unpacks the .Net framework (even if it's already installed).  After that, we installed the View Connection Server which uses ADAM not as an offline copy of AD, but as an LDAP repository for communications between View Connection Servers. The install is a simple one, and the configuration comes later via the View Manager web interface.

Before getting to View Manager configuration, we needed to install the vSphere client, which isn't any different when it comes to VMware View.  It's used to create the base VM, but the desktops themselves are managed from the View Manager interface. After the vSphere client was installed, we were ready to go installing our base desktop.

We began installing Windows XP (Windows 7 is not yet supported in VMware View), and while we were waiting, we learned that VMware's Mike Coleman is directly involved with two things very near and dear to the tech community, both of which took place when he worked for Microsoft. First, Mike was the guy that actually wrote the text that displays while you're installing Windows XP--the stuff about how Windows XP makes your life better and so on.  That by itself is pretty cool, but then we learned that he's also the person driving the demonstration in the famous, pre-YouTube era video of Bill Gates in an earthquake! Both of those things from one guy--who's now in our lab showing us VMware View! The odds of that have to be somewhere between finding true love on a blind date and, I don't know, having to evacuate more than one industry event due to a fire alarm (tune in Thursday for that!).

After installing XP, we installed both VMware Tools and the View Agent. The VMware Tools package is the same one that's used on any other VMware Virtual Machine. The View Agent is what hooks the machine to VMware View and enables all the View-specific add-ons like PC over IP, USB redirection, and so on. After that, we took our first, baseline snapshot of the Windows XP VM. Snapshots are View's method of version control, and you can use them to fork a base image into separate images or roll back changes in case something goes awry. It's a simple process, done in vCenter, and the desktop is ready to be provisioned. All that's left before that is to configure View Manager.  This process involves lots of little steps, like pointing View Manager to the vCenter server, entering default domain credentials for joining desktops to the domain, licensing, authentication settings, administrators, and so on.

When we finished configuring View Manager, we were technically able to broker desktops.  We still had a little bit of config left to do in order to create pools of desktops, though.  It seems like a lot of steps, but it went by surprisingly fast for us. I don't know if we kept official time, but I recall us both being pretty surprised how far we'd made it by this point.

Right off the bat when creating desktop pools, Todd recommended creating a single-desktop pool (more accurately: provisioning an "Individual Desktop") so that you can work out any kinks before pushing that desktop out to many people. During pool configuration, you configure disconnect settings, default display protocol (PCoIP or RDP), number of monitors and max resolution (which dictates how much video memory is allocated to the VM), and Flash limiters, which are used with RDP to limit the quality of Flash content. The last thing that has to be done is called "Entitlement," which is nothing more than granting certain users or groups access to use a desktop pool.

As we went to test our single desktop pool, we learned from Todd that the web client doesn't fully support PCoIP at the moment, which is good to know if you're currently working with View 4 and can't figure out why things aren't working right.  If you install the full View client, you'll get the full PCoIP implementation.  Other things that the full Windows client enables that the web client does not are: USB redirection drivers and a chained GINA so that it can scrape credentials and pass them to the virtual desktop. The initial connection worked, but didn't connect full screen. It turns out you have to power the virtual machine down completely in vCenter in order to get it to re-read the resolution and video memory settings that were configured in View Manager.  Warm reboots aren't enough, which is all we'd been doing at that point.  Thankfully, Todd knew that right off the bat, and we were instantly glad that we invited the vendors to come on site with us :)

At this point, it was 11:30 in the morning.  We'd spent less than three hours in the lab, and we were already provisioning desktops!

VMware View Composer and provisioning desktops

Now that we've verified our desktop is working, it's time to make some copies of it to create a "real" desktop pool. The process is somewhat similar to the one used with creating our "Individual Desktop" pool from before, but there are quite a few new options.

To start, we have de-provision our single desktop base image by deleting it from View Manager (which leaves the actual image intact).  After that, we can create an Automated Desktop Pool, which will allow us to see machines built on demand.  Here we're presented with an option to configure a persistent or a non-persistent pool. At this stage in the game, "persistent" means that if a users is provisioned VM #3 at their first logon, they'll always be sent to VM #3. "Non-persistent," on the other hand, means that each time they log on, they'll be assigned to the next available VM. This is just from a VM usage standpoint, though, not from a data standpoint. Users environments are treated the same in both situations. We chose non-persistent because it's more interesting to watch.

The next step we had is to enable Linked Clones, which uses a single disk image combined with delta files to compose each user's desktop. Without Linked Clones, we'd have a situation where each desktop would be a full copy of the base VM, which will consume enormous amounts of disk space, comparatively speaking. So, with Linked Clones on, if we publish 100 10GB desktops, we'll have a single, 10 GB image and 100 small delta files. With Linked Clones off in the same situation, we'd see 100 10GB images for a total of 1 TB of storage!

Most of the pool creation process is similar to what we saw before, but there are some differences (these are only a few of the more interesting ones):

  • We're able to select how many desktops we can create in our pool as well as what these machines will be called in the domain.
  • We can configure how many desktops pre-started waiting for connections. This is just like what we saw with the Citrix solution yesterday, and it helps to speed up logons during busy times.
  • You're able to select the image you want to use, as well as which snapshot of that image you want to use. Later, this snapshot will be flattened into the base image to create a single image on one file, rather than a ton of files that are required to compose a single base desktop
  • Virtual machine file location and hosts that it will run on
  • Storage planning (overcommit), which tells View how to manage disk space and estimate how much space will be consumed by the single image and the delta files.
  • QuickPrep settings - QuickPrep is what View uses to inject domain membership information into virtual machines at runtime, including the container in AD where the VM's should belong. This is new for View 4.  Prior versions required you to spin up each VM once in order to get it properly joined to the domain.

Now, the virtual machines are being configured, and while we were waiting, we learned from Todd that the bulk of the work is being done by the ESX servers. View Manager essentially tells vCenter what to do on a high level, and vCenter relays that to the ESX host in the form of more granular commands for it to execute in order to create the virtual machines.

Updating the master disk image

The last thing we did besides the user experience testing is to make a change to the base image in order to push out a change. In this case, we chose to Adobe Reader.  To do this, we created a replica of the base image and took a snapshot of it. Then we installed Adobe reader, took another snapshot, and recomposed the snapshots and the base image replica into a new base image for the desktop pool. The process is actually pretty simple, and View will actually clean up anything left over so that there's not remnants of old replicas laying around.

The user experience

The last thing for the day with VMware is the user experience testing, and for that we have to lean heavily on the video. In case the video doesn't show it well enough in graphics, we should talk a little about the build to lossless compression technology that PCoIP uses. The idea behind it is that, when in a WAN situation, the user will see what looks like a highly compressed JPEG as their desktop, and as time goes by it builds itself up to a "normal" looking interface. There's two ways to describe it. First is to think of a 50% compressed JPEG, gradually building up incrementally to a full quality JPEG. The other is to think of a progressive GIF image that slowly builds itself up to it's normal appearance. PCoIP's build to lossless resembles both of those situations, but in a far more usable way. 

You will be able to see it pretty well in the tests we did with Microsoft Word. Scrolling around in a document, build to lossless is quite visible in the text.

The Bottom Line

From Gabe:

This day was great for me.  It was the first day of Geek Week, and it went of really, really well.  I was most surprised that we had the entire thing up and running less than three hours. Based on the 25 hours or so that my laptop has spent encoding just five videos, we could've installed VMware View eight times! Part of the reason the setup didn't take as long (besides the fact that View is made up of purpose-built components and not a hodge-podge of things that just so happen to work together) is that there are simply less moving parts. View doesn't do as much as some of the other solutions out there. It doesn't broker SBC connections along with desktops, and it only supports ESX for the backend. If you don't want to broker SBC or use another hypervisor, then the simplicity is elegant, but if your environment calls for more than what View has to offer, the simplicity becomes a setback.

Regarding the user experience, I'm happy to see that PCoIP provides a quality user experience, and it's encouraging to see how well it performed on the WAN. The "build to lossless" feature was really cool to watch, and I hope it shows up well in the user experience videos. If not, we might have to try setting up a DVI capture or high FPS screen recording to get a good look at it. I think it's the only thing that made the WAN useable. Next Geek Week might be protocol-oriented (either that or Client Hypervisors are my two favorite ideas), and if it is, we can dig deeper into what the protocol is doing to the VM, host, client, and network.

From Brian:

VMware is one of two vendors that really surprised me this week. (Check back later in the week to learn who the other one was!) I think before Geek Week, I had two main biases against them (both things you’ve all heard about before). First, I was afraid that since their history is server virtualization and they think “a VM is a VM is a VM,” I was nervous that View would have a server-centric approach to desktops and that stuff View Composer wouldn’t make sense for desktop people. Second, I was skeptical that PC-over-IP would be any good, especially over the WAN. I thought the build-to-lossless would be annoying and I’m surprised VMware decided to take on Citrix in the protocol space.
As you saw in the videos, the reality is that View was very straightforward to install. I was surprised at how easy View Composer was, and I liked that I could do everything I needed to do via the View Management Console. PC-over-IP definitely surprised me with the fact that it was an overall decent experience—both on the LAN and the WAN—and I confidently say it passes the “good enough” test.
Of course our Geek Week: VDI testing only scratched the surface of these products, and there’s no doubt that XenDesktop has more features than View. But when it comes to setup and simplicity, I’ll take View over XenDesktop any day. The question is whether View is too simple. No Terminal Server support. No blade support for PC-over-IP. No remote assistance for users. No choice of hypervisors. Really it’s like View is a giant “easy button.” If you’re lucky enough that your exact needs match its exact capabilities, then you’ve got a simple winner. But if you need more than View can do, the search goes on…

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

As a conclusion, View4 & PCoIP is nowhere near of *working* in WAN. How many times didn't i hear "build to lossless", "quite good".

No! It's not quite good. It's unusable for any WAN case. Period.

Seriously guys. Is this the kind of experience anyone in his/her right mnd would enforce on a fellow human being?

For info, same goes for all vendors. While the varying grades of hardship differ, the overall pain remains. VDI over WAN is, as of now, is an utter failure and all encompassing nightmare...


Kimmo, Brian and Gabe basically found very different conclusions from yours.


While the TS support in View is crappy, isn't those technologies overlapping ?

Why to setup a complex TS environment, requiring many more servers, if you can either install them directly on the gold image, of isolate/package using ThinApp ?

VDI eliminates app integration issues, so, installing some apps on the image, let's say, when ThinApp does not work, is very acceptable.

Also, the 'no choice of hypervisor' will really be a problem at all ? I cannot imagine someone saying , "hey, we need to use Hyper-V, since it is our standard for virtualization" :-D

XenDesktop supports ESX because ESX is everywhere, not supporting ESX would severely limit the product.

Blade PCs are a niche, not too much common to see them everywhere.

I think in the end, IMO the majority of customers will be "lucky enough that your exact needs match its exact capabilities" , while a few users cases will need TS/XenApp, BladePCs, or other hypervisors (and Citrix will have a clear advantage on those).


@ VMGuy - I'm courious about where you are going with this:

"Why to setup a complex TS environment, requiring many more servers, if you can either install them directly on the gold image, of isolate/package using ThinApp ? "

There's a really simple reason for this, $$$$.  The scalability difference between RDSH and VDI is undeniable. Typical VDI hosts get 50-100 CCU and the same host typically gets 2-3X users if using a shared OS like 2008 R2 with RDSH.  So using RDSH instead of VDI, where you can will typically reduce the number of required servers by 2/3 and require way less storage.

Let's look at some facts:

1.  With 2008 or 2008 R2, Application Virtualization is part of the RDS CAL.

2.  VDA/VECD is not required.

3.  SAN Storage is not required.

4.  If SAN Storage is used, one is looking at ~ 100GB of space for a single host.  

5.  No dedup, LinkedClones, DiffDisks...required.  It's non-redundant out of the box.  Install an app, or deliver it with App-V and it's there for everyone.  This has been your "golden image" technology for the past 15 years.

There are very valid use cases for HVD/VDI, i.e. remote developers, AppCompat, Vendor Support, USB Device Support, Multi-security domain support, user installed apps, but these are the vast minority of use cases.

I won't go into the complexity statement, as if you've deployed several thousand virtuyal desktops and you think that's less complex than TS, I'd say you've never managed TS.  They are different.  Different use cases, different skill sets to manage them, different TCO.

I once had a a customer say, "wow, these new 19" LCD monitors are fantastic, why can't we get these for everyone, as those 15" LCD monitors are aweful".

I said, "who's budget", and she pointed down the hallway to the CIO's office.  She said, "what's the big deal, they're only $300, and they're so pretty".  I then said, "you know, you have 1500 workstations with 15" monitors", so that "cool" thing you think everyone should have will cost your company nearly half a million dollars to procure.  Do you think the CIO is going to agree with you?"  She replied "maybe we shouldn't mention this new monitor I ordered for myself".

All users are not the same.  All use cases are not the same.  It's undeniable that VDI does some things that RDSH doesn't, but so is the fact that it costs a lot more.  This is exactly why most companies choose to use both, along with some rich PCs, as no one solution works for everyone within the available budget.



I think I was not clear enough. I fully agree with your statements. But my point was not TS versus VDI. I know TS is cheaper, and less complex.

My point is: If for whatever reason a customer wants a VDI solution, why to have in parallel a XenApp farm to deliver the apps to those virtual desktops ? That would make the solution incredibly complex and expensive (even if the XenApp licenses are bundled on XenDesktop).

This is because Brian pointed that as a missing feature on VMware View, and that depends on the viewpoint. I tend to think those technologies overlap, and since you choose one that fulfill you needs, stay on it !


@VMGuy - excuse my french but for me you enpict a fan boy right down to the essense of the term.

Please don't give me "Brian and Gabe basically found very different conclusions from yours", I'm not entirerly certain that thse both gentlemen want to be diminiched to advisorys of your obvious agenda. Nonetheless my opinions are my own and not reliant on anybody else.

Happy easter / kimmo


Let's see, Brian wrote:

"PC-over-IP definitely surprised me with the fact that it was an overall decent experience—both on the LAN and the WAN"

You wrote: "No! It's not quite good. It's unusable for any WAN case. Period."

Looks to me very different conclusions.


Jesus VMFanboy pushing hors$hit again. PCoIP does not work period in a WAN situation with multiple users in a branch office. That's real world, which does not have infinite BW. Add to that remote access and it's awful. If you believe PCoIP works you are naive and will enjoy the hype on the VMWare truck!


PCoIP is certainly a great display protocol.  However in some scenarios of slow remote connections (like over certain WANs) there may be issues where PCoIP doesn't function quite as well.  In those cases, you can complement the VMware View deployment with Ericom Blaze, a software-based RDP acceleration and compression product that provides improved performance over WANs. Besides delivering higher frame rates and reducing screen freezes and choppiness, Blaze accelerates RDP performance by up to 10-25 times, while significantly reducing network bandwidth consumption over low-bandwidth/high latency connections.

You can use VMware View with PCoIP for your LAN and fast WAN users, and at the same time use VMware View with Blaze over RDP for your slow WAN users.  This combined solution can provide enhanced performance in both types of environments, letting you get the best out of VMware View for your users.

Read more about Blaze and download a free evaluation at: