My topic of choice was the same as the title for this post Windows 7 IOPS for VDI: Deep Dive.  As I hate having lots of text on slides when presenting I created an accompanying document which I have now made available for download here:

Windows 7 IOPS for VDI: Deep Dive (Short form)

Please comment if you have any requests for more testing or a particular update to the document.

If for any reason the above link doesn’t work here is a mirror.

Installation

Installing the XenClient host software was very easy and went exactly as it was supposed to, although there is no option to slip the hypervisor under the OS, or backup and retrieve the OS, so as yet, no in place upgrades are possible.  Whether it is possible to use XenConvert or Sysinternals disk2vhd to create a VHD, load it into the Synchonizer server and redeploy I don’t know, it’s certainly not a documented feature (edit: See comments).

There is two parts to the host installation software, though both install as one, the Xen hypervisor itself and what Citrix call the Citrix Receiver, now this is what they usually call their client software, so presumably it will act much more like it’s namesake later.

Installing the Synchonizer server was equally as simple, just import the xva into a XenServer and spend a couple of minutes configuring it as per the documentation.  I’m not surprised that there isn’t an option to use Hyper-V or ESX at the moment, although Citrix have shown that they are willing to port their virtual appliances to other hypervisors, so I wouldn’t be surprised to see the virtual appliances arrive on competing hypervisor products at some point.  At this point I would recommend a little bit of further configuration, which I will cover below in the XenClient with Synchronizer section.

Guest Installation

Creating the VM’s is again very simple, pick your OS, RAM and vCPU’s and that’s about it.  One issue with creating the VM is that the wireless card can only be used in shared mode, while the wired card can be used in the more traditional shared, bridged or host configuration.  This means that you can only use NAT with the wireless card, this could of course cause issues.  For instance you can’t configure an extra IP address on the card.  I get the feeling that getting the wireless networking to work was one of the harder things that Citrix had to do.

So far, supported Guests are limited to Windows 32 bit client operating systems, Windows XP, Vista, and Win 7 32-bit.  I decided to install Windows 7.  There is no option to mount an iso file and I had to search around to find a burner to produce the installation disc.  Windows 7 installed without a problem, though I felt perhaps a little slowly.  This may just have been a case of a watched pot, but I think without the guest tools installed, this would make sense.

The XenClient iso is automatically mounted into the operating system on boot, although this is the only iso file you can mount using the hypervisor.  The installation of the XenClient tools was very temperamental, either giving errors or missing installing the audio device. The installation takes a while longer than I’m used to, but I suppose it’s doing a lot more, after it’s finished two reboots are required.

Experimental Features

The two experimental features available are 3D support and application publishing.  I hope that both features make it off the experimental list and onto the supported list by release.

3D support is configured by enabling it within the Citrix receiver console and installing software in the guest VM.  This went pretty smoothly, I took a couple of screenshots of the windows experience index before and after the 3D was enabled, unfortunately I didn’t take a screenshot before I wiped my laptop to give the best comparison, but here are the two shots:

Before 3D

After 3D

As you can see the 3D performance is dramatically better.  How close it is to native performance I’m not sure.  3D can only be enabled on one running VM at a time.  Also you can’t publish applications from a 3D enabled VM, presumably as the publishing protocol (modified ICA?)  can’t handle the difference in screen output.

Application publishing seemed to go well and worked as documented.  You need to install software on both the publishing VM and the receiver.  I wonder if the traffic goes over IP or through the hypervisor, through the hypervisor would be more secure.

Peripheral Support

What is and isn’t supported seems to be a bit of a mystery at the moment, I can’t find any documentation on which classes of device are supported.

The extra buttons on my mouse don’t work, this is apparently because all mouse and keyboard input goes through the hypervisor and the more advanced features are not supported, I would guess that this means any proprietary buttons on a keyboard would be non functional too.  This is actually a much bigger problem than it might appear, with any new tech user acceptance is key and taking away functionality from such basic things as mouse and keyboard would affect almost all users and cause numerous complaints.

USB hard drives worked fine, except they were not recognised on boot, they had to be unplugged and re-plugged to be picked up, presumably the tools need to be running before the device is plugged in.

