BillClarkCNB
Enthusiast
Enthusiast

How to shrink a thick-provisioned disk

Jump to solution

I'm running ESXi 6.5 and have a server that has a 1TB, thick-provisioned drive as part of it's virtual makeup that I'd like to reduce.  Current used space is less than 200GB and isn't going to grow beyond that.  This is a production server, so the utmost care must be taken.  There are 4 other drives on this virtual server and they are all fine with their respective sizing.  Is it possible to shrink that overly large disk and recover the unused LUN space?  Thanks

1 Solution

Accepted Solutions
continuum
Immortal
Immortal

This is a production server, so the utmost care must be taken.
So no downtime with a failsafe process ?
Would a 15 minutes downtime be acceptable ?
1. create additional protective snalpshot.
2. vmkfstools -i 1tb.vmdk new-thin.vmdk -d thin
3. 15 minutes downtime: attach snapshot to new-thin.vmdk and power on

4. if all is good consolidate the chain to get rid off protective snapshot
This is the approach I use when failure is no option.
That converts the vmdk from thick to thin.
If you want to do a partition resize let me know.

Do you need support with a recovery problem ? - send a message via skype "sanbarrow"

View solution in original post

0 Kudos
17 Replies
MikeStoica
Expert
Expert

You can do that using VMware converter

0 Kudos
ThompsG
Virtuoso
Virtuoso

Hi BillClarkCNB,

Another option, if VMware Convertper is not your thing and you have space,is to present another VMDK at the corrected size. Copy the data over to this using something like Robocopy. When ready, switch the drive letters and move on with life Smiley Wink

Kind regards.

0 Kudos
BillClarkCNB
Enthusiast
Enthusiast

Does VMware Converter run a type of clone command against the original virtual machine, allowing you to change some aspects of the resulting virtual machine?  Or does it modify the existing virtual machine with no backout plan?  Only ever ran the P2V version and that was years ago....

0 Kudos
BillClarkCNB
Enthusiast
Enthusiast

Thought about that, but unfortunately the drive in question has 15 million + "placeholder" files as part of an imaging application.  I suppose I can do some copy tests and see how long it would take to copy and use this method.

0 Kudos
continuum
Immortal
Immortal

This is a production server, so the utmost care must be taken.
So no downtime with a failsafe process ?
Would a 15 minutes downtime be acceptable ?
1. create additional protective snalpshot.
2. vmkfstools -i 1tb.vmdk new-thin.vmdk -d thin
3. 15 minutes downtime: attach snapshot to new-thin.vmdk and power on

4. if all is good consolidate the chain to get rid off protective snapshot
This is the approach I use when failure is no option.
That converts the vmdk from thick to thin.
If you want to do a partition resize let me know.

Do you need support with a recovery problem ? - send a message via skype "sanbarrow"

View solution in original post

0 Kudos
BillClarkCNB
Enthusiast
Enthusiast

Downtime outside of business and reporting hours is acceptable, I have a decent window for maintenance and such.  I'm assuming the "vmkfstools" command needs ran from the particular hosts console?  Upon completion, the space differential between what is fully allocated now as a thick disk vs what is being used will be automatically available to the VMware environment?  Since these are Windows partitions, once the steps you listed are completed, is there anything else that is needed to be done to the Windows OS for the partition to show correctly?  Thanks!

0 Kudos
BillClarkCNB
Enthusiast
Enthusiast

So I tested the VMware Converter Standalone product and while it worked, it took it's own sweet time, and maybe that is due to how I have it setup.  I installed the Converter software on a physical server, and created a new task to do a V2V conversion of a Win2008R2 server with a 60GB hard drive, shrinking that hard drive down to 40GB on a different LUN on the same SAN.  While the process worked, it took about an hour and 45 minutes.  Would this process be sped up if the Converter application was installed on a guest server that is part of the VMware environment?

0 Kudos
continuum
Immortal
Immortal

Converter will always be one of the slowest options ....
Just had another idea ....
Why dont you add a new 200 GB vmdk to that VM and then use robocopy to copy the data to the new drive.
Then you just need a short period without activity to do a final sync and then switch driveletters so that the new disk gets the driveletter of the old - large vmdk.

Do you need support with a recovery problem ? - send a message via skype "sanbarrow"
0 Kudos
BillClarkCNB
Enthusiast
Enthusiast

I've thought about that idea, of using a new drive and RoboCopy.  That would definitely speed up a basic file copy and still might look into that.  If I remember right, RoboCopy can preserve security permissions on the copy.

So, I ran through your earlier directions on a test server that had a 100GB drive, and only 25GB being used.  I do show that the drive is now "Thin", but it still registers the size as 100GB.  How do I fully reclaim that space now that VMware sees it as thin-provisioned?  Thanks!

0 Kudos
ThompsG
Virtuoso
Virtuoso

Hi BillClarkCNB,

Disable SSL for VMware Converter and you will surprised by the increase: Disabling SSL encryption on VMware Converter Standalone 5.x and 6.0 (2020517) | VMware KB

Obviously this makes it less secure and people could read the traffic over the wire but if needs must do this. In my experience this can bring the speed up from MB/sec to 10-100’s MB/sec. Other factors in here such as network and storage speeds but it certainly makes for a better experience. Test anyway and see.

Otherwise as mentioned RoboCopy maybe an option but with little files it can be painful. In this case use the ”MT” switch to increase threads. This really helps with small files as others are in flight while acknowledgements are being done. I find somewhere between 8 - 16 is the sweet point but you mileage may vary.

Kind regards.

0 Kudos
ThompsG
Virtuoso
Virtuoso

Hi BillClarkCNB,

Check what is allocated vs provisioned. The provisioned size will be 100GB however the allocation should only be the data consumed.

Look from the datastore view or on the VM summary page and the storage allocated should be displayed.

Kind regards.

BillClarkCNB
Enthusiast
Enthusiast

It shows "Provisioned Space = 100GB", and "Used Space = 22.61GB".  So I think I'm forgetting how thin-provisioning works, and that you do set a "max" size of the disk, but it doesn't pre-allocate it all.  Even though it shows 100GB, it is only using 22GB on the SAN. Is that correct?   Looking at the overall free space on the LUN, it does appear that it increased after this test.  I'm going to test with another server just to verify....

0 Kudos
continuum
Immortal
Immortal

> but it still registers the size as 100GB.
All vmkfstools -i commands do not change the "nominal size".
To change that you need to
1. resize the partition inside the guest
2. power off the guest

3. cut down the flat.vmdk with a dd-command

4. adjust the size in the vmdk descriptor

5. boot the VM with a Linux LiveCD that can rebuild the GPT-backup at the end of the disk

6. reboot the VM
For many users step 3 is too scary - so they rather do not use this approach.

Do you need support with a recovery problem ? - send a message via skype "sanbarrow"
0 Kudos
GGonzalez507
Contributor
Contributor

Good day,

You can try a Storage vMotion and select thin provisioning on the destination route:

  1. Right-click the virtual machine, and click Migrate.
  2. Click Change datastore.
  3. Click Next, and select a datastore that is not the same as the current datastore.
  4. From the dropdown, select the Thin Provision virtual disk format.
  5. Click Next, then Finish. You can monitor the progress of the conversion in the Tasks and Events view in vCenter Server.

Source: VMware Knowledge Base

ThompsG
Virtuoso
Virtuoso

Yes that is correct - 100GB is maximum size with 22GB being used. As blocks are changed the VMDK will grow in size until it reaches the provisioned (max) size - assuming you modify every block.

If you go the Converter or Robocopy route then you can either use Thin or Thick as the destination disk. Both of these options will resize the disk.

The other option is to tackle the original disk as continuum has mentioned. He is much braver than me but you are in very good hands there as well Smiley Happy

Kind regards.

0 Kudos
Matthew6411
Contributor
Contributor

Select Disk Management, and select the partition you need to shrink. Right Click the Volume/Partition to shrink, and select Shrink. TellPopeyes

0 Kudos
BillClarkCNB
Enthusiast
Enthusiast

> but it still registers the size as 100GB.
All vmkfstools -i commands do not change the "nominal size".
To change that you need to
1. resize the partition inside the guest
2. power off the guest

3. cut down the flat.vmdk with a dd-command

4. adjust the size in the vmdk descriptor

5. boot the VM with a Linux LiveCD that can rebuild the GPT-backup at the end of the disk

6. reboot the VM
For many users step 3 is too scary - so they rather do not use this approach.

Looking closer at what I actually need, I think the above is overkill in my situation.  By doing the process in your first reply, I'm able to shrink the volume in question down to what is actually being used by making it a thin disk.  With that, I immediately recover that unused space that was pre-allocated as a thick disk.  I'm not worried about the new thin disk growing to the maximum allotted size because the original purpose of those drives has changed and any data won't be anywhere near the size of the allocated space.  In addition, I can shrink the Windows partition just to provide a stop gap against something running away and creating a lot of data.

0 Kudos