Dealing With Shrinkage, and Expansion – Resizing Virtual Disks

george_costanza[1].jpg

Despite all of the time you spent planning your virtual machine deployment, inevitably someone will want to make a change to their VM. While some of these may be straight forward, change the CPU allocation, increase the memory allotment, some of these will not be. Say the accounting team had determined they needed 450GB for their VM, but in reality only had 3GB data, and you need to now fit in a 200GB database for development and testing of some new software. With only 120GB left, you will need to shuffle some space around.

The beauty of virtualizaiton, is that this is much easier than it used to be in the physical world. You no longer have to add disks to raid sets, dynamically expand, and hope against hope that Windows comes back, without issue. In fact, VMware makes this quite easy for us, and provides several tools to preform these changes. This post will describe several, and how they pertain to Windows VM’s (as that is where most of my expertise lies). I will do another with some best practices around Linux, as there are some special considerations, depending on how you setup your partitioning to begin with.

NOTE: All of these Situations and Methods for dealing with them assume you have cloned, or otherwise made a backup of the data in the VM being manipulated. I am not responsible for you shooting yourself in the foot. I will however teach you how and where to aim.

Situation 1: Expanding a Non-System volume

This one is simple enough, and the procedure works like this:

Power down the VM

Edit Settings

Enlarge the disk

Power VM on

Use diskpart to expand the volume

Situation 2: Expanding a System volume

There are two common ways you can go with this. The first is to use a second Windows VM, and the second to use a gparted (or other) boot disk. In either circumstance, the procedure is much like the one descibed for situation 1. We’ll first cover the Windows VM method, then the boot disk method, and then I’ll tell you why I generally choose the latter.

Windows VM:

Power down the VM

Edit Settings

Enlarge the disk

Attach the disk to a second Windows VM.

From the second Windows VM, rescan disks.

Use diskpart to resize the volume

Shutdown the second Windows VM

Detach the disk

Power both VM’s back on

Check that the expansion was successful

Boot Disk Method (gparted):

Power down the VM

Edit Settings

Enlarge the disk

Boot the LiveCD

Expand the volume

Power the VM on

In case you didn’t catch it, the Boot Disk method, has a few less steps, and only requires rebooting a single VM.

Situation 3: Shrinking a volume (System or otherwise)

NOTE: This note is here because you likely have not read the first one warning you to backup your VM first, I can’t do it for you, and Jill, the cute one from accounts payable… she’s counting on you to have backed it up, just in case.

This one is a bit more involved, which is why I’ve put it at the bottom, after all… Don’t all good things come last? (at least I think that’s how that goes) The procedure goes like this:

Defrag the disk

Power down the VM

Boot the LiveCD (gparted)

Shrink the NTFS partition to LESS (this is critical) than the new desired size

Shutdown the VM

Use the VI client to shrink the disk

Boot the LiveCD, and expand NTFS

Reboot

So there you have it. A bunch of ways to expand disks in VMware ESX, by hand. Now, if you were to download VMware Converter, the list of steps is much fewer:

Power down VM

Run it through converter

Power on VM

Here are some links to the tools discussed:

gparted – LiveCD

VMware Converter

More info at VMware-Land


Technorati : , , ,

Del.icio.us : , , ,

Zooomr : , , ,

Flickr : , , ,

5 thoughts on “Dealing With Shrinkage, and Expansion – Resizing Virtual Disks

  • “Shrink the NTFS partition to LESS (this is critical) than the desired size” should read “Shrink the NTFS file system to LESS (this is critical) than the new desired disk size.” for clarity. Other wise some one might try to shrink the partition with the NTFS fs on it to smaller then the desired new disk size with data lost as a result.

    Aside from this, this is good info. I read it and wondered why would you decrease the partition size to smaller then the desired end partitioned size.

  • “Shrink the NTFS partition to LESS (this is critical) than the desired size” should read “Shrink the NTFS file system to LESS (this is critical) than the new desired disk size.” for clarity. Other wise some one might try to shrink the partition with the NTFS fs on it to smaller then the desired new disk size with data lost as a result.

    Aside from this, this is good info. I read it and wondered why would you decrease the partition size to smaller then the desired end partitioned size.

Comments are closed.