We are pleased to announce the launch of SnapCenter 6.1, which introduces a range of advanced features designed to enhance our data protection capabilities in the areas of backup and disaster recovery. These enhancements will facilitate the broader adoption of our enterprise and cloud storage solutions ... View more

By Michael Haigh (@MichaelHaigh) and Patric Uebele, Technical Marketing Engineers at NetApp ... View more

Are you looking to migrate VMs across hypervisors. Have you ever wondered how to offload the conversion process to storage for quicker results? Let's examine migrating 5 VMs, each with two 1TB disks in addition to the OS disk, totalling 10TB of data disks plus the OS disk.     Impressive, isn't it? This blog introduces the NetApp Shift toolkit, which can be utilized to simplify and accelerate VM migrations across hypervisors. Let's explore together how the Shift toolkit achieves this.   What’s the problem statement Given VMware's recent licensing changes, organizations are revisiting their virtualization strategies to improve cost efficiency, scalability, and reduce business risks. This includes optimizing the existing VM estate and adopting either a multi-hypervisor or hybrid cloud approach.   Be it any scenario, ONTAP is the ideal platform for any hypervisor platform. ONTAP supports all the prominent hypervisors in on-premises environments and has first-party data services in each major cloud, supporting VMware cloud offerings and cloud native workloads. This enables organizations to navigate the licensing changes easily by choosing the appropriate deployment model for their workloads.     While optimization activities are ongoing, every organization is evaluating a multi-hypervisor approach so as to reuse their existing hardware investment, which supports a multi-vendor hypervisor strategy, thus strengthening operational flexibility, mitigating vendor dependency, and optimizing workload placement. By combining multiple hypervisors, organizations can tailor infrastructure to meet diverse workload demands while managing costs. Organizations then streamline multi-hypervisor management by leveraging interoperability, cost-effective licensing, and automation.   A critical requirement in this approach is the swift and seamless mobility of virtual machines, guided by SLAs and workload placement strategies. Migrating from one hypervisor to another involves a complex decision-making process for businesses. Key considerations include application dependencies, migration timeline, workload criticality, and the impact of application downtime on the business. However, with ONTAP storage and Shift toolkit, this is a breeze. How about wicked fast (100x faster) conversions to any hypervisor of your choice using clones, call it VM migration offloader. Below is an example of conversion from VMware to Hyper-V.       Introducing NetApp Shift Toolkit (a simple VM mobility platform) The NetApp Shift toolkit is an easy-to-use, graphical user interface (GUI) solution that allows to migrate virtual machines (VMs) between different hypervisors and convert virtual disk formats. The whole process utilizes NetApp Snapshots® and FlexClone® technology to quickly convert VM hard disks. Additionally, the toolkit manages the creation and configuration of destination VMs. Does not require additional storage or data center resources.   For detailed information, see my Shift toolkit guide   What are the key benefits: Beneficial for organizations looking to optimize VM licensing costs and extend IT budgets. Provides flexibility in a multi-hypervisor environment by supporting bidirectional conversion hypervisors. Helps minimize long downtime and enhances business productivity. Offers choice and flexibility by reducing licensing costs, lock-in, and commitments to a single vendor. Reduces virtualization costs with data portability. Is offered free from NetApp. Provides fully scriptable REST APIs that can be leveraged by automation workflows. Note: The pre-requisite for Shift toolkit is to have VMs running on NFS volume residing on ONTAP storage. This means if the VMs are hosted on block based ONTAP storage or on third party storage arrays, then VMs should be moved using Storage vMotion to the designated ONTAP based NFS datastores. Guess what, the VMs will remain online during svmotion, ensuring minimal downtime for migrations when moving to target hypervisor.   Shift toolkit can be downloaded here and is available for Windows Systems only.   For detailed installation steps, refer to Installing and setting up Shift toolkit   How Shift toolkit works: The high-level steps performed are as follows:   Connects to VMware and Hyper-V to collect host and VM resource metadata Allows selection of VMs and Shift toolkit injects the required scripts Script to remove VMware tools and retain the IP settings irrespective of the OS type VMware tools removal performed at the target            Note: No modifications are made to the source VM, allowing it to be rolled back    exactly as it was            Note: Once prepared, VMs should be powered off based on the maintenance window Deletes existing snapshots for all VMs in the blueprint Triggers VM snapshots for Blueprint – at source Trigger volume snapshot before disk conversion Clone and convert VMDK to VHDx format for all VMs Power ON VMs in protection group – at target Register the networks on each VM Remove VMware tools and assign the IP addresses using trigger script or cron job depending on the OS type For detailed information, refer to using the Shift toolkit to perform VM migration   What can Shift toolkit do for you: Shift toolkit provides flexibility in a multi-hypervisor environment by supporting bidirectional conversion between the following hypervisors: VMware ESXi to Microsoft Hyper-V Microsoft Hyper-V to VMware ESXi (Upcoming release) Shift toolkit supports disk-level conversions of virtual disks between hypervisors for the following disk formats: VMware ESX to Microsoft Hyper-V (virtual machine disk [VMDK] to virtual hard disk format [VHDX]) VMware ESX to KVM compatible hypervisors (VMDK to QCOW2)   Note: The converted qcow2 files are compatible with any KVM hypervisors. For example, a qcow2 file can be utilized with RHEL-based KVM using virt-manager to create a VM, as well as with ubuntu KVM, Rocky Linux based KVM and others. The same can be used with Oracle Linux virtualization manager and with OpenShift virtualization after importing using NetApp Trident. The goal is to provide the disk (converted in secs to mins) which can then be integrated into existing automation scripts used by organizations to provision the VM and assign the network. This approach helps reduce overall migration times, with disk conversion handled by Shift toolkit APIs and the remaining script bringing up the VMs.   In future releases, Shift toolkit will support end-to-end migration from VMware to other compatible KVM hypervisors. However, with the current release, the conversion can be performed via the UI or APIs.     Summarizing NetApp Shift toolkit helps an administrator to rapidly and seamlessly convert VMs from VMware to Hyper-V. It can also convert just the virtual disks between the different hypervisors. Therefore, Shift toolkit saves several hours of effort each time that you want to move workloads from one hypervisor to the other. Organizations can now host multi-hypervisor environments without having to worry about whether workloads are tied down to a single hypervisor. This capability increases flexibility and reduces licensing costs, lock-in, and commitments to a single vendor.    To learn more about this process, feel free to follow the detailed walkthrough: https://netapp.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=6bf11896-3219-4ba7-9a00-b2d800d47144&start=0   If you’re planning to migrate thousands of VMs and ready to start simplifying the migration process, NetApp is here to help. https://mysupport.netapp.com/site/tools/tool-eula/netapp-shift-toolkit ... View more

