Citrix recently announced their work is almost done on the client hypervisor (can you call it a hypervisor if their is a DOM0 or parent partition?). That apparently ruffled some feathers and caused a bit of kerfuffle. [Yes, that really is an Andy & Lou reference] Personally, I wondering what the big deal is all about. Learn more about my skepticism here…
It’s come to my attention that some venerable commentors believe the good ship VMware View 4.5 is trouble, and taking in water. It’s my firm belief that the ship is steady as she goes… Don’t believe me? Look I know when the GA is but I can’t say because I’m gagged (AKA NDA’d) by VMware! Read on McDuff.
This week I spent some (not all) of my time playing about with a Panologic Device.
[Oh, and contrary to popular belief - they didn't pay me to do this, and I didn't ask for any money. I all asked for was a the device and software so I could play. Remember, after years of documenting VMware technologies - mainly for free - VMware has never given me a penny. He who pays the piper calls the tune - does NOT apply on RTFM. Got that?]
It’s not a PC and its not a dumb-terminal. It’s something else all together – its what’s called a zero-client. What that means is essentially the device is truly stateless. It boots over the network to what’s called the Pano Manager, which then acts as a broker to your virtual desktops. I’ve been writing a guide to VMware View 4.5 (which is currently in beta), and thought it was about time that I looked at dumb-terminals and zero-clients. If first came across Panologic at the North Carolina User Summit in 2008, and then again when they presented at the London User Group. Panologic is not alone in creating a zero-client, there are others on the market – and I’d be happy to evaluate them if the respective vendors can setup me up with a device and necessary software. It’s important to really understand what zero-client really means – it means literally there is no software or firmware on the device. You plug it, and so long as the appropriate system services are in place (DHCP, the zero-client manager/broker, vCenter and Virtual Desktops) – then the client simply boots, presents a logon screen and the user gets their desktop. I’m going to experiment with my Pano over the next couple of weeks, hopefully using my partner as a guinea-pig (I’m sure she wouldn’t not like being compared to furry rodent, despite her feline qualities!). She’s working in London, and wants to leave her laptop down there, but she will still need to browse the web and stuff when she gets home for the Le Weekend. Rather than letting her “borrow” my Mac Book Pro, and have complain about where the DEL key is – I thought I would take her keyboard, screen and mouse – and plug them into the Pano. She’s always complaining about her old Jurassic Windows XP laptop being to slow – so perhaps she will find the virtual desktop experience a better one.
Well, OK – I guess now that View4 has been released you could say this is a little old hat. But… much I what I write about in View3 is much the same in View4! Honestly! Someday I plan to revisit this series of articles probably when VMware 4.5 is released… By then VMware will have thier PCoIP protocol working with the Security Server, and much better integration with ThinApp.
This was originally wrote for the vSphere4 book that recently became available on Amazon. But it never made the book because of length of the whole book, and difficulty of finding a good home for a chapter VDI. Thanks to the folks of TechTarget for taking my work and making it available.
Here’s all the articles I wrote about the NetApp Rapid Clone Utility 3.0 available on TechTarget.com. The three articles build as series to show you the full functionality of the NetApp RCU 3.0. At the time I wrote this – 3.0 was in beta but I imagine it has GA’d now.
Part one of the series describes what the RCU can do, and how its setup. Part 2 covers how you can provision new volumes from the NetApp Filer, and mount them to each and every ESX host as click of mouse. Finally, part 3 covers how you can quickly clone many VMs using the RCU – and then make those cloned desktops accessible by VMware View or Citrix XenDesktop
Following on from my recent “Chinwag” with Gabrie Van Zanten, this blogpost compares the relative merits of VMware View and Citrix XenDesktop. It raises the issue that a VDI project does offer the tempting possibility of considering other virtualization vendors other than VMware. It also posits the idea that by diversifying your virtual portfolio to be more multi-vendor you might reduce your dependency on a single virtualization vendor, build the virtualization team out of the striaght-jacket of being a VMware-One-Trick-Pony – and although your organization to really play one virtualization vendor of against another from a licensing perspective.
Just in case you have missed this – I recently had a series of articles published on searchvirtualdesktop.techtarget.com. The articles are all about VMware View. Originally, this was meant to be a chapter in my new book on vSphere4 (due at the end of Feb). But in the end the book just got too long – so I offered up the whole chapter to the folks at TechTarget.com. I guess its little bit out of date because soon after VMware View4 was released. But it is still mainly current – after all the biggest change in View4 is PCoIP – many of the concepts stay the same… I’ve promised techtarget to update the articles to View4 once I have time…
(I picked this title because I am a big Hunter S. Thompson fan – and I had plenty of fears before contemplating the upgrade! The loathing came later! [JOKE] Actually, the upgrade was no better or worse than any other I have previous undertaken. In fact compared to one nightmare upgrade from vCenter 1.0 to 2.0 it was a walk in the park. What follows is blow-by-blow account of my experiences – it got quite lengthy. If you want a quick summary – scroll to the end and just read the conclusions)
UPDATE:
Since writing this post – I’ve had a thought. What if I’d fully patched the ESXi host first with vCenter4.0 BEFORE upgrading vCenter4.0 to vCenter 4.0 U1. Would that have stopped the disconnect from taking place? I can’t test that approach myself – but I would LOVE to hear from those who can. So I can perhaps find a work around to the disconnects that took place in my upgrade process.
Well, it’s the time already – a new update to VMware’s flagship virtualization platform – vSphere4. I probably would have not upgraded from 4.0 to 4.0 Update 1, if it hadn’t been for the almost simultaneous release of View4 and the eagerly awaited – PCoIP protocol. One of View4 pre-requisites is for vSphere4 U1. Despite this I started of with a deploy of View4 on vSphere4.0 to see how hard and fast that “pre-requisite” was. In truth I was a bit nervous (perhaps more than normal) about this Update 1 roll-out.
Well, I thought it would be nice to discuss the attributes and features of VMware View4 new PCoIP protocol which will be released very shortly. In case you don’t PCoIP stands for PC over IP – and then intention is to deliver remote display protocol which rivals “legacy” thin-client protocols such as RDP/ICA with a new protocol that offers a “PC-like” experience over the wire. Historically, protocols like RDP/ICA have not performed will in graphics intensive applications like scanning, CAD, and streaming video.
If you want to see what PCoIP looks like to the end-user – prior to the GA some folks have put videos up on youtube.com. Of course, the quality of those videos vary – how ironic!
VMware’s main competitor in this will be Citrix XenDesktop’s HDX protocol. It’s been a long time in the gestation. VMware has been talking about PCoIP for some time, and its been an on-going project with Teradici which historically has specialized in hardware and software bases remote display delivery. VMware View4 delivers a software experience, but the co-development will allow smart terminal manufacturers to fit graphics cards that leverage hardware based graphics acceleration.
Since View3.1, VMware has endeavored to support other protocols such Sun’s Appliance Link Protocol (ALP), and HP’s Remote Graphics Software (RGS). Additionally, by supporting RDP – they pushed out the envelope beyond just supporting virtual machines, but access to Blade PC and Terminal Services. VMware wants to continue supporting these other protocols – but the hope is over time that folks will favour PCoIP.
First things first – some practical things. There is no “special” client or agent for PCoIP that has to be installed and configured – PCoIP is built-in to both the View Agent (installed to the VM) and the View Client (installed to the Windows PC – it’s an optional component). Incidentally, you mist install the FULL View Client (not just use the View web-pages) to get the PCoIP driver installed to the client device. Installing the agent installs special audio and graphics drivers (codecs) into the virtual desktop. You would expect that with all this capacity for graphically rich user experience that PCoIP would be undesirable on the WAN. However, according PCoIP can degrade the user experience to compensate for increase in latency or narrow-bandwidth.
It’s perhaps with that sentence that I should issue disclaimer. After this point much that I’m going write is based on me reading documentation. I wasn’t allowed on to the View4 beta programme. In fact a great many of peers (other vExperts) weren’t on the View4 Beta Programme. I’ve been told that many of the FTSE 100 companies – weren’t on the beta programme either. In fact its been one of the most elusive beta programmes that VMware has run in recent years. So its VERY difficult at this stage to really properly benchmark these claims for performance. The other thing I would say, is even if this FUD turns out to be groundless – there maybe other reasons to with this implementation of PCoIP that might make it a “LAN” based technology rather than a “WAN” or more properly speaking a “Internet Protocol”. I dare say there will be al ot of FUD around the PCoIP protocol, and in fairness VMware will only have themselves to blame – after making access to the beta programme so exclusive. With that said, beta code is notorious for being unsuitable for true bench tests – it still has debug symbols included in it – with GA code doesn’t. Anyway, according to VMware – even if you WAN link displays 150ms-250ms latency – PCoIP will still deliver satisfactory performance. As I write this – I’m sat in a hotel in Bergen, Norway – ping my equipment in Nottingham, UK. The latency is 55ms via the hotel Wifi link. Latency is often seen as the be all and end all when it comes to remote desktop displays – in my experience the frequency of dropped and retransmitted packets are as important. The maximum my latency has been (while I was typing this article) was 452ms and I lost 3% of the packets during that time.
Anyway, before I go further let have a look at the features of PCoIP – and explain how it manages to achieve it magic. PCoIP gets most of acceleration from special codecs which process the graphical data to the users screen – the clever bit is that PCoIP can identify different graphical components – and then render that portion the sceen with the correct codec. So if you think about the screen – that screen will built with many graphical components such as icons, video, text, photos and the kind of graphics that you might see in PowerPoint or Excel Charts. PCoIP has a codec for each type, and can idea the types of screen content and then render with the right codec.
Another critical feature is “progressive build”. But very simply PCoIP races to get the information to the user screen as quickly as possible – in a lossy format. Typically, a web-page will show text, first and basic image. Then quickly and in the background these images get progressive sharper and better quality. This is particular good for rapid web-browsing (where the user goes backwards and forwards rapidly) because the user isn’t waiting for images to be built slowly – in a line by line - pixel by pixel basis – like RDP does.
Anyway, putting aside these core components there are some other PCoIP features which you should be aware of:
Multi-monitor Support (4 displays of the same resolution
32-bit colour
1920×1200 Resolution
Clipboard functionality (Cut & Paste Text to/from local device to PCoIP Session)
Control Bandwidth allocated to media formats like Flash (think youtube.com!). This is done by the View Agent installing a special control into the web-browser – so the system is aware it is running inside a virtual desktop. It then uses the VMware Adobe Flash Optimizer to control the bandwidth for different “Flash” experiences such as youtube.com or interactive flash demonstrations
USB is supported
Multimedia redirection is supported if the device supports (this is where video is played locally using local graphics/audio control – and redirected away from the ICA/RDP/PCoIP session
So far – wonderful stuff. OK, well I guess it time of the downsides – because they always are. In View3, VMware acquired a license for “ThinPrint” which they dubbed “Virtual Printing”. It’s a not full implementation of the ThinPrint product incidentally. Virtual Printing and PCoIP are incompatible. This means unless you procure a solution that IS compatible – you will be forced to use native printer drivers – which eat up precious bandwidth. In fact, printing has been the bane of everyone’s life who operates in the thin-client arena. I speak as someone who started with NT4 and Citrix MetaFrame 1.8 and finished with Citrix Presentation Server 4.5
PCoIP must be currently used with “Direct Connection” to the View Connection Server. Currently, PCoIP is incompatible with VMware Views “Security Server”. In case you don’t know. Connection Servers sit on your private network, and are joined to domain. As such you should never put them in a DMZ because they are vulnerable. Security Servers on the other hand are designed to facilitate firewall traversal – and are suitable for the DMZ. If you unfamiliar with the relationships my buddy, Tom Howarth who has real world experience of VMware View implementations has this handy diagram:
This is quite important limitation. It means any existing View implementation that uses a combination of Connection & Security Servers – cannot be used with PCoIP. It means introducing a different access mechanism - such VPN connection to make the PCoIP protocol secured with SSL and ”firewall friendly”. Those of you have been this business for while will now that although this limitation isn’t a show-stopper as such – it’s a stumbling block. Historically, users haven’t like VPN clients. They can be arse to setup and get working. And most users who rarely appreciate the distinction between the [SHIFT] key and the [SPACEBAR] rarely appreciate the reason why the VPN session must be brought up first before they can do any work. Certainly, most Citrix and View end-users are used to cranking up client or web-browser – typing in their username/password – and getting their desktop. PCoIP will work with 128-bit SSL, but again its unclear what the performance overhead might be with that additional payload.
You might be interested to know why a PCoIP session can connect to Connection Server, but not Security Server. It’s quite simple. PCoIP sessions are established with UDP packets (Port 50002 to be precise) to the Connection Server – and Security Servers only support TCP sessions. Whilst the PCoIP protocol does have built-in encryption – its not clear at this stage how this SSL session established. From what I tell it is NOT certificates based, but generated by internal algorithm. This is very similar the kind SecureICA that existed in the early Citrix MetaFrame product – prior to the introduction of certificates based encryption with things like the Citrix Secure Gateway and the Citrix Access Gateway. It’s fair to say that the competition (Citrix) has in the past introduced feature such as “Session Reliability” which have in the 1st instance been incompatible with their Security Systems. So to some degree ALL the thin-providers are guilty of this:
“Here’s brand new feature that massive improves performance and the user-experience – Oh, and by the way its incompatible with all our firewall traversal products…”
The good news is View4 is configurable in such way – that you could allow the user to select PCoIP if they were on the corporate LAN, and use thinner-more firewall friendly protocol when they are on the WAN/Internet. Whether they appreciate the difference is any one’s guess! By default the preferred protocol is PCoIP unless changed by the administrator or the end-user in the client.
On the audio side – PCoIP does support high quality audio OUTPUT, but it currently lacks an audio INPUT. This means such devices as voice-recorders – popular say in hospitals where doctors/consultants like to “record” their notes would have be delivered some alternative method.
So. There we have it the good, the bad and the ugly. Certainly our industry has been crying out for replacements for RDP/ICA for some years – and both Citrix and VMware have put some good R&D into the new protocols. Clearly, PCoIP is work in progress – and there’s much that can be done in the world virtual desktop to improve the manageability such as good deployment tools – and the flexible ways of delivering the apps to the virtual desktop. Additionally, there are still specific weakness in the world of printing and bolting down the desktop – where old methods such as Microsoft GPOs simply don’t cut the mustard. There are interesting days ahead!
Someday I plan to revisit this series of articles probably when VMware 4.5 is released… By then VMware will have thier PCoIP protocol working with the Security Server, and much better integration with ThinApp.
RSS
iTunes
