How to migrate thick VMs from traditional storage to thin in VSAN?

[pfuhli]

Hi there,

we are looking for a way to change the disk format of VMs during a live migration from a cluster with traditional fibre channel storage to a vSAN cluster.

The VMs in the source cluster are all thick provisioned and we want to have them thin provisioned in the target cluster.

Is there a way to do all this online?

Regards,

daniel

[a_p_]

I didn't do this myself yet, but from how I understand it, you'd create a VM Storage Policy with Object Space Reservation = 0% for the vSAN Cluster, and select this during Storage Migration. The VM Storage Policy will dictate the target format.

André

[pfuhli]

We tried this but it did not work.

[a_p_]

Only a guess, but maybe a similar issue like the one explained in OVA deployment using Webclient creates always thick provisioned vmdk (2145798) | VMware KB

André

[TheBobkin]

Hello pfuhli,

Are you performing this vMotion via the Web Client?

When choosing the destination vSAN datastore, at the 'Select storage' page are you selecting

- For 'VM storage policy' a valid vSAN Storage Policy with OSR = 0 as a.p. advised?

- 'Select virtual disk format' 'Thin Provision'?

Where are you seeing the disks as 'Thick' after performing the above?

Do the resulting vmdk Objects have the Storage Policy (SP) applied correctly, show as 'compliant' and show as ProportionalCapacity = 0 when checked via RVC using vsan.vm_object_info <path to VM>?

If for some reason these are all landing as Thick, there are other workarounds to re-apply Thin in bulk (as in apply to all VMs) to these Objects such as creating an identical SP (with a new name) and then applying this to all affected VMs (then apply original one back if you prefer). Alternatively simply adding a zero value rule-set to the existing SP (e.g. IOPS limit = 0), applying the change to all Objects when prompted, then as with the other work-around you can remove this rule and re-apply or leave it as is.

Bob

-o- If you found this comment useful please click the 'Helpful' button and/or select as 'Answer' if you consider it so, please ask follow-up questions if you have any -o-

[stephan87]

Hi Bob,

yes. We performing the vmotion via webclient and select compute first and then storage cause it is another cluster (from traditional vmfs cluster to vSAN cluster). We select the default vSAN storage policy where OSR = 0. After that we cannot change the disk format (greyed out).

We see the disk as thick on the edit settings page in the details pane of the disks with the old c# client and with powershell "get-harddisk". VM shows as compliant.

We have tested one workaround: move the vm back to vmfs storage and select thin as disk format and then move the vm back to vSAN cluster again.

Stephan

[TheBobkin]

Hello Stephan,

If it is a case of having to use workaround (or this is easier), I would advise using the SP edit/apply or new identical SP and then re-apply back original as opposed to migrating back and forth.

You can test that this functions on a single VM or disk Object and then apply in bulk to all VMs using that SP later if applying this is working okay.

Bob

-o- If you found this comment useful please click the 'Helpful' button and/or select as 'Answer' if you consider it so, please ask follow-up questions if you have any -o-

[KaramjotSingh]

Hi pfuhli,

As per my knowledge, what best work around will be to try doing a SvMotion on any other datastore and choosing thin provision on any target VMFS datastore, once it is done at source, you could try SvMotion to vSAN type datastore.

[stephan87]

Hi Bob,

applying a identical SP did not help. But thanks for your suggestion.

[eode]

Question

On what findings are you basing your conclusion that it's not thin? What do you see? What are the numbers?

Short answer

In short; if OSR = 0 in the storage policy, then OSR should be 0. No need to "select" thin or thick - this is all in policy. You could also verify this in RVC (se previous comments).

Other possible "solution" - disk reclaim

Regarding disk reclaim (vSphere "used space" dosn't match OS used space)

If you're looking at the "GB used storage space" (on the disk, in Web Client), the "used storage space" should usually equal the OS space * policy (e.g. FTT=1, then it's OS disk used space * 2). If calculations does not match (OS used vs "GB used storage space"), you could reclaim diskspace, e.g. using "zeropunch" on the disk (using SDelete from Sysinternals in Windows (-z) or dd in Linux). This needs to be done before migrating the data (or you need to migrate back and forth, again). Usually with datamover, null blocks are not "reclaimed".

Note: This will fill up the virtual disk (then "zap the zero's, sort of speaking"), so make sure you have enough underlying space for this operation (if thin disks).

After the disk is "filled with zero-blocks" (Or "zapped!" - in SDelete), you should be able to shrink the VMDK (removes the zero-blocks). Sadly, this isn't supported on vSAN (yet), so you have to Storage vMotion the VMDK. If a new blocksize on the target, the "zero-blocks" will *not* be copied, so in short, only the data will be moved.

If you're not able to use Storage vMotion, you could also move the VMDK to a VMFS DS, and run vmkfstools -K /path/to/disk/vm.vmdk, which will "punch out the zero's" (this operation will requires you to unlock the VMDK, which usually means shutting down the VM - or detach the disk).

After migration (or --punchzero), if you recheck you're "GB used storage space", it should now equal the OS space * policy.

Also see KB2004155 from VMware:

Storage vMotion to thin disk does not reclaim null blocks

https://kb.vmware.com/kb/2004155

Best regards,

Espen Ødegaard