What is NetApp Trident?   NetApp Trident is a storage orchestrator developed by NetApp that adheres to the CSI specification, providing persistent storage solutions for Kubernetes environments. It integrates seamlessly with NetApp storage systems and is fully compatible with Amazon EKS, a managed Kubernetes service. Trident operates by automatically handling persistent volume claims (PVCs) within Kubernetes. When a PVC is made, Trident communicates with the relevant NetApp storage service to provision the necessary volumes. In AWS environments, Trident integrates effortlessly with Amazon EKS deployments, using the robust capabilities of NetApp ONTAP to deliver reliable persistent storage.   What are Amazon EKS add-ons?   Add-on software gives an application more capabilities, and the same is true with Amazon EKS add-ons. The AWS Marketplace hosts numerous verified and compatible third-party add-ons that can provide operational capabilities for Amazon EKS that aren’t available out of the box. When you install these add-ons through the AWS Marketplace, you can be sure that they’re all AWS compliant, have up-to-date security patches, and have been tested to work properly with your underlying Amazon EKS deployment.   NetApp Trident as an Amazon EKS add-on   With this new functionality, you can now download NetApp Trident directly from the AWS Marketplace through the Amazon EKS console. This enhancement simplifies the deployment and integration of Trident within the Amazon EKS deployment wizard. Whether you use UI or CLI tools like eksctl, the Trident add-on provides the same capabilities, a consistent and seamless experience across different interfaces. As a result, Trident is now seamlessly incorporated into the Amazon EKS deployment workflow, eliminating the need for manual installation on your part. In summary, this update significantly streamlines the process of using Amazon EKS with NetApp ONTAP, making it much more convenient and efficient for you.   What is auto-configuration of back ends on Amazon FSx for NetApp ONTAP?   Previously, users had to manually configure numerous prerequisites—like the Trident back end, storage classes, before deploying their applications. Starting with the 25.02 release, Trident now supports automatic back-end configuration after you install it, which sets up Trident related configurations automatically, providing a seamless experience. Here is a list of resources that are created as part of this process: Trident back end Storage class containing SVM credentials SVM for each FSx for ONTAP file system Currently, automatic back-end configuration on Amazon FSx for NetApp ONTAP is supported only for the NFS and iSCSI protocols.   Prerequisites   Following are the prerequisites for automatic Trident back-end configuration for FSx for ONTAP:  Find the file system ID for the FSx for ONTAP instance. You can obtain it from the AWS portal in the Amazon FSx service. This portal displays all the available file systems along with their IDs. Ensure that you have an IAM role with the necessary permissions so that this feature functions properly. To confirm that all the permissions are in place for the newly created role, review the documentation on how to create an IAM role. Make sure that you have Custom Resource Definitions (CRDs) for the VolumeSnapshotClass, VolumeSnapshotContent, and VolumeSnapshot installed on your cluster before you enable the automatic back-end configuration feature. kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-5.0/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-5.0/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/release-5.0/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml   How to install and to enable back-end auto-configuration for the NetApp Trident add-on Let’s take a high-level look at how to deploy and to auto-configure Trident through the Amazon EKS console: Select the Amazon EKS cluster on which NetApp Trident needs to be installed. Navigate to the Add-Ons section. Here, you see a list of any add-ons that you currently have installed. Click the Get More Add-Ons button. From the Select Add-Ons window, scroll down to the AWS Marketplace Add-Ons section. You can search for “NetApp” or “NetApp Trident” in the search field, or you can use the filtering option to select NetApp from the list of vendors. NetApp Trident appears in the search results by using either method. Select it by checking the box at the top right. Click Next to continue with the installation process.             Select the 25.02 version from the drop-down menu, because automatic back-end configuration is supported starting with this version. To enable auto-configuration, you need to pass a few details as part of the JSON schema (shown in the following “Optional configurations”), which includes the file system ID, the authentication method for SVMs, and protocols for which auto-configuration needs to be performed. Next, in the cloudIdentity field, provide the IAM role that you created during the prerequisite phase. Click Next to continue with the installation process. { "cloudIdentity": "'eks.amazonaws.com/role-arn: arn:aws:iam::<accountID>:role/<AWSEKS_FSxN_CSI_DriverRole>'" "ontapConfigurator": { "enabled": true, "svms": [ { "authType": "awsarn", "fsxnID": "fs-0dfeaa884a68b1cab", "protocols": [ "nfs", "iscsi" ] }, { "authType": "awsarn", "fsxnID": "fs-5dclba491a31c2cdc", "protocols": [ "nfs", ] } ] } } Let’s briefly try to understand the newly added ontapConfigurator section: ontapConfigurator: The root object for the ONTAP configuration-related user input: enabled: Set to true to enable automatic back-end configuration. svms: Contains the list of file system IDs for which automatic back-end configuration will be created: authType: Set the authentication type for SVM authentication. For AWS, arn-based authentication ("awsarn") is currently supported. fsxnID: Set the file system ID of the FSx for ONTAP instance; for example, "fs-0dfeaa884a68b1cab". protocols: Specify the list of supported protocols for automatic back-end configuration; "nfs", "iscsi", or both. On the final window, review all the details to ensure that they are correct, and then click Create Now you can move on to your cluster and verify that Trident was successfully installed. kubectl get pod -n trident NAME READY STATUS RESTARTS AGE trident-controller-6fcb4d9c8d-2hrw6 6/6 Running 0 9m51s trident-node-linux-bxmvn 2/2 Running 0 9m50s trident-node-linux-gldkc 2/2 Running 0 9m50s trident-node-linux-w47w6 2/2 Running 0 9m50s trident-node-linux-wq6sm 2/2 Running 0 9m50s trident-operat​   Now that Trident is set up, you can also verify that the Trident configurators (responsible for the lifecycle of auto-configuration), Trident back ends, storage classes, and AWS Secret Manager secrets have been created successfully.  The tconfs, which hold user-entered inputs such as file system ID, protocols, and authentication type, should also have been created. kubectl get tconf -n trident NAME PHASE STATUS CLOUD PROVIDER netapp-nas-backend-configurator Done Success AWS netapp-san-backend-configurator Done Success AWS --------------------------------------------------------------------------------------- kubectl describe tconf netapp-nas-backend-configurator -n trident Name: netapp-nas-backend-configurator Namespace: Labels: app.kubernetes.io/managed-by=Helm Annotations: meta.helm.sh/release-name: trident meta.helm.sh/release-namespace: trident API Version: trident.netapp.io/v1 Kind: TridentConfigurator Metadata: Creation Timestamp: 2025-03-13T12:44:53Z Generation: 1 Resource Version: 1008274 UID: 18d9311f-931c-4f37-b4ee-5adb5d163039 Spec: Storage Driver Name: ontap-nas Svms: - Auth Type: awsarn Fsxn Id: fs-0dfeaa884a68b1cab Protocols: - nfs - iscsi Svm Name: trident-fs-0dfeaa884a68b1cab - Auth Type: awsarn Fsxn Id: fs-5dclba491a31c2cdc Protocols: - nfs Svm Name: trident-fs-5dclba491a31c2cdc Status: Backend Names: - trident-fs-04f8f55e27350a9c1-nfs - trident-fs-04f8f55e27350a9c2-nfs Cloud Provider: AWS Deletion Policy: Last Operation Status: Success Message: Completed Trident backend configuration Phase: Done Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Processing 119s trident-operator.netapp.io Provided backend configuration is correct Normal Processing 118s (x2 over 2m1s) trident-operator.netapp.io Validating backend configuration Normal Processing 118s trident-operator.netapp.io Creating backend with the provided configuration Normal Processing 118s trident-operator.netapp.io Backend creation successful Normal Processing 118s trident-operator.netapp.io Creating storage classes for the backend Normal Processing 118s trident-operator.netapp.io Storage class creation successful Normal Success 118s trident-operator.netapp.io Completed Trident backend configuration You can also verify whether the Trident back ends have been created. kubectl get tbc -n trident NAME BACKEND NAME BACKEND UUID PHASE STATUS trident-fs-0dfeaa884a68b1cab-iscsi trident-fs-0dfeaa884a68b1cab-iscsi 86018ab1-5dfe-4292-9efb-7a143fa43fa1 Bound Success trident-fs-0dfeaa884a68b1cab-nfs trident-fs-0dfeaa884a68b1cab-nfs 18c35c18-29c4-40fc-84b3-dd0c05bee7bb Bound Success trident-fs-5dclba491a31c2cdc-iscsi trident-fs-5dclba491a31c2cdc-iscsi 13f2c4e5-9b8d-4f1e-bc3a-7a9f6d8e7c2b Bound Success trident-fs-5dclba491a31c2cdc-nfs trident-fs-5dclba491a31c2cdc-nfs 91e2d3c4-5b6a-7d8e-9f0a-1b2c3d4e5f6a Bound Success ------------------------------------------------------------------------------------------------------------------------------------------------------ kubectl describe tbc trident-fs-0dfeaa884a68b1cab-iscsi -n trident Name: trident-fs-0dfeaa884a68b1cab-iscsi Namespace: trident Labels: <none> Annotations: <none> API Version: trident.netapp.io/v1 Kind: TridentBackendConfig Metadata: Creation Timestamp: 2024-11-14T12:46:01Z Finalizers: trident.netapp.io Generation: 1 Resource Version: 1008310 UID: 44f2e0c0-e842-41f5-a8e3-b94b485107eb Spec: Aws: Fsx File System ID: fs-0dfeaa884a68b1cab Credentials: Name: arn:aws:secretsmanager:us-west-2:186785786363:secret:trident-fs-0dfeaa884a68b1cab-iNA9nP Type: awsarn Management LIF: 10.0.255.230 Storage Driver Name: ontap-san Svm: trident-fs-0dfeaa884a68b1cab Version: 1 Status: Backend Info: Backend Name: trident-fs-0dfeaa884a68b1cab-iscsi Backend UUID: 86018ab1-5dfe-4292-9efb-7a143fa43fa1 Deletion Policy: delete Last Operation Status: Success Message: Backend 'trident-fs-0dfeaa884a68b1cab-iscsi' created Phase: Bound Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Success 33s trident-crd-controller Backend 'trident-fs-0dfeaa884a68b1cab-iscsi' created Next, you can verify whether the storage classes have been created. kubectl get sc NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE gp2 kubernetes.io/aws-ebs Delete WaitForFirstConsumer false 3d17h trident-fs-0dfeaa884a68b1cab-iscsi csi.trident.netapp.io Delete Immediate true 3m40s trident-fs-0dfeaa884a68b1cab-nfs csi.trident.netapp.io Delete Immediate true 3m44s trident-fs-5dclba491a31c2cdc-iscsi csi.trident.netapp.io Delete Immediate true 2m10s trident-fs-5dclba491a31c2cdc-nfs csi.trident.netapp.io Delete Immediate true 2m14s ------------------------------------------------------------------------------------------------------------------------------------------- kubectl describe sc trident-fs-0dfeaa884a68b1cab-iscsi Name: trident-fs-0dfeaa884a68b1cab-iscsi IsDefaultClass: No Annotations: <none> Provisioner: csi.trident.netapp.io Parameters: backendType=ontap-san AllowVolumeExpansion: True MountOptions: <none> ReclaimPolicy: Delete VolumeBindingMode: Immediate Events: <none> root@scspa3026497001:~/trident# kubectl describe sc trident-fs-0dfeaa884a68b1cab-iscsi Name: trident-fs-0dfeaa884a68b1cab-iscsi IsDefaultClass: No Annotations: <none> Provisioner: csi.trident.netapp.io Parameters: backendType=ontap-san AllowVolumeExpansion: True MountOptions: <none> ReclaimPolicy: Delete VolumeBindingMode: Immediate Events: <none> You can visit AWS Secrets Manager to verify that the secret with the Amazon Resource Name (ARN) arn:aws:secretsmanager:us-west-2:186785786363:secret:trident-fs-0dfeaa884a68b1cab-iNA9nP is present and securely holds the SVM-related credentials. All the preceding processes are handled as part of the one-click Trident Amazon EKS add-on installation. At this point, you can directly create a PVC by using the provided storage classes, and you can start using the application seamlessly as demonstrated here:  apiVersion: v1 kind: PersistentVolumeClaim metadata: name: test-new-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: trident-fs-0dfeaa884a68b1cab-iscsi Verify that the volume is created in the Volume section of the Amazon FSx for NetApp ONTAP management portal. Conclusion   Auto-configuration offers significant benefits by eliminating the need for manual configuration, enabling you to deploy and to configure Trident seamlessly. This streamlined process enhances the user experience to the level of built-in cloud CSI drivers like Amazon EBS and Amazon EFS, making it easier and faster for you to set up and to manage storage solutions. Another important highlight is the simplicity of the process, which means that Amazon EKS users no longer need to be experts in storage or in FSx for ONTAP. Developers, for example, can use the add-on to effortlessly configure storage back ends for their stateful applications. For more details about this offering, review the official documentation.    Ready to get started? Head over to the Amazon EKS add-on section of the AWS Marketplace to install and to automatically configure the NetApp Trident add-on.   Happy provisioning! ... View more

