VMworld 2015: Virtual Volumes Technical Deep Dive
•Download as PPTX, PDF•
0 likes•552 views
This document provides a technical deep dive on virtual volumes. It begins with an overview of the challenges with today's LUN-centric storage architectures, such as complex provisioning, wasted resources, and lack of granular control. It then introduces an application-centric model using virtual volumes that provides dynamic storage service levels, fine-grained control at the VM level, and common management across arrays. The rest of the document details the management plane, data plane, consumption model using storage policy-based management, virtual machine lifecycles, snapshots, and offloading operations with virtual volumes.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to VMworld 2015: Virtual Volumes Technical Deep Dive
Similar to VMworld 2015: Virtual Volumes Technical Deep Dive (20)
More from VMworld
More from VMworld (14)
Recently uploaded
Recently uploaded (20)
VMworld 2015: Virtual Volumes Technical Deep Dive
- 1. Virtual Volumes Technical Deep Dive Ken Werneburg, VMware, Inc Patrick Dirks, VMware, Inc STO4649 #STO4649
- 2. • This presentation may contain product features that are currently under development. • This overview of new technology represents no commitment from VMware to deliver these features in any generally available product. • Features are subject to change, and must not be included in contracts, purchase orders, or sales agreements of any kind. • Technical feasibility and market demand will affect final delivery. • Pricing and packaging for any new technologies or features discussed or presented have not been determined. Disclaimer CONFIDENTIAL 2
- 3. Today’s Challenges in External Storage Architectures External Storage vSphere Array-a Array-b Today 1. Create fixed-size, uniform LUNs 2. Lack of granular control 3. Complex Provisioning cycles 4. LUN centric storage configurations ✖ Extensive manual bookkeeping to match VMs to LUNs ✖ LUN-granularity hinders per-VM SLAs ✖ Overprovisioning (better safe than sorry!) ✖ Wasted resources, wasted time, high costs ✖ Frequent Data Migrations LUN LUN LUN LUN LUN CONFIDENTIAL 3
- 4. Instead… an App-centric Model Drives Agility and QoS 5 App-centric Automation • Dynamic delivery of storage service levels when needed • Fine control of data services at the VM level • Common management across heterogeneous devices Rapid provisioning No overprovisioning of resources QoS automation Simple change management Today • Static pre-allocation of shared storage container (LUN) • Data services tied to storage container • Vendor specific management ✖ Long provisioning cycles ✖ Overprovisioning of resources Today’s Infrastructure-centric Model ✖ Management complexity ✖ Frequent data migrations CONFIDENTIAL
- 5. Replication Snapshots Caching Encryption De-duplication vSphere External Storage Architectures with Virtual Volumes External Storage with VVols Policy based Management Offloaded Data Services Eliminates LUN Management Provides Per-VM Granularity datastore a External Storage without VVols vSphere Array-a Array-b LUN LUN LUN LUN LUN AND CONFIDENTIAL 7
- 6. Agenda 1 What are VVols? 2 Management Plane 3 Data Plane 4 Consumption Model - SPBM 5 VM Lifecycle with VVols 6 VVol Snapshots 7 Questions and Answers CONFIDENTIAL 9
- 7. vSphere Virtual Volumes A More Efficient Operational Model For External Storage
- 8. VMware vSphere Virtual Volumes 13 Integration Framework for VM-Aware Storage Virtual Volumes Overview • Virtual disks are natively represented on arrays • Enables VM granular storage operations using array-based data services • Extends vSphere Storage Policy-Based Management to the storage ecosystem • Supports existing storage I/O protocols (FC, iSCSI, NFS) • Based on T10 industry standards • Industry-wide initiative supported by major storage vendors • Included with vSphere CONFIDENTIAL
- 9. High Level Architecture Published Capabilities Snapshot Replication Deduplication Encryption Overview • No FileSystem • ESX manages Array through VASA (vSphere APIs for Storage Awareness) APIs. • Arrays are logically partitioned into containers, called Storage Containers • VM disks, called Virtual Volumes, stored natively on the Storage Containers. • IO from ESX to array is addressed through an access point called, Protocol Endpoint (PE) • Data Services are offloaded to the array • Managed through storage policy-based management framework vSphere Storage Policy-Based Mgmt. Virtual Volumes Storage Policy Capacity Availability Performance Data Protection Security PE VASA Provider CONFIDENTIAL 14
- 10. vSphere Virtual Volumes • Virtual Volumes – Virtual machine objects stored natively on the array – No Filesystem on-disk formatting required • There are five different types of recognized Virtual Volumes: – CONFIG – vmx, logs, nvram, log files, etc – DATA – VMDKs – MEM – Snapshots – SWAP – Swap files – Other – vSphere solution specific type vSphere Web Client View vvol CONFIDENTIAL 16
- 11. Storage Container Storage Containers • Logical storage constructs for grouping of virtual volumes. • Typically defined and setup by storage administrators on the array in order to define: – Storage capacity allocations and restrictions • Capacity is based on physical storage capacity • Logically partition or isolate VMs with diverse storage needs and requirement – Storage policy settings based on data service capabilities • Minimum one storage container per array • Maximum depends on the array vSphere Virtual Volumes SAN / NAS Storage Containers CONFIDENTIAL 17
- 12. Differences between Storage Containers and LUNs • Size based on array capacity • Max number of SCs depend only on the array ability • Size of SC can be extended • Can distinguish heterogeneous capabilities for different VMs (Virtual Volumes) provisioned in that SC • Fixed size mandates more number of LUNs • Needs a FileSystem • Can only apply homogeneous capability on all VMs (VMDKs) provisioned in that LUN. • Managed by In-band FileSystem commands Storage Containers LUN CONFIDENTIAL 19
- 13. Storage Container (SC) vSphere Web Client Storage Management UI Datastore Storage Container • What do the Admins see? • How are the storage containers setup? • What does the vSphere Admins see? • Why are we still creating datastores in this new model? CONFIDENTIAL 20
- 14. Virtual Volumes VM objects view from a storage container on an arrayVM objects view from a datastore vSphere Web Client Storage Management UI vSphere Admin View Storage Admin View CONFIDENTIAL 22
- 15. Management Plane vSphere Virtual Volumes
- 16. VASA Provider (VP) • Software component developed by storage array vendors • ESX and vCenter Server connect to VASA Provider (VP) using standard VASA protocol • VP provides Storage Awareness services and presents array’s SPBM capabilities • Single VP can manage multiple arrays • Interface between VP and array is private and VP can be designed to run anywhere (e.g. within the array’s management server, in firmware, or outside the array) • Responsible for creating and managing Virtual Volumes SAN / NAS Virtual Datastore Standard SAN/NAS Data Path Protocol Endpoint(s) vSphere Virtual Volumes Storage Container VASA Provider (VP) Standard VASA Control Path Private array Control Path CONFIDENTIAL 24 PE PE PE
- 17. Data Plane vSphere Virtual Volumes
- 18. Discovery Procedures – Storage Container Virtual Volumes Snapshot Replication vCenter VASA Provider Storage Container Discovery Process • Storage admin sets up Storage Container with desired capacity • Desired Capabilities are configured for the Storage Containers • VASA Provider (VP)’s URL is registered in VC • VASA Provider presents Storage Container and its capabilities to vCenter • Any new VMs that are created will subsequently be provisioned in the Storage Container based on SPBM profile associated with virtual disks CONFIDENTIAL 26
- 19. Protocol Endpoints Protocol Endpoints • Access points that enables communication between ESXi hosts and storage array systems. – Part of the physical storage fabric – Created by Storage administrators Scope of Protocol Endpoints • Compatible with standard SAN and NAS Protocols: - iSCSI - FC - FCoE - NFS v3 • Existing multi-path policies and NFS topology requirements are applied to the PE Why Protocol Endpoints? SAN / NAS Virtual Datastore Data Path Protocol Endpoint(s) PE vSphere Virtual Volumes Storage Container CONFIDENTIAL 27
- 20. Discovery Procedures – Protocol Endpoint Protocol Endpoint discovery process • VASA Provider (VP) reports PEs for container to VC at registration • When Virtual Datastore is created on host, VC passes PE information to host • SCSI PEs are discovered during an ESX rescan • NFS PEs are configured and mounted automatically • Hosts report to VP which PEs are accessible SAN / NAS Virtual Datastore Data Path Protocol Endpoint(s) PE vSphere Virtual Volumes Storage Container VASA Provider CONFIDENTIAL 29
- 21. Binding Operations • Bindings are data paths created by VP, in coordination with the array, on request from ESXi hosts, between hosts and array for accessing virtual volume. • Different Binding Mechanism: • Binding – requests creation of I/O channels for a virtual volume • Unbind – destroys the I/O channel for a virtual volume to a given ESXi host • Rebind – provides the ability to change the I/O channel (PE) for a given virtual volumes run time using events. create bind unbinddelete VM Creation VM power-on open (2) I/O read (2) I/O write (2) VM power-off close (2) VM destroy VP rebalance REBIND I/O Virtual Volume Lifecycle CONFIDENTIAL 30
- 22. Bind Requests • IO path is established through a VASA Bind request • VASA Provider does two things upon receiving a Bind request • Coordinates with array to select a PE and unique secondary ID for VVol to be bound • Returns a PE ID and secondary ID to which the VVol is bound to host • For SCSI, the secondary ID is the secondary LUN ID • For NAS, the secondary ID is the file path • M:M Relationship between VVol and PE Virtual Volumes VASA Provider VVol PE VVol Bind CONFIDENTIAL 32
- 23. CONFIDENTIAL Virtual Volumes – Other Bind Scenarios UNBIND Virtual Volumes VASA Provider VVol PE VVol UNBIND • Delete binding of a VVol to the PE • VASA Provider deletes binding on request of host (usualy at VM power-off) REBIND Virtual Volumes VASA Provider VVol PE VVol PE REBIND • Move VVols access to different PE • VASA Provider may choose to issue a rebind for several reasons, such as load balancing or storage migration 33
- 24. VVol Consumption Model: Ensuring SLOs through SPBM – Storage Policy-Based Management
- 25. Storage Capabilities and VM Storage Policies • Storage Capabilities – are array based features and data services specifications that capture storage requirements that can be satisfied by a storage arrays advertised as capabilities • Storage capabilities define what an array can offer to storage containers as opposed to what the VM requires • Arrays Storage Capabilities are advertises to vSphere through the Vendor Provider and VASA APIs • In vSphere Storage Capabilities are consumed via VM Storage Policy constructs • VM Storage Policies is a component of the vSphere Storage Policy-based management framework (SPBM) SPBM object manager virtual disk Datastore Profile VM Storage Policy vSphere VM Storage Policy Management Framework Storage Capabilities for Storage Array Access Capacity Published Capabilities Snapshot Replication Deduplication QoS Virtual Datastore CONFIDENTIAL 35
- 26. Storage Policy Based Management (SPBM) – Array Capabilities Virtual Volumes APIs Storage Policy-Based Mgmt. CV CV CV Storage admin Publish Capabilities • Array based features and data services • Defines what an Array can offer • Advertised to ESX through VASA APIs Sample Default Profile for (6090a058-cd89-ffe3-87763007db37] - capabilities Disk Types Disk Encryption Dedupe Replication Snapshot CONFIDENTIAL 36
- 27. Storage Policy Based Management (SPBM) – VM Policies CONFIDENTIAL 37
- 28. Storage Policy Based Management (SPBM) CONFIDENTIAL 38
- 29. Management Workflow • What do the Admins see? • How are the storage containers setup? • What does the vSphere Admins see? • Why are we still creating datastores in this new model? Storage policies vSphere Web Client Storage Management UI Datastore Storage Container Storage Capabilities virtual volumes virtual machines CONFIDENTIAL 39
- 31. vvol DATA vvol CONF vvol SWAP vvol DATA vvol CONF vvol SWAP Provisioning Workflow storage arrays PE vSphere Admin 1. Create Virtual Machines 2. Assign a VM Storage Policy 3. Choose a suitable Datastore Under the Covers • Provisioning operations are translated into VASA API calls in order to create the individual virtual volumes. Under the Covers • Provisioning operations are offloaded to the array for the creation of virtual volumes on the storage container that match the capabilities defined in the VM Storage Policies offloadtoarray Virtual Datastore Storage Container vSphere Virtual Volumes CONFIDENTIAL 41
- 32. Snapshots • Snapshots are a point in time copy on write image of a Virtual Volume with a different ID from the original • Virtual Volumes snapshots are useful in the contexts of creating: – a quiesced copy for backup or archival purposes, creating a test and rollback environment for applications, instantly provisioning application images, and so on • Two type of snapshots supported: – Managed Snapshot – Managed by ESX • A maximum of 32 vSphere managed snapshot are supported for linked clones of an individual VM – Unmanaged Snapshot – Manage by the storage array • Maximum snapshot dictated by the storage array Managed Snapshot - vSphere Unmanaged Snapshot - Array CONFIDENTIAL 42
- 33. Snapshots: Files vs. Vvols flat filemain.vmdk main.vmdk redo logsnap.vmdk snap.vmdk VVol ID 86 VVol ID 42 CONFIDENTIAL 43
- 34. Revert to Snapshot: Files vs. Vvols flat filemain.vmdk main.vmdk redo logsnap.vmdk snap.vmdk VVol ID 86 VVol ID 42 backout VVol ID 243 Snap Shot data CONFIDENTIAL 44
- 35. vSphere Virtual Volumes Is An Industry-wide Initiative 46 Multiple Available Now Unique capabilities And Many More… 39Partnersin theProgram CONFIDENTIAL
- 36. The Benefits of vSphere Virtual Volumes 47 A More Efficient Operational Model For External Storage Improves Resource Utilization • Increase capacity utilization. • Eliminate overprovisioning • Reduce management overhead • Eliminate inefficient handoffs between VI and Storage Admin • Faster storage provisioning through automation • Simplified change management through flexible consumption • Self-service provisioning via cloud automation tools Simplifies Storage Operations • Leverage native array-based capabilities • Fine control at the VM level • Dynamic configuration on the fly • Ensure compliance through policy enforcement using automation Simplifies Delivery of Service Levels CONFIDENTIAL
- 39. Virtual Volumes Technical Deep Dive Ken Werneburg, VMware, Inc Patrick Dirks, VMware, Inc STO4649 #STO4649
- 40. Backup
- 41. Operation Scenarios Offload, Migrations, Snapshots 53
- 42. Migration Scenario: with VAAI vs Virtual Volumes VASA API Compatible Array 2 vSphere VMFS VVOLs 1 vSphere Admins Migrate VM from VMFS to VVOL datastore software data mover implementation CONFIDENTIAL 54
- 43. 55 vSphere Virtual Volumes Offload Operations vSphere VMFS VVOLs vSphere Admins offload to array offloadtoarray Virtual Machine Operation Offloaded • Virtual Machine provisioning • Virtual Machine deletes • Virtual Machine full clones • Virtual Machine Linked Clones • Virtual Machine Snapshots • Storage vMotion (Powered off VMs) CONFIDENTIAL
- 44. VM operation from VVOLs container to different VVOLs container vSphere Admins vSphere 1 2 offloadtoarray 3 Fully VAAI & VASA APIs Compatible Array SC-A SC-B always attempt default operation with VASA API primitives If default operations fails VAAI API primitives are used VM operation from VVOLs container to different VVOLs container vSphere Admins vmkernel data mover uses VAAI primitives for cloning operation vSphere 1 2 offloadtoarray 3 Fully VAAI & VASA APIs Compatible Array SC-A SC-B default1 fail back 2 vendor native clone utilized with VASA primitives cloning operation VAAI vs VVOLs CONFIDENTIAL 58
Editor's Notes
- Today Device specific management Rigid SLAs management from LUNs Lack of VM awareness Difficult to forecast right capacity and performance use over time Difficult to change policies once allocated based on pre-defined configurations Difficult to change apps to new policies T: Let’s examine in more detail how storage policy-based management works.
- Customer ask us the question sometimes… “Why is VMware entering the storage market?” The answer is simple, with the hypervisor, we have an opportunity to change how we address the storage challenge The hypervisor is uniquely positioned in the IT stack to have visibility to: See what applications are running in VMs at any given time, and Have a global view of underlying infrastructure Because it sits directly in the I/O path, the hypervisor has the unique ability to make optimal decisions around matching the demands of virtualized applications with the supply of underlying physical infrastructure. The result is that the hypervisor enables a new approach to storage that puts the application in charge of defining its own storage requirements. Virtualization is the gateway to enable a new way of provisioning and managing storage that lets software manage storage needs T: Let us show you how this works…
- How does the VVol architecture enable your storage partner to improve your storage consumption? Move from per-LUN to per-VM provisioning based on SLAs applied to VMs and virtual disks Enable arrays to present their unique capabilities (availability, dedup, compression, encryption, ...) Give arrays control at individual virtual disk granularity Simplify provisioning by channeling all access through pre-configured PEs Software-Defined Storage Flexible resource management Common control across heterogeneous resources Granular VM-centric SLA management Without VVols: • LUN is formatted as single monolithic datastore • Virtual disks are VMDK files scattered over the filesystem • Endpoint to receive SCSI or NFS read/write IO • Storage is unaware of virtual disks or VMs With VVols: • Storage Container is abstraction for available space • Virtual disks are created as individual Virtual Volumes with Storage Requirement Profile • Data path uses existing storage connectivity • “Protocol Endpoint” is SCSI LUN or NFS mountpoint • Storage system in complete control of Virtual Volume
- SDDC is not just a VMware vision -- an approach embraced by IT teams around the world SDDC involves decoupling software from hardware to improve agility, flexibility and efficiency Abstracting, Pooling and Automating resources to make them more easily consumed Four key pillars of SDDC… Expanding compute to all applications… Virtualize the network to increase speed and efficiency… Replacing manual approaches to IT management with automation… T: And the last pillar… is about transforming storage by introducing a new operational model that is driven by applications
- Storage has long been a critical piece of every datacenter Not only does it allow you to store data, but we are transitioning into a data-driven era Capacity and speed are important The industry is changing, new competition, new technologies T: As we think about the change, it is important to understand the challenges being seen in today’s data center
- Virtual Volumes virtualizes SAN and NAS devices into logical pools of capacity, called Virtual Datastore. Then, Virtual Volumes represents virtual disks natively on the underlying physical storage. This makes the virtual disk the primary unit of data management at the array level. It becomes possible to execute storage operations with VM granularity and to provision native array-based data services to individual VMs. To enable efficient storage operations at scale, Virtual Volumes uses vSphere Storage Policy-Based Management Both Virtual Volumes and SPBM are offered as standard features of the vSphere platform, from a pricing and packaging standpoint.
- Storage Admin Cares about Capacity Management Access Control Admissible Data Services Meeting Application SLA requirements Data Security VI admin cares about On-demand storage provisioning for VMs Application of appropriate VM-level data services SLA compliance checks throughout VM lifecycle
- Other-Vvol is a generic type of Vvol for solution specific objects i.e HBR side car file, CBRC files, etc
- Capacity is based on physical storage capacity A single Storage Container can be simultaneously accessed via multiple Protocol Endpoints Questions: How is it setup ? How is it discovered? What are all the aspects to consider when setting it? Does the PE and SC have to be aware of each other? Assigning capabilities to a SC? Associating a datastore to a storage container? Why do you need to create a datastore? Products like vCAC, vCOPs, DRS,VC use the concept of a datastore natively. What does the vsphere admin see? Need at least 1 SC per array. You can have as many as the array can support. An SC cannot span across array
- How is it setup ? How is it discovered? What are all the aspects to consider when setting it? Does the PE and SC have to be aware of each other? Assigning capabilities to a SC? Associating a datastore to a storage container? Why do you need to create a datastore? Products like vCAC, vCOPs, DRS,VC use the concept of a datastore natively. What does the vsphere admin see? An SC cannot span across array? No
- Why are datastores are still utilized: because vSphere and all of its platform features are aware of the concept of a datastore and in order to preserve the interoperability without requirement the adjacent feature modules to change. What does the vsphere admin see? They see the same vsphere datastore and information as normal in the vSphere Web Client. Screen shot Products like vCAC, vCOPs, DRS,VC use the concept of a datastore natively. Need at least 1 SC per array. You can have as many as the array can support. An SC cannot span across array
- Other-VVol is a generic type of Vvol for solution specific objects i.e HBR side car file, CBRC files, etc
- Storage awareness such as capabilities, status etc
- Why the concept of a PE? In today’s LUN-Datastore world, the datastore has two purposes – It serves as the access point for ESXi to send IO to. It also serves as storage container to store many VM files (VMDKs). This dual-purpose nature of this entity poses several challenges – You do not need as many access points as you need the storage itself. Because of the rigid nature of the size of the datastore, and the fewer number of datastores, you have to combine several VMs together to be stored in the same datastore even if the VMs have different requirements. So, how about we separate out the concept of the access point from the storage aspect? This way, we can fewer number of access points to several number of storage entities. And hence the introduction of PE.
- Questions: Equivalent to what in todays world?. E.i if there are vasa API to communicate with the array what will the PE do? What do some of the command do? Show and example! What is the discovery process? During a rescan ESX will identify PE and maintain then in DBs. Multi-pathing on the PE unsure high availability Concept of queue depth in a PE?
- Questions: Equivalent to what in todays world?. I.e. if there are vasa API to communicate with the array what will the PE do? What do some of the command do? Show and example! What is the discovery process? During a rescan ESX will identify PE and maintain then in DBs. Multi-pathing on the PE unsure high availability Concept of queue depth in a PE?
- ESX will call to the VASA provider using the bindVirtualVolume API with the given vvolID , which is the VVol ID. This makes up the "objectID". ESXi hosts will reference on a particular VVol ESXi hosts calls the VASA provider via an API with the given vvolID. The VASA provider will then return with a protocol endpoint ID as well as a secondary ID. In the case of SCSI, this is a second level LUN ID. In the case of NAS, this is an object for IO. Once this information is acquired from the VASA provider, it will be used to open a SCSI device in the SCSI stack of perform a file open on the NFS client depending on the transport of the VVol to construct the data path on ESX. (Can a PE be a SCSI and a NFS PE at the same time?) A VASA Provider may choose to unbind a VVol to a PE for several reasons to provide vendor specific capabilities.
- ESX will call to the VASA provider using the bindVirtualVolume API with the given vvolID , which is the VVol ID. This makes up the "objectID". ESXi hosts will reference on a particular VVol ESXi hosts calls the VASA provider via an API with the given vvolID. The VASA provider will then return with a protocol endpoint ID as well as a secondary ID. In the case of SCSI, this is a second level LUN ID. In the case of NAS, this is an object for IO. Once this information is acquired from the VASA provider, it will be used to open a SCSI device in the SCSI stack of perform a file open on the NFS client depending on the transport of the VVol to construct the data path on ESX. (Can a PE be a SCSI and a NFS PE at the same time?) A VASA Provider may choose to unbind a VVol to a PE for several reasons to provide vendor specific capabilities.
- a PE ID is the ID to which the VVols are bound to. Several ESX hosts may issue a bind to the same VVol and the underlying VASA provider may choose to return same of different PE IDs to different hosts. A Secondary ID to be used for I/O between the PE and the bound VVol. The scope of this ID is unique for this VVol-PE bind request. It established a unique communication channel for I/O to that VVol
- Why are datastores are still utilized: because vSphere and all of its platform features are aware of the concept of a datastore and in order to preserve the interoperability without requirement the adjacent feature modules to change. What does the vsphere admin see? They see the same vsphere datastore and information as normal in the vSphere Web Client. Screen shot Products like vCAC, vCOPs, DRS,VC use the concept of a datastore natively. Need at least 1 SC per array. You can have as many as the array can support. An SC cannot span across array
- [Ken] Unmanaged snapshots VMware anticipates that early generations of VVol storage systems will support on the order of tens of thousands of snapshots.
- This slide walks through the architecture of Vvols at a high level. Subsequent slides will dive into individual components in a bit more detail.
- Virtual Volumes is an industry-wide initiative that will allow customers to leverage the unique capabilities of their current storage investments and transition without disruption to a simpler and more efficient operational model optimized for virtual environments that works across all storage types. Major Storage vendors participated in the design of Virtual Volumes, and many more will support the initiative driving value with their unique implementations.
- Now let’s discuss the value proposition of vSphere Virtual Volumes Virtual Volumes simplifies storage operations by automating manual tasks and eliminating operational dependencies between the VI Admin and the Storage Admin. Provisioning becomes faster and change management simpler because of the policy-driven automation. Virtual Volumes simplifies the delivery of storage service levels to applications by providing administrators with finer control of storage resources and data services at the VM level that can be dynamically adjusted in real time. Virtual Volumes improves resource utilization by enabling more flexible consumption of storage resources, when needed and with greater granularity. The precise consumption of storage resources eliminates overprovisioning.
- storage vmotion is not offloaded to the array...if a VM has snapshots, the migration of those snapshots can be offloaded to the array, but svmotion of a live running disk is not offloaded. Only if the VM is not powered on is svmotion fully offloaded to the array (assuming the source and destination are managed by the same provider)