jump to navigation

How to Shrink/Expand a VMDK in ESX 3.5 February 17, 2010

Posted by General Zod in Tech, VMware.
trackback

I got back into work today to discover that all of my VMware datastores were running extremely low on disk space.  Apparently, one or more of the other Administrators had been creating VMs over the weekend and had apparently thought it was OK to nearly max-out the free disk space to accommodate a project.

For those of you unaware… you should ensure that there is always some free space available on your datastores for multiple reasons.

  • When a VM is powered on, additional disk space is occupied by VSWP file that is the equivalent size of the memory assigned to the VM.

  • When someone takes a snapshot of a VM, the original VMDK disks are frozen and supplemental delta disk files are created that could possibly swell (over time) to take up the same amount of disk space approximately equal to the size of the original VM.

So after some investigation and making a couple calls, I was able to track down a few virtual machines with with excessively large drives (one of which was a 80 GB drive that was hosting only 4 MB of data).  I scheduled an outage for each, and set to work reclaiming the wasted disk space.

If you don’t have them already, then you will need the following:

  • Install Putty (or some other SSH client solution) on your workstation.

  • Build an extra VM onto which you’ll be installing some kind of partition management software.  (I have a personal preference for Paragon Partition Manager.)  In these instructions, I’ll refer to this as the “Partitioning_VM”.
  • Ensure that there is enough free space on your VM’s datastore to accommodate more than twice the size of the VM.

Before we begin, I think it’s important for you to understand that I’m not writing these instructions for the “every man”.  I’m going under the assumption that you work with VMware rather regularly, and know how to handle most of the rudimentary tasks involved with it’s administration.

So how to handle it?

WARNING:  If anything goes wrong while using either of the the following procedures, then it may result in data loss.  Use these procedures at your own risk.

********************************************************************************

How to Shrink a VMDK

I’m starting with the more complicated “shrinking” of a VMDK because I feel it needs the most attention.  I have found other sites that have written similar procedures, but they are usually written rather nonchalantly, and usually had a habit of glossing over important details or adding numerous useless steps.  So I pieced them together into this procedure.

There may be faster ways to accomplish this in the future.  It’ll probably be a lot easier once I’ve upgraded to vSphere 4 and have migrated all my VMs to Windows 2008.  However, for now… this is what works for me for VMware VI3.  I have used this procedure several times with 100% success.

