VMware clarifies what features they'll support via PC-over-IP for VDI

Like most conferences, VMware used the Day 2 keynote for the more technical content they wanted to share with the conference-wide audience. The keynote was led by VMware's CTO Steve Herrod.

Like most conferences, VMware used the Day 2 keynote for the more technical content they wanted to share with the conference-wide audience. The keynote was led by VMware's CTO Steve Herrod. Steve confirmed the high level stuff that Paul Maritz mentioned yesterday. There was nothing really new, although he did mention a cool feature of the client hypervisor that it will have the ability to check-in periodically for enforcement of usage and security policies. The example he used was that if you realized you had a major security problem with one of your VMs, you could enable a policy which would disable that VM. Then the next time a remote client running the hypervisor checked in, it would learn that VM was disabled and it would security destroy it. Pretty cool!

The "money" information was about VMware's protocol plans. They talked about the PC-over-IP capabilities that they're adding into their View VDI products. As you may recall, last September VMware announced that they'd signed a codevelopment agreement with Teradici and that the two companies would work together to create a software-only implementation of Teradici's PC-over-IP remote display protocol. (Today's PC-over-IP implementations are hardware-based, meaning you need a graphics card with a Teradici chip in it on your remote host, and a thin client device with a Teradici card in it to connect from the client end.) From a branding standpoint, VMware never mentioned the word "Teradici" on stage today, and they did not mention that this technology was based on their co-development agreement. (I guess they didn't want anyone to know that this technology was currently available via companies other than them.) Instead, VMware only mentioned this as "PC-over-IP." (And while most readers of this website are familiar with PC-over-IP and Teradici, a journalist sitting next to me was really impressed and asked my several questions about how this "VMware PC-over-IP" works.)

In the keynote, Steve and Jerry explained that VMware would use PC-over-IP to support three use cases:

  • WAN
  • LAN for 2D graphics
  • LAN for 3D graphics

The WAN use case

Jerry explained that while the WAN use case is really complex, it's VMware's intention to use the software-only implementation of PC-over-IP to support users with 150-250ms latency. They'll give them "basic" flash (think YouTube videos, not full-on Flash apps), voice over IP, remote printers, local storage, etc. (Actually, now that I think about it, I'm not 100% sure the WAN use case was using PC-over-IP. The WAN use case might just be using the traditional RDP with the Wyse TCX extensions that VMware licensed.)

LAN for 2D graphics use case

VMware expects the LAN use case for business apps to be the most common. They'll support multiple displays (they didn't specify how many "multiple" meant) at 1900x1200 resolution, a rich internet browsing experience, "full" Flash content, Adobe AIR, Silverlight, etc. Jerry said this would be the "true PC experience" with HD video and rich 2D graphics. And again, this was all with a software implementation of PC-over-IP.

LAN for 3D graphics use case

