Inchoate Curmudgeon

While looking for an OS X alternative to the ESX Virtual Infrastructure CLient for accessing the console of a virtual machine hosted on ESX, I found this article. An example configuration for accessing the console for a client on the ESX server using VNC port 5901 using a password of “secret” would require adding the following entries in the .vmx file for the virtual machine.

RemoteDisplay.vnc.enabled = "true"
RemoteDisplay.vnc.port = "5901"
RemoteDisplay.vnc.password = "secret"

The instructions work for ESX, except for one small detail: the ESX server won’t accept remote VNC connections. There is likely some way to turn this on, but allowing remote vnc connections to a server is typically not allowed and is considered a security hazard.

The solution is too use ssh port forwarding. If the vnc port on the ESX server is 5901, you create a tunnel with the following ssh command:

ssh -L5901:localhost:5901 user@esxhost

where “esxhost” is the hostname of the esx server and “user” is an authenticated user on the esx host.

Once logged in, you can connect to vnc port 5901 using any vnc client on the ssh client machine you have just connected from. The host should be “localhost”, the port should be “1″ and the password should be “secret”. The console for the client on the ESX server should be displayed. My vnc client of choice on OS X is “Chicken of the VNC” but here are many alternative vnc clients for OS X and other operating systems.

Note that ssh is disabled by default for root on ESX server, so if the “user” for ssh access is root, you will either need to enable root access by editing /etc/ssh/sshd_config on the ESX server and set “PermitRootLogin” to “yes”, or use another user authenticated on the ESX console. The later method is more secure since enabling root ssh access to the console is inadvisable for production installations.

The x4600 is an 8 processor, 16 core AMD Opteron machine. If you’ve ever wondered what 70 vm’s on a single box would look like, wonder no more.

You’ll probably want to download it to get a closer look.

Vince Hill and I have been doing some lab work with the x4600 and ESX 3.01. One of the tests we have been running has ~50 Linux vm’s doing a kernel compile in a loop to stress CPU and ~10 Red Hat vm’s running the Medrec, a J2EE test application to stress some of the 32Gb of memory.

Not surprisingly, the box is pegged under this load, but what is surprising is how responsive it is despite the load. Medrec response is snappy and the compile times for the kernel compile tests degrade linearly and gracefully.

This picture is of the Virtual Center console graphing CPU utilization. We’ve fenced off CPU 0 for the ESX console and CPU 15 few a few “utility” machines for things like a Linux virtual firewall/router, a Solaris 10 instance with some disk load generation tools (vdbench) and mediawiki site for our notes.

We have a number of customers preparing to kick the tires on this configuration with vmware. We think we’ll see a LOT of these x4600 servers installed where customers are looking to reduce space and power consumption in their data centers with an excellent data center solution.