Under which two conditions can vStorage APIs for Array Integration (VAAI) provide a performance benefit? (Choose two.)
A.
When a virtual disk has VMDK files stored on an NFS datastore.
B.
When a virtual disk is created using the New Virtual Machine wizard.
C.
When cloning a virtual machine with snapshots.
D.
When a virtual disk is deleted.
I feel like the answers are C and D, VAAI should speed up cloning shouldn’t it?
Can anyone help me understand why VAAI would make any difference to a VMDK on an NFS datastore?
I feel like anwser B could also be correct. VAAI will create an thick disk must faster then without VAAI.
http://www.youtube.com/watch?v=FiIn70FJZb4
Cloning is also faster, but im not sure when using snapshots?
From vsphere-esxi-vcenter-server-501-storage-guide.pdf, page 171, Hardware Acceleration Benefits.
The host can get assistance with the following activities:
– Cloning virtual machines or templates
– Writes to thin provisioned and thick virtual disks
Page 172, Hardware Acceleration for Block Storage Devices.
– Block zeroing, also called write same. Enables storage arrays to zero out a large number of blocks to provide newly allocated storage, free of previously written data. This operation reduces the time and network load when creating virtual machines and formatting virtual disks.
On the basis of these statements, I feel like the answers are B and C
I’m confused. At http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1021976 we read that:
VAAI uses these fundamental operations:
– Atomic Test & Set (ATS), which is used during creation and locking of files on the VMFS volume
– Clone Blocks/Full Copy/XCOPY, which is used to copy or migrate data within the same physical array
– Zero Blocks/Write Same, which is used to zero-out disk regions
– Thin Provisioning in ESXi 5.x and later hosts, which allows the ESXi host to tell the array when the space previously occupied by a virtual machine can be reclaimed on thin provisioned LUNs.
– Block Delete in ESXi 5.x and later hosts, which allows for space to be reclaimed using the SCSI UNMAP feature. For more information on Block Delete/SCSI UNMAP.
On the basis of these statements, the correct answers are C and D
this link suggests that VAAI can not offload a vm clone with snapshots to the storage hardware: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1021976
B is far too ambiguous, we don’t know if the provisioning type is thin or thick.
D is obvious, so it leave A as the last option. A is worded horribly, but still the best-worst answer.
Hardware Acceleration Benefits
When the hardware acceleration functionality is supported, the host can get hardware assistance and perform
several tasks faster and more efficiently.
The host can get assistance with the following activities:
Migrating virtual machines with Storage vMotion
Deploying virtual machines from templates
Cloning virtual machines or templates
VMFS clustered locking and metadata operations for virtual machine files
Writes to thin provisioned and thick virtual disks
Creating fault-tolerant virtual machines
Creating and cloning thick disks on NFS datastores
from vStorage APIs for Array Integration FAQ
…….
What improvements have been made to VAAI for ESXi 5.x?
To encourage customers to use larger and fewer datastores, in ESXi 5.0, support for Thin Provisioning VAAI primitive has been added .
In ESX5.0, support for NAS Hardware Acceleration is included with support for the following primitives:
Full File Clone – Like the Full Copy VAAI primitive provided for block arrays, this Full File Clone primitive enables virtual disks to be cloned by the NAS device.
Native Snapshot Support – Allows creation of virtual machine snapshots to be offloaded the array.
Extended Statistics – Enables visibility to space usage on NAS datastores and is useful for Thin Provisioning.
Reserve Space – Enables creation of thick virtual disk files on NAS.
Note: Previously the only supported VMDK type that could be created on NAS was thin.
………..
since a snapshot is a delta vmdk, with the Full File Clone primitive ….. C is correct
VAAI hardware offload cannot be used when:
The source and destination VMFS volumes have different block sizes
The source file type is RDM and the destination file type is non-RDM (regular file)
The source VMDK type is eagerzeroedthick and the destination VMDK type is thin
The source or destination VMDK is any kind of sparse or hosted format
Cloning a virtual machine that has snapshots (or doing a View replica or recompose), because this process involves consolidating the snapshots into the virtual disks of the target virtual machine
The logical address and/or transfer length in the requested operation is not aligned to the minimum alignment required by the storage device (all datastores created with the vSphere Client are aligned automatically)
The VMFS datastore has multiple LUNs/extents spread across different arrays
it is clearly written there that cloning a virtual machine that has snapshot cannot be used….In my opinion A and D are correct.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1021976
Block Zeroing, also known as Write Same/Zero: This enables the storage system to “zero out” a large number of data blocks to expedite the provisioning of new VMs and reduce I/O for common tasks.
So B is true
VAAI hardware offload cannot be used when: Cloning a virtual machine that has snapshots
So C is wrong
How a disk running on NFS provide performance benefits ?
NFS datastores support only thin Storage so thin type is not very fast
Note: NFS server supports thick layer in the VAAI v2 ( so little confuse)
So i think A is wrong
so B and D are true
answer A seems to be correct, NFS with Hardware Acceleration enabled can benefit from VAAI.
http://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.vm_admin.doc_50%2FGUID-4C0F4D73-82F2-4B81-8AA7-1DD752A8A5AC.html
ESXi/ESX 4.1 does not support hardware acceleration with NAS storage devices.
Support for NAS storage devices was introduced in ESXi 5.x.
VAAI hardware offload cannot be used when:
The source and destination VMFS volumes have different block sizes
The source file type is RDM and the destination file type is non-RDM (regular file)
The source VMDK type is eagerzeroedthick and the destination VMDK type is thin
The source or destination VMDK is any kind of sparse or hosted format
Cloning a virtual machine that has snapshots (or doing a View replica or recompose), because this process involves consolidating the snapshots into the virtual disks of the target virtual machine
The logical address and/or transfer length in the requested operation is not aligned to the minimum alignment required by the storage device (all datastores created with the vSphere Client are aligned automatically)
The VMFS datastore has multiple LUNs/extents spread across different arrays
Note: Hardware cloning between arrays (even if within the same VMFS datastore) does not work.
In ESXi 5.x, support for NAS Hardware Acceleration is included with support for these primitives:
Full File Clone – Like the Full Copy VAAI primitive provided for block arrays, this Full File Clone primitive enables virtual disks to be cloned by the NAS device.
Native Snapshot Support – Allows creation of virtual machine snapshots to be offloaded to the array.
Extended Statistics – Enables visibility to space usage on NAS datastores and is useful for Thin Provisioning.
Reserve Space – Enables creation of thick virtual disk files on NAS.
Note: Previously, the only supported VMDK type that could be created on NAS was thin.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1021976
A and D are correct.
It looks like A & C can be correct. I don’t see anything for deleting a VMDK
https://www.vmware.com/pdf/vsphere4/r41/vsp_41_esxi_server_config.pdf (page 119)