RMM 7.4 GUI Operations Guide v1.13

JANUARY 2024
RMM 7.4 GUI OPERATIONS GUIDE
RACKWARE INC
VERSION 1.13
Contents
1 Overview ............................................................................................................................................... 4
2 Getting Started...................................................................................................................................... 5
2.1 High Level Migration Steps .......................................................................................................... 6
2.2 High Level DR Steps ..................................................................................................................... 7
3 Gathering Source Server Information ................................................................................................... 8
4 Prepare the Source Servers................................................................................................................... 8
5 Install the RMM in the Target Cloud ..................................................................................................... 9
5.1 RMM Sizing Considerations ......................................................................................................... 9
5.1.1 OCI (Oracle Cloud Infrastructure) ........................................................................................... 9
5.1.2 Azure Cloud ........................................................................................................................... 10
5.1.3 Google Cloud ......................................................................................................................... 11
5.1.4 Zadara Cloud ......................................................................................................................... 12
5.2 Installing the RMM .................................................................................................................... 13
5.3 Verify RMM is Running .............................................................................................................. 13
6 Prepare RMM Waves .......................................................................................................................... 14
6.1 Using the GUI to Create a Wave ................................................................................................ 15
6.2 Using an Input (.csv) File to Create a Wave ............................................................................... 18
6.2.1 Entering values in the template .csv file ............................................................................... 18
6.2.2 Uploading the template .csv file ........................................................................................... 20
6.3 Setting the Parallel Count .......................................................................................................... 20
6.4 Starting a Wave ......................................................................................................................... 21
6.5 Create DR Policy ........................................................................................................................ 21
7 Defining Cloud Parameters ................................................................................................................. 24
8 Autoprovisioning the Servers.............................................................................................................. 26
8.1 Performing a Stage 2 Sync/Host Sync with Autoprovisioning ................................................... 26
8.1.1 Performing a Stage 2 Sync with Autoprovisioning ................................................................ 26
8.1.2 Performing a Host Sync with Autoprovisioning .................................................................... 31
8.2 Performing a Failover (DR) ........................................................................................................ 32
8.2.1 Failover in Test Mode ............................................................................................................ 33
8.2.2 Failover - Actual Failover ....................................................................................................... 34
2
RackWare Inc • Proprietary and Confidential
8.3 Performing a Fallback (DR) ........................................................................................................ 35
9 Using Pre-provisioned Servers ............................................................................................................ 37
10 Initial Verification of Target Servers ................................................................................................... 38
11 Delta Syncs .......................................................................................................................................... 39
12 Final Sync/DR Test............................................................................................................................... 40
13 Common Operations ........................................................................................................................... 41
13.1 Reprovisioning a Server ............................................................................................................. 41
13.2 Handling Sync Failures ............................................................................................................... 43
13.3 Retrying a Failed Sync Immediately........................................................................................... 44
13.4 Stop, Pause Syncs ...................................................................................................................... 45
13.5 Storage Monitoring ................................................................................................................... 46
13.6 Deleting a Wave......................................................................................................................... 49
13.7 Adding a Server to Wave ........................................................................................................... 49
13.8 Disabling a Sync ......................................................................................................................... 50
13.9 Editing a Sync ............................................................................................................................. 51
13.10 Deleting a Sync ...................................................................................................................... 52
13.11 Checking License Status ........................................................................................................ 53
13.12 Moving a Sync to a Different Wave....................................................................................... 53
13.13 Sync Options.......................................................................................................................... 54
Appendix 1 Sync Options Description .................................................................................................. 56
Appendix 2 Adding Storage to ZFS Pool ............................................................................................... 65
Appendix 3 RMM PostScript Sample ................................................................................................... 66
3
1 Overview
This document walks through the steps of using the Rackware Management Module (RMM) GUI to
migrate a group of servers to a cloud or to protect a group of servers by setting up a Disaster Recover
(DR) site in a cloud. The steps are the same no matter where the current production servers are, or to
which cloud they are being migrated. The environment of the current production servers is referred to
as the “source” or “origin” environment, while the environment of the cloud to which the servers are
being migrated is referred to as the “target” environment.
The RMM generally resides in the target site (which is the DR site if using the RMM for DR). If it is
required that the IP addresses in the target site be the same as in the source site then IP NATing can be
done on the source site to achieve this.
There are two types of syncs that can be done, Staged Syncs or host syncs. With Staged Syncs, the
contents of the origin servers are “captured” and stored in images on the RMM. During the RMM
installation, space needs to be allocated for the images. An image can be refreshed periodically to be
kept in sync with the origin server. This phase of a Staged Sync is referred to as a Stage 1 Sync. The
images are then synced to the target servers. This phase of a Staged Sync is referred to as a Stage 2
Sync. This method is recommended when setting up a DR site. Staged Syncs are required if using the
RMM’s backup and selective file restore feature.
With host syncs, the contents of the origin host are copied (and refreshed) directly to the target server.
Storage for images is not needed. This method is recommended if doing just a migration. Host syncs
should not be used for DR - if a host sync is interrupted during a sync (perhaps due to a DR event) the
target server may not be able to boot. If the reason for the interruption was because of a disaster, the
origin server might also be unable to boot.
4
The target servers may be autoprovisioned or pre-provisioned. In most cases autoprovisioning is used.
With autoprovisioning, the RMM must be given the credentials of the API of a cloud and told where to
provision the servers. The target servers, if they do not yet exist, are then created automatically when a
Stage 2 Sync or a Host Sync is performed.
There are rare cases when a target server needs to be pre-provisioned. This is done by someone logging
in to the cloud and manually creating a target server with the desired attributes, including an IP address.
When pre-provisioning servers, the RMM does not need to know the credentials of the cloud or where
to provision the server since it is already provisioned. The RMM will identify the target server by its IP
address. After the server is created, a Stage 2 Sync or a Host sync can be performed to the target server.
If a Host Sync or a Stage 2 Sync is being done with autoprovisioning, it is referred to as a “Host
Autoprovision Sync” or “Stage 2 Autoprovision Sync”.
If a Host Sync or a Stage 2 Sync is being done to an existing system (ie the target was pre-provisioned, or
it has already been autoprovisioned) then it is referred to as a “Stage 2 Delta Sync” or “Host Delta Sync”
because only the changes (the delta) from the source host are being synced to the target host.
Additionally, Staged Syncs may be done with Dynamic Provisioning when using the RMM to set up a DR
site. In this method the contents of the origin servers are “captured” and stored in images on the RMM
as with a Staged Syncs. Those images are refreshed by performing syncs from the source server to the
images on the RMM (Stage 1 Syncs). Nothing is provisioned in the target cloud until a Failover is needed
or a DR test is performed. At that time the servers will be automatically provisioned into the target
cloud and assigned the images from the RMM via a Stage 2 Sync.
A Wave is a group of servers that is migrated together. Servers are autoprovisioned into the target
environment one wave at a time. For the DR use case, a failover can be performed on a wave.
Disaster Recovery operations can be performed only if the RMM has been licensed for Disaster Recovery
operations.
2 Getting Started
The manuals referenced in this document are available on the RackWare support portal .
5
The support portal also contains “how to” videos and the RackWare Knowledge Base, containing articles
answering common questions and workarounds for when error messages are seen. Search on the error
message you are seeing or keywords of topics you would like information on to find the article you
need. The support portal also includes the RMM Diagnostics Guide, which explains the diagnostic tools
and logs that are available with the RMM.
If you do not yet have access to the support portal, please send an email to support@rackwareinc.com
to request access or to report any issues you are experiencing.
Both the source and the target environments, as well as the source servers, have requirements that
must be met for any migrations to a cloud to be successful. Please see the RMM Prerequisites and
Operational Requirements Guide for the prerequisites for the RMM server, the source servers, and the
source and target environments. Please ensure that the prerequisites are in place before attempting
any migrations.
If you are not using the RMM from a cloud’s Marketplace, the RMM software will need to be installed.
Please see the RMM Installation Guide for instructions on installing, upgrading, and licensing the RMM
software.
2.1 High Level Migration Steps

At a high level the migration procedure is:
1. Verify that the source network is isolated from the target network. The only path for
communication between resources in the source network and resources in the target network
should be through the RMM.
2. Gather information about the source servers.
3. Prepare the source servers
6
4. Install the RMM in the target cloud and verify it is running
5. Prepare Waves of servers to migrate
6. Gather information about the target cloud environment (autoprovisioning)
OR
Create and prepare the target servers in the target cloud (pre-provisioned targets).
7. Use the RMM to sync the servers to the cloud, either by autoprovisioning them or using the pre-
provisioned target servers.
8. Initial verification of the servers in the target cloud.
9. Perform one or more delta syncs from the source environment to the servers in the target cloud
to capture changes (i.e., any files/folders that had been modified or deleted since the start time
of the previous sync) to the source servers since the initial migration or previous sync was
performed.
10. Quiesce the applications and perform a cutover/final delta sync from the source environment to
the servers in the target cloud.
This workflow is the same regardless of what applications or OSes are on the source server and is the
same regardless of which target cloud is being used.
2.2 High Level DR Steps

At a high level, the procedure for protecting servers (DR) is
1) Verify that the source network is isolated from the target network. The only path for
communication between resources in the source network and resources in the target
network should be through the RMM.
2) Gather information about the source servers.
3) Prepare the source servers
4) Install the RMM in the target cloud and verify it is running
5) Prepare Waves of servers to migrate and do an initial capture of a server
6) Set up a DR Policy
7) Perform delta syncs of the servers, syncing the servers to capture changes (i.e., any
files/folders that had been modified or deleted on the source servers since the start time of
the previous sync) according to the DR Policy
8) Gather information about the target cloud environment (autoprovisioning)
OR
Create and prepare the target servers in the target cloud (pre-provisioned targets).
9) Use the RMM to autoprovision the servers
10) Initial verification of the servers in the target cloud.
11) Resume performing delta syncs of the servers
12) Perform a DR test.
This workflow is the same regardless of what applications or OSes are on the source server and is the
same regardless of which target cloud is being used.
7
3 Gathering Source Server Information
For each source server, the hostname, OS, and IP address of the server should be obtained to identify
the server. The IP address must be an IP address over which the source server can communicate with
the RMM server.
If you are planning on manually creating the target servers in the target cloud, then in order to have the
target servers match the source servers as closely as possible, you will need to know the number of CPU
cores, the amount of RAM, and the number and size of the disks on the source servers. Putting this
information in a table as below may be helpful.
HostName IP Addr OS CPU RAM Disk 1 Disk 2 Disk 3 Disk 4 Disk 5

