As a hosting provider’s systems engineer, I had the task to give console access to our customer’s virtual machines. Because we built our vSphere network infrastructure to a private network of course, therefore we did not give vCenter access to our customers directly, they have a separated public management server and web interface which connects to this private network. Between the public user interface and private network, we are using the vSphere Perl SDK to manage customer commands. (like deploy vm, poweron, poweroff, …)
I’m pretty sure this scenario is familiar most of you who works in hosting environment, so the only one question is, how to set up the console and give it to the customers? You have plenty of options available, but most of them did not work by the way. 🙂
First and imho the best option was the pre-authenticated console. Lamw has a very good how to about this. I must confess, I have used this solution. The only problem is that this does not work in vCenter 6.0 and above. You can see in the post’s comments, the authentication has been removed by VMWare. and when you try to use pre-authenticated console, it will redirect you back to vCenter login page. I spent many days to find a way to bypass this block, there are some useful information in the VMWare community portal how to get the Jsession ID and use it, but after a lot of trying it leads me to a dead route.
The third and finally working option for me is the VNC console. The concept to make this work looks like this:
- Open some ports for VNC in your ESXi machines
- Set up the VNC port, password in your virtual machine
- Integrate a web VNC and a proxy (noVNC in my case) into the customer interface code
Okey, let me show you how it works in practice:
First of all, log in to your vCenter server or ESXi hypervisor. Select your ESXi host (hosts and clusters) and under Configure tab, under System box, select Security profile. In the firewall section, select edit, then look for gdbserver and tick the checkbox, then click ok.
This will open the firewall ports from 1000 – 9999 and from 50000 to 50999 which can be used to configure VNC ports in the VM configurations. Optionally, you can set the allowed IP addresses for extra security. Only your customer manager server’s internal IP address need to be allowed.
After you finished it, the firewall ports will opening. Now the virtual machines must be set, to listen for VNC requests. To do this, select one of your VM, be sure it has turned off state. Select Configure tab, under Settings box, VM Options. Click to edit, drop down to Advanced, then click Edit configuration. You will see the Name and Value boxes in the bottom. Add each of this three name and value pair:
Name: RemoteDisplay.vnc.enabled Value: true Name: RemoteDisplay.vnc.port Value: 50011 Name: RemoteDisplay.vnc.password Value: yoursecuretpassword
Then click ok to save the settings. Now you can power on your virtual machine.
At this point, you can fire up you VNC client (Tight VNC or anything that you like) and test these settings. Connect to your ESXi server’s IP address and the dedicated port which you set up above in the VM. The VNC client should ask your password, give it. If everything went fine, you will see your VM up and running.
Of course, you can automate this procedure using lamw’s vmAdvSettings.pl script. This script written to vSphere Perl SDK (which I use in unix environtment) but I’m pretty sure you can find example scripts for this task to Java or C# SDK. The script works as any other vSphere Perl SDK script, but I give you some examples for this case:
./vmAdvSettings.pl --username "firstname.lastname@example.org" --password "vCenter password" --server "vcenter.host.domain" --vmname "your-vm-name" --operation "update" --key "RemoteDisplay.vnc.enabled" --value "true" ./vmAdvSettings.pl --username "email@example.com" --password "vCenter password" --server "vcenter.host.domain" --vmname "your-vm-name" --operation "update" --key "RemoteDisplay.vnc.port" --value "50011" ./vmAdvSettings.pl --username "firstname.lastname@example.org" --password "vCenter password" --server "vcenter.host.domain" --vmname "your-vm-name" --operation "update" --key "RemoteDisplay.vnc.password" --value "yoursecretpassword"
Almost done, you just need to download a VNC proxy, which will connect to the VM’s VNC port as you tested it below. Because you need to give something to your customers too, it should be a nice web access VNC coded in HTML5. Good news, noVNC have both in one. Of course, you can use anything else you want, but I made my decision to use noVNC.
In the example, I assume you are using one of the Linux systems (RHEL or Debian based are both good) for your customer manager portal, which has a network access to the public internet where your customers can reach it, and a private network where it can reach you vSphere system. I also assume that your webapp which your customers see via your public domain installed to /var/www/html
First of all, download noVNC from https://github.com/novnc/noVNC/archive/master.zip and unzip it into your webapp dir into a separated folder. (In my example, to: /var/www/html/novnc) noVNC has a websockify proxy which will handle the requests between the HTML5 VNC console and the VM. Start it first:
/var/www/html/novnc/utils/websockify/run -D --web /var/www/html/novnc/ 6011 esxi.host.domain:50011
The last part, connect to the websockify process with noVNC. You need to call the right URL, nothing more: http://customer.manager.public.domain:6011/vnc.html?autoconnect=true&host=customer.manager.public.domain&port=6011&password=yoursecretpassword
That is all, if you see your VM up and running, then you made everything fine.
This solution is tested in 6.0 and 6.5 environments, everything works perfectly. No ticket or jsession id hacks, so I think it is the clearest way to make it.