With the release last year of our new generation of ASA series of controllers, you may have noticed that I updated the VMware vSphere with ONTAP Best Practices to recommend using the latency policy option on the round-robin Path Selection Plugin (PSP) with ASA systems.

You can also set this option when using the newer High-Performance Plug-in (HPP) on either SCSI LUNs or NVMe namespaces). In fact, it’s quite easy with the HPP to just pop into the vCenter UI and click the option on the device.

Starting with VMware Cloud Foundation (VCF) / vSphere 9.0, this configuration is now the default for NetApp LUNs. Additionally, changes to the default NVMe namespace configuration may be introduced in a future update to ESXi.

But what if you aren’t using the HPP? Or if you are on a release that doesn’t support using the HPP on SCSI devices, limiting you to the old NMP plugin? Especially if you have a lot of hosts to manage?

My friend and coworker, @ScottBell , and I worked up this little PowerShell script using VMware PowerCLI to create a new Storage Array Type Plug-in (SATP) rule to update all of the hosts in the datacenter to use the latency policy.

It makes setting up demo labs so much faster and easier.

Before getting to the script, let me explain two things.

1. Even though the new ASA systems no longer have aggregates and volumes to manage, sharing a common Storage Availability Zone (SAZ) between the HA pair(s), and all paths being exposed symmetrically as ALUA active/optimized to all Storage Units(SUs, note that LUNs and namespaces are called SUs in the new ASA systems), one controller is still considered the owner of the SU, and IO to that node may be ever so slightly faster, measured in microseconds, than paths to the other controller. Therefore, under heavy sustained load, those microseconds could add up over time.
2. VMware added the latency option to the round robin PSP in ESXi way back in the vSphere 6.7 days. For over a decade, Linux (thus including KVM) has used a latency-based round-robin mechanism called dm-service-time, while Microsoft Windows/Hyper-V has long offered similar options like LQD (Least Queue Depth) and LB (Least Blocks).
   
   The goal with all of the previously mentioned examples is to prefer paths that perform the fastest. I.e., they have the lowest latency, the lowest number of outstanding commands or bytes, etc..
   
   Historically, that has been very helpful in other use cases too, especially instances where you may have asymmetric pathing (i.e., one path may have more hops than another), or you may have one path go flaky with a slowly failing SFP, a slightly over-bent Fibre cable, and other things like that.
   
   Flaky is my highly technical term, feel free to use it.

That’s where the advantage of using these types of multipath settings comes in handy with ASA systems. Although generally speaking, you will never notice the difference unless you are running a very storage-intensive workload, using every bit of performance the system has to offer. That being said, even when you aren’t pushing the systems very hard, the ability to automatically minimize using flaky paths that aren’t quite dead yet is incredibly beneficial.

Over the years of my career, I have seen many an outage or performance degradation caused by paths that just weren’t dead enough to fail out, but also ended up stalling IOs in the host’s queuing mechanism.

So, now that we’ve gotten that out of the way, onto the script.

Keep in mind that you will need to either unclaim/reclaim the LUNs, or put the hosts into maintenance mode and do a rolling reboot. Usually, you have to use the latter method because the former requires there to be no IO at all on a path to be unclaimed. *Sometimes* I have had luck with unclaiming/reclaiming with a host just in maintenance mode. But it seems inconsistent in my experience.

# Set the latency policy for NetApp ONTAP LUNs in a vCenter environment by specifying the datacenter to update.
# By Chance Bingen and Scott Bell, NetApp, 2025.

# Load VMware PowerCLI core module if not already available
Import-Module VMware.VimAutomation.Core

# Uncomment the below Set-PowerCLIConfiguration command if you want to ignore invalid certificates
# Note: This is not recommended for production environments as it can expose you to security risks.
# Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false

# Prompt for the vCenter Server
$vCenter = Read-Host -Prompt "What vCenter do you want to connect to?"
Write-Output "You entered: $vCenter"

# Prompt for vCenter Server credentials
$cred = Get-Credential

# Connect to the vCenter Server using the provided credentials
Connect-VIServer -Server $vCenter -Credential $cred

# Prompt for the datacenter
$Datacenter = Read-Host -Prompt "Which datacenter do you want to update?"
Write-Output "You entered: $Datacenter"

$vmhosts = Get-VMhost -Location $Datacenter

# Suppress PowerShell errors
$OldErrorActionPreference = $ErrorActionPreference
$ErrorActionPreference = "SilentlyContinue"

foreach ($vmhost in $vmhosts) {
    $esxcli = Get-EsxCli -VMHost $vmHost -V2
    $hostname = Get-VMHost $vmHost.Name
    $arguments = $esxcli.storage.nmp.satp.rule.add.CreateArgs()
    $arguments.pspoption="policy=latency"
    $arguments.description="NetApp ONTAP Latency SATP Rule"
    $arguments.vendor="NETAPP"
    $arguments.type="vendor"
    $arguments.satp="VMW_SATP_ALUA"
    $arguments.claimoption="tpgs_on"
    $arguments.psp="VMW_PSP_RR"
    $arguments.option="reset_on_attempted_reserve"
    $arguments.model="LUN C-Mode"
    $esxcli.storage.nmp.satp.rule.add.Invoke($arguments) | Out-Null
    # Check if the command was successful
    if ($?) {
        # Output a message including the hostname
        Write-Host "Successfully added Latency policy to host: $hostname"
    } else {
        Write-Host "Failed to add Latency policy to host $hostname"
    }
}

# Reset $ErrorActionPreference to previous value
$ErrorActionPreference = $OldErrorActionPreference

# Disconnect from the vCenter Server
Disconnect-VIServer -Confirm:$false

One thing you might change, depending on your environment, is scoping it to a particular vSphere cluster instead of a whole datacenter. To do that, just change this:

$Datacenter = Read-Host -Prompt "Which datacenter do you want to update?"
Write-Output "You entered: $Datacenter"

To this:

$vcluster = Read-Host -Prompt "Which cluster do you want to update?"
Write-Output "You entered: $vcluster"

And change this:

$vmhosts = Get-VMhost -Location $Datacenter

To this

$vmhosts = Get-Cluster -Name $vcluster | Get-VMhost

Of course, you may wonder about NVMe namespaces, since they exclusively use the HPP and not the Native Multipathing Plugin (NMP). Those are bit easier to do because there’s a native interface for it. But, if you have a lot of hosts to manage, you may want to script that too. If you would like to see some examples of that, let us know.

If you have any questions, feel free to comment below, and we’ll be happy to answer them.

More resources can be found at:

ONTAP 9 – Learn About ONTAP SAN Configuration

https://docs.netapp.com/us-en/ontap/san-config/index.html

Learn about SAN host configurations

https://docs.netapp.com/us-en/ontap-sanhost/overview.html

VMware vSphere with ONTAP Best Practices Guide (Formerly TR-4597)

https://docs.netapp.com/us-en/ontap-apps-dbs/vmware/vmware-vsphere-overview.html

TR-4080: Best Practices for Modern SAN

https://www.netapp.com/media/10680-tr4080.pdf

TR-4684: Implementing and Configuring Modern SANs with NVMe/FC

https://www.netapp.com/pdf.html?item=/media/10681-tr4684pdf.pdf

Let’s get into it.

Granular Datastore Protection: Protect Only What Needs Protecting

The headline feature in 10.6 is Granular Datastore Protection (GDP), which shifts both SnapMirror active sync (SMas) and most traditional SnapMirror replication policies from only protecting entire host clusters down to individual VMFS datastores. Instead of protecting every datastore in a cluster whether it needs it or not, vCenter administrators can now choose exactly which datastores belong in a protection group — and add, remove, or delete them one at a time without disturbing the rest.

What is a protection group? It’s a vCenter-local representation of a consistency group (CG) in ONTAP 9 on AFF, ASA, FAS, and software-defined systems. We chose to use the term “protection group” in ONTAP tools to be aligned with VMware’s terminology. What this ultimately means is that you can now create and manage CGs directly in the vCenter UI.

So, what does this mean for new ONTAP tools users?

• Selective protection — mix protected and unprotected datastores freely within the same host cluster.
• Operational flexibility — modify protection groups without tearing down protection for an entire cluster.
• Multiple protection groups per cluster — replicate different datastores to different storage virtual machines (SVMs) or targets as business needs dictate.
• Incremental adoption — protect new datastores as they’re created, or bring existing ones into a group over time.

Ok, what if you are an existing user of ONTAP tools? It's simple — upgrades from ONTAP tools 10.4 and 10.5 seamlessly migrate existing host-cluster protection settings to the new model, no manual reconfiguration or import required.

GDP supports SnapMirror active sync's "Automated Failover Duplex (AFD)" policy across uniform and non-uniform vSphere Metro Storage Cluster (vMSC) topologies — giving architects far more precision when designing business continuity for mixed-criticality workloads. GDP can also use traditional asynchronous SnapMirror policies, though that would not be a vMSC configuration.

For a deep dive into GDP, check out the blog that Rajiv and I wrote about it: SnapMirror Active Sync + ONTAP tools for VMware vSphere Granular Datastore Protection (OTV10.6) - NetApp Community

A Lighter Footprint, Right Out of the Box

Not every environment needs a heavyweight appliance. ONTAP tools 10.6 introduces an Extra Small (XS) deployment size — just 6 vCPUs and 12 GB of RAM per node — and makes it the default Day-0 deployment profile for traditional provisioning and protection workloads. That’s a noticeable reduction from the previous Small footprint (9 vCPU / 18 GB), removing a resource barrier that had kept smaller environments and edge sites from adopting ONTAP tools.

Also new in this release, CPU hot add and memory hot plug are now enabled by default, so scaling up to small, medium, or large later requires no manual reconfiguration on fresh 10.6 deployments, nor do you have to shut down the appliance to reconfigure it if you forgot to do so during the initial deployment.

Stronger Security Visibility with Expanded Audit Logging

Security and compliance teams get a significant upgrade in 10.6. ONTAP tools now captures detailed audit logs (including full request and response bodies), discovery and cleanup jobs, and maintenance console operations — complete with username, timestamp, and correlation IDs for full traceability. Logs are retained for 30 days by default (configurable), protected by automated integrity checks that raise alerts on tampering or deletion, and can be forwarded to external systems like VCF Operations for Logsvia syslog. Enterprise security teams increasingly require this level of visibility. With ONTAP tools 10.6, it’s now built directly into the appliance.

Faster NFS Datastores with nconnect Support

NFS performance got a major boost with nconnect support back in 8.0u2. But it lacked any kind of GUI or API (I wrote a blog about it here: Automate nconnect and snapshot offload for NFS datastores and turn your VMware storage up to 11 - NetApp Community). It is now configurable directly during NFSv3 and NFSv4 datastore provisioning. By establishing multiple TCP connections over a single IP address, nconnect lets ESXi hosts distribute file operations across those connections in round-robin fashion — unlocking more of the available network bandwidth for NFS workloads without any change to the storage network topology. With nconnect, NFS datastores deliver SAN-level performance with NAS-level simplicity.

ONTAP tools 10.6 can even modify the maximum nconnect limit of your ESXi hosts from the default limit of 4 up to the maximum supported 8.

When it comes to nconnect integration, there is one caveat to be aware of: due to a limitation in the vCenter SDK, a plugin can’t modify nconnect settings after the datastore is mounted. However, starting with vSphere 9.0, you can change these settings in the datastore's host connectivity menu. Additionally, you can use the script that I shared earlier.

Cleaner Lifecycle Management

Even good old-fashioned housekeeping gets easier with ONTAP tools 10.6. A new force-delete flag for vCenter removal lets administrators clean up stale or unreachable vCenter entries — including automatic ONTAP tools plugin unregistration — without being blocked by lingering storage backend or datastore associations, provided no vVol datastores or active protection are involved.

Under the hood, ONTAP tools 10.6 also dynamically switches from ntpd to chronyd for time synchronization (with automatic migration on upgrade), re-implements and optimizes the authentication service for a smaller resource footprint and faster startup, and reorganizes log storage under a dedicated /var/log/otvng directory for cleaner troubleshooting and log rotation.

Availability

ONTAP Tools for VMware vSphere 10.6 launched on July 24, 2026, and supports ONTAP 9.16.1 through 9.19.1 alongside VMware Cloud Foundation (VCF) 5.2.1 through 9.0, and vSphere 8.0U3 through 9.0(the appliance can be deployed on ESXi 9.1). More version qualifications may be coming, so stay tuned for further updates. Direct upgrades are supported from ONTAP tools 10.4 and 10.5, with existing host-level protection settings automatically migrated to the new Granular Datastore Protection model.

In summary, whether you’re running a lean single-site deployment or a stretched, multi-site VMware environment protected by SnapMirror Active Sync, ONTAP tools 10.6 gives you finer control, a smaller footprint, and better visibility — all without compromising on the enterprise-grade protection NetApp customers count on.

Active-Active VM Storage at Datastore Granularity: SnapMirror Active Sync meets ONTAP tools Granular Datastore Protection 

The two things to remember 

1. Active-active with synchronous SnapMirror (SnapMirror active sync / SM-as) — ONTAP TOOLSONTAP tools Granular Datastore Protection (GDP) lets you hand-pick VMFS-FC or VMFS-iSCSI datastores inside an ESXi host cluster and protect them with zero recovery time objective (RTO)/zero recovery point objective (RPO)replication backed by ONTAP SnapMirror Active Sync. VMs can read and write from either site. 
2. Load balancing across sites: Workloads can actively use I/O from either location.  
3. With uniform host proximity, peered datastores at both sites are mapped to ESXi hosts at both sites. If one ONTAP cluster becomes unreachable, VMs continue serving I/O from the surviving site with typical failover latency on the order of ~11 ms (the actual I/O resumption time [IORT] will be environment-dependent).  
4. With non-uniform host proximity, ESXi hosts are only mapped to the local copy of the datastore. I.e. If a VM migrates or fails over to a host on the other site, that host only accesses the local ONTAP cluster. If one ONTAP cluster becomes unreachable, the VM will use vSphere HA to failover to the other site since it can only access its local copy.  

Everything else in this article explains how ONTAP tools 10.6 provisions and governs that experience. 

Why GDP changes the protection conversation 

Before ONTAP TOOLS 10.6, Host Cluster Protection (HCP) was all-or-nothing: protecting a cluster meant protecting every eligible VMFS datastore on that cluster together. 

Granular Datastore Protection (GDP) shifts the unit of protection from the host cluster to individual VMFS datastores — while still operating within a single ESXi host cluster boundary. 

Customer value: Protect only the datastores that matter, add/remove datastores over time, and run different SnapMirror targets per SVM, without forcing every datastore in the host cluster into the same protection group. 

What ONTAP SM-as brings to GDP 

SnapMirror Active Sync (SM-as) is ONTAP’s synchronous, active-active replication mode used by the Automated Failover Duplex (AFD) policy. Combined with GDP, it delivers: 

• RPO = 0 — writes are synchronously committed to NVRAM on both sites before acknowledgment 
• RTO = 0 — because both copies are always available, IO can resume as soon as the mediator initiates the failover and the host multipath driver can retry any required I/Os 
• Active-active data path — both copies are read/write capable (policy and proximity permitting) 
• Consistency group (CG) backed protection — multiple LUNs/datastores in one atomic replication unit 
• Automatic host access orchestration — ONTAP TOOLS manages igroups, LUN maps, mounts, and HBA rescans 

GDP is the ONTAP TOOLS control plane; SM-as is the ONTAP replication engine. ONTAP TOOLS creates and lifecycle-manages: 

• Protection Settings — which datastores are protected, CG membership, SnapMirror relationship 
• Cluster Configuration — fault domains, host-to-SVM mapping, uniform vs non-uniform proximity 
• Initiator groups (igroups) — host IQNs/WWPNs mapped to protected LUNs at each site 

ONTAP TOOLS 10.6 constructs that you configure 

1. Protection Setting 

A protection group ties together: 

• One or more VMFS datastores (same host cluster, same SVM) 
• An ONTAP consistency group 
• A SnapMirror Active Sync relationship (for AFD) 
• Initiator groups for host access 

Typical workflows: Protect · Modify (add/remove datastore) · Unprotect · Delete 

2. Cluster Configuration (required for AFD / SM-as) 

Maps an ESXi host cluster to two fault domains (Site A / Site B): 

• Each fault domain lists ESXi hosts + peered source/target SVMs 
• The uniform_host_config attribute is set at create time and is immutable 

The following table illustrates the two protection constructs. 

Prerequisite: Create Cluster Configuration before protecting datastores with AFD/SM-as. Async-only SnapMirror does not require cluster configuration. 

Uniform vs Non-Uniform Host Proximity 

This is the architectural fork that determines the system behavior during various modes of failure in different fault domains. 

Uniform proximity (uniform_host_config = true) 

Behavior: Peered datastores from both sites are mapped to ESXi hosts at both sites. All hosts in the cluster can access all protected datastores. ONTAP TOOLS manages igroup replication and host proximity settings across both SVMs. 

Use cases: 

• Active-active workload distribution — VMs on either site issue I/O to locally mapped LUNs based on proximity settings 
• Metro / stretched cluster — compute at both sites, storage synchronously mirrored 

How does GDP use SMas to protect you in different failure scenarios: 

• Storage cluster failure — IO continues without vSphere HA by using remote copy 
• Storage network failure on local target side of network — IO continues without requiring vSphere HA by using the remote copy 
• Storage network failure on local initiator side of network — A vSphere HA event triggers automatic recovery on the remote site with VM reboot 
• Compute failure — vSphere HA reboots VM on an applicable ESXi host based on resource availability. Affinity and anti-affinity rules may dictate which site the VM is rebooted on 
• Full site outage — VM’s on the failed site are rebooted and recovered by vSphere HA on the surviving site, and I/O is resumed; typical switchover latency ~11 ms (lab/field reference; actual depends on distance, network, and load) 

Non-uniform proximity (uniform_host_config = false) 

Behavior: Peered datastores are mapped only to hosts locally within each site. Site A hosts access Site A SVM LUNs; Site B hosts access Site B SVM LUNs. Replication is still synchronous (SM-as), but with a reduced number of non-disruptive failure scenarios at the VM layer. For this reason, uniform configurations are considered the best practice when the environment can support it. 

Use cases: 

• Campus / dual-room: each room’s hosts only access their local copy 
• Optimizing limited WAN bandwidth: eliminating host network traffic between failure domains 
• Reduced SAN path management: hosts cannot see remote paths 
• Sync DR with site affinity: zero data loss 

How does GDP use SMas to protect you in different failure scenarios: 

• Storage cluster failure — A vSphere HA event triggers automatic recovery on the remote site 
• Storage network failure on target side of network — A vSphere HA event triggers automatic recovery on the remote site 
• Storage network failure on initiator side of network — A vSphere HA event triggers automatic recovery on the remote site 
• Compute failure — vSphere HA reboots VM on applicable ESXi host based on resource availability. Affinity and anti-affinity rules may dictate which site the VM is rebooted on 
• Full site outage — VM’s on the failed site are recovered by vSphere HA on the surviving site, and I/O is resumed; typical switchover latency ~11 ms (lab/field reference; actual depends on distance, network, and load) 

Side-by-side comparison 

End-to-end user flow: from datastore selection to protected active-active 

GDP use cases (where customers win) 

Version and platform guardrails (ONTAP TOOLS 10.6) 

Supported 

Not supported in 10.6 

• NFS and NVMe datastore protection 
• Sync / strict-sync policies outside AFD SM-as scope 
• Local snapshot policies for GDP workflows 
• Protecting datastores across different SVMs in one protection setting 
• Moving a datastore between protection groups (unprotect + re-protect required) 
• Custom async SnapMirror policies 
• MetroCluster-backed configurations 
• ONTAP clusters with > 4 nodes 
• Mixing uniform and non-uniform protection on the same host cluster 
• Protection failover initiated from ONTAP TOOLS UI (use ONTAP System Manager) 
• ONTAP TOOLS discovering CGs / SnapMirror created outside ONTAP TOOLS (CLI/SM) 

Operational guardrails customers should know 

Host proximity and igroups — what ONTAP TOOLS automates 

When you protect a datastore, ONTAP TOOLS 10.6: 

1. Creates or extends an ONTAP consistency group spanning the protected LUNs/volumes 
2. Establishes SnapMirror Active Sync to the peered SVM 
3. Creates nested igroups (parent per datastore, child per host) with host IQNs/WWPNs from participating sites 
4. For uniform AFD: replicates igroups across sites so all hosts retain access 
5. For non-uniform AFD: creates site-local igroups mapped to local fault-domain hosts 
6. Mounts peer datastores and rescans HBAs when topology changes (cluster config modify) 

You do not manually patch igroups for GDP lifecycle operations — ONTAP TOOLS owns add/remove host, mount, unmount, and shrink flows. 

Deeper dive, what happens when a complete site or failure domain goes down? 

Uniform proximity + SM-as 

• Both copies were actively serving I/O 
• SM-as maintains synchronous consistency 
• ESXi hosts at the surviving site continue I/O on the accessible LUN paths 
• Expected: I/O continuity with failover latency typically in the ~11 ms range (not a guaranteed SLA — validate in your environment) 

Non-uniform proximity + SM-as 

• Source-site hosts were actively using local LUNs; target site held the sync replica 
• RPO remains 0 — no committed write loss 
• RTO is non-zero — DR-site hosts (or orchestrated failover) must establish access via igroup/mount/rescan workflows 
• ONTAP TOOLS cluster configuration modify / protection discovery may be needed after topology events 

Quick decision guide 

Summary 

ONTAP SnapMirror active sync provides the synchronous, active-active replication engine. ONTAP TOOLS 10.6 Granular Datastore Protection provides the VMware-native control plane to: 

• Hand-pick which VMFS datastores to protect inside a host cluster 
• Model uniform or non-uniform host proximity via Cluster Configuration 
• Lifecycle-manage consistency groups, SnapMirror, igroups, mounts, and rescans 

Key Takeaways  

Active-active sync SnapMirror: GDP + SM-as delivers zero-RPO, dual-site VMFS protection at datastore granularity. 

Load balancing: SnapMirror active sync enables both sites to actively serve I/O, maximizing resource utilization with best of breed business continuity on failure. 

Google Cloud VMware Engine gives you a familiar vSphere environment in Google Cloud. As VM estates grow, storage often becomes the bottleneck — and the cost driver. Adding ESXi nodes just to get more datastore capacity is rarely the most efficient answer.

With Google Cloud NetApp Volumes Flex Unified, you can provision NFS volumes from a storage pool and mount them as external NFS datastores on VMware Engine. Storage scales independently from compute. You keep ONTAP data services — snapshots, clones, and replication — behind the volume. And the same Flex Unified pool can also serve other file and block workloads when you need them.

This blog walks you through the basics of using Google Cloud NetApp Volumes Flex Unified to provision an NFS volume and mount it as an external NFS datastore on VMware Engine. It works with bothzonalandregionalFlex Unified storage pools.

We'll use a zonal Flex Unified storage pool with the NFS volume mounted to a VMware Engine private cloud. The same approach works with both zonal and regional storage pools.

Prerequisites

Before you begin, make sure you have:

• An active Google Cloud VMware Engine private cloud with at least one cluster.
• A Flex Unified storage pool already created in the same zone or region as that private cloud.

IAM permissions, VPC peering, the NFS service subnet, volume creation, and datastore mount are covered in the steps below.

Important notes before you start

1. Enable delete protection when you create the volume

Flex Unified volumes used as VMware Engine datastores must be created with delete protection enabled. In the Google Cloud console, this appears as below.

If you use the gcloud CLI, enable delete protection at volume creation with --restricted-actions=DELETE. This prevents accidental deletion while the volume is mounted and in use. This setting is permanent, so enable it when you provision the volume.

2. Volume deletion requires a 52-hour wait after unmount

Even after you unmount the NFS datastore from your VMware Engine cluster, the underlying NetApp Volumes NFS volume cannot be deleted immediately. All clients must first disconnect, and then you must wait more than 52 hours before deletion is allowed.

If you try to delete the volume earlier than this, you will see an error like below.

Plan for this waiting period in migration and decommission runbooks. If you need capacity right after unmount, create a new volume rather than expecting the old one to be removable immediately.

Architecture at a glance

Google Cloud VMware Engine runs your vSphere estate in a private cloud. Google Cloud NetApp Volumes hosts the NFS volumes that you mount as external datastores. Those environments are connected by VPC network peering, so ESXi hosts can reach the NFS service over private IP addresses — without sending datastore traffic over the public internet.

In a typical setup:

• Your customer VPC is peered to both VMware Engine and NetApp Volumes (for management and workload connectivity).
• The VMware Engine network is also peered directly to the NetApp Volumes tenant network. This is the path NFS datastore mounts depend on.
• Optionally, cross-region replication can protect NetApp Volumes data for DR.

NFS datastore traffic uses a dedicated service subnet on the private cloud. After peering is active, allow time for route propagation to ESXi hosts before you mount the datastore.

Step-by-step walkthrough

In this blog, we'll walk through the end-to-end process of connecting Google Cloud VMware Engine to an NFS volume from a Google Cloud NetApp Volumes Flex Unified storage pool and presenting it as an NFS datastore to the VMware Engine private cloud cluster. Along the way, you'll configure the required networking, provision the NFS storage, create the datastore, and mount it to your VMware cluster so it can be used for virtual machine workloads.

What we'll cover:

1. Grant IAM permissions to the VMware Engine service agentEnable VMware Engine to access the Google Cloud resources required for datastore integration.
2. Retrieve Google Cloud NetApp Volumes networking detailsGather the service networking information required to establish connectivity between the two services.
3. Create VPC Network PeeringConnect the VMware Engine network to the Google Cloud NetApp Volumes service network, allowing ESXi hosts to reach the NFS datastore.
4. Configure the NFS service subnetSet up the dedicated subnet that carries NFS traffic between your VMware Engine private cloud and Google Cloud NetApp Volumes.
5. Create a Flex Unified NFS volumeProvision the NFS volume that will be used as the datastore and enable delete protection to safeguard against accidental deletion.
6. Identify the target private cloud and clusterLocate the Google Cloud VMware Engine private cloud and cluster where the datastore will be mounted.
7. Create the VMware Engine datastoreRegister the NFS volume as a datastore within Google Cloud VMware Engine.
8. Mount the datastore to the clusterMake the datastore available to all ESXi hosts in the target cluster.
9. Validate the deploymentVerify that the datastore is mounted successfully and ready to host virtual machine workloads.

By the end of this blog, you'll have a Google Cloud NetApp Volumes Flex Unified NFS volume mounted as a datastore in Google Cloud VMware Engine, enabling storage to scale independently from compute resources and providing a flexible foundation for VMware workloads in Google Cloud.

Step 1: Grant IAM permissions

VMware Engine uses a Google-managed service account to access NetApp Volumes and view network peerings. Grant the roles roles/netapp.viewer and roles/compute.networkViewer to service-PROJECT_NUMBER@gcp-sa-vmwareengine.iam.gserviceaccount.com.

Grant the required roles.

Replace PROJECT_NAME and PROJECT_NUMBERwith the value for your environment.

Step 2: Get Google Cloud NetApp Volumes VPC details

To peer VMware Engine with NetApp Volumes, you need the NetApp tenant project ID and tenant VPC network name.

Using the Google Cloud console:

1. Go to VPC networks in the project where NetApp Volumes is deployed.
2. Open the VPC network peered with NetApp Volumes.
3. Open the VPC network peering tab.
4. Select the peering to the NetApp Volumes tenant project (typically named sn-netapp-prod).
5. Copy the Peered project ID and Peered VPC network information. 

You'll need these values in the next step.

Step 3: Create VPC peering between VMware Engine and NetApp Volumes

Before a Google Cloud NetApp Volumes NFS volume can be mounted as a datastore, the Google Cloud VMware Engine private cloud must be able to reach the Google Cloud NetApp Volumes service network.VPC network peeringprovides that connectivity by exchanging routes between the VMware Engine network and the NetApp tenant network, so ESXi hosts can access the NFS export over private IP addresses.

Without this peering, ESXi hosts cannot reach the NetApp Volumes NFS endpoint, and the datastore mount will fail.

Console steps

1. Go to VMware Engine → VPC Network peerings → Create
2. Name: gcve-gcnv-peering
3. VMware Engine network: In current project → select default (or the VEN attached to your private cloud)
4. Peered VPC type: Google Cloud NetApp Volumes
5. Google Cloud NetApp Volumes tenant project ID: the peered project ID from Step 2
6. Route exchange: Enable Import custom routes and Export custom routes
7. Click Create and wait until status is ACTIVE

Verify the peering is active.

Note: The peering connection may become ACTIVE within a few minutes, but route propagation to ESXi hosts can take up to 20 minutes. Wait for propagation to complete before you create and mount the datastore.

Legacy VMware Engine networks: If your private cloud was created before November 12, 2023, you may need a private connection instead of VPC network peering. See Use Google Cloud NetApp Volumes as a vSphere Datastore in VMware Engine for legacy network instructions.

Step 4: Configure the NFS service subnet

NFS datastore traffic between VMware Engine private cloud and Google Cloud NetApp Volumes uses a dedicated service subnet on the private cloud. This subnet must:

• Use a unique CIDR range (at least /26; larger is fine)
• Provide enough IP addresses for each ESXi node in the cluster
• Be used only for NFS datastore traffic (the same subnet can back multiple NFS datastores)

Management and service subnets are created with the private cloud. User-defined service subnets (for example, service-1 through service-5) can be assigned a CIDR when you’re ready to use them for NFS.

Assign a CIDR to the service subnet. In this example, we configure a service subnet named service-1 with 10.20.11.0/24.

Console steps

Go to VMware Engine → Subnets, select your private cloud, and confirm or edit the service subnet you’ll use for NFS.

You’ll use this CIDR in the NFS volume export policy and this subnet name (service-1) when you mount the datastore.

Tip: NSX-T gateway and distributed firewall rules do not apply to service subnets. Keep the CIDR dedicated to NFS datastore traffic and free of overlaps with other networks.

Step 5: Create the Flex Unified NFS volume

Create the NFS volume from your Flex Unified storage pool with delete protection enabled. Include the service subnet CIDR in the export policy:

The export policy must allow:

• The service subnet CIDR (10.20.11.0/24)
• Read/write access
• Root access
• NFSv3 (VMware Engine supports NFSv3 only for external datastores)

Important: The export policy allowed-clients CIDR must match the service subnet you will use at mount time.

Step 6: Identify your private cloud and cluster

Before creating the NFS datastore, identify the ESXi cluster that is part of your VMware Engine private cloud. You will need the cluster name in subsequent steps.

In this example, the cluster name is cluster01. Use this value in the remaining configuration steps.

Step 7: Create the VMware Engine datastore

Create a datastore object that points to your Flex Unified NFS volume. This registers the volume with VMware Engine.

Datastore creation is asynchronous. Verify it is active.

Step 8: Mount the datastore to the cluster

Mount the datastore to your vSphere cluster using the dedicated NFS service subnet from Step 4.

This is what makes the NetApp Volumes NFS volume available to ESXi hosts.

Step 9: Verify the mount

Confirm the datastore is mounted on the cluster and visible to ESXi hosts.

At this point, the NFS datastore should be visible in vCenter under Storage on all ESXi hosts in cluster01.

From vCenter:

1. Open Storage and select gcnvnfsds
2. Go to Configure → Device Backing
3. Confirm:

• Server: matches the NFS IP address of the NetApp volume
• Folder: matches the share name of the NetApp volume

You can now provision VMs to it or migrate workloads with Storage vMotion.

Unmounting and deleting a volume

When you decommission a datastore:

1. Unmount the datastore from the VMware Engine cluster.
2. Confirm no clients remain connected to the NFS volume.
3. Wait for more than 52 hours.
4. Delete the volume if it is no longer needed.

Attempting deletion before the waiting period completes, or while clients are still connected, returns an error.

Why this matters

VMware estates on Google Cloud don’t have to scale storage and compute together. With Flex Unified NFS volumes on Google Cloud NetApp Volumes, you can:

• Add external vSphere datastores without provisioning more ESXi nodes.
• Scale capacity and performance independently for VM workloads.
• Use the same Flex Unified pool for NFS datastores and other file or block workloads.
• Apply ONTAP data services — snapshots, clones, and replication behind your VMware storage.
• Support both zonal and regional storage pool designs.

For supplemental datastores, dev/test environments, tier-2/3 workloads, and storage-heavy VM estates, NFS datastores on VMware Engine are a practical way to bring enterprise NetApp storage to your vSphere environment in Google Cloud.

Get Started

• Ensure you have a Flex Unified storage pool in the same zone or region as your VMware Engine private cloud.
• Follow the steps above — IAM, peering, service subnet, volume, datastore, and mount.
• Review the Google Cloud NetApp Volumes documentation and VMware Engine NFS datastore guide.
• Talk to your NetApp or Google Cloud account team for sizing and architecture guidance.

We can't wait to see how you put Flex Unified NFS datastores to work on Google Cloud VMware Engine.

A validated VDI architecture for scalable, high-performance Citrix workloads

Modern datacenters face many challenges including how to deliver a consistent end-user experience across applications, devices, and locations. Many requirements must be considered and questions arise such as: should every user receive a laptop with high-end graphics capabilities? What about secure applications that require enterprise-grade performance and reliability? Virtual desktop infrastructure can help address these questions and balance cost efficiency, security, and 3D performance to deliver applications that end users rely on with a degree of reliability that simply cannot be accomplished by end user devices.