We are thrilled to announce a significant enhancement to Google Cloud NetApp Volumes with the integration of Assured Workloads. This powerful combination empowers organizations to deploy NetApp Volumes in a rigorously secure and controlled environment, specifically designed to meet the stringent compliance demands of highly regulated sectors such as government, healthcare, and financial services.   Google Cloud NetApp Volumes offers organizations Assured Workloads Regions and Support for Regional Controls in Australia, Canada, Europe, Singapore, and US regions.    Reduced Risk With Assured Workloads support, Google Cloud NetApp Volumes opens the path to running more secure and compliant storage workloads on Google Cloud. Enterprises can now significantly reduce their risk and liability by enabling adherence to relevant standards and regulations and mitigate risks of noncompliance that can result in reputational damage, legal challenges, and severe penalties.   Future-proof security Regulatory standards are constantly evolving to address emerging technologies and threats. Google Cloud NetApp Volumes with Assured Workloads support helps enterprises stay ahead of these changes and enables their compliance measures to remain effective and up to date, future-proofing their security and compliance.   Uncompromised compliance Navigating the complex landscape of industry regulations and standards like ISO, SOC, HIPAA, and GDPR is simplified with Assured Workloads. Assured Workloads offers a preconfigured environment meticulously designed to align with these requirements, easing the burden of compliance and audit preparation. Assured Workloads establishes a fortified environment for NetApp Volumes, incorporating robust isolation controls and encryption mechanisms to safeguard sensitive data from unauthorized access and potential breaches.   Comprehensive security and performance NetApp Volumes delivers exceptional performance and scalability to support demanding workloads. Integration with Assured Workloads lets the high-performance capability remain uncompromised, even within the most security-conscious environments. By providing a comprehensive security framework, Assured Workloads can potentially reduce the need for supplementary security measures, leading to cost savings and operational efficiencies.   Enhanced controls and visibility   Assured Workloads offers enterprises stringent controls and enhanced visibility into data locality, personnel access, and auditing of their data stored in NetApp Volumes.   Data locality - Assured Workloads provides granular control over data location, allowing you to specify where NetApp Volumes data is stored and processed, maintaining  compliance with data sovereignty and residency requirements. Personnel access - Stringent controls are implemented to govern access to NetApp Volumes environments within Assured Workloads. Enterprises have the authority to define which Google Cloud personnel can access your data and under what circumstances, providing an additional layer of security and oversight. Audit logging - Comprehensive audit logging capabilities in Assured Workloads offer detailed visibility into activities and events in your NetApp Volumes environment. This transparency aids in monitoring, troubleshooting, and maintaining compliance. Cryptographic control over data access - All data stored in NetApp Volumes is encrypted by default. For more control on data encryption, you can use Cloud Key Management Service (Cloud KMS) to manage your own encryption keys. Assured Workloads supports appropriate encryption based on compliance needs. Google Cloud's multilayered approach maintains data confidentiality, security, and compliance. Use cases   The synergy between NetApp Volumes and Assured Workloads unlocks a wide array of use cases.   Highly regulated industries - Organizations operating in sectors with stringent regulatory requirements, such as healthcare, financial services, and government, can leverage NetApp Volumes with Assured Workloads to confidently deploy workloads in a secure and compliant manner. Sensitive data - For organizations entrusted with safeguarding sensitive data, including personally identifiable information (PII), protected health information (PHI), and financial data, NetApp Volumes with Assured Workloads offers robust protection against unauthorized access and data leakage. Mission-critical applications - Assured Workloads provides a dependable foundation for mission-critical applications that rely on NetApp Volumes, so that these applications operate within a secure and highly available environment and minimize the risk of disruptions and downtime.   Get started The integration of Assured Workloads with NetApp Volumes enables seamless deployment and management. The intuitive interface and comprehensive documentation facilitate the configuration and deployment of volumes in the Assured Workloads environment.   To delve deeper into the capabilities and benefits highlighted in this blog post, explore our detailed documentation and resources for Assured Workloads and Google Cloud NetApp Volumes. Elevate your enterprise’s file storage and compliance capabilities with Google Cloud NetApp Volumes and Assured Workloads support. Embrace the future of secure, compliant, and efficient data management today.   ... View more