My USB headset was not recognised at all, despite the drivers being native to Win7.

The fingerprint reader on the laptop also wasn’t recognised.

Although I didn’t have a webcam to test, there are a few forum posts complaining about lack of functionality.  Citrix say they are hoping to have these in by release.

I said before that Wireless support was one of the harder things to do, I think that USB support may well be the other thing they had trouble with.  In device manager I always got a non functional USB hub, whether this is just me or an issue with the tools I don’t know.

XenClient with Synchronizer

Creating the template VM was simple, though remarkably slow, my transfer rate was between 500 and 2,500 kbps, this really needs to improve if you are transferring Gigs of data.  I then created a new VM and used the template for install, again worked fine, if painfully slow.

I then installed a few apps and took a backup of the OS, after which I destroyed my local VM.  Restoring it worked, but first the client downloaded the six Gig template image, then the 10Gig of backup, why not just restore from backup?  This also happened at a snails pace, I had to leave it over night .

Additional users can be created in the synchronizer or imported from AD, once there though they can’t be deleted.  This is due to issues with checked out VM’s.

One thing with the Synchronizer appliance, it starts with a default of 20Gig disk space, this will obviously get used up very fast.  Either you can connect it to an NFS share or expand the disk, I’d advise you do one of these at the very start to avoid space issues.

The Synchronizer seems to be very basic at the moment, I’d expect the feature set of this to be expanded before release.

Other stuff I tried

Windows 2008 server (32 bit of course) installed OK, and seemed to work fine, but installing the tools broke the wireless networking.  If you don’t need wireless I don’t see why this shouldn’t be absolutely fine.

Ubuntu wouldn’t install, it hung very soon into the process, though it would run live from the CD.

Is it any good?

I have to say I’m impressed, the consoles were snappy and easy to use, apart from some issues with installing the tools everything worked as documented.  I expected the USB support to be iffy and the HCL to be small. both of these will improve over time.  The HCL especially will get better quickly as Dell and HP OEM XenClient and add their own drivers.

Peripheral support is a big deal, they really need to get USB support as close to native as possible, or acceptance is going to be hard.

Guest support is OK, though Linux guest support needs to arrive quickly, one of the major benefits of having a client hypervisor will be having 3rd party virtual appliances sitting in the background. I’m sure this is where major innovation and value add from third parties is going to come.  Without Linux support, that’s not going to happen.

Although as yet the HCL list is currently very small, I bet Citrix will be relying on third party vendors to OEM XenClient and add their own drivers.

Supported laptop models

*The 15.4″ Premium, UltraSharpTM WUXGA (1920×1200) Display with High Brightness (Wide View) is not supported. Only the 15.4″ Premium WXGA+ (1440×900) LED Display (Wide View) and 15.4″ Premium WXGA (1280×800) Display models are supported.

Hardware requirements

XenClient runs on the 64 bit hardware platforms listed above only. The additional hardware requirements are:

• Intel Core 2 Duo series processor with Intel VT-x Technology and VT-d Technology (Intel vPro Technology)

• 4GB or more memory recommended

• 160GB or more disk drive space recommended

• Intel Integrated Graphics 4500MHD

Note:

XenClient does not support the use of non-symmetric RAM DIMMs.

Supported operating systems

XenClient supports the installation of the following operating systems:

• Microsoft Windows 7 32bit

Note:

If you prefer to use Windows XP Mode to run your Windows XP applications on your Windows 7 VM, (instead of using a separate Windows XP VM) please ensure that you download the latest version of the Windows XP Mode software from http://www.microsoft.com/windows/virtual-pc/. Some earlier versions of the Windows XP Mode software used Intel VT-x virtualization technology in a way that conflicted with XenClient operation. The latest version of Windows XP Mode does not use Intel VT-x virtualization technology.

• Microsoft Windows Vista 32bit SP2

• Microsoft Windows XP 32bit SP3

Note:

The installation or modification of software directly on the XenClient host file system is not supported.

With the announcement of the inclusion of the PC over IP (PCoIP) Teradici in VMware View this week at VMworld.  I think that there is something people may be missing.