It’s easy to point out the benefits of VDI, but deployment can be a whole different animal; VDI is often regarded as complicated, expensive and time consuming. If only there were a turnkey, validated design that outlined exactly what to expect with a VDI deployment. Enter FlexPod for Citrix Virtual Apps and Desktops, a Cisco Validated Design (CVD) that covers the groundwork required to quickly and easily unlock a legendary tier of collaborative application delivery.

The cheat code for fast, efficient and scalable virtual desktop infrastructure

The FlexPod for Citrix Virtual Apps and Desktops Deployment Guide covers everything needed to deploy Citrix VDI quickly and consistently. The requirements, best practices, and performance expectations are thoroughly documented to help deliver a consistent experience for thousands of end users. By leveraging Cisco compute, Cisco networking, and NetApp AFF storage, FlexPod engineers have been able to validate up to 2600 virtual desktops in as little as 15 rack units. This guidance is flexible with expansion options for graphically intensive workloads with X-series PCI-e nodes. Scale up, down, out and in based on what your organization needs.

The calm before the storm: Boot and login benchmarks showcase the FlexPod difference

Some of the most common VDI challenges derive from two bottlenecks: startup and logon. Both can cause a “storm,” where resources become exhausted, impacting the end users’ ability to access their virtual desktop. FlexPod has benchmarked and stress tested VDI workloads to help address some of the most common pitfalls of virtual desktops. By using Login VSI and graded by the End-User Experience (EUX) metric, our engineers put FlexPod to the test, simulating both boot and login storms. The combination of high-performance compute, networking, and storage resulted in EUX scores ranging from 7.9 to 8.8 – far exceeding the 6.5 recommended score to help ensure that end users have a seamless experience in the most demanding of environments.

Don’t let the traditional complexities of VDI hold your organization back. With FlexPod for Citrix Virtual Apps and Desktops, you have a proven, stress-tested blueprint to deliver exceptional performance and reliability at scale. Ready to transform your end-user experience? Download the FlexPod Datacenter: Citrix Virtual Apps and Desktops with vSphere 8 Deployment Guide and get started on your virtual desktop journey today!

Explore the Design Guides to kick start your FlexPod deployments

Learn more about Cisco Intersight

we are moving our VMWare VMs to Nutanix, just wonder if we have VM plugin for Nutanix to take VM snapshots such as VMWare Snapcenter plugin?

thank you

we have created second Vcenter, just wonder if we can point the new vCenter to the same snapcenter VMWare plugin server without creating second plugin server.

thank you,

Organizations migrating workloads from data centers or other hyperscalers to Amazon Web Services (AWS) often share a common challenge: How to assess and optimize what the future deployment and its end-state architecture will look like from the earliest stages of the planning cycle. 

Making decisions about your post-migration storage architecture without accurate, workload-specific data can result in a deployment that misses performance expectations or introduces unnecessary long-term costs. What architects and IT teams need first is clarity: A precise view of existing workloads, their storage behavior, and how different AWS storage options compare under real-world conditions.

Now, all of that is possible with the new integration between Amazon FSx for NetApp ONTAP (FSx for ONTAP) and Matilda Cloud, the AI-powered platform designed to automate and accelerate application modernization, and management. In this post we’ll explore this new integration and see how it combines automated, AI-based environment discovery with storage-specific modeling. It’s a data-driven approach to evaluating storage options when moving workloads—in particular VMware virtual machines and databases—to AWS. This combined approach can drive cost savings of as much as 30-40%.

Here’s what we’ll cover:

The need for a realistic pre-migration storage assessment

How Matilda Cloud and FSx for ONTAP make workload migration assessments easier

The benefits of the data-driven storage assessment provided by Matilda Cloud and FSx for ONTAP

Get better insights into your migration to AWS with Matilda Cloud

The need for a realistic pre-migration storage assessment 

The difference between a successful cloud migration and an expensive rework can come down to one critical decision: choosing the right storage architecture. Assessment tooling that thoroughly profiles the existing environment and recommends the best option in AWS is imperative.

During migration assessments, teams are expected to compare enterprise-grade storage capabilities with AWS services while estimating the performance rates and total cost of ownership (TCO). 

Doing this manually can be challenging, because it requires detailed understanding of workload behavior, storage features, and knowledge of the technical details and pricing models of the AWS services involved. The task becomes even more complex when teams must evaluate multiple AWS service options. At worst, migration might result in a non-optimized storage or platform, which would require a second migration with increased risks, complexity, and expenses. 

Obviously, meeting resilience and performance features is imperative, and cost optimization is always a factor that comes into play in the target environment. But migrating workloads such as databases and VMware environments come with further complexity. VMWare environments rely on shared datastores that support mixed workloads with a range of performance requirements. Database workloads usually have requirements around the consistency of input/output operations per second (IOPS) and latency sensitivity.

For example, a data center running VMware clusters and database servers might store years of infrequently accessed data alongside active, performance-intensive datasets. Without the ability to tier data to low-cost capacity pools or other storage efficiency features, teams risk provisioning high-performance storage for all data on AWS, which can drive higher costs over time.

The reality in the trenches is that architects still rely on basic methods such as spreadsheets and generic assessment tools to estimate migration TCO under different configuration scenarios. These methods struggle to account for enterprise storage features and possible additional investments that would need to be made to mitigate the gaps.

One example is customers who migrate their production databases from an on-premises VMWare environment that now has to consider the costs for their disaster recovery solution. An incomplete comparison of the pre-migration state results in both operational impact and long-term cost differences between storage architectures.

How Matilda Cloud and FSx for ONTAP simplify workload migration assessments

Matilda Cloud delivers AI-powered discovery and assessment capabilities designed specifically for VMware and database environments following three key automated steps:

1. Discovery: Matilda’s automated tools discover your current environment (VMware, physical servers, databases) and map application dependencies.
2. Analysis: The platform analyzes your applications and infrastructure, with special focus on configuration metadata, historical performance metrics, and storage consumption patterns across the estate.
3. Modeling: It models the deployment with all AWS storage options, showing side-by-side comparisons and applying intelligent sizing logic to recommend the best fit for purpose service.

The Matilda assessment provides block and file volumes, workload density, IOPS and throughput demand profiles, and insights into how capacity will be consumed and retained over time. The result is a workload-level baseline that reflects how storage is used, rather than how it was originally provisioned.

FSx for ONTAP is an AWS storage service that provides file and block storage within a single AWS service, supporting Network File System (NFS), Server Message Block (SMB), iSCSI, and Amazon S3 compatible access. The service includes enterprise storage capabilities such as NetApp® Snapshot™ technology, lightweight cloning, simultaneous multiprotocol access, and built-in storage efficiency features. These capabilities influence performance design, data placement, and long-term cost outcomes, particularly for VMware and database workloads such as Microsoft SQL Server and Oracle, which depend on consistent latency and predictable I/O behavior.

The integration between Matilda Cloud and FSx for ONTAP extends Matilda’s baseline assessment into a storage-aware modeling phase for AWS. Instead of applying generic sizing ratios, Matilda maps observed workload behavior directly to FSx for ONTAP configuration constructs. 

As part of the assessment, Matilda incorporates FSx for ONTAP capabilities directly into the modeled architecture. Storage efficiency assumptions, data tiering behavior, and workload-specific performance characteristics are evaluated as first-order design inputs. 

This avoids treating enterprise storage features as post-migration optimizations by having to acquire additional third-party or custom-developed solutions to fill those gaps discovered afterwards. Instead, the assessment reflects how they shape capacity planning, performance headroom, and operational workflows from day one using FSx for ONTAP on AWS.

The first AWS Migration Acceleration Program certified tool to work with FSx for ONTAP 

Matilda Cloud is the first AWS Migration Acceleration Program (MAP) certified tool to integrate with FSx for ONTAP. This integration is designed for storage-focused assessments, complementing specialized accelerator programs, such as MAP for VMWare. This certification aligns the assessment with AWS-recommended migration frameworks while extending them with storage-specific intelligence that is often missing from traditional migration analysis.

The output of the integration is a detailed assessment report that presents a direct comparison between all AWS storage services, including FSx for ONTAP. The report includes modeled cost estimates, configuration assumptions, and qualitative comparisons of storage capabilities, providing a clear, defensible foundation for architectural decision-making.

The benefits of the data-driven storage assessment provided by Matilda Cloud and FSx for ONTAP

By grounding architectural choices in workload-level data and storage-aware modeling, the assessment provided by Matilda Cloud and FSx for ONTAP leads to clearer insights around cost, performance, and operational efficiency.

• Trust in migration strategy and architectural choices

The Matilda Cloud assessment supports organizations as they evaluate performance and resilience requirements. Users can commit to migration or architecture decisions with certainty before deploying any new infrastructure on AWS. This approach leads to more decisive actions by removing uncertainty during the planning phase and shortening the decision cycles for migration projects.

• Clear visibility into cost and efficiency

The comparative reports provide quantifiable insight into cost drivers across different storage options and decrease the risk of additional storage migration projects after the transition to cloud. In anonymized customer assessments conducted using Matilda Cloud, FSx for ONTAP configurations have shown cost advantages of more than 30% compared to alternative AWS storage options depending on workload characteristics and data access patterns.

The following Matilda assessment provides a cost comparison between using FSx for ONTAP and Amazon Elastic Block Store (Amazon EBS). The blended architecture Matilda evaluates here uses Amazon EBS for root system volumes and FSx for ONTAP for data volumes across both primary and capacity storage tiers.

• Evaluate your enterprise storage features upfront

The assessment highlights the operational value of enterprise storage capabilities through the all-important lens of cost savings. Features such as cloning, data tiering, and multiprotocol access are evaluated during the planning stage, rather than leaving your team to discover them after migration and having to pay to fix them later. 

This forward-thinking assessment style helps teams understand the practical impact of advanced storage functionality before deployment. In the screenshot below, a Matilda Cloud assessment has identified $7.4M in annual storage waste across eight inefficiency patterns, along with $2.8M in potential recoverable savings by using FSx for ONTAP in one quarter: 

The insights from this assessment highlight several common infrastructure challenges that often remain hidden during manual migration planning. These include Snapshot sprawl, over-provisioned IOPS, volumes with low change rates, and the overhead of maintaining custom-developed solutions like self-managed NFS servers and backup tools. By addressing these factors, the Matilda assessment identifies a potential 38% in cost savings and a return on investment (ROI) in under 3 months.

Get better insights into your migration to AWS with Matilda Cloud

Successful migrations from data centers or other hyperscalers to AWS depend on making the right storage decisions early. The integration between Matilda Cloud and FSx for ONTAP introduces an objective, assessment-driven approach that helps organizations compare storage options with clarity and confidence. 

By combining automated discovery with storage-aware modeling, teams gain the insight needed to streamline migration planning and align architecture with real workload requirements.

Learn more about the Matilda and NetApp integration in our joint webinar, or contact Matilda Cloud to check AWS-funded assessment options for your VMWare workloads.

VMware teams are facing growing pressure to modernize infrastructure and reduce costs while maintaining fast, reliable, and secure operations. 

To meet these demands strategically and at scale, Amazon Elastic VMware Service (Amazon EVS) can be the next step for these teams, offering scalability and access to a wide range of other AWS services.

Amazon FSx for NetApp ONTAP (FSx for ONTAP) is an AWS-certified external storage option that provides even more benefits from Amazon EVS. To help access the cost and performance benefits of using FSx for ONTAP for Amazon EVS, NetApp® Workload Factory now provides the Amazon EVS migration advisor wizard. This guided planning tool transforms VMware workload migration to Amazon EVS with FSx for ONTAP, creating optimized, data-driven designs that align with AWS Well-Architected Framework recommendations as well as VMware and NetApp best practices.

This article is part of a Workload Factory migration advisor series. Part 1 explored manual mode, where the user defines their configuration parameters. In this post, we’ll show you how to use the migration advisor inventory upload mode to automatically build a migration plan that supports faster, more cost-aware VMware workload migration to Amazon EVS with FSx for ONTAP, using your current VMware inventory and performance data. 

Read on as we cover:

How the inventory upload mode works

How to build your migration plan with the inventory upload mode

Prerequisites

Step 1. Upload your VM inventory

Step 2. Specify planning parameters

Step 3. Select storage workload placement

Step 4. Design the datastore layout

Step 5. Review your migration plan

Step 6. (Optional) Provision your migration plan

Ready to build your Amazon EVS migration plan?

How the inventory upload mode works

As VMware environments expand to support consolidated enterprise compute estates, manual resource cataloging becomes increasingly time-consuming and error-prone, making large-scale migration planning difficult. Inventory upload mode in the Workload Factory Amazon EVS migration advisor eases that bottleneck by automatically parsing VMware inventory data and pre-filling migration advisor parameters, producing a complete, best-practice migration plan in minutes.

At the center of this capability is the VMware Planning Center, the management hub for all migration data in Workload Factory. From this screen, VMware architects can upload datasets, track their analysis status, launch migration advisor sessions for each environment, and deploy resources to their Amazon Virtual Public Clouds (Amazon VPCs) based on the migration plans they create.

VMware environment data can be collected using three methods, each designed to provide a different level of detail and insight:

1. RVTools: A free Windows-based utility that can export VMware environment configuration data directly from vCenter. It captures VM names, CPU and memory allocation, storage usage, and datastore mappings, but does not collect runtime performance metrics.

Best for quick assessments where performance data isn’t required.

2. Data Collector: A PowerShell or PowerCLI-based script developed by NetApp. It gathers the environment configuration and collects runtime performance data (IOPS, throughput, latency, etc.) on a user-defined schedule. The data runtime collection captures workload peaks and uses them later to improve planning accuracy.

Best for performance-aware migration planning and well-architected right-sizing.

3. NetApp Data Infrastructure Insights (DII): A Software-as-a-service (SaaS)-based observability platform from NetApp that continuously collects performance metrics across storage, compute, and networking.

Workload Factory connects directly to DII tenant accounts to automatically import environment configuration and runtime performance data. This is similar to Data Collector but without any scripts or manual exports.

Best for continuous, tenant-level analysis at enterprise scale.

Once your VMware inventory and performance data are uploaded, Workload Factory automatically analyzes the information, applies your selected planning parameters, and generates an optimized migration plan for your entire VMware estate. The result is quick, data-driven decision-making and consistent alignment with AWS and VMware best practices, whether you are migrating a handful of workloads or thousands of virtual machines (VMs).

To learn more about how DII supports visibility and clarity in complex environments, read From Unmapped Chaos to Cloud-Ready Clarity: How DII Makes Workload Visibility Simple.

How to build your migration plan with the inventory upload mode

The inventory upload mode workflow in the Workload Factory Amazon EVS migration advisor transforms VMware migration planning into an automated process that produces well-architected results. This section shows how to set up your migration plan using upload mode, step by step.

Note: Inventory upload mode supports migrations from on-premises VMware environments and from VMware Cloud on AWS (VMC) sources.

Prerequisites

Before you begin, make sure you have:

• A source VMware environment.
  
• A Workload Factory account with VMware planning access.
  
• (Optional) AWS account view permissions, if you plan to deploy directly using CloudFormation.
• (Optional) VMware vSphere credentials, if you plan to mount datastores to an Amazon EVS cluster during provisioning.

Step 1. Upload your VM inventory

From your Workload Factory home, open the menu options (three-line icon) in the upper-left corner, and then select the VMware workload.

This will take you to the VMware planning center, where all inventory data and migration projects are managed.

In the VMware planning center, select Upload VM inventory, then follow the dialog prompts to add your dataset using your preferred data source: RVTools, Data Collector, or Data Infrastructure Insights. You assign the dataset a name of your choice, then upload it as a ZIP file containing the VMware inventory information extracted with your selected tool.

In the image below, you can see a collected dataset being imported into the Planning Center with the Data Collector option (note the Codebox on the right displays a PowerShell template that can be used to carry out this same process programmatically):

Select Done when you are finished, and the dataset will appear in your Planning Center dashboard. When its status changes to Available, it’s ready for analysis.

Step 2. Specify planning parameters

Next to your uploaded dataset, select Start planning, then choose AWS Elastic VMware Service from the drop-down menu as your target environment. This opens the Amazon EVS migration advisor wizard.

The migration advisor wizard starts by offering a summary view in the VM configuration upload section that shows VM count, provisioned capacity, and utilized capacity.

From here, you can define your planning parameters, which guide how Workload Factory models your environment:

1. Under VM Inventory Considerations, select your AWS Region.

2. Under Target capacity and protection considerations, specify:

• Datastore capacity: Define the total capacity for your deployment in TiB. (An automatically calculated, optimized capacity recommendation will be available in a future release.)
• Capacity source: Choose whether to base sizing on provisioned or utilized storage.
• Data reduction ratio: Adjust to reflect your environment’s data efficiency profile. 
• Headroom percentage: Set between 5% and 25% to allow for growth and Snapshot copies.
• VM Snapshot protection: Enable to include default Snapshot policies in capacity estimates.

Note that this preparatory step mirrors manual mode, but is faster and data-driven.

Learn more about the Amazon EVS migration advisor manual mode in this post.

We recommend keeping the default values, which are pre-populated using NetApp best practices for your storage type.

