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:
More info at VMware-Land
“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.
Fixed.. I think,
Fixed.. I think,
“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.
Fixed.. I think,