The big disadvantage of the original hardware to hardware PCoIP implementation was that each connection to the server required it’s own Teradici card.  This is obviously not a scalable solution.  As the software to software solution is unveiled at VMworld, the attention seems to be on the fact you can get the performance without stuffing your servers full of Teradici cards.  To my mind the software to software approach has a big flaw, you need power on the client. Power on the client means either a full PC on the other end, which defies the point, or a really expensive thin client.

The real key would be to go from software to hardware.  A software client on the server communicating with a hardware Teradici chip on the client.  You could avoid all the issues of managing the ‘almost PC’ modern thin clients and go back to the cheap, minimal management, devices I think thin clients should be.

I’m curious as to why this is not being made more of as the client devices are already there like this one from Samsung and if you look at the Teradici video on Brian Maddens site they say it will work.

As the devices get cheaper, maybe down to about $200 with the great performance of PCoIP I can see this being the ‘killer app’ for VMware in this space.

To work this out we need to start from first principles, way back in 2005ish.  We had many expensively maintained fat desktops, spare CPU cycles in the data center and a virtualisation layer.  This meant that we could take the fat desktops not already covered by terminal server (which only counted for around 20%) and move them into the data-center.  These new desktops would allow our users to install apps, personalise their OS, and IT could keep the environment stable.  People were saying things like ‘I can give my users local admin privileges!’.

That was the dream and it all sounded pretty good.  Then people realised that they would have to change cheap storage on the end point for expensive storage in the data-center.  Also it just seemed, well silly, to have 5000 copies of explorer.exe sitting on the SAN.  The advantages of data de-dupe were talked about, but the model that everyone settled on was a golden OS image, Citrix had Provisioning Server and VMware had linked clones.  Not only did this solve the high SAN demands, it enabled us to only update/patch one golden image and it worked for everyone! Double win!

So now we have thousands of users on one golden image, trouble is we need different application sets.  No Problem! said the industry, we have application virtualisation, it’s even a fairly mature technology, ThinApp, Citrix Streaming, App-V and all the rest.  Except not all applications are suitable for streaming, some have license requirements that rely on MAC addresses, some install drivers or services, etc. etc.

In any large organisation there are maybe 2% of these applications which are generally more than 10 years old, but that can’t be dumped.  Out of say six hundred apps that’s only twelve apps that need to be in the golden image, so we increase the number of golden images to twelve, and the rest of the applications are streamed.

So far so good, although with this golden image model, we have hit a snag, to allow users to install applications, we need to use block level deltas to save the personal information.  Over time these block level deltas can grow to the size of the original installation, ruining our nice SAN space saving ideas!  Not only that, when you update the base image you can’t reconcile the deltas, you have to throw them away.  That’s no good, you can’t give users a facility and then randomly remove their changes.  OK, lets lock down the OS, we can use a profile solution to save user personalisation using the file system (although obviously no user installed apps).  For a great explanation of block vs file see Brian Madden’s post “Atlantis Computing hopes to solve the “file-based” versus “block-based” VDI disk image challenge ”

Lots of vendors already in the Terminal Server space, immediately said ‘We have a profile solution!’ and Appsense, RES, RTO, Tricerat etc put out VDI profile solutions.

All of this worked great in the POCs and pilots, trouble is when it scaled up to 1000s of users we found that the power users who were moving gigs of VMDK’s around or working with large media files etc. meant we had to have REALLY expensive Tier 1 storage at the SAN, it became uneconomical to move those users to VDI so we left them on their fat desktops.

So where does that leave us on our big VDI project?

• Multiple users on an OS image
• Application silos
• Locked down desktops
• Profile solutions from Appsense, RTO, RES etc.
• Users limited to Task and knowledge workers
• Oh yeah, print solutions from Citrix and ThinPrint.
• Desktops accessed via RDP or ICA

I mean what does that sound like to you?  To me it sounds EXACTLY like Terminal Server.  What we have done is taken a VDI dream and apply terminal server thinking to it, unsurprisingly, it’s now looking just like terminal server, but with extra licensing costs.

We need to apply some brand new thinking, there are vendors out there trying to do this, like the afore mentioned Atlantis, but before VDI really takes off we need to rethink a lot of things or Gartners prediction of VDI being a $65 billion business with 40% of the worlds professional desktops seems to be a long way off.