If unsure about the data reduction ratio, you can also get contextual recommendations by selecting Help me decide. Below you can see the Help me decide analysis for the data reduction ratio qualifier:

Once parameters are set, select Next to proceed.

Step 3. Select storage workload placement

Workload Factory applies your planning inputs to the uploaded data and automatically performs optimization calculations. Specifically, the migration advisor evaluates performance and cost trade-offs between internal vSAN and external FSx for ONTAP datastores. 

You can prioritize either cost optimization or recoverability: As you toggle between the two, the recommended deployment options will automatically update.

Here you can see the review screen for workload placement between vSAN and FSx for ONTAP external storage:

In the VMs inventory list, you can review each VM’s proposed target, allowing you to fine-tune workload placement between vSAN and FSx for ONTAP. You can also manually adjust selections in the VM list to refine which workloads move to FSx for ONTAP.

When your selection is finalized, select Next to proceed.

Step 4. Design the datastore layout

After storage placement, Workload Factory analyzes VM performance data to propose a datastore layout that optimizes for throughput and capacity utilization. The system balances workloads based on IOPS, latency, and other performance patterns, applying FSx for ONTAP best practices for volume sizing, Snapshot policy, and provisioning.

Here you can see the review screen for the automatically generated datastore layout:

This stage also includes recommendations for Snapshot buffers and ONTAP efficiency settings, which are necessary to maintain a well-architected configuration. Select Next to continue.

Step 5. Review your migration plan

On the Review plan page, Workload Factory provides a comprehensive summary of your proposed migration design before deployment.

Here you can review the generated migration plan:

This screen includes several sections designed to simplify validation:

• FSx for ONTAP storage capacity analysis displays logical and physical capacity, including VM data, Snapshot buffer, and growth headroom.

• The FSx for ONTAP configuration and cost breakdown summarizes the recommended configuration, including file system count, deployment details, capacity, and estimated monthly cost.

• Datastore layout and VM allocation show how VMs are distributed across datastores, along with projected IOPS, throughput, and capacity allocations.

• Solution design assumptions outline the optimization parameters, architectural assumptions, and sizing guidelines applied in the generated design.

You can export the plan as a PDF or CSV, and share it with relevant stakeholders to review before committing changes in AWS. The plan is also saved automatically for later review and provisioning. 

Step 6. (Optional) Provision your migration plan

When you are ready to deploy, you will be redirected to the AWS console, where the template will be ready to use. 

Choose your preferred creation mode:

• Quick create uses your selected Region, and applies NetApp and AWS best-practice defaults for Amazon VPC, security group, and Snapshot policy.
  
  
• Advanced create offers full customization, including network configuration, mount permissions, and security group rules.

Here you can see the provisioning workflow for the FSx for ONTAP configuration using Quick create mode.

In both cases, follow the on-screen prompts to complete the required deployment fields. The pre-populated fields follow the created migration plan, or NetApp and AWS best practices for VMware (for example, setting NFS.MaxQueueDepth=128 for ESXi host settings).

Your Amazon EVS cluster details are automatically populated from your environment, including vCenter address and administrator credentials for seamless integration.

During provisioning, you can optionally mount the newly created FSx for ONTAP datastores directly to your Amazon EVS cluster. When enabled, Workload Factory automatically configures ESXi settings, connects to your vSphere environment, and mounts the datastores.

Note: You need to reboot the ESXi host for the new NFS.MaxQueueDepth value to take effect.

Once your configuration is complete, you can download the auto-generated Infrastructure-as-Code templates for use in CloudFormation.

Ready to build your Amazon EVS migration plan?

With the inventory upload mode, Workload Factory simplifies VMware-to-Amazon EVS migration planning by creating a data-driven, optimized design based directly on your VMware inventory and performance data.

Whether you are planning a few workloads or migrating thousands of virtual machines, Workload Factory helps you build well-architected, cost-efficient, and performance-balanced plans with FSx for ONTAP as external storage.

To explore how Workload Factory streamlines VMware modernization on AWS, visit the NetApp Workload Factory website or sign in to start planning your VMware migration today.

Hi, this is a new installation of ONTAP tools for VMware vSphere 10.5.

When we click on the OTV plugin within vCenter, buttons are all greyed out - hovering over displays "Insufficient privilege"

Per the following NetApp KB, we've verified that both forward and reverse DNS is functioning normally: https://kb.netapp.com/data-mgmt/OTV/VSC_Kbs/Insufficient_privilege_in_OTV_10_x_options

We've also already added the OTV service account as a member to the global AD Security group: "vSphere8 vCenter Admins" and assigned that same AD Security Group to the vCenter "Administrator" role and it doesn't work.

We also attempted an OTV installation using the vsphere.local admin account and that too also didn't work.

We've attempted the installation and setup on 2 separate/different lab (test/dev/non-prod) environment vCenter's and seeing the same behavior across them both.

Any ideas?

Amazon Elastic VMware Service (Amazon EVS) is the recently launched AWS service that helps users to operate VMware workloads natively on AWS. And by using Amazon FSx for NetApp ONTAP (FSx for ONTAP) as an external datastore, you can decouple the VMware workload storage from compute. This opens the door to cost optimization strategies that aren’t possible in vSAN-only VMware deployments.

To evaluate the cost impact of using FSx for ONTAP with Amazon EVS, NetApp® Workload Factory now offers an Amazon EVS total cost of ownership (TCO) calculator. With it, you can compare two storage approaches for Amazon EVS—scaling with vSAN or extending capacity with FSx for ONTAP—so you can see the cost and savings estimates for your deployment.

In this post, you’ll discover how FSx for ONTAP reduces Amazon EVS costs and how to use the TCO calculator.

• The hyperconverged cost challenge: Buying more compute just to scale up storage
• How FSx for ONTAP reduces TCO on Amazon EVS
• Estimate your deployment costs and potential savings with the Workload Factory VMware TCO calculator
• How to Use the Workload Factory VMware TCO calculator
• Get started with FSx for ONTAP and Amazon EVS

The hyperconverged cost challenge: Buying more compute just to scale up storage

Amazon EVS brings your VMware deployment to AWS with no refactoring and no retraining, making VMware relocation fast, secure, and much more cost-effective. 

Out of the box, Amazon EVS uses vSAN storage virtualization technology to pool storage in a single vSAN datastore across Elastic Sky X Integrated (ESXi) hosts. That means your total storage capacity is determined by the number of compute hosts running. If you outgrow your storage footprint, you can’t just add new disks—you also have to add more compute. That means more vCPUs and memory, whether you need them or not, and that’s a major cost concern.

Consider this: To support 180 TiB of usable storage with vSAN alone, you might need to provision three additional ESXi hosts. Those three extra hosts could add more than $25,000 in monthly compute costs, even if the workloads don’t require that extra compute power.

The outcome? Oversized clusters, inflated costs, and underutilized resources—especially for storage-intensive workloads.

How FSx for ONTAP reduces TCO on Amazon EVS

FSx for ONTAP is an AWS-native, fully managed storage service that delivers the same trusted NetApp ONTAP® data management capabilities many enterprises use on premises. 

As an external datastore for Amazon EVS, it extends enterprise-grade NetApp storage capabilities to VMware on AWS, providing flexibility and efficiency beyond what vSAN-only designs offer.

Here’s how FSx for ONTAP lowers TCO in Amazon EVS:

• Decoupled storage and compute

In an Amazon EVS deployment, FSx for ONTAP acts as a separate, remote, shared storage server. The Amazon EVS ESXi compute nodes can access FSx for ONTAP as an external, network-attached datastore. And since FSx for ONTAP is independent storage, it can scale up on demand without adding compute. Learn how FSx for ONTAP decouples storage from compute and reduces TCO.

• Storage efficiency features and data tiering

FSx for ONTAP delivers enterprise-class storage efficiency for Amazon EVS workloads through built-in thin-provisioning, data compression, deduplication, and compaction. To further optimize costs, the data tiering feature automatically tiers infrequently used data to low-cost storage until the data needs access again. 

• Data mobility

Replicating VMware data involves complex, time-intensive processes. FSx for ONTAP simplifies this with NetApp SnapMirror®, which transfers only incremental changes after the initial data sync. The result is faster, less costly data mobility with reduced downtime and development expenses. This is relevant for use cases such as data migration, hybrid environment management, and syncing disaster recovery copies.

• License cost savings

 Using FSx for ONTAP as external storage reduces the number of compute hosts in use, enabling customers to need fewer core-based licenses.

Together, these capabilities deliver significant cost optimization, with TCO up to 50% lower than vSAN-only scaling.

For more on the benefits of using FSx for ONTAP with Amazon EVS, read Using Amazon EVS with FSx for ONTAP to optimize costs and performance. Next, we’ll look at the VMware workload TCO calculator in Workload Factory, which will show the details of the cost comparison.

Estimate your deployment costs and potential savings with the Workload Factory VMware TCO calculator

Workload Factory is a free service that helps you model, assess, and optimize your cloud infrastructure strategies that use FSx for ONTAP to meet specific workload requirements and align with NetApp and AWS well-architected storage framework best practices.

A key feature is the VMware TCO calculator, built specifically for evaluating storage choices in Amazon EVS. This tool goes beyond cost estimates and cost comparisons: It acts as a decision-making aid for anyone considering relocating VMware to Amazon EVS. 

With it, you can compare the cost impact of running Amazon EVS with vSAN only versus extending storage with FSx for ONTAP. Instead of relying on spreadsheets or assumptions, the calculator delivers clear insights that support confident decision-making:

• Infrastructure architects can compare Amazon EVS with other VMware cloud options to see the potential costs and savings of their designs.
• IT managers can justify Amazon EVS proposals with verifiable numbers.
• Cloud planners can identify cost-saving opportunities driven by inefficiencies (such as overprovisioning) and observe the effects of applying best practices.

Use it before migration, during rightsizing and cluster balancing, or as an ongoing checkpoint for audits and strategy reviews.

How to Use the Workload Factory VMware TCO calculator

With the Workload Factory VMware TCO calculator, you can model Amazon EVS cluster requirements, compare scaling with vSAN versus FSx for ONTAP, and export a detailed report with savings projections. Clear visuals and documented assumptions highlight exactly where the savings were made. Let's walk through how to use the calculator.

Step 1: Open the calculator in Workload Factory

From the Workload Factory home page, go to the VMware workload card and select Explore savings.

This opens the Amazon EVS TCO calculator view.

Step 2: Define your VMWare workload requirements

The first step is to describe your environment. 

As an example, let’s say we want our high-availability pair of i4i.metal instances to include 160 TiB of storage. But, this compute configuration for Amazon EVS comes with up to 60 TB of local AWS Nitro SSD storage only. That gap forces you to either add extra compute with vSAN or extend capacity with FSx for ONTAP.

In the TCO calculator, we can use the sliders in the left panel to specify the required physical CPU count, physical memory in GiB, and VM storage in TiB. Additionally, you can change your Amazon EVS billing plan from on-demand to 1-year or 3-year reservations if acquired for your deployment. 

By default, the calculator assumes standard ONTAP storage efficiencies (single-AZ deployment, SSD storage only, first-generation filesystem type, scale-up model), shared tenancy pricing, and deployment in the us-east-1 region.

Step 3: Review your cost comparison output

Once the requirements are set, the right-hand panel comes alive. It shows side-by-side costs for two scenarios: Scaling Amazon EVS with vSAN or with FSx for ONTAP.

In this case, FSx for ONTAP delivers 49% monthly savings—about $42,938 compared with vSAN-only scaling—on-demand.

Scrolling down, the calculator also provides a detailed breakdown of FSx for ONTAP external storage specifications and TCO estimates—including host counts, storage efficiency savings, and estimated monthly costs. These details help you understand not only how much you can save, but also where the savings come from. 

Please note that VMware Cloud Foundation licensing costs are not included. The additional cost savings FSx for ONTAP provides by requiring fewer core-based licenses are also not shown in the calculator. 

Step 4: Export the final report

You can adjust the inputs multiple times to reflect your workload mix—for example, a storage-heavy VDI deployment or a compute-balanced production cluster. Every change updates the savings model instantly.

When you are ready, you can print the report for your team from your browser or select Contact an expert by email for tailored guidance.

Workload Factory also guides you to the next step: Plan EVS Migration, which helps execute your design with automation and best practices.

You can learn more about how to use the migration advisor from Expedite VMware workload relocations with Workload Factory Migration Advisor.

Get started with FSx for ONTAP and Amazon EVS

The VMware TCO calculator is more than a cost estimator; it’s a way to bring transparency to your Amazon EVS planning. By modeling storage and compute separately, you see exactly how FSx for ONTAP transforms VMware economics on Amazon EVS. No surprises, no hidden assumptions: just clear numbers you can use to guide decisions.

Whether you’re exploring Amazon EVS for the first time or looking to optimize an existing cluster, the calculator gives you the insight to act with confidence. And with the Workload Factory migration advisor, you can go beyond modeling: design your migration, generate infrastructure-as-code, and move forward with a well-architected deployment.

Watch this video on how to estimate your cost savings on Amazon EVS with FSx for ONTAP and Workload Factory, or get started with the cost calculator today.

Introduction:

In last week's blog, we were excited to announce the latest version of NetApp ONTAP tools for VMware vSphere. The 10.5 update is designed to simplify and secure your VMware Cloud Foundation storage operations. This release includes several new customer-requested features that enhance security, resilience, automation, and manageability for modern enterprise environments.

In this second installment in our three-part series, we will take a look at what’s new in data protection with the return of NetApp MetroCluster support, expanded support for VMware Live Site Recovery (vLSR, formerly Site Recovery Manager, or SRM), and interoperability with the SnapCenter Plugin for VMware (SCV) using complex hierarchical consistency groups for distributed applications.

If you missed the other posts, you can find them here:

ONTAP Tools for VMware 10.5 (Part 1 of 3): Hardening Your VMware Private Cloud - NetApp Community
ONTAP Tools for VMware 10.5 (Part 3 of 3): Supporting Your VMware Private Cloud - NetApp Community

New Data Protection Features in This Release

1. MetroCluster Support

Business continuity just got easier. With MetroCluster support, you can now leverage synchronous replication for mission-critical workloads, both SAN and NAS, ensuring high availability and business continuity across sites or other failure domains.

• Storage Backend Onboarding:
  • Both source and destination clusters must be onboarded for provisioning to work after a MetroCluster switchover event. This can be done either globally in the ONTAP tools Manager UI (the example below), or locally within the vCenter remote plugin UI.
    
    
    
    
• UI Enhancements:
  • MetroCluster configuration and peer details are shown in storage backend views.
    
    
    
• Switchover/Switchback Handling:
  
  • Storage discovery must be triggered post-switch to maintain provisioning workflows. This will allow ONTAP tools to understand which SVM context is currently controlling the storage.
    
    
    
• API Updates:
  
  • APIs now return MetroCluster configuration details for clusters and storage backends.

2.    SRM/SRA with Hierarchical Consistency Groups (CG)

• The integration of VMware Live Site Recovery Manager (VLSRM, or just SRM) and Storage Replication Adapter (SRA) now supports hierarchical consistency groups. This means you can orchestrate complex recovery scenarios with backup functionality, fully interoperable with SnapCenter (SC) and SnapCenter Plug-in for VMware vSphere (SCV).
• Upgrades require a new SRA adapter with updated certificate handling. The updated adapter can be found on the ONTAP tools 10.5 download page(login required), along with the ONTAP tools OVA and upgrade ISOs.

3.    VMFS Replication with Hierarchical CG

SC and SCV backups are interoperable, giving you granular control and flexibility for virtual machine storage.

• Hierarchical CGs can be created by SC or SCV.
• Snapshots from SMas (SnapMirror active sync), SC, and SCV workflows are listed separately in ONTAP and can also be recovered by NetApp Disaster Recovery.

Conclusion:

The latest NetApp ONTAP tools for VMware vSphere deliver robust enhancements for business continuity, disaster recovery, and data protection. With new features like MetroCluster support, hierarchical consistency groups, and expanded interoperability with SnapCenter, IT teams can now achieve greater security, resilience, and automation for their VMware private cloud environments. These advancements empower organizations to confidently protect mission-critical workloads and streamline storage operations.

Ready to get started?

You can download ONTAP tools here: https://mysupport.netapp.com/site/products/all/details/otv10/downloads-tab

And if you are new to ONTAP tools, be sure to check out my installation cheat sheet here: https://docs.netapp.com/us-en/ontap-apps-dbs/vmware/vmware-vvols-checklist.html

Introduction:

We’re excited to announce the latest release of NetApp ONTAP tools for VMware vSphere, designed to simplify and secure storage operations for VMware vSphere and Cloud Foundation. This update brings new features that enhance security, resilience, automation, and manageability for modern enterprise environments.

In this first blog, we will unpack what’s new in security with strict certificate validation and enhancements to ONTAP tools’ own certificates.

Update: You can find the other posts here:

