It seems that VMware became aware that just about everyone has been logging into their ESXi boxes and enabling SSH access. So for the 4.1 release of ESXi, it is easy to enable the feature from within the vSphere client. Here's how.

ESXi is great. Which is fortunate as it is also the way that VMware is going in the long run. There will be no service console before too much longer (although I can't get a fixed date on when out of my insiders within VMware). When you need to drop away from the vSphere client and interact with the vmkernel through commands and scripts, it can be a bit limiting. The VMware management Appliance (vMA) is very handy in most cases. But there are some times when you really do need to run commands on the ESXi server itself. Without a service console how do you do this? Read on.

This article describes how to install ESX4i onto a USB 'Pen' drive using a Mac. I found this article which is very useful if you are unfortunate enough to have a PC.

FreeBSD 8.0 doesn't natively support an iSCSI target server. This was a bit of a surprise when I discovered this fact, but I was sure that the ports database would include something that I could use. This technote shows how to set up the target server I found and have working. I'm running VM's on it from my ESXi servers and performance seems pretty good. (Especially considering that the FreeBSD installation in question is also a virtual machine, but that is another story...)

The iSCSI target server that I'm using is the istgt daemon. To compile and install this is simplicity itself.

From vSphere forwards, VMware has included fully working and supported access to SATA based hardware. This includes using that hardware for allowing a virtual machine to see those drives directly through a RDM (Raw Device Mapping). This means that it is possible to share cheap and plentiful local storage directly with virtual machines. Why is this of interest to the corporate environment? Well, perhaps it isn't really that useful in the 'real' world. But it's bloody handy at home!

Storage multi-pathing is an important technology that's been built into VMware for fibre channel SANs for some time. It's handled automatically for FC (and hardware iSCSI actually): just put more than one HBA into your server and off you go. This is not the case for software iSCSI however. There is only one software iSCSI initiator inside the vmkernel, so you can't do multi-pathing, right? Hmm... read on.

When you convert a physical server into a virtual machine using VMware converter, it is only possible to create full sized 'thick' disks. Ok, so you can resize the volume from the original server during the conversion, but the .vmdk file that you end up with is stored in thick format. This might not be what you want. It usually isn't. Most people want sparse disks now that thin provisioned disks are fully supported in vSphere. (The current version of converter is 4.1.1).

Most days, I really, really love working with VMware. When the system is working sweetly and the VMs are all happily migrating about in their little swarms, then I'm happy too. But when the dark clouds of instability start to mass on the horizon, it can be a hard day at the office. This was nothing to do with VMware and everything to do with bad design.