Today was a documentation day. Yippee! Oh Visio, how you manage to manipulate the simplest lines into complex, tangled webs, one will never know.
What I do know is that PCoIP provided an excellent user experience when working with graphics in Visio. One of the great features of PCoIP is that it builds the image to full quality over time unlike some other protocols that will generate a fuzzy image when bandwidth is unavailable. Indeed, a nice feature when working with graphics and attempting to read the small print on drawings. Dragging objects, working with text, connecting devices, and editing images were all accomplished from within the virtual desktop with no frustrating waiting while the image is redrawn as in RDP. Keep in mind I am accessing a virtual desktop in Steelhead Data’s cloud in Sacramento, CA from my home office in Portland, OR.
Scott Davis, VMware View CTO, does a great job of describing the PCoIP technology in his blog…
More importantly, by transmitting compressed bitmaps or frames, we can adjust the protocol in real time to account for the available bandwidth and latency of the communications channel. On a WAN connection with typically less bandwidth and higher latency, a less crisp image is produced quickly, typically with 0.2-0.5 bits/pixel producing a grainy, but still recognizable image. Kind of like an analog TV… This rapidly sharpens with increasing clarity and detail visibility with each succeeding frame until the image is perceptually lossless. This is a high quality image at a total of approximately 1-3 bits/pixel. Think of it as now Digital HD to stick with our TV analogy. On a higher performance LAN, the images become sharp instantly and will build to complete lossless at 5-15 bits per pixel. Think of it as Blu-Ray!
After completing some documentation, I shifted over to responding to customer requests in our managed services platform where we host VMware View desktops for businesses. Pros to using a View desktop: My desktop is located in the datacenter with the managed environment so connectivity to the infrastructure is fast and easy. Running tools such as the vSphere client to access the console of VMs from within the View desktop provides a better experience than if I run the same tool over a VPN connection on my local client. In the past I would have made a similar connection into a terminal server or Citrix environment where I could then access these tools. The difference here is that I have my own dedicated desktop where I get to install the tools that are useful to me like the great automation tool from thevesi.org for performing tasks in a vSphere environment. Or maybe I want to use the Webex one-click application. This is not something that I would want to install on a shared terminal server but it’s my desktop and I’ll do as I please! If an application decides to misbehave, I have the option of rolling back to a snapshot or refreshing my desktop to a point where it is running like a well oiled machine. Try doing that on a terminal server or traditional desktop.
This post is part of a project I am undertaking where I will be using a VMware View desktop for - hopefully - all of my work computing. See more by clicking the "myview" tag.
I was only at the keys for part of the day today so there wasn’t too much interaction with my VDI, View, virtual desktop, whatever you want to call it. It’s tempting to call it VD for virtual desktop but that just seems wrong. One “fun” thing happened while connected from a café over 4G. I was working on a document and writing some emails when suddenly I got a message that my laptop battery was nearly dead and I should connect to a power supply. Oooops. No power outlet in sight. I decided to let it run out because there was no risk of losing the data I was working on. Add that to the list of things I did not consider as a benefit of desktop virtualization.
This blog is about the good and the bad so let me tell you about something that is really frustrating. In order to keep my work and personal computing separated, I have a personal laptop and thin client connected to a KVM (keyboard, video, mouse) switch to allow for sharing a single monitor, keyboard, and mouse. For some dang reason, the thin client recognizes the keyboard and mouse properly but often times – not always – when I connect to my desktop in the cloud, the keyboard and mouse aren’t recognized or I receive a prompt saying that they couldn’t be installed. GRRRRRRRrrrrrrrrr. This typically is resolved by connecting to the desktop using the View client on my laptop and rebooting it but sometimes just requires switching through the KVM connections or unplugging and reconnecting the USB plug. Any thoughts? Let me make it clear that I am running Windows 7 as my virtual desktop which is “experimental” according to VMware.
This post is coming to you from my VMware View virtual desktop “in the cloud.”
Let me start by explaining that I’ve promised some coworkers and colleagues that I will be attempting to use a VMware View desktop as my primary work computing device. I have a Wyse P20 in my home office and a laptop that I will use to connect to View. I live in Portland, OR, use Comcast as my ISP, have a 4G Clear wireless connection, and 3G through my Blackberry all of which I will use to connect to a desktop in Sacramento, CA. What’s the likely outcome? There will probably be some frustrating moments when I can’t get to the View environment or maybe I will be unable to resist viewing rich media on a local client. On that note, I can’t stop raving about my ability to stream Hulu through the virtual desktop with smooth playback and synchronized audio over my Comcast internet connection. PCoIP performance is fantastic! I’m sure my employer loves to hear that I’m watching TV on a desktop hosted in our cloud…
Today, I’m onsite with a customer working on a VMware Health Check report. A virtual desktop limitation that I encountered almost immediately is that I need to connect to their environment using remote desktop from my fat client that is plugged into their network. My desktop in the cloud can’t help me here. I guess technically I could VPN into their network from the virtual desktop but depending on their VPN policies I would almost certainly drop the connection upon initiating the tunnel.
However, I did manage to take my notes and customize the report within my virtual desktop. I’m using Microsoft’s Live Mesh to sync screenshots, performance captures, etc over from the fat client where I’ve copied these items from the customer’s systems over the LAN.
There are definitely some hoops that I have to jump through to make this all work out but two clear benefits are 1. The report and data is kept in the datacenter; 2. I simply disconnected the session last night with the document draft still open and it was waiting for me this morning when I launched the virtual desktop. One word: AGILITY! I can access my apps, data, tools… everything from anywhere that I have a connection. Which, with the prevalence of connectivity be it through 3G, 4G, or wifi, I rarely find a place where I cannot get connected. We’ll see what happens the next time I hop on a plane.
There are three methods for allowing Xen Desktop Delivery Controller access to VirtualCenter in order to create a new desktop group:
Allow HTTP access to the SDK on the vCenter (VirtualCenter) web server.
Modify the proxy.xml file on the virtualCenter server located in c:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\
Restart the VMware VirtualCenter Server service (vpxd) on the VirtualCenter host.
Import the defaul VMware SSL certificate into the Xen Desktop Delivery Controller. (not recommeded in a production environment because you must use the defaul certificate hostname of “vmware”
Copy rui.crt from c:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL to the Xen Desktop Delivery Controller server
Import the certificate into the Trusted Root Authority for the computer account
Open the Certificates Snap-in in an MMC console and choose to manage the Computer account
Expand down to Trusted Root Certificate Authorities and right-click on Certificates and choose Import…
Use the wizard to select the rui.crt file that you copied from the VirtualCenter server
Close the MMC
Edit the hosts file in %windir%\system32\drivers\etc with notepad and add the following and save the file:
vmware <ip of your virtualcenter server>
Use an SSL certificate from a trusted root authority.
This process involves creating an SSL certificate for you VirtualCenter server and configuring IIS to use this certificate. This is a well documented procedure. See VMware and IIS documentation for this procedure.