Citrix released version 1.0 of their client hypervisor, called "XenClient," two weeks ago. I wrote a fairly negative article about it, basically saying that while I loved the concept of XenClient, I didn't feel like the 1.0 release was ready, and therefore it was pretty worthless for now.
Then last week I attended Citrix Synergy Berlin. Countless Citrix employees came up to me to let me know they had read my article. Reactions were split, with some agreeing with me by feeling the product should still be classified as a beta, and others basically thinking I was an idiotic blow-hard who hadn't even used the product. (For the record I was part of the XenClient beta program, and I spent plenty of time with it before forming my opinion.)
One of the good things that came from the article is that two key folks from Citrix offered to sit down with me at Synergy and have a no-holds-barred conversation about XenClient. I happily agreed!
I first sat down with Peter Blum, the lead product manager for XenClient. That was followed the next day by a conversation with Ian Pratt, co-creator of the Xen hypervisor and co-founder of XenSource. So needless to say, these are the right guys to be talking to!
I asked each of them tons of questions, and I furiously typed notes as they spoke. Today's article is entirely based on my conversations with them. I organized the content by subject, first addressing the issues I raised in my Oct 4 article, and then going into the other questions I asked.
Is XenClient 1.0 ready to be a real product, or is it still "beta" quality?
Today's guidance is that it's a v1.0 product, so they're expecting it to be used for pilots and proofs of concept. If someone came to them and said, "I want to deploy 10k seats," they'd say no. But a lot of people are doing it on their own. And there are actual customers with maybe 100 or 200 endpoints that fully plan on deploying 1.0 to all their users.
That said, Citrix expects the next XenClient release (targeted for the first half of next year) to be the one that people really start to use, and then 2012 will be the volume year.
This maturity cycle is something that all products go through... certainly they saw the exact same thing with XenServer.
What about all the "known issues?"
Well first of all, XenClient is free, and so they want to be totally open about the issues. A lot of those things don't happen that often. If you look at View 4, there are over 80 similar "known issues." They think XenClient is about average there. But again, this XenClient is 1.0, and any product is going to have a long list of issues.
They actually pointed out that they're in a tough position. If they don't disclose the issues then people will accuse them of hiding stuff and customers will waste time troubleshooting and calling support for stuff they already know about. But if they do disclose the issues then they get bloggers pointing them out to the world. (touche!)
But they feel that this 1.0 release will primarily be used by IT pros, and again, it's free and most of the known issues have workarounds. And in a few more releases this won't be a problem.
What about the "experimental" features?
There are a lot of good solid features in the product that are not experimental. Building a client hypervisor is hard work, and they're very proud of what's in there and supported.
As for the specifics, the application sharing is experimental because you can't share apps out of a VM that has the 3D pass through, so for that to be a full-on feature then it has to be solid and the UI has to make sense.
As for 3D support, actually they now feel that that's now full production quality, but they weren't able to internally sign-off on that until too late, so the documentation and the product officially say that 3D is experimental.
Why is vPro required?
XenClient 1.0 does NOT require vPro--it's just "highly recommended." Actually it comes down to the chipset. Really what they need is VTX and VTD, and any system with vPro automatically has those. But actually there's a lot of hardware out there without vPro that does have VTX and VTD, and assuming those systems have Intel graphics & BIOS (as opposed to EFI), then XenClient should work fine.
And to be clear, Ian directly said, "No one's paid us not to use vPro." (Last month I implied that XenClient requiring vPro was due to Intel paying Citrix, rather than any technical reason. Ian made it very clear that this was not the case.) In the future, there will be non-vPro devices on the HCL.
Why the "small" hardware compatibility list (HCL) ?
The HCL now has 23 systems, which is double the size from the beta testing. But more importantly, those 23 different models represent 15 million devices in the world. They went to the OEMs and asked, "What are your highest volume systems?" There's a major bell curve for the numbers and models of laptops that these vendors sell. They took the two highest ones from each vendor, plus the little executive laptops. And the chances are pretty good that users will have one of them.
And again, this is just a start. Within a year or year-and-a-half, this problem will kind of fix itself.
The only area on the HCL where they've really taken some flack is on the GPU. (XenClient 1.0 is only supported on systems with Intel GPUs.) They didn't take into account that the early adopters are IT Pro folks who want XenClient for themselves and most likely have more powerful GPUs. Of course Citrix demoed XenClient.next on the main stage at Synergy in Berlin running on an Nvidia GPU system, so this is coming as soon as possible.
But all this conversation is just around what's officially supported. XenClient works fine on quite a bit more stuff, it's just that Citrix didn't have the bandwidth to actually go through the whole certification process. But there's a lot of stuff out there that's not on the HCL that works fine.
Citrix is also working with the OEMs to get all the "little" features working, like the special hardware buttons. To get support for stuff like that, they need to work with the vendors. (In case you're wondering, sometimes it's really easy to get the buttons to work--they're just a regular keyscan code. Other times special button presses make WMI calls to the BIOS, and Citrix has to leverage a generic mechanism for remoting back in the BIOS.
On lack of TxT & TPM support
Even though all this technology (like TxT) has been in Intel clients for awhile, there's still no significant use of TxT today. Intel usually makes sure the hardware works, but from the BIOS enablement point of view, if there's no real software to test, then the OEMs often ship laptops and desktops with broken BIOS that can't properly interface with TxT. Citrix saw this and realized it's going to be hard to make TxT work at this point, (and in fact they found several occasions where the BIOS tables on systems with vPro were just plain wrong)!
So the lack of support of TxT on some vendor platforms, and the interaction between TxT and TPM are not well tested becasue there is nothing to test against--in fact some older BIOS revisions would even brick the machines when TxT was enabled.
Then there are also some logistical issues to sort out. TxT combined with sleep mode of a laptop is really complex. What happens in this case is that TxT will check the system when you sleep, and then again when wake up to ensure that everything is as you left, and then use the TPM to seal it. But during the boot-up process, the BIOS runs before the hypervisor and the VM, so when the BIOS changes things, TxT resets and your state is gone. So XenClient doesn't even get a chance to work with TxT.
The good news moving forward is now that Citrix has a better relationship with the OEMs, they can address this. But it's important to know that they're on the bleeding edge of TxT and TPM and VT-D and that those issues will get solved pretty quickly.
Relationship with OEMs
One of the problems Citrix had with the early XenClient testing and hardware certification was that they were sort of on their own when it came to hardware for testing. Initially Citrix had to go out and literally buy a bunch of Dell and HP systems for development, testing, and QA.
But their OEM relationships are evolving. Now they're seeing that instead of them going out to the OEMs, the OEMs are actually sending them new systems for testing. In fact some of the stuff Citrix is getting are dev versions of systems that are many months out--they're literally a bunch of circuit boards in a styrofoam box. This means that instead of Citrix chasing the OEMs after the fact, they're actually part of the design process.
One of the announcements from Synergy last week was that several Lenovo devices were now supported for XenClient 1.0. In that case Lenovo actually came to them looking to get their stuff certified, so Citrix is already seeing the fruit of some of their momentum here.
Ultimately Citrix wants to work with as many OEMs as possible to build and deploy client hypervisors. Any technology they develop will be shared freely via open source (except for a few graphics components they need to protect) with other OEMs, and ultimately these OEMs might create new products that even compete against Citrix's offerings, which is okay.
Disk image portability
Today's XenClient disk images are 100% hardware independent. In the future it's really only the GPU driver that would need to be specific to a certain physical GPU. Citrix envisions that they'd just overbuild the drivers in the VM. Really the main challenges are booting and networking--as long as you can do those, then everything else is easy. And booting and networking on clients is fairly easy. (No SAN drivers, SCSI, RAID controllers, etc.) The real key is just to avoid a Blue Screen for "boot device not found," but again that's not a problem for laptops.
I asked if Citrix would create multiple VHDs that were layered dynamically to separate out the hardware-specific components from the OS. They were very clear in their answer to this: no. "If we've done that, we've failed," Ian said.
Xen's Paravirtualization architecture abstracts the model for the devices. Citrix's plan is to come up with abstract models for different GPUs. So today they can do that with Intel, so a single set of paravirtualization GPU drivers could work for many different Intel GPUs, but they can't use that to make an Intel GPU look like an ATI or Nvidia GPU. But because these GPUs aren't boot devices, you can always fall back to a generic graphics driver.
And with the trend to put more and more on the CPU, Citrix's job actually gets easier as time goes on. Creating something like XenClient would have been much harder a few years ago since today's hardware is much more homogenous.
Of course you still need native drivers for USB devices that are connected to the host and shared via USB pass-through.
Why is the XenClient "dynamic image mode" functionality different than Citrix Provisioning Server?
XenClient's dynamic image mode is similar in some ways to Provisioning Server (PVS), and in fact there are many crossover technologies. But there are also some key differences.
The main thing is that PVS requires a LAN connection to the boot volume which is on a NAS. In XenClient, the boot volume is local.
I asked whether they'd ever support PVS. Citrix pointed out that PVS works fine with XenClient today as long as it meets the PVS requirements (namely a persistent LAN connection), but that when it comes to offline disks, mostly like XenClient and XenDesktop / PVS will jointly evolve so that the same disk image can be used for both.
Citrix is also thinking about the various "layering" technologies required to lay down a fully customized user environment on top of a shared master image (regardless of whether that's handled by PVS or XenClient dynamic images). Whether that's some form of app virtualization, User Profile Manager, or something we haven't seen yet, the concept is similar.
Why should people use XenClient 1.0?
There are several reasons to use the 1.0 version of XenClient. First is the whole business & personal VMs on the same device. Citrix is really seeing this with mobile users where companies want to get away from giving their users local admin rights. XenClient lets them lock down their business desktops while still giving users the flexibility to do whatever they want with their personal images.
Security is another big play, not just for the disk encryption, remote kill pill, and low attack surface of a Type 1 hypervisor, but also in government situations where a single users needs multiple desktops that each connect to networks at different security classification levels.
A final reason people are using XenClient--and this came as a surprise to Citrix--is for an "upgrade" of VMware Workstation or Virtual Box. This is mainly for the early adopter IT pros, but the feeling is a Type 1 hypervisor running natively on a device can provide a better experience than VMs running in Windows.
Why is XenClient a Type 1 hypervisor? Will Citrix create a Type 2?
Citrix considered building a Type 2 version of Xen at one point, but ultimately they decided the market just wasn't there. For XenClient, Type 1 just "feels" better, for lag, performance, etc.
Citrix's answer to Type 2 is XenApp streamed apps plus XenVault. That's their pitch for BYOC & contractors today.
Type 1 is important because the IT department controls it. In a Type 2 environment, the base layer can be personal, which means users could delete it, install malware, spyware, etc. Not so with a Type 1 hypervisor that's controlled by IT.
How well does the Synchronizer work?
The Synchronizer is a server-side component that's responsible for deploying and backing up XenClient disk images. (And in fact it's the Synchronizer that must be licensed if it's used to control more than ten devices. XenClient itself is free.)
Today the Synchronizer backs up systems by asking the client hypervisor to take a standard VHD snapshot on a schedule. The snapshot file starts out empty but then grows with the changes that are made. This is the file that's periodically backed up, so if you need to restore your image you can find the original master plus the chain of delta backups.
Today the Synchronizer backs up everything. Citrix is working on technology they're calling "VHD Compact" which punches out page files and deleted files to keep the backup snapshots as small as possible, but that functionality needs more testing so it hasn't been turned on for XenClient 1.0.
Even though 1.0 backs up everything, it does still compress the snapshots before they're send across the network.
What about Neocleus?
Intel bought client hypervisor maker Neocleus last month. What does this mean for Citrix and XenClient?
Neocleus was going out of business, and what Intel bought was a bunch of system software guys in Israel who really know their stuff. These kinds of guys are hard to come by, and if Citrix had a group in Israel then they would have picked them up. But overall this deal has not affected Citrix's relationship with Intel.
What about Virtual Computer?
It's been almost two years since Citrix invested in Virtual Computer, another startup in the client hypervisor space. Citrix's ultimate goal (and reason for investing in Virtual Computer) is to grow the market. Anything that gets more Xen out there is good for Citrix.
In the case of VIrtual Computer, they're going after a different use case by focusing on SMBs and existing hardware devices. Even though they share the same core (Xen), Virtual Computer has done a lot of good work and they're proud of what they've done.
Citrix has the luxury of looking forward and working with the core hardware features that are coming up in new platforms like Sandy Bridge and Huron River while startups like Virtual Computer are focusing on the current install base since they have to sell products today. But this means that the two are complementary. Citrix will do well in the enterprise space while others will do well in the verticals.
In the longer term companies like Virtual Computer may even adopt the XenClient platform but with their own management stack.
What version of the Xen hypervisor is in XenClient?
XenClient 1.0 is based on the same hypervisor as the "Cowley" edition of XenServer will be released as Citrix XenServer 5.6 Feature Park 1. The only difference is in the configuration (for things like power management) that will be different on the client versus the server. XenClient also makes use of different Xen security modules.
One of the things that's fun about the client stuff. is that XenServer has 50k+ customers, so rolling out anything new requires a crazy amount of testing. But on the client, they can be far more aggressive, which is why we're seeing some of the security modules enabled first in the client hypervisor that will we eventually make their way into XenServer.
What about AMD?
All of Citrix's XenClient messaging is focused around Intel because they're the dominent enterprise laptop platform. Right now AMD seems to be a bit more consumer-focused. For example, there's no IO MMU (which is like Intel's VTD) in AMD's client platform.
But from a technical standpoint there's nothing really stopping XenClient 1.0 from running on an AMD system. XenServer has supported AMD for years.
What about the Mac?
First, there's no technical reason Citrix can't make XenClient run on a Mac and enable the Mac OS X to be run in a guest VM. (Even though the Mac has EFI instead of BIOS, the Xen hypervisor can handle that and in fact the open source version of Xen has support for EFI.)
The bigger issue is that Citrix wouldn't offer XenClient on the Mac without Apple's full support, regardless of what the Mac OS X EULA says. The good news is that Citrix now has a relationship with Apple based on the Receiver for iOS, so should the Mac platform ever become a priority for them, at least they have someone in Cupertino they can call.