KVM from the other side of the world

I manage two second hand enterprise servers on the other side of the world. This is how I remotely manage them.

Published 29. November 2024

Using old KVM software is known for being a huge pain in the ass, with the old Java applets for many reasons being incompatible with modern systems. Accessing the KVM from outside their native network is even trickier. Around once a year I need to perform some kind of maintenance on them, and I forget what I did to access them between each time. These notes are for me, but someone else may also find them useful:

If you have access to a jumpbox with Docker

Use a KVM to VNC docker container. These run an X server together with a VNC server in a container set up to run these ancient Java web start applets. There is usually also a webui you can use to access the inside of the container without a VNC client. However, I think it's easier to just use a VNC client so keep that in mind. These kinds of containers seem relatively well known in the homelab community.

Here are a few suggestions:

I tried fighting with the KVM javaws applets to make them work. It was not worth my time. It's not worth your time. These containers are so much easier.

Jumpbox with no Docker (and routers/etc)

Even if you don't have access to a machine with Docker on the same network, you can still access the KVM. All you need is SSH access to something - this includes the router itself.

SSH port forwarding is your friend. the KVM platforms often use port 5900(wonder why). When it comes to port 80 and 443, don't rewrite them to some other port, as some KVM platforms dislike this(I guess they inspect the Host header?). Simply ssh -L 0.0.0.0:80:<kvm_ip>:80 <ssh-server>. The 0.0.0.0 part is not normally required, but is useful if you plan to access the forwarded port from inside a Docker container. You will also need to run a similar command for any other port needed by the KVM software - usually 5900 and possibly 443.

Instead of running Docker on a jumpbox, you can run it locally. However, this has a big caveat: you generally can't use host networking as port 5900 is used by both VNC and most server KVM software i have seen. Instead, set the KVM host to be the predicted IP address of the host on the network spun up for the pod by Docker. If you use docker compose (which you should, unless you want to use bash history to relaunch Docker containers), the ip address is simple to predict: Docker allocates /16 subnets starting from 172.18.0.1/16. Simply see what the last used address range is and add 1.

What is happening here is that your docker container is set up on a virtual network in which your computer acts as a router. If you port forwarded the KVM server with a listening port of 0.0.0.0 as above, the forwarded ports will be available on any IP address belonging to your computer - including its IP address inside the virtual Docker network. Of course, instead of 0.0.0.0 you could use the same value you used for the KVM host setting on your docker container (assuming it is correct). The main clue here is that not providing a listen IP would cause ssh to default to 127.0.0.1, which is an IP not reachable by Docker containers not running with host networking enabled.