Cores (GB) Size Size Size Size Size
(GB) (GB) (GB) (GB) (GB)
Host1 10.1.50.1 Windows 4 8 60 200 N/A N/A N/A
2019
Host 2 10.1.50.2 Centos 2 4 40 1024 N/A N/A N/A
7.8
If you are planning on having the RMM automatically provision the target servers in the cloud, then
gathering the core/ram/storage information is not needed. The RMM will create the target servers in
the target cloud with the cpu, ram, and storage that best matches the source server specifications.
Verify that the servers you are planning to migrate meet the criteria in Chapter 6 of the RMM
Prerequisites and Operational Requirements Guide.
4 Prepare the Source Servers
Before a server can be migrated, it must be prepared such that it is compliant with the requirements
listed in Chapter 7 of the RMM Prerequisites and Operational Requirements Guide.
That chapter also describes the firewall ports that need to be open in any Cloud environment.
At a high level, the configuration needed on the source servers mainly falls into 4 areas.
- a port for ssh needs to be open on the source server and on any firewalls between the RMM and the
source server
- a user needs to be set up to be able to ssh from the RMM to the source server without requiring a
password
- there must be adequate space for snapshots on the source servers
- any antivirus software on the source servers must have rmm processes whitelisted.
8
Before attempting to migrate a server, be sure the server and the target cloud environment have the
prerequisites in place as described in the RMM Prerequisites and Operational Requirements Guide.
5 Install the RMM in the Target Cloud

If the RMM was already obtained through a marketplace, then it has already been installed.
If it has not been obtained through a marketplace, then it will need to be installed. The RMM should be
deployed on a VM instance in the target cloud. See the Chapter 5 of the RMM Prerequisites and
Operational Requirements Guide for the list of OSes on which the RMM may be installed, the disk
requirements of the RMM, and the configuration requirements of the RMM.
The primary access to the RMM will be through a web browser. If the web browser will be running on a
machine outside of the target cloud, then the RMM will need a public IP address.
5.1 RMM Sizing Considerations

The RMM Server typically runs on a virtual machine in the target cloud. Below are some guidelines for
each cloud for sizing the VM that will be hosting the RMM.
5.1.1 OCI (Oracle Cloud Infrastructure)

As a guideline, when deploying RMMs in OCI for a DR solution, install the RMM on an instance with a
shape of VM.Standard.E4.Flex or VM.Standard.E3.Flex using block storage with Balanced Performance
and an attachment type of Paravirtual. The number of OCPUs/Memory in the instance should be
either 8 OCPUs and 64 GB Memory or 4 OCPUs and 32 GB Memory. The optimum number of OCPUs
and memory for your deployment depends on the number of servers to be protected by an RMM and
the RPO time required for those servers as described below.
If you deploy the RMM on a VM.Standard.E4.Flex or VM.Standard.E3.Flex instance with 8 OCPUs and 64
GB RAM, the number of servers that can be protected on a single RMM is shown in the table below:
Average RPO time of the servers being Number of Servers being protected
protected on a single E4/E4.Flex instance with
8 OCPUs/64 GB RAM
< = 1 hour Up to 24
2 hours Up t0 30
3 hours Up to 36
4 hours Up to 40
If you deploy the RMM on a VM.Standard.E4.Flex or VM.Standard.E3 Flex instance with 4 OCPUs and 32
GB RAM, the number of servers that can be protected on a single RMM is shown in the table below:
protected on a single E4/E3.Flex instance with
4 OCPUs and 32 GB RAM
< = 1 hour Up to 12
9
2 hours Up to 15
3 hours Up to 18
4 hours Up to 20
The table below shows the recommended VM Sizes when deploying RMMs in OCI for a pure migration
solution
VM Shape #OCPUs RAM (GB) Block Volume Max # Simultaneous Migrations

Performance
E4/E3.Flex 8 64 Balanced 24
E4/E3.Flex 4 32 Balanced 12
For both migrations and DR, using two block volumes to store your images rather than 1 will in general
give better performance. For example, if you need 12 TB of storage for your images, having two 6 TB
disks will in general give better performance than having a single 12 TB disk.
If using an RMM Bridge Server in OCI as part of your configuration, we recommend its instance have an
E4.Flex shape with 2 OCPUs and 16 GB RAM. No additional block volumes are needed for the RMM
Bridge Server. A Bridge Server can be installed on RHEL7, CentOS7, OELv7, or Ubuntu 16.04/18.04.
5.1.2 Azure Cloud
As a guideline, when deploying RMMs in Azure for a DR solution, install the RMM on a VM with a VM
Size of Standard_D16s_v4, Standard_D8as_v4, or Standard_D4as_v4. The optimum VM Size depends on
the number of servers to be protected by an RMM and the RPO time required for those servers as
described below.
If you deploy the RMM on a Standard_D16s_v4, the number of servers that can be protected on a single
RMM is shown in the table below:
protected on a single Standard_D16s_v4
< = 1 hour Up to 24
2 hours Up to 30
3 hours Up to 36
4 hours Up to 40
If you deploy the RMM on a Standard_Da8s_v4, the number of servers that can be protected on a single
protected on a single Standard_D8as_v4
10
< = 1 hour Up to 12
2 hours Up to 15
3 hours Up to 18
4 hours Up to 20
If you deploy the RMM on a D4as_v4, the number of servers that can be protected on a single RMM is
shown in the table below:
protected on a single Standard_D4as_v4
< = 1 hour Up to 6
2 hours Up to 7
3 hours Up to 9
4 hours Up to 10
The table below shows the recommended VM Sizes when deploying RMMs in Azure for a pure migration
solution
VM Size Max # Simultaneous Migrations
Standard_D16s_v4 24
Standard_D8as_v4 12
Standard_D4as_v2 6
If using an RMM Bridge Server in Azure as part of your configuration, we recommend have a machine
size of Standard_D4as_v2. A Bridge Server can be installed on RHEL7, CentOS7, OELv7, or Ubuntu
16.04/18.04.
5.1.3 Google Cloud
As a guideline, when deploying RMMs in Google Cloud for a DR solution, install the RMM on a VM with a
Machine Type of C2-standard-16, C2-standard-8, or C2-standard-4. The recommended machine type
depends on the number of servers to be protected by an RMM and the RPO time required for those
servers as described below.
If you deploy the RMM on a C2-standard-16, the number of servers that can be protected on a single
protected on a single C2-standard-16
< = 1 hour Up to 24
2 hours Up to 30
3 hours Up to 36
4 hours Up to 40
11
< = 1 hour Up to 12
2 hours Up to 15
3 hours Up to 18
4 hours Up to 20
< = 1 hour Up to 6
2 hours Up to 7
3 hours Up to 9
4 hours Up to 10
The Machine Type of the VM on which the RMM will run varies depending on how many simultaneous
migrations you wish to perform.
Machine Type Max # Simultaneous Migrations

C2-standard-16 24
C2-standard-8 12
C2-standard-4 6
5.1.4 Zadara Cloud
As a guideline, when deploying RMMs in Zadara Cloud for a DR solution, install the RMM on a VM with
an instance type of z4.4xlarge, z4.2xlarge, or z4.xlarge. The recommended machine type depends on
the number of servers to be protected by an RMM and the RPO time required for those servers as
described below.
If you deploy the RMM on a z4.4xlarge, the number of servers that can be protected on a single RMM is
protected on a single z4.4xlarge
< = 1 hour Up to 24
2 hours Up to 30
3 hours Up to 36
4 hours Up to 40
12
If you deploy the RMM on a z4.2xlarge, the number of servers that can be protected on a single RMM is
protected on a single z4.2xlarge
< = 1 hour Up to 12
2 hours Up to 15
3 hours Up to 18
4 hours Up to 20
If you deploy the RMM on a z4.xlarge, the number of servers that can be protected on a single RMM is
protected on a single z4.xlarge
< = 1 hour Up to 6
2 hours Up to 7
3 hours Up to 9
4 hours Up to 10
The Machine Type of the VM on which the RMM will run varies depending on how many simultaneous
migrations you wish to perform.
Machine Type Max # Simultaneous Migrations

z4.4xlarge 24
z4.2xlarge 12
z4.xlarge 6
5.2 Installing the RMM

The RMM installation file can be downloaded from the RackWare ftp server. If you do not know your
credentials on the ftp server, please contact support@rackwareinc.com. The procedure for installing
the software, including the licensing procedure for it, is in the RackWare RMM v7.4 Installation Guide.
5.3 Verify RMM is Running
After the licensing procedure has been completed, from the RMM’s console window, issue the
command “rw rmm show”.
The “License Data” section will show you the functional type of your license and how many migrations
your license allows and the expiration date of your license. Verify that the expiration date and number
of sessions allowed and remaining is what you were expecting. See the Chapter 2 of the RackWare
RMM v7.4 Installation Guide for additional information about RMM licensing.
13
License Data
Version : 3.0
Type : Production
Functional Type : Migration
Limits Install Date Expiry Date Validity
---------- ------------------------ ------------------------ --------
3/3 remain Fri May 28 15:49:18 2021 Fri Jun 18 15:49:18 2021 Valid
6 Prepare RMM Waves