ONTAP Tools for VMware 10.5 (Part 2 of 3): Protecting your VMware vSphere and VCF Deployments - NetApp Community
ONTAP Tools for VMware 10.5 (Part 3 of 3): Supporting Your VMware Private Cloud - NetApp Community

New Certificate Features in This Release

1. Certificate Validation for ONTAP and vCenter

With both state and non-state actors attempting to gain access to your vital data every single day, security is more important than ever. This new release introduces robust certificate validation for both ONTAP and vCenter, ensuring every TLS handshake from ONTAP tools (sometimes referred to as OTV, not to be confused with Overlay Transport Virtualization) is authenticated and encrypted. This enhancement helps safeguard your data and virtual infrastructure from unauthorized access.

Now, before we get started, I have to give a fair warning here. The default self-signed certificates in ONTAP won’t be good enough. You can generate some higher-security self-signed certs using ONTAP's CLI if you want, or leverage your enterprise CA and use CA-signed certs like we should all be doing anyway.

So, before we take a deeper dive into certificate validation, I wanted to address the elephant in the room. If you maintain a sandbox lab, a home lab using simulators, or other reduced security environments, there is a process where you CAN disable certificate validation. So, no, you don’t really need to set up a certificate authority and/or reissue all of your certificates if you are comfortable with a reduced security posture. Also, note that if you are upgrading from a previous release, and the upgrade detects that you have ONTAP systems with invalid certificates, it will give you the option to either disable certificate validation right away or immediately cancel the upgrade.

To disable certificate validation, simply complete these steps:

1. Log into the maintenance console as the “maint” user and select application configuration, option 1.
   
2. Select “Change Cert Validation Flag”
   
3. Note if you are changing from false (disabled) to true (enabled), and enter y or n as appropriate. In this example, I am re-enabling it.
   
4. Wait for the services to restart. This may take quite a while. Time to grab a nice cup of coffee or make some tea.

2. Manager UI & RPUI Enhancements:

1. Users can add or modify certificates for ONTAP storage backends and vCenter servers via UI or manual upload. Simply select the “Modify storage backend” option from the ONTAP tools “Storage backends” menu.
   
2. The UI now shows certificate expiry warnings and allows certificate replacement.
   
3. Certificate statuses (expired/expiring soon) are visible in the Storage backends listing views in both the ONTAP tools Manager UI and the vCenter UI.
   

3.    API Changes:

1. New and updated APIs support certificate onboarding, validation, truststore updates, and secure TLS handshakes.
2. Certificates are stored securely and tracked in the ONTAP tools database itself instead of being handled separately.

4.    Platform Requirement:

1. Onboarding storage backends requires that the ONTAP server certificate contain valid Common Name (CN) and Subject Alternative Name (SAN) entries. I recommend that your SAN be the IP address that reverse-resolves via ONTAP tool's DNS server to the FQDN common name. As I mentioned previously, if you try to upgrade to version 10.5 and have onboarded systems with self-signed certificates lacking SAN entries, you will be presented with an option during the upgrade to either disable certificate validation or cancel the upgrade.
2. Remember, certificate validation can be toggled via the maintenance console as shown above. Note that the maintenance console is not accessible via SSH. Only the vSphere console.

5.    Extended Certificate Expiry

1. To reduce maintenance overhead, certificates for both the ONTAP tools UI/API Gateway and Storage Replication Adapter (SRA) services now have a 1-year (previously 10 years) expiry
2. Auto-renewal mechanisms are in place to prevent workflow disruptions,  simplifying lifecycle management and compliance.

Conclusion:

ONTAP Tools for VMware 10.5 brings stronger certificate validation, easier management, and streamlined certificate lifecycles with auto-renewal—making your VMware private cloud more secure and easier to maintain.

Ready to get started?

You can download ONTAP tools here: https://mysupport.netapp.com/site/products/all/details/otv10/downloads-tab

And if you are new to ONTAP tools 10, be sure to check out my installation cheat sheet here: https://docs.netapp.com/us-en/ontap-apps-dbs/vmware/vmware-vvols-checklist.html

VMware and the software-defined data center (SDDC) have helped a generation of businesses grow and expand through virtualization. But now, VMware users face a major challenge in growing legacy systems beyond the data center. AWS recently launched Amazon Elastic VMware Service (Amazon EVS) to help meet this need and support the path to modernization. 

Amazon EVS extends the virtualization layer seamlessly between on-premises data centers and Amazon Web Services (AWS), giving VMware administrators a way to relocate and scale their environments without having to replatform or rewrite applications.

This post will explore how the NetApp® Workload Factory Amazon EVS migration advisor simplifies transitions from on-premises VMware deployments to Amazon EVS using Amazon FSx for NetApp ONTAP (FSx for ONTAP) as external storage, guiding you step by step to create a well-architected storage configuration.

Here’s what we’ll cover:

• The need for more streamlined VMware migrations
• Workload Factory expedites the VMware workload relocation process to Amazon EVS
• Planning VMware workload relocations to Amazon EVS with the migration advisor
• Amazon EVS environment requirements
• Review the migration plan
• Provisioning FSx for ONTAP and Amazon EVS datastores
• Workload Factory is empowering seamless VMware workload relocations to Amazon EVS

The need for more streamlined VMware migrations

Migrating VMware workloads requires careful navigation. Organizations typically encounter several key considerations:

• Planning: Planning is a critical piece of your migration. This includes a full assessment of your existing infrastructure and understanding which workloads to run in the cloud.
• Identifying the right target: Another consideration is finding the most suitable target environment. That means evaluating multiple options in order to find the solution that will keep any migration in line with your business goals.
• Costs: Cost optimization represents a significant opportunity during cloud migrations. By leveraging rightsizing and strategic resource allocation, migrations can turn into a strategic financial optimization initiative.
• Time: Many organizations are under significant pressure to rapidly migrate their VMware environments, which can create challenges when applications require extensive refactoring or rebuilding. By embracing fast paths to AWS, teams can accelerate their cloud transition timelines, reduce operational overhead, and quickly unlock the agility and scalability of cloud environments without extensive application refactoring.

One way that customers can solve these challenges is by using Amazon EVS with FSx for ONTAP as external storage. Let’s see how Workload Factory is streamlining that solution.

Workload Factory expedites the VMware workload relocation process to Amazon EVS 

Workload Factory is a specialized service that streamlines provisioning and optimizing FSx for ONTAP by combining design recommendations and best practices from AWS, VMware, and NetApp ONTAP®. This helps you optimize your environment and maintain well-architected operation throughout its lifecycle.

For organizations moving VMware workloads to AWS, the new Workload Factory migration advisor for Amazon EVS capability offers crucial support during the assessment and planning phases of your migration. 

The migration advisor serves as a central hub for designing the optimal FSx for ONTAP storage infrastructure configuration for your VMware workload when relocating to Amazon EVS. With the migration advisor, you provide the specifications you need from an external datastore, and the advisor aligns those details with FSx for ONTAP configuration guidelines, well-architected best practices, and guardrails. This helps provide the right FSx for ONTAP configuration from day one, keeping your VM relocation tasks streamlined and well executed.

Planning VMware workload relocations to Amazon EVS with the migration advisor

This section will provide a walkthrough of the Amazon EVS migration advisor process for relocating a VMware workload to an Amazon EVS environment using an NFS-based FSx for ONTAP file system as external storage.

Note that you can either have a pre-existing Amazon EVS deployment or you can configure one through this process. This walkthrough shows the process for setting up the migration before Amazon EVS is deployed. This will show how to create the datastores and apply all required ONTAP settings, which you can connect to Amazon EVS later.

To start the migration advisor review process, select the Workload Factory home page and find the VMware workload widget. 

Workload Factory will offer two modes to choose from:

• Manual mode: With manual mode, you enter the capacity and performance requirements, and Workload Factory creates the plan.
• Upload inventory mode: In this mode, Workload Factory helps you discover and upload your existing VMware configuration, which Workload Factory uses to create the plan.

In this post, we’ll walk through the manual mode option. The inventory upload mode walkthrough will be published in a follow-up post.

In the Workload Factory homepage, scroll to the VMware widget, and choose Plan and Create. This will open the manual mode deployment configurations screen.

Amazon EVS environment requirements

In the next window, you will specify your Amazon EVS environment requirements.

Region: Select the AWS Region where you plan to deploy your Amazon EVS environment. 

Note: FSx for ONTAP configuration options can vary between AWS Regions. When you select a Region here, Workload Factory automatically aligns the FSx for ONTAP configuration with the options available for that Region.

VM capacity: Enter values between 1 TB and 160 TB. The VM capacity value provided should be the total logical capacity occupied by the VMs that will be migrated to AWS. Workload Factory will use this value to calculate the required storage capacity for FSx for ONTAP.

Required IOPS: Select the necessary input/output operations per second (IOPS) for your Amazon EVS datastores. Be aware that FSx for ONTAP IO rates are also influenced by configured filesystem SSD capacity and throughput, which might need to be increased accordingly. Note, this value can be adjusted later.

Required throughput in Mbps: This will configure the throughput for your Amazon EVS datastores. If you need to achieve a high IO rate, set a high throughput value here, since your FSx for ONTAP file system type determines the baseline suggested IO rate. Note, this value can also be adjusted later.

Datastores count: The migration advisor automatically calculates the number of datastores you require. You also have the option to override this suggested number.

Workload Factory will recommend a datastore count that reflects the number of volumes required to achieve optimal performance based on the specific FSx for ONTAP configuration. If you manually set a lower value, Workload Factory will alert you to this fact.

Average data reduction ratio: Select the desired data reduction capacity ratio. This metric indicates how effectively data can be reduced in size through FSx for ONTAP storage efficiency features, such as data compression, deduplication, compaction, and thin provisioning. 

The value that Workload Factory offers here by default is a best practice conservative estimate that can be retained in most cases. If you want to explore further and see if this number fits your needs, choose Help me decide for a recommended value based on your use case data characteristics that impact storage efficiency mechanisms.

The Help me decide button provides guidance on the appropriate ratio to choose based on your VM estate, such as whether your VM storage capacity is used by databases or media, or if the data is encrypted or compressed.

Headroom percentage: This capacity supports VM growth and serves as an interim buffer for default snapshot protection. Select a headroom percentage between 5% and 25%. The recommended value is 20%. 

You can also enable VM snapshot protection. This setting will follow the default Snapshot policy, as described.

After all the values are selected, choose Review plan.

Review the migration plan

On the next page, you will review the FSx for ONTAP external datastore plan. You can also export the plan to PDF. 

Suggested FSx for ONTAP configuration

First, you will be presented with a suggested FSx for ONTAP configuration that matches the input you gave about your VMware workload requirements.

This suggested configuration includes information such as required logical capacity, physical capacity, snapshot buffer, and headroom. You can also see the suggested configuration summary, including the estimated monthly cost.

You can export the plan in PDF by choosing Export plan (PDF) in the upper-right corner.

FSx for ONTAP configuration and cost analysis

Scrolling down to the next section, you can see the FSx for ONTAP configuration based on the provided details. It also provides an analysis of the estimated costs that will accrue based on the throughput capacity, IOPS, and backups.

Volume configuration

Scrolling down again, you’ll find the details of the datastores. This configuration is determined based on the user specifications provided in the first step. Workload Factory recommends a datastore count sufficient to achieve optimal performance, and then divide the required capacity—the VM capacity + headroom capacity + the Snapshot buffer capacity + automatic growth and tiering estimations—equally between datastores. 

Configuration design assumptions

In this section, you are provided with the reasoning behind the solution design. These assumptions include VMware best practices, capacity-related assumptions, FSx for ONTAP design considerations, and assumptions used as the basis for cost estimations.

Choose Provision to begin the set-up process

Provisioning FSx for ONTAP and Amazon EVS datastores

You will be brought to the page for creating and configuring FSx for ONTAP file system and datastore volumes for your Amazon EVS environment. 

First, you’ll see two options for creating the file system: Quick create and Advanced create. Both options will automatically build the file system based on the sizing properties in the migration plan. However, in Quick create, specific file system and network attributes will be automatically determined, while in Advanced create, you will be asked to specify these values.

Note: In both cases, there is some additional information that you’ll need to provide, such as your AWS credentials, Amazon Virtual Private Cloud (Amazon VPC), Availability Zone preference, and your ONTAP credentials. However, it’s strongly recommended to follow all the best practices for deploying Amazon EVS datastores, as detailed by Workload Factory in the Network & Security section for Region & VPC, and AZ subnet.

In the Summary segment, you can see the Default configurations listed with their details.

There are two important areas to note when using the Advanced create option. In the Network & security section, where you set specific parameters for your system: 

• In the NFS Datastores access option, you can automatically configure an FSx for ONTAP export policy that limits datastore mounting to the Amazon EVS host VLAN. This helps make the deployment more secure. Learn more in the host management VLAN subnet documentation.

For the Security group configuration, you can automatically provision a new security group that will limit inbound traffic only to ports that are mandatory for the external datastore use case and for basic management. Setting this value yourself helps to reduce the possibility of an insider attack on the environment.

Scrolling down to Plan configuration in the Summary section, you can see the settings configured by the migration advisor for the Amazon EVS environment. This includes configurations aligned with best practices for Snapshot policies, storage efficiencies, and tiering policies.

If all this checks out, choose Create at the bottom of the screen to deploy the FSx for ONTAP file system.

On the right-hand side, you’ll see the Codebox. Here, you can find an AWS CloudFormation template that you can use to automate the FSx for ONTAP for Amazon EVS external storage creation. You can either download the template, copy it, or redirect it to CloudFormation in AWS to automate the deployment. 

Workload Factory is empowering seamless VMware workload relocations to Amazon EVS 

NetApp Workload Factory and its VMware migration advisor are powerful tools that can help speed your VMware migrations to AWS. This free tool, which you can start using right away, simplifies and optimizes your move from on-premises VMware to Amazon EVS with FSx for ONTAP as external storage. 

Workload Factory speeds up VMware relocations to Amazon EVS by building in well-architected best practices and creating infrastructure-as-code snippets, all while cutting down the time, effort, and costs of setting up and running an AWS environment. 

Ready to simplify your relocation to AWS so everything runs smoothly from day one? Learn more about Workload Factory or get started now

@hi All

We upgraded vCenter to 8. I was running SC plugin 4.7, so went for new install of SC 6.1. SC plugin 6.1 comes without vmware tools. I can't install vmware tools. Throwing errors. Any help would be appreciated.

Thanks

We have SCV 4.x with latest ONTAP version (9.12 onwards) which works fine. It has vault backups. when we tried to restore a VM using vault backup it fails with error, "Unable to mount datastore failed to create lun clone:no input ESX initiator lds".

In the secondary cluster, fcp service is up and has its wwpns zoned correctly with ESXi hosts at source. Also, the secondary SVM is added in storage systems section of SVC plugin.

Is there anything we are missing here?

Thank you!

For organizations adapting to changes in virtualization licensing while optimizing total cost of ownership (TCO), OpenShift Virtualization combined with NetApp ONTAP offers a powerful, future-ready solution. This presents a compelling alternative option for virtualization. Built on KubeVirt, an open-source technology, it enables seamless management of virtual machines (VMs) alongside containers within a unified Kubernetes environment. This integration allows IT teams to consolidate workloads on a single platform, streamlining operations and accelerating cloud-native transformation. NetApp ONTAP stands out as the most versatile data platform for virtualization, on-premises or in the cloud. It supports all major hypervisors in on-premises environment and offers native data services across leading public clouds. ONTAP’s integration empowers organizations to:

• Seamlessly adapt to licensing changes
• Choose the optimal deployment model for each workload
• Maintain consistent data management across hybrid and multi-cloud environments

This flexibility positions ONTAP as a strategic enabler for organizations navigating the evolving virtualization landscape.

What is OpenShift virtualization

Key Capabilities

• KVM-based VMs run in containers, managed as Pods
• Fully scheduled, deployed, and managed by Kubernetes
• Intuitive VM lifecycle management via the OpenShift web console
• Integrated with Kubernetes-native persistent storage and orchestration

Storage & Data Protection with NetApp Trident

• Trident CSI: Dynamic storage provisioning over NFS, FC, iSCSI, NVMe/TCP
• Granular VM-level operations: snapshots, clones, volume expansion

Trident Protect:

• Crash-consistent VM backups to S3-compatible storage
• Disaster recovery with replication, failover, and failback

Beyond the powerful storage features like snapshots, clones, and efficiency, NetApp ONTAP plays a key role in streamlining VM migration to OpenShift Virtualization. Depending on the number of VM disks and their size, the available migration options will take some time. This is where ONTAP along with cloning capability via Shift toolkit make the migration seamless. Call it the virtual machine migration offloader to storage.

Why Shift toolkit