Note:  For the examples in this procedure, I am going to assume that the VMDK file is named VMSERVER.vmdk, and that it needs to be shrank to 8 GB.

  1. If your VM has any snapshots on them, then delete them all now.  I’m afraid I haven’t worked out a way around this, so consider this a requirement.
  2. Shutdown the VM.  Make sure that no one restarts the VM until this procedure has been completed!
  3. Create a backup of the VM by cloning the entire VM to a new VM.

    For the purposes of this example, we’ll assume that I’ve cloned the “VMSERVER” virtual machine to a new VM named “VMSERVER_CLONE”.

    Remember that all the know-how in the world is no substitute for a reliable backup!

  4. Shutdown your “Partitioning_VM” virtual machine.  Edit the VM, and add the VMDK that you wish to resize as a secondary Hard Disk.  Apply the changes, and power it back on.
  5. Use your partitioning software to resize the partition to be SMALLER than the end target partition size and is placed at the beginning of the drive.  (These instructions assume that you have only one partition per VMDK.  If this is not the case, then you might want to consider a new strategy.)
  6. After your partition has been resized, then shutdown the “Partitioning_VM” again, and remove the drive from the VM (being careful NOT to select to delete it from the disk).
  7. Next, SSH into your Host server, and SU up to an administrative account (if necessary).
  8. Now you need to create a new VMDK at the target size (of 8 GB for this example).  From your SSH session, invoke a command similar to the following.

    vmkfstools -c 8G -d thick VMSERVER_NEW.vmdk

  9. Next, we’re going to perform a byte-by-byte copy of the contents of the old VMDK into the new VMDK.  (Please note that this command will take a long time to complete, and does NOT display any kind of status counter.  The bigger your target VMDK, then the longer it will take.  So please, be patient.

    Use a command similar to the following to complete this task.

    dd if=VMSERVER-flat.vmdk of=VMSERVER_NEW-flat.vmdk bs=1048576 count=8192

    In this command, we’re telling it to copy the first 8 GB of data from the OLD to the NEW.  The ”bs” parameter represents the block size of data to be used (which is set to 1048576 bytes or 1 MB).  The “count” parameter is telling it how many blocks to copy (which is set to 8192 blocks, which is 8 GB).

    Do NOT omit the “-flat” part of each filename.  If you look closely at a directory listing of your VM, you will see that each VMDK file actually consists of 2 files (VMSERVER.VMDK and VMSERVER-flat.VMDK).  It is the “-flat” file that actually contains all of your data.

  10. Now we need to transfer the CID from the old VMDK and the new VMDK.

    The CID stored in a VMDK file is a unique case-sensitive 8-character string that is randomly generated every time a change is made to a VMDK file.  It identifies the current state of the VMDK file to the host server.  When manipulating the CID in a VMDK, you need to take particular care to be EXACT at all times.  If the CID is not correct when the VM is powered on, then VMware will choke on the VM and complain (which may result in data corruption).

    You’d think that the CID would have transferred with the rest of the data, but you’d be wrong.  Why?  Remember that each VMDK consists of 2 files.  We copied the “-flat” file, and the CID is in the other file.

    So first, display the first few lines of the OLD VMDK file

    cat VMSERVER.vmdk

    And you’ll get output that looks similar to this:

    # Disk DescriptorFile
    version=1
    CID=8d259130
    parentCID=ffffffff
    createType="vmfs"

    Document the 8-character alphanumeric string that follows “CID=” exactly.  Later, I’ll be referring to this as the “GOOD_CID”.

    Repeat the same step on the VMSERVER_NEW VMDK

    cat VMSERVER_NEW.vmdk

    Document this CID as well (which I’ll be referring to as the “BAD_CID”).

  11. Next, we’re going to rename the OLD VMDK to a different filename.

    vmkfstools -E VMSERVER.vmdk VMSERVER_OLD.vmdk

  12. Now, we are going to perform a streaming-edit the VMDK file to replace the BAD_CID with the GOOD_CID.  When this command is invoked, it will create a 3rd copy of the VMDK file, so we’ll be naming the target VMDK to use the same filename as the OLD VMDK had used originally.

    Remember when invoking the following command to substitute the “GOOD_CID” and “BAD_CID” for the actual alphanumeric strings that you documented above in Step #10.
     
    sed -e ‘s/BAD_CID/GOOD_CID/g’ VMSERVER_NEW.vmdk > VMSERVER.vmdk

  13. Return to the VIC, and re-add the newly resized VMDK to the “Partitioning_VM”.  Power it on, and resize the partition again to accommodate the full capacity of your VMDK file.  Then, power off the “Partitioning_VM” and remove the VMDK from it.
  14. Then, edit the settings on the original VM.  Remove the old VMDK and apply the settings.  Then, re-add the VMDK and apply the settings.  (This may seems silly to do, but it’s to ensure that VMware understands that the VMDK file size has changed.)
  15. Power on the VM.  (If prompted to change the SCSI ID, then click YES.)
  16. Once you have confirmed that the VM has started properly and feel comfortable that it’s functioning correctly, then you can return to your SSH session and delete the superfluous VMDK files.

    vmkfstools -U VMSERVER_OLD.vmdk
    vmkfstools -U VMSERVER_NEW.vmdk

  17. After you have confirmed the functionality of your VM 100%, then you should finally feel comfortable enough to erase your backup CLONE of the original VM.

********************************************************************************

Next,…

How to Expand a VMDK

This procedure is actually significantly shorter in steps, and doesn’t require any SSH session work at all.

  1. If your VM has any snapshots on them, then delete them all now.
  2. Shutdown the VM.  Make sure that no one restarts the VM until this procedure has been completed!
  3. Create a backup of the VM by cloning the entire VM to a new VM.
    For the purposes of this example, we’ll assume that I’ve cloned the “VMSERVER” virtual machine to a new VM named “VMSERVER_CLONE”.

    Once again… remember that all the know-how in the world is no substitute for a reliable backup!

  4. Edit the Settings on the VM, and use the Up/Down arrows on the Hard Disk size to increase the capacity of the VMDK.  Apply the changes.
  5. Shutdown your “Partitioning_VM” virtual machine.  Edit the VM, and add the VMDK that you wish to resize as a secondary Hard Disk.  Apply the changes, and power it back on.
  6. Use your partitioning software to resize to match the full capacity of the VMDK.
  7. After your partition has been resized, then shutdown the “Partitioning_VM” again.  Edit it’s Settings to remove the VMDK (being careful NOT to select to delete it from the disk).
  8. Now, you can power the original VM back on.
  9. Once you have confirmed the functionality of your VM and feel comfortable enough, then you should clean up your environment by deleting your backup CLONE of the original VM.

********************************************************************************

I hope someone finds this helpful.

Comments»

1. Setup a Windows Failover Cluster in VMware « Useful Glyphs - August 10, 2010

[…] to document which LUN is mapped to this VM.) This is actually my preferred solution even though expanding the drive in the future will require additional SAN work.  (I usually try to keep SAN changes to a […]

2. Setup a Windows Failover Cluster in vSphere « Useful Glyphs - August 10, 2010

[…] to document which LUN is mapped to this VM.) This is actually my preferred solution even though expanding the drive in the future will require additional SAN work.  (I usually try to keep SAN changes to a […]

3. austin - November 3, 2010

Thank you soo much. Your instructions were clear, and concise. And most importantly, correct. Thanks for taking the time to document this.


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

%d bloggers like this: