You can do that using VMware converter
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
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....
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.
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.
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!
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?
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.
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!
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.
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.
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....
> 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.
You can try a Storage vMotion and select thin provisioning on the destination route:
- Right-click the virtual machine, and click Migrate.
- Click Change datastore.
- Click Next, and select a datastore that is not the same as the current datastore.
- From the dropdown, select the Thin Provision virtual disk format.
- 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