In-depth Q&A with Citrix about the current and future XenClient

Citrix released version 1.0 of their client hypervisor, called "XenClient," two weeks ago.

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.

Join the conversation

19 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Brian, thanks for yet another excellent article.


I have a few questions about the architectural differences between XenClient and Virtual Computer NxTop Engine. Maybe @Doug Lane or someone else could tell a bit more? You know, for geek education purposes, cause I really want to know.


As both NxTop Engine and XenClient are based on Xen (and Citrix being an investor in Virtual Computer) how is it that NxTop can support both AMD and Intel CPUs, Intel, ATI and NVidia GPUs and having concurrent  3D graphics support on multiple running VMs?


I am being explained that this is due to the different architectural and build design of NxTop and XenClient. Ok, but DOH! That doesn’t really say that much...


I’m interested to know what those architectural and build design differences really are, and maybe most important, why are they there? To what purpose and to what end?


Please educate me


Thanks /kimmo


Cancel

good article!


in a couple of your titles you mentioned xendesktop 1.0, did you mean XenClient 1.0?


Cancel

Yes.. thanks Corey! I wrote this article on the plane heading home from Russia, and I was literally falling askeep towards the end.. I made the changes where I accidentally wrote "XenDesktop" instead of "XenClient." Thanks.


Cancel

The additional information is appreciated, but I still believe, and think the Q&A further proves that  this shouldn't be a 1.0 release.


"if they don't disclose the issues...<cut>...If they do disclose the issues" -- isn't this with all software releases, and why people have feedback on beta releases?


"..it's just that Citrix didn't have the bandwidfh to actually go through the whole certication process."


"..sort of on their own when it came to hardware for testing..."


Lack of resources doesn't make this not a Beta, just lack of priority and resources.  Citrix isn't a mom and pop shop.  Wait until you're ready.


It's terrific that it is available, but plenty of beta, preview, and pre-release software is available that "will primarily used by IT Pros."


Change the name of anything from [Beta | Alpha | Pre-Release | Evaluation | Test-Drive] to 1.0 and you are rightfully open to as much scrutiny from the public as it chooses.


Press releases of features is great for stockholders.


When the rest of us hear of a production release, we want it to seem likle one, or you lose credibility.


Is the product release something Citrix is proud of, or are they simply proud to be able to announce it?


Cancel

@Kimmo,


While we both start with a common base in Xen, there are some key differences in our architectural approaches: some big and some small.  The biggest one is the approach we have each taken with graphics.  With NxTop, we have always put a big premium on breadth of hardware compatibility and VM portability across different hardware.  As a result, we have put a lot of focus into paravirtualizing the graphics stack 100 percent of the time versus doing graphics pass-through the way XenClient does.


This single architectural decision is why our hardware compatibility is much broader.  The base processor technology both products need to function is Intel VT-x (or in our case alternatively the AMD equivalent, AMD-V).  In order to do graphics pass-through securely and reliably you need the input/output memory management unit (IOMMU) functionality in Intel’s newer generation of virtualization extensions, VT-d.  So, when Brian explains that XenClient doesn’t actually need vPro, it just needs VT-d, this is why.  The reality is that VT-d is most often (but not always) bundled in with vPro, so it is easier to generalize and say “if you want XenClient, get vPro machines.”


(As an aside, both Virtual Computer and Neocleus tried early on to replicate the IOMMU functionality in software, so we could do pass-through on VT-x systems, but neither of us was successful.)


What we do with NxTop is rely exclusively on Linux graphics drivers that we have integrated into NxTop Engine’s control domain (Dom0 in Xen parlance) and then present a generic NxTop graphics driver up to Windows.  So, in addition to breadth of hardware compatibility, we also get fairly effortless VM portability across hardware platforms.  When a VM moves from a Dell running NxTop to a Lenovo running NxTop, Windows sees exactly the same thing; no driver swaps required.  In addition, because we don’t need Intel’s hardware IOMMU, we can also deal with AMD.  I would be doing a disservice to our engineering team if I said it was easy, but the reality is that Xen runs on AMD-based servers in lots of places today.  It's just that no one is trying to go graphics pass-through on servers.


Because XenClient is letting the OS talk directly to the GPU, in addition to needing the IOMMU in hardware, they also need to come up with an elegant approach for managing graphics drivers in the VM as Brian described in his article.  Right now, it doesn’t matter that much, since they are running on a limited number of Intel GPUs.


With all of that said, there are also some advantages to how XenClient is going about things.  By doing pass-through, they achieve excellent graphics performance in the primary VM day one.  In our case, graphics performance is unnoticeably different from native for a typical business user, but it is not native and our 3D support is limited today.  Our 3.0 release includes “experimental” support for OpenGL 3D in multiple concurrent VMs (something not possible on XenClient), but we don’t yet support Aero, DirectX, etc. the way XenClient can in a single pass-through VM.  We have been working on this for quite a while, and if you don’t think it’s possible all you need to do is look at VMware’s Type-2 products.


Unlike VMware, we did not have the luxury of going out and acquiring Tungsten Graphics.  We need to build it ourselves.  Fortunately, we are getting pretty good at this stuff.  :)


At the end of the day, I don’t think there is a right or wrong answer.  It is all about trade-offs and priorities.  As a large company with other revenue streams, Citrix is wise to “skate to where the puck is going” rather than try to deal with legacy hardware.  In our case, this is our only business, and we feel that maximizing hardware compatibility is key to capitalizing on our first-mover advantage to grow revenue faster.


Doug Lane


Virtual Computer, Inc.


p.s. I never intend for these things to be this long.  It just kind of happens...


Cancel

Everybody who is crying about it's a 1.0 release etc. Let me ask you a question. If Citrix called it 4.0 like XenDesktop would your expectations change? XD 4.0 is a pile of junk and I don't see you posting that it's also an advanced beta at best.


The good news here is vPro is not required and the fact that they are showing commitment to keep pushing forward and create a market. I also like the comments about being open and letting other's have a piece of the pie. This is a all good for us customers.


The only questions I wish Brian had probed them more on was their plans for advanced management and when. Is it their own, partnerships etc. Otherwise good article.


Cancel

@Appdetective, I don't think that people are crying that its a v1.0 - I think some enterprise punters are crying because what they perceived they were going to get from Xenclient is far removed from what they've actually got. A rose by any other name and all that.


I'd agree that some punters want the facility to let users fiddle with their own desktop. But you can do that with a type2 hypervisor, why limit yourself to the small HCL list that XenClient imposes? IMO, thats not a great use case for Type#1


Security - especially for government use as Brian described is a Big Thing. In the UK there's a drive to move government to a shared platform. That's not going to happen overnight, the ability to host mutliple environments on one device would stop the waste of having users carrying multiple devices which is not uncommon. Its going to help the evolution of getting there. But again, XenClient's problem here is the poor h/w support. It'll get better sure - but when and why indeed not a wider h/w support earlier? Have you seen VC's h/w list? Then theres disk encryption accreditation for security - but then VC don't have that either and its something for them both to work on.


What a good deal of customers would like is less dependence on the h/w for their builds - more flexibility in buying devices. Not for BYOC per se, but for 'what is the cheapest today'. Type#1 offers the option for enabling that flexibility and a greater option for standardisation. Its interesting to see Citrix going down the passthrough route - as to best utilise their higher end HDX they need a some form of OS on the end device, and that OS in turn needs managing


Ergo, I'm 100% behind you on management - the syncronizer is not a management product. XD4's management was not splendid. How will those functions all fit together with the existing product set or will it be tagged on and it take to v5 (@2014) before it starts to look half decent?


Cancel

@Brian - great article about some insights into the current and future progress of XC.


@Doug - great post about insight into how the architecture of NxTop compares to XC. By explaining it the way you have it gives incredible clarification as to where the technologies relate and differ.


The thing is though, I just want more streamlined and integrated management of all of my offered services.


- Server Hosted Desktops, Apps and Data


- Client Hosted Desktops, Apps and Data


I don't really see that happening unless the management was done by a single vendor...


Take for instance Wyse Xenith management integration with XenDesktop 5.


Cancel

@appdetective - Had it been about XD, I would have the same opinion. :->  I agree that it's great they are pushing forward, and growing maturity is terrific with any product, but changing the version number doesn't change maturity, just the (temporary) appearance of it. I do appreciate Citrix sharing comments with Brian that were a bit more human and bit less marketing though.


Cancel

@icelus, I think thats a very valid point it is perceived that without a single management interface you can't move forward


Yet, if you've a citrix environment (for example) its likely you've


a management interface for XApp4.5


a management interface for WI


a management interface for XApp6.0


a management interface for XenDesktop


plus the management interface for AD as you've got XA6.0 and you need to manage policies.


You're a single vendor house and you've already multiple interfaces.


But then flip it round - is that such a nightmare? Great it makes your life easier does it impact on the wider business? At the risk of going all Star Trek II on you really - does a couple of IT administration tasks outweigh the needs of the business?


Cancel

@andy


You point out a great pain that still remains with Citrix. They haven't matured to what I find is ideal, unfortunately I probably implied that they did. My mistake.


Another great point you state is the flip side of it all. You are right, I won't cry if multiple management consoles are used. It's just another console to the countess other ones that are used for other tasks not related to desktop virtualization.


The thing is consolidation of similar tasks is proven to make things more efficient, so I was just implying that the integration of a centralized and consolidated management consoles would make administration much more simpler as well as mature the products as a whole.


Cancel

With how things are coming along, I am just hoping to see XenApp 7 with Application Studio and app managment integrated in Desktop Director to ease management.


Also, in addition to Citrix Receiver killing Dazzle, maybe it will kill WI too.


Cancel

And as the article already elluded, have Citrix Synchronizer kill PvS too.


It's just a name and Synchronizer is better IMO.


Talking about names...


I am just waiting for VMware to take a stab at Citrix Receiver calling it 'Deceiver' to promote Horizon.


Citrix definitely took a stab at VMware saying that it's definitely not over the Horizon for them.


Cancel

@andywood. Fair points. The only saving grace here is that we are not on a 4.0 release with people still making excuses that it will get there.... I actually don't mind them being straight up here and saying there are gaps and it will take time. It's the right expectation. If only the same was true for XenDesktop, which is an advanced beta at best.


Cancel

@Duoug Lane. WOW. Thanks for a great post. Very appreciated! I think I now have a clearer picture on the key architectural differentiators between XenClient and NxTop and the relative pros and cons of the different approaches.


The only thing I didn’t quite get was how the IOMMU implementation differs.  


Are you saying that in NxTop Dom0 Linux driver/Generic Windows paravirtualized driver approach there is no need or use for Intel VT-d or AMD HyperTransport to do the hardware based IOMMU virtualization? en.wikipedia.org/.../IOMMU


In addition, in regards of Intel VT-d/AMD Hypertransport – is there a hard technical limitation on only being able to do IOMMU pass-through to a single VM at a time (or primary VM as you put it) thereby limiting 3D graphics to that single VM whereas the other VMs running simultaneous are restricted to simple virtualized 2D graphics?


If that is the case, would it be possible to have an hybrid approach where the “primary VM” uses VT-d/Hypertransport technology for direct pass-through, and the subsequent VMs uses the Dom0 Linux driver/ Generic Windows paravirtualized driver technology?


These additional comments and questions are really directed to everybody. I might be totally wrong in my reasoning and assumptions. Please correct me and contribute in the discussion. Also @Citrix employees. What’s your take?


Thanks all for a very interesting discussion. Keeps the ball rolling.


Kindly /Kimmo


Cancel

It is encouraging that folks are truly interested in the tyoe 1 client-side hypervisor.


I'd like to take 2 minutes out of your day to describe the RC2 version of NxTop 3.0


I recently installed it on a Dell 830 (T7500), 4 GB RAM. I had the installer use the whole disk (creating a DOM0). If you are interested in dual-booting a machine, make sure you have at least 20 GB free on an extra partition. Installation took approx. 10 minutes. The new UI on top of the HV is very nice. It allows you to configure networking, additional peripherals, and assign a primary account.


Another nice thing is that one can use it as a quick OS to RDP, Skype, or surf the net (e.g. to Brian Madden) using Chrome. All come included.


1st boot took about 1 minute to stabilize and subsequent boots take about 30 seconds or so. (in comparison, Windows XP took 15 seconds and Windows 7 takes 20 seconds; All clean installations).


After you configure your hardware, you'll probable want to create a NxTop (additional instances of OS'es). You access this via the Control Panel (IMHO, this should be more visable especially in the free version).


The creation of the template (logical NxTop) is very fast, but the wizard bumps you back to the Control Panel. It should take it to the next step and ask if you want to start the NxTop. Make the flow seemless.


You'll now see at another "icon" on the main screen indicating the added OS instance. Click on it and you'll be on your way (similar to any other OS installation).


I recommend that anyone interested in the technology take a few hours and enjoy the show.


(I do not work for Virtual Computer or any other major player, but rather take a "trust, but verify" approach to the confusing virtualization market).


Regards,


-SillyRabbit


Cancel

To answer Kimmo's questions...


You are correct that the NxTop implementation does not require VT-d or an IOMMU -- all devices are virtualized and no VM has direct access to hardware; thus the IOMMU is not required. As Doug said, we chose this approach in order to maximize VM portability and at the same time provide support on a very wide range of platforms (including those that do not have VT-d).


WIth VT-d there is a limitation that a specific PCI function can only be passed through to a single VM (or handled by Dom0) at any given time - if you think about it, you cant have independant drivers in two VMs controlling the same piece of hardware.


Regards,


Simon Graham


Virtual Computer Inc


Cancel

@Simon Graham Thanks!


Is there anyone from Citrix that could expand on the topic from their viewpoint? I mean, with the native pass-through it seems that it would only support 3D on a single VM plus the need to have native drivers.


As have been pointed out due to the current quite limited HCL of XenClient (with only Intel graphics supported) there isn’t that much of driver discrepancy as of now, but with a growing HCL (like the Nvidia support as presented at Synergy) this would rapidly become an issue.


Well, that is unless there is an hybrid approach that gives customers the choice of both eating the cake and keeping the cake based on their specific needs.


In a lot of ways I would see a happy marriage between XenClient and NxTop feature set and different approaches as the most beneficial go-to-market offering.


I for one wouldn’t really like to be in the position of choosing between as I’d like to have both, full stomach on the never ending cake :)


Cancel

Hi, little questions about the new improvement from SP1.  The Capability to boot from PVS image. Does the hardware and software suppose to be really separated ?  What I means can we take any VHD file to boot with ?


Thanks


Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close