a suggestion for a new Veeam feature!

[ashleyw]

hey guys,
We are in the process of a housekeeping exercise on our farm of around 400 VMs.
All our VMs get thin provisioned, but often they'll be loaded with junk until someone clears the junk out and then wonders why so much space was allocated to the VM in the first place.

One of the features missing from VMware is the ability to shrink vmdk files - this limitation seems to have been there from day 0.
However, the ways of shrinking seem to be pretty well documented - the basic approach seems to be;
- move all the used blocks to the start of the virtual disk
- resize the partition to match the required size (larger than the used blocks).
- adjust the vmdk descriptor to reduce the size of the VMDK.
but at any stage a slight error can result in data loss.
the alternative to this approach seems to be to use vmware convertor but this requires the VM to be off line during the process.

Is there not an opportunity for Veeam to create a disk resizing feature based around their replication technology specifically to handle reducing VMDK files?
i.e you'd select a VM and select a target disk size, Veeam would replicate to the new VM then at the point of switch over would reassign IP and MAC address etc to the new VM and delete the old one form vcentre.

A feature like this could easily add to what is already a great product.

cheers
Ashley

[foggy]

How much longer will failover of the VM take in case of DR? Typical approach is to periodically perform defrag with subsequent sdelete to zero out the dirty blocks. This will expand the thin disk, so further storage vMotion will be required to reclaim space.

[dellock6]

And just to complete what Alexander said, svmotion needs to happen between two datastore with different block size. Since vmfs5 has leveled the block of any datastore to 1mb, a motion between two vmfs5 datastore will not produce any result. A trick could be to have an nfs volume mounted and used just for this.