Anybody ever shrunk a vm drive before?

[hkazi]

We run VSphere 6 and are about to attempt it. Never done it before and last time it was done (before my time) we had to do a baremetal recover the virtual server. Can anybody please give us some advise such what to look out for ... or even "dont do it !!"

These are the instructions we found :

http://https://www.experts-exchange.com/articles/12938/HOW-TO-Shrink-a-VMware-Virtual-Machine-Disk-VMDK-in-15-minutes.html

Edited January 21, 2018 by elsiegee40

[Domino]

If you've room to add another disk of the size you want, and move the content, that's by far the safest way to do it.

[hkazi]

Thanks for the suggestion. That would have definitely been easier to do it that way but we are no space to spare

[Davit2005]

I this an OS drive, I'm guessing it is.

 

What services is the server providing??

[hkazi]

Yes it is and it is our SIMS server ...

[Mic_Impero]

I've done this plenty of times in Hyper-V and in production environments, but never in VMware. I've never had a problem with it.

I think if the first time I'd ensure I had a full backup since MIS changes were last made and do this with enough time to restore it should I need to before MIS would need to be accessed again.

[dapaulio]

I too have shrunk vhd in hyper v on countless occasions however compact through the gui sometimes doesn’t make a difference for reasons I am yet to understand.

I found using diskpart to mount and compact vhd more reliable. Can’t see why it would be any different with vSphere however Please make sure you have a reliable backup. Maybe test on a non mission critical vhd.

You won’t be able to do a snapshot as this creates another changes file (well it does in HV).

I repeat ... DO NOT perform this if you have snapshots

 

Shut server down

Make sure all snapshots are merged with the vhd.

Open cmd

Diskpart

Select vdisk file=“c:\path\to\vhd”

Attach vdisk readonly

Compact vdisk

Detach vdisk

Boot server back up

[Tefters]

Do you have another datastore available?

If so I would personally convert the disk from thick to thin provisioning (presuming your disk is thick) across datastores leaving the disk the same size but converting it in order to claim back the zeroed blocks.

 

Yes the provisioned size will be the same but the actual raw disk size would be lower.

 

This is all presuming you have a cluster, multiple datastores and vmotion.

 

The converter method is simple enough however takes time and if it wasn’t enough enough make sure you have a full VM backup (example Veeam and if it goes wrong just restore the disk).

 

You could even go old school and clone the disk with the likes of Clonezilla (other products are available) and just attach a second drive and then boot into the clone software and away you go.

Edited January 21, 2018 by Tefters

[rich_tech]

When your doing any work like this, Turn off any backup imaging programs like veeam that may be scheduled to run when your working on it, they use snapshots and can kick off a nasty issue where you have to use vi and edit disk files manually and their parent file entries as I found out recently

[dapaulio]

When your doing any work like this, Turn off any backup imaging programs like veeam that may be scheduled to run when your working on it, they use snapshots and can kick off a nasty issue where you have to use vi and edit disk files manually and their parent file entries as I found out recently

 

Good advice always something Of an oversight when I manually compacted. Iv obviously just been lucky up until now. Mind you Our backups only happen overnight. So unless I’m burning the midnight oil (had been known to happen) [emoji487][emoji482][emoji42]