So you’ve followed the guide to integrate Keycloak with Okta via SAML 2.0. The next logical step to simplify that configuration would be to automatically map user groups in Okta (if they should have access to Zerto) to corresponding groups in Keycloak to reduce management even more. Guess what? It’s actually pretty straightforward, and the nice part is I have “RH” to thank for taking what I’ve previously done with user mapping and bringing it to groups; so huge shoutout to him for the assist!
Let’s face it, no one wants to manage application access via users, especially at scale. And no one wants to have another step to take once a user logs into something for the first time. By mapping an Okta group to an existing group in Keycloak this will take any additional administrative work to wait for a user to login, only to get denied access, just so the admin can add them to the group to try again.
Properly managing access to applications shouldn’t be a burden. It should be as seamless and without admin overhead as possible. For example, if I’m defined as a Zerto Admin in Okta, when I first login to Zerto, I want to be let right in with the proper access; not have to bug another admin to add me to a group. What if my group membership needs change? It should be able to be done in Okta and then reflected in Zerto on my next login, so we want to also account for group membership updates without any additional work. The following procedure will be the icing on the cake and make your Keycloak/Okta integration pretty much hands-off once you’ve set it up; and you can go back to doing great things again.
Don’t Jump Ahead!
Before you follow this guide, please make sure you’ve already set up the integration (steps are in my previous blog titled: Zerto 10 Keycloak and Okta SAMLv2.0 Integration. You may have also got to the end of my previous guide and followed the link to this one; so if that’s how you ended up here, then you’re right on track!
Create the Keycloak Groups for Zerto Roles
When Zerto is deployed, there are some out-of-the-box pre-configured roles with the necessary permissions attached to them, so that’ll save you some time. You can view what those roles are and what privileges have been assigned to them in this Zerto document: ZVM Appliance Roles and Permissions
For the most part, these are generally all you need, but just know, that if you want to create any custom roles, you can, and Keycloak already contains the privileges within – so you can use what you need if you have to.
Before you start: If you don’t know how to manage Zerto Role-based Access Controls, please see my previously written blog titled “Zerto 10 Role-based Access Controls” and scroll down to the section titled “Managing Zerto Roles by Using Groups” to create the groups in Keycloak if you haven’t already done that.
Configure the Okta to Keycloak Group Mapping
The first thing you want to do here is make sure you’ve already created the groups you need in Okta and added users to that/those group(s). Once you’ve done that, go to the Zerto SAML application you created for the SAML 2.0 provider in Keycloak.
Create the Group Attribute Statement in Okta
When you get to the app:
Click on the General tab, then scroll down to the SAML Settings area, and click Edit.
Under General settings, click Next.
Scroll down to Group Attribute Statements and for the name, type groups.
For the Filter, select starts with and enter the prefix for all groups related to Zerto. In my example, I have two groups; one for admins called ZertoAdmins, and one for viewers (read-only) named ZertoReadOnly.
Click Next, then on the next page, click Finish
Now switch over to Keycloak.
Create the Group Mapper in Keycloak
Log into Keycloak, switch to the Zerto realm.
Click on Identity Providers, then click on your Okta SAML provider.
Click on the Mappers tab at the top.
Click Add Mapper.
Provide a name to identify the mapper (i.e. ZertoAdmins, or ZertoReadOnly)
Select Force as the sync mode override. This will force an update to group membership if one was made in Okta (i.e. moving a user from the ZertoReadOnly group into the ZertoAdmins group).
Select Advanced Attribute to Group as the Mapper Type
Type in the key for the attribute (this is the “name” in the group attribute statement from Okta). This is typically “groups” without the quotes.
For the Value, input the actual name of the group in Okta (i.e. ZertoReadOnly).
Click Select group
Find the group in the list, click the arrow to the right, the click the Select button.
Click Save.
Now try logging in to Zerto.
Conclusion and Troubleshooting
After you’ve completed this step to map groups from Okta into Keycloak automatically, Keycloak will look for group memberships in the claims that come through with the login request. If Keycloak sees a match based on the mappers you have set up, then the user will automatically be assigned to the right group/role in Zerto and be allowed access.
Troubleshooting Note: Make sure when you created the group in Keycloak that you have added the necessary role to the group, because if the group isn't assigned to any Zerto role, then on login that user will get kicked back to the Okta login page.
rcFederation Tracer: If you’re setting this up for the first time and want to see what claims are coming through on your requests (again, thanks for the recommendation on this utility, RH!), take a look at SAML, WS-federation and OAuth tracer (installs as a browser add-in) to be able to see what is in your web requests as the communication between Keycloak and Okta take place.
Here’s an example of seeing the attributes Okta passes over to Keycloak on authentication:
Well, I hope this was helpful, and as always, if you have questions or comments, I’d love to hear your feedback. Please also share this with anyone who may find it useful.
Did you know that when the Linux-based Zerto Virtual Manager Appliance (ZVMA) was released, the way Zerto handled permissions has completely changed, giving you more control over who has access and what type of access they have?
In the old days (like a year ago, and to some still currently on the Windows-based ZVM), Zerto permissions were really an extension of vSphere permissions. When Zerto got installed on a Windows VM, part of that installation process created roles and permissions within vCenter that you could use to grant users access to certain Zerto functionality, if not all functionality. This was because Zerto mainly relied on whether or not you or any user trying to get into Zerto had an account with access to vCenter. For those who knew about it and used it, it worked, however, it left much more to be desired, like true RBAC and eliminating the possibility for any old vSphere Admin to have complete control over Zerto.
Today, as of the Zerto 9.7 Linux appliance and into 10, managing access in to Zerto has been decoupled from vSphere permissions and brought into Zerto through Keycloak, not to only provide RBAC, but to also provide an additional layer of security and more integration options for access management. Now the only connection into vSphere is a service account, and all user access into Zerto is based on having access granted through Keycloak.
Identity Provider Options
When you take a look at what type of integrations are available with Keycloak, it can be a little overwhelming, however, as long as it has what you need, you likely won’t care for what else is there, right? There are currently 18 built-in options for identity providers and user federation options (pictured below). I’d say there are likely many more when you consider that anything else that can be connected to with OpenID Connect, SAML v2.0, Kerberos, and LDAP/s are also available.
With a plethora of options available, the two most common ones I hear as customer needs today are Okta and Active Directory, and I’ve already published a YouTube video for Active Directory integration via LDAPs, so this update is going to be specific on how to set up Okta integration via SAML v2.0.
The goal here in this post is to list out the order of operations and the steps required to perform so that when you log in to Zerto, instead of pre-creating an account in Keycloak, you’re going to rely on an existing account in Okta that has access to Zerto, with the added benefit of push-button MFA.
Configuration
Procedure Overview
So I’ve tested this with both OpenID Connect, and SAML v2.0 Identity providers, and I’ve come to the conclusion (and verified with some customers I’ve encountered who were also Okta customers) that configuring this integration via SAML v2.0 is much simpler, and doesn’t require banging head on keyboard. Having no prior experience setting this identity provider up took less than an hour from start to finish, so it was extremely simple.
So if you want to do this in one sitting, there are five main steps in the procedure that I counted.. okay, 6 if you want to include deploying the ZVMA and getting it on the network, which I won’t cover here:
Note: Keycloak and Okta have the tendency to automatically log your session out if you leave them idle for too long, so be sure to keep those sessions active while you’re jumping between the two.
Deploy, configure, and license the ZVMA
Configure the SAML 2.0 provider in Keycloak
Create the Okta Application and download the signing certificate
Configure mappers to map user attributes from Okta into Keycloak
Upload and import the Okta signing certificate to the ZVMA and Keycloak trust store
Logging in to Zerto
One thing to note is that when you’re performing steps 2,3, and 4 above, you may want to have both Keycloak and Okta open at the same time, because there are some values that they will be trading back and forth. Having both open allows you to complete them in parallel and make for a smoother experience.
I will also include at the end of this write up a “next steps” optional but recommended step that comes after logging in for the first time, so be sure to read all the way through, because it will be about RBAC assignment to the Okta user that has been logged in.
If you have any questions, please ask them in the comments.
Configure the SAML v2.0 Provider
Log into the Keycloak administrator interface on the target ZVMA via https://[FQDNorIP]/auth (replace [FQDNorIP] with the FQDN or IP address of your ZVMA).
After you’re logged in, you will see a drop-down list at the top left that defaults to “master.” Click there and select zerto from the list to change into the Zerto realm of settings.
In the left navigation bar, under configure, select Identity providers.
From the selection screen, choose SAML v2.0
Enter the information as shown in the screenshot below, and note that you cannot change the Redirect URI, however, you will need this when configuring the Okta app, so copy it and have it ready to go when you get to the Okta configuration portion below.
In the SAML Settings area, disable the setting labeled “Use entity descriptor.” Once disabled, more fields will appear below in the SAML settings.
Before filling anything out further, open another browser window and log in to the Okta admin site to create an app for Zerto, because now you’re going to need to gather/enter URIs in both Keycloak and Okta.
Create and Configure the Okta Application and Download the Signing Certificate
In the Okta admin, expand Applications in the left navigation bar, and select Applications from the nested options.
Click on Create App Integration
For the name, enter Zerto SAML, then click Next.
Under General, where it asks for the Single sign-on URL, enter the Redirect URI that was automatically created in Keycloak. Refer to step 5 above where you started setting up the SAML v2.0 provider in Keycloak.
Enable the ckeckbox labeled “Use this for Recipient URL and Destination URL.”
Leave everything else as default, then scroll down and click Next.
The next page is for feedback, so select the following options and click Finish. You will be returned to the applications page.
On the applications page, click the gear icon to the right of the Zerto SAML app you just created, and select Assign to Users.
For each user that requires access to Zerto, click the Assign link to the right of their name to add them to the app. Without assigning them, they won’t be able to login to Zerto using their Okta account. Optionally, you can create a group in Okta and assign your users to that instead of individually here.
When you click on Assign, another box will pop up with the user name in the box. Click Assign and go back to be returned to the main list of users. If there are more users to add, repeat the previous step, otherwise, you can close the window with the list of users.
Back on the applications page, if you click on the app, you will see your added users/groups in the list.
Now, download the signing certificate. Click on the Sign On tab at the top.
Scroll down to the SAML Signing Certificates section and find the active certificate. At the right of that active certificate, select Actions > Download Certificate. This is what you will be uploading to the ZVMA and importing to Keycloak, so keep track of it. Save the certificate as a .cert file (which should be what it defaults to).
Now you need to get a couple of URLs from Okta to use in Keycloak. Click on the Sign On tab for the Okta application.
Scroll down to the SAML 2.0 section. Beneath the Metadata details header, click on the link that says more details.
Copy the Sign on URL and the Sign Out URL
Now return to Keycloak to continue the SAML v2.0 provider configuration.
Return to Keycloak
In the SAML Settings section of the SAML v2.0 provider you’re configuring in Keycloak, find the Single Sign On Service URL field and enter the Sign on URL that you copied from Okta in the previous step.
For the Single Logout Service URL, past the Sign Out URL you copied from Okta in the previous step. When done, it will look similar to the image below:
Leave all other fields as default. Click Save.
Scroll down to the Advanced Settings and verify the following settings:
First login flow: first broker login
Post login flow: none
Sync mode: Import
Click Save.
Configure Mappers for Attribute Import From Okta to Keycloak on Login
Mappers will be used between Okta and Keycloak to easily import user attributes on login to Zerto. If you do not provide mappers, then on first login, the user will be prompted to enter their e-mail address, first name, and last name. The idea with configuring mappers is to bring those attributes over from Okta to populate the fields in Keycloak for the user automatically, so the login is much more seamless.
First we will configure the attribute mapping in Okta, followed by the mapper configurations in Keycloak.
Okta Mapper/Attribute Configuration
Log onto the Okta administration page.
Go to the SAML Application that you previously configured in Okta (probably named Zerto SAML).
On the General tab of the application, scroll down to the section labeled SAML Settings and click Edit.
Click Next.
On the Configure SAML step, scroll down to the Attribute Statements section and add the following attributes. These will map Okta user attributes to Keycloak user attributes for simpler login as mentioned above.
Scroll down and click Next.
Click Finish.
Keycloak Mapper Configuration
Configure the Mappers for users’ e-mail, first name, and last name in Keycloak to be brought over to their Keycloak account automatically on login.
In Keycloak, click on the Okta SAML provider you configured.
Click the Mappers tab at the top, then click Add Mapper.
Add the mapper for the user’s first name. Complete the fields as shown in the image below, then click Save.
Go back to the Mappers tab, and add another mapper for the user’s last name this time (see image below for values to use). Click Save.
Go back to the Mappers tab, and add another mapper for the user’s e-mail address this time (see image for values to use). Click Save.
Upload and Import the Okta Signing Certificate to the ZVMA and Keycloak Trust Store
Update: I decided to include the certificate import steps here, but left the link to the original Zerto documentation as others have been asking for it and felt this would be more “complete” with it inline.
Upload the Okta certificate to the ZVMA. Put the file in the following location: /var/data/zerto/zkeycloak/certs/
Use PuTTy or other SSH client to log onto the ZVMA. If you are doing this via the vSphere console, select 0 from the appliance manager menu to exit to the shell.
Run the following command to add the certificate to Keycloak’s trust store:
You will be prompted to enter the keystore password. Use the password below. If for some reason you are asked to change that password, use the same one, don’t change it.
truststorepass
When prompted to trust the certificate type yes and press enter.
Finally, fun the following command to kill the current pod and run the updated one with the certificate in place
kubectl delete pod zkeycloak-0
You can now end your SSH session and start logging in to Zerto via the Okta SAML login method.
Original Zerto documentation for importing certificates into Keycloak’s truststore:
After you’ve completed all the steps previous to this section, you can start logging in to Zerto. One thing to note is that when you login via your Okta credentials, the user loggig in (if given access to the Zerto SAML app via Okta) will be logged into Zerto, and if you look in the Users section of the Keycloak Zerto realm, there will also be an account created in there for the user.
By default, the user being given access through this method will have admin rights to Zerto. If you would like to minimize permissions or access into Zerto with, for example, read-only access, you can visit the following URL where I have previously wrote about how the Role-based Access Controls work within Zerto. Optionally, you can import group attributes from Okta the same way you mapped user attributes, however, that is out of scope here.
That’s all I’ve got for this time. I hope you’ve found this useful and if so, please share it with others who you feel will find it useful as well. For any questions, please leave a comment!
Update: Mapping Okta Groups to Keycloak Groups
After you’ve gone through this, you’re probably wondering how you can also automatically map Okta groups into Keycloak for Zerto access. Please see my follow-up blog post on Mapping Okta Groups to Keycloak (SAML 2.0) to continue from here and get your groups mapped over automatically. By doing this, you will avoid having to add users to Keycloak groups after their first login.
My previous post explained how to perform a Zerto Windows ZVM migration to the Linux ZVMA in a situation where you have two NICs on your ZVM for traffic separation. But, what about everyone else who is running a standard deployment of Zerto with single-NIC ZVMs? I mean, the process has got to be simpler, right? The answer to that is yes. There are a lot less steps involved since we’re not going to be dealing with additional network interfaces and fumbling around with persistent routing in Windows and Linux, and then remembering we had that in place months, or years later!
When thinking of how the migration process works when moving from Windows to Linux, I can’t help but feel that the product team at Zerto couldn’t have come up with a simpler and more elegant way to accomplish this. I mean, its like having a “penguin” standing outside a “window” holding a box, while you full-send all the data held behind that window into the box – and then tell the penguin he is now all things that window was.
Well, that was fun (and thanks to Dall-e for creating that image for me), but realistically, it’s as simple as four main steps (and one pre-req). Also, there’s a video at the end of this if you don’t feel like reading; which will walk you through the migration of both sites.
Pre-req: Windows ZVM Must be on Zerto 9.7U4patch2
Oh yeah, it might help you if you also double-check the Interoperability Matrix to make sure the intended versions of Zerto are compatible with your version of vCenter and ESXi.
Deploy the Linux Zerto Virtual Manager Appliance to vCenter
Download and run the Zerto Migration Utility from the Windows ZVM
Log into the Zerto UI and validate
Repeat for the recovery site
Below, I’ll break down each of those three steps to provide a little more color about what is involved with each one. Trust me, if you prep everything in a way you can simply just move from one step to the next, it’ll all go smoothly and before you know it, you’re done.
If you’re wondering where to start and not sure if you should do the protected or the recovery site first, I usually start with the protected site because if that’s down while it’s being migrated, and you need to perform any type of recovery, at least you’ll still have the recovery site intact. Or you could prefer to migrate the recovery site first. It’s totally up to how you would normally upgrade Zerto when new releases are out. Just make sure you complete one site before starting on the next.
Step 1: Deploy the Linux ZVMA to vCenter(s)
So the very first thing you need to do is to make sure you have all your Windows ZVMs upgraded to the latest version of Zerto, which is at the time of this writing, 9.7U4patch2.
Next, head to https://www.zerto.com/myzerto, go to Support and Downloads, and download version 10.0U2 of the Zerto Virtual Manager Appliance (Linux). This comes as an OVF, so there’s no need to build your own Linux VM. Just simply download the OVF and deploy it as you would any other virtual appliance in that format in vCenter.
Once you’ve deployed the ZVMA to each vCenter, power them up. You’re going to do a couple of things (in this order):
Once booted up, login with the username: zadmin and enter the default password, which is: “Zertodata123!” (without the quotes). You will be prompted to change the password to something more secure that matches your policy guidelines for passwords.
Once logged in, you may see the appliance enter an initialization stage – this may take several minutes, but typically goes pretty quick before it displays the appliance manager menu. Follow the steps in order below because if you start with the network settings, you’ll have to reboot before you can enable SSH.
Select option 7 to enable SSH. Once enabled, you’ll be returned to the appliance manager menu.
Press 2 and configure static IP settings for the appliance. This IP address will only be used temporarily, so you won’t need to create a DNS record for it, or anything like that. Ultimately, the IP address of this appliance will be the IP address your Windows ZVM is using prior to the migration. Once you’ve configured your IP settings, the appliance will let you save the settings and then tell you to reboot to complete the network configuration.
That’s it. You are done preparing the appliance for the migration.
Step 2: Download and Run the Zerto Migration Utility from the Windows ZVM
Go to https://www.zerto.com/myzerto and download the Zerto Migration Utility from support and downloads (same place you got the Linux ZVMA OVF). Save the migration utility to the desktop of the Windows ZVM.
Open a Remote Desktop connection to the Windows ZVM. Once logged in, run the migration utility (right-click –> Run as administrator). Oh yeah, get yourself another temporary IP address for this server, because the Migration Utility will need it.
When the migration utility starts, the first screen will have a link to a “read me.” You’ll need to click that link before the “Next” button is enabled.
Click next.
Enter the IP address for the Linux ZVMA and the password for the zadmin account, then click Verify SSH Connectivity button. After that connectivity is confirmed, click Next.
Now, enter that temporary IP address I mentioned 4 steps ago and complete the rest of the network settings, then click Next.
Review the Summary screen, and then click Migrate when ready.
Within a few seconds, your RDP connection will drop you – that’s because the alternative IP has been applied to the Windows ZVM. Just re-connect your RDP session using that alternative IP that you entered. The migration utility will still be running.
Once the migration completes, and says it’s successful, you can shutdown the Windows ZVM. Notice how the screen also includes a link to the IP address that was previously assigned to the Windows ZVM for production use. This IP address has now been assumed by the Linux ZVMA. If you’re using DNS and FQDNs to access Zerto, now might be a good time to update DNS to reflect the change.
NOTE: Do not run the uninstaller for Zerto from the Windows Add/Remove programs. Doing this will delete VPGs, uninstall VRAs, unpair sites, and remove the Zerto plug-in from vCenter. In other words, IT WILL BREAK YOUR ZERTO IMPLEMENTATION. Just delete the Windows ZVM after you’ve migrated all sites from Windows to Linux successfully.
Step 3: Login to the Zerto UI and Validate
Open your browser, and connect to Zerto using the original IP address of the Windows ZVM (see the “Migration Completed” image above for reference) that was moved over to the Linux ZVMA. The new URL to access Zerto is https://[IPorFQDN]. Note, there is no port 9669 after the host name. The appliances uses port 443 for the UI.
Login using the following credentials. Since it’s the first time you’re logging in, you will be prompted to change the password.
User: admin Password: admin
When you first login, you’re likely going to see some alerts. Give Zerto a few minutes – those will all go away. Don’t get impatient like I did, you’ll end up in a troubleshooting frenzy only to find out that it all will settle down if you just give it some time. After all, Zerto just underwent brain surgery, it will need to heal.
While the healing is going on, click around to Sites, VPGs, Setup, etc. If you also selected to upgrade the VRAs automatically, you’re probably going to see a bunch of that activity taking place too, so keep an eye on the vSphere tasks as well as the alerts in Zerto to get an idea of what’s happening.
Once everything settles, login to the recovery site UI and make sure it sees the same things the protected site is seeing in terms of the Zerto status.
Step 4: Delete the Windows ZVM
Once you’ve gotten both the protected and recovery sites migrated to the Linux Zerto Virtual Manager Appliance, you can now clean up – remember – do not uninstall Zerto from those old Windows ZVM VMs. It will break Zerto. The best thing to do is to delete those old ZVMs after both sites are successfully migrated and you have validated that everything works.
Thanks for stopping by! Please leave a comment if you have any questions or to let me know how this worked out for you. And if you found this useful, please share it with others who you feel it could help.
Here’s a video to show you how the above process works. Enjoy!
It’s a new year, and along with that comes a whole lot of “new things.” New things may come in the form of resolutions, new gym memberships, new jobs… you get the point. And while it’s not so new today, Zerto 10 has delivered a new architecture for the Zerto Virtual Manager. So to some, a new year’s resolution could mean finally moving off of Windows, and onto a more secure and capable Linux-based Zerto Virtual Manager.
And if you’re like me, new things make us remember old things. In fact, I had totally forgotten that I wrote an article about bolting on (virtually) a second network interface to my ZVM back in 2016 to meet a network security requirement. Apparently, that was found useful to others, and it has come full circle, so I’ll share how to get that specific configuration from Windows to Linux without breaking Zerto (for too long). You can read the original post here.
The “Good to Know” Stuff
The blog post contains a lot of information related to the tasks performed, so it will be helpful to be familiar with a few things. I also did not write this as an in-depth “how to build your lab” write-up. Also, this is specific to vSphere environments and does not cover any public cloud Zerto environments.
If you want to build a lab to try this out, you can build it according to the diagram below in the “Lab Configuration” section. Then follow my Dual NIC ZVM post to configure your Windows in-guest routing.
Zerto Resources and Documentation
There is quite a bit of information that you’re required to understand before migrating from the ZVM to the ZVMA, and it’s the usual stuff like version compatibility, pre-requisites, etc, etc… So I’ve put everything here in case you need to review or are in planning.
Zerto Virtual Manager Appliance (Linux-based): Understand the pre-requisites for running the ZVM Appliance in your environment. Refer to the interoperability matrix to see what is compatible with Zerto 10+
Zerto Port Usage: You will need to familiar with this in order to create the proper network separation, including any firewall ports required to segregate traffic for Zerto management and replication networks.
.
The Lab Configuration
Below you’ll see a very high-level diagram of what this setup looks like in my lab if you’d like to build a lab out to follow along. How you achieve the network separation is up to you. In my lab, I didn’t have multiple subnets in each site, so I got creative and used a combination of Windows Defender firewall policies and in-guest persistent routes based on IP addresses. The main goal of this post is to get you migrated from a dual-NIC Windows ZVM to a dual-NIC Linux ZVMA.
What you’re seeing below is that the network interfaces connected to the green lines are all meant to communicate “administrative” traffic with each other. This is the network where your OS patches will be delivered, domain authentication takes place, and/or users will access the Zerto UI. They are also the interfaces over which you will pair Zerto sites.
The interfaces connected to the magenta lines are all meant for VRA-related traffic. This includes things like ZVM management control of VRAs, managing checkpoints, and log collection. The actual data being replicated for protection by Zerto will also flow on this network and is being managed by the VRAs through direct connections the source and target VRAs make with each other. Again, refer to the Zerto Ports Usage link above for more information.
Windows ZVM to Linux ZVMA Migration
If you’ve made it this far in, you’re likely already running Zerto in your environment in a dual-NIC configuration and are looking to migrate to the Linux ZVMA, and have probably read this kb article. At the very bottom of that article, there’s some text stating that migrating a dual-NIC ZVM is not supported and that the recommendation was to “move” to a single NIC prior to migrating, then add it back afterwards. This is also called out in the Migration Utility Pre-requisites documentation.
What that really means is that during the migration, the utility will not allow you to migrate if there is still a second NIC on your Windows ZVM. I have included the steps below to get past that, but you’re still going to have to build that second NIC on the Linux ZVM post-migration, and I also cover that in detail.
The Migration Steps, In order
Below you will find a high-level set of steps to take to complete the migration. This procedure assumes you have two (2) NICs on each ZVM that needs to be migrated over to Linux, and that you have read the Zerto Migration Utility Pre-requisites documentation. Having some networking experience and being able to configure routing in Windows or Linux would also be helpful.
Tip: Have at least four IP addresses available to use as temporary IP addresses (two per site) during the migration process.
If you don’t want to read through these steps or want a more detailed demonstration of a complete migration, there’s a video at the end of this post that I created to walk you through the entire process. If there is any section that requires configuration text, I will include that below.
Important: Always complete the migration on one site before starting the second site. The steps below will only pertain to the site you’re working through migration on. When you are done with that first site, start again at step 1 for each remaining site.
If this is being done for production – it helps to open a proactive (lower severity) support case with Zerto for visibility to let them know you’re going to start migrating your ZVM to Linux. This way, should you run into any issues along the way, you can call Zerto support and reference the existing case.
For each site that you will be migrating, make sure you upgrade the Windows ZVM to the latest Windows version of Zerto. The last version of Zerto supported on Windows is 9.7U4p2, which was released on November 28, 2023.
Again when upgrading, be sure to complete the upgrade on one site before moving to the next. Don’t forget to upgrade the VRAs as well.
Download the Linux-based ZVMA (version 10.0U2, released November 28, 2023) from MyZerto
Deploy the OVF in the vCenter that has the Windows ZVM you are going to migrate to Linux.
You’re going to need 1 temporary IP address for the ZVMA.
After you delpoy the OVF, power the ZVMA on, and login using the zadmin user. The default password can be found in the Appliance Manager Menu documentation.
Once logged in, you will see the Appliance Manager menu.
Select option 2 to configure a static IP address using the temporary IP address from above.
Reboot when prompted
After the reboot, log back in and this time use option 7 from the Appliance Manager Menu and enable SSH (this is required by the migration utility).
Download the Zerto Migration utility (version 10.0U2, released December 4, 2023) from MyZerto
Save the .zip file to the desktop of the Windows ZVM
Extract the contents of the zip file to the desktop of the Windows ZVM
Optional, but recommended: In vCenter, take a snapshot of the Windows ZVM to give yourself a point in time you can recover to should you need to.
Open an RDP connection to the ZVM open the folder that contains the migration utility.
Before you run the migration utility:
You will need 1 temporary IP address for this Windows ZVM.
Because the migration utility doesn’t support migration when there are two NICs on the Windows ZVM, you will need to disable the second NIC.
Go to the Network Connections in Windows.
Right-click on and disable the second NIC. This NIC will stay disabled throughout the rest of the process. The migration utility will not do anything to this second NIC.
Run the migration utility entering the required inputs throughout the wizard.
At the summary screen, un-check the box to Upgrade VRAs because the VRAs reside on the network managed by your second NIC, you won’t be able to get to them, so it’s best to wait until you’ve re-applied that second NIC on the ZVMA after the migration has been completed.
Once the migration utility starts to run, you will get disconnected from your RDP session. This is normal because the IP address has been changed.
Log back in to the Windows ZVM via RDP using the alternative IP address you provided.
The migration utility will still be running.
Exit when the migration completes.
If the migration succeeded, shutdown the Windows ZVM that you have just migrated. DO NOT ATTEMPT TO UNINSTALL ZERTO FROM THIS WINDOWS ZVM.
If the migration doesn’t succeed, the utility will actually rollback the changes. If you don’t wish to proceed, re-enable that second NIC after the original IP address is re-instated to the Windows ZVM (original IP re-instatement will be done by the migration utility).
More importantly, if you encounter the error in the image below, it is not a show-stopper. This check can be bypassed, however, you will need to contact Zerto support to obtain the necessary fix. Unfortunately, I’m not authorized to post that fix publicly.
Next, we will need to work with the Linux ZVMA, so open up either the vSphere console or a PuTTy session to the ZVMA. Remember, after successful completion of the migration utility, the IP address for the ZVMA will be the original IP address that the Windows ZVMA had.
Once logged onto the ZVMA, you’ll see the appliance manager menu. Use option 1 to display the current network settings. You’ll see that the primary IP address is the old IP address of the Windows ZVM. Take note of the Primary NIC Name, as this will be helpful to know when we configure the second NIC.
Press enter to return to the main menu.
Because we have not yet added the second virtual NIC to the ZVMA, select option 5 to shutdown the appliance.
Once the appliance is shutdown, edit the VM settings and add a second virtual network adapter, and put it on the network that the old Windows ZVM secondary NIC was on. Save the VM settings and power on the ZVMA.
Log back in to the ZVMA, and select option ‘0’ to Exit to the Shell. We will now start configuring the second NIC. The steps we will take are also listed in this KB article, so you can follow along with that to get your second NIC configured and saved. The screenshot below will show the format to use when entering the NIC settings since they are not formatted in the KB article.
Once you’ve saved the configuration file and exited nano, we will configure the persistent routing required to make this new NIC route traffic to your replication network correctly (similar to what you have done on your Windows ZVM, but because it’s Linux, it’s a bit different).
If you are watching the my video on this - you will need to skip toward the end (22:28) to watch the routing configuration section. In this write-up, this is the point where you will be configuring routing.
While there are different ways to create the routing in Linux, the steps below will ensure they are persistent through reboots of the appliance.
From the shell, we’re going to first create a routing table to use in later steps:
sudo nano /etc/iproute2/rt_tables
In the rt_tables file, add a line to create a routing table to use. Follow the format in the image below. The number you use can be anything, but must be unique – don’t use the same number as any existing entries. The name can be anything you want it to be, just remember both the number and name, because it will be needed in the next steps.
Use CTRL+O to write out (save) the file, then CTRL+X to exit nano.
Now we’re going to go back in to the /etc/network/interfaces file and add our routing configuration.
sudo nano /etc/network/interfaces
Go to the end of the file and add the following lines. Replace “100 zertoens224” and any instance of “zertoens224” with whatever you used in the previous step to create the routing table.
There’s also an image for you to reference at the end of this step:
Use this if you want to route to specific IP addresses:
#create the routing table on boot for the rules to use post-up echo "100 zertoens224" >> /etc/iproute2/rt_tables #create the ip rule for this interface and add it to the table post-up ip rule add from [your ens224 IP address] table zertoens224 post-up ip route add [IP Address of the VRA] dev ens224 table zertoens224 post-up ip route add [IP Address of the VRA] dev ens224 table zertoens224 [add more lines as needed]
Use this if you want to route to entire subnet(s) – replace [0.0.0.0/24] with your own network:
#create the routing table on boot for the rules to use post-up echo "100 zertoens224" >> /etc/iproute2/rt_tables #create the ip rule for this interface and add it to the table post-up ip rule add from [your ens224 IP address] table zertoens224 post-up ip route add [0.0.0.0/24] dev ens224 table zertoens224
Use CTRL+O to write out (save) the file. Use CTRL+X to exit nano.
At the shell type appliance-manager to return to the appliance manager.
Select option ‘4’ to reboot the ZVMA.
To verify the settings, log back into the ZVMA, and select ‘1’ from the appliance manager to show the current configuration file contents for the network. You will see all the new routing entries in there.
To test connectivity, you can run ping -R [destination VRA IP address] from the shell and you’ll see what interface the ping goes out of and returns on (example image below).
You can now exit the shell and close your session with the ZVMA.
Log onto the Zerto UI at https://[PrimaryIPaddressOfZVMA]
Username: admin Password: admin
Since this is the first time you’re logging into the Zerto UI on the ZVMA, you will be required to change the password, so set it to something appropriate for your environment or to meet your password requirements.
Verify the dashboard shows everything as healthy – just note that because we just added that second NIC, it might take a few minutes for things to right themselves, so you might see some alerts regarding site connectivity. Because the primary NIC was online, it’s unlikely at this point you’d see a site connectivity alert.
Go to the Setup tab, and you will notice that the VRAs all state that there is an upgrade available. At this time, you can start upgrading the VRAs.
After all VRAs are upgraded, monitor Zerto to make sure things are returning to green/normal. If you see any issues, contact Zerto support and reference your support case opened in Step 1.
Once everything returns to “normal” you can now turn your attention to your second site and go back to step 1 in this procedure to repeat the process until you’ve completed the migration in each environment/site.
Summary
I get it, change isn’t always welcomed, but without change and without innovation, we become stagnant and comfortable with accepting what’s “normal.” Hopefully, the past few years have changed our impression of change and what’s “normal.” I figure, since it’s also a new year, let’s meet some new challenges and overcome them clear any obstacles for the year, so we can keep moving forward!
With planning and reading up on the documentation to perform the migration from the Windows ZVM to the Linux ZVMA, the process is very straightforward. My recommendation is to gather all the pre-requisites, and verify that you meet all the version requirements prior to getting started for the most efficient route to completion. Its also helpful if you are fortunate enough to have a lab environment to go through this at least once to see how it works for yourself and document any differences in your own environment that need to be accounted for before pulling the trigger on this migration.
If you’ve performed the migration, or have any questions before you do, please leave a comment below, or in the video comments on YouTube (video below). Thanks for reading, and if you’ve found this useful or know anyone who could benefit from this, please share!
