Spring is almost complete here in the northern hemisphere, and it has been a time of new growth – both in nature and with BlueXP disaster recovery as a service (BlueXP DR). Our April, May, and June releases bring many exciting new features and improvements that I’m thrilled to share with you. Let’s dive in!
Amazon Elastic VMware Service Integration
First up, we’ve added support for Amazon Elastic VMware Service (Amazon EVS) connected to Amazon FSx for ONTAP storage (Amazon FSxN). This is a game-changer for those familiar with Amazon VMware Cloud on AWS from Broadcom (Amazon VMC). Amazon EVS, powered by VMware Cloud Foundation from Broadcom on a fully managed EC2 framework, offers seamless integration with familiar VMware tools like VMware vCenter. This means you get the same look, feel, and control as an on-premises vCenter cluster, without the scalability or feature restrictions that were imposed by Amazon VMC. Plus, you can protect both NFS and VMFS datastores in the same replication plan.
Figure1: BlueXP disaster recovery protection with Amazon EVS
To learn more, see our new deployment guide Using BlueXP disaster recovery with Amazon EVS.
Datastore-Scoped Resource Groups
We’ve made it even easier to protect large groups of VMs with our new datastore-scoped resource groups (RGs). Previously, creating a resource group with hundreds or thousands of VMs could be tedious, and managing changes like VM migrations (vMotion anyone?) required manual updates. Now, you can create RGs and replication plans (RPs) based on entire datastores. Simply select the “Datastores” option when selecting VMs to protect. As shown in Figure 2, you can select one or more datastores for protection. This will tell BlueXP DR to refresh each vCenter datastore to identify all VMs to be protected.
Figure 2: Protecting datastores
In conjunction with this new selection method, BlueXP DR will automatically rescan each vCenter on a regular basis to proactively identify when VMs have been added or removed from each datastore and make the appropriate changes for each RP. This dynamic approach ensures that any changes within the datastore are automatically reflected in your RGs and RPs, thanks to our scheduled discovery feature. This new scheduled rescan is performed every 24-hours by default but is easily changed by editing each vCenter (Figure 3).
Figure 3: Changing the automatic rescan schedule
To learn more about creating resource groups using vCenter datastores, see Create a resource group or Create a replication plan in the BlueXP disaster recovery documentation.
Scheduled vCenter inventory refresh
Along with the support for datastore-scoped protection groups, BlueXP DR needed a way to detect new VMs added to datastores and any VMs that might have been removed from the datastore without user intervention. By default, BlueXP refreshes vCenter inventory every 24 hours, but users can change this frequency to a shorter period…down to one hour if needed.
To learn more, visit Perform replication plan operations in the online documentation.
Subnet-based IP address modifications
BlueXP DR supports the ability to alter each protected VM’s configuration as part of the failover process. Most importantly, is the potential need to change each VM’s network configuration due to failing over to a vCenter that is connected to different virtual networks with different IP subnets. In previous BlueXP DR versions, if you had two choices available to configure each VM’s IP address configuration: use the same IP settings as the source vCenter virtual networks, or use a different set of IP settings…which would then have to be manually entered for each VM. This is fine if your replication plan was protecting a relatively small number of VMs, but what if your replication plan was protecting hundreds or thousands of VM? Manual configuration simply is not viable in these scenarios.
Starting with our May 2025 release, we now offer a third configuration option: subnet mapping. This allows BlueXP DR to automatically assign IP addresses based on the virtual network’s specific configuration settings.
To use subnet mapping, you need to tell BlueXP DR the IP configuration settings (IPv4 CIDR, gateway, and DNS settings) for each virtual network being used within the vCenter. Once we have this information, it is really a simply process to use subnet mapping. You simply need to select that third option for VM configuration mapping during replication plan creation. BlueXP DR takes it from there. When you perform a failover, BlueXP DR will view each IP address as a subnet and host component based on the CIDR and simply replace the source subnet component with the destination subnet component and reuse the same host component of the IP address. Currently we support like-for-like subnet classes only.
For example:
Assume we have the following virtual networks and settings:
|
|
Source (vmNet001) |
Destination(vmNet100) |
|
CIDR |
10.0.0.1/24 |
192.168.1.1/24 |
|
Gateway |
10.0.0.1 |
192.168.1.1 |
|
DNS |
12.200.3.45 |
13.200.4.100 |
The table below illustrates how the IP configuration is changed for each VM:
|
|
Source (vmNet001) |
Destination(vmNet100) |
|
VM1 |
10.0.0.152 |
192.168.1.152 |
|
VM2 |
10.0.0.153 |
192.168.1.153 |
|
VM3 |
10.0.0.175 |
192.168.1.175 |
And all VMs will use the new gateway and DNS server(s).
To implement subnet-based VM configuration see how define virtual network IP configurations on each vCenter and then configuring VM network settings during replication plan creation.
Support for ONTAP SnapMirror policy-based snapshots
We have had several customers ask us why they can’t just use the snapshots created by their existing SnapMirror replication plans that are already protecting their VMware volumes and LUNs. Well, we agree! Now for any replication plan you create, you have the option to use those existing ONTAP snapshots as restore points or to use the existing BlueXP DR snapshot schedules. This feature is available if all of the datastores selected during replication plan creation are hosted on volumes with existing SnapMirror relationships.
This is a great option for those who already have an extensive SnapCenter for VMware data protection plan in place, and simply want to automate failover and recovery using BlueXP DR. This could also be a valuable tool for those using a third-party solution for backup but want to move to a DR solution that was not possible with their previous solution.
Configuring this feature is simple:
- Chose to protect datastores during replication plan creation
- Check the “Use platform managed backups and retention schedules” option on the Datastores section of the replication plan creation wizard
All of the details can be found in the Replication plan creation documentation.
Cross resource group boot order
BlueXP DR supported the ability to restart VMs in a particular order. This information was configured during the replication plan creation. If a replication plan protected multiple resource groups, the boot order settings were only valid within that resource group, and the order of the resource groups was fixed. We realized that this may not meet the needs of all of our customers, and so now boot order ignores the resource group boundary. In the new paradigm, all 1’s boot in parallel across all resource groups.
Learn more about boot order in the Create replication plan documentation.
Support for Microsoft Windows LAPS authentication for VM reconfiguration operations
Customers that do not use per-VM administrator accounts or need to have the ability to rotate passwords for administrator accounts in Windows, can now use Microsoft Windows LAPS to obtain the administrator password for each Windows VM when BlueXP DR needs to run VM-local scripts, change IP addresses, or perform any other privileged operation within the VM.
Learn more by visiting the Create a replication plan documentation.
Persistent Replication Plan Settings
One of the more subtle but significant improvements is the persistence of replication plan settings when making changes. Before this update, modifying your replication plan often required reconfiguring all mappings between vCenters, even if unnecessary. Now, those settings remain intact, streamlining the process and improving your overall experience.
Disable automatic configuration of reverse replication during failover
Normally, when you perform a failover operation, BlueXP DR looks to see if the source site resources are still accessible. If they are, BlueXP automatically configures a reverse SnapMirror relationship to make sure that your VMs are protected even when operating from the DR site.
Some customers may not want to do this as they may want to perform some additional testing or reconfiguration prior to returning to the normal operating configuration. For these customers, you can now disable this automatic SnapMirror relationship creation when you initiate a failover of a replication plan as shown in Figure 4.
Figure 4: Skip protection during a failover
Improved Stability
We’ve also implemented numerous internal changes to enhance stability and handle a wider variety of edge scenarios. While these improvements might not be immediately visible, they ensure that BlueXP DR is enterprise-ready and reliable when you need it most.
Final Thoughts
We’re continually enhancing BlueXP DR by adding new features and supporting new platforms and use cases. This release introduces several new feature and enhancements that dramatically improve BlueXP DR functionality and value to our customers. Our commitment to stability and usability remains unwavering.
If you’re looking for a robust disaster recovery solution for your VMware infrastructure, I encourage you to explore BlueXP Disaster Recovery. For current NetApp customers and partners, we offer a Lab on Demand for a risk-free trial of all BlueXP DR features. You can also install the BlueXP connector and enjoy a 30-day free, unlimited capacity trial by visiting our BlueXP service portal.
For additional information about these latest features and how BlueXP disaster recovery can help you achieve your VMware DR goals, visit the following valuable resources:
- Blog: BlueXP Disaster Recovery Now Supports Amazon Elastic VMware Service with FSxN for ONTAP
- Solution Brief: BlueXP disaster recovery
- Amazon Announcement: Amazon Elastic VMware Service now integrates with Amazon FSx for NetApp ONTAP
- Blog: Using Amazon Elastic VMware Service with FSx for ONTAP to optimize costs and modernize VMware
- Solution homepage: BlueXP disaster recovery
- Blog: Protect on-premises VMware infrastructure with NetApp BlueXP Disaster Recovery, Amazon Elastic VMware Service, and Amazon FSx for NetApp ONTAP
- Video: BlueXP disaster recovery and Amazon EVS Demo
Stay tuned for more updates, and happy spring!
