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 :)
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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
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.
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…