By Michael Haines, vCloud Architect
In Part 1 of this post, I inroduced the components of the VMware console proxy, remote console proxy, and how they work with vCloud Director. In Part 2, I'll cover resiliency of the remote console proxy, what ports are required, operations available to the user, and run through troubleshooting and tools.
7. How Resilient is the Remote Console Proxy?
The VMware Remote Console Proxy Plugin actually opens four different connections to the Console Proxy for a single Remote Console session (three for the vCenter server, one for the ESX/ESXi server). The Console Proxy is stateless, and therefore the Load Balancer can route each of those four connections to different Console Proxies and the system would still work perfectly fine. If a connection is dropped for some reason (e.g. the Console Proxy dies), then the VMware Remote Console Proxy automatically tries to re-establish it and the Load Balancer can route it through a different Console Proxy. The user should not notice anything but a small delay.
8. What ports are required to be open for the Remote Console Proxy to function correctly?
The vCD Console Proxy Plugin communicates with the vCD server only on port 443 via the Console Proxy. That is the only port that is required to be open and accessible from the Internet.
9. What operations are available to a user of the Remote Console Proxy?
The following functionality is exposed by the VMware Remote Console Proxy and presented and consumed in VMware vCloud Director:
- If the Virtual Machine (VM) is powered off and you connect the VMware Remote Console Proxy to it, it will implicitly power it on.
- Power Off the Virtual Machine (VM).
- Reset the Virtual Machine (VM).
- Suspend the Virtual Machine (VM).
- If the Virtual Machine (VM) is suspended, it will implicitly resume it on initial connection, similar to power on.
- Remote MKS interactions, including grabbing / un-grabbing input, and explicitly sending Ctrl+Alt+Del to the guest.
- Full screen support.
- Remote device support for CD-ROMs and floppies, whether physical or backed by file images, which exists on the client machine.
- Technically, it will let you connect these devices as server-side as well.
- If the Virtual Machine (VM) temporarily disconnects, such, as during reverting to a snapshot or the MKS connection is lost, the VMware Remote Console will try to re-connect.
The VMware Remote Console Proxy behaviour is to automatically power on and resume the Virtual Machine (VM), if it is powered off or suspended when you open a console to it. However, vCD allows you to open a console of a Virtual Machine (VM), only if the state of the Virtual Machine (VM) is powered off. This behaviour is enforced by vCD and not the VMware Remote Console Proxy.
Here are some of the most common things to check if for some reason you are not able to use the Remote Console Proxy:
- Does `netstat -nape | grep 443` show a java process listening on the IP Address that you specified as the (internal) console proxy IP Address when running the configure script? This should also show port 443 open on the HTTP service IP.
- Can you telnet to port 443, 902, and 903 on the vCenter server from the vCD server?
- Can you telnet to the public console proxy IP on port 443 from outside of your Load Balancer?
- Do the VMware Remote Console Plugin logs, which exist on the client, tell you anything? On Windows clients, the VMware Remote Console Plugin logs are typically found in C:\Documents and in Settings\LOGINUSER\Local Settings\Temp\vmware-LOGINUSER. The file names follow the pattern of vmware-LOGINUSER-VMWAREVMRCPID.log and vmware-VMWAREVMRCPID-mks-LOGINUSER-VMWAREREMOTEMKSPID.log. On Unix clients, the VMware Remote Console Plugin logs are typically found in /tmp/vmware-LOGINUSER. Again, the file names follow the pattern vmrc-VMWAREVMRCPID.log and VMWAREVMRCPID-mks VMWAREREMOTEMKSPID.log.
- Do the Console Proxy logs tell you anything? The Console Proxy logs al its activity in the same way as the rest of the vCD server. Its logs therefore can be found in <vCD dir>/logs/vcloud-container-info.log and vcloud-container-debug.log.
The following python script can be used to get a Virtual Machine (VM) console through the VMware Remote Console Proxy. The script expects curl and vmware-vmrc to be in your path. This script has currently been tested on Linux and Windows. The latest version of the script, version 1.0.2 is able to work on windows by using python and curl compiled for windows. In addition to this on Windows we have tested both with and without the cygwin shell. If you get the following when you try and run Vmrc-mks.py as follows:
$ python Vmrc-mks.py
Traceback (most recent call last):
File "Vmrc-mks.py", line 13, in <module>
ImportError: No module named argparse
This is because this script requires Python 2.6 or later and the argparse package, which is not always installed with the default distribution. This can be found at:
The script performs the following:
- login to vCD
- request screen ticket
- parse the mks://… URL and extract the host/vm moref/ticket
- decode the URL-encoded ticket
- pass proper arguments to vmrc
usage: vmrc-mks.py [-h] [-v] -c CREDENTIALS [–curl CURL] [–vmrc VMRC]
Script to process and acquire the VM screen ticket from the vCloud REST API.
acquire_ticket_uri URI to acquire ticket action:
https://<vCD Cell Host>/api/v1.0/vApp/vm-265481682/screen/action/acquireTicket
-h, –help show this help message and exit
-v, –verbose verbose messages
-c CREDENTIALS, –credentials CREDENTIALS
credentials in format user@Org:password
–curl CURL point to curl executable, default is "curl"
–vmrc VMRC point to vmrc executable, default is "vmware-vmrc"
vmrc-mks.py -c vcloud@system:vcloud https://10.10.10.2/api/v1.0/vApp/vm-265481682/screen/action/acquireTicket
Providing the VMware Remote Console clients (VMRC) functionality in vCD allows you to access multiple vCenter and ESX/ESXi servers from a single location. This is useful, as it allows the cloud provider’s to "hide" the structure of their vCenter servers and ESX/ESXi servers where the Virtual Machine’s (VMs) are located. In addition to this, the VMware Remote Console clients are stateless and therefore provide both scalability and availability.