Node01 hat an hard reboot error of the ACP module, this was also visible in the shelf-log-iom log.

With this error we decided to replace node01 but the issue presists with the sporadic ACP errors.

We restarted both nodes both BMC and turned ACP off and on.

Since the issue presists we are thinking to replace the node02, since the system has no expansion shelfes. If the issue then presits my only thought is that the midplane of the Controller shelf is faulty.

System has one Controller shelf and is hosting CIFS/NFS

Any other ideas or would you also replace the other node?

Hi Team,
We are currently setting up the IHCAZ CV4 lab environment in Azure. The lab guide specifies Standard_E4ds_v4 for CVO and Standard_E8ds_v4 for CVOHA. However, Azure has informed us that these VM sizes are currently under growth control and are not available for our subscription. Could you please confirm whether any other supported Azure VM sizes with similar specifications can be used as alternatives for CVO and CVOHA?

If yes, could you please recommend the appropriate VM sizes that we can use?

Thank you.

thanks

It's a valid concern. Many migration solutions in the market have historically relied on VMware's Virtual Disk Development Kit (VDDK) as a core component for moving virtual machine data between hypervisor platforms. With public access to VDDK now restricted, organizations are understandably assessing the potential impact on their migration plans.

The answer is simple: No.

Shift Toolkit has never relied on VDDK, qemu-img or storage array copy offload mechanisms such as VAAI XCOPY/vmkfstools as part of its migration architecture. As a result, recent changes surrounding VDDK availability do not impact migration workflows, existing projects, or our product roadmap.

Why This Matters

For years, VDDK has been a common component used by VM migration solutions to access and transfer virtual machine data. As a result, many organizations have found themselves exposed to changes beyond their control when those dependencies become restricted, altered, or unavailable.

The recent VDDK situation is a reminder that critical migration projects should not hinge on a single hypervisor vendor's SDK or utility. When a migration platform depends on external tooling, unexpected changes can introduce complexity, delays, or additional operational overhead.

The Shift Toolkit Difference

For Shift Toolkit customers, the recent VDDK changes are not triggering product redesigns, engineering workarounds, or alternative migration workflows.

That's because Shift Toolkit was designed from day one without a dependency on VDDK, qemu-img or storage array copy offload mechanisms.

While some migration vendors may now be evaluating alternative approaches following the VDDK changes or leaning more heavily on storage copy offload technologies such as VAAI XCOPY/vmkfstools, our engineering team remains focused on what we've always focused on: delivering new hypervisor choice, enhancing migration capabilities, and improving the customer experience.

What's New in NetApp Shift Toolkit 8.2

NetApp Shift Toolkit continues the journey by building on the capabilities introduced in previous releases and delivering further enhancements to simplify and accelerate virtualization migrations.

These investments are about innovation, not dependency replacement. Because Shift Toolkit has never depended on VDDK, qemu-img or storage array copy offload mechanisms, we've been able to keep evolving the platform without being pulled off course by changes to third-party migration components.

Highlights in v8.2

• Optimized VMware to AWS VM migrations using the EBS Direct API for improved performance and efficiency. 
• Bi-directional support for Proxmox to VMware, enhancing workload portability. 
• Cross-SVM support for OpenShift virtualization for greater deployment flexibility. 
• Standard Port Group support during discovery of VMware environments.

Key Benefits of Using Shift Toolkit:

• Zero copy migration with no block copy process, the true storage offloading for any hypervisor migrations, making Shift toolkit the fastest migration tool
• Unparalleled VM mobility across on-premises hypervisor platforms and now to the cloud.

Note: Shift Toolkit now supports Hyper-V, VMware, OpenShift, OLVM, Proxmox, and AWS EC2 as first-class citizens, and our proprietary conversion mechanism can support any hypervisor and disk format, making VM mobility a breeze.

• No dependency on VDDK for VM migrations.
• No reliance on qemu-img conversion processes.
• No dependency on VAAI XCOPY or vmkfstools based storage copy offload.
• Reduced exposure to third-party licensing or product availability changes.
• Consistent migration experience regardless of shifts in the VMware ecosystem.
• Continued innovation focused on customer outcomes, not dependency management.
• And finally, it's free.

The Bottom Line

Others may be looking for a path beyond VDDK. Shift Toolkit never had to. 

No VDDK. No qemu-img. No migration roadblocks. Just a dependable path to the hypervisor of your choice with Shift Toolkit.

Industry changes will keep happening, licensing models will keep evolving, and technologies will come and go. What's important is having a data mobility platform that isn't tied to those changes. With Shift Toolkit and ONTAP, organizations can migrate virtual machines across hypervisors without worrying about VDDK availability, qemu-img dependencies, or unexpected ecosystem shifts.

If your organization is looking for migrating virtual machines, try NetApp Shift toolkit and see the difference.

Recently one of our customer has purchase the FAS70 with 2 Qty of DS212C shelf... Now we want to do the connectivity from controller to shelf.. for which I am referring this document : https://docs.netapp.com/us-en/ontap-systems/fas-70-90/install-cable.html#step-4-cable-the-shelf-connections . In this document it has show connetivity from FAS70 to 2 Qty of DS460C.. Referring the I have prepared the document which I have attached. But while also going through netapp website : https://docs.netapp.com/us-en/ontap-systems/sas3/install-cabling-rules.html#controller-a-and-c-port-connection-rules-for-platforms-without-internal-storage .. I got this image (Attached). Now i am confused which connecivity i should use? Attached PDF it is created by me by taking reference of NetApp docs (FAS70 to 2 Qty of DS460C shelf connecivity) and attached image is again from NetApp docs only. Please someone help here.

The core content of the exam remains unchanged and continues to cover the areas outlined below:

• Storage Platforms
  
• Core ONTAP
  
• ONTAP Storage
  
• Networking
• Storage Protocols and Connectivity
• Data Protection
  
• Security
• Performance
  

We installed a new, previously used hard drive.

Now the following message appears in the grid log:

Uncertified drive detected.

Has anyone else experienced this before?

As I understand it, this is because the drive came from a system that had newer firmware installed.

I’ve only found information from HPE on the internet regarding this.

Get-NcNode:

Line |

20 | $nodes = Get-NcNode -Controller $cluster

| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

| Error converting value "All checks passed" to type 'DataONTAP.C.Types.System.Reason'. Path 'ha.takeover_check.reasons[0]', line 143, position 27.

Other clusters that are 9.16.1 don't have this issue. Happens on two different 9.18.1 clusters. The workaround I found is to add "-ONTAPI" to the connect-nccontroller but obviously isn't a long term fix. Not sure if this is an ONTAP or a powershell toolkit bug.

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

While managed services simplify administration by automating many operational tasks, enterprise Oracle environments often have specific requirements around performance, availability, recovery objectives, database lifecycle management, and operational flexibility. For these environments, architecture decisions are driven less by operational simplicity and more by the need to meet workload requirements.

This post explores the options for running Oracle Databases on AWS and explains how Amazon FSx for NetApp ONTAP (FSx for ONTAP) can enhance self-managed deployments.

What this post covers:

• Two options for running Oracle Databases on AWS
  
• The managed option: Simplicity and automation
  
• The self-managed option: Control and flexibility
  
• Optimizing self-managed Oracle with FSx for ONTAP
  
• Case study: A global learning company modernizes on AWS
  
• Summary

Two options for running Oracle Databases on AWS

There are two main options for deploying Oracle on AWS. The first is to choose a fully managed service, like Amazon Relational Database Service (Amazon RDS) for Oracle or Oracle AI Database@AWS, where AWS and Oracle handle most of the infrastructure management, with less configuration control for the customer. The second is to opt for a self-managed deployment on Amazon EC2, giving you full control over the Oracle stack and underlying architecture.

Both these choices are viable; the best fit depends on your business and technical needs. While this decision is often framed as control versus simplicity, you should also consider factors such as recovery requirements, database copy management, architectural flexibility, performance objectives, and overall cost efficiency.

The managed option: Simplicity and automation

Managed services like Amazon RDS for Oracle reduce operational effortby automating tasks such as provisioning, patching, backup, and monitoring.

Capabilities

With Amazon RDS for Oracle, you can scale compute and memory, with storage scaling up to 256 TiB. For demanding workloads, Provisioned IOPS SSD storage up to 256,000 IOPS is supported. High availability is achieved through multi-Availability Zone (AZ) deployments, which maintain synchronous standby volumes and provide automatic failover.

Amazon RDS also offers managed alternatives to Oracle Real Application Clusters (RAC) capabilities, through multi-AZ, vertical scaling, and Oracle GoldenGate platform integration. The newer Oracle AI Database@AWS service provides access to Oracle Exadata infrastructure and Autonomous Database services within AWS data centers, which is ideal if you need native Oracle capabilities with low-latency connectivity to AWS applications.

Overall, these managed options accelerate deployment, simplify maintenance, and reduce operational complexity.

Considerations

It’s important to bear in mind that this simplicity comes with less granular control. With Amazon RDS, you have no direct shell access, get restricted administrative accounts (SYS and SYSTEM), and face limits on certain privileges. This can be a significant drawback for organizations with custom configurations, specific operational tools, or a need for direct OS and storage control.

Amazon RDS also has service-specific limits, such as a 16 TiB maximum data file size and a fixed 8 KB database block size. Oracle AI Database@AWS adds multi-cloud complexity, requiring management of both AWS and Oracle Cloud Infrastructure (OCI) components.

