vsphere_static_160x300
Free Business and Tech Magazines and eBooks
Badges

vexpert_logo_100x57

gestaltitbadge

follow-me-twitter

Subscribe to me on FriendFeed

Comments / DISQUS
Feedjit.com

Using vSphere Client on Ubuntu Linux with Single Application RDP

I have periodically attempted different methods for running the VMware vSphere and VI Client (VIC) on Ubuntu. While continuing to keep my fingers crossed for VMware to release a Linux version, I’ve tried several workarounds only to remain unsatisfied:

  • installing the VIC with Wine
  • Locally running Windows virtual machines in either Virtualbox or VMware Workstation/Player
  • Used the ESX web client when possible (features are limited)
  • Used a full Remote Desktop to vCenter

The method with the least pre-configuration necessary has always been a remote desktop with the VIC already installed, but there is always some untimely inconvenience involved when working between two different desktops.

Long story short, the rest of this post is about using the default Ubuntu Terminal Server Client to access a single application via RDP. This is perfect for using the vSphere Client or VIC on Linux. It does not require a “published application” or full Terminal Server, but instead it is a simple way to take advantage of the administrative RDP connection from the standard Remote Desktop access available on any Windows operating system.

Before I describe how to set this up I want to also reference my first try at RDP directly to the vSphere Client and VIC. Afterall,

the first attempt is what started me down this path, and readers may find some value from where I’ve already moved on.

I originally ran across Brian Atkinson’s Blog: vSphere client for Linux (sort of)… and I was intrigued by the idea of being able to use SeamlessRDP and the Linux application rdesktop to access a single Windows application remotely. It’s simple enough to download the SeamlessRDP.zip file and expand it on the Windows server with the VIC installed. Entering the Ubuntu Terminal command is not difficult to script, but the experience for me was always “buggy”. Maybe it was because my SeamlessRDP sessions were to the vCenter server which, more times than not, was a VM itself? It just wasn’t a very reliable session. I came to the conclusion that calling the SeamlessRDPshell application in order to run the VMware Client most likely is not an efficient way to get the job done. Check out the post at the link above for the full details.

The concept of a RDP session to a single application stayed with me as a great idea, and it wasn’t until I participated in a brief and unrelated conversation about the latest features of Microsoft’s RDP client that it dawned on me to explore the default Terminal Server Client which is now under Applications > Internet in Ubuntu. Eureka!

The General Tab should be very familiar to anyone connecting remotely to Windows servers

I choose to use a specified screen size for each session, but experiment with the settings on the Display tab to achieve what works best for you

The Local Resources Tab is key. For convenience be sure to allow access to your local Ubuntu drive(s).

The Programs tab is where the session to a single Application is configured. By default the vSphere client is installed at:
“c:\Program Files\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\VpxClient.exe”. This varies depending on 32bit versus 64 bit OS, but once you have the correct path enter it here.

Save the RDP configuration with the Save As button for repeated use.

Here’s a sreen shot of the vSphere Client open on 32 bit Ubuntu 9.04.

Exiting the vSphere Client exits the RDP session, but clicking the “x” to close the window leaves a disconnected session on the remote server. This can result in a scenario where the maximum of 2 connections is exceeded if you are not careful. Be sure to tweak the MS Terminal Services Settings from the Administrative Tools Menu so that idle and disconnected settings end in an appropriate amount of time (I’ve been using 15 minutes) to prevent this from happening.

All in all it is still a work around, but in my opinion it has been the most reliable and feasible one. It doesn’t eliminate the need for at least one Windows desktop in your environment, but if you have vSphere or VI3 your are probably going to have vCenter anyways, right?

Related Posts

  • Oh... My. Quite useful, quite useful indeed.
  • Yes it is. I'm also now using single app rdp to IE7 to get to full
    OWA. The lite version in Firefox is just not the same!
  • Have you tried Unity with Workstation? Another way to work around the same problem.
  • Sure. I've used locally hosted VMs via seamless windows. Sometimes
    it's not worth the effort to build a VM on multiple pcs, or if the
    desktop I'm on has limited CPU and RAM installing a host hypervisor
    and running a VM isn't a good option.
  • Good read. I like your solution better! Its cleaner and doesn't rely on 3rd-party add-ons to the vCenter server, which sometimes makes security people start asking lots of questions.
  • Brian,

    Thanks and "cleaner" is a great way to describe it. I don't have performance stats to back it up, but my experience has been "snappier" even over the WAN. I wonder if RDP to a single application has a smaller overhead then full desktop?
  • Rich,

    Very quickly comparing the three options is interesting:
    1.) RDP session with a full desktop and VpxClient has seven processes running
    2.) seamlessrdp session with VpxClient has five processes running
    3.) RDP session with the single program (VpxClient) has three processes running

    The three processes in #3 above are also present in #2 and #1. The RDP session with a program (#3) is the base, if you will. The other options simply add more overhead on top of these same three processes.

    The full RDP session has the most overhead, as it supports a desktop (explorer.exe) and anything running in the system tray - this included an antivirus process in my tests. The RDP with a program option you presented definitely requires the least amount of overhead.

    My tests weren't very thorough or extensive, but I suspect that delving deeper into this with my handy sysinternals detective kit would most likely only further prove the point.
  • Brian,

    That's good enough proof for me, but if you invstigate further let me know.

    Playing "devil's advocate" for further comparison:
blog comments powered by Disqus
Hyper9 Cowabunga
Support VM /ETC
Support VMETC.com

Support VMETC.com

@rbrambley tweets
Advertisements
VMTN Roundtable Podcasts
Subscribe



Add to Google Reader or Homepage
Subscribe in NewsGator Online
Add to netvibes
Add to Plusmo