Cloning the ESXi boot volume

20150703 - VMwareSince ESXi was introduced it has been possible to install it to a USB key. Initially it was always a hack… I remember getting a 3.5 image and using dd in a very unsupported way to write an image. It was only when ESXi 4.0 came along were USB keys officially supported as a boot volume.

I remember thinking this would save us a lot of money.  We no longer needed two 146GB disks and an expensive RAID card to host the boot volume and service console, as we could use cheap and cheerful USB keys.

Unfortunately, cheap doesn’t always equate to cheerful, as not all USB keys are made equally.

Recently at the company I work we discovered a number of hosts where the USB keys that had been provisioned were substandard, and had a low mean time between failure (MTBF). This resulted in the familiar error of losing the device backing the boot filesystem. While ESXi will continue to run (the image is copied into memory during boot), it does mean the system is highly unlikely to boot next time.

We decided to replace the USB keys, meaning a full reinstallation of ESXi was necessary. We raised a Request for Change and scheduled a maintenance window with the client.  Unfortunately due to the critical nature of the hosts, the window wasn’t as large as we hoped. I had to find a way to reprovision ESXi on a number of hosts in the time allocated.

I decided that cloning was the solution.

I downloaded the GParted Live ISO to my workstation and connected to the first server’s remote management card (iDrac/IMM/iLO).  I disabled HA host monitoring on the cluster, evacuated the first host, placed it into maintenance mode and then shut it down. I then replaced the internal USB key with the new model, and inserted the old one into a random port on the front.  Finally I disconnected the fibre cables (this is really important – if you accidentally erase or resignature a SAN LUN you’re going to have a really bad day).

Fortunately the server still recognised the old key, despite ESXi previously reporting it as lost.

I then booted into the GParted Live image:20151120 - 1After choosing the default image, I received the console screen. Here I just selected the default again.20151120 - 2Next I was asked to choose my language:

20151120 - 3

I chose 02 and moved on. I then typed 0 to start X and run GParted:

When the GUI loaded, I ran GParted to see what disks were available. It saw two, one empty and one with partitions:

20151120 - 4

20151120 - 5

As you can see, /dev/sda is the new USB key.

From here I ran the Terminal application,  and then cloned the partition table using:

sudo sgdisk --replicate=/dev/sda /dev/sdb

The important thing to note here is the syntax, which should be:

sgdisk –replicate=/dev/target /dev/source

If you get that wrong, you will wipe your existing disk!

This created an empty partition table on the new USB key, but with no data on it:

20151120 - 6

Now all that was left was to copy the data.

Back in GParted I refreshed the devices. I then selected each partition in turn on the original USB key, right-clicked to copy it, and then pasted it into the same place on the new key.

Some of the partitions couldn’t be copied, but this didn’t prove to be an issue. In the above example, partitions /dev/sdb7, /dev/sdb9 and /dev/sdb3 were the ones.

Finally I clicked Apply to commit. I then powered off the host, removed the original USB key, reconnected the fibre and powered it back on.  ESXi started without issue, now on a completely new boot volume.

20151120 - 7

Using GParted like this is a great way to visualise the partition table of an ESXi boot volume. Check it out!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s