While managed services are excellent for prioritizing simplicity, they might not suit organizations with strict architectural standards or advanced operational needs, particularly where multiple database copies, large storage footprints, specialized recovery requirements, or demanding performance objectives are involved. In these scenarios, a self-managed architecture can provide both greater flexibility and a more cost-efficient operating model.

The self-managed option: Control and flexibility

Running Oracle on Amazon EC2 provides complete control over your database architecture and operations.

Capabilities

With a self-managed model, you control the OS, database configuration, storage, backup strategy, and high availability (HA) and disaster recovery (DR) designs. So, you can choose the Amazon EC2 instances and storage platform that precisely match your performance, availability, and compliance needs.

This flexibility is crucial for applications requiring specific Oracle features or custom configurations. It also lets you mirror on-premises architectures, preserving operational consistency while modernizing on AWS.

Considerations

The trade-off is greater responsibility. Your team has to design, operate, and maintain the entire environment, including backup, HA and DR, and capacity management. This requires significant in-house expertise in Oracle, AWS, storage, and networking, in addition to responsibility for monitoring, patching, and testing failover processes.

The self-managed model makes the most sense if you need deep control; but is less suitable for teams wanting to minimize infrastructure management.

Optimizing self-managed Oracle with FSx for ONTAP

Organizations that require a self-managed Oracle deployment face the challenge of designing and operating an architecture that delivers the required levels of availability, recoverability, performance, scalability, and operational efficiency.

Amazon FSx for NetApp ONTAP helps address these challenges by combining the control of a self-managed environment with the enterprise-grade storage capabilities of ONTAP®, delivered as a managed AWS service. Many capabilities that would otherwise need to be designed and operated separately are built into the storage layer, helping simplify operations, while retaining flexibility.

Key benefits include:

• Meeting demanding recovery objectives: FSx for ONTAP provides storage-level multi-AZ, Snapshot copies, and cross-AWS Region replication, protecting against failures and data loss, while enabling faster recovery. These capabilities can help meet aggressive recovery point objectives (RPO) and recovery time objectives (RTO).
• Delivering high performance: FSx for ONTAP scales to up to 72 GBps of throughput and 2.4 million IOPS, withconsistent sub-millisecond latency for business-critical applications. So, you can align storage performance with the needs of demanding Oracle workloads.
• Independent scaling: Storage capacity and performance can be scaled independently of the Amazon EC2 database server, so you can expand storage without re-architecting the compute layer. This flexibility is particularly valuable for large Oracle environments, where storage and compute requirements often evolve at different rates.
• Accelerated workflows through fast cloning: ONTAP FlexClone® technology enables fast, space-efficient, writable copies of Oracle environments, streamlining DevTest, QA, reporting, and analytics workflows. For organizations maintaining numerous database copies, this can significantly reduce both operational effort and storage consumption.
• Optimizing cost at scale: Features like compression, compaction, thin cloning, and data tiering significantly reduce storage consumption and costs, particularly in large Oracle environments with multiple database copies. This helps organizations optimize storage economics without compromising performance or functionality.

With FSx for ONTAP, the storage infrastructure becomes a strategic asset that makes self-managed Oracle on AWS more resilient, agile, and cost-efficient. For some Oracle deployments, these capabilities aren’t merely optimization features; they become architectural requirements.

Case study: A global learning company modernizes on AWS

A global learning company operating in 70 countries needed to migrate its complex Oracle ERP environment to AWS. The project involved re-architecting Oracle RAC systems to run on hundreds of Amazon EC2 instances with 400 TB of storage. Given the scale and complexity of the environment, maintaining architectural flexibility and enterprise-grade data management capabilities was a key migration requirement.

By choosing a self-managed approach with FSx for ONTAP, the company went live on AWS in just over 4 months. It saw immediate performance gains, including a 20% improvement in supply chain processing. FSx for ONTAP also reduced operational effort and accelerated workflows, with database refreshes running 10 times faster while financial processing times cut by two-thirds.

As a result, the company improved agility, performance, and operational efficiency, while maintaining the flexibility needed to support complex enterprise workloads.

Summary

Fully managed Oracle services on AWS are an excellent choice for organizations prioritizing operational simplicity. However, many enterprise environments require more than simplified administration; they need greater control over architecture, recovery, performance, database lifecycle management, and storage.

For these use cases, a self-managed model on Amazon EC2 provides the necessary flexibility. By incorporating Amazon FSx for NetApp ONTAP, organizations can optimize this architecture with enterprise-grade storage capabilities for protection, performance, cloning, scalability, and storage efficiency.

The key is to start by understanding the requirements of your Oracle workload and then choose the deployment model that best supports them. Where architectural flexibility and advanced storage capabilities are important, FSx for ONTAP can help you modernize Oracle on AWS, without sacrificing control or operational efficiency.

For more information, read our blog post about how to optimize Oracle databases on AWS with Amazon FSx for NetApp ONTAP and NetApp® Workload Factory™, or watch our webinar on Unlocking Oracle performance on AWS with Amazon FSx for NetApp ONTAP.

For many enterprises, the answer is no longer simply "move everything to the public cloud."

Some workloads must remain close to factories, hospitals, offices, or users. Some data must stay within a country or regulatory boundary. Some applications depend on predictable performance and availability. And many organizations already have years of investment in enterprise storage, data protection, and operational processes that they do not want to replace simply because the virtualization platform is changing.

At the same time, IT teams still want what the cloud has taught them to expect: consistent operations, automation, centralized management, APIs, policy-driven infrastructure, and faster access to new services.

The challenge is giving organizations the freedom to place applications and data where they make the most sense while operating them consistently. That's where Azure Local and NetApp come together.

The best of Azure, where you need it

Think about what people love about Azure. They love the consistency. The automation. The management tools. The ability to modernize infrastructure without constantly reinventing the wheel.

Azure Local extends the Azure operating model into customer-controlled environments, allowing organizations to run workloads in their own datacenters and distributed locations while using Azure-based management, governance, monitoring, and automation. Microsoft is increasingly positioning Azure Local as a foundation for sovereign and private cloud environments where control, compliance, and operational consistency matter most.

In simple terms, Azure Local gives organizations more freedom to decide where workloads run without creating an entirely separate operational model for each location.

Modernization shouldn't require rebuilding the data layer

For enterprise customers, however, infrastructure modernization often creates another problem: Why should changing the compute or virtualization platform require changing the storage architecture too?

Many organizations already operate mature enterprise SAN environments supporting large estates of business-critical workloads. Those environments represent more than storage capacity. They include operational knowledge, resiliency practices, data protection policies, security controls, and years of infrastructure investment.

Support for external enterprise storage with Azure Local creates a different modernization path. Customers can modernize the virtualization and operational layer while continuing to use enterprise storage for the workloads and data that depend on it.

This ability to separate compute and storage is particularly important in large datacenters, where compute capacity and storage capacity rarely grow at the same rate. Rather than forcing both to scale together, customers gain greater flexibility to evolve each layer according to business requirements.

But infrastructure is only half the story

Anyone who has worked in IT knows the infrastructure isn't usually the hard part.

The hard part is the data. How do you protect it? Replicate it? Govern it? Move it between environments? Keep it secure while supporting new applications and AI initiatives?

That's where NetApp becomes strategically important.

NetApp allows customers to modernize the compute and virtualization layer without forcing a simultaneous redesign of the data layer.

ONTAP provides enterprise storage capabilities for availability, efficiency, protection, security, replication, and lifecycle management that many organizations already depend on for mission-critical workloads. And because NetApp spans on-premises and Microsoft Azure environments, customers can build a data strategy that extends beyond a single infrastructure platform.

The result is a cleaner separation of concerns: Azure Local provides the cloud-connected infrastructure and operational model, while NetApp provides the enterprise data foundation underneath it.

Customers can decide where applications should run while maintaining consistent capabilities for managing and protecting the data those applications depend on.

A practical path for virtualization modernization

This becomes particularly relevant as organizations reassess their virtualization strategies.

Many enterprises considering alternatives to their existing virtualization platforms already run their most important workloads on shared enterprise storage. For those customers, replacing the hypervisor, servers, networking, storage, backup architecture, and operational processes simultaneously creates unnecessary cost and risk.

Azure Local with NetApp offers another approach: modernize the virtualization platform while preserving the enterprise data architecture where it still makes sense.

That can reduce the number of variables customers must change at once and allow infrastructure teams to modernize incrementally rather than treating virtualization transformation as a complete datacenter rebuild.

Diagram: NetApp ONTAP intelligent data infrastructure.

Azure Local and NetApp give organizations the flexibility to modernize compute and virtualization while maintaining an enterprise data foundation that extends across on-premises and Azure environments for HPC and AI-driven insights, real-time analytics, and secure, scalable workflows.

A modernization deployment we're seeing more often

Imagine a global manufacturer running thousands of virtual machines across regional datacenters and production sites.

Central IT wants to standardize infrastructure operations around Azure, while individual countries must meet local requirements for data residency, security, and availability. At the same time, the company has already invested heavily in enterprise storage, SAN networking, data protection, and operational processes.

A virtualization modernization should not require replacing all those layers at once.

With Azure Local, the organization can introduce a cloud-connected operating model for infrastructure in its own datacenters. With NetApp, it can continue using an enterprise data platform designed for the availability, protection, efficiency, and lifecycle requirements of business-critical data.

The company can modernize the compute and virtualization layer while preserving the data architecture where doing so provides operational and economic value.

And over time, it can decide workload by workload which applications remain local, which use Azure services, and which move to the public cloud.

Instead of choosing between cloud innovation and infrastructure control, the organization gains the flexibility to evolve each layer on its own timeline.

And increasingly, this matters for AI

AI initiatives often depend on large volumes of proprietary data that cannot simply be copied into every compute environment. In many cases, organizations will need to bring compute and AI services closer to governed enterprise data rather than continually moving that data toward compute. A flexible infrastructure and data architecture lets organizations place compute where it is needed while retaining control over the data that differentiates their business.

Why this matters now

The conversation around hybrid cloud has changed. A few years ago, hybrid cloud was primarily about migration. Today, it's about flexibility.

Organizations want the freedom to decide where applications run and where data resides. They want to meet sovereignty and regulatory requirements without slowing innovation. They want to preserve investments that still provide value rather than replacing infrastructure simply because another layer of the stack is changing.

And increasingly, they want infrastructure architectures that allow compute and data to evolve independently. Azure Local and NetApp fit naturally into that model. Azure Local provides a cloud-connected infrastructure and operational experience. NetApp provides the enterprise data foundation. The most important benefit isn't simply that Azure Local runs on-premises or that NetApp connects on-premises and cloud storage.

It is architectural choice.

Customers can modernize compute without automatically replacing storage. They can adopt a cloud operating model without forcing every workload into the public cloud. They can preserve enterprise data services while changing virtualization platforms. And they can decide over time which applications and data belong locally, in Azure, or across both.

Enterprise modernization should not require customers to choose between a cloud operating model and the data architecture they already trust.

Azure Local and NetApp give organizations another path: modernize what needs to change, preserve what continues to deliver value, and evolve the architecture at the pace the business requires.

Explore More

• Microsoft guidance for enabling NetApp external storage with Azure Local
• Bring Azure Local to Enterprise Scale with NetApp – Now Generally Available
• Connect with your NetApp or Microsoft team to validate configurations and plan your deployment.

By Matt Trudewind and Bill Rulo

How NetApp helps Federal Agencies adopt PQC and meet requirements today

Harvest now, decrypt later: The threat is already underway

Most encryption works like a digital lock: authorized users have the key, while everyone else sees unreadable data. Quantum computers could eventually open some of today’s widely used locks much faster than conventional computers. Post-quantum cryptography, or PQC, replaces those vulnerable locks with new mathematical protections designed to resist both conventional and quantum attacks.

Quantum computing is no longer just a research topic for labs, academia, and science fiction. For federal agencies, especially Intelligence Community (IC) and the Department of War (DoW) - the security implications are becoming very real, very quickly.

The concern is not simply what a quantum computer can do today. The bigger concern is what adversaries are already doing in preparation to utilize quantum computers to decrypt and unlock data in the near future.

One of the most urgent risks is called a harvest-now-decrypt-later attack. An adversary steals encrypted data or network traffic today, stores it, and waits until a sufficiently capable quantum computer can break the public-key encryption protecting it. That future point is sometimes called Q-Day. Data that appears unreadable today could then be exposed after it has already left the agency’s control.

This threat attack matters more for federal agencies because some mission and intelligence data must remain confidential for decades, potentially longer than the encryption protecting it remains safe. Examples include intelligence reporting, defense plans, weapons-system information, National Security System (NSS) data, citizen records, and long-term archives.

That is why post-quantum cryptography, or PQC, is not just a future compliance exercise. It is an existing and substantial threat to data security that agencies need to plan for now. Federal agencies cannot control when Q-Day will occur, however they can control whether the mission data they are protecting today will still be protected when Q-Day arrives.

Federal PQC guidance is moving into acquisition decisions

Federal policy is moving PQC from long-range planning into near-term acquisition and deployment decisions. White House Executive Orders 14306 and 14412 establish direction for strengthening cybersecurity and preparing for advanced cryptographic attacks. For National Security Systems, NSA’s Commercial National Security Algorithm Suite 2.0, or CNSA 2.0, identifies approved algorithm families and expected transition milestones. The practical message for system owners and vendors is clear: identify where vulnerable cryptography is used, plan the transition, and include PQC readiness in budgets and procurements now.

The transition timeline is especially important for IC and DoW customers. NSA’s CNSA 2.0 guidance identifies January 1, 2027, as the target for new National Security System acquisitions to be CNSA 2.0 compliant where required; December 31, 2030, as the target for equipment and services that cannot support CNSA 2.0 to be phased out; and December 31, 2031, as the target for CNSA 2.0 algorithms to be mandatory for National Security Systems, subject to the applicable policy, mission, and implementation guidance.

Be aware there is some nuance here. The January 1, 2027 date is referenced in the NSA CNSA 2.0 FAQ, while the CNSSP-15 (Committee on National Security Systems Policy No. 15) is currently the policy anchor. Because of that, some agencies may treat the 2027 milestone as strong acquisition guidance rather than a hard requirement across every environment. But for NSS, procurement cycles, and mission systems being designed today, the practical takeaway is clear: PQC readiness is becoming a near-term purchasing decision, not a distant roadmap item.

What NIST standardized—and why it matters

In August 2024, the National Institute of Standards and Technology (NIST) finalized its first three PQC standards after a multi-year international process. The standards identify quantum-resistant methods for two basic security functions: creating protected connections and proving that a user, system, certificate, or software update is authentic. Over time, these methods will replace vulnerable public-key algorithms such as Rivest-Shamir-Adleman (RSA), Elliptic-Curve Cryptography (ECC), and Digital Signature Algorithm (DSA).

• The three standards address two practical needs. Module-Lattice-Based Key-Encapsulated Mechanism (ML-KEM) helps two systems establish a shared secret for a protected connection. Module-Lattice-Based Digital Signature Algorithm (ML-DSA) and Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) provide quantum-resistant digital signatures that help verify identity and confirm that software, messages, or certificates have not been altered. The table below maps the formal standard names to those everyday functions.

The initial NIST PQC standards

These standards matter to storage because federal data is exposed through more than the media on which it resides. Risk also arises when administrators manage systems, applications access data, storage systems replicate data, certificates authenticate connections, and software or firmware is verified.

NIST has also made clear that agencies and organizations should begin migrating systems to quantum-resistant cryptography now, and that cybersecurity products, services, and protocols will need updates as organizations identify where vulnerable algorithms are used.

NetApp perspective: The data layer belongs in the PQC plan

NetApp provides data infrastructure software and systems that organizations use to store, manage, protect, and move data across data centers, remote locations, and cloud environments. Its core storage operating system, ONTAP, provides the software capabilities that control how data is accessed, replicated, encrypted, and recovered.

A lot of the PQC conversation focuses on networks, browsers, PKI, and applications. Those are all important. But for federal agencies, the data/storage layer is just as critical.

Why? Because storage is where the mission data lives.

An agency’s PQC plan must protect more than websites and network connections. Storage systems are where mission data remains for years or decades, where administrators manage it, and where copies move between locations for continuity and recovery. If those management and data-transfer paths continue to use vulnerable cryptography, the agency has closed only part of the security gap.

That is where NetApp can help.

Beginning with ONTAP 9.18.1, NetApp can use NIST-standardized post-quantum methods for specific ONTAP connections. This includes replication connections for on premises or cloud-based ONTAP instances. In practical terms, these capabilities are intended to protect selected administrative and data-movement paths that use supported TLS and certificate workflows. Agencies should validate the exact platform, protocol, certificate, and deployment requirements for each use case. The connections administrators use to manage storage and the connections systems use to move protected copies of data should also be evaluated. The relevant underlying standards are ML-KEM for establishing protected connections and ML-DSA for digital signatures and authentication.

Many storage operations depend on protected connections and digital certificates. These include the connection an administrator uses to manage a storage system, the connection two systems use to copy data for backup or recovery, and the certificates systems use to confirm that they are communicating with a trusted endpoint. PQC updates the public-key protections inside supported workflows; it does not replace every form of encryption in the storage environment.

End-to-end PQC capabilities without a rip-and-replace model

A software-based delivery model can reduce transition effort for supported systems. Agencies may be able to add PQC capabilities through an ONTAP upgrade rather than deploying a separate appliance or replacing the storage platform.

NetApp currently provides end-to-end PQC encryption for all mission and enterprise workloads for both new and existing customers at no additional cost. That is a big deal for federal agencies facing tight timelines, constrained budgets, and complex procurement processes.

Practical federal PQC use cases NetApp helps address

• Management of storage systems: Administrators can manage ONTAP through System Manager GUI and APIs using quantum-resistant TLS and certificate mechanisms.
• Safe replication of data: Data replication workflows for backup and DR can use quantum-resistant algorithms to help protect data as data moves between storage systems.
• Safe access to data: Client-to-storage access protocols, including File, Block, and Object, can benefit from quantum-resistant cryptography provided through IPsec and TLS.
• Encryption at rest: NetApp has used AES-256 to encrypt stored data for well over a decade. Current guidance considers AES-256 resistant to known quantum attacks when it is configured and implemented appropriately. This protection addresses data stored on the system, while PQC primarily updates the public-key methods used to establish trusted connections, exchange keys, and verify identities.
• Layered encryption for classified environments: NetApp Volume Encryption (NVE) provides software-based AES-256 encryption, while NetApp Storage Encryption (NSE) uses self-encrypting drives for hardware-based AES-256 encryption, enabling a layered encryption model validated by the NSA Commercial Solutions for Classified program for hosting top secret data.

Why NetApp is different

Federal cryptographic transitions are routine. When agencies moved from FIPS 140-2 to FIPS 140-3, NetApp’s crypto-agile architecture enabled customer to adopt new validated cryptographic module through an ONTAP software upgrade rather than a hardware refresh. This helped reduce costs, complexity, and operational impact.

NetApp provided an easy path for existing customers utilizing software encryption at rest to do this. A simple upgrade to ONTAP 9.15.1 or later automatically updates the NetApp cryptographic module to a FIPS 140-3 validated module without any impact to existing deployed systems. In other words, NetApp has a history of helping our customer easily transition to new cryptography without impacting existing missions, workflows and operations.

When it comes to the transition to PQC specifically, some vendors may be able to say they support quantum resistant encryption in a narrow use case. But federal customers should ask a more important question: Where does that PQC support actually apply?

Does it protect only CLI access? Only Fiber Channel? Only one management path? Only a narrow protocol? Or does it extend across the operational realities and use cases of how agencies manage, access, move, and protect data?

NetApp differentiation is that PQC support is broader than a single interface or isolated protocol. NetApp supports PQC end-to-end across GUI-based management, API access, replication, certificate authentication, TLS-based operations, client-to-storage encryption in transit, and storage-level encryption. That means agencies are not limited to protecting only one administrative workflow or one data path. The data is protected throughout the entire workflow path, not just for one workload. Whether it’s file, block, or object protocols, from the time data leaves the client endpoint until the data lands on the storage device, it is secure with NetApp’s unique end-to-end PQC encryption.

Because NetApp supports PQC as part of ONTAP core software and capabilities, this helps existing customers move toward quantum-resistant operations for their data layer without adding cost or complexity through a separate purchase.

Key questions every agency should ask

The bottom line

For federal agencies, PQC is not only about preparing for Q-Day. It is about protecting long-lived mission data from adversaries who may already be collecting encrypted information today.

The government guided timeline is fast approaching. NIST standards are available. CNSA 2.0 is shaping procurement expectations. IC and DoW agencies need solutions that help them modernize cryptography without disrupting mission operations.

NetApp helps federal customers take a practical, data-centric approach to post-quantum readiness. Supported PQC capabilities protect selected management, authentication, and replication workflows, while established AES-256 controls continue to protect data at rest. Together, these controls support a layered strategy for safeguarding the data layer where mission information ultimately resides. NetApp delivers these capabilities through ONTAP software updates at no additional cost for new and existing customers, enabling agencies to prepare for the post-quantum era today - without waiting for a rip-and-replace cycle tomorrow.

The Data Layer Should Be Part of Every PQC Roadmap

Most discussions about post-quantum cryptography focus on networks, applications, and PKI. Federal agencies must also evaluate the infrastructure where mission data is stored, protected, replicated, and recovered.

As agencies build their post-quantum roadmaps, they should ask whether their data infrastructure can:

• Protect long-lived mission data from harvest-now-decrypt-later threats.
• Support evolving quantum-resistant standards.
• Adapt to future cryptographic requirements through software-driven crypto-agility.
• Enable modernization without disrupting ongoing operations.

The agencies that prepare their data layer today will be better positioned to secure mission outcomes tomorrow.

When connecting (Connect-NcController) my ontap arrays, it can take around 40 seconds to connect to our main one.  When I connect to my others ones, it takes around 3-5 seconds.

I get no errors, so I am not sure why this is. Is it simply because our main array is busy and API connections have a lower priority?

I am running PowerShell 7.6.3 with NetApp.ONTAP module version 9.18.1.26.

NetApp and Veeam have a long-standing partnership focused on data protection innovation, and Veeam Backup & Replication (VBR) – part of Veeam’s Data Platform (VDP) – is a leading solution for enterprise data resilience.

The integration between NetApp and Veeam provides faster, more efficient data resilience with almost no impact on your production environment. This allows you to dramatically improve the RPO and RTO for your applications and more effectively protect them against evolving threats.

Now, NetApp and Veeam are taking things to the next level with a new NetApp plug-in developed using Veeam’s Universal Storage API framework.

Figure 1) NetApp USAPI plug-in for Veeam

New and improved integration

The NetApp USAPI plug-in with Veeam delivers more efficient and advanced ONTAP integration. The plug-in improves on Veeam’s native ONTAP integration by enabling more streamlined and efficient data protection workflows. The plug-in also delivers new features, functionality and platform support to help make backup and recovery more secure and resilient. The plug-in allows both NetApp and Veeam to innovate faster, and it reduces the time to value for new feature releases in both ONTAP and VBR. Here are some key benefits that the NetApp USAPI plug-in delivers:

• Storage Snapshot Backups – create and manage ONTAP snapshots directly in the VBR console and use ONTAP snapshots to drastically reduce system overhead when protecting VM workloads
• Resiliency and DR – take advantage of ONTAP’s SnapMirror optimized replication feature that can be managed directly in VBR to replicate snapshots between clusters for maximum resiliency, security and recoverability
• Data Immutability – Veeam protects VMs using NetApp tamperproof snapshots that help keep data safe against malware and unauthorized deletion

How it works

Configuring VBR to use the NetApp USAPI plug-in is done via the same simple and user-friendly process you’ve come to expect from Veeam. You can download and install the plug-in directly from the VBR user interface. Then, you can easily connect your NetApp storage to VBR using the Add Storage wizard.

Figure 2) Add NetApp storage in VBR with the NetApp USAPI plug-in

Once your NetApp ONTAP storage systems are connected to VBR, you can browse the storage in the VBR storage explorer. You can rescan a storage system or specific volume, and you can create storage snapshots directly in VBR without the need to switch interfaces.

Figure 3) Browse the connected NetApp storage directly in VBR

You can create new VMware backup jobs that use ONTAP snapshots and snapshot replication (SnapMirror) the same way you’ve always done it with VBR. Simply create a backup job and select the appropriate NetApp plug-in workflow in the job creation wizard, fill in the details, and you’re all set.

Figure 4) VBR backup for VMware vSphere using the NetApp USAPI plug-in

Functionality

Veeam backup from ONTAP snapshots (BfSS) significantly improves system performance by offloading backup processing from production systems, which nearly eliminates the performance degradation (known as VM stun) that can happen with VMware backups.

Figure 5) Improve VM performance with VBR backup from ONTAP snapshots

VBR can create additional backup copies to off-cluster targets – including NetApp StorageGRID – which can be made immutable for additional protection against malware and accidental or malicious deletion. This provides a robust 3-2-1-1 backup strategy.

VBR can orchestrate snapshot replication in ONTAP, with new functionality delivered by the plug-in:

• VBR automatically detects SnapMirror asynchronous and synchronous relationships in ONTAP and coordinates updates
• Use SnapMirror async or sync replication targets as the source for Veeam BfSS jobs

The plug-in also delivers new snapshot immutability functionality that is key for building the most secure data protection solution possible:

• Make snapshots immutable in VBR using ONTAP’s tamperproof snapshot feature
• Use ONTAP tamperproof snapshots in a VBR data lab environment

With ONTAP tamperproof snapshots, VBR’s anomaly detection and threat hunter security features, you can create a unique cyber vault backup solution that will keep your data protected against ransomware and other malware threats.

Figure 6) Protect data against ransomware using ONTAP tamperproof snapshots

Feature and Platform Support

The NetApp plug-in for VBR is supported with VBR 13.1 and beyond, and it supports a broad range of ONTAP platforms: FAS, AFF, ASA and ASA r2.

The plug-in will support the following Veeam workflows:

• Snapshot management
• Snapshot replication
• Snapshot immutability
• Snapshot archiving will be available soon in a future VBR release

The existing Veeam native ONTAP integration delivers efficient data protection for VMware, with support for:

• ONTAP snapshots
• SnapVault
• SnapMirror asynchronous

The NetApp plug-in for VBR supports all the above features available in the Veeam native ONTAP integration. In addition, the plug-in adds support for several new ONTAP features and configurations:

• Tamperproof snapshots
• SnapMirror synchronous
• MetroCluster
• SVM-DR
• SnapMirror active sync

The plug-in is supported with all currently supported versions of ONTAP. It can be downloaded here. The release notes can be seen here.

Summary

NetApp and Veeam continue to jointly innovate to improve and simplify the data protection experience. The NetApp plug-in for VBR enables faster innovation and time to value for new features and NetApp storage platforms. This makes data resilience more efficient and more secure.

Stay tuned for upcoming announcements about how NetApp and Veeam are working together to deliver the most advanced solutions for on premises, cloud, and Kubernetes data protection and resilience.

As organizations move from AI experimentation to production-scale deployments, the attack surface expands dramatically. Large language models, AI agents, vector databases, training datasets, and inference pipelines all rely on one critical asset: data. If data is compromised, manipulated, encrypted, or exposed, the value of AI quickly disappears.

This is why theNetApp AI Security Framework is built upon a Data-Centric Zero Trust Architecture with three foundational pillars: Hardening, Detection & Response, and Recovery. Together, these pillars provide a comprehensive approach to protecting AI workloads from cyber threats while ensuring business continuity.

Foundation: Data-Centric Zero Trust

Traditional security approaches focus on securing infrastructure and networks. AI environments require a different mindset because data moves across on-premises systems, clouds, AI pipelines, agents, and model repositories.

The NetApp AI Security Framework embraces three core Zero Trust principles:

• Assign least-privilege access
• Assume breach
• Never trust, always verify

By placing data at the center of security strategy, organizations can protect AI workloads throughout their lifecycle, from training and fine-tuning to inferencing and retrieval-augmented generation (RAG).

Pillar 1: Hardening

The first step in AI security is reducing the attack surface before threats occur. NetApp hardening capabilities are designed to prevent unauthorized access and ensure that only trusted users, applications, and AI agents can interact with sensitive data.

Key capabilities include:

• Multi-Admin Verification (MAV) to prevent malicious or accidental administrative changes
• Storage Multi-Tenancy (SMT) to isolate workloads and datasets
• Data Classification to identify and govern sensitive information
• Role-Based Access Control (RBAC) for permission enforcement
• OAuth 2.0 Integration for secure identity-based access
• Attribute-Based Access Control (ABAC) for granular authorization
• Encryption for protecting data both at rest and in transit

These controls help establish a secure foundation for AI environments while ensuring compliance and governance requirements are met.

Pillar 2: Detection & Response

Even the most secure environment must assume an attacker may eventually gain access. The second pillar focuses on rapidly detecting anomalies and automating responses before significant damage occurs.

Key capabilities include:

• Autonomous Ransomware Protection (ARP) for AI-driven threat detection
• File Policy Analytics (FPolicy) for monitoring suspicious activity
• SIEM and SOAR Integrations for enterprise-wide visibility and orchestration
• Comprehensive Auditing for compliance and forensic investigations
• Ransomware Resilience capabilities that minimize business impact
• Data Infrastructure Insights (DII) and Storage Workload Security (SWS) for behavioral analytics and real-time monitoring

This pillar provides continuous visibility into user behavior, data access patterns, and emerging threats, enabling security teams to react quickly and confidently.

Pillar 3: Recovery

Cyber resilience is ultimately measured by how quickly an organization can recover from an attack. AI environments often contain irreplaceable datasets, vector embeddings, and model artifacts that must be restored rapidly and accurately.

NetApp delivers multiple layers of recovery protection:

• SnapLock® for immutable data protection
• Tamperproof Snapshots (TPS) for secure point-in-time recovery
• NetApp Cyber Vault for isolated recovery environments
• Commvault Integration for enterprise backup and recovery
• Commvault + ARP for enhanced ransomware remediation
• Rapid Recovery and Clean Restore capabilities to restore trusted data quickly

These technologies help ensure that organizations can recover AI environments with confidence while minimizing downtime and operational disruption.

Security That Enables AI Innovation

AI adoption should not force organizations to choose between innovation and security. By combining proactive hardening, intelligent threat detection, and rapid recovery capabilities, the NetApp AI Security Framework provides a comprehensive strategy for protecting the data that powers modern AI.

The result is a security architecture that helps organizations confidently deploy AI agents, train models, build RAG applications, and scale generative AI initiatives while maintaining control over their most valuable asset: their data.

In the age of AI, security is no longer just about protecting infrastructure. It is about protecting the data that fuels intelligence. That's exactly what the NetApp AI Security Framework is designed to do.

To finish, here is a summarized view of the Security Framework

We find ourselves in the 6th month of the year, so it is time to think about what is happening in calendar Q3 - one of the data collection projects we will be kicking off is research into the possibility of adding Proxmox virtualization support to DII. 

If you would be interested in Proxmox support in DII, drop me a note at ostiguy at netapp dot com . Please let me know what protocols and storage vendors you are using with Proxmox.

Thanks

Matt

Edge locations have quietly become some of the most data-intensive places in the enterprise. Point-of-sale systems, factory-floor sensors, security cameras, and clinical devices are generating volumes of data that needs to be captured, processed, and protected close to where they originate often with no IT staff on-site and no room for a rack full of disparate point products. That's the gap this NVA is built to close with a proven infrastructure that's compact enough for a closet or cabinet without asking customers to sacrifice the resiliency, security, or manageability they expect from the core data center.

FlexPod Edge is the edge-optimized variant of the broader FlexPod converged infrastructure family that NetApp and Cisco have co-engineered for more than seventeen years. Rather than shrinking a data center rack and hoping it fits, FlexPod Edge is purpose-designed around the real constraints of remote sites: limited power and cooling, little to no local IT expertise, and a need for centralized, remote management at scale across hundreds of locations.

The architecture is built on Cisco Unified Edge, which consolidates compute and networking into an integrated platform sized for space and power constrained environments. Because it's managed through Cisco Intersight, IT teams get the same cloud-based operational visibility and lifecycle management they use for core infrastructure without needing hands-on-keyboard support at every site.

Rather than treating edge storage as a bare-bones storage tier, FlexPod Edge extends full ONTAP data services out to the edge by using NetApp FAS or AFF arrays.

• Snapshot copies for fast, space-efficient local recovery
• SnapMirror replication back to core data centers or the cloud for disaster recovery and centralized backup
• FlexCache speeds up data access and cuts WAN costs for local read-heavy applications
• Inline deduplication and compression to shrink the physical footprint at cost- and space-sensitive sites
• Autonomous Ransomware Protection to detect and contain anomalous encryption behavior before it spreads.

Managed centrally through NetApp Console, these capabilities let a centralized IT team operate hundreds of edge sites with data protection policies as consistent as anything in the core data center. In each case, the requirement to process and protect data locally, without giving up the visibility and governance IT needs across the whole fleet.

As with all NetApp Verified Architectures, this whitepaper is the output of joint engineering work between NetApp and Cisco. The teams designed, deployed, and tested the reference architecture in a lab environment, network and storage configuration details, and deployment best practices so field teams and customers can implement it with a predictable outcome rather than DIYing a design from scratch. Full technical details, bill of materials, and validated configuration steps are available in the published NVA.

Customers and partners evaluating an edge infrastructure refresh or standing up edge sites for the first time should start with the NVA, then loop in their NetApp and Cisco account teams to size the specific deployment. For organizations already running FlexPod in the core data center, FlexPod Edge offers a way to extend that same operating model, and the same data services, all the way out to the edge.

We are using the NetApp Shift Toolkit as part of a VM migration project (from VMware to Proxmox).

I noticed that there are several “DRO” (Disaster Recovery Orchestrator) snapshots on the volumes. From my understanding, these are related to the Shift Toolkit, which creates a volume snapshot before converting the disks. It then creates a clone (FlexClone) to convert the disk format from .vmdk to .qcow2, without modifying the original virtual machine.

These snapshots are consuming a significant amount of storage space (more than 18 TB! on flash array for few tests). I assume they are temporary and expected to be automatically cleaned up.

Is it possible that some blueprints were not executed successfully and that the snapshots were therefore not properly cleaned up?

Are these snapshots intended to provide a rollback mechanism, allowing us to revert to the original VM running on VMware?

Could you please confirm whether my understanding is correct, and let us know whether these snapshots can be safely deleted when there is no migration process currently in progress?

Thank you in advance for your clarification.

Best regards,

Google Cloud NetApp Volumes Flex Unified is now Broadcom certified as external storage for Google Cloud VMware Engine (GCVE) and ESXi z3 baremetal deployments, available in every Google Cloud VMware Engine region. VMware teams now have a validated storage architecture that combines enterprise-class storage capabilities with the operational simplicity of a fully managed first party Google Cloud service.

In this blog, we will examine how Google Cloud NetApp Volumes Flex Unified enables VMware teams to go beyond traditional cluster attached storage. You will learn how certified external storage can help simplify disaster recovery, reduce infrastructure costs, leverage enterprise data services such as snapshots and replication, decouple storage from compute lifecycles, support both NFS and block workloads, and scale capacity and performance independently as VMware environments grow.

More than a Certification

Google Cloud NetApp Volumes Flex Unified solves some of the most common storage challenges VMware teams face. It enables them to: 

• Scale: Scale storage independently of ESXi host count
• Protect workloads: Apply enterprise data services such as snapshots, clones, and replication at the storage layer without impacting performance
• Disaster Recovery: Design efficient disaster recovery environments without mirroring production compute resources
• Reduce costs: control the cost of inactive data as workloads grow through automatic tiering
• Maintain separation: separate storage lifecycles from compute lifecycles
• Deploy multi protocol: Support both file(NFS) and block-based(iSCSI, NVMe/TCP) VMware workloads from a single managed storage platform
• Migrate: Avoid disruptive migrations as infrastructure evolves.

For organizations deploying Google Cloud VMware Engine infrastructure, Google Cloud NetApp Volumes Flex Unified provides a certified storage foundation that aligns infrastructure growth with workload requirements instead of cluster constraints.

Certified for Production VMware Deployments

For VMware platform teams, certification is often the final validation step before a technology enters production. External storage that has not been validated against the platform introduces risk that most organizations are unwilling to accept for business critical workloads.

Google Cloud NetApp Volumes Flex Unified is listed in the Broadcom Compatibility Guide as a certified external storage for Google Cloud VMware Engine, providing a validated architecture for attaching NetApp storage to VMware private clouds running on Google Cloud.

With qualification across GCVE and ESXi z3 baremetal deployments, customers can confidently deploy Google Cloud NetApp Volumes Flex Unified in both existing and new environments without waiting for additional storage qualification cycles.

Availability in every Google Cloud region where VMware Engine operates completes the architecture. The same storage design can be applied consistently across regions, which simplifies standardization for organizations operating multiple private clouds or planning geographically distributed deployments.

Enterprise Data Services at the Storage Layer

Organizations are frequently limited on their recovery point frequency due to the operational impact.  Host-level protection approaches compete with production workloads for resources, forcing administrators to balance recovery objectives against application performance. Google Cloud NetApp Volumes shifts protection to the storage layer through storage-side snapshots that avoid placing additional I/O burden on production virtual machines. This allows you to decrease your recovery point objective all  while maintaining application performance. VMware environments with GCNV benefit from  enterprise data services, including:

• Snapshots for rapid, low-impact recovery points
• Instant Clones for fast provisioning of test, development, refreshes and investigations.
• Integrated backups for long-term data protection, with support for both in-region and cross-region backups
• Replication for cross-region disaster recovery and business continuity
• Encryption with Google Cloud KMS managed as part of the NetApp Volumes security model

All these capabilities are delivered as a fully managed service. There is no storage infrastructure to procure, deploy, patch, or refresh.

Simplified Disaster Recovery

Because legacy storage is typically bound to the production cluster, traditional disaster recovery solutions often require maintaining a similarly sized standby compute environment, increasing infrastructure costs and complexity.

Google Cloud NetApp Volumes decouples storage from compute, enabling a more efficient disaster recovery design. Organizations can maintain a smaller standby Google Cloud VMware Engine cluster while replicating data with NetApp Volumes replication and scaling storage independently. This allows recovery environments storage to be sized around RPO and RTO requirements, reducing infrastructure costs by eliminating the need to mirror production compute resources.

Storage Lifecycle Independent of Compute Lifecycle

One of the most significant benefits of external storage in Google Cloud VMware Engine is the ability to separate storage lifecycles from compute lifecycles.

Many organizations carefully plan capacity, protection, and recovery strategies, only to discover later that cluster-local storage has tied their data lifecycle to node maintenance schedules, infrastructure refreshes, and platform transitions.

When storage resides within the VMware cluster, infrastructure events often become storage events:

• Node maintenance can impact storage operations
• Hardware refreshes can introduce migration projects
• New node generations may require datastore transitions
• Cluster growth can trigger storage redesign efforts

Google Cloud NetApp Volumes helps decouple storage from those infrastructure changes:

• Node maintenance does not require storage migrations
• Node generation transitions become datastore attachment decisions rather than large-scale migration projects
• Datastores persist independently of cluster growth and host refresh cycles

This separation enables VMware teams to manage storage and compute as independent resources, reducing operational complexity and long-term risk.

Optimize VMware storage costs with Auto-Tiering

Not all data in a VMware estate is active. Content libraries, images, archives, logging and telemetry data, backup targets, and aging virtual machine disks typically account for a significant portion of consumed capacity while being accessed infrequently. In most environments, this inactive data occupies the same storage tier as production data, and cost scales accordingly.

Google Cloud NetApp Volumes addresses this with automatic tiering. Infrequently accessed data is moved to a lower-cost storage tier automatically, based on access patterns, without administrative intervention.

For VMware architects, this delivers value in several ways:

• Cost follows actual usage. Capacity that is no longer active does not continue to consume premium storage economics.
• No workload redesign is required. Virtual machines continue to use the same datastore. Data placement is handled by the storage service, not by Storage vMotion campaigns or secondary archive datastores.
• High-capacity estates remain manageable. Archives, backup targets, and content repositories can grow on a single volume while long-term cost is optimized in the background.
• Operational overhead is reduced. There is no separate archival process, tiering policy engine, or data movement project to maintain.

Auto-tiering is most valuable for workloads with large capacity footprints and relaxed performance and latency requirements for the inactive portion of the dataset. Performance-sensitive virtual machines continue to operate on the storage tier appropriate to their requirements, while the cost of cold data is optimized automatically.

The result is a storage model where capacity growth does not translate directly into proportional cost growth; an important consideration as VMware estates expand in Google Cloud.

One Storage Platform for NFS and Block Workloads

Most VMware estates contain a mix of workload types and storage requirements. Google Cloud NetApp Volumes Flex Unified supports both NFS datastores and VMFS datastores for Google Cloud VMware Engine, with NFS, iSCSI, and NVMe/TCP.

Google Cloud NetApp Volumes Flex Unified provides a unified storage platform that supports:

The same storage pool can also serve file and block workloads outside VMware. Consolidating on a single platform simplifies architecture, procurement, and ongoing operations compared with maintaining separate storage services for file and block requirements.

Scale Capacity and Performance Independently

In many environments, storage growth drives infrastructure purchases that are unrelated to actual workload needs causing higher costs. However, Google Cloud NetApp Volumes allows capacity, performance, and compute resources to scale independently which eliminates this dependency. That means:

• A 200 TB workload does not need premium performance pricing if it doesn't require high IOPS.
• Performance increases do not require capacity purchases.
• Capacity growth does not require additional ESXi hosts.

This flexibility helps VMware teams align spending with actual workload requirements rather than infrastructure design limitations.

Key use cases include:

• High-capacity environments such as backup repositories, archives, content libraries, and telemetry data.
• Supplemental capacity for migrations, temporary projects, and datastore expansion.
• Development and test environments that require cost-efficient storage without sacrificing management capabilities.

Why choose Google Cloud NetApp Volumes

VMware workloads on Google Cloud no longer need to accept the traditional trade-offs between storage functionality, scalability, and operational simplicity.

With Google Cloud NetApp Volumes Flex Unified, organizations can:

• Take frequent storage-based snapshots without impacting production VMs.
• Leverage ONTAP data services including snapshots, clones, and replication.
• Maintain storage independently of node maintenance and hardware refresh cycles.
• Design disaster recovery around recovery objectives instead of mirrored production infrastructure.
• Support both NFS and VMFS datastore requirements.
• Integrate encryption with Google Cloud KMS.
• Scale capacity and performance independently of ESXi node count.
• Deploy on Broadcom-certified storage qualified for GCVE  and ESXi z3 baremetal configurations.

For VMware teams planning disaster recovery initiatives, expanding datastore capacity, supporting storage-intensive applications, or simplifying long-term infrastructure operations, Google Cloud NetApp Volumes provides a modern storage architecture for Google Cloud VMware Engine.

Get Started

Google Cloud NetApp Volumes Flex Unified is generally available as Broadcom-certified external storage for Google Cloud VMware Engine in every supported Google Cloud region.

The fastest way to evaluate the service is to start with a single workload:

• A snapshot-sensitive datastore
• A disaster recovery replica
• A capacity-intensive dataset
• A supplemental datastore for cluster expansion

Measure the results in terms of recovery point frequency, operational effort, storage utilization, and ESXi node requirements.

To learn more:

• Review the Broadcom Compatibility Guide certification listing
• Follow the deployment guide for Google Cloud NetApp Volumes datastores on Google Cloud VMware Engine
• Explore the Google Cloud NetApp Volumes documentation
• Engage your Google Cloud or NetApp team for architecture and sizing guidance

For VMware architects looking to modernize storage operations while preserving enterprise data services, Google Cloud NetApp Volumes Flex Unified delivers a certified, scalable, and operationally efficient storage foundation for Google Cloud VMware Engine.

AWS Transform, the service that uses agentic AI to accelerate cloud migrations, now supports Amazon FSx for NetApp ONTAP as a storage target for block storage migration to the Amazon Web Services (AWS) Cloud. It introduces a direct migration path, eliminating the multi-step workarounds that previously added cost, time, and risk.  

In this post we cover: 

​​ 

• ​Background: migrating block-based workloads before AWS Transform 
• ​How AWS Transform simplifies migration 
• ​Unified migration flow for compute and block storage 
• ​How FSx for ONTAP supports day-2 operations  
• ​Impact on modernization projects 
• ​Summary and next steps 

​​ 

Background: migrating block-based workloads before AWS Transform 

Enterprise workloads that utilize block storage typically have well‑defined requirements around performance consistency, data protection, security, and rich data management capabilities. In on‑premises environments, these expectations are met through enterprise storage platforms that provide capabilities such as fast backup and recovery, data replication, and security controls. 

As organizations move enterprise workloads to AWS, preserving the storage capabilities those workloads depend on becomes an increasingly important consideration.   

This is where FSx for ONTAP comes in. FSx for ONTAP is a fully managed storage service that’s built on NetApp’s popular ONTAP storage software to deliver enterprise‑grade storage capabilities that enterprise workloads need to operate effectively on AWS. 

Despite the strong fit, moving data to FSx for ONTAP often required migration teams to plan storage separately from compute, relying on a two-step migration flow, or using third-party tools.   

How AWS Transform simplifies migration  

AWS Transform is designed to help organizations plan and execute complete resource migration to the AWS Cloud using AI‑assisted workflows.  AWS Transform applies intelligence to analyze environments, generate migration insights, and orchestrate execution across large-scale modernization initiatives. 

AWS Transform brings together the following two distinct but related capabilities under a single service: 

Assessment capabilities 
The assessment functionality analyzes existing environments to identify application dependencies, infrastructure characteristics, and modernization readiness. This AI‑powered assessment helps teams prioritize workloads and build informed migration plans. 

Migration capabilities 
AWS Transform coordinates workload migration to AWS through automated workflows that now support  FSx for ONTAP as a storage target.  Customers familiar with AWS Application Migration Service (MGN),  now part of AWS Transform, can replicate block storage data directly to FSx for ONTAP  as well. 

Unified migration flow for compute and block storage  

The migration flow is streamlined into a single migration motion, eliminating the need for separate migration steps or tools: 

Source workloads → AWS Transform migration → Amazon EC2 with FSx for ONTAP 

AWS Transform handles more than replication. After a migration wave is configured and FSx for ONTAP is selected as the storage target, AWS Transform continuously replicates block storage data to FSx for ONTAP LUNs while source applications remain online. 

For testing and cutover, AWS Transform launches the target Amazon EC2 instances, connects the migrated FSx for ONTAP LUNs over iSCSI, and enables validation before final cutover. This creates a more unified motion for migration teams and a cleaner path to production. 

