VM Ware ESXi under VM Ware Fusion


I’m looking at getting a new home lab/server set up, and am seriously considering ordering one of these:

HP ProLiant ML110 G6 Quad Core X3430

It will need filled with memory and a load of disk space, but I reckon that’s still a whole lot of server for the money.

The Plan

The plan is to install VM Ware ESXi 5 on to it (using the USB Drive), and manage the server through the remote VM Ware vSphere Client app. This will allow me to create new Virtual Machines and migrate my existing appliances over to this server, then I can retire the old servers these have been running on. I’m also wanting to develop some automation processes for managing VM’s – creating new ones, bringing them up and down etc using Jenkins to orchestrate the processes, so this will allow me to work on that too.

Before ordering the ML110 I wanted to take a better look at the installation of ESXi – it doesn’t sound difficult, but while I’ve used it often I’d never set it up before so wanted to see what was involved.

VM Ware ESXi 5 Installation under Fusion on an iMac

It’s a little bit crazy and recursive, but, I realised I may be able to do this on my iMac under VM Ware Fusion, which it turns out does allow you to install ESX as a Virtual Machine itself…. which you can then use to manage and create new (Virtual?) Virtual Machines – a bit of a brain-ouch, and it’s clearly not going to be fast, but it’s good enough for my testing.

Installing ESXi is very straightforward – I selected the obvious option of “VM Ware ESX” in Fusion on my iMac, told it I had an image I wanted to use and pointed it at the VM Ware ESXi 5 ISO image I had downloaded from VM Ware (you need to register then fumble about their site for a while to find and download the free version – that’s the way I did it anyway). Keep a note of the serial number they give you, as that will remove the 60 day trial restriction later.

Fusion suggested a 40G file system for this instance and allocated 2GB RAM and 2 cores, which I was quite happy to run with for my test. Speaking of RAM – there was a restriction on the amount of physical RAM you could use with the free version of ESXi 5 – it was 8GB a while ago but this has now been increased to something more sensible – 32GB I think?

There are no surprises or major decision needed during the install of ESXi 5 itself – it took all of 5 minutes to run through and reboot, and that was with it running as a Virtual Machine on an overloaded iMac – on proper hardware like the HP ProLiant ML110 G6 Quad Core X3430 that I’m looking at, it would be loads faster.

When the install is done, there’s nothing more to see on the ESXi (VM), apart from the HTTP address it gives you to connect to the ESXi Host and access a simple web page it serves with links to download the VM Ware vSphere Client application to another host and start managing your server. This address was given by DHCP in my case – I think you can specify or change this easily if you want to.

Client Installation

Downloading the VM Ware vSphere Client took a while (longer than installing ESXi did!) as it came from the VM Ware site rather than being directly served by the ESXi host. Now for the bad news… for clients, you have a choice of running either Windows or Linux. No mention of an OSX vSphere client, so I had to fire up a Windows VM just to set up the client app on… not what I had been hoping for – there’s a petition asking VM Ware to sort this out here:


When I get things running I could create a VM on my ESXi host which I can RDP on to, but that’s still a pretty ugly solution – if the Linux client is ok I’d go with that over the Windows one, and I think there’s also a Web Interface. But, part of the reason for me doing this in the first place is so that I can look in to the SDK and API’s for automating the creation of VM’s with VM Ware using Jenkins though, so I’ll grin and bear the Windows yuckness and see how things go.

Installing the vSphere client gets worse and worse though – my VM needed an update to its Microsoft .Not Framework (something I tend to avoid) which churned away for quite some time, and the console looks to be written in J# too (yes seriously – J# – what the… ?), which meant another “Framework upgrade” which took another while and a half – so the client set up ended up taking about 10 times longer than the server, and I had to run a Windows VM just for it… not too cool.

Once done, I could point my vSphere client at the IP address of the ESXi (VM) using its advertised IP address, the default user name (which I’d forgotten to take a note of – it’s “root”) and the password I’d specified during the install. This gets me to the Hypervisor where I can start creating and managing my own VM’s.

Cool stuff, despite the client letting things down.

Easy method to tunnel VNC over an SSH connection

This has been done many times in many different ways, but I’ve finally found a workable solution that suits my needs and my setup, and (perhaps most importantly when it comes to ports and tunneling…) that I can get my head around 🙂


So… at home, I have a Windows machine with remote desktop enabled, but I don’t want to open up yet another port on my router or firewall (or to expose a Windows machine to the world) for the few times that I want to get a remote desktop connection to it.

But, I have a web-facing Ubuntu Linux host which I use frequently to access the non-Windows parts of my Home Network – another Linux host, an occasionally used FreeBSD VM, Solaris 10 server, a couple of iMac’s and my ATV2.

I can see the Windows file system ok by ssh’ing in to the Linux box (it’s file system is shared and mounted) but I can’t see or access the Windows desktop when I’m outside of my home network. Doing so is handy for access to the VM Ware vClient to manage my ESX Server, etc.

A solution for this is to tunnel the VNC protocol from my remote host to the Internal Windows server via the (already exposed) SSH connection on my web-facing Linux host. To do this from outside my home, I kick off an SSH session like this:

ssh -L 5900: myuser@www.donaldsimpson.co.uk

that command breaks down like this:

ssh using the -L arg ([-L [bind_address:]port:host:hostport]), which forwards the local port 5900 to, and attaches the tunnel on its port 5900 (the port that RDP or VNC is running on).

Note that the IP address is my “internal” Windows server with a non-routable IP address – it’s accessible to/from my Linux Host (www.donaldsimpson.co.uk), but not from anywhere outside my network.

After that, I specify the SSH logon details for my Linux host and when that connection is made I’m prompted for the password for “myuser@www.donaldsimpson.co.uk“. When that is accepted I am logged on to my Linux box at the console (Cygwin with SSH installed in this case) as per usual, and I’ll need to leave this terminal open. The SSH Tunnel has been created and will end when this session does.

The next and final step is to launch “mstsc” (or VNC or another RDP Client) on my local host and create a connection – not connecting to www.donaldsimpson.co.uk, but to – this is the local end of the tunneled connection; at the other end, via my SSH Host, is the listening port on the Windows host. After supplying the requested credentials, it makes the connection, then finally shows me my Windows Desktop – woohoo, job done.