To begin using the GUI, point a web browser at “https://<ip address of the RMM>”. Then, on the logon
screen, enter ‘admin’ as the username, and enter the password that was chosen for ‘admin’ when the
RMM was installed (if using an RMM installed from the IBM Marketplace, the password will be
“rackware” by default; if using an RMM installed from the Oracle Marketplace, the password was set
when the ‘admin’ user was added). A license must have already been installed on the RMM, and the
prerequisites for the RMM as described in the RMM Prerequisites and Operational Requirements Guide
must have been met in order for the login to be successful.
After the GUI login is successful, the Waves page will be shown.
14
A Wave contains a group of servers that need to be protected or migrated. To migrate or protect a
server, the server must be added to a Wave. So, first, a Wave needs to be created. A wave can be
created manually using the GUI and then one server at a time can be added to a wave via the GUI, or, if
there are many severs in a wave, information about all the servers can be put into an input .csv file and
the file can be uploaded to the RMM to create a wave.
6.1 Using the GUI to Create a Wave
If you click on the + above Create Wave, the Create Wave screen will be shown.
Enter the name you wish to call the wave. Leave the Passthrough field checked if a Host Sync will be
created except if it is known that the target servers will be able to communicate directly with the source
servers. When the Passthrough field is selected, it means that during host syncs the communication
between the source host and the target host will go through the RMM. When it is not selected, the
source host will communicate directly with the target host without having the RMM in the
communication path. For example, if both the source servers and the target servers are using public IP
addresses, they will be able to communicate directly with each other and the box can be unchecked. If
unsure, leave the box checked. The Passthrough setting has no effect on Staged Syncs.
15
The radio buttons determine if you want to only create a wave, without any hosts (ie you will define the
hosts later), or if a wave should be created with hosts now. Select ‘Wave with host’. A screen with
fields for information about the first host in the wave will be shown.
On the Source side, enter the following values in the appropriate field:
IP Address - the IP address of the source server
Friendly Name - this is a name, meaningful to the RMM, given to the server. Typically it is of the
form <hostname>-source, or <hostname>-src, but it can follow any naming convention you would like to
use.
OS - Select either Linux or Windows
SSH Port - The port number the RMM should use to ssh to the server. By default port 22 will be
used, but a different port number can be entered if needed.
Username - the user the RMM uses to ssh to the server. If following the instructions and
examples in the RMM Prerequisites and Operational Requirements Guide, ‘rackware’ would be used for
Linux servers, and ‘SYSTEM’ would be used for Windows servers. Please note that the username is case
sensitive. For example, if the Windows server was set up using “SYSTEM” as the username when
installing the MSI, “SYSTEM” is what must be entered here. The sync will not be successful if “system”
were entered here.
Passthrough - This should be left checked when doing a Host Sync except if it is known that the
target server will be able to communicate directly with the source server. For example, if both the
source server and the target server are using public IP addresses, they will be able to communicate
directly with each other and the box can be unchecked. If unsure, leave the box checked.
16
If the server you wish to add is a Windows server, an additional field, ‘Passwordless’ would be shown; by
default it would be checked, and it should be left checked.
On the Target side, enter the following values in the appropriate field:
Target Type - Use the default value of Autoprovision, unless you have pre-provisioned (i.e.,
manually created) a server in the target Cloud that will be used as the target server.
Sync Type - Use the default value of ‘Direct Sync’ if doing just a Migration. Use the Value of
“Stage 1” if you will be using dynamic provisioning or if the target environment is not yet set up. Use
the Value of “Stage 1 and 2” if you are using Staged Syncs and you wish to keep the target server
updated after each Stage 1 Sync. When adding a host for the first time, there are no circumstances
when you would select “Stage 2”.
Friendly Name - this is a name, meaningful to the RMM, given to the server. Usually, it is of the
form <hostname>-tgt or <hostname>-target, but it can follow any naming convention you would like to
use. It must be different than the Source Friendlyname. This name will be used as the virtual server
instance name in the target Cloud, and as such it must be considered a valid name in the target Cloud.
For example:
• For IBM Cloud VPC the IBM specification at

https://cloud.ibm.com/apidocs/vpc?code=python#create-instance -shows the definition of
“name” in the “Response” section of that web page. Note that, as defined there, upper case
letters are not permitted in IBM resource names.
• For Google Cloud, it must be a valid name as described in
https://cloud.google.com/compute/docs/naming-resources#resource-name-format
Once all the fields have been filled in, press the Create button. You will then see that the host data has
been added to the wave.
Press the + button, shown with a red box around it above, to add another host to the wave
17
Follow the same steps as before to add another host to the wave.
6.2 Using an Input (.csv) File to Create a Wave

To use an input file, click on ‘download template’. The RackwareWaveTemplate.csv file will then be
downloaded.
6.2.1 Entering values in the template .csv file

Open the csv file. There are many columns in the file, but most of the columns do not need to be used
for the use case this document is describing. Change the name of the file to be whatever you wish your
Wave to be called. In this example the file was renamed to be Wavewith1.csv.
For Linux source hosts, enter values in the following columns-:
Origin Name – This is the friendlyname of the origin host used to identify the host on
the RMM. A friendlyname is a name with significance only to the RMM. It may
be different than the actual hostname
Origin IP – IP address of the origin host
Origin Username – this is the username the RMM will use to access the source server.
The examples in the RMM Prerequisites and Operational Requirements Guide
show “SYSTEM” as the Origin Username for Windows hosts and “rackware” as
the Origin Username for Linux hosts.
Target Name - This is the friendlyname of the target (OCI) host used to identify the host
on the RMM. Be sure the Target Name is different than the Origin name.
Clonename – The name you wish to call the captured image of the host. Be sure the
18
Clonename is different than the Origin Name and the Target Name. If Host Syncs
are being used rather than Staged Syncs, then the Clonename field can be
left blank.
OS – Linux
Operation – host capture (Note - if the use case is Migration rather than DR, then
the Operation will be ‘host sync’)
Note that in the snapshot above several of the columns have been hidden. The order of the fields is
inconsequential - the correct values simply must be entered in the appropriate column. Fields can also
be removed from the template layout, as long as all mandatory fields are present.
For Windows hosts, enter values in the same columns (the “OS” would be “Windows”). In addition, for
Windows hosts you need to enter:
ssh only (with a value of Y)
Note – “ssh only” in the .csv file corresponds to the “Passwordless” field on the GUI.
For Windows hosts, the Origin Username will be whatever was set up on the Windows Origin server
following the steps in the Prerequisites Guide. The examples in the RMM Prerequisites and Operational
Requirements Guide show “SYSTEM” as the Origin Username.
As noted above, the Origin Name should always be different than the Target Name. One way of
ensuring this is to have the origin names end in a suffix, such as “-origin” or “-src”. So, if the hostname
of the origin server is “Host1”, then the Origin Name would be “Host1-src”.
Similarly, the Clonename should be different than the Origin Name and the Target Name. So if the Origin
Name is “Host1-src” then the Clonename could be “Host1-image” while the Target Name would be
“Host1-tgt”.
Do not enter anything in the Target IP column unless you plan on pre-provisioning that server instead of
having the RMM autoprovision the server.
While the template .csv file does not currently list all cloud parameters, they can be added to row 1 of
the template as well. See the RMM 7.4 Cloud Parameters and Operations for more information about
the parameters and how to refer to them in a template .csv file. The cloud parameters can be added to
the .csv file now, before it is uploaded, or you can upload the .csv file without including the cloud
parameters, and then add the cloud parameters through the GUI later. If a .csv file that includes cloud
parameters is uploaded, the cloud parameters won’t be visible on the GUI until after a clouduser is
associated with a wave.
Save the .csv file with the desired name. When saving it, please do not change the format of the file.
19
6.2.2 Uploading the template .csv file
Once your wave input file is complete, click on the ‘Select the file you want to upload” box, then select
the .csv file you created. The file will be uploaded and a screen showing the Wave and the hosts in it will
be shown.
If doing Staged Syncs the Passthrough option has no effect. If doing Host/Direct Syncs then leave the
Passthrough field set to ‘enabled’ except if it is known that the target server will be able to
communicate directly with the source server. For example, if both the source server and the target
server are using public IP addresses, they will be able to communicate directly with each other and the
box can be unchecked. If unsure, leave the box checked.
6.3 Setting the Parallel Count
The Parallel Count determines how many migrations or syncs in the wave will be performed in parallel.
It is set to 1 by default. A value of 0 means that all the migrations in the wave will be performed in
parallel. The number of CPUs and amount of memory in your RMM server as described in the RMM
Sizing section of this document can be used to determine the maximum value for the parallel count.
Set the value by choosing a number from the dropdown.
20
6.4 Starting a Wave
When the wave is created, all syncs in the wave will have a Target Type value of “Autoprovisioning” by
default.
If doing Staged Syncs, press the Start button shown below circled in red to start the wave and begin
capturing the hosts in the wave. The capture can be started even if the cloud parameters have not yet
been added.
Once the replication begins, the Status field will be updated as the capture proceeds. The captures can
be completed even though at this point the wave has not been associated with clouduser.
If doing host syncs, if the wave has not been associated with a clouduser, and the targets servers have
not been manually provisioned, then the wave should not be started at this time, since any sync will fail
immediately since the target servers do not exist and the RMM does not yet have the information
needed to autoprovision them.
6.5 Create DR Policy

If the use case is purely Migration, then this section can be skipped. If the use case is DR then create the
DR policy for this wave. This can be done before, while, or after any captures complete. Navigate to DR
– Policies and press the + button. This will bring up the ‘Create New DR Policy’ screen.
21
Enter the name of the DR Policy and the Periodicity (in this example, a sync will be done every 60
minutes).
Note that there are 4 types of Periodicity:
By Schedule – the syncs in an associated wave can be done every day at a certain time, or every
week on a certain day at a certain time
By Frequency – the syncs in an associated wave can be done every 5-120 minutes or every 1-23
hours.
Once – the syncs in an associated wave should be done only 1 time.
Continuous – When a sync completes another one will be started as long as the parallel count of
the wave is not exceeded.
When a Periodicity of By Frequency is used, ‘Exclude From’ and ‘Exclude To’ fields are also shown.
These can be used to prevent syncs from starting during certain periods of time. For example, if
Exclude From is set to 06 (hour) and 00 (minute) and Exclude To is set to 08 (hour) and 00 (minute) then
no syncs will be started between 06:00 and 08:00.
The Notification Email field can be used to have emails automatically sent to one or more persons or
email aliases whenever a sync fails or whenever a sync completes. Enter an individual email address or
an email alias in the Notification Email field and then press the + button to add that email to the list of
emails to receive a notification. Continue adding an email address and pressing the + button until all
the desired email addresses have been added to the Notification Email list. Please note that emails will
be sent only if the RMM networking is such that it can reach the desired recipients email servers.
After all fields have been set up as desired, press the Create button to create the DR Policy.
22
Now put the Wave into a policy. Once the capture completes, go to Replication – Waves and click on
your wave name.
Click on ‘No Policy’. From the Dropdown, select the policy you just created
and press the ‘Assign Policy’ button.
Once a policy is assigned to a Wave, the Wave is shown under DR-Waves. Click on a Wave to view the
servers in it. Note that the Goal for the sync in the Wave is now “Stage 1”, and the Policy became active
23
once a Wave was assigned to it. Since the Policy was a 60-minute policy (rather than a policy scheduled
to start at a certain time), a Stage 1 sync is executed right away.
(Note – a ‘Stage 1’ sync is a sync from a source host to an image on the RMM. A ‘Stage 2’ sync is a sync
from an image on the RMM to a host in the target environment).
Now a Stage 1 sync will be run for each server in the Wave every 60 minutes.
It is possible for multiple waves to assign the same DR Policy. If that is done, performing a failover
operation on one wave will cause all waves assigned to the same DR Policy to perform a failover. If you
wish to have a wave perform a failover only when the failover button is pushed for that wave, then have
a separate DR Policy for each wave. See Performing a Failover (DR) for more information about
performing failovers.
7 Defining Cloud Parameters

