Storage VMotion and Thin (on hardware)

[roycesj]

I'm trying to explain something we are seeing. We have a new Clariion array, and are moving off an existing Clariion using storage VMotion. The new array is set up to thin provision the storage on the hardware. The VMs were set up using the default Thick disks (not Eager-Zeroed Thick). When we use storage VMotion to move the VMs, though, the Clariion consumes all the allocated space for the VM, not just what has been consumed. We had assumed that moving the VM (still Thick in VMware) would reclaim the space as the VM moved, thinking that it would only copy the disk locations that had been written to, and not copy the others.

I understand that we can do "VMware Thin" on top of "hardware thin" and this would probably fix the issue. My problem is that we aren't mature enough operationally to deal with two different sets of alarms and tracking the space utilized on both thin operations at once, so we wanted to have the hardware do it and reclaim the space as we moved over. Any ideas why that isn't happening?

[mittim12]

If your moving a 20GB thick disk over then 20GB is going to be taken up on the SAN side. That's how it's supposed to work correct? We don't utilize SAN thin provisioning but I always thought that it would allow the ESX host to see a 500GB LUN but from a SAN side we had only dedicated 100 GB. Well as you move that 20 GB thick disk over then the SAN would need to increase to 120GB and so forth.

If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

[roycesj]

So that matches what we're seeing, but not what we expected. Our thinking was that creating a new Thick disk shouldn't write anything to the SAN since with Thick nothing gets written on the disk until the first write to that block. So we thought that we could give the hosts a 500GB LUN, with no initial allocation (or a very small one, like you said). Then, as we create a new 50GB VM, this should only use however much of that was actually written to (say 20GB). So even though I've allocated 50GB of disk space to the VM, only 20GB has been consumed (just like thin on VMware, but with the added benefit of reducing the SAN space allocation required, rather than the whole 500GB being allocated).

We also thought this would apply to Storage VMotion - that those blocks that had been written to would be copied over, but the rest would appear on the SAN as unallocated space since those block haven't been written to yet. Does anyone know for sure how it works? How bad were my assumptions?

[mittim12]

http://virtualgeek.typepad.com/virtual_geek/2009/04/thin-on-thin-where-should-you-do-thin-provisioni...

I was reading over Chad's blog on storage array vs vsphere thin provision and found the text below that seems to support your theory.

2.when you use thin provisioning techniques at the array level using NFS or VMFS and block storage you always benefit. In vSphere all the default virtual disk types - both Thin and Thick (with the exception of eagerzeroedthick) are “storage thin provisioning friendly” (since they don’t “pre-zero” the files). Deploying from templates and cloning VMs also use Thin and Thick (but not eagerzeroedthick as was the case in prior versions).

If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

[roycesj]

I knew I'd seen something like that before, but that doesn't match what we're seeing - at least using storage VMotion. However, you do point me at a possible reason. Most of these VMs have been around a while, and were deployed from templates. So perhaps they were "eager-zeroed thick" because of previous versions. Anyone know how to check that? I checked a couple in the VI client, and they just say "Thick", so maybe that isn't it.

[mittim12]

Not sure how to tell that but you should be able to create a new one as Thick and deploy it. That will at least allow you to see the behavior of a known Thick vmdk.

If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

[mittim12]

Found an older post that discussed formatting from Windows and how that may zero out the disk.

http://communities.vmware.com/message/1511243

If you found this or any other post helpful please consider the use of the Helpful/Correct buttons to award points

[DSTAVERT]

One of William Lam's scripts might help to discover the vmdk type.

http://communities.vmware.com/docs/DOC-11554