This is particularly relevant for VMware environments, where virtual machines run on  Virtual Machine File System (VMFS) datastores backed by block LUNs or on NFS datastores. Because AWS Transform replicates from an agent inside each virtual machine at the guest operating system level, the source array and protocol don't constrain the target. Whether vSphere sits on NetApp® or on a third-party array, data volumes can land on FSx for ONTAP as iSCSI LUNs, with the OS boot volume on Amazon EBS.

AWS Transform also provides flexibility. Teams can define a default storage target for a migration wave and override that choice at the individual server level. This supports workloads to continue landing on Amazon Elastic Block Store (Amazon EBS), while workloads that benefit from ONTAP‑specific capabilities can land directly on FSx for ONTAP. 

The following diagram illustrates the AWS Transform VMware migration with FSx for ONTAP as the storage target: 

How FSx for ONTAP supports day-2 operations  

After migration, the focus shifts from moving workloads to operating them in AWS. For block-based VMware and database workloads, that includes backup and restore, recovery testing, DevTest refreshes, replication, and business continuity planning.  The storage layer influences how much of that operating model can remain consistent.  

FSx for ONTAP can help teams maintain familiar storage operations in AWS by providing ONTAP capabilities such as snapshot based protection, efficient data copies, replication, encryption, and ransomware protection. 

Because AWS Transform can now migrate data directly to FSx for ONTAP, teams can continue using ONTAP-based storage workflows after cutover instead of redesigning those processes separately. This is especially valuable for organizations already using ONTAP, where existing operational practices can carry forward into AWS with less change. 

Impact on modernization projects 

For infrastructure managers and IT professionals, this release simplifies migration planning. When compute, network, and block storage move together in one coordinated workflow, there are fewer moving parts to align across teams and fewer opportunities for storage to become a late‑stage bottleneck. 

For modernization project leads, it reduces architectural compromise. Teams no longer need to choose between using AWS Transform for the primary migration workflow and using a separate approach to land block workloads on FSx for ONTAP. The migration process can better reflect the intended steady‑state architecture from day one. 

For VMware administrators, this creates a cleaner route to move workloads to Amazon EC2, while preserving the block storage semantics that environments depend on. At a time when many organizations are reexamining their VMware strategy, this can help reduce friction between planning and execution. 

For database and application owners, it means fewer tool transitions and a more consistent operational model after cutover. Business‑critical block workloads such as Microsoft SQL Server, Oracle, and IBM DB2 can move to AWS while continuing to benefit from the data management, storage efficiency, and protection capabilities available in ONTAP. 

For teams with mixed storage environments, AWS Transform provides the migration for block-based workloads, while AWS DataSync remains the recommended service for file storage migrations. Together, these services provide a complete migration strategy for complex enterprise estates. 

Summary and next steps 

With support for FSx for ONTAP as a storage target, AWS Transform now offers a more complete path for enterprise block workload migrations. Customers can move block workloads to Amazon EC2 with direct access to managed ONTAP storage in the AWS Cloud, without intermediate steps or third-party tooling. 

For organizations migrating block‑based applications, this release simplifies migration design, broadens storage destination choice, and supports day-2 operations in AWS. 

Next, read the AWS Transform announcement and review the AWS storage blog for practical guidance on Migrating VMware Storage to FSx for ONTAP  using AWS Transform. 

Plugin Output:

 Path              : /data/netapp-manageability-sdk-9.8P10/zedi/zexplore.jar

 Installed version : 2.19.0

 Fixed version     : 2.25.5

 Path              : /data/netapp-manageability-sdk-9.8P10/lib/java/classes/manageontap-9.8P10.jar

 Installed version : 2.19.0

 Fixed version     : 2.25.5

Description:

The version of Apache Log4j on the remote host is affected by a vulnerability:

• Improper encoding of non-finite floating-point values during MapMessage JSON serialization in Apache Log4j API produces output that is not valid JSON. When a MapMessage contains a non-finite IEEE 754 value (NaN, Infinity, or -Infinity), MapMessage.asJson() emits the corresponding bare token. RFC 8259 does not permit these tokens, so a conformant parser rejects the resulting document. An attacker who can supply a non-finite value can cause the affected layout to emit malformed JSON, which may corrupt the enclosing log record or disrupt downstream log ingestion and parsing. (CVE-2026-49844)

Note that Nessus has not tested this issue but has instead relied only on the application's self-reported version number.

Can someone please provide more details to remediate this issue and way to fix whether we should upgrade SDk to 9.8P12 and it iwll include latest updated .jar file?

For years, zero recovery point objective (RPO) for NAS workloads has been achieved through synchronous replication, but achieving zero recovery time objective (RTO) has been a major bottleneck to achieving business continuity. Although synchronous copies of data were available, accessing those copies when needed required scripting, disruptive cutover procedures, and manual interventions.

SnapMirror active sync changed the game for SAN by offering zero RPO and zero RTO for block workloads. With ONTAP 9.19.1, that same synchronous replication with automated failover capability extends to NAS workloads, like NFS and SMB. This type of NAS data is often equally mission‑critical as SAN, but transparent failover was out of reach. If you run mission-critical file workloads on AFF or AFX, this release is worth a closer look.

In this post, you will see the gap SM-as NAS closes, how replication and failover behave under the hood, and where it fits next to other solutions offered by NetApp.

The problem: Business continuity for NAS lagged behind SAN

SnapMirror active sync has delivered zero-RPO, zero-RTO failover for SAN workloads for some time. Critical NAS data, like finance ledgers on SMB, Oracle or virtualization workloads on NFS, custom financial small file workloads, and mixed-protocol departmental shares, was also subject to strict regulatory and operational compliance requirements. The DR options for those workloads included MetroCluster for site-wide protection, using SnapMirror synchronous replication with a manual failover process, or simpler SVM-DR that could deliver a low RPO, but not zero RPO.

Those options involved trade-offs:

1. MetroCluster excels when you need infrastructure-level, site-wide continuity. Still, it comes with architecture and operational constraints that not every file workload can tolerate, and it does not offer the granularity of SnapMirror active sync.
2. SVM-DR is approachable for whole-SVM protection, yet asynchronous replication means data loss is possible at failover, and recovery is operator-driven.
3. SM-as proved synchronous replication plus automated failover could work at metro distances, but NAS was out of scope until now.

Before 9.19.1, zero data loss and transparent application failover for these critical NAS workloads was offered with MetroCluster. Without it, customers had to compromise with disruptive procedures, RPO trade-offs, or SAN-only active sync while file services waited. From 9.19.1, critical FlexVol data within SVMs can be protected with zero-RPO, zero-RTO with transparent application failover, leveraging proven SnapMirror and SnapMirror active-sync technologies.

What’s new in ONTAP 9.19.1

SnapMirror active sync for NAS ships in ONTAP 9.19.1 and later. Supported platforms are AFF and AFX.

Table 1: SnapMirror active sync NAS vs SAN

Note: Although the failover in SMB 2.x / SMB 3.x versions and non-CA shares is disruptive (remount/restart apps), the zero RPO for data is still maintained. This is a protocol limitation and not under the control of SnapMirror active sync.

Unlike SM-as SAN, NAS does not offer active-active client I/O on both sides of the same protected SVM during normal operation. The secondary SVM remains dormant until failover or planned failover.

How it works: architecture overview

1. Synchronous data replication: Protected FlexVol volumes in an SVM replicate data synchronously to the partner cluster. Writes are acknowledged to clients only after commit on both sides, which delivers zero RPO for protected volumes.

2. Configuration Replication Service (CRS): SVM configuration, i.e., LIF definitions, exports, shares, quota configuration, and related settings, are replicated so the secondary can assume the identity of the primary SVM during failover. Identity discard is not supported. You must plan your network environment carefully for matching network design on both sites.

3. ONTAP Mediator: The Mediator (on-premises Linux VM or NetApp Console hosted) is required. It provides quorum for cluster health decisions, enables automated failover, and helps prevent split-brain by ensuring only one site serves a given protected SVM relationship.

Figure 1: SnapMirror active sync NAS

Secondary SVM behavior

Failover does not rely on traditional LIF migration in the sense of moving addresses you never pre-staged. The CRS-replicated LIFs already exist on the secondary and transition to operational up/up on their home nodes.

Table 2: Secondary SVM behaviour

Granularity

Protection is SVM-scoped, but you can include or exclude individual volumes when creating the relationship, or when adding volumes later. You can seamlessly add or remove volumes from the SM-as relationship as and when the SLA changes. It does not delete the volumes or the data inside them; instead, internally, volume membership changes trigger a geometry expand or shrink operation.

Figure 2: Granularity of protection

Co-existence

SnapMirror active sync for SAN and NAS can run on the same cluster. It also allows protected and unprotected SVMs to coexist. To protect a NAS SVM with SnapMirror active sync, the SVM must be dedicated to NAS workloads and must not host SAN or object (S3) protocols.

Figure 3: Co-existence of SVMs

Async fan-out

SnapMirror active sync for NAS solves metro-distance, zero-RPO continuity between two sites. Many customers also require a 3-way DR solution with a third location, a remote vault, or a recovery region with asynchronous replication and different RPO/RTO expectations. In ONTAP 9.19.1, SM-as NAS supports volume-level async fan-out with one additional SnapMirror async leg per protected volume, layered on top of the synchronous SM-as relationship.

Figure 4: SnapMirror async fanout

Key benefits

