Uncategorized

vSphere 4.1 – The First Bug found (and how to resolve it)

Hi,

So i was having Fun testing Our new EMC VAAI integration into vSphere 4.1, and started to do a full clone of a VM X 10 Times.

What are VAAI you may asked, well, CLARiiON and Celerra and VMAX will support VMware vStorage APIs for Array Integration, .  there are some functions that your storage system can handle more efficiently than your virtual servers and their hosts can. VAAI moves these tasks from the host to the storage system to perform those functions faster — and free up resources for your virtual servers.

the API’s that were implemeted here includes

* Hardware-Accelerated Locking = 10-100x better metadata scaling

 –Replace LUN locking with extent-based locks for better granularity.

–Reduce number of “lock” operations required by using one efficient SCSI command to perform pre-lock, lock, and  post-lock operations.

 –Increases locking efficiency by an order of magnitude

* Hardware-Accelerated Zero = 2-10x lower number of IO operations –Eliminate redundant and repetitive host-based write commands with optimized internal array commands

* Hardware-Accelerated Copy = 2-10x better data movement –Leverage native array Copy capability to move blocks

anyway,

To my surprise, i found out that as oppose to the small disk I/O observed at early betas using ESXtop, in this build generated a LOT of IOPS..

i started scratching my Head..what could it be, so i started eliminating,

first thing ive done is to clone the VM at the same datastore..that worked just Fine as observed here:

so that leaded me to think there is something wrong with the source datastore where the template reside..i checked the source datastore and then it hit me, 

The “template Datastore” Block Size was 1MB cluster size, and the “Target Datastore” was 2MB cluster size..

and i HAVE seen this bug before (4.0 – 4.0.2), so i formatted the source datastore to be at  a 2MB cluster dize and that fixed the problem..

so, an old problem that was fixed in vSphere 4.0.2 came back from the dead

🙂

Update1: it turned out that this is by Design:

linked to chad’s blog at:

http://virtualgeek.typepad.com/virtual_geek/2010/07/vsphere-41—what-do-the-vstorage-apis-for-array-integration-mean-to-you.html#more

The source and destination VMFS volumes have different block sizes (a colleague, Itzik Reich, already ran into this one at a customer, here – not quite a bug, but it does make it clear – “consistent block sizes” is a “good hygiene” move)

Categories: Uncategorized

2 replies »

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s