Whether the use case is a DR use case or a Migration use case, and whether you are using Staged Syncs
or Host Syncs, if you are going to autoprovision the target hosts the next step is to define the cloud
parameters to the RMM so that the servers in the Wave can be provisioned automatically when a
Failover occurs (DR) or when the initial migration occurs (DR or Migration).
There are three sets of cloud Parameters. The first is the set of parameters that is used by the RMM to
log in to the cloud API. This set of parameters describes a Cloud User.
After the Cloud User is added, it will be associated with a wave, which defines the environment in which
the wave will run, and the second set of parameters, the wave/environment parameters, will be
entered.
24
The wave parameters are used to describe where the servers in a wave will be provisioned by default.
The values of the wave parameters become the default values for the third set of parameters, the
individual sync parameters. These parameters are present in a tab that contains the name of the cloud
associated with the wave.
The parameter names vary for each cloud type. See the RMM 7.4 Cloud Parameters and Operations
guide for the listing of the parameters for the cloud, and the steps to follow to define the values of the
appropriate parameters to the RMM through the RMM GUI.
25
8 Autoprovisioning the Servers
After a clouduser has been defined and associated with a wave and the individual sync cloud parameter
values have been entered on the GUI as described in the RMM 7.4 Cloud Parameters and Operations
manual, the servers in a wave can be autoprovisioned.
There are two ways a server in a wave can be autoprovisioned into a cloud - performing a Stage 2
Sync/Host Sync with autoprovisioning or performing a Failover. The first method must be used if doing
a migration, since performing a Failover applies only if protecting servers via the RMM’s DR
functionality.
8.1 Performing a Stage 2 Sync/Host Sync with Autoprovisioning

This section describes performing syncs with autoprovisioning by having the autoprovisioning done as
part of a Stage 2 Sync (DR) or a Host Sync (Migration), without there being a failover. Depending on
your use case, see either the section Performing a Stage 2 Sync with Autoprovisioning or the section
Performing a Host Sync with Autoprovisioning
8.1.1 Performing a Stage 2 Sync with Autoprovisioning

