The Client Integration Plug-in provides access to a virtual machine's console in the vSphere Web Client, and provides access to other vSphere infrastructure features. The Client Integration Plug-in also lets you log in to the vSphere Web Client by using Windows session credentials.
More interesting is the list of the workflow functionality not (yet) supported in the vSphere Client (for a complete list of supported and not supported functions see this post). Of course, the list of functions depends on the version of the new client web. Vmware’s vCenter client for Apple iPad was released this week to the Apple App Store. The download is free and the application itself provides mobile access to your virtual infrastructure.
I've downloaded and seem to have successfully installed, however when I try to use it, vCenter acts like the plugin is not installed.
The log file, in ~/VMware/CIP/ui/sessions/session_0000/logs/csd.log
, includes messages like:
Running the 'vmware-csd-installer' gives some hints of a problem:
Mark Henderson♦The apparent solution I found was to create a folder and some symlinks, and then run the main GUI installer for the plugin again:
The issue is that the installer finishes, but silently fails due to missing libraries, libraries that probably existed in earlier OS X versions.
Because the libraries don’t exist, necessary certificates don’t get generated, and even re-running the installer from the application directory won’t solve it (including with the below hack). What you need to do is ensure the libraries will be there when the installer gets to the “Running package scripts…” section on initial install.
There are a number of possible solutions, including the one above, but the below seems the cleanest and doesn’t require multiple installs.
Before installing the application, do the following:
Then run the full installer.
This will create a hack to allow the packaged libraries to be used when the package scripts get run. If it’s working correctly the “Running package scripts…” will take many minutes to run as it executes “openssl” to generate the following:
If it instead installs very quickly, you can be fairly certain it didn’t installed correctly and probably VMware has changed something yet again. If it works, you can both upload files and deploy OVF files.
Last year, a standalone Virtual Machine Remote Console (VMRC) was released for Windows as part of vSphere 5.5 Update 2b which provides an alternative way of launching the VM console due to NPAPI deprecation. There was of course a huge request for Mac OS X support and the VMRC team has been working hard and today I am please to announce that standalone VMRC is now available for Apple Mac OS X which you can download using the following URL: www.vmware.com/go/download-vmrc
Note: Mac OS X 10.8 or greater is required to use the new Standalone VMRC. The release notes will be updated to reflect this requirement
There are currently two methods of launching a remote console to a Virtual Machine using the vSphere Web Client as seen in the screenshot below:
If the problem persists, please disable “SnailGit Extension” in “System Preferences » Extensions” and then enable it again. A: SnailGit supports the following URL schemes: – – – git:// – ssh:// Q: Does SnailGit work well with other Git clients? Q: What kind of URL schemes does SnailGit support? The last resort is to relaunch Finder or restart your computer.
When using the Standalone VMRC method, instead of opening the VM console in the browser, it will launch the native VMRC application on your system whether that be Windows or Mac OS X. All basic functionalities of the Standalone VMRC is available as you would expect such as power operations, device management, etc.
Note:There is not a specific version of vSphere that is required to directly launch the Standalone VMRC. However, to launch it within the vSphere Web Client, you will need vSphere 5.5 Update 2b or greater.
The other great thing about the Standalone VMRC is that it can function without vCenter Server and the vSphere Web Client and you can actually use it to connect to VM directly on an ESXi host. To use the VMRC without the vSphere Web Client, you will need to construct the VMRC URI which looks like the following:
vmrc://clone:[TICKET]@[HOST]:[PORT]/?moid=[VM-MOREF]
where TICKET is obtained by calling the AcquireCloneTicket() method using the SessionManager in vCenter Server. The HOST will either be the Hostname/IP Address of vCenter Server and the PORT should be default to 443 and you will need to specify the VM MoRef ID. In the case of a standalone ESXi host, you would just change the HOST property. If you do not wish to use the clone ticket, you can also just provide the following URI which will prompt for your ESXi credentials
vmrc://@[HOST]:[PORT]/?moid=[VM-MOREF]
Once you have generated the VMRC URI, you MUST launch it through a web browser as that is how it is passed directly to the Standalone VMRC application. In my opinion, this is not ideal especially for customers who wish to automatically generate this as part of a VM provisioning workflow to their end users and not having to require a browser to launch the Standalone VMRC application. If you have some feedback on this, please do leave a comment.
In the mean time, a quick workaround is to use the 'open' command on Mac OS X along with the VMRC URI which will automatically load it into your default browser and launch the Standalone VMRC application for you.
open 'vmrc://clone:cst-VCT-52e44ad7-712f-9f45-a9ee-13ec6a74acaf-[email protected]192.168.1.60:443/?moid=vm-18'
UPDATE (05/31/15) - If you are connecting directly to an ESXi host you can either use the vSphere API to query for the VM MoRef ID or you can easily pull it by running the following command directly in the ESXi Shell:
vim-cmd vmsvc/getallvms
I am sure there are probably a few of you asking, what about for Linux users? Well, you can probably guess what is being worked on next 😉