VAAI consideration with View Composer

In keeping with this year’s theme of View being a big part of my work I spent some time with a customer this week, looking at a view implementation.  In emails with the customer an odd thing had come up, the View Composer Replica disks were being provisioned fully allocated, i.e. 30GB rather than the 10GB size of the data inside the VM.

You may want to revisit how View Composer disks work. You also may recall an earlier post about replica disks being bloated because deleted files remain on the disk, that was not the cause.  And you should definitely look at Duncan’s article about different datamovers used to copy disks on ESX.

The issue my customer had was that their Master VM (the one that is copied to the replica) was on a VAAI enabled array.  The same array holds the SSD backed datastore where the replica’s are held.  Since the two datastores both have a block size of 8MB the hardware offload datamover is used.  This datamover does not reclaim zeroed blocks in the copy, so the replica is the same size as the master, 30GB.  This was not desirable as a lot of expensive SSD was holding empty blocks.

The quick fix was to move the master to a datastore not on the VAAI array, in this case the local datastore in the host.   Since this has proved that the datamover was the cause of the issue (and that neither I nor the client was going mad) we will have to reformat one of the datastores with a different block size.  This will force the use of the zero reclaiming datamover.

I’d like to stress that VAAI is great for View Composer, hardware offload of locking makes VMFS perform better for the growing delta disks.  Do not disable VAAI to resolve this issue.  Also VAAI is great for storage copies and clones, but it behaves differently to non-VAAI when it comes to zero reclaim.  The solution is to have the Master VMs on datastores with different block size to the datastores that contain replicas.

My customer was using tiered storage, so only one replica per pool.  Without tiered storage there is one replica per datastore which makes fully allocated replicas far more painful.

Another side note is that the SSD backed datastore must have enough free space for the full size master VM in order to provision the replica, despite the fact that the replica is smaller than the master.  This is because before the clone we don’t know how much space will be saved by thin provisioning the replica.

© 2011, Alastair. All rights reserved.

About Alastair

I am a professional geek, working in IT Infrastructure. Mostly I help to communicate and educate around the use of current technology and the direction of future technologies.
This entry was posted in General. Bookmark the permalink.

2 Responses to VAAI consideration with View Composer

  1. CH says:

    What storage vendor is this? Would this behavior be vendor specific? More details please.

  2. Alastair says:

    The storage is a VMax. Duncan’s post suggests that this is expected behaviour for all VAAI arrays.
    I hope to be able to test on another array but don’t have a lot of options with VAAI since I don’t work for a storage vendor.

Comments are closed.