Virtual Machine Console Access with Platform9
Have you ever botched your VM’s network configuration? Maybe you forgot to allow SSH traffic in your firewall settings? How do you fix the network configuration when you cannot even SSH into your VM? One usually sits in front of their physical machine to fix such issues. But with the advent of virtualization, there is no physical machine to fix. So how does one sit in front of their broken virtual machine?
One solution is provided to us by the Virtual Networking Computing (VNC) system. This system allows users to “sit in front” of their virtual machine’s console or graphical user interface by displaying bitmap images of the remote machine’s default display.
Platform9’s 1.2 release a few months ago added virtual machine console access through the web browser which provides an out-of-band access for your instances. Our VNC implementation is similar to what is typically deployed with other OpenStack based clouds but the Platform9 implementation has been modified to support our SaaS model. In this post I will explain how Platform9 delivers VNC to your web browser and answer some frequently asked questions.
Supposed we have the following setup:
We have two hypervisors with two VMs running on each. When a user tries to access VM1’s console, the client (the web browser in this case), sends a request to the Platform9 controller which then gives it an access url of the form http://<console_endpoint>:6080?token=<token>, where console_endpoint can be the IP address of the hypervisor (or the VMware Gateway in the case of VMware deployments). Once the client receives this url, it can begin initiating the connection for console access.
One may ask if console_endpoint has to be externally accessible from outside a company’s firewall and the answer is no. In fact, in Platform9’s lab environment, our hosts aren’t accessible outside company firewall. To access a VM’s console in this case, we have to be connected to the company VPN. Since the console_endpoint isn’t accessible from the Internet, no VM console traffic ever leaves the company’s datacenter. However, this is not necessarily need to be the case. One may choose to serve VNC traffic over the Internet if need be—console_endpoint just needs to be accessible from outside the company’s firewall. The console_endpoint can also be a 1:1 NAT mapping that maps externally accessible IP address to the private internal IP address of a hypervisor or the appliance in case of VMware.
Continuing on, all VNC traffic from VMs in hypervisor 1 (10.1.0.2) will be served over 10.1.0.2:6080. Similarly, VMs residing in hypervisor 2 will be served over 10.1.0.3:6080.
This multiplexing and demultiplexing of VNC traffic is done by the pf9-novncproxy service running on each hypervisor. This service takes care of proxying RFB packets to websockets so that a web browser may be able to consume it. The web browser then processes this data into images for the user to see. Client side scripts executed in the browser take care of capturing input from the user and sending them back to the proxy which is then passed to the VNC server.
With VMware, a similar scenario happens. The only difference is that the pf9-novncproxy service is running on the appliance and not on each hypervisor.
How does Platform9 make this easy to configure? During host authorization the cloud administrator is able to select which IP address (if the hypervisor has multiple) the VM console traffic is served. Platform9 agents on the host take care of starting the required services as well as configuring the hypervisor to enable the functionality. No need to edit any configuration files! (KVM only—this will be a footer). As of this writing, the VMware appliance automatically sets the console_endpoint by using the appliance’s IP address.
Some frequently asked questions:
Q: Does my instance need an IP address/network connectivity for VM console to work?
A: No. The novncproxy service connects directly to the host of the instance to serve VNC. Think of this as actually sitting in front of the machine.
Q: Do I need to be in the same subnet as the hypervisors to be able to connect to the VM console.
A: No. If the console_endpoint is routable from where you are trying to access the console, then you should be able to connect to your VM’s console.
Q: Do I need to be in the same vlan as the hypervisors?
A: No. The service sits on top of the network layer (L3) so it doesn’t matter which L2 segment you are on.
Q: How do I access a VM’s console outside my firewall?
A: You need the console_endpoint to be accessible outside your company’s firewall.
- Beyond Kubernetes Operations: Discover Platform9’s Always-On Assurance™ - November 29, 2023
- Platform9 Introduces Elastic Machine Pool (EMP) at KubeCon 2023 to Optimize Costs on AWS EKS - November 15, 2023
- KubeCon 2023 Through Platform9’s Lens: Key Takeaways and Innovative Demos - November 14, 2023