When first testing that you have your RMM parameters and your OCI environment set up correctly, you
may wish to perform a manual Stage 2 sync with Autoprovisioning. A manual Stage 2 sync can be
performed only when a Stage 1 is not in progress. If this wave is associated with a DR Policy, verify that
the DR Policy is not about to cause the Stage 1 sync to begin. If it is, you may wish to pause the DR
Policy.
To do so, go to the Wave containing the server you wish to autoprovision, and select the Edit icon in the
row of the sync.
26
After the Edit screen comes up, be sure the Target Type is set to Autoprovision and change the Sync
Type to Stage 2:
Since a clouduser has been associated with the wave (as described in RMM 7.4 Cloud Parameters and
Operations there is now a 3rd tab visible on the screen, containing the name of the target cloud followed
by “Options”.
Note that the Friendly Name on the Source side of the screen and the Image Name on the Target side of
the screen already have values. That is because they were defined in the wave input file described in
Chapter 4 of this document. If you did not define them in the wave input file (aka the template.csv file)
or did not use a wave input file, then enter them here. The Image Name (also known as the Clone
Name) is a name local to the RMM of the captured image of the server. A common convention is to use
the source friendly name appended with “-IMAGE”. The Friendly Name of the Target will be the name
of the VM provisioned in OCI.
The Friendly Name for the source host, the Friendly Name for the target host, and the Image Name
should all have unique values; none of them should have a name that is the same as another name.
The Advanced Options tab allows for additional configuration. Click on the triangle next to “Advanced
Options”
27
The Provision Disks option allows you to change the disk sizes that the RMM creates when it provisions
a server. If not specified, the RMM will create disks with storage equal to the amount of storage on the
source server (with the exception of if right-sizing is used as described below). The disk sizes can be
specified in a comma-separated list, where the first size specified is the size of the boot disk. The sizes
can be specified in TB, TiB, GB, GiB, KB, KiB, or Bytes. Note that due to differing interpretations of
values, a 100 GB disk provisioned by the RMM will be reported as 93 GB by Windows
(https://massive.io/file-transfer/gb-vs-gib-whats-the-difference/ )
The Provision Disks values have meaning only when autoprovisioning a server.
Example:
The Right Sizing option allows you to change the size of a file system. This option is valid when
autoprovisioning a server and when syncing for the first time a preprovisioned server (as long as the
Keep Target Layout option is not specified). You can change the size of one or multiple file systems.
When autoprovisioning, the amount of disk space provisioned will be increased if necessary to hold the
file system size specified.
When using right sizing when syncing a preprovisioned server (i.e.Target Type = Existing System) for the
first time, the file system size can only be decreased, unless there is space on the preprovisioned target
that has not been allocated to a file system. Also, right sizing is valid with preprovisioned servers only if
the file system referenced does not already exist on the preprovisioned server.
A sync will fail if right-sizing is attempted on a file system that already exists on the target server.
28
In the Right Sizing fields, enter a file system id in the first field, a number in the second field, and then
select the units from the dropdown in the third field. Press the + button to Right Size another file
system on the server.
For Windows, file systems may be specified by drive letter, volume label, mountpoint path, volume
serial number, or volume identifier. Any of the following are valid ways of specifying the file system:
E:
SQL Data
F:\Data\
1CFB-3C0C
\\?\Volume{c557d989-f22e-41a7-9f98-01ff0250e318}\
The first is the E: drive, the 2nd is the drive labeled "SQL Data", the third is the file system mounted at
F:\Data\, the fourth is the file system with volume serial number 1CFB-3C0C, and the last one is the
volume with the specified volume ID.
For Linux, For Linux, file systems may be specified by device node, LVM volume group name, LVM logical
volume name, label, UUID, mountpoint, or device number (e.g. 8:1). For example, the following are
valid ways of specifying the file system:
/dev/sdg
VolGroup00/lv_tmp
/opt/data
The first is a device node, the 2nd is an LVM Logical Volume, and the 3rd is a mount point.
The sizes can be specified in TB, TiB, GB, GiB, KB, KiB, or Bytes. Note that due to differing interpretations
of values, a 100 GB disk provisioned by the RMM will be reported as 93 GB by Windows
(https://massive.io/file-transfer/gb-vs-gib-whats-the-difference/ ).
The Backup and Restore Options field will be shown when the Sync Type has a value other than Direct
Sync. For Stage 1 and Stage 2 Syncs, both the Retention Policy and the Image Version fields will be
shown.
29
For a Stage 1 Sync, just the Retention Policy will be shown.
For a Stage 2 Sync, just the Image Version field will be shown
The Retention Policy field allows you to define how long images of this host should be kept, while the
Image Version field allows you to choose an image version to use to restore files. See RMM 7.4 Backup
and Selective File Restore for details on using these fields.
After all the desired options have been set, press the Modify button. Once the Modify button is
pressed, the Wave screen will show the Goal of the Wave to be Stage 2.
30
At this point the server is set to be autoprovisioned into the cloud the next time a sync is performed,
whether it is performed manually or performed because the DR Policy triggered it (e.g., the policy says
to run a daily sync at 6 PM and it is now 6 PM, or the policy says to run a sync every hour and it is now
an hour since the last sync).
To run it manually, press the Start button, circled in red above. This will cause a Stage 2 Autoprovision
sync to be done for all hosts in the wave.
8.1.2 Performing a Host Sync with Autoprovisioning

Assume that the .csv input file as described in Section 4 is named testwave.csv and looks like
Then after uploading it to the RMM, the wave screen for testwave was
Then we added a clouduser as described in RMM 7.4 Cloud Parameters and Operations, and then
associated that clouduser with the wave by clicking on “Not configured” and added the desired cloud
wave parameters and individual sync parameters. After all the cloud-related parameters have been
added (see Performing a Stage 2 Sync with Autoprovisioning for a description of the Advanced Options
parameters) the syncs in the wave are ready to be started, by using the Start button.
31
to start the syncs in the wave. As part of the host syncs, the servers in the target cloud environment will
be provisioned.
8.2 Performing a Failover (DR)

If you are doing dynamic provisioning, you will likely be doing Stage 1 syncs regularly, and will wish to do
a Stage 2 Autoprovision only when a Failover is needed due to a DR event occurring in the source
environment. Before performing a failover, verify that there is no connectivity between the resources in
the source environment and the resources in the target/DR environment other than through the RMM.
Connectivity between resources in the two regions could have consequences for the source
environment after the target/DR servers are up and running their workloads.
Please note that while the button to perform a failover is available on a Wave screen, pressing that
button will trigger a failover on the DR Policy, and on all waves applied to the DR Policy. For example, if
there are 2 waves applied to a DR Policy, and the failover button is pushed on one of them, both waves
will perform a failover.
32
To perform a Failover, press the Failover button (shown in the red box above). Once you do that a
confirmation window will be shown
8.2.1 Failover in Test Mode

If you select Test Mode, once any Stage 1 syncs in progress have completed, if the Target Type of the
sync is Autoprovision then a Stage 2 Autoprovision sync will be done for each host in the wave. If the
Target Type of the sync is ‘Existing System’ then a Stage 2 Delta Sync will be performed. As long as at
least one Stage 2 Sync in the wave is running, the state of both the wave and the DR Policy will be
“Running Failover in Test”
Once all the Stage 2 syncs are complete, the Stage 1 Syncs from the source server to an image on the
RMM will continue as per the DR Policy, i.e., if the DR policy specifies a frequency of 1 hour, then Stage 1
syncs will be started every hour. The State of the DR Policy becomes ‘Failover Test’, while the Wave
Status is Failed Over. The actual production servers remain in the source environment, while the target
environment contains a copy of the source servers.
33
Once the failover test is complete, press the red button on the DR Policy screen under the Actions
column. This will prompt you to either Resume the policy or Pause the policy.
Choosing Resume will give another prompt, asking when you would like the policy to be resumed
After the policy is resumed, the Wave Status will be moved back to Idle, and the DR Policy will be moved
to the Active state. The Stage 1 Syncs will be performed as per the DR Policy.
If a server in the target cloud was autoprovisioned as a part of the failover, you may wish to delete it
from the target cloud.
8.2.2 Failover - Actual Failover

When a Failover is done, but not in Test Mode (i.e., an Actual Failover), once any Stage 1 syncs in
progress have completed a Stage 2 Autoprovision Sync will be performed for each host in the wave.
While a Stage 2 Sync for at least one host in the wave is running, the state of both the wave and the
policy will be ‘Running Failover’. After the Stage 2 AP Syncs are completed, Stage 1 syncs will not be
34
performed - an Actual Failover would usually be done only in the event of a disaster on the origin
environment, so those servers would not be able to do a Stage 1 sync. When the Stage 2 AP Syncs are
complete, the state of the DR Policy is Failed Over, while the state of the Wave is also Failed Over.
At this point the servers in the target environment are now the production servers. Note that there may
be some configuration changes necessary (Active Directory, DNS) for the applications to run in the new
environment. Making these changes is outside the scope of RackWare.
8.3 Performing a Fallback (DR)
‘Fallback’ is typically executed in cases of a real disaster event happening to the original production
environment. It may take an extended time to revive the original production servers, during which time
significant DELTA changes of data have already happened at the DR site - the servers in the DR site are
now the production servers. Once the servers in the original production environment are up, this
DELTA is Synced back to the original source servers in a Fallback.
A ‘Fallback’ test on live production servers is not usually performed and not recommended as the
primary site is still the production site and serving business transactions and the ‘Fallback’ process will
overwrite data on the original production servers with the data from the original target server.
In an actual Disaster event, after a successful actual failover, once the primary site is restored & the
RMM can SSH to the original production servers (over port 22) and once the RMM prerequisites are
taken care of, the RMM would be ready to execute a ‘Fallback’ operation. With respect to prerequisites,
in a Fallback operation the servers in the DR site, which were originally “target” servers are now the
“source” servers and the original “source” environment is now the “target” environment.
If you wish to perform a Fallback, press the Fallback button on the Wave screen as shown below
35
A confirmation window will come up
After pressing the Yes button, a set of reverse syncs will be performed for each host in the wave - a sync
from the original target/DR server (which is now the new production server) to the image on the RMM
followed immediately by a sync from the image on the RMM to the original production server. While
any of these syncs is in progress, the status of the wave will be “Falling Back” and the state of the DR
Policy will be “Falling Back”.
While a fallback is in progress to a server, that server will be booted into the RackWare microkernel.
Near the end of the reverse sync the server will be booted back into its original Windows or Linux OS.
36
Once both syncs for all of the hosts in the wave have completed successfully, the wave status will be
“Fallen Back” and the DR Policy state will be “Fallen Back”
To resume the DR Policy and begin syncing from the original production servers to the RMM, as was
being done before the Failover started, press the green Resume button (circled above) on the DR Policy
screen.
9 Using Pre-provisioned Servers

There may be times when autoprovisioning of servers into the desired cloud would not be possible. In
those rare cases a target server will need to be manually provisioned. Once the target server is
provisioned, and the prerequisites for it have been set up (so that the RMM can ssh to it) then the RMM
will be able to communicate with it over its IP address. At that point the contents of the source server
can be sync’ed to the target server, using either a Staged Syncs Sync or a Host Sync.
Once the target server has been provisioned and set up, add a sync for it to a wave. If you are using .csv
files to add your hosts, enter the IP address in the “Target IP” column. When the Target IP is specified,
37
the RMM will know that this is an existing system (rather than one that needs to be autoprovisioned) so
when the host is added to the wave it will be as a Target Type = Existing System.
If you manually add this host to a wave, be sure the IP address is filled in. By default, the Target
Username will be the same as the Source Username. But if the target server was built with a different
username being the username that the RMM can use to ssh to the target, then enter that username in
the Target Username field. This will be the username that the RMM uses to ssh to the target server
during the first sync. After the first sync completes successfully, the target server will have the same
contents as the source server, and so the target username will be the same as the Source Username on
delta syncs.
10 Initial Verification of Target Servers

After a server has been migrated to the target cloud you may wish to do some initial verification of the
server. Depending on the options used on the Host Sync or Stage 2 sync, the server may first need to
have a ‘host release’ command issued for it. Please contact RackWare support if the target server is not
in its native OS.
38
Any testing should be done only when there are no host syncs or Stage 2 syncs in progress. If any DR
policies are active, they should be paused to ensure that a sync does not get started while the initial
verification is in progress.
Depending on what other servers have been migrated to the target environment and the application
architecture used in the source and target environments, this testing may be limited to verifying that
certain files/directories are present on the target server.
11 Delta Syncs
With a migration use case there are often a couple of delta syncs (ie syncs where only the data that has
been changed on the source since the previous sync is copied to the target) done after the initial
migration has taken place. These syncs may be performed on all the servers in a wave or on just some
of the servers in a wave.
With a DR use case, resuming all the DR Policies will start the syncs again as per the schedule laid out in
the DR policy. This is the usual steady state in a DR use case.
After a server has been autoprovisioned successfully, the Target Type radio button on the page for the
individual sync will be automatically changed from Autoprovision to Existing System.
This indicates that the next sync that will be done of that server will be a delta sync – the RMM will
update the target server with all the changes that have taken place on the source server since the last
successful sync.
To start a sync for every host in the wave, press the Play button on the Wave screen.
39
If you want to start delta syncs for only some of the hosts in the wave, disable the ones you don’t want
to start. Section 13.7 shows how to disable and enable syncs in a wave. Alternatively, if you want to
start only 1 sync in a wave, you can select just that one by checking the box on the far left of the row
containing that sync.
If you want to start two or more, then you will need to use the method of disabling all the ones that you
don’t want to start and then press the Play button.
12 Final Sync/DR Test
If doing a migration, the last sync will be a cutover/final sync. During this sync applications on the
source server should be quiesced. After the cutover sync one final test can be performed with the
servers in the target environment.
For a DR use case, DR tests are typically scheduled once or twice per year. During this test all the
servers, including the dynamically provisioned servers, will be provisioned in the target environment.
Considering the Targets are now in the DR Environment, necessary configuration changes (Active
Directory, DNS) may be needed for the applications to run in the DR environment. Making these
changes is outside the scope of Rackware.
40
Once all those changes are in place, users can perform the desired Application/DB, etc. validation, per
their requirements. Please contact RackWare support if you have any questions on performing a DR
test.
13 Common Operations
This section describes some common operations performed with the GUI
13.1 Reprovisioning a Server

After a server is provisioned into a cloud, the RMM expects that the next operation that will be
performed with that target server will be a Stage 2 delta sync or a Host delta sync. On the System tab
of the Edit Host screen, the Target Type will be changed automatically from Autoprovision to Existing
System.
Sometimes, when testing the RMM, one will wish to reprovision a server – to delete it and start the
provisioning process from the beginning. This section describes how to do that.
After the sync that autoprovisioned the server into OCI completes, the Target Type will be set to Existing
System.
41
To be able to retry the autoprovisioning (perhaps with different parameters), simply change the radio
button to select autoprovisioning. Once you do that, a warning will appear, stating that the current
target host on the RMM will be deleted, and that for the autoprovisioning to be successful, the current
host in the cloud will need to be deleted in the cloud.
42
If you wish to continue, then press the Modify button.
Note that if you then do the stage 2 sync2 autoprovision or the host sync autoprovision, the target
friendly name (which will also be the name of the server in the target cloud) will by default be the same
as it was previously. If that is not what you wish, then change the Friendly Name to the desired value.
13.2 Handling Sync Failures

If a migration or sync fails, the status field will change to Failed.
Clicking on the “i” next to the ‘Failed’ will show the reason for the failure.
43
The last line of the failure message includes the location of a more detailed log on the RMM. It is always
of the form ‘/var/log/rackware/by-jobid/<hex number>.log’. Please include the /var/log/rackware/by-
jobid/<hex number>.log file when reporting any failures. See the RMM Diagnostics Guide for
additional information about
13.3 Retrying a Failed Sync Immediately
Sometimes a sync in a wave will fail, and you know from the error message how to fix it, and you do not
want to wait until the other syncs in the wave complete before retrying the failed sync.
To retry it immediately, click on the blue retry arrow, in the Actions column for the sync.
44
Then check the Retry Immediately box on the subsequent screen
This will start the sync immediately.
13.4 Stop, Pause Syncs

While a sync is actively running, the Stop Replications and Pause Replication buttons will be shown.
45
You might wish to stop all the syncs in a wave if you realize that something was set up wrong such that
the syncs will eventually fail. Pressing the stop button will cause all syncs in the wave to be stopped.
The sync status for each will change to Cancelling, and then, after about a minute, to Cancelled. Once
they have all been stopped (cancelled) you can make the changes needed and then restart the wave.
It is possible to stop only 1 sync in a wave while leaving all the other syncs in the wave running, but that
must be done using CLI commands. See Stopping Just 1 Sync in a Wave for the instructions on doing
that.
If the Pause button is pressed, then all syncs currently running will be allowed to complete, but no new
syncs from the wave will be started. For example, if there are 5 syncs in a wave, and the parallel count is
3, if the wave is paused while the first 3 are running, those 3 will complete but the other 2 in the wave
will not be started.
13.5 Storage Monitoring

The RMM has a mechanism of alerting users when its storage pool (ZPool) usage exceeds the capacity of
80 percent.
This is useful when doing stage syncs in disaster recovery scenarios because the image of the source
server is stored in the RMM. This feature may not be useful in migration use cases.
To configure email alerts, click the gear icon at the bottom of the sidemenu.
46
This will open up a new window, as shown below:
47
Click on the ‘RMM Config’ tab.
Make sure you slide the toggle bar to the right to enable Storage Monitoring. Enter the email address to
which you want notifications sent, and then click the button to include the email in the notification
email list.
48
13.6 Deleting a Wave
If you wish to delete an entire wave, select Waves on the left panel, and then click on the trash can icon
in the row of the wave to be deleted.
13.7 Adding a Server to Wave

A server can be added to a wave at any point by using the Add Host button on the wave screen.
This will cause another screen to come up where the information about the host and the sync can be
entered.
49
13.8 Disabling a Sync
The green check mark under Actions indicates that that sync is Enabled.
You can disable a sync by clicking on the green arrow, which will change it to a red circle with a line
through it.
Any sync that has been disabled will not be executed as part of the wave. It may be useful to disable a
sync if, for example, you know that the sync will eventually fail due to some setup issue on the source or
target and so don’t want it to start at this time. You may also wish to disable some syncs if you want to
perform a delta sync on only some of the servers in a wave.
If a sync is disabled, enable it by clicking on the red circle that has a line through it. This will change the
icon back to a green check mark.
50
13.9 Editing a Sync
To edit the parameters of a sync, click on the pencil/paper icon under Actions.
This will bring up the screen showing the source and target IP addresses and friendly names.
These fields can be edited if needed. For example, if a sync has failed because the wrong IP address was
entered, the correct one can be entered and then saved by pressing the Modify button.
The other tab present on the top of the screen is the Sync Options tab. Clicking on that tab shows the
following screen.
51
The RMM contains several sync options that may be needed in certain circumstances. Appendix 1
describes these options.
13.10 Deleting a Sync

To delete a sync from a wave, click the trash can icon in the Actions area of the sync to remove the sync
from the wave.
A sync can be deleted only when it is not in the process of running. While a sync is running the trashcan
icon will be greyed out.
52
13.11 Checking License Status
To check on the status of your license, click on the Gear icon at the bottom of the left panel. The
expiration date and the number of remaining sessions will then be displayed.
13.12 Moving a Sync to a Different Wave

The icon with an arrow pointing to the right and one pointing to the left under Actions is the Move Item
action.
This is used to move a sync from one wave to a different wave. When you click on it, a screen will
come up showing you other waves you have defined. Select one of those to move the sync to that
wave.
53
13.13 Sync Options
For certain servers you may wish to use non-default sync options when you are syncing them. To
change a sync option, click on the pencil/paper icon.
The Sync Options tab will then be shown.
Click on that tab to see the sync options available.
54
See Appendix 1 for a description of the Sync Options.
55
APPENDIX 1 SYNC OPTIONS DESCRIPTION
This section describes the sync options seen on the Sync Options tab of a sync.
The fields on the screen are described in alphabetical order below. The field name shown is what should
be entered in a .csv file as the column header unless otherwise noted in the description of the field
name.
Allow Direct Fscopy

Allow-direct-fscopy is applicable only to Linux syncs.
If selected, the filesystems on a linux source server will be directly copied to the
target server whenever the source server does not have enough free extents to create an appropriately
sized snapshot. If the source server does not have enough free extents and the --allow-direct-fscopy is
not specified, then the sync will fail.
It is always preferable to have enough space to snapshot a filesystem, but if that
can’t be done, and it is KNOWN that the rate of change of the data on that filesystem is fairly low, allow-
direct-fscopy can be set for the mountpoint of that filesystem.
Using allow-direct-fscopy inappropriately can lead to the image having
inaccurate copies of files - which is why having enough space to snapshot a filesystem is always
preferable.
56
Allow FS Deletion
Setting this option instructs the RMM to delete any file systems on the target
that no longer exist on the source. Requiring this option to be set protects deletion of data from the
target when there is a partial outage on the origin (individual disk removed or destroyed, but origin is
otherwise still up).
For example, suppose the source server has E, F, and G drives and the target
also has E, F, and G drives. Then the E drive is deleted from the source. When a Stage 1 sync is
performed it will also be deleted from the image. When later doing a Stage 2 Sync, the RMM will
notice that the target has E, F, and G while the image just has F and G. So it will ask for confirmation
that you really want the E drive deleted from the target (Allow FS Deletion?) before it does the Stage 2
Sync.
Bandwidth Limit
If the link between the source server and the RMM, or between the source
server and the target server, is being used for other traffic, and you wish to limit the bandwidth this sync
will use, specify the maximum bandwidth in Kbytes per second for this sync in this field.
Parallel count
This is the number of sync engines to be run in parallel for this individual
workload. Depending on the amount of data to be synced on the drives of the source host, your sync
may complete more quickly if you set the parallel count value. For example, if the source has 3 500GB
drives, setting the parallel count to 3 will likely reduce the time it takes for the sync to be complete. If
the source has 2 50 GB drives and 1 1.5 TB drive, then setting the parallel count to 3 will likely not
reduce the time it takes for a sync to complete.
Caution should be used when setting this value to ensure that neither the RMM
nor the source server is overburdened.
If not specified, then if a Host Sync is being performed the RMM will use as a
value the number of vCPUs that are available on both the source host and the target host. If not
specified, and a staged sync is being performed, the RMM will use a value of 1.
In a .csv file, “parallel” (without the quotes) should be used as the column
header.
Cloud Init
If selected, will leave cloud-init enabled on the Linux target server, when it is
installed and enabled on the Linux source server. If not selected, then even if cloud-init is installed and
enabled on the Linux source server, it will not be installed on the Linux target server. This parameter
has no effect on Windows servers.
Delete All Target FS

Specifying this will cause all file systems to be deleted from the target server.
This may be needed when hosts are being built from a template, and the hosts end up with the same file
system ids. File system ids should be globally unique. Specify this on an initial Host Sync so that the
existing file system ids will be deleted from the target. After a sync with this option completes
57
successfully, the option will be cleared so that delta syncs will retain the file systems on the target.
Event Script
Enter the full path of an RMM event script, that will execute commands either
just before or just after a host sync or stage 2 sync.
Event Script Args

This is the list of arguments passed to the RMM event script referenced by --
event-script. If entering the arguments in a .csv input file, use multiple columns, each with a column
header of ‘Event Script Args’ and put one argument in each of those cells.
Exclude File System(s)

Excludes file systems from syncs. For Linux, file systems may be specified by
device node, LVM volume group name, LVM logical volume name, label, UUID, mountpoint, or device
number (e.g. 8:1). RackWare recommends that the System/OS logical volumes NOT be excluded.
For Windows, file systems may be specified by drive letter, volume label,
mountpoint path, volume serial number, or volume identifier. RackWare recommends that the
System/OS volumes (typically C) NOT be excluded. If needed, non-system or data directories on C may
be excluded.
Linux example:
/dev/sdg,VolGroup01,VolGroup00/lv_tmp,/opt/data
This would exclude everything on disk sdg, all LVM volumes in volume group
VolGroup01, logical volume lv_tmp in volume group VolGroup00, and the file system mounted at
/opt/data.
Windows examples:
E:,"System Reserved",'C:\Data\',1CFB-3C0C
This excludes E:, the drive labeled "System Reserved", the file system mounted
at C:\Data\, and the file system with volume serial number 1CFB-3C0C.
'\\?\Volume{c557d989-f22e-41a7-9f98-01ff0250e318}\'
This excludes the volume with the specified volume ID.
Note - in the .csv input file, the parameter is called “exclude”. If you wish to exclude multiple volumes,
then use multiple columns with the “exclude” header in the .csv file
Reserve Drive Letters:
This parameter is specific to Windows machines. The letters in the provided

string will not be used when mounting file systems or exposing snapshots on the Windows origin. The
RMM, as part of it’s workflow creates a temporary snapshot on the windows source server. It will by
default, start at the end of the alphabet to determine on which drive letter the snapshot should be
mounted. By specifying this parameter, the RMM will not mount the snapshot on those drive letters.
The letters should be provided as a simple string of drive letter characters. For example: to reserve
drives F, P and Y, use the string "FPY".
58
Exclude SAN
By default the RMM will include drives found on a san in a capture. If you wish
to not include the drives on a san in a sync, select this option
Filter File
On the GUI, specify a path to a filter-file
A filter-file contains paths, one per line, to exclude or include during sync
The filter-file can have paths in the following formats:
a. <device> (+/-) /relative/path
where the device can be a partition like /dev/sda1
or a logical volume in the format vg/lv.
b. (+/-) /absolute/path
Examples:
+ /opt/data
- /opt/*
/dev/sda1 - /grub.conf
vg_root/lv_data1 + /data/include
+ D:\SQL\DB\IncludeMe
- D:\SQL\DB\*
1CFB-3C0C - \SQL2\DB2\ExcludeData
\\?\Volume{c557d989-f22e-41a7-9f98-01ff0250e318} -
\SQL3\DB3\ExcludeData
The filter-file may be kept on either the local PC/laptop, or may be kept on the
RMM. If it is kept on the local PC/laptop, then choose ‘Upload local File’ and then Browse to the
location of the file. If it is kept on the RMM, then choose ‘File Path on RMM’ and enter the full path
name of the file. In a .csv input file, the name of the parameter is “filter path”. When entered in a .csv
file, the filter file must be kept on the RMM.
Please see this article on creating and using filter files for additional information.
Ignore Missing
Using this option may be needed if a Host Sync or a Stage 2 Sync fails with a
message “Rackware microkernel contains n file system(s) and/or disk(s) that did not exist in OS”. The
error is shown if, after reexamining the target after it is booted into the microkernel, the RMM finds that
the number of disks has changed since it was booted into Windows. This may have been caused by
there being a multipath disk on the target. This option is also used if a Host Sync or Stage 2 Sync failed
with a ‘missing drive on target’ error, which may have been caused by a windows disk type changing
between when the target was booted into Windows and when it was booted into the microkernel.
In Place
If a Linux Host Sync or Stage 2 Sync fails with a ‘No space left on device’ error, and the
error message mentions a file that has a size greater than the amount of free space on the file system,
59
specify the file system of the file here. File systems may be specified using the same identifiers accepted
by the --exclude option. The special value "ALL" (all caps) may be used to specify all file systems. By
default Windows servers are synced with an In Place value of ALL.
If you wish to specify more than one location as “in place” in a .csv input file, then use
multiple columns in the .csv file, each with a header of “In Place”, and specify one location per column.
Include File Systems

List file systems to include that would otherwise be excluded. File systems may
be specified using the same identifiers accepted by the Exclude File System(s) option. Normally the file
systems located on removable disks and USB disks are excluded from syncs.
Example 1:
Exclude File System(s) contains “datavg” and Include File System(s) contains “
/media/usb,datavg/datalv05”
This would include the USB volume mounted at /media/usb and logical
volume datalv05 in volume group datavg while excluding the rest of
the volumes in datavg.
Example2:
Suppose there is one file system on a SAN that you wish to include, but 9 that
you do not want to include. Use the ‘Exclude SAN’ option and then use ‘Include File Systems’ to include
the one file system you do want.
Note – this option can’t be used to include NFS appliances
In a .csv file, use “include” as the column header. If you wish to include multiple file
systems, then use multiple columns in the file, each with a column header of “include”.
Keep Target Layout

Select this if you wish to retain all partitions and disks on the target without
modifying them to match those of the source.
No In Place
By default, full file systems will automatically use an in-place sync. Selecting
this option says to not automatically use in-place sync for full file systems.
No Reboot
If selected, then at the end of a host sync or stage 2 sync the target server will
remain in the RackWare microkernel rather than being rebooted into the Linux or Windows OS. Setting
this option will reduce the time it takes to complete a host sync or stage 2 sync. But if/when it is
desired that the target server be booted into Linux or Windows, the CLI command ‘rw host release’ will
need to be issued. Using this option on a group of target servers can allow you to determine the order
in which the servers in that group should be booted to their OS. Alternately, this option could be
turned off if a particular sync is known to be the last sync, and then the target will be booted into Linux
or Windows after the sync.
While a target is in the microkernel, there are only 2 operations that should be
performed; the ‘rw host release’ command or performing another sync. If the target is rebooted or
powered off while it is in the microkernel, it might not be able to be booted into the Linux or Windows
OS or into the RackWare microkernel - so it would need to be destroyed. Therefore, never reboot or
power off a target that is booted to the microkernel, unless directed to do so by RackWare support.
60
No Transfer
Do a dry-run showing the operations that would be performed by the sync, but
without syncing any data. This may be useful to verify that ssh is working, snapshots are available, and
exclude/filter/include files are set up correctly. Note however that if the sync is an autoprovision sync,
the autoprovisioning of the target will still be done.
No Transfer Compress
For Host Syncs:
By default the RMM will perform network compression when performing a host
sync. It is possible to change that default by changing the value of policy_compression_direct in the
/opt/rackware/data/options file. If the default setting for host syncs is in place and you wish to not have
network compression done on a particular host sync, select the No Transfer Compress option on that
sync.
To view the current default settings, use the CLI command “rw rmm show -v |
grep compress”. A value of 1 means compression is enabled, and a value of 0 means it is disabled
For 2 Stage Syncs:

By default the RMM will perform network compression when performing a
stage 1 sync and will not perform network compression when performing a stage 2 sync. It is possible to
change those defaults by changing the value of policy_compression_stage1 and
policy_compression_stage2 in the /opt/rackware/data/options file. If the default setting for Stage 1
syncs is in place and you wish to not have network compression done on a particular Stage 1 sync select
the No Transfer Compress option on that sync. If the non-default setting for Stage 2 syncs is in place,
and you wish to not do compression on a particular Stage 2 sync, then select the No Transfer Compress
option on the sync.
To view the current settings, use the CLI command “rw rmm show -v | grep
compress”. A value of 1 means compression is enabled, and a value of 0 means it is disabled.
To specify No Transfer Compress in a .csv input file, use a column header of “transfer
compress” and then use a value of “no” or “0” or “false”.
Replicate DNS Setting

By default, when performing an initial host sync or an initial stage 2 sync, the
target DNS settings will be left as they were initially on the target. To change that, set this field as
follows:
Select "Source" to copy the name server addresses from the source.
Select “TARGET” to retain the existing dns server addresses on the target server.
This is the default setting.
If you wish to specify one or more custom dns server ip addresses, enter them
as a comma separated list.
In a .csv input file, use “target dns” as the column header. If you wish to specify
multiple custom dns server ip addresses, use multiple columns with “target dns” as the header.
snapalloc
Based on the RMM default options, the space needed for a Linux snapshot on a
filesystem is 15 percent of the used space of that filesystem. If needed, for each individual sync that
61
percentage can be raised or lowered, or can be specified in terms of GB, MB or bytes. The amount
needed to prevent a snapshot from being invalidated depends on how quickly the data in the filesystem
is changing while the capture/sync is taking place.
On a Linux host, use the ‘pvs’ command shows how many free extents are
available on a physical volume.
If the amount of space needed for a snapshot, as determined by the snapalloc
value, is not available on the source host, then the Host Sync or Stage 1 Sync will fail.
If you essentially wish to change the space needed for a Linux snapshot on a file
system for all syncs, this can be done via editing values in the /opt/rackware/data/options file. Please
contact RackWare Support if you wish to do that.
Target Ignore Disk(s)

When an initial host sync or stage 2 sync is being done to a pre-provisioned
target, the diskid(s) specified will be ignored when the RMM is determining on which target disks the
source file systems should be placed. All the volumes and file systems on the diskid(s) specified will be
left untouched. The diskid(s) will be remembered by the RMM on delta syncs.
By default a value of “NONE” is used for the diskid, meaning that all the volumes
and files systems on all the disks can be used by the RMM.
In a .csv input file, the column header is “target ignore disks”. If you wish to ignore
more than one disk, then use multiple columns with a header of “target ignore disks” and specify one
disk to ignore in each of those columns.
TNG
When TNG is specified on a host sync or a stage 1 sync, the RMM installs a delta tracker
on the source during the 1st host sync which tracks writes on the file system at runtime. When delta
syncs are run, only these tracked changes (delta) are synced. This delta is the changes that occurred
since the last successful sync. This type of sync overcomes the limitations of rsync and significantly
improves the RPO as no time is spent calculating the delta during the sync. Please contact RackWare
support if you wish to use this option.
Transfer Compress
By default the RMM will perform network compression when performing a host sync or
a stage 1 sync. It is possible to change that default setting by changing the value of
policy_compression_direct in the /opt/rackware/data/options file. If the default setting has been
changed so that compression is off by default, and you wish to have network compression done on a
particular host sync or stage 1 sync, select the Transfer Compress option on that sync.
To view the current default settings, use the command “rw rmm show -v | grep
compress”. A value of 1 means compression is enabled, and a value of 0 means it is disabled.
To specify this in a .csv file, use a column header of “transfer compress” and use a value
of “yes” or “1” or “true” (without the quotes)
Verbose
This enables additional logging to be turned on, which may be helpful to debug
an issue that is reproducible.
62
SSH Port
This field is on the System tab of the GUI, not the Sync Options tab. By default, the RMM will ssh to the
source servers using port 22. If another application on the source server is using port 22, the RMM can
use a different port to ssh to the source server. Specify that port number here. This must be
coordinated with the Linux source server configuration or the Windows MSI installation.
Provision Disk
This field is on the System tab of the GUI, not the Sync Options tab. It can be
used to specify the disk sizes that will be autoprovisioned. If not provided, disks will be provisioned to
match the disks on the source machine. The sizes should be specified as a comma separated list of sizes
where the first size will be used for the boot disk.
Enter suffixes as: B, KiB, MiB, GiB, TiB
Example: 1TiB,111GiB,500MiB
To specify this in a .csv input file, multiple column headings, each saying “provision disk” should be used.
The size specified in the first “provision disk” heading will be used for the boot disk.
Right Size
This field is on the System tab of the GUI, not the Sync Options tab. It can be
used to specify a different (i.e. different than was on the source server) size for a file system on the
autoprovisioned server. In a .csv input file, an entry is specified as
<file system specification>=<target size>
with a file system being specified using the same method as described in the Exclude File System
parameter. The size units supported are B, KB, KiB, MB, MiB, GB, GiB, TB, and TiB. Sample entries are:
vg_centos69/lv_root=10GB
/dev/sdb2=500MiB
C:=300GB
F:=500GiB
To specify multiple entries in a .csv file, use multiple columns, each with a
header of ‘Right Size’ (without the quotes) and put a single entry in each such column.
New target hostname
This field is on the System tab of the GUI, not the Sync Options tab. It is visible
on the GUI (as “Host Name”) when the Sync Type is Direct Sync, Stage 2, or Stage 1 & 2. This value will
be used as the hostname of the target server, whether the Target Type is Autoprovision or Existing
System. If not specified, then the hostname of the target server will be the same as the hostname of
the source server.
Target name
This field is on the System tab of the GUI, not the Sync Options tab. It is visible on the GUI (as
“Friendly Name” on the Target side). This is the name by which the RMM will know the host. When an
instance is autoprovisioned, this name will also be used as the name of the instance in the target cloud.
63
If this name is changed on subsequent/delta syncs, the name change will be effective on the RMM, but
will not change the name of the instance in the target cloud.
64
APPENDIX 2 ADDING STORAGE TO ZFS POOL
If additional space for images is needed in the zfs pool, the ‘rwadm zfs configure’ CLI command must be
used. Please refer to the “RMM Administration Tools” section of the RMM Product Operations (CLI)
Guide. Please contact Rackware Support at support@rackwareinc.com if you need access to the
RackWare Support site.
65
APPENDIX 3 RMM POSTSCRIPT SAMPLE
The RMM can be told to execute a script right before starting a sync or immediately after completing a
sync via Event Scripts. Event Scripts that are executed before starting a sync are referred to as “pre-
scripts” while scripts to be executed after completing a sync are referred to as “post-scripts”
The scripts are written and debugged by customers. This section describes the framework for using the
scripts, and provides an example.
In this case, the problem that needed to be solved was the migrated servers could not connect to the
NTP server (which was also the AD server). When servers were migrated they could not find an NTP
server, and they ended up with times in the GMT time zone rather than the desired PDT time zone.
A workaround was to execute a set of commands on the target server after it had been migrated:
date
w32tm /config /manualpeerlist:"12.16.19.91" /syncfromflags:manual /update
w32tm /resync
date
w32tm /query /status
w32tm /resync
date
Net Stop W32time
W32tm.exe /unregister
W32tm.exe /register
Net Start W32time
date
However, there were many target servers involved, and executing those commands, or even a script
containing those commands, manually on each target server was impractical. So a script named
“remote time change” was created containing the commands above and that script was called by the
Event Script shown below named “time change.sh”. time_change.sh is a wrapper script, that interfaces
with the RMM and copies the remote_time_change script to the target server and executes the
commands in it. See the end of this appendix for the location to download the two scripts if desired.
Since the commands in “remote time change” are to be executed after the migration completed, the
Event Script is a postscript.
The steps to use these scripts are as follows:
1) copy the remote_time_change file to the /opt/rackware/ directory on the RMM.

2) Issue the command 'chmod 755 /opt/rackware/remote_time_change' on the RMM
3) copy the time_change.sh file to the /opt/rackware/utils/pre-post-scripts/ directory on the RMM
4) Issue the command 'chmod 755 /opt/rackware/utils/pre-post-scripts/time_change.sh' on the RMM
5) On the Sync Options tab of the sync, enter /opt/rackware/utils/pre-post-scripts/time_change.sh in

the Event Script field
66
6) In the Event Script Args field, enter "post,<username>,<target-friendly-name>,
/opt/rackware/remote_time_change
<username> is the user the RMM uses to log in to the server (typically "SYSTEM" or "rackware”), and
target-friendly-name is the name of the target host on the RMM, for example, win2k12-tgt.
Then press the Modify button and retry the sync.
Follow these steps for each of the syncs where the time zone change on the target needs to be done.
The scripts will work with either an autoprovision stage2 sync or a delta stage 2 sync. When a Stage 1
sync is performed, the scripts dont do anything. So the Event Script field and the Event Script Args field
can be set once and then remain in place no matter which type of sync is being done.
The postscript time_change.sh is shown below:
#!/bin/bash
###################################################################
# #
# Copyright 2022 RackWare, Inc. #
# #
# This is an unpublished work, is confidential and proprietary #
# to RackWare as a trade secret and is not to be used or #
# disclosed except and to the extent expressly permitted in an #
# applicable RackWare license agreement. #
# #
###################################################################
export RW_EMIT_ALL_ERRORS_AS=errorMessage # Emit all error messages to the "error_message" field

67
readonly script_dir="$(cd -P "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
readonly lib_dir=${script_dir}/../lib
readonly utils_dir=${script_dir}/../
readonly common_dir=${utils_dir}/common/
source "${lib_dir}"/assert.sh
source "${lib_dir}"/errno.sh
source "${lib_dir}"/linux.sh
source "${lib_dir}"/log.sh
source "${lib_dir}"/package.sh
source "${lib_dir}"/user.sh
readonly usage="\
Usage: time_change.sh scripttype username friendlyname remotescriptpath
Executes the specified script on remote host.
scripttype - Type of the script whether it's pre or post execution.

username - User of remote host where configuration needs to be done.
friendlyname - RMM friendlyname of remote target host where configuration needs to be done.
remotescriptpath - Path of the script present on RMM to be run on remote host.
Options:
-h Show this help.
"
function parse_arguments()
{
script_type=${1}
user=${2}
friendlyname=${3}
script_path=${4}
if [[ -z "${script_type}" ]]; then

error "Please specify script type as input execute on the remote host"
exit "${ENOENT}"
fi
if [[ -z "${friendlyname}" ]]; then

error "Please specify remote target host's RMM friendlyname on which to execute the script"
exit "${ENOENT}"
fi
if [[ -z "${user}" ]]; then

error "Please specify remote host user on which to execute the script"
exit "${ENOENT}"
fi
if [[ -z "${script_path}" ]]; then
error "Please specify script path on RMM which is to be executed on remote host"
exit "${ENOENT}"
fi
}
68
function parse_command_line()
{
parse_options "${@}"
shift $((OPTIND - 1))
parse_arguments "${@}"
}
function parse_options()
{
while getopts "h" opt_; do
case "${opt_}" in
h) echo "${usage}"; exit 0;;
?) echo "${usage}"; exit 0;;
esac
done
}
function execute_remote_script()
{
local command_=
local files_=()
local status_=
if [[ "$(echo ${script_type} | tr '[:upper:]' '[:lower:]')" != "post" ]]; then

return 0
fi
output_=$(rw host show | grep -i "${friendlyname}")
if [[ $? -ne 0 ]]; then
info "Target host with specified friendlyname doesn't exist on RMM."
return 0
fi
ip=$(rw host show | grep -i "${friendlyname}" | awk -F ' ' '{ print $4 }')
if [[ "${ip}" =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
info "Target host object have a valid IP address configured."
else
info "Target host object doesn't have a valid IP address configured."
return 0
fi
target=${user}@${ip}
cp -f ${script_path} ${utils_dir}
local script_name=$(basename ${script_path})
info "Executing ${script} on remote host ${target}"
command_="bash ${script_name}"
files_+=(remote_time_change)
scx_opts_+=(-F "${common_dir}"/ssh_config)
#if [[ "${ssh_port}" -ne 22 ]]; then
# scx_opts_+=(-P "${ssh_port}")
#fi
pushd "${utils_dir}" &> /dev/null
69
"${common_dir}"/scx "${scx_opts_[@]}" "${target}" "${command_}" \
"${files_[@]}"
status_=${?}
popd &> /dev/null
rm -rf ${utils_dir}/${script_name}
return "${status_}"
}
debug=true
export RW_VERBOSE=1
script_path=
script_type=
scx_opts=()
friendlyname=
user=
target=
parse_command_line "${@}"
execute_remote_script
# Local Variables:
# sh-basic-offset: 4
# indent-tabs-mode: nil
# End:
# vi: set et ts=4 sw=4 :
Note that there are 4 parameters being passed in.
script_type=${1}
user=${2}
friendlyname=${3}
script_path=${4}
The first parameter is the script_type. The script_type indicates the type of script to be used, either
“pre” or “post”. Since this is intended to be a postscript, “post” is what should be used.
The second parameter is the username that should be used to log in to the target server. This will be
the same username as what was used to log in to the source server (typically “SYSTEM” for Windows
servers and “rackware” for linux servers).
The third parameter is the friendlyname of the target server. This will be the same value that was used
as the Target Friendlyname on the GUI when setting up the migration.
The fourth parameter is the script path – the location of the script containing the commands that are to
be executed (“remote time change” in this case) that is to be executed.
70
The parameters are passed to the Event Script through the Event Script Args field on the GUI as shown
above.
This model can be followed for any post-script actions needed by changing the contents of the “remote
time change” script to contain whatever set of commands you need to have executed on the target
server after a migration.
The scripts referenced in this example can be downloaded from

https://rackware.freshdesk.com/a/solutions/articles/5000879201 if logged in to the Rackware Support
site.
71

RMM 7.4 GUI Operations Guide v1.13

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RMM 7.4 GUI Operations Guide v1.13

Uploaded by

Copyright:

Available Formats

JANUARY 2024

RMM 7.4 GUI OPERATIONS GUIDE

2.1 High Level Migration Steps

2.2 High Level DR Steps

HostName IP Addr OS CPU RAM Disk 1 Disk 2 Disk 3 Disk 4 Disk 5

4 Prepare the Source Servers

- there must be adequate space for snapshots on the source servers

5 Install the RMM in the Target Cloud

5.1 RMM Sizing Considerations

5.1.1 OCI (Oracle Cloud Infrastructure)

VM Shape #OCPUs RAM (GB) Block Volume Max # Simultaneous Migrations

5.1.2 Azure Cloud

5.1.3 Google Cloud

Machine Type Max # Simultaneous Migrations

5.1.4 Zadara Cloud

Machine Type Max # Simultaneous Migrations

5.2 Installing the RMM

5.3 Verify RMM is Running

6 Prepare RMM Waves

6.1 Using the GUI to Create a Wave

• For IBM Cloud VPC the IBM specification at

6.2 Using an Input (.csv) File to Create a Wave

6.2.1 Entering values in the template .csv file

For Linux source hosts, enter values in the following columns-:

ssh only (with a value of Y)

6.3 Setting the Parallel Count

6.5 Create DR Policy

Note that there are 4 types of Periodicity:

Once – the syncs in an associated wave should be done only 1 time.

and press the ‘Assign Policy’ button.

7 Defining Cloud Parameters

8.1 Performing a Stage 2 Sync/Host Sync with Autoprovisioning

8.1.1 Performing a Stage 2 Sync with Autoprovisioning

8.1.2 Performing a Host Sync with Autoprovisioning

8.2 Performing a Failover (DR)

8.2.1 Failover in Test Mode

8.2.2 Failover - Actual Failover

8.3 Performing a Fallback (DR)

9 Using Pre-provisioned Servers

10 Initial Verification of Target Servers

12 Final Sync/DR Test

13.1 Reprovisioning a Server

13.2 Handling Sync Failures

13.3 Retrying a Failed Sync Immediately

This will start the sync immediately.

13.4 Stop, Pause Syncs

13.5 Storage Monitoring

13.7 Adding a Server to Wave

13.10 Deleting a Sync

13.12 Moving a Sync to a Different Wave

The Sync Options tab will then be shown.

Click on that tab to see the sync options available.

Allow Direct Fscopy

Delete All Target FS

Event Script Args

Exclude File System(s)

Reserve Drive Letters:

This parameter is specific to Windows machines. The letters in the provided

Include File Systems

Keep Target Layout

For 2 Stage Syncs:

Replicate DNS Setting

Target Ignore Disk(s)

New target hostname