Comments on: Only Thin Provisioned in the Beginning

By: slowe

slowe — Fri, 24 Oct 2008 16:43:26 +0000

Vikas, you may be correct; I’m not familiar enough with the SDK to know for sure. Even so, the end result is the same: users will expect thin disks and get thick disks.

By: Vikas

Vikas — Fri, 24 Oct 2008 16:18:02 +0000

>>> “Clones made from the thin provisioned disks have thick provisioned VMDKs.”

It is probably a VC UI limitation. I think VC SDK itself allows you to create thinly provisioned clone. If “VirtualMachineRelocateTransformation.sparse” is specified while cloning it will create a thinly provisioned clone.

By: slowe

slowe — Wed, 08 Oct 2008 11:53:24 +0000

Good how-to guide, Kent–I’ll have to give that a try in my lab!

By: Kent B. Hansen

Kent B. Hansen — Wed, 08 Oct 2008 08:41:36 +0000

I don’t know how to prevent this behavior, but I made a little guide on how to convert the disks back to thin provisioned disks while they’re online.

You can find my guide here: http://blog.tpv.dk/?p=3

By: Dispelling Some VMware Over NFS Myths

Dispelling Some VMware Over NFS Myths — Sat, 16 Aug 2008 22:05:42 +0000

[...] a certain point. What I pointed out back in March of this year, though, was that these VMDKs are only thin provisioned at the beginning. What does that mean? Perform a Storage VMotion operation to move those VMDKs from one NFS [...]

By: Andrew Miller

Andrew Miller — Tue, 01 Apr 2008 18:07:47 +0000

Thanks very much for posting this — I’ve recently found what you’re describing on ESX 3.0.2/VC 2.0.2U1 and was searching to find confirmation.

I’d be very interested in any response to the SR noted above.

By: Nick Triantos

Nick Triantos — Tue, 01 Apr 2008 13:23:17 +0000

Given that we enable dedup on primary data rather than just backups and archives, we needed to be cognizant of the fact that performance is still a requirement. Had we done it inline, we’d have the hit “wall” at around 250MB/s TOTAL which the maximum performance achieved today by inline methods today.

So the idea was to achieve a balance between performance and deduplication. Having it behave as a “trash compactor” which can be scheduled rather than a “shredder” allows to obtain the best of both worlds.

By: slowe

slowe — Tue, 01 Apr 2008 12:28:03 +0000

Andy,

The fact that deduplication is post-process does present a few challenges in managing it, but I’d rather have it post-process than in-line and causing my performance to take a major nose dive.

Nick,

Thanks for the tips–I’ll have to give those a try.

By: Nick Triantos

Nick Triantos — Tue, 01 Apr 2008 02:49:19 +0000

Indeed. Cloning or movement of a thin vmdk to another datastore reverts it to thick. This is not just on ESX 3.5 but it happens in the pre 3.5 versions as well. I believe we’ve filed an SR this.

A couple of ways around this when you use NFS:

1) Use Single File Snap restore and clone from a Netapp snapshot and restore a copy with a different name to either the same volume or a different qtree within the same volume

2) Use cp with the sparse option

3) Use ndmpcopy and create a new VM from a NetApp snapshot either onto the same volume on the same array, or a different volume on the same array or across different NetApp arrays regardless of location.

By: Andy Leonard

Andy Leonard — Mon, 31 Mar 2008 23:37:06 +0000

One big problem with A-SIS for VMware that I see is that it is post-process: your LUNs will be fat until the (nightly, or ad-hoc) A-SIS process makes them thin again. Storage VMotion would presumably result in fat vmdks on your destination – and possibly big problems if you oversubscribed your VMFS storage and have to Storage VMotion a lot of VMs in a short amount of time.

Andy