Shift toolkit combines high-fidelity format conversion with native storage cloning and efficiency to convert a VMDK to RAW and handles it at scale & speed. The metadata only nature of FlexClone means the conversion can be done in seconds to minutes (for example, 2 TB in seconds). This allows customers to run VM conversions with minimal storage overhead and near-zero downtime. To emphasize the point, there is no data copy in here, meaning the conversion happens instantly. This saves time and compute resources. This makes ONTAP a strategic enabler for large-scale migrations involving tens of thousands of VMs, delivering efficiency without disruption.

While VMKFStools cloning with copy offload is a supported method, it still requires data movement across volumes, even though the process is offloaded to the storage layer. In contrast, the Shift Toolkit significantly outperforms XCOPY offload. It acts as a VM migration offloader that eliminates the need for actual data copying. The Shift Toolkit API enables intra-volume copies, where both the source and destination reside within the same volume. By leveraging NetApp’s proprietary deduplication technology, the destination file typically occupies only a few kilobytes for metadata, allowing clone operations to complete almost instantly.

Importantly, this approach avoids reliance on deprecated protocols within the VMware ecosystem. Instead, it uses supported, traditional datastores to enable fast and seamless VM migration.

This blog covers how the NetApp Shift Toolkit brings the same seamless migration experience to Red Hat OpenShift Virtualization as it does for hypervisors like Hyper-V and provides a step-by-step guide on transitioning to OpenShift Virtualization using Shift Toolkit’s conversion APIs. Looking ahead, future releases of the toolkit will offer enhanced capabilities and deeper integration to further streamline the migration journey.

Prerequisites

• OpenShift cluster with OpenShift Virtualization operator and NetApp Trident CSI driver installed.
• Shift toolkit v2.2 installed
  • No additional configuration required. Since only Shift toolkit API is used in this case, there is no need to configure Shift toolkit resource groups or blueprint.

• Administrator level privileges on the OpenShift cluster
• A Linux instance (this can be an existing management instance as well) with tridentctl and OC command line tool installed.
• kubeconfig exported or OC login shd be executed to connect to the cluster.
• Download the script named - Shift VM to OpenShift from Shift toolkit script block and copy the zip file to this Linux instance.
• Unzip the zip using unzip <filename> (unzip 'shift-vm-to-openshift.zip')
• Ensure Python3 is installed (dnf install python3)
• Install openjdk 8 or later version (yum install java-1.8.0-openjdk)
• Run pip install -r requirements.txt (need internet)

VM requirements:

• Ensure the VMDKs for a VM are placed on individual volumes. For instance, consider a VM with 3 disks. Each of the disk should be placed on its individual volume (mapping datastore to PVC construct). This needs to be done manually using storage vmotion.
• The script runs against RHEL 8 and 9, SLES 12 and Windows 2019/2022

Note: The script doesn’t assign Network now. This needs to be manually assigned. Will be covered in a later update.

PrepareVM requirements (for injecting Virtio drivers):

• PrepareVM script is embedded in the zip file. Use powershell to execute the script from the Shift toolkit VM.
• Ensure vmware.powercli module is installed (install-module VMware.PowerCLI -scope AllUsers -force -SkipPublisherCheck -AllowClobber)
• For Windows VM, mount the virtio iso to the VM. The virtio driver can be downloaded from here.

Preparing the VM

Shift toolkit runs the VirtIO driver, qemu-agent installation and fstab update script. To accomplish the same, Shift toolkit uses powercli to connect to the guest VMs (Linux or windows) and updates the VirtIO drivers ensuring the necessary drivers are available once the VM boots up on OpenShift side.

The script for Linux and Windows can be found in the zip extract. The syntax to use is as follows:

.\prepare-vm.ps1 -vCenter "IP or FQDN" -vCenterUser "administrator@domain.com" -vCenterPass "password" -vmName "vm name" -guestUser "user" -guestPass "password" -osFlavor "linux" -localWindowsScriptPath "prepare-vm-win.ps1" -localLinuxScriptPath "prepare-vm-linux.sh"

Note: The script remains the same for Linux or windows distro, just need to ensure the right parameters are passed.

Discovering VMs from vCenter and volumes on ONTAP storage

In order to start the process, update the json file with the following details:

• ONTAP Cluster
  • This can be a SVM, its management IP and vsadmin credentials
  • Splitclone parameter can be set to “False” if the clone volume doesn’t need to be detached.
• vCenter
  • Min RBAC rights to access the vCenter to discover the VMs and associated VMDK files.
• Shift toolkit
  • The Shift toolkit VM IP and the credentials to access the same. If using the default credentials, it will be admin/admin
• Trident storage class
  • Should be NFS backend and ensure the right version is updated
• OpenShift
  • Specify the project name (default is used as an example)

Note: Keep the rest of the values as default

High level workflow:

Once the pre-reqs are met, simply execute python3 main.py which will do the orchestration.

Below sections cover what steps are triggered by Shift toolkit APIs to convert the VMDK ad create a VM on the OpenShift side.

Convert VMDK

Once the json file is updated, the script will automatically find the VMDKs associated with each VM including the primary boot disk. The conversion happens in seconds compared to other approaches.

Note: if there are multiple VMDK files, each VMDK will be converted.

Upload the RAW image to OpenShift Virtualization Cluster

With the virtual machine disk image converted to RAW format, script uploads the RAW file to OpenShift cluster and import them individually using trident.

Create Virtual Machine

Script generates a “YAML” for each VM depending on the OS.

Booting VM for the first time

Depending on the Virtual Machine OS, Shift toolkit will auto assign the VM boot option, along with the storage controller interface. In case of Linux distros, VirtIO is used. And for Windows, Shift toolkit starts with SATA interface and then auto installs VirtIO drivers and then changes the interface to VirtIO by modifying the YAML.

Note: Once the VM boots up, ensure to assign the network manually for this iteration.

All the above is covered by running python3 main.py

Fast, Simple VM Migration with ONTAP and Shift Toolkit

In this blog demo, a RHEL VM with 3 fully populated disks totalling 1.5 TB was migrated to OpenShift Virtualization in under 5 minutes. The VMDK to RAW conversion completed in seconds - thanks to ONTAP and Shift Toolkit.

This showcases a streamlined, low-impact approach to rehoming VMs using ONTAP storage. And if you're using block protocols, storage class migration is your go-to solution. This is just the beginning, stay tuned for deeper protocol level integration ahead.

Planning a Move to OpenShift Virtualization? Shift Toolkit Has You Covered.

If you are planning to migrate to OpenShift virtualization or already in the process, give Shift toolkit script a try. It’s completely free. Reach out to your NetApp team to register your interest and explore upcoming integrations that streamline operations.

We are currently running OnTAP Tools 9.11. I see that I can upgrade to 9.13 easily enough, but 10.0 seems to be a different animal altogether. The link belong talks about migrating from 9.x to 10, but I can't find information on upgrading. Does a separate OVA need to be deployed to 'upgrade' to 10? If so I can't find that documented anywhere. The article below talks about being able to migrate from 9.11 "D4", but not from 9.12 or 9.13. If I upgrade to 9.13, will I be able to migrate to 10? Can anyone provide clarity? Thanks in advance.

https://docs.netapp.com/us-en/ontap-tools-vmware-vsphere-10/migrate/migrate_to_ng.html

I'm studying ONTAP tools and would like to better understand your perspective on the tool. I think the value it adds to administration is fantastic. But I'm also concerned about the risks if an attacker gains access to vCenter and can also directly damage the storage, such as deleting datastores, Snapmirrors, etc.

1) Is this risk worth the tradeoff for management agility?

2)How do you significantly reduce these risks? 

3) Does it work well with Multi-Admin Approvals?

I'm trying to upgrade the self signed certificate of ONTAP Tools for vSphere version 10.4 to one signed by our internal MS CA.
When doing so, I receive the error The payload for POST request is invalid.
I already found KB: Unable to upgrade from certificate to CA in ONTAP Tools for VMware vSphere v10.3 - NetApp Knowledge Base

This however does not help.

Many of you have seen VMware's announcement today regarding the general availability of VMware Cloud Foundation (VCF) 9.0. VCF 9.0 delivers many powerful new capabilities as well as changes to existing supported technologies. Among other things, one change you will see is that “starting with VCF 9.0 and vSphere Foundation 9.0, the vSphere Virtual Volumes capability, also known as vVols, is deprecated and will be removed in a future release of VCF and vSphere Foundation. Support for vSphere Virtual Volumes will continue for critical bug fixes only for versions of vSphere 8.x, VCF and vSphere Foundation 5.x, and other supported versions until end-of-support for the respective release.”

Note: vSphere 8.0 reaches end of service on October 11, 2027.

You can read more in the VCF 9.0 Release Notes: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/release-notes/vmware-cloud-foundation-90-release-notes/platform-product-support-notes/product-support-notes-vsphere.html

How the NetApp advantage helps you transition your existing vVols storage architecture into an intelligent data infrastructure.

Why it matters: Traditionally, the top three reasons that vSphere administrators deployed vVols were:

1. Granular quality of service, especially in SAN environments. With traditional VMFS file systems, the storage array has no visibility of the individual VMDK inside the datastore. Therefore, without vVols, the only way to provide storage-native VM or VMDK granular data services was with vVols.
2. Simplicity at scale. Again, this is mostly seen as an advantage in SAN environments, where, traditionally, vSphere administrators were required to manage many different VMFS file systems to meet the needs of the business. With vVols, admins simply consumed the allocated capacity from the array, instead of being limited to a specific VMFS datastore for any given VM.
3. Snapshot offload. VMware strongly recommends that administrators limit the use of traditional vCenter managed snapshots. This is because each snapshot incurs unnecessary IO amplification throughout its life, reducing performance and becoming a single point of failure for the VM. With vVols, since each VMDK is a unique entity on the storage array, you can use the array's native snapshot or cloning technology to create thin snapshots that do not incur any performance penalty.

The NetApp Advantage: What do you do if you require all or some of these storage capabilities? There are many options, and it can appear daunting to sift through them all. The following are just a few of the options available, and in many cases you will want to leverage more than one solution.

1. Even without vVols, ONTAP tools for VMware provides a simplified, vCenter-integrated, intuitive user interface with easy wizard-driven workflows to automate the provisioning and complete lifecycle management of both VMFS and NFS traditional datastores. The embedded dashboards, reports, and UI extensions enable seamless monitoring of your environment without ever leaving your day-to-day working environment or learning how to be a storage admin.
2. Even with traditional VMFS or NFS datastores, SnapCenter and BlueXP Backup and Recovery Service, included for free with the ONTAP One license for ONTAP-to-ONTAP backups, integrate ONTAP native snapshots directly into the vCenter UI. With SnapCenter and BlueXP, vCenter administrators can easily and intuitively leverage ONTAP snapshots, which have no performance penalty or IO amplification, for individual VM or VMDK recovery. There is even a feature to clone and mount a VMDK to recover specific files.
3. Customers can take ownership of their data and directly connect to it from the guest OS using in-guest software iSCSI or NVMe/TCP initiators or NAS protocols.
   1. By taking ownership of your data in this way, you future-proof your investment and gain complete flexibility to re-platform to any hypervisor, anywhere, even to a cloud instance where they could connect to their data in FSx, Google Cloud NetApp Volumes (GCNV) or Cloud Volumes ONTAP (CVO) by using SnapMirror.
   2. By directly connecting to application data using NAS protocols, ONTAP will have a first-person view of the data. You gain the advantage of being able to leverage the entire Intelligent Data Infrastructure with technologies like Data Classification, autonomous ransomware protection with AI, fpolicy, vscan, QoS, quota management, direct access to recover individual files from the snapshots directory, etc.
   3. Likewise, using guest-connected block protocols, you unlock the ability to use SnapCenter or BlueXP Backup and Recovery Service regardless of the underlying hypervisor. You also gain the ability to restore or clone individual VM disks from a snapshot for test/dev, VDI, etc, without having to first clone and mount the entire datastore.
   4. Using the NetApp PowerShell Toolkit, you can transform your existing VMDKs from NFS datastores into LUNs and thus, into NVMe namespaces (if required) using the same underlying technologies as the NetApp Shift Toolkit for zero-copy migrations. This, again, brings back VM-disk granular quality of service and VM-disk granular access options. A vVol LUN or namespace could even be converted back into a VMDK for NFS access.
4. NetApp Trident, when used with KubeVirt-based hypervisors like Red Hat OpenShift Virtualization, can deliver equivalent functionality to vVols. Using CSI storage in this way can even be seen as superior to vVols because it does not require an out-of-band VASA Provider.
5. For customers who prioritize the simplicity at scale that vVols offers,  consider NFS-based datastores. Traditional FlexVol volumes can provide up to 300TB per datastore, and FlexGroup volumes can provide up to 60PB, with 400 billion files on a 10-node cluster for a single datastore.
   1. While non-vVols NFS datastores are not able to fully maximize granular QoS due to the nature of the ESXi NFS client, you can nevertheless use QoS to mitigate the blast radius of a noisy neighbor VM to just the host where the VM is running.
   2. Direct access to the .snapshot directory makes copying and recovering VMDKs as simple as dragging and dropping them.
   3. Managing access to NFS at scale is generally seen as the easiest way to use storage when block protocols like NVMe/TCP are not required.
   4. While ONTAP itself cannot see inside of a VMDK, ARP/AI can protect individual VMDKs in a datastore by understanding the entropy of the data itself, just as it can protect guest files using guest direct NAS access.
   5. Modern NFS features like nconnect and session trunking boost NFS performance to new levels.

The NetApp advantage isn’t just in how you use a single array or integrate with off-box software. It’s the entire intelligent data infrastructure because ONTAP isn’t just an array. It’s an intelligent data management platform that allows you to leverage your data any way you want, anywhere you want. Be it in the on-prem core, at the edge, or in the public cloud.

EDIT 25.08.21: Added references to ONTAP tools for VMware.

The landscape for VMware users continues to evolve. Many organizations are seeking options to understand what is next for their VMware workloads. They are asking for flexibility and choice with the goal of delivering better VMware service at a lower cost.

A common challenge has been the tight coupling of the VMware infrastructure, where storage and compute are required to scale together, which increases costs due to overprovisioning. Other challenges include the complexity and burden of refactoring applications as part of migration to the cloud. Now, there is a solution: Amazon Elastic VMware Service (Amazon EVS). With Amazon EVS, customers have a way to run VMware Cloud Foundation (VCF) directly within an Amazon Virtual Private Cloud (Amazon VPC). This presents a fast and secure way to migrate and modernize VMware workloads to AWS, so they can gain all the performance and resilience benefits possible, without undergoing costly and time consuming application  replatforming or refactoring projects.

In addition, to simplify and accelerate migrations, reduce costs, and maintain operational consistency, Amazon EVS can use Amazon FSx for NetApp ONTAP (FSx for ONTAP) as its external datastore. FSx for ONTAP is a fully managed AWS storage service that delivers the features of NetApp® ONTAP®. By using FSx for ONTAP as the external datastore for Amazon EVS, VMware users now have a path to scale compute and storage independently, all while gaining a wide range of enterprise-grade storage capabilities. With FSx for ONTAP and Amazon EVS, customers can streamline and enhance their VMware workloads on AWS with powerful features that reduce costs, improve data protection, and simplify the extension and migration of workloads to AWS.

In this blog we will discuss: the benefits and challenges of VMware migration, why using FSx for ONTAP as Amazon EVS external storage solves common challenges, the key benefits of using FSx for ONTAP with Amazon EVS, and how to build a high-performance and cost-optimized VMware architecture on AWS.

VMware migration benefits and challenges

For more than 400,000 organizations, VMware's software-defined data center (SDDC) architecture has been the backbone of enterprise IT on-premises. To take advantage of the cloud, many organizations choose to migrate and operate VMware workloads on AWS for the following benefits:

• Scale and performance: VMware on AWS delivers the independent scaling of compute and storage as business needs change and more resources are required at peak periods of operation.
• Enhanced disaster recovery (DR): The AWS Cloud can be used as a disaster recovery target for the on-premises VMware SDDC.
• Cloud economics: Facilitate “cloud-first” strategies and execute the decommissioning aging infrastructure.
• Application modernization: Unlock modern application development by creating new environments that work seamlessly with both on-premises and AWS datastores.

As customers look to move their VMware workloads to the cloud, they need to consider the following challenges:

• High TCO: The hyperconverged infrastructure traditionally used by VMware couples compute and storage, making it costly to operate and scale.
• Inefficient data protection: Traditional VMware backup and DR solutions can be slow, costly, and complex, often requiring multiple copies of data.
• Complex data migration: Moving large VMware workloads without causing disruptions to existing operations can be difficult.
• Inconsistent hybrid cloud operations: Keeping workflows consistent and minimizing disruptions across on-premises and cloud environments requires careful planning.

To address these challenges and offer a more seamless migration experience, AWS has introduced Amazon EVS. Amazon EVS has been designed to speed up your ability to deploy virtualized applications and benefit from the scalability, resilience, and performance of the AWS Cloud while keeping familiar VMware tools and existing skills. You get full control over the entire VMware architecture and a virtualization stack that’s optimized to serve all of your workload needs, even when working with third-party tools.

Why Amazon EVS?

Amazon EVS is intended for workloads that have complex dependencies. There are workloads that IT teams don’t want to disturb. However, when faced with a data center exit, or the long-term strategy of moving to the cloud, these workloads can become an issue. Amazon EVS allows you to migrate to the cloud without re-platforming or refactoring applications and still get the scalability, resilience, and performance benefits of AWS. There are other migration strategies for migrating VMware workloads to AWS, but these require re-platforming.

• Re-platforming your VMware-based VMs to Amazon Elastic Compute Cloud (Amazon EC2). This option requires refactoring, which can include infrastructure and licensing changes, and may introduce protection, compliance, and compatibility challenges.
• Re-platforming your applications for containerization with Amazon Elastic Kubernetes Service (Amazon EKS). This option offers better scalability, but requires application redesign.

Amazon EVS provides a faster way for your VCF workloads to gain the benefits of AWS, and doesn’t require refactoring or replatforming your applications. Plus, Amazon EVS gives you the ability to run other applications within your Amazon VPC in addition to VCF. It’s easy to operate Amazon EVS using either the AWS Management Console or the AWS Command Line Interface (AWS CLI). As an AWS-native service, Amazon EVS extends your VMware workloads’ access to over 200 AWS services, opening up the possibilities for working with services such as  analytics, containerization, serverless, managed databases, generative AI, and much more. Amazon EVS delivers:

• Flexibility: Customers can bring their own VCF licenses to AWS and take advantage of different consumption options, including on-demand, 1-year, and 3-year plans. Customers can also take advantage of Amazon EC2 Savings Plans.
• A consistent VMware experience: Amazon EVS extends your familiar VMware environment to AWS, minimizing the learning curve for your teams.
• Enhanced control: With Amazon EVS, admins can use several management and security tools, including Network Virtualization and Security Platform (NSX), Elastic Sky X Integrated (ESXi), SDDC manager, and vCenter. This gives customers full control over configuring the entire virtualization stack even while working on AWS.

Amazon EVS delivers even more benefits when using FSx for ONTAP. As a fully managed ONTAP storage service on AWS, FSx for ONTAP provides a range of enterprise-grade benefits, including elastic storage decoupled from compute, that can increase your flexibility and reduce costs. The following diagram shows a high-level overview of what an on-premises VMware vCenter and Amazon EVS architecture looks like, providing full compatibility and operational consistency while gaining access to many AWS services and solutions.

By using FSx for ONTAP with Amazon EVS, organizations get powerful new capabilities that directly address the main migration and operation challenges.

Connectivity options available for using FSx for ONTAP with Amazon EVS

When attaching FSx for ONTAP to Amazon EVS as its external storage, users can choose from three primary connectivity options:

• NFS datastore

FSx for ONTAP provides highly scalable, high-performance, file storage for your VMware workloads, enabling you to separate storage scaling from compute requirements. This option is ideal for organizations with data-intensive applications that need to independently scale storage capacity and performance while simplifying VMware workload manageability and recoverability. 

• iSCSI datastore

For workloads requiring block storage, FSx for ONTAP delivers Internet Small Computer Systems Interface (iSCSI) LUNs that deliver enterprise-grade performance and data management capabilities. This option provides the low-latency, high-throughput, storage needed for mission-critical, block-based applications. In the following diagram you can see the combined Amazon EVS and FSx for ONTAP architecture for the NFS/iSCSI datastore use case.

• Guest-attached NFS/SMB storage

Virtual machines can directly mount FSx for ONTAP volumes, supporting multiprotocol access for both Network File System (NFS) and Server Message Block (SMB) files, giving you flexibility for different application requirements. Using this option is highly beneficial in situations where data needs to be accessed by multiple hosts and heterogeneous operating systems. In the following diagram you can see architecture for the guest-attached NFS/SMB storage use case.

FSx for ONTAP manages storage lifecycle tasks such as security updates, upgrades, and patching, while Amazon EVS handles the virtualization environment lifecycle. You retain control over network connectivity and storage configuration, which provides more flexibility to administrators. For more details on which clients and protocols are supported by FSx for ONTAP, please refer to the Supported FSx for ONTAP Clients documentation.

Key FSx for ONTAP benefits for Amazon EVS customers

Cost optimization

In addition to storage scaling independent of compute, FSx for ONTAP offers storage efficiencies, including data deduplication, compression, compaction, tiering cold data to a lower-cost capacity pool, and thin provisioning volumes as needed. This means that you won’t be locked into operating on a certain scale. Your storage can grow with your needs, without ballooning costs. The following diagram shows how FSx for ONTAP allows you to scale up storage without adding cluster nodes to the Amazon EVS virtualization environment.

Through the FSx for ONTAP storage efficiency capabilities, your organization can achieve TCO savings that can reach 50% of the overall service cost—outperforming what you can expect to achieve with VMware vSAN technology, especially for storage-heavy workloads. 

Data protection and high availability capabilities

FSx for ONTAP includes various capabilities that enable highly available and well-protected VMware deployments:

• FSx for ONTAP is highly available with the choice of using multiple Availability Zones (AZs) or single AZs. Each FSx for ONTAP file system is deployed in an active-passive configuration. If one node fails, the other takes up operation automatically, increasing availability and maintaining your business continuity. Using the multi-AZ option adds even more resilience, as your workloads can maintain continuity even if an entire AZ is unavailable.
  
• NetApp Snapshot™ technology creates instant, thin, crash-consistent, point-in-time data copies for use in backup, recovery, and archiving.
  
• NetApp SnapMirror® replication technology replicates your VMware data, including application-consistent Snapshot copies. This is a major component of BlueXP™ disaster recovery as a service (DRaaS), which offers a simple, efficient, and cost-effective way to protect and recover your VMware workloads. BlueXP DRaaS provides seamless replication via SnapMirror, enabling fast failover as well as non-disruptive failover testing that enhances recovery readiness without affecting production. 
  
• Enhanced backup via NetApp SnapMirror, which replicates your NetApp Snapshot data to a low-cost backup repository. This is superior to traditional VMware software-based replication methods as there is virtually no performance impact and minimal storage overhead. 
• NetApp SnapLock® creates tamper-proof, write once, read many (WORM) data copies that offer indelible data protection.

Data migration and hybrid cloud management

With FSx for ONTAP, VMware customers can maintain consistent data management practices in AWS and on premises.

For users coming from on-premises ONTAP, FSx for ONTAP offers:

• Seamless and scalable bulk data migration with native ONTAP capabilities such as SnapMirror. 
• Familiar ONTAP workflows—no need to retrain teams or change processes.
• Interoperability with AWS services for enhanced storage, analytics, and compute capabilities.
• A seamless experience across the hybrid on-premises and AWS environments.

In a hybrid cloud environment, FSx for ONTAP gives you the benefits of operational consistency at the storage level as well as the same architecture, same capabilities, and a simple migration step.

Multiprotocol support for guest-attached storage

FSx for ONTAP simplifies multi-protocol data access by supporting both NFS and SMB in a single solution. This is critical for applications requiring shared access across Windows and Linux environments.

VMware integration

FSx for ONTAP offers tight integration with the VMware technology, supporting vStorage APIs for Array Integration (VAAI) for both iSCSI and NFS datastores. VAAI integration offloads day-to-day VMware management operation to FSx for ONTAP, providing:

• Lightning-fast virtual machine (VM) cloning and migration with reduced overhead.
• Optimized vSphere Cluster and VM management operations, such as storage reclamation and datastore volume locking.
• Offloads VM snapshot and backup operations to ONTAP technologies, which results in less performance impact on the virtualization environment.

Next steps: Build a better VMware strategy on AWS

The combination of Amazon EVS and Amazon FSx for ONTAP empowers organizations to migrate, operate, and optimize VMware workloads in AWS with greater flexibility, lower costs, and improved data protection.

By using Amazon EVS with FSx for ONTAP, you can build a smarter, more efficient cloud strategy for your

VMware workloads—one that’s cost-effective, scalable, and secure.

hello:

  After adding the whitelist of the esxi firewall on vcenter, we can no longer perform cloning. Here is the error message. Is there any solution

thank you

Are you looking to migrate VMs across hypervisors. Have you ever wondered how to offload the conversion process to storage for quicker results? Let's examine migrating 5 VMs, each with two 1TB disks in addition to the OS disk, totalling 10TB of data disks plus the OS disk.

Impressive, isn't it? This blog introduces the NetApp Shift toolkit, which can be utilized to simplify and accelerate VM migrations across hypervisors. Let's explore together how the Shift toolkit achieves this.

What’s the problem statement

Given VMware's recent licensing changes, organizations are revisiting their virtualization strategies to improve cost efficiency, scalability, and reduce business risks. This includes optimizing the existing VM estate and adopting either a multi-hypervisor or hybrid cloud approach.

Be it any scenario, ONTAP is the ideal platform for any hypervisor platform. ONTAP supports all the prominent hypervisors in on-premises environments and has first-party data services in each major cloud, supporting VMware cloud offerings and cloud native workloads. This enables organizations to navigate the licensing changes easily by choosing the appropriate deployment model for their workloads.

While optimization activities are ongoing, every organization is evaluating a multi-hypervisor approach so as to reuse their existing hardware investment, which supports a multi-vendor hypervisor strategy, thus strengthening operational flexibility, mitigating vendor dependency, and optimizing workload placement. By combining multiple hypervisors, organizations can tailor infrastructure to meet diverse workload demands while managing costs. Organizations then streamline multi-hypervisor management by leveraging interoperability, cost-effective licensing, and automation.

A critical requirement in this approach is the swift and seamless mobility of virtual machines, guided by SLAs and workload placement strategies. Migrating from one hypervisor to another involves a complex decision-making process for businesses. Key considerations include application dependencies, migration timeline, workload criticality, and the impact of application downtime on the business. However, with ONTAP storage and Shift toolkit, this is a breeze.

How about wicked fast (100x faster) conversions to any hypervisor of your choice using clones, call it VM migration offloader. Below is an example of conversion from VMware to Hyper-V.

Introducing NetApp Shift Toolkit (a simple VM mobility platform)

The NetApp Shift toolkit is an easy-to-use, graphical user interface (GUI) solution that allows to migrate virtual machines (VMs) between different hypervisors and convert virtual disk formats. The whole process utilizes NetApp Snapshots® and FlexClone® technology to quickly convert VM hard disks. Additionally, the toolkit manages the creation and configuration of destination VMs. Does not require additional storage or data center resources.

For detailed information, see my Shift toolkit guide

What are the key benefits:

• Beneficial for organizations looking to optimize VM licensing costs and extend IT budgets.
• Provides flexibility in a multi-hypervisor environment by supporting bidirectional conversion hypervisors.
• Helps minimize long downtime and enhances business productivity.
• Offers choice and flexibility by reducing licensing costs, lock-in, and commitments to a single vendor.
• Reduces virtualization costs with data portability.
• Is offered free from NetApp.
• Provides fully scriptable REST APIs that can be leveraged by automation workflows.

Note: The pre-requisite for Shift toolkit is to have VMs running on NFS volume residing on ONTAP storage. This means if the VMs are hosted on block based ONTAP storage or on third party storage arrays, then VMs should be moved using Storage vMotion to the designated ONTAP based NFS datastores. Guess what, the VMs will remain online during svmotion, ensuring minimal downtime for migrations when moving to target hypervisor.

Shift toolkit can be downloaded here and is available for Windows Systems only.

For detailed installation steps, refer to Installing and setting up Shift toolkit

How Shift toolkit works:

The high-level steps performed are as follows:

• Connects to VMware and Hyper-V to collect host and VM resource metadata
• Allows selection of VMs and Shift toolkit injects the required scripts
  • Script to remove VMware tools and retain the IP settings irrespective of the OS type
  • VMware tools removal performed at the target

           Note: No modifications are made to the source VM, allowing it to be rolled back    exactly as it was

           Note: Once prepared, VMs should be powered off based on the maintenance window

• Deletes existing snapshots for all VMs in the blueprint
• Triggers VM snapshots for Blueprint – at source
• Trigger volume snapshot before disk conversion
• Clone and convert VMDK to VHDx format for all VMs
• Power ON VMs in protection group – at target
• Register the networks on each VM
• Remove VMware tools and assign the IP addresses using trigger script or cron job depending on the OS type

For detailed information, refer to using the Shift toolkit to perform VM migration

What can Shift toolkit do for you:

Shift toolkit provides flexibility in a multi-hypervisor environment by supporting bidirectional conversion between the following hypervisors:

• VMware ESXi to Microsoft Hyper-V
• Microsoft Hyper-V to VMware ESXi (Upcoming release)

Shift toolkit supports disk-level conversions of virtual disks between hypervisors for the following disk formats:

• VMware ESX to Microsoft Hyper-V (virtual machine disk [VMDK] to virtual hard disk format [VHDX])
• VMware ESX to KVM compatible hypervisors (VMDK to QCOW2)

Note: The converted qcow2 files are compatible with any KVM hypervisors. For example, a qcow2 file can be utilized with RHEL-based KVM using virt-manager to create a VM, as well as with ubuntu KVM, Rocky Linux based KVM and others. The same can be used with Oracle Linux virtualization manager and with OpenShift virtualization after importing using NetApp Trident. The goal is to provide the disk (converted in secs to mins) which can then be integrated into existing automation scripts used by organizations to provision the VM and assign the network. This approach helps reduce overall migration times, with disk conversion handled by Shift toolkit APIs and the remaining script bringing up the VMs.

In future releases, Shift toolkit will support end-to-end migration from VMware to other compatible KVM hypervisors. However, with the current release, the conversion can be performed via the UI or APIs.

Summarizing

NetApp Shift toolkit helps an administrator to rapidly and seamlessly convert VMs from VMware to Hyper-V. It can also convert just the virtual disks between the different hypervisors. Therefore, Shift toolkit saves several hours of effort each time that you want to move workloads from one hypervisor to the other. Organizations can now host multi-hypervisor environments without having to worry about whether workloads are tied down to a single hypervisor. This capability increases flexibility and reduces licensing costs, lock-in, and commitments to a single vendor. 

To learn more about this process, feel free to follow the detailed walkthrough:

https://netapp.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=6bf11896-3219-4ba7-9a00-b2d800d47144&start=0

If you’re planning to migrate thousands of VMs and ready to start simplifying the migration process, NetApp is here to help. https://mysupport.netapp.com/site/tools/tool-eula/netapp-shift-toolkit

When companies need financial management and planning, they can turn to AdvisorEngine. This US-based wealth management service provider offers tools and services that help financial advisors assist clients manage portfolios and stay ahead of the curve. 

But AdvisorEngine was having issues around the performance of the massive Microsoft SQL Server database estate supporting a line-of-business software as a service (SaaS) application. After a deep analysis of the system’s architecture, the company realized that modernizing the storage layer would make a big difference. 

AdvisorEngine turned to Amazon FSx for NetApp ONTAP (FSx for ONTAP) to do that. In this post I’ll explain how FSx for ONTAP addressed AdvisorEngine’s challenges and the added benefits it provided in the process, including a sixfold performance improvement, a 50% cost reduction, and much more.

Here’s what we’ll cover:

• AdvisorEngine: A major fintech company with a massive SQL Server deployment
• This architecture presented some challenges
• How FSx for ONTAP solved AdvisorEngine’s database challenges
• What is FSx for ONTAP?
• AdvisorEngine saw a vast improvement using FSx for ONTAP
• The next step? Automating FSx for ONTAP using BlueXP workload factory
• Conclusion

AdvisorEngine: A major fintech company with a massive SQL Server deployment 

AdvisorEngine provides a range of wealth management services and technologies—including portfolio management, digital onboarding, customer relationship management (CRM) systems, financial planning tools, and more. Together, the company oversees client assets totaling over half a trillion dollars.

One of these products is a customer-facing SaaS application that runs on Amazon Web Services (AWS). The application’s architecture included around 1,000 self-managed SQL Server databases running between two Always-On Failover Cluster Instances (FCIs) on AWS. 

Here’s what the architecture AdvisorEngine had been using looked like:

• Two self-managed SQL Server Always-On FCIs, each with three nodes: one primary node, one node for high availability (HA) in a different Availability Zone (AZ), and one node for disaster recovery (DR) located in a separate AWS Region.
• Around 1,000 SQL Server databases split between the two FCIs.
• Backup via SQL Server’s internal backup process to Windows File Server.
• A third-party replication engine responsible for synchronous replication between the Elastic Block Store (EBS) storage volumes for the FCI nodes, and asynchronous data replication to the DR nodes.

This architecture presented some challenges

The main challenge was that the application was experiencing performance issues. There were drop-offs and spikes throughout the day. Performance was simply not consistent, and for a line-of-business application such as this, that was simply not acceptable.

AdvisorEngine was also relying on a third-party vendor to replicate data for disaster recovery (DR) purposes. That tool was not only affecting the performance of the production environments, it was also not meeting AdvisorEngine’s recovery time objective and recovery point objective targets, and data was frequently out of sync.

With the business growing and the application adding new users, a new solution had to be found. The first option—to expand the existing resources to meet the growing demand—would have been prohibitively expensive. And it wouldn’t solve the difficulty with the DR system.

The team at AdvisorEngine did a deep dive into the database and analyzed the entire architecture. They discovered that the file system performance was lagging because of the replication service’s processes. As such, the file system couldn’t handle the scale of the SQL Server workload.

The following images show the kind of performance drop-offs that AdvisorEngine was experiencing. The total transactions per minute peaked at 10,194 transactions per minute (TPM):

How FSx for ONTAP solved AdvisorEngine’s database challenges

What is FSx for ONTAP?

FSx for ONTAP is an AWS storage service that delivers NetApp ONTAP functionality natively on AWS. It provides a highly available file system and block storage that can scale to meet even the most demanding workloads, from vast GenAI knowledge bases to massive SQL Server deployments such as AdvisorEngine’s. Learn more about FSx for ONTAP here.

AdvisorEngine looked at several different storage services on AWS to solve the problem. Compared with the other services, FSx for ONTAP was less expensive and delivered a more performant experience. Even though AdvisorEngine and its IT teams had no previous hands-on knowledge with NetApp technology, FSx for ONTAP was the obvious choice as it provided a like-for-like experience in the cloud as on premises. FSx for ONTAP was also the only service on AWS that was able to provide block storage that could be shared across Availability Zones (AZs).

That’s an important point for this story: Even without previous experience with NetApp or ONTAP technology, the IT team was able to quickly understand its workflows and benefit from its value and efficiency.

Here’s what the new architecture with FSx for ONTAP looks like:

 The architecture includes:

• An FSx for ONTAP multi-AZ high-availability (HA) pair stored in a primary AWS Region
• Another FSx for ONTAP multi-AZ HA pair which is stored in a different AWS Region and used for DR
• Asynchronous replication via SnapMirror® between the primary and DR FSx for ONTAP instances
• Backup via a third-party backup process to Amazon Simple Storage Service (Amazon S3) and later, Amazon S3 Glacier
• Virtual private cloud (VPC) peering between the primary and the DR FSx for ONTAP environments to a Windows Server FCI Quorum file share 

AdvisorEngine saw a vast improvement using FSx for ONTAP

AdvisorEngine was able to accomplish major improvements with its application and its underlying SQL Server deployment by switching to FSx for ONTAP:

Performance improved sixfold 

AdvisorEngine saw the performance of the application’s database increase sixfold, all while using a similar amount of Amazon Elastic Compute Cloud (Amazon EC2) instances. A major contributing factor to the increase in performance was that NetApp SnapMirror was now being used for replication as opposed to the inefficient third-party tool. 

The diagram below shows how FSx for ONTAP has performed versus the peaks and valleys of the old architecture. Where the old environment was delivering sporadically, FSx for ONTAP is delivering consistently:

Costs came down by 50%

AdvisorEngine was able to significantly reduce the costs of running the SQL Server deployment: AdvisorEngine’s costs are down 50% using FSx for ONTAP. 

There was also a 75% cost avoidance by switching to FSx for ONTAP. That’s because scaling up the previous storage solution’s bandwidth would have required the use of larger and more expensive Amazon EC2 instance types. Because FSx for ONTAP uses network performance, there was no need to scale up compute that way.

Another part of the savings comes from the new DR setup (see more on that below). That replication takes place between FSX for ONTAP instances via SnapMirror. This is a highly efficient technology that updates the data incrementally. That reduces the time and costs of replicating data to the DR copy, all without the added expense of using a third-party technology. 

Learn more about how to lower your AWS database costs with FSx for ONTAP.

A high level of resilience for business continuity

FSx for ONTAP is highly available by default, with each instance consisting of two FSx for ONTAP nodes that are kept in constant sync. AdvisorEngine is using the deployment option that places the two FSx for ONTAP nodes in separate AZs, providing the highest possible availability. Even if a whole AZ goes down, the system will seamlessly transfer all operations to the healthy node, preserving business continuity.

Note that FSx for ONTAP is the only AWS storage service that can share block storage across AZs out of the box, with no need for additional instances or costs.

Better data protection, without a third-party tool for DR 

FSx for ONTAP provides AdvisorEngine with a way to protect its data across AWS Regions with its built-in cross-Region replication capabilities. 

The main technology that makes this possible is NetApp SnapMirror. Because SnapMirror uses highly efficient incremental replication, it works very quickly and prevents any of the performance issues the previous replication technology caused.

This setup also saves on compute spending because DR is part of the storage layer and not related to compute, meaning AdvisorEngine doesn’t have to constantly write from live resources.

For additional protection, AdvisorEngine is backing up data on an Amazon S3 bucket. A policy later tiers old backups to Amazon S3 Glacier. These backups are created from the DR copy which is a mirror of the production data, so there is absolutely no impact on the performance of the live environment.

Here’s what the DR and backup architecture with FSx for ONTAP looks like:

Easy-to-create, cost-efficient database clone copies

By leveraging NetApp FlexClone® technology, FSx for ONTAP enables AdvisorEngine to create instant and lightweight clone copies of database environments. These lightweight environments take up a bare minimum of storage space, which means they don’t incur the additional storage charges that other technologies face for creating full copies. Plus, creating clones is non-disruptive for the production environment.

AdvisorEngine uses these copies for various development needs, including validation, QA, and testing. Because they take only minutes to create, the entire development cycle is now much faster. Before using FSx for ONTAP, AdvisorEngine couldn’t regularly run staging environments. FSx for ONTAP and its cloning capabilities changed all that, which improved their continuous integration and delivery (CI/CD) processes.

Here you can see how the clone-based staging environments fit into the overall architecture:

The next step? Automating FSx for ONTAP using BlueXP workload factory

AdvisorEngine has a unique opportunity to make their FSx for ONTAP deployment faster and safer using BlueXP™ workload factory for AWS. 

Workload factory is a free service within the BlueXP GUI that makes it possible to build workloads—including database environments—right the first time thanks to: 

• Automated deployment: Workload factory makes it possible to automatically deploy the infrastructure needed for new and existing databases. The FSx for ONTAP storage layer and EC2 instances are optimized for database workload requirements.
• Continuous optimization: Keeping tabs on the database is an ongoing and automatic process, and workload factory monitors and reports to make sure the architecture is optimized and aligned with best practices. Read more about how continuous optimization works.
• Automating IaC: Workload factory provides pre-generated infrastructure-as-code (IaC) snippets for APIs, Terraform, and CloudFormation. Codebox, where workload factory delivers the snippets, provides a resource to support ongoing day-1 and day-2 operations.
• Faster onboarding: For users who are just getting started with FSx for ONTAP, workload factory helps onboard your database to the new storage environment. It starts by assessing your current storage system to provide total cost of ownership (TCO) calculation and deployment recommendations, to help you optimize your environment’s configuration.
• Best-practice guardrails: Workload factory provides best-practice recommendations that are automatically applied to the environments it provisions. These keep your database running optimally from the very start.

Learn more about enhancing database operations with BlueXP workload factory for AWS or try it now.

Conclusion

FSx for ONTAP block storage gave AdvisorEngine’s SQL Server deployment six times more performance, 50% lower costs, enhanced CI/CD pipelines, and simplified and enhanced resiliency. 

Want to learn more about FSx for ONTAP and this architecture? Visit these resources:

• Watch this in-depth webinar on the AdvisorEngine customer success story with FSx for ONTAP
• Read the AdvisorEngine case study
• Find out more about enhancing your database performance and cost with FSx for ONTAP here

NetApp is excited to announce the release of ONTAP tools for VMware vSphere 10.4, the cornerstone of our VMware vSphere and Cloud Foundation integration.

ONTAP tools empowers vSphere administrators with simple and intuitive capabilities for provisioning, protecting, monitoring, and managing the entire lifecycle of their datastores using the NetApp ONTAP intelligent data infrastructure.

Administrators and SREs can take advantage of either the simple-to-use vCenter GUI extensions or robust REST API integration for use with VMware Cloud Foundation (VCF) Automation (formerly Aria and vRealize Automation), Ansible, PowerShell/PowerCLI, or any other common automation platform or scripting language. Storage Policy-Based Management (SPBM) simplifies storage management and automation at scale using VMware Virtual Volumes (vVols).

ONTAP tools is built upon three pillars that lower TCO and risk through simplification and automation:

If you tried ONTAP tools before 10.3, be sure and check it out again because the installation process has been greatly simplified and now works out of the box without requiring any scale-out or scale-up for >90% of non-vVols users. For production vVols users, we always recommend scaling out for high-availability and load balancing, which is a hallmark of ONTAP tools 10. Scaling-up or scaling-out is now achieved by simply going to the appliance management UI and clicking the edit appliance settings option on either the main page or the “Getting Started” page.

If you are still using ONTAP tools 9, one more thing to know about ONTAP tools 10 is that it supports adding multiple vCenter servers to one appliance, whereas in the past, we always required one appliance per vCenter.

We are pleased to announce the general availability of vVols support for all ASA systems launched, now including the ASA A1K, A90, and A70, as well as the new entry-level ASA A20 and midrange ASA A30 and A50. Previous generations of ASA and all Unified systems retain their existing support.

Let's take a high-level look at the advantages of using Vols with this new storage architecture.

Limits for vVol counts are generally going to match what you see in Hardware Universe for your version of ONTAP and system type. ONTAP tools 10.4 itself currently supports up to ~100K vVols with a 3-node HA-large deployment, but please check the configuration limits section of the prerequisites page, as this number continues to increase as ONTAP tools evolves. If you have smaller systems, ONTAP tools will let you add multiple ONTAP storage clusters to reach the scale you need.

With all that said, let's take a look at what new and updated capabilities ONTAP tools 10.4 delivers:

ONTAP tools 10.4 can be downloaded here: https://mysupport.netapp.com/site/products/all/details/otv10/downloads-tab/download/65001/10.4/downloads

You can find the documentation here: ONTAP tools for VMware vSphere documentation.

The best practices guide for vVols can be found here: TR-4400: VMware vSphere Virtual Volumes (vVols) with NetApp ONTAP.

The best practices guide for SRA can be found here: TR-4900: VMware Site Recovery Manager with NetApp ONTAP.

The general best practices guide for VMware with ONTAP can be found here: TR-4597: VMware vSphere for ONTAP.

With Insight in the rearview mirror, many of you who attended my sessions heard me talk about using nconnect with vSphere 8.0U2 and later achieving block-protocol performance levels with the simple NFS file protocols.

For those who haven’t heard of nconnect before (given how new it is in the VMware universe, it’s unsurprising that many VMware admins haven’t), let me give you a short primer.

Starting in ONTAP 9.8 (December 2020), NetApp added support for nconnect for NFS v3 and v4.X, which has been supported by Linux clients since kernel 5.3 (September 2019 and SUSE Linux the year prior). Nconnect allows an NFS client to establish multiple TCP connections from a single client interface (vmkernel port in this case) to a single server interface (ONTAP NFS LIF for example), allowing for distribution of I/O across the connections for improved performance.

When used with LACP ifgroups and TCP-port-based load balancing in ONTAP, and active-active uplinks with vmkernel ports in vSphere, NFS connections are balanced across multiple physical connections. Thereby allowing you to utilize your network resources to the maximum extent possible.

Compare the flow of IO with and without nconnect

Our internal testing has shown that you can achieve performance on par with block protocols using the same transport and number of active/optimized connections.

Refer to the solution guide for NFS nConnect feature with NetApp and VMware and NFS best practice and implementation guide | TR-4067 (netapp.com) as well as the previous blog post NetApp and VMware – Better than ever - NetApp Community. Broadcom also publishes Guidelines and Requirements for NFS Storage with ESXi (vmware.com). For more information from VMware by Broadcom, see knowledge base articles 91497 and 91479.

Full support was added for NFS v4.1 in vSphere 8.0 update 3.

• VMware ESXi 8.0 Update 3 Release Notes

Importantly nconnect can be utilized without downtime, reboots, or remounting of datastores. The number of connections can be scaled up or down as needed, from 1-4 (up to 8 with advanced settings).

Unfortunately, as of vSphere 8.0 Update 3, there is still no simple UI to manage your nconnect settings. To that end, for my own TME labs, I have written a basic PowerShell script that configures nconnect for you. It asks the user for the following items:

1. vCenter to manage
2. Credentials to use
3. Which datacenter contains the hosts to update
4. What the desired nconnect value should be.

The script configures the max allowed value to 8  then sets the value you entered for all datastore connects on all hosts in the indicated datacenter.

Note: ESXi has a hard-coded limit of 256 NFS connections, therefore consideration should be given to how many datastores you plan to use with nconnect as each additional connection counts towards the limit. That said, even increasing nconnect from 1 to 2 is well worth the effort because the increase in performance can be noticeable when you push the limits.

As a bonus, it also enables VAAI snapshot offload which eliminates the problem of vCenter-managed snapshots by using array-based disk clones instead of VMDK delta files. Note that VMs that have existing snapshots or that you don’t have permission to modify will throw an error in the script execution, but the script will just continue to the next VM.

Keep in mind that vCenter-managed snapshots that leverage VAAI being FlexCloned files are not the same as volume snapshots integrated with vCenter through the NetApp SnapCenter Plugin for VMware (SCV). SCV can also integrate tamper-proof snapshots (TPS) for extra ransomware protection and enable you to restore from secondary or tertiary snapshot copies on other systems. Both VAAI offloaded and SCV-integrated snapshots can be used to complement each other.

The only downside to VAAI snapshot offload is that vSphere doesn’t allow storage vMotion of VMs that have offloaded snapshots. You would have to delete the snapshots before you could storage vMotion that VM to another datastore. Feel free to remove that part if you don’t want to take advantage of snapshot offload.

And now for the script. This should help until the vCenter UI/API gap is addressed in the future. You may wish to modify it from the datacenter context to ESXi cluster context, depending on your use case.

#Load VMware PowerCLI core module if not already available
Import-Module VMware.VimAutomation.Core

# Prompt for the vCenter Server
$vCenter = Read-Host -Prompt "What vCenter do you want to connect to?"
Write-Output "You entered: $vCenter"

# Prompt for vCenter Server credentials
$cred = Get-Credential

# Connect to the vCenter Server using the provided credentials
Connect-VIServer -Server $vCenter -Credential $cred

# Prompt for the datacenter
$Datacenter = Read-Host -Prompt "Which datacenter do you want to update?"
Write-Output "You entered: $Datacenter"

# Prompt for nconnect value
$nconnect = Read-Host -Prompt "What do you want the nconnect value to be? (1-8)"
Write-Output "You entered: $nconnect"


Write-Output "Now updating VMs to enable snapshot offload"

#Enable VAAI snapshot offload
$vms = get-vm -Location $Datacenter
foreach ($vm in $vms) {
    New-AdvancedSetting -Entity $vm -Name snapshot.alwaysAllowNative -Value TRUE -Confirm:$false -Force:$true
}

# Get all NFS datastores and hosts in the datacenter
$V3Datastores = Get-Datastore | Where-Object {
    $_.Type -eq "NFS" -and $_.Datacenter -match ($Datacenter)
}
$V41Datastores = Get-Datastore | Where-Object {
    $_.Type -eq "NFS41" -and $_.Datacenter -match ($Datacenter)
}
$vmhosts = Get-VMhost -Location $Datacenter

#Setting the maximum allowed nconnect value
Write-Output "Now updating the nconnect max value"
foreach ($vmhost in $vmhosts) {
    Get-AdvancedSetting -Entity $vmhost -Name NFS.MaxConnectionsPerDatastore | Set-AdvancedSetting -Value 8 -Confirm:$false
}

# Loop through each datastore and set the nconnect value to $nconnect for both NFSv3 and NFSv41
Write-Output "Now updating NFS v3 datastores to $nconnect"

foreach ($vmhost in $vmhosts) {
    foreach ($V3Datastore in $V3Datastores) {
        $esxcli = Get-EsxCli -VMHost $vmHost -V2
        # Set nconnect for NFSv3
        $arguments1 = $esxcli.storage.nfs.param.set.CreateArgs()
        $arguments1.volumename = $V3Datastore.Name
        $arguments1.connections = $nconnect
        $esxcli.storage.nfs.param.set.Invoke($arguments1)        
    }
}

Write-Output "Now updating NFS v4.1 datastores to $nconnect"

foreach ($vmhost in $vmhosts) {
    foreach ($V41Datastore in $V41Datastores) {
        $esxcli = Get-EsxCli -VMHost $vmHost -V2
        # Set nconnect for NFSv41
        $arguments2 = $esxcli.storage.nfs41.param.set.CreateArgs()
        $arguments2.volumename = $V41Datastore.Name
        $arguments2.connections = $nconnect
        $esxcli.storage.nfs41.param.set.Invoke($arguments2)
    }
}


# Disconnect from the vCenter Server
Disconnect-VIServer -Confirm:$false