• Zero-RPO: Synchronous replication for protected NAS FlexVols. No application data loss at failover for in-scope protocols.
• Zero-RTO with automated failover.
• Transparent failover where protocols allow, i.e., NFS and SMB3 CA clients can reconnect with no disruption.
• Granular, workload-level protection. Protect critical SVMs (or subsets of volumes within an SVM) without committing the entire cluster to a single DR model.
• Granular workload failover: Selectively fail over individual tenants, departments, or applications at SVM level without impacting the rest of the cluster. This enables targeted DR testing, non‑disruptive maintenance, phased migrations, and even active load balancing between sites.
• Unified operations story: Manage relationships through ONTAP System Manager alongside SM-as SAN; one ONTAP skillset for block and file metro continuity.
• Secondary copy utility: Cross-SVM FlexClone on the destination supports test/dev, analytics, and DR validation without impacting primary I/O.
• Cost-efficient metro DR: Uses a standard inter-cluster network without dedicated replication switches.

Use cases

• Enterprise file services with strict RPO/RTO requirements:
  Departmental or business-specific SVMs that must survive site loss without replaying hours of file changes, especially where audit or compliance treats file data like tier-1 applications.
• Financial services and healthcare:
  Workloads that already demanded sync block DR can now align selected NAS tiers (e.g., document repositories, imaging interfaces on NFS, SMB CA–enabled application shares) to the same business continuity requirements provided protocol choices match non-disruptive vs disruptive failover expectations.
• Manufacturing and design collaboration:
  Project shares that need metro-distance protection and predictable failover without rebuilding every mount point.
• Service providers and multi-tenant clusters:
  SVM-level failover independence allows a protected SVM to fail over without forcing unrelated SVMs on the same cluster into the same event. This helps service providers and multi-tenant environments meet client-specific compliance or regulatory requirements by enabling workloads to run from the secondary cluster when needed. After failover, client access to protected volumes is served from the secondary cluster, providing greater flexibility in where data is accessed and hosted.
• Phased Site Migration & Active Load Balancing
  Gradually transition operations from one data center to another on an SVM-by-SVM basis for lower-risk migrations. Distribute active workloads optimally by running some enterprise applications on Site A and others on Site B, while protecting both.

Considerations and limitations

• Treat SM-as NAS as workload-granular continuity, not a wholesale MetroCluster replacement. MetroCluster remains the answer when you need site-wide, infrastructure-level protection.
• Scale (per HA pair): up to 50 NAS SVMs (combined with SAN CGs: 50 (SVMs + CGs) total), 400 volumes, 80 volumes per SVM, 16 LIFs per SVM.
• Replication topology: Two-way SM-as (each cluster hosts independent protected SVMs for the other) is supported to optimize infrastructure utilization.
• Auto reconfiguration of asynchronous replication fan-out leg, SVM-granular async fan-out, and cascade replication is not supported with SnapMirror active sync for NAS in the first release.

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. 

Figure 1: Symmetric Active-Active SAN pathing on NetApp AFF

Modern enterprise SAN environments cannot tolerate downtime. Mission‑critical databases and large‑scale VMware deployments demand continuous availability and predictable I/O behavior, with little tolerance for controller failovers or path transition delays. At the same time, organizations are under pressure to consolidate workloads onto fewer platforms without sacrificing resilience.

NetApp addresses this challenge by extending symmetric active-active SAN pathing to NetApp AFF systems with ONTAP 9.19.1, bringing the same nondisruptive SAN access model that customers value on NetApp ASA into NetApp’s unified all-flash portfolio. For AFF, this capability enables simultaneous, active-optimized access across both nodes in an HA pair, helping mission-critical SAN applications maintain continuous availability and predictable I/O behavior while running alongside NAS and other workloads on a single, proven ONTAP platform.

This extension does not blur the lines between AFF and ASA; it sharpens the role of each platform. AFF is the right choice when customers want to consolidate mission-critical SAN, NAS, and mixed enterprise workloads with shared ONTAP services, cloud mobility, and operational consistency across protocols. ASA remains NetApp’s purpose-built, block-only SAN platform, optimized for customers that want a simplified SAN experience while sustaining predictable performance and efficiency. Together, AFF and ASA give customers two strong architectural choices: unified consolidation where flexibility matters most, and dedicated block simplicity where a SAN-only operating model is a priority.

Unified Workload Centralization on NetApp AFF

Active-active architecture moves AFF closer to true mission-critical centralization. Customers can run demanding block workloads alongside file and object services on one ONTAP foundation, providing consistent availability, protection, mobility, and management across on-premises and the cloud. The result is stronger continuity for the workloads that demand it most. The primary use cases include:

• Centralize mission-critical mixed workloads: Run performance and latency sensitive databases, VMware, enterprise applications, electronic health record (EHR) systems, file services, and object-enabled workflows on AFF to reduce silos while preserving the availability and predictability that critical SAN environments require.
• Extend one data architecture across environments: Apply consistent replication, protection, dev/test, tiering, and disaster recovery across SAN, NAS, and object data, enabling movement between AFF and ONTAP-based cloud services without using separate operating models.
• Modernize data pipelines on production data: Run analytics, AI/ML, backup, and data services alongside your primary production datasets, using the right protocol for each stage and avoiding redundant copies, slow ETL workflows, and isolated staging platforms.

Technical Value

ONTAP 9.19.1 improves host I/O performance on AFF systems by introducing symmetric active-active pathing. This feature allows hosts to use concurrent active-optimized paths across both controllers in an HA pair to access data volumes. Since alternate paths stay active and optimized, host operations resume quickly during path failures, avoiding the latency associated with ALUA/ANA path state transitions. [GR1] [FD2] SAN pathing is configured at the Storage Virtual Machine (SVM) creation time, where administrators can select either symmetric active-active or traditional active-local pathing for each SVM. Existing SVMs remain unchanged, and customers can adopt active-active incrementally by creating new SVMs with active-active pathing and moving workloads over time. The core technical advantages include:[FD3]

• Continuous Availability: Active‑optimized paths across both nodes eliminate ALUA/ANA transition delays, isolating mission-critical applications from underlying network path failures.
• Simplified Storage Operations: Consolidates asymmetric structures like SCSI ALUA Target Port Groups and NVMe ANA Access Groups into a single policy in mixed block-storage environments.
• Enable Host Side Load Balancing: The storage array presents all links as active & optimized, allowing the host to perform network load balancing and distribute I/O traffic across multiple paths.

The Takeaway

With symmetric active-active SAN pathing on AFF systems, ONTAP extends mission-critical availability to unified workloads without giving up the platform advantages customers already rely on: efficiency, resilience, security, cloud mobility, and operational consistency. AFF becomes an even stronger foundation for customers standardizing mixed block, file, and object workloads across on-premises and cloud—delivering a secure, efficient, multi-protocol architecture built for today’s demands and tomorrow’s growth.

Getting Started

Whether you are modernizing your SAN infrastructure or consolidating mixed workloads, active‑active pathing on AFF provides a new design option at no additional licensing cost. Start by identifying workloads most sensitive to path disruption—such as VMware, databases, and transactional applications—and evaluate how active‑active pathing on AFF can help simplify architecture, improve access continuity, and standardize your environment on a unified platform. For configuration guidance and technical details, see the official documentation at: https://docs.netapp.com/us-en/ontap/san-admin/multipath-automatic-lif-failover-support.html .

We have Active iq but it just gives you the volume growth not folder level.

Does anyone use the ontap API's to do any monitoring of storage?

We are planning upgrade of a FAS50 from ONTAP 9.16.1P7 to 9.17.1P10.

Reason for upgrade is controller panic/reboot related with mgwd becoming unresponsive. Fix for our issue is confirmed on 9.17.1P10 and not available on 9.16.1 patches.

Before upgrade we want make sure nothing on our environment can be affected.

Current applications using storage:

• SnapCenter 5.0 SP2 for Oracle
• SnapCenter 6.2P1 for SQL Server and Exchange
• No VMware / ESXi

Main concern is SnapCenter 5.0 SP2 because components are showing as EOVS in IMT.

We are trying to confirm if SnapCenter 5.0 SP2 Oracle environment can still be supported with ONTAP 9.17.1, or if SnapCenter must be upgraded first.

For Oracle we requested:

• Linux OS/version
• Oracle version/RU
• standalone or RAC
• ASM yes/no
• physical or virtual
• storage protocol, looks like FC currently
• exact Oracle and UNIX/FileSystem plug-in versions

For SQL:

• Windows Server version
• SQL version/edition/CU
• standalone, FCI/WSFC or Always On AG
• physical or virtual
• storage protocol, looks like iSCSI
• exact SQL and Windows plug-in versions

For Exchange:

• Windows Server version
• Exchange version/CU/SU
• standalone or DAG
• physical or virtual
• iSCSI/FC usage
• exact Exchange and Windows plug-in versions

Also requested:

• confirm 5.0 SP2 and 6.2P1 are separate SnapCenter Server installations
• Windows version of both SnapCenter Servers
• confirm all protected storage is on same FAS50
• other production applications/hosts using cluster
• any secondary ONTAP used for SnapMirror/DR/backups

Depending protocol we will also check Host Utilities, multipathing/MPIO, HBA driver/firmware, SAN switches etc.

We will run Upgrade Advisor and also check shelf/disk firmware before upgrade.

Main question:

Is there anything else you would validate before going from 9.16.1P7 to 9.17.1P10?

And especially, anyone know correct position for SnapCenter 5.0 SP2 Oracle with ONTAP 9.17.1 when 5.0 components are EOVS in IMT?

Would EOVS mean we should upgrade SnapCenter 5.0 first even if IMT can show a compatible configuration, or can the ONTAP upgrade still be supported?

CONTAP-621129 - this was the contap we used as RCA

Thanks in advance