The final use case that VMware will support is for full 3D graphics over the LAN, including CAD/CAM, video, GIS, animation, etc. For this use case, they will require the assistance of "specialized hardware on the host and the client." In other words, this is exactly how Teradici works today. (It's just that they can broker the connection with VMware View, which is also actually available today.)

Demo Time: A bit misleading for people not "in the know"

After explaining the three use cases, Jerry showed a demo of "VMware View's 3D performance over a LAN." He used Google Earth and an application with a 3D CAD-like rendering of the Eiffel Tower. I hate to sound so negative about everything here, but most in the audience were mislead by this demo. It was a demo of Teradici's hardware chipset-based implementation. It had absolutely nothing to do with VMware. Yes, the crowed loved it and they applauded wildly. But they didn't know they should be applauding for Teradici, not VMware.

To be fair to Jerry, I don't think he purposefully tried to mislead anyone. He mentioned this was a "hardware assisted" solution connected to a workstation behind the stage. But after the demo, two people came up to me and said "Wow! I can't believe VMware gets such good performance!" I mentioned this performance was from Teradici and their chips, not VMware, and the people were surprised. So while the demo was a connection that was "brokered" by View 3, VMware didn't really have anything else to do with it.

So congratulations Teradici! Your demo rocked!

The big question

VMware has still not publicly demonstrated their software-only PC-over-IP implementation. This is the one we'll all get for free when we buy future versions of VMware View, and this is the experience our users will have when connecting to VM-based View environments. It's great that VMware is planning to support the LAN and WAN use cases, but we're still waiting to see how good the user experience will be.

Stay tuned!

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Is there no "good news" in Cannes?  



Thanks for the objective analysis & useful info for those of us with a very big interest in VDI that didn't make it to VMworld :).

Personally, I think it is a good idea to be a bit sceptic & keep raising the "why" and "how" questions. In the increasing VDI battle between VMware & Citrix and Microsoft, it is not surprising that some demos might not be entirely applicable to the story that was to be demoed (like the example you mention here, Teradici hardware assisted acceleration where the software based version is the one that is drawing most VDI enthousiasts' attention).

It's a common trick amongst vendors of course, but it is very hard to see through the nuances & similar tricks for those that are not physically present at a VMworld or a TechEd. In that context, your scepticism or "you being negative" is precisely the added value that people should be looking for in an article or blogpost on VMworld. I'll read the vendors story on their website in a few days ;).


Expect to see that VMware/Teradici Software to evnentually make it back to hardware..


Not being a hardware or software engineer, I really struggle with the concept of turning a highly specialized hardware solution into a piece of software. Surely there must be a good reason Teradici built the thing as hardware in the first place? Is it reasonable to expect the same level of performance when the specialized hardware is gone? Presumably it will just require even more powerful general processing hardware at the client end to deliver the resources to perform the functions in software. After all, you don't get nothing for nothing. Maybe the end result will be a more powerful but very simple client device, with everything complex done in software? Thanks for keeping us up to date with VMWorld Brian.


I wasn't at the presentation but spent a lot of time at the Terradici booth. I'm the VDI team leader at my company and this was one of the major attractions for me. I asked them about the big screen showing a 1080p video in full screen, I was pretty amazed by that demo until he explained me that it wasn't VMware's implementation of teradici protocol. Then he pointed out the other computer which were in fact virtual machines attached to a new product from Samsung with apparently no OS in them (didn't verify that information). These desktops were hosted by ESX with a custom device with 5 Teradici chips on them so 5 Virtual machines was the limit on that setup. Each virtual machine was bound to one of the Teradici chip, preventing the action of vMotion on those VMs. But the client was simply a client supported by the VMware View client with no special chip in them; all was done by the software implementation of the Teradici protocol inside the VMware view client. He explained me that Teradici just dropped that code to VMware 1 or 2 weeks ago.

The performance was slower that the full hardware implementation of Teradici but was much faster than anything else I've seen so far (ICA, RDC + TCX, Panologic, ProvisionNetwork), nothing to compare. We can expect slower performance for sure or more CPU utilisation on the ESX host but I can bet that the result will be amazing.

I am not sure of what VMware presented, but the demo I had with Teradici was very impressive and that scenario correspond apparently to the LAN for 3D graphic use case that you listed.

If you what to have more details about this go see them, they are need the innovators booths. They can even details how the protocol works and how they can shape it to get better performance. In my humble opinion, it’s the best of them all so far.


The Red Hat SPICE protocol offers similar perfomance to Teradici without the imposed hardware limitations.  We will be evaluating the Red Hat SolidICE solution via the early adopter program.  I found a simple video example below, but I've also seen it in action and am thoroghly impressed.  However, as with most of these 'high performance' protocols, optimization for low bandwidth/high latency connections is slow to develop.


I don't necessarily mind a hardware implementation, but since no standards exist, and the current video hardware vendors (Intel, nVidia, ATI) are not involved, chosing any of the current solutions could be a dicey approach.


I find it funny that people think that software remote protocols don't have hardware limitations.  The better your CPU and GPU on both Host and Client devices, the better your 'software' remote protocol operates.  That is assuming that the network is not the limiting factor.

The example of "Red Hat SPICE protocol" offering similar performance may be true, but with what version of Red Hat ($$$), what type of client CPU ($$$) and what type of client GPU ($$$).  And at what cost to the amount of CPU/GPU cycles at the Host.

The PCoIP portal can provide the low-end and h igh-end performance with the 'same hardware' with zero load on the Host CPU.  So if you upgrade your host machine then you automatically get the better performance at the portal (client) and don't have to worry about software compatibility.

In addition, software protocols have the limitation of being tied to a particular OS.  So in the example above of Red Hat SPICE, you are tied to Linux.  For RDP - tied to Microsoft.  Mac - tied to Parallels ? (don't know this one).

Software protocols are normally optimized specifically for the OS they are associated with, and then 'may' be ported to other OS'es as a secondary thought.  So to have optimal performance on all OS'es you need to have knowledge of several different remoting protocols and use them all.

PCoIP is OS agnostic, meaning the same portal device can work with a host card in a MAC, PC or Linux Box, assuming it has a PCIe slot.  In addition the portal device (including the PCoIP enabled Samsung Monitor) does not have an OS and is completely stateless - you can think of it as a network appliance that you configure once and then forget about it (or have your IT person worry about it).  You do not pay for any OS on the portal and doesn't require virus updates and maintenance.

In terms of standards, Net2Display from VESA is being worked on right now\.  For the software protocols adhering to standards, the only one (to my knowledge) that is publicly documented is RDP, and the public document doesn't cover all of the 'add-on features' that Microsoft has to differentiate it's version of RDP against other protocols.  It may come to pass that Red Hat releases the SPICE protocol as OpenSource but do you think Red Hat won't follow Microsoft's lead and hold some optimizations/features back to differentiate themselves from the pack?


I find it kind of amusing really as RGS does all of this today in a software package and is available for download at www.hp.com/go/rgs


Check Chris Wolf's post about Software PCoIP: