esxi

I often talk to people who don't understand what VMware snapshots are for and how they work. Common bad practices include using them as a backup technique, or applying them for the long term when applying patches. I hope that the following article might be useful to explain how snapshots work in vSphere. Part 1 of this article deliberately avoids showing you how the vSphere GUI works. I'll talk about the hows and whys in this part and show you how to apply this sensibly to a real VM in part 2.

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.

On one of my recent courses a delegate noted that a full format doesn't inflate a thin disk. I've got an answer for him in this article. First, let's prove what he saw.

I created a new Windows virtual machine using the typical settings. The only change that I made was to select thin provisioned disks. The disk was 8GB in size and a typical VM has 1Gb RAM, totalling 9GB as shown.

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.

Today I moved my standard vSwitch networking over to a distributed switch. It went well. Ok. I lie, it didn't go well at all. To be fair the main part of the work had gone very well. I've migrated all my virtual machines over successfully to the new port group. I've even migrated my ESXi management network vmkernel port over too. All was looking great until I renamed the dvUplinks.

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...)

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! In this article, we'll look at creating RDMs on local SATA storage devices and then sharing these with a Solaris or FreeBSD virtual machine for use in a ZFS pool.

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.