RMM Product Operations CLI Guide 2.0.5

APRIL 2022
RACKWARE MANAGEMENT MODULE
PRODUCT OPERATIONS (CLI) GUIDE
RACKWARE INC
VERSION 2.05
Contents
1 Overview ............................................................................................................................................... 3
2 Command Line Overview ...................................................................................................................... 3
2.1 CLI Conventions............................................................................................................................. 3
2.2 CLI Grammar Constructs ............................................................................................................... 4
3 Migrating Servers to a Cloud using the CLI ........................................................................................... 6
3.1 Migrating Servers Individually ...................................................................................................... 6
3.1.1 Two Stage Sync ..................................................................................................................... 6
3.1.2 Host Sync ............................................................................................................................... 9
3.1.3 Adding a Cloud User or Vcenter .......................................................................................... 10
3.2 Migrating Groups of Servers in Waves ....................................................................................... 10
4 Protecting Servers with DR Policies .................................................................................................... 11
5 RMM Administration Tools ................................................................................................................. 11
5.1 zfs Commands ............................................................................................................................. 12
5.1.1 zfs configure ........................................................................................................................ 12
6 Diagnostic and Management Tools .................................................................................................... 15
6.1 Relationship Commands ............................................................................................................. 15
6.1.1 SyncRelationshipShow ........................................................................................................ 16
6.1.2 SyncRelationshipAdd........................................................................................................... 16
6.1.3 SyncRelationshipDelete ...................................................................................................... 17
6.2 Viewing zfs Pool Status ............................................................................................................... 17
6.3 License Related Commands ........................................................................................................ 18
6.3.1 rw rmm show ...................................................................................................................... 18
6.3.2 rw license generate-report ................................................................................................. 18
7 Adding Users and Groups ................................................................................................................... 19
8 Commands for Migrating Individual Servers ...................................................................................... 19
8.1 Clouduser Add, Vcenter Add ....................................................................................................... 19
8.1.1 Clouduser Add ..................................................................................................................... 19
8.1.2 Vcenter Add ........................................................................................................................ 20
8.2 Host Capture ............................................................................................................................... 21
8.2.1 Command syntax: ............................................................................................................... 21
Page 2 of 66
8.2.2 Explanation of Flags: ........................................................................................................... 22
8.2.3 Examples: ............................................................................................................................ 26
8.3 Host Sync ..................................................................................................................................... 26
8.3.1 Command Syntax ................................................................................................................ 26
8.3.2 Explanation of Flags ............................................................................................................ 30
8.3.3 Examples ............................................................................................................................. 45
8.4 Image Sync .................................................................................................................................. 46
8.4.1 Command Syntax ................................................................................................................ 46
8.4.2 Explanation of Flags ............................................................................................................ 50
8.4.3 Examples ............................................................................................................................. 66
1 Overview
This document explains how to use the Command Line Interface (CLI) of the RackWare Management
Module (RMM) to capture images and perform syncs from source servers to images, from images to
target servers, and from source servers directly to target servers. This manual describes the commands
available for each of the above functions, the options available for each of those commands, and a
description of those options.
There is additional functionality in the CLI that is not yet documented in this draft of the manual.
Note that the RMM also has a GUI that can be used for migrating servers to a cloud and protecting
servers using DR Policies. The manual “Using RMM 7.4 to Set Up a DR Site in OCI” provides an example
of how to use the GUI for migration and setting up DR policies with OCI. There are similar manuals
available for Azure, vCenter, and GCP.
2 Command Line Overview

2.1 CLI Conventions
The command line structure is modeled largely after Linux conventions:
context action target[, <target>, . .] \

[--flag] \
[--flag option_a|option_b] \
[--flag <value>] \
[ . . . ] \
There are contexts in which an action is to be performed. Typically there is a specific target upon which
to perform the action. Each command has a set of mandatory and optional flags.
To illustrate the command structure consult the host show command:

host show [<host_spec>]
[-s|--rsync-stats]
Page 3 of 66
[-t|--rsync-stats-history]
[-n|--num-rsync-stats]
[-c|--cutover]
[-a|--analysis]
[-d|--dependency]
[--docker-container-info]
[--rmm <rmm_friendlyname>]
(Note: To use --rmm input, this RMM must be hub-role enabled.)
[-v|--verbose]
[--all-info]
Some --flags have an abbreviated form denoted by -<letter>, such as -v instead of --verbose.
Flags that are optional are surrounded by brackets, [--flag]. If there are no brackets, the flag is
required for the command.
Some flags stand alone and take no parameters.
Some flags take a value as a parameter. An example is --rmm which takes a rmm friendly name
Contexts and actions can also optionally support abbreviated forms. If so, the bolded letters are
required, others are optional. For example, “host show” can be entered as ”h sh”.
2.2 CLI Grammar Constructs
<alphanumeric> :
<abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789>
encoded in ASCII
<aws-key characters> : <alphanumeric> plus /+
<az secret char set> : <alphanumeric > plus +.[]
<az secret chars> : <alphanumeric plus +-[]
<diskid char set> : <alphanumeric plus /
<fs char set> : <alphanumeric> plus ’”/\:-_
<ID character set> : <alphanumeric> plus -
<name character set> : <alphanumeric> plus -_
<ocid id char set> : <alphanumeric> plus .-
<oci fprint char set> : <alphanumeric> plus :
<path char set> : <alphanumeric> plus /
<argument list> :<a comma separated list of arguments>

<aws access key> : <20 alphanumberic characters>
<aws secret access key>: <40 <aws-skey characters>
<AWS VPC ID> : “vpc-“8 alphanumeric characters
<AWS Subnet ID> : “subnet-“7 alphanumeric characters
<az client id> :37 characters from <ID character set>
<az client secret> :32 characters from <az secret char set>
<az subscription id> :36 characters from <ID character set>
<az tenant id> :36 characters from <ID character set>

<cloud provider type> : ”aws”|”azurerm”|”gcp”|”oci”|”oscloudstack”|”softlayer”
Page 4 of 66
<diskid> : up to 128 characters from <diskid char set>
<diskid list> : a comma separated list of diskids
<disksize list> : <size list>
<file system> : up to 128 characters from <fs char set>

<file system list> : <file system>,<file system>,<file system>,..
<friendlyname> : <name>
<from-host-or-image> : <hostspec> | <imagename>
<GCP_machine_type> : <'n1-standard-1'|'n1-standard-2'|'n1-standard-
4'|'n1-standard-8'|'n1-standard-16|'n1-standard-32|'n1-standard-
64|'n1-standard-96|'n1-highmem-2'|'n1-highmem-4'|'n1-highmem-8'|'n1-
highmem-16'|'n1-highmem-32'|'n1-highmem-64'|'n1-highmem-96'|'n1-
highcpu-2'|'n1-highcpu-4'|'n1-highcpu-8'|'n1-highcpu-16'|'n1-highcpu-
32'|'n1-highcpu-64'|'n1-highcpu-96'>
<hostspec> : <ipaddr>|<friendlyname>
<host> : <friendlyname>
<imagename> : <friendlyname>
<image> : <imagename> | <host>
<ipaddr> : an IPv4 address in standard notation.
<ipaddr list> : a comma separated list of ipaddrs
<jobname> : <name>
<linux-password> : <a valid linux password>
<linux-username> : <a valid Linux username>
<name> : 1 to 128 characters from <name character set>.
But the <name> can not be “all”
<ocid> : 1 to 128 characters from <ocid id char set>

<oci fingerprint> : 47 characters from <oci fprint char set>
<parallel_count> : <number from 1 to 16>
<passphrase> : quoted string containing up to 128 characters
<password> : <windows password> | <linux password>
<path> : up to 4096 characters from <path char set>
<percent_used_size> : <number from 1 to 100>
<right-size-spec> : The format for <right-size-spec> is one or more

comma-separated fields in the following format:
<file_system>=<size>
Where <file_system> identifies a file system. It
can be a file system label or UUID, a mount
point, an LVM <vg_name>/<lv_name>, or a device
node (/dev/vda2)
<size> specifies the new size for the file system
on the target.
<size> : <number><size_suffix>
<size_list> : comma separated list of <size>s
<size_suffix> : B | KB |KiB | MB | MiB | GB | GiB | TB | TiB
1 KB (SI Kilobyte) = 1000 bytes
1 KiB (binary Kilobyte) = 1024 bytes
Page 5 of 66
<ssh_port> : <number from 0 to 65535>
<source_host_spec> : <hostspec>
<subnet-name> : <string with up to 154 characters; blanks may
be included, but names with blanks must be
double quoted
<targetname> : <friendlyname>
<target> : <target-uid>|<targetname>
<target_host_spec> : <hostspec>
<username> : <windows-username> | <linux-username>
<windows-username> : a valid Windows username
<windows-password> : a valid Windows password
3 Migrating Servers to a Cloud using the CLI

At a high level, there are two different sets of CLI commands that can be used to migrate a server to a
cloud. Individual servers can be migrated to a cloud, one at a time, by using the “rw host capture” and
“rw image sync” commands or by using the “rw host sync” command. Alternatively, groups of servers
can placed in a wave and then all the servers in a wave can be migrated with a single command.
While it may be quicker to migrate an individual server using the capture or sync commands than to use
the wave related commands, using the ‘host capture’, ‘image sync’, and ‘host sync’ allows for only one
host per command to be captured or synced.
3.1 Migrating Servers Individually

There are two ways of migrating a server individually:
1) Two Stage Sync - with this method an image of the source host is created on the RMM and then
that image can be assigned to a target host in a cloud. This is essentially a store-and-forward
method of getting a source image to a target host in a cloud - the source image is stored on the
RMM and then copied to the target host. The target host may already exist or it may be created
during the sync operation.
2) Host Sync - with this method, an image of a source host is copied directly onto the target host in
the cloud. The target host may already exist or it may be created during the sync operation.
The image is not stored on the RMM at any point.
3.1.1 Two Stage Sync

When using the Two Stage Sync methodology, an image of the source host is captured using the ‘host
capture’ commandThe image is stored on the RMM, and, as changes occur on the source host, the
image can be kept up-to-date by using the ‘image sync’ command.
At some point you will wish to assign that image to a target host in a cloud, e.g. OCI or Azure. This is
done with a variant of the ‘image sync’ command. The target host can be pre-provisioned, or it can be
automatically provisioned when the ‘image sync’ command is issued.
3.1.1.1 Capturing an Image

The ‘rw host capture’ command (re)discovers the Host (ie the origin server) and catalogs the discovered
information required for a replication process and prepares the Image for further management
operations. It also creates a clone of the Origin Image by creating an image of the server, while leaving
Page 6 of 66
the actual Origin Image untouched. The RMM connects to the origin host over the network, takes a
snapshot of the Image on the running server, and copies the image bits to a storage location on the
RMM Server.
The created Image object is a separately viewable object in the RMM CMDB. The name of this object is
specified by --clonename. The Image object contains the actual Image bits and metadata about the
Image, such as network configuration information. The state of this object is CAPTURED. This object
can be viewed by the Image Show command.
If a Discover of the <host> was not run first, the host must be identified by its IP address, and the
Capture will also create the appropriate objects of the Origin server. Early in the capture process, the
origin server is “discovered” by the RMM. Once the origin server has been discovered, its attributes
can be viewed with the ‘rw host show’ command.
If the capture fails after the origin server has been discovered by the RMM, then on any subsequent
capture, the origin server may be specified by the host “friendlyname” rather than by its IP address.
Specifying the origin server by its IP address will always be correct, regardless of whether the origin
server has been discovered or not.
Once an origin server has been captured, its image is stored in the RMM’s repository. Once there, the
image can be:
• Sync’ed with the origin server to pick up any changes to the origin server since the capture was
done
• Assigned to a target server in a cloud
• Sync’ed to a target server, so the target server can pick up any changes that were done to the
origin server since the assign was done
• Modified to change certain elements of the image such as networking
The Capture is non-disruptive to the Origin workload, although Capture generates disk IOs and network
traffic as a copy of the Image is transferred to the RMM's CMDB.
Images captured with the --flex option will have an image type of FlexImage.
In order for the capture to be successful, there are certain prerequisites that must be in place on the
origin server. Please see the RMM v7 Prerequisites and Operational Requirements guide for the list of
prerequisites.
While there are many options for the ‘rw host capture’ command, the simplest form is:
Command syntax:
Usage:
host capture | h ca <ip_address of source host>
--image <name> -n|--friendlyname <name> --flex --os <windows |
linux> [--ssh-only]
Linux Examples:
rw host capture 10.10.0.1 --image my-Linux-Image -n my-Linux-Src --flex --os linux
Page 7 of 66
Windows Example:
rw host capture 10.10.0.2 --image my-Win-Image -n my-Win-Src --flex --ssh-only --os windows
Upon successful completion of the ‘rw host capture’ command, the attributes of the origin host can be
seen via the ‘rw host show’ command and the attributes of the captured image can be seen with the ‘rw
image show’ command.
For the full set of flags available with the ‘rw host capture’ command, and additional examples, please
see section 7 “Command Reference”
3.1.1.2 Refreshing the Image - Stage 1 Sync

Once an image has been captured, it can be refreshed, picking up any changes made to the source
server since the last time the image was captured or refreshed, with the ‘rw image sync’ command.
The Stage 1 sync variant of ‘rw image sync’ will synchronize a source host with a CAPTURED Image.
While there are many options for the ‘rw image sync’ command, the simplest form for a Stage 1 Sync is:
Command syntax:
Usage:
Image sync | i sy <host> --image <friendlyname> --flex
Linux Example:
rw image sync my-Linux-Src --image my-Linux-Image --flex
Windows Example
rw image sync my-Win-Src --image my-Win-Image --flex
The prerequisites for a Stage 1 sync are the same as for a ‘host capture’
For the full set of flags available with the ‘rw image sync’ command, and additional examples, please see
section 7 “Command Reference”.
3.1.1.3 Migrating to Cloud Environment - Stage 2 Sync

At any point after an image has been captured, that image can be assigned to a host in the target
environment. This is done using a Stage 2 sync.
The first time a Stage 2 Sync is performed, the host in the target environment may be either
preprovisioned, meaning it was created manually using the target cloud specific mechanism for creating
a (virtual or bare metal) machine in the cloud, or it may be automatically provisioned during the Stage 2
sync.
Please note that the ‘rw image sync’ command is used for both Stage 1 syncs and Stage 2 syncs.
3.1.1.3.1 Stage 2 Sync to Preprovisioned Hosts

If the captured image is being assigned to a preprovisioned host, the RMM does not yet have a
friendlyname for the preprovisioned host, so the IP address of the host is used in the initial Stage 2 sync
command. As part of the initial Stage 2 sync process, the target host is “discovered” automatically.
Page 8 of 66
Once the host is discovered, a friendlyname is associated with the host. In subsequent Stage 2 syncs
the friendlyname is used as a reference to the host in the ‘rw image sync’ command.
Alternatively, if the preprovisioned host is discovered using the ‘rw host discover’ command, then the IP
address of the host is associated with a friendlyname, so the friendlyname can be used in the initial
Stage 2 sync command.
3.1.1.3.2 Stage 2 Sync with Autoprovisioning

If the target host does not yet exist, the RMM can provision it into a cloud (or a vcenter) as part of the
Stage 2 sync process. This requires the use of the “--autoprovision” option in the ‘rw image sync’
command. Either a clouduser or a vcenter must also be specified on the command so that the RMM
knows where to create the target host.
As part of the initial Stage 2 sync process with an autoprovisioned target, the target host is “discovered”
automatically. Once the host is discovered, a friendlyname is associated with the host. In subsequent
Stage 2 syncs the friendlyname is used as a reference to the host in the ‘rw image sync’ command.
3.1.2 Host Sync

With a host sync, an image of a source host is copied directly onto the target host in the cloud. The
image is not stored on the RMM. This is done using the “rw host sync” command.
The first time a sync is done, the host in the target environment may be either preprovisioned, meaning
it already exists in the target environment, or it can be automatically provisioned during the Direct Sync.
Please note that the term “Direct Sync” is synonymous with the term “Host Sync”.
While there are many options for the ‘rw host sync’ command, the simplest form for a Host Sync is:
Usage:
rw host sync <source_host_spec> { --target <target_host_spec> | --autoprovision } [optional flags]
Linux Example:
rw host sync my-Linux-Src --target my-Linux-target
Windows Example
rw host sync my-Win-Src --target my-Win-target
For the full set of flags available with the ‘rw host sync’ command, and additional examples, please see
section 7 “Command Reference”.
3.1.2.1 Host Sync with Preprovisioned Target

If the image of the source host is being assigned to a preprovisioned host, when the first sync occurs the
RMM does not yet have a friendlyname for the preprovisioned host, so the IP address of the target host
is used in the initial Host Sync command. As part of the host sync process, the target host is “discovered”
host syncs the target’s friendlyname is used as a reference to the host in the ‘rw host sync’ command.
Page 9 of 66
Alternatively, if the preprovisioned host is discovered using the ‘rw host discover’ command, then the IP
address of the target host is associated with a friendlyname, so the target’s friendlyname can be used in
the initial Host Sync command.
3.1.2.2 Host Sync with Autoprovisioned Target

If the target host does not yet exist, the RMM can provision it into a cloud (or a vcenter) as part of the
host sync process. This requires the use of the “--autoprovision” option in the ‘rw host sync’ command.
Either a clouduser or a vcenter must also be specified on the command so that the RMM knows where
to create the target host.
As part of the initial host sync process with an autoprovisioned target, the target host is “discovered”
host syncs the friendlyname is used as a reference to the host in the ‘rw host sync’ command.
3.1.3 Adding a Cloud User or Vcenter

If target hosts are going to be autoprovisioned into a cloud or a vcenter, then a clouduser or vcenter
needs to be added.
If autoprovisioning of targets is not going to be done, then cloudusers and vcenters do not need to be
added.
An ‘rw clouduser add’ command provides the information necessary for the RMM to be able to log in to
a cloud API. Login access to the API is needed for the RMM to be able to create resources (e.g. virtual
machines) in the cloud.
Usage:
rw clouduser add <name> -p <cloud provider type> <cloud specific flags>
The clouduser name will be specified in any sync command that autoprovisions machines.
Similarly a vcenter must be added if any VMs are to be autoprovisioned in a vcenter.
Usage:
rw vcenter add <name> --vcenter <ip addr> --vcenteruser <username> --vcenterpass <password>
3.2 Migrating Groups of Servers in Waves

Groups of servers can be migrated and synced by placing the servers into waves. Each source server in
a wave can be captured, part of a Stage 1 sync, part of a Stage 2 sync, part of a Stage 1 and Stage 2 sync,
or part of a Host Sync. All flags that are part of the individual sync commands can be set for a specific
server’s sync by editing the appropriate item in the wave.
The following commands are used to create, manage, modify, and delete waves:
rw wave add
rw wave add-machine
rw wave delete
rw wave delete-machine
Page 10 of 66
rw wave deselect
rw wave edit
rw wave edit-cloud
rw wave edit-item
rw wave get-history
rw wave move
rw wave move-item
rw wave pause
rw wave retry-item
rw wave select
rw wave show
rw wave start
rw wave stop
rw wave update
4 Protecting Servers with DR Policies

To protect servers, information about the servers should be added to a wave, and a DR Policy should be
applied to the wave. The DR Policy determines how often syncs of the wave (and thus of the servers in
the wave) will be performed. A DR Policy can be failed over, in which case all servers in all waves that
the policy has been applied to will fail over to the target environment. Pausing a DR Policy prevents
additional syncs from starting in all waves to which the policy has been applied, while resuming the
policy signals that the syncs in the waves to which the policy has been applied should be started.
The following commands are used to create, manage, modify, and delete DR Policies.
rw drpolicy create
rw drpolicy delete
rw drpolicy show
rw drpolicy pause
rw drpolicy resume
rw drpolicy modify
rw drpolicy apply
rw drpolicy failover
rw drpolicy fallback
rw drpolicy log
5 RMM Administration Tools

This set of commands administers and configures the RMM. These commands include
rwadm zfs
rwadm start
rwadm restart
rwadm stop
Page 11 of 66
rwadm config
rwadm init
5.1 zfs Commands

There are several commands available for modifying the zfs storage pool used by the RMM for staged
syncs or for Direct Syncs with the TNG feature. All those commands are ‘rwadm zfs’ commands.
USAGE: rwadm zfs <option>
configure - configure and enable zfs functionality on RMM (see below)

enable - enable zfs compression (use this only after consultation with RackWware Support)
disable - disable zfs compression (use this only after consultation with RackWare Support)
dedupOn enable zfs dedup (use this only after consultation with RackWare Support)
dedupOff disable zfs dedup (use this only after consultation with RackWare Support)
status - print zfs status
5.1.1 zfs configure

The main function of the ‘rwadm zfs configure’ command is to increase the size of the zfs storage
available to the RMM. It can also be used to enable zfs storage to be used if it was not enabled when the
RMM was installed.
After entering ‘rwadm zfs configure’ the user will be prompted to add another storage location for the
zfs storage
[root@rmm-7-4-0-378 opc]# rwadm zfs configure

CentOS Linux release 7.9.2009 (Core)
Found supported RedHat/CentOS release.
CentOS Linux release 7.9.2009 (Core)
===============================================================
Available storages
1. default at localhost:/srv/images
Enter your choice [1]:
Press enter to select the default location. Please consult with RackWare Support if you wish to select a
different location.
After pressing enter information about the current RMM storage pool will be displayed, followed by a
prompt to add an additional disk
RMM Storage Pool is already configured

Statistics of RMM Storage pool is :
==================================================
RMM STORAGE POOL |
==================================================
Pool Name : rwzpool
Total Size : 49.5G
Page 12 of 66
Pool Free : 31.9G
ZFS Compression Algorithm: lz4
======================================================
Do you want to add extra disk to RMM storage pool? (Y/N) [N]:
Reply with Y if you wish to add an extra disk. The RMM will then show a list of existing devices, and their
usage status.
Do you want to add extra disk to RMM storage pool? (Y/N) [N]: Y
Existing devices in the system which can be added to RMM Storage Pool are:
===============================================================
| EXISTING DEVICES |
===============================================================
/dev/sda (in-use)
dev/sda1 (in-use)
/dev/sda2 (in-use)
/dev/sda3 (in-use)
/dev/sdb (in-use for ZFS)
/dev/sdb1 (in-use for ZFS)
/dev/sdc (free)
===============================================================
[A]dd disk or [F]inished [A]:
To add an extra disk, enter “A”
[A]dd disk or [F]inished [A]: A

You have 3 chance(s) to enter a valid device. Check by executing "parted -l"
Warning: Device will get formatted after adding to RMM Storage pool.
Enter device name/path to be configured as RMM Storage pool. [ONE AT A
TIME]:
The device name you enter must be one of the devices shown in the list shown by the RMM and should
be shown as being “free” in the list.
In this example, /dev/sdb is already being used for ZFS storage, and we wish to add /dev/sdc to the pool.
So /dev/sdc is entered
Enter device name/path to be configured as RMM Storage pool. [ONE AT A

TIME]: /dev/sdc
Valid device: /dev/sdc
Following disks will be added to RMM Storage Pool:
/dev/sdc
Page 13 of 66
Setting disk label...
Information: You may need to update /etc/fstab.
Status of rwzpool:
pool: rwzpool
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
rwzpool ONLINE 0 0 0
sdb ONLINE 0 0 0
sdc ONLINE 0 0 0
errors: No known data errors
Existing devices in the system which can be added to RMM Storage Pool are:
=================================================================
| EXISTING DEVICES |
=================================================================
/dev/sda (in-use)
/dev/sda1 (in-use)
/dev/sda2 (in-use)
/dev/sda3 (in-use)
/dev/sdb (in-use for ZFS)
/dev/sdb1 (in-use for ZFS)
/dev/sdc (in-use for ZFS)
/dev/sdc1 (in-use for ZFS)
=================================================================
[A]dd disk or [F]inished [A]:
If there are no more disks to be added to the zfs pool, then enter ‘F’
[A]dd disk or [F]inished [A]: F

Retaining Previous Configuration
Loading ZFS properties from previous configuration...
Enabling ZFS Compression...
Final Configuration:
================================================================
| RMM STORAGE POOL |
================================================================
Pool Name : "rwzpool"
Total Size : 109G
Pool Free : 91.4G
RMM Storage Pool Compression Algorithm: "lz4"
================================================================
The ’Total Size’ and ‘Pool Fee’ values are updated as a result of the new disk being added.
Page 14 of 66
Note - You can see the size and the amount of free space in the zfs pool at any time by using the ‘rw
pool show’ command.
6 Diagnostic and Management Tools

A set of commands exists for gathering information about the RMM’s environment and the hosts that
are being migrated and for deleting resources so that operations can be retried from the beginning.
Those commands include:
rw imageconfig syncrelationship show

rw imageconfig syncrelationship add
rw imageconfig syncrelationship delete
rw imageconfig set
rw pool show
rw rmm show
rw license generate-report
rw host show
rw host discover
rw host delete
rw image show
rw image delete
rw help
rw job query
rw log show
rw host release
6.1 Relationship Commands

A relationship between a host and an image, or between a host and a host, is added the first time a sync
is done between the two entities. If a capture or Stage 1 Sync is performed, a relationship is added from
the source host to the image. If a Stage 2 Sync is performed a relationship is added from the image to
the target host. If a Host Sync is performed a relationship is added from the source host to the target
host. Once a relationship is established, any type of sync that would conflict with the established
relationship will fail with a relationship error. This helps prevent hosts from having the wrong image
assigned to them.
For example, if a source (production) host is performing Stage 1 syncs to an image, and then a CLI
command ‘rw image sync’ is issued which would perform a sync from an image to the source host (thus
overwriting the data on the production host) that sync will fail with a relationship error, namely:
The specified source and target is not allowed to perform sync operation. To override
specify --force or modify the sync relation confluence options.
The current relationships should then be investigated, and the appropriate relationships added or
deleted.
Page 15 of 66
6.1.1 SyncRelationshipShow
This command shows all the sync relationships on the RMM, or just the ones for the host or image
specified
Usage:
imageconfig syncrelationshipshow [host | imagename]
Examples:
[root@rmm01 ~]# rw ic srs
Host Entries
Sync From Sync To Stage
-------------- --------------- -------
centos78-src centos78-Image STAGE-1
win2k19-src win2k19-img STAGE-1
centos78-Image bj-centos78-tgt STAGE-2
win2k19-img bj-win-tgt STAGE-2
[root@rmm01 ~]# rw ic srs win2k19-img
Host Entries
----------- ----------- -------
win2k19-img bj-win-tgt STAGE-2
win2k19-src win2k19-img STAGE-1
[root@rmm01 ~]# rw ic srs centos78-src
Host Entries
------------ -------------- -------
centos78-src centos78-Image STAGE-1
6.1.2 SyncRelationshipAdd
This command is used to add a relationship between a host and an image or between two hosts.
Relationships are added automatically between resources when the initial sync between them is
performed. This command needs to be executed manually only if something unusual needs to be done
on the RMM.
Usage:
imageconfig syncrelationshipadd [host|imagename] --target
[host|imagename]
Example:
[root@rmm01 ~]# rw ic sra centos78-Image --target centos78-src

Accepted command 'ic sra centos78-Image --target centos78-src
Page 16 of 66
jobid file: /var/log/rackware/by-jobid/000000000000318c.log
The sync relationship has been added
6.1.3 SyncRelationshipDelete
This command is used to delete a relationship between a host and an image or between two hosts. You
may wish to prevent additional syncs from happening accidentally (ie via an incorrect CLI command)
between a host and an image or between two hosts, and a way to prevent that would be to remove the
relationship between the two resources.
Usage:
imageconfig syncrelationshipadd [host|imagename] --target
[host|imagename]
Example:
[root@rmm01 ~]# rw ic srd centos78-Image --target centos78-src

Accepted command 'ic srd centos78-Image --target centos78-src
jobid file: /var/log/rackware/by-jobid/0000000000003193.log
The sync relationship has been removed
6.2 Viewing zfs Pool Status

The status of the RMM’s zfs pool can be checked at any time by using the ‘rw pool show’ command.
Usage:
pool show | po sh [<array>[:<pool>]]
[root@rmm-7-4-0-378 opc]# rw pool show

WARNING: License expires after 17 day(s).
Please consider renewing the license at the earliest.
======================================
Regular Pool Info: array-iet:default
======================================
TotalSize TotalUsed Available Capacity Path Mount On
--------- --------- --------- -------- ----------- --------
38.06 GB 19.63 GB 18.43 GB 52% /srv/images /
===============================================================
ZFS Pool 'rwzpool'at /srv/images Info: ZPOOL_ENABLED
================================================================
TotalSize TotalAllocated Available TotalLogicalUsed TotalCompressRatio Compression Dedup DedupRatio Capacity Fragmentation
--------- -------------- --------- ---------------- ------------------ ----------- ----- ---------- -------- -------------
109.00 GB 17.58 GB 88.01 GB 27.20 GB 1.54x lz4 off 1x 16% 0%
There are two sections of output. The first is for the non-zfs storage of the /srv/images partition. The
2nd,and most important part, shows the size and available space of the zfs pool. In the example above,
there is 88 GB still available out of the total pool size of 109 GB.
Page 17 of 66
6.3 License Related Commands
These commands give you information about your RMM license
6.3.1 rw rmm show

The rw rmm show command gives information about the RMM, including how many of your
licenses have been used and when the licenses will expire.
[root@rmm]# rw rmm show
RMM Info
Software version : v7.4.0.583
Build date/time : Mar 22 2022 at 13:42:35
Uptime : 16 day(s), 6 hour(s), 52 minute(s), 15 second(s)
Installation Time : Wed Mar 1107:15:26 2020
System Date/Time : Thu Apr 14 23:44:54 2022
Environment
LocalConfigDB : /opt/rackware/data/rmm.db
RemoteConfigDB : /opt/rackware/data/rmm.db
Configuration
Default boot method: tftp
RMM IP Interface:
Configured RMM Roles
ROLE : RMM_ROLE_STANDALONE
Configured RMM Hub(s)
Plugins
None installed
Operation Statistics
Total Host Captured : 10
Total Assign Operations : 0
Total Data Migrations : 7
Total Hosts Discovered : 11
License Data
Version : 3.0
Type : Production
Functional Type : Disaster Recovery
Limits Install Date Expiry Date Validity
----------- ------------------------ ------------------------ --------
1/12 remain Fri Mar 25 15:20:39 2022 Wed Mar 29 15:20:39 2023 Valid
6.3.2 rw license generate-report

This command displays the list of servers which have consumed a license along with the details
of the servers for the current license batch.
Usage:
license generate-report | l gr
[--all will display the list of servers which has consumed the license till now.]
[--period <Specify the number of months 1 | 2 | n>]
[root@rackware-rmm opc]# rw license generate-report
Friendly Name IP Address Job Id Timestamp Operation
---------------- ---------- ------ ------------------------ ---------
w2k12-src 10.1.0.6 135163 Fri Aug 28 05:03:42 2020 SYNC
centos7-src 10.1.0.5 156430 Fri Sep 18 01:18:07 2020 DISCOVER
Page 18 of 66
If host/direct syncs are being done, the Operation column will show either DISCOVER or SYNC, depending on whether
or not a migration has been successful.
If staged syncs are being done, the Operation column will show either DISCOVER or CAPTURE, depending on whether
or not the Capture has been successful.
7 Adding Users and Groups

The RMM contains a set of commands for adding RMM users and groups with various privileges. Those
commands include:
rw user add
rw user modify
rw user delete
rw user show
rw org add
rw org modify
rw org delete
rw org show
rw auth add
rw auth delete
rw auth show
8 Commands for Migrating Individual Servers

8.1 Clouduser Add, Vcenter Add
8.1.1 Clouduser Add
The syntax for a ‘clouduser add’ is:
Usage:
rw clouduser add <clouduser name> -p <cloud provider type> <cloud specific flags>
The clouduser name will be used in any sync command that autoprovisions a VM into a cloud. The valid
list of cloud provider types are:
aws Amazon EC2 (Amazon Elastic Cloud Compute)

azurerm Azure Resource Management
oscloudstack Open Source CloudStack
softlayer Softlayer
oci Oracle Cloud Infrastructure
gcp Google Cloud Platform
The flags for each cloud provider type are as follows:
Page 19 of 66
8.1.1.1 AWS
-s | --secretaccesskey <aws secretaccesskey>
-a | --accesskey <aws accesskey>
8.1.1.2 Azurerm
--subscriptionid <az subscriptionid>
--azure-tenantid <az tenantid>
--azure-clientid <az clientid>
--azure-client-secret <az client-secret>
[--datacenter <name>] (location of datacenter)
8.1.1.3 CloudStack
--apiurl <api_access_url>
--apikey <api_key>
-s|--secretaccesskey <secretaccesskey>
--oscloudstack-domain-id <domain id>
8.1.1.4 Softlayer
-u|--user <username>
--apikey <api_key>
--domain <Domain Name>
[--hourly] (if specified, use hourly billing instead of the default of monthly billing)
[--access-rights <rights-list>]
8.1.1.5 OCI
--region <name>
--oci-user-id <OCID> (user OCID for accessing oracle cloud infrastructure account)
--oci-pkfilepath <path> (path to private key file used for oracle cloud infrastructure account>)
--oci-fingerprint <oci fingerprint> (finger print value for oracle cloud infrastrcture user)
--oci-tenantid <OCID> (tenancy id value for oracle cloud infrastructure user)
[--oci-compartment <name>] (default compartment name for this cloud user)
[--oci-compartment-id <OCID>] (default compartment id for this cloud user)
[--oci-passphrase <passphrase>] ( pass phrase key for oracle cloud infrastructure user)
Note - If the oci-user-id specified has access to only a certain compartment then one of --oci-
compartment or --oci-compartment-id must be specified. If neither of those are specified, then it is
assumed that the oci-user-id specified has access to the root compartment.
Note - oci passphrase is an optional parameter for adding additional security to a user account)
8.1.1.6 GCP
--gcp-service-file <path> (path to the gcp-service-file)
--projectid <project>
8.1.2 Vcenter Add

The ‘rw vcenter add’ command is used to add vcenter configuration information to the RMM’s database.
The vcenter name added will be used an any sync command that autoprovisions a VM into a vcenter.
Page 20 of 66
Usage:
vcenter add <friendlyname>

--vcenter <ip addr>
--vcenteruser <username>
--vcenterpass <password>
[--port <port> ]
8.2 Host Capture

8.2.1 Command syntax:
This section lists the flags of an ‘rw image sync’ command and the parameters, if any, associated with
those flags. The description of the flags is in the following section.
Usage:
host capture <hostspec>
--clonename <name> | --image <name >
--flex
--os <windows | linux>
[--allow-direct-fscopy <path>]
[-b|--bw-limit|--bw_limit <Kb/s>
[--cancel]
[--exclude <file system list>]
[--exclude-san]
[--filter-file <path>]
[--force]
[-n|--friendlyname <name>]
[--include <file system list>]
[--include-san]
[-j|--jobname <job_name>]
[--no-xfer]
[--no-xfer-compress]
[--parallel <parallel_count>]
[--password <windows-password>]
[--right-size <right-size-spec>]
[--snapalloc <percent_used_size>%|<N>GB|<N>MB|<bytes>]
[--ssh-only]
[--ssh-port <ssh_port>]
[--tng]
[--user <username>]
[-v|--verbose]
[--xfer-compress]
Page 21 of 66
8.2.2 Explanation of Flags:
Below is a description of the flags used in a ‘host capture’ command.
<hostspec>
Hosts can be specified by IP address or, if the Host was previously discovered by
the RMM, the host’s FriendlyName may be used .
--clonename <name> | --image <name >
Either --clonename or --image must be specified. The <name> will be the name
of the image that is captured.
--flex
Image will be captured to a flex image
--os <windows | linux>
Specify that the os of the origin server is either windows or linux.
[--allow-direct-fscopy <path>]
Allow-direct-fscopy is applicable only to Linux captures
The path is a path to an input file, which contains a list of mountpoints- one per
line- whose associated filesystems should be directly copied from instead of copying from a snapshot.
If specified, the filesystems on a linux source server will 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
[-b|--bw-limit|--bw_limit <Kb/s >]
If the link between the origin server and the RMM is being used for other traffic,
and you wish to limit the bandwidth this capture will use, --bw-limit (and --bw_limit) will limit the
bandwidth to designated value in KB/sec.
[--cancel]
If a capture is in progress and you don’t wish to wait for it to complete, you can
cancel the capture. To do so specify “rw host capture <host friendlyname> --cancel” or “rw host capture
<clonename> --cancel”. The capture will then be terminated cleanly within a few minutes.

Excludes file systems from capture. 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 Windows, file systems may be specified by drive letter, volume label,
mountpoint path, volume serial number, or volume identifier.
Linux example:
-- exclude /dev/sdg,VolGroup01,VolGroup00/lv_tmp,/opt/data
Page 22 of 66
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:
-- exclude E:,"System Reserved",'C:\Data\',1CFB-3C0C
-- exclude '\\?\Volume{c557d989-f22e-41a7-9f98-01ff0250e318}\'
The first excludes E:, the drive labeled "System Reserved", the file
system mounted at C:\Data\, and the file system with volume serial number 1CFB-3C0C.
The second excludes the volume with the specified volume ID.
[--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 capture, specify --exclude-san.
The parameter is the path to a filter-file
A file containing paths, one per line, to exclude or include during sync
The 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/
+ /opt/data
/dev/sda1 - /grub.conf
vg_root/lv_data1 - /
vg_root/lv_data1 + /data/include
- D:\SQL\DB
+ D:\SQL\DB\IncludeMe
1CFB-3C0C - \SQL2\DB2\ExcludeData
\\?\Volume{c557d989-f22e-41a7-9f98-01ff0250e318} - \SQL3\DB3\ExcludeData
[--force]
Under unusual circumstances, a capture may fail with a relationship error. The
preferred workaround is to determine why the error occurred and fix it (see the ‘imageconfig
syncRelationshipAdd’ and ‘imageconfig syncRelationshipShow’ commands) but specifying --force will
work as well. Use this with caution, being sure that you understand what has happened before using --
force.
[-n|--friendlyname <name>]
When capturing a host specified by IP Address, the friendlyname is the name by
which the RMM will refer to the origin host. If a friendlyname is not specified, the RMM will choose a
name with the format “RW-Host-nn” where ‘n’ is a number.
[--include <file_system>,<file_system>,...]
Page 23 of 66
Includes file systems that would otherwise be excluded. File systems may be
specified using the same identifiers accepted by the --exclude option. Normally the file systems located
on removable disks and USB disks are excluded from syncs.
Example:
-- exclude datavg --include /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.
[--include-san]
Normally, SAN file systems are included by default. But if the
policy_syncPolicy_excludeSan option is enabled in the RMM options file, then SAN file systems are
excluded by default. In that case use this option to include SAN file systems.
By default the name of the job (which is used in ‘rw job’ commands such as ‘rw
job query’, ‘rw job show’) is the friendlyname of the host being captured. Use --jobname to make it be
something else
[--no-xfer]
Do a dry-run showing the operations that would be performed by the capture
without actually syncing any data.
By default the RMM performs compression across the network for captures. If
you wish to not do compression on a particular capture, specify the --no-xfer-compress option on the
capture.
[--parallel <number>]
This determines the maximum number of file systems on a server that can be
captured simultaneously. For example, if a windows server has a C drive and an E drive, a setting of ‘--
parallel 2’ will cause the C and E drive to be captured simultaneously, likely reducing the time it takes to
complete the capture. If --parallel is not specified the RMM uses “--parallel 1”.
This must be used with caution, as specifying too high of a parallel count on too
many captures can cause the RMM to thrash. Note that the RMM capacity calculations in the RMM
Prerequisites and Operational Requirements manual assume a parallel value of 1. If only a small
number of servers are being captured on the RMM simultaneously, then setting this to a value greater
than 1 may be beneficial.
[--password <windows-password>]
This is used only when Windows servers are being accessed with the deprecated
method of username/password rather than with ssh-only. This is the password of the username
(specified with the “--user” parameter) being used to access the Windows server.
If neither --ssh-only nor --password is specified for a Windows capture, the capture will
fail.
Specifies a new size for a file system on the target. The format for <right-size-
spec> is one or more comma-separated fields in the following format:
Page 24 of 66
<fs_specifier>=<target_size>
Where <fs_specifier> identifies a file system. It can be a file system label or
UUID, a mount point, an LVM <vg_name>/<lv_name>, or a device node (/dev/vda2)
And <target_size> specifies the new size. It accepts both SI (i.e. gigabytes) and
binary (gibibytes) suffixes.
Example:
--right-size vg_centos69/lv_root=10GB,/dev/sdb2=500MiB
OR
--right-size C:=30Gib,'\\?\Volume{610ef992-212f-4906-8b99-
dba9743b6c98}\'=1GB
Supported size units:
B, KB, KiB, MB, MiB, GB, GiB, TB & TiB
Based on the RMM default options, the space needed for a snapshot on a
filesystem is 15 percent of the used space of that filesystem. If needed, that 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 to show how many free extents are
available on a physical volume.
On a Windows host, use ‘vssadmin list shadowstorage’ to determine how much
free space is available for snapshots.
If the amount of space needed for a snapshot, as determined by --snapalloc is
not available, then the capture or stage 1 sync will fail.
Examples:
--snapalloc 25%
--snapalloc 10GB
--snapalloc 100MB
--snapalloc 100000bytes
If neither %, nor GB, nor MB, nor bytes is specified then “bytes” is assumed
[--ssh-only]
This should be used only with Windows captures. In order for the RMM to ssh to
the Windows origin server, the MSI package must have already been installed on the Windows origin
server as described in the Prerequisites and Operational Requirements manual
By default, ssh’ing from the RMM to a server is done over port 22. If port 22 is
already being used by some other process on the origin server, then a different port can be used.
Specify the port you wish the RMM to use when ssh’ing to the origin server.
[--tng]
Specifies that this sync should be a tng sync. When a TNG sync is performed the
RMM installs a delta file tracker on the source (as part of capture or sync) which tracks writes on the file
system at runtime. When a Stage 1 Sync runs, only these tracked changes (the delta) are synced. This
delta is the changes that occurred since the last successful sync or capture. This type of sync overcomes
Page 25 of 66
the inefficiency of rsync and significantly improves the RPO as no time is spent calculating the delta
during the sync
[--user <username>]
By default the RMM ssh’es to linux servers as ‘root’ and to windows servers as
‘SYSTEM’. If a different username is being used in your environment, use --user to specify that
username
[-v|--verbose]
This enables additional logging to be turned on. For most issues it will not be
necessary to turn this on to gather the required information for an issue. It should be turned on only if
asked to do so by Rackware Support.
[--xfer-compress]
By default the RMM will perform compression when transferring the image
across the network. It is possible to change the default by changing the value of
policy_compression_capture from its default of 1 to 0 in the /opt/rackware/data/options file. If the
RMM has been brought up with that setting and you now wish to turn compression on for a particular
capture, use the --xfer-compress option
8.2.3 Examples:
rw host capture 192.168.111.201 --image lin-host-image --os linux -n friendly-name-of-host-
w_192_168_111.201_addr --flex
%since --user is not specified, ‘root’ is the username used
rw host capture 192.168.11.200 --image win-host-image --os windows -n windows_source_host

--flex --ssh_only --ssh_port 8022
%since --user is not specified, ‘SYSTEM’ is the username used. The RMM will ssh over
port 8022
rw host capture 192.168.11.19 --clonename lin_image --os linux -- --flex

%since a friendlyname (-n) is not specified, the RMM will choose a name with the
format “RW-Host-nn” where ‘n’ is a number;
8.3 Host Sync

8.3.1 Command Syntax
This section lists the flags of an ‘rw host sync’ command and the parameters, if any, associated with
Host Sync: Syncs an origin host to a target host. The initial sync is similar to performing a capture and
Stage 2 sync, but in a single step with no intermediate image stored on the rmm. Subsequent syncs can
be run to keep the hosts in sync.
Usage:
rw host sync <source_host_spec> { --target <target_host_spec> | --autoprovision } [optional flags]
Page 26 of 66
<source_host_spec>
<target_host_spec> | --autoprovision
Each Host Sync command thus contains a specification of a source host, and a specification of a target
host. If the target host already exists, it is specified with a <target_host_spec>. If the target host does
not already exist, --autoprovision will be used with --clouduser or --vcenter and a set of cloud specific or
vcenter specific flags.
The flags in the following subsections are divided into those that can be specified on an ‘rw host sync’
command regardless of whether or not the sync command is autoprovisioning a host into a particular
cloud or a vcenter, and those that should be specified only on host syncs that are autoprovisioning hosts
into a particular cloud or a vcenter. Note that some flags in the first category are valid only when
autoprovisioning a host, but are valid for all clouds, not just a specific cloud.
8.3.1.1 Common Optional Flags
[--allow-direct-fscopy
[--allow-fs-deletion]
[-b|--bw-limit <bandwidth in KBytes per second>]
[--cancel]
[--clouduser <name>]
[--delete-all-target-fs]
[--event-script <path>]
[--event-script-arguments <argument list>]
[--exclude <file system list>
[--exclude-san]
[--force]
[--friendlyname <friendlyname>]
[--ignore-missing]
[--in-place <file system list> | ALL]
[--include <file system list]
[--include-san]
[-j|--jobname <name>]
[--keep-target-layout]
[--new-target-hostname <name>]
[--no-in-place]
[--no-reboot]
[--no-xfer]
[-o|--os <windows | linux>]
[--passthrough]
Page 27 of 66
[-p|--password [<password]]
[--provision-disks <disksize list>]
[--ssh-only]
[--target-dns <ipaddr list>
[--target-friendlyname <friendlyname>]
[--target-ignore-disk <diskid list>]
[--target-password <password>]
[--target-user <username>]
[--tng]
[--user <username>]
[-v|--verbose]
[--xfer-compress]
8.3.1.2 Amazon Web Services (AWS) Flags

[--aws-communication-ip-type]
[--aws-disk ]
[--aws-elastic < ‘new’ | <allocation-id> | <public-ip of elastic IP> >]
[--aws-instance-type]
[--aws-region]
[--aws-subnet-id]
[--aws-subnet-ip <pass ip present in specified subnet range >]
[--aws-vpc-id]
[--nsgs <nsg>[,…]
8.3.1.3 Azure Flags

[--allocate-public-ip]
[--azure-subnet-name <name>]
[--azure-vnet-name <name>]
[--azure-vm-size <name>]
[--datacenter <name>]
[--nsgs <nsg>[=<location>]
[--resource-group <name>]
[--vnet-resource-group <name>]
8.3.1.4 Cloudstack Flags

[--hypervisor-name <hypervisorname>]
[--service-offering <serviceofferingname>]
[--ssh-keypair-name <keypairname>]
[--zone-name <zonename>])
Page 28 of 66
8.3.1.5 Google Cloud Platform (GCP) Flags
[--gcp-network <gcp-network>]
[--gcp-subnet <gcp-subnet>]
[--machine-type <name>]
[--zone <name>]
8.3.1.6 OCI Flags

[--av-domain <name>]
[--bare-metal]
[--cloud-tag <name=value>,…]
[--compartment <name>]
[--compartment-id <ocid>]
[--fault-domain <name>]
[--image-name <name>]
[--image-id <ocid>]
[--network-profile <Network profile name>]
[--no-instance-provision]
[--no-public-ip]
[--nsgs <nsg>[=location],…]
[--private-ip <ip address>]
[--provision-disk-type <iscsi|paravirtualized|emulated>]
[--public-ip <ip address | EPHEMERAL>]
[--region <name>]
[--shape <shape>]
[--subnet <subnet-name>]
[--subnet-id <ocid>]
[--use-private-ip]
[--vcn <name>]
[--vcn-id <id>]
[--vcn-compartment <name>]
[--vcn-compartment-id <ocid>]
8.3.1.7 Softlayer Flags

[--domain <name>]
[--hourly ]
8.3.1.8 Vcenter Flags

[--cluster <name>]
[--datastore <name>]
Page 29 of 66
[--esxhost <esxhostname>]
[--nic <DEVICENAME=name,TYPE=type,NETWORKNAME=name,IP=x.x.x.x,CIDR=24,
GATEWAY=x.x.x.x,DNS1=x.x.x.x,DNS2=x.x.x.x,>]
[--resourcepool <name>]
[--route <PREFIX=<network>,CIDR=<length>,NEXTHOP=<address>]
[--vcenter <name>]
[--vmfolder <path>]
8.3.2 Explanation of Flags

This section defines the flags of an ‘rw host sync’ command.
Each Host Sync command contains a specification of a source host, and a specification of a target host.
If the target host already exists, it is specified with a <target_host_spec>. If the target host does not
already exist, --autoprovision will be used with --clouduser or --vcenter and a set of cloud specific or
vcenter specific flags.
The flags in the following subsections are divided into those that can be specified on an ‘rw host sync’
command regardless of whether or not the sync command is provisioning a host into a cloud or a
vcenter, and those that should be specified only on host syncs that are provisioning hosts into a
particular cloud or a vcenter.
[--allow-direct-fscopy]
Allow-direct-fscopy is applicable only to Linux syncs.
If specified, the filesystems on a linux source server will 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.
preferable.
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).
[-b|--bw-limit <bandwidth in KBytes per second>]

Page 30 of 66
and you wish to limit the bandwidth this sync will use, --bw-limit will limit the bandwidth to the
designated value in KB/sec.
[--cancel]
This option allows an in-progress sync to be terminated. If a capture is in
progress and you do not wish to wait for it to complete, you can cancel the capture. To do so specify
“rw host sync <source host | target host> --cancel”. Note that though a ‘host sync’ command has both
a source host friendly name and a target host friendlyname, only one of those need to be specified
when the --cancel option is used. The sync will then be terminated cleanly within about a minute.
If --cancel is used, no other optional flags should be specified.
[ --clouduser <name>]
This option is valid only when --autoprovision is specified. If --autoprovision is
specified then either --clouduser or --vcenter must be specified. The name of the clouduser must have
been previously been added with the ‘rw clouduser add’ command.
This option 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.
The full path of an RMM event script, that will execute commands either just
before or just after a ‘host sync’ command
[--event-script-arguments <argument list>]

This represents the list of arguments passed to the RMM event script
referenced by --event-script

number (e.g. 8:1)
Linux example:
--exclude /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:
--exclude E:,"System Reserved",'C:\Data\',1CFB-3C0C
--exclude '\\?\Volume{c557d989-f22e-41a7-9f98-01ff0250e318}\'
The first excludes E:, the drive labeled "System Reserved", the file system
mounted at C:\Data\, and the file system with volume serial number 1CFB-3C0C.
Page 31 of 66
[--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, specify --exclude-san.
The parameter is the 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:
Examples:
+ /opt/data
- /opt/*
- D:\SQL\DB\*
\\?\Volume{c557d989-f22e-41a7-9f98-01ff0250e318} -
\SQL3\DB3\ExcludeData
[--force]
If a sync fails due to a relationship error, the --force option can be used to force
the sync to be executed. This option should be used only when there is a full understanding of why the
sync failed and why this will fix it. Setting up the relationship properly is the best course of action to
take when there is an error due to a relationship failure. Using --force inappropriately can have
undesirable results.
[--friendlyname <friendlyname>]
Assigns the friendlyname representing the source host when an initial ‘host
sync’ (in which the source host is specified by IP address) is executed. In subsequent host syncs the
source host may be represented by this friendlyname. If not specified, the RMM will choose a
friendlyname of the form RW-HOST-nn, where ‘nn’ is a two digit number.
[--ignore-missing]
Using this option may be needed if a Host 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 there being a multipath disk
on the target. This option is also used if a Host 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.
Page 32 of 66
[--in-place <file system list>| ALL]
Use in-place file syncing on the listed file systems. 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.
[--include <file system list]

Example:
--exclude datavg --include /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.
[--include-san]
[-j|--jobname <name>]
Sets a jobname for this ‘host sync’ job; if not set, the jobname defaults to
“jobname-<source host friendlyname>”
Specifies option to retain all partitions and disks on the target without
modifying it to match those of the source.
Specifies a new hostname for the target. When not given the target hostname
will be the same as the origin hostname. This is effective only on the first ‘host sync’ for a source/target
pair.
[--no-in-place]
Do not automatically use in-place sync for full file systems.
[--no-reboot]
At the end of a host sync the target server will remain in the RackWare kernel
rather than being rebooted into the Linux or Windows OS. Setting this option will reduce the time it
takes to complete a host sync. But if/when it is desired that the target server be booted into Linux or
Windows, the ‘rw host release’ command will need to be issued.
[--no-xfer]
Do a dry-run showing the operations that would be performed by the sync, but
without syncing any data.
By default the RMM will perform network compression when performing a host
Page 33 of 66
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, use the --no--xfer-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.
[-o|--os <windows | linux>]

This is required on the first host sync for a source/target pair. It specifies the os
type of the source host. On subsequent host syncs this parameter should not be used.
synced simultaneously. For example, if a linux server has a /dev/sda3 file system and a /dev/sda4 file
system a setting of ‘--parallel 2’ will cause /dev/sda3 and /dev/sda4 to be synced simultaneously, likely
reducing the time it takes to complete the sync. If the --parallel flag is not used, the RMM determines
an appropriate value for --parallel based on the number of cpu cores on the source server and on the
target server, using the formula
parallel_count=MIN (#cpu_cores_on_source, #cpu_cores_on_target)
This must be used with caution, as specifying too high of a parallel count on a
sync can cause the sync to thrash.
[--passthrough]
When this option is not set, the RMM sets up the communication paths
between the source host and the target host and the data path goes directly from the source host to the
target host.
When this option is set, the communication path goes through the RMM, which
performs a network level forwarding function. This option should be used only when the environment is
such that the source host can’t communicate directly with the target host.
[-p|--password [<password]]
This is the Windows password for the Windows user specified with --user in an
initial host sync. It is used only when --ssh-only is not being used.
[provision-disks <disksize list>]

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.
Supported size suffixes are B, KB, KiB, MB, MiB, GB, GiB, TB & TiB
Specifies a new size for a file system on the target when performing a Stage 2
sync (either with or without the --autoprovision option). The format for <spec> is one or more comma-
separated fields in the following format:
<fs_specifier>=<size>
Where <fs_specifier> identifies a file system. It can be a file system label
Page 34 of 66
or UUID, a mount point, an LVM <vg_name>/<lv_name>, or a device node (/dev/vda2). <size> specifies
the new size pf the file system on the target.
Example:
. OR
dba9743b6c98}\'=1GB
Supported size suffixes are:
On a Linux host, use the ‘pvs’ command shows how many free extents are
[--ssh-only]
This is valid only with Windows syncs. It indicates that the RMM will access the
source and the preprovisioned target (if it exists) without a windows password using ssh. In order to
access a host with ssh the RackWare MSI package must have already been installed on the Windows
origin server (and the preprovisioned target server) as described in the Prerequisites and Operational
Requirements manual.
By default, ssh’ing from the RMM to a server is done over port 22. If port 22 is
already being used by some other process on the origin server, then a different port can be used.
Specify the port you wish the RMM to use when ssh’ing to the origin server.
[--target <target_host_spec>]
--target must be specified on a host sync if --autoprovision is not specified. The
target_host_spec may be an ip address, indicating that RMM knows the target just by its IP address, so it
has not yet been discovered by the RMM. It may also be a friendlyname, indicating that it has been
discovered by the RMM (either through an explicit ‘rw host discover’ command, or through a previous
‘rw host sync’command getting past the discover phase)
[--target-dns <ipaddr list>| SOURCE | TARGET]

By default, when performing an initial host sync, the target DNS settings will be
Page 35 of 66
left as they were initially on the target. To change that, use --target-dns as follows:
Use “SOURCE” to copy the dns server addresses from the source server
If you wish to specify one or more custom dns server ip addresses, enter them
as a comma separated list.
Use “TARGET” to retain the existing dns server addresses on the target server.
This is the default setting.
[--target-friendlyname <name>]
This is valid on the initial host sync when the preprovisioned target server is
specified by IP address, or when autoprovisioning is being done. It indicates the name by which RMM
will refer to the target server.
[--target-ignore-disk <diskid>,<diskid2>]
When an initial host sync is being done to a preprovisioned target, the diskid(s)
specified will be ignored when the RMM is determining on which target disks the source file systems
should be placed. Allow the volumes and file systems on the diskid(s) specified will be left untouched.
The diskid(s) will be remembered by the RMM on subsequent 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.
When used on an initial host sync with a preprovisioned target, represents the
Windows password for the user specified by --target-user on the target server. This can be used only
if the source host is being accessed via --user and --password.
This parameter is not valid on subsequent host syncs.
When used with autoprovisioning into OCI, this can be used to provide the
password for the custom image provided in --image-name. Please see the OCI subsection of this
section for additional information.
When used on an initial host sync with a preprovisioned target, represents the
username to use to access the Linux or Windows target host.
This parameter is not valid on subsequent host syncs.
When used with autoprovisioning into OCI, --target-user can be used to provide
the username for the custom image provided in --image-name. Please see the OCI subsection of this
section for additional information.
[--tng]
When --tng is specified on a host 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 subsequent syncs are
run, only these tracked changes (delta) are synced. This delta is the changes occurred since the last
successful. This type of sync overcomes the inefficiency of rsync and significantly improves the RPO as
no time is spent calculating the delta during the sync.
[--user <username>]
This is the username to be used when accessing the source host. It should be
Page 36 of 66
specified only on the initial host sync if the source host is specified by ip address. If not specified, ‘root’
will be used for Linux hosts and ‘SYSTEM’ will be used for Windows hosts.
[-v|--verbose]
asked to do so by Rackware Support
[--xfer-compress]
By default the RMM will perform network compression when performing a host
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 for host syncs has been changed so that
compression is off by default, and you wish to have network compression done on a particular host
sync, use the --xfer-compress option on that sync.
To view the current default settings, use the command “rw rmm show -v | grep
8.3.2.2 AWS Flags

The following options are valid when using --autoprovision with ‘--clouduser AWS’
[--aws-vpc-id <AWS VPC ID > ]

This is a mandatory parameter when using ‘--clouduser AWS’. The VPC ID will
come from your account. Each VPC ID is in a particular region. A sample <AWS VPC id> is “vpc-
a2345678”
[--aws-subnet-id <AWS Subnet ID]

This is a mandatory parameter when using ‘--clouduser AWS’which comes from
your account. The VPC ID may be associated with multiple subnets; this parameter defines which of
those subnets should be used when launching the instance. A sample <AWS Subnet ID> is “subnet-
a234567”.
[--aws-region <name >]

The <name> is one of the AWS defined regions. This needs to be specified if you
wish the VM to be created in a region other than the region of the vpc-id. If not specified, the region of
the vpc-id will be used.
[--aws-instance-type <Specify the instance type to be used with AWS> ]

This optional parameter defines the cpu/memory/storage/networking capacity
of the instance being launched. If not specified, the RMM will choose an instance based on the
characteristics of the source server
[--aws-communication-ip-type < Ip type (public/private) to be used to perform RMM

operations> ]
This optional parameter describes the type of IP that the RMM will use when it
communicates with the newly spawned instance. Possible values are “public” or “private”. If “private”
is used, then the vpc-id and the subnet-id of the spawned instance should be the same as the RMM. If
not specified, a value of “private” is assumed.
Page 37 of 66
When specified, indicates that the instance being launched will have an elastic
ip. The elastic ip may be specified via an existing elastic allocation-id or an existing elastic public ip
address, or, if ‘new’ is specified, a new elastic ip will be created for this instance.
If not specified, the newly provisioned instance will not have an elastic ip.
[--aws-subnet-ip <ip address>]

When specified, defines the private IP address that should be used for the newly
provisioned instance. It must be in the allowable range of ip addresses according for the subnet-id in
which the instance is being provisioned.
If not specified, AWS will select the private ip address to be used by the newly
provisioned instance.
[--aws-disk <aws-disk-spec>]
This optional parameter defines the disks that should be associated with the
instance being provisioned. If not specified, the RMM will choose the number of disks and the
specifications of the disks based on what is on the source server.
The <aws-disk-spec> is of the form:
‘NUM=<number>,SIZE=<size in GiB of the disk>, IOPS=<Max IOs per
second the disk is allowed to perform>, TYPE=<disk types as defined in
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html>’
Each of the 4 parts must be specified
If multiple disks need to be specified, then multiple --aws-disk statements must
be specified
Examples:
To specify 1 1000GiB disk of type st1 limited to 1600 IOPS:
--aws-disk ‘NUM=1,TYPE=st1,IOPS=1600,SIZE=1000’
To specify 2 2000GiB disks of type gp2 limited to 20000 IOPS
--aws-disk ‘NUM= 1,TYPE=gp2,IOPS=20000,SIZE=2000’ --aws-disk
‘NUM=2,TYPE=gp2,IOPS=20000,SIZE=2000’
Note - If using aws-disk with a Linux server, the first disk must be at least 30 GB ;
if using aws-disk with a Windows server, the first disk must be at least 50 GB. Disks after the first one
may be any size.
[--nsgs <nsg>[,…]]
This optional parameter includes one or more network security groups. The
network security group can be identified by an nsg name or an nsg id. While network security groups for
other clouds include an optional location, in AWS a location is never used and will be ignored if
specified.
Example:
--nsgs sg-b3876125,Launch-Wizard-4
8.3.2.3 OCI Flags

The flags in this section are valid when using --autoprovision with a clouduser name that was added with
a cloudprovider of “oci”.
Page 38 of 66
When ‘--autoprovision is used with a clouduser name that was added with cloudprovider of oci, --av-
domain and either --subnet or --subnet-id are required flags. If --subnet is used, then --vcn or --vcn-id
must be specified.
[--av-domain <name>] (availability domain)

An OCI Availability Domain is a physical datacenter. An Availability Domain
contains one or more Fault Domains. Availability domains are physically isolated from each other so a
problem in one Availability Domain is unlikely to affect another.
--av-domain is required when ’--autoprovision --clouduser <name with oci
provider>’ is specified on the ‘host sync’ command..
For more information
see: https://docs.cloud.oracle.com/iaas/Content/General/Concepts/regions.htm#AboutRegionsandAvail
abilityDomains
[--bare-metal]
If specified, means that the launched instance should reside on a bare metal
machine
When creating an instance in OCI (via ‘rw host sync’ or ‘rw image sync’), you can
assign tags to the instance –associating metadata with the instance in the form of key value pair. OCI
supports defined tags and free form tags. RMM provides the ability to associate both defined and free
form tags for an autoprovisioned host using the --cloud-tag parameter. For OCI, the RMM supports two
type of tags:
a) Defined tags as: NameSpace.TagKey=TagValue
b) Freeform tags as: TagKey=TagValue
For example, --cloud-tag Rackware.OperatingSystem=Linux,Tag1=Value1,Tag2=Value2
For either type of tag, the tag key and tag value to use must match what is in
your OCI account.
The name of the compartment to use for finding images (if image is specified by
--image-name) and provisioning resources. If an image is specified by name, it must exist in this
compartment. Instances and Block Volumes will be created in this compartment. If the compartment
name is unambiguous in the compartment hierarchy, it can be specified simply by name. Otherwise, the
fully qualified compartment name must be provided (i.e.
/parent_compartment/child_compartment/compartment).
If not provided, Compartment will default to the root compartment.
Either compartment” or compartment id, but not both, may be specified
The OCID of the compartment to use for finding images (if image is specified by
name) and provisioning resources. If an image is specified by name, it must exist in this compartment.
Page 39 of 66
Instances and Block Volumes will be created in this compartment.
If not provided, the compartment id will default to the ocid of the root
compartment
Specifies a fault domain name to use when launching an instance. If not
provided, no Fault Domain will be provided when launching the instance, and OCI will automatically
choose a Fault Domain for the instance.
This is the name of an oci image - most likely a custom image. If specified, it
must reside in the “oci compartment”/”oci compartment id” specified above. If not provided, an image
will be chosen automatically that best matches the source machine based on the images available in OCI
[--image-id <ocid>]
This is the same as --image-name, but specified as an OCID rather than a name)

The name of a network-profile. A Network Profile defines a set of OCI flags. If a
network profile is specified, the value of its compartment, vcn, and subnet would not need to be
specified on the ‘image sync’ command. Network Profiles are currently not implemented.
This flag is used to determine a compatible shape, image and disk configuration
for a target host without actually provisioning a VM.
[--no-public-ip]
If not specified, then a public IP will be assigned to the instance in OCI. --no-
public-ip should be specified only when it is known that the RMM can reach the launched instance over
it's private ip assigned by Oracle
Provide one or more network security groups to be used. The security groups
should be given as a comma separated list of key/value pairs where the key is the nsg name (or the nsg
OCID) and the value is the location of the security group. Because this list is comma separated, network
security groups with commas in the name cannot be added during autoprovision and must be added
manually later. The location is a compartment name, path or ID and is required when the security group
is identified by name and is in a different compartment from the VCN. Otherwise, the location is not
necessary.
Example:
nsgs nsg1,ocid1.networksecuritygroup...nsg2,nsg3=comp1,nsg4=ocid1.compartment...comp2
The first value is an nsg name with no location (because the nsg is in the same
compartment as the VCN), the second is an nsg OCID with no location, the third is an nsg name with a
compartment name for the location and the fourth is an nsg name with a compartment OCID for the
location.
Page 40 of 66
[--private-ip] <ip address>
The private ip address which will be assigned to launched VM. If not specified,
then OCI will choose a private IP address in the appropriate subnet
The type of attachment to use for provisioned disks. If --provision-disk-type is
not used, the paravirtualized attachment type will be used for any block volumes being provisioned.
[--public-ip <ip address> | EPHEMERAL]

This field has meaning only if “no-public-ip” is not set.
If “no-public-ip” is not set, then the <ip address> parameter represents the
public ip address which will be assigned to launched VM. It must be an IP in OCI’s pool of reserved
public IP addresses.
If “no-public-ip” is not set, and the value EPHEMERAL is used, then OCI will
choose an appropriate public IP address for this instance
[--region <name>]
Specifies the region into which the autoprovisioned VM will be placed. If not
specified, the region used in the relevant ‘rw clouduser add’ command will be used.
[--shape <shape>]
Specify the shape of the launched instance. If not specified, the RMM will
choose an appropriate shape based on the memory and CPUs of the source server
[--subnet <name>] (Selects a subnet)

The name of the Subnet to use. If the subnet is specified by name, then the
Subnet must exist in the compartment of the VCN being used during the autoprovision. When the
subnet is specified by name, then either vcn or vcn-id must be specified. Either --subnet or --subnet-id
(but not both) must be specified.
[--subnet-id <ocid>] (Same as subnet but using ID instead of name)

The OCID of the Subnet to use. Either --subnet or --subnet id (but not both)
must be specified. If the subnet is specified by ID, then the subnet may be in a compartment different
than the compartment of the VCN being used during the autoprovision.
This is the password of the username of the custom image. For Linux custom
images, it should never be specified. For Windows images, it should be specified only if the Windows
custom image is accessed via a username/password, rather than with ssh-only.
Note that --target-password has a different meaning when not used with OCI
autoprovisioning. See the ‘Common Optional Flags’ section for that description.
This is the username for the custom image. “Target User” is the name of the
Operating System user which the RMM can use to connect to “Image Name”. It should be specified only
when a custom image is being used that does not use cloud-init. All custom images that are based on
OCI provided images include cloud-init. If an Ubuntu "Image Name" is specified, and a 'Target User' is
not, then the username 'ubuntu' is assumed. If a non-Ubuntu Linux “Image Name” is specified, and a
Page 41 of 66
‘Target User’ is not, then the username ‘opc’ is assumed.
If a Windows “Image Name” is specified which includes cloud-init, and a ‘Target
User’ is not, then the username and password will be generated by OCI after launching the instance and
those credentials will be used by the RMM when first connecting to the instance. If a Windows “Image
Name” is specified which does not include cloud-init, the 'Target User" must be provided.
Note that --target-user has a different meaning when not used with OCI
[--use-private-ip]
Specifying --use-private-ip will tell RMM to use the private ip of the target to
communicate with the target. Use this flag only if it is known that the target will be reachable from
RMM over its private IP
[--vcn <name>]
The name of the VCN to use. This VCN must exist in the VCN Compartment. If
the subnet is specified by name, then either vcn or vcn-id must be specified
[--vcn-id <ocid>] (Same as vcn but using ID instead of name)

The OCID of the VCN to use. This is the same as --vcn, except the vcn is
specified by ID instead of my name. The vcn-id must exist in the vcn compartment id. If the subnet is
specified by name, then either vcn or vcn-id must be specified. If the subnet is specified by ID, then
neither vcn nor vcn-id are required parameters.
The name of the compartment that contains the VCN referenced in this
command when the VCN is specified by name. If the compartment name is unambiguous in the
compartment hierarchy, it can be specified simply by name. Otherwise, the fully qualified compartment
name must be provided (i.e. /parent_compartment/child_compartment/compartment).
If neither vcn-compartment nor vcn-compartment-id are provided, vcn-
compartment will default to the same compartment as in the Compartment paramter.
[--vcn-compartment-id <ocid>] The ID of the compartment containing the vcn or

the vcn-id being used in this command.
8.3.2.4 Azure Flags

The following options are valid when --autoprovision is specified with ‘--clouduser Azure’
--resource-group <name>
This is a required parameter. It indicates the name of the resource group into
which the new VM should be placed
[--datacenter]
The datacenter within resource group in which the new VM should be placed.
If not specified, the datacenter that is specified in the clouduser will be used.
Page 42 of 66
The size (e.g “Basic_A1”, or “Standard_A2”, or “Standard_D2”) of the VM to be
provisioned. If not specified, the RMM will choose a size that most closely matches the source server.
If specified, the VM will be created with a public IP address.
[--azure-vnet-name]
Specifies the virtual network name where the autoprovisioned VM will be
placed. This should be specified only if the vnet-name already exists in the resource group and the
datacenter of the Azure account. If not specified, the RMM will create a vnet named “<vmName>-vnet”
and place the autoprovisioned VM in that vnet.
Specifies the subnet name of the autoprovisioned VM in the vnet of the
autoprovisioned VM. This should be specified only when the subnet name already exists in the vnet-
name. If not specified, a subnet named <vmName-subnet> will be created in the vnet of the
autoprovisioned VM.
Provide one or more network security groups to be used. The security group
should be given as a key/value pair, where the key is the group name and the value is the location of the
security group. The location is a resource group name and is optional. If not provided, the group will be
put in the resource group the VM will provision in. This will add the network security group to the
subnet the VM is in, as recommended by Azure. If the user needs to apply the network security group to
the VM NIC, use the --nic-nsgs option instead. Azure only supports one network security group per
subnet.
Example:
--nsgs test-nsg=test-resource-group
The name of the resource group that contains the azure-vnet-name specified in
this command. If not specified, the name used in --resource-group will be used.
[--target-ignore-disk] <disk spec>

Please refer to the description of this parameter in the subsection “Command
Syntax” of the Image Sync section. When autoprovisioning Linux servers into Azure, always specify “--
target-ignore-disk /dev/sdb”; when autoprovisioning Windows servers into Azure, always specify “--
target-ignore-disk disk1”
8.3.2.5 GCP Flags

The following options are valid when --autoprovision is specified with ‘--clouduser gcp’
Selects a GCP network
Selects a GCP subnet
Page 43 of 66
[--zone <zone>]
The Zone for GCP autoprovision
[--allocate-public-ip] create VM with public IP address
[--machine-type < GCP machine type>]

Selects a type (cpu, memory) of machine to autoprovision

The following options are valid when --autoprovision is specified with ‘--clouduser cloudstack’
name of hypervisor on which user wants to launch target vm
Specifies a service offering name (CPU / RAM ) for target VM
Specifies an ssh keypair used to launch the target vm.
[--zone-name <zonename>]
Use with Open Source cloudstack autoprovision; specifies the zone within
which the user want to launch the target virtual machine

The following options are valid when --autoprovision is specified with --vcenter
[--cluster <name>]
Selects the cluster in vCenter to provision the machine on.
Selects a datacenter when using --autoprovision
Selects the datastore in vCenter to provision the machine on.
[--esxhost <name>]
ESX host name when using --vcenter
Specifies NIC configuration when using --vcenter:
Type may be "e1000" or "vmxnet"
NETWORKNAME is the name of the network in vmware
The --nic option may be repeated to specify multiple NICs.
resource pool when using --vcenter
Specifies network routes when using --vcenter
Page 44 of 66
For example, to specify a route in 192.168.1.0/24 via 192.168.15.10, use
--route PREFIX=192.168.1.0,CIDR=24,NEXTHOP=192.168.15.10
The --route option may be repeated to specify multiple routes.
[--vcenter <name>]
Selects a vcenter to use when using --autoprovision
[--vmfolder <path>]
vmware folder path when using --vcenter

The following options are valid when --autoprovision is specified with ‘--clouduser softlayer’.
[--hourly ]
Use hourly billing on this VM; if not specified, the billing type from the
‘clouduser add’ (which defaults to --monthly) will be used.
[--domain <Domain Name>]

The domain name of this VM, e.g. “rackwareinc.com”. If not specified, the value
used on the ‘clouduser add’ will be used.
[datacenter <Location of Datacenter>]

The datacenter where this VM should reside. This parameter is required when
autoprovisioning into Softlayer.
8.3.3 Examples
8.3.3.1 Initial Host Syncs (Preprovisioned target)
rw host sync 172.16.6.21 --friendlyname win-source --ssh-only --target 192.168.1.2 --os windows
%ssh-only access to source and target, both using SYSTEM as the userid; the target
%friendlyname will be of the form RW-Host-nn
rw host sync 172.16.6.21 --friendlyname win-source --user Administrator --password

R@3kware! --target 192.168.1.2 --target-friendlyname win-tgt --target-user admin --target-password
Psw1@2abR --os windows
%both source and target username and password supplied
rw host sync 172.16.6.22 --friendlyname lin-source --user rackware --target autoprovision --

clouduser oci-cloud --vcn vcn1 --subnet Subnet1 --av-domain hxxx:US-ASHBURN-AD-1 --flex --region us-
ashburn-1 --target-friendlyname centos7-tgt1 --compartment DRcomp
8.3.3.2 Initial Host Syncs (Autoprovisioned Target)

rw host sync centos7-src --os linux --autoprovision --clouduser ocitest --compartment /Network-
profile7 --vcn vcn-20190403-2300 --subnet "Public Subnet" --av-domain hxxx:US-ASHBURN-AD-1 --
target-friendlyname centos7-tgt
%linux source server is accessible as root, and has previously been discovered; ‘ocitest’
was previously defined with ‘clouduser add command; linux target is being provisioned in the Network-
profile7 compartment, which is one level under the root compartment.
Page 45 of 66
rw host sync 172.16.6.22 --friendlyname win-source --user rackware --target --ssh-only --
autoprovision --clouduser oci-cloud --vcn vcn1 --subnet Subnet1 --av-domain hxxx:US-ASHBURN-AD-1 --
flex --region us-ashburn-1 --target-friendlyname centos7-tgt1 --compartment DRcomp --target-
friendlyname win-target --os windows
%Source windows server is accessible via the SYSTEM user; target server win-target will
be provisioned in the OCI compartment DRcomp
8.3.3.3 Subsequent Host Syncs

This shows examples of subsequent host syncs, that is, a host sync done after the initial host
sync.
rw host sync lin-source --target lin-target
rw host sync win-source --target win-target
8.4 Image Sync

8.4.1 Command Syntax
This section lists the flags of an ‘rw image sync’ command and the parameters, if any, associated with
There are three variants to the ‘rw image sync’ command.
#1: Synchronizes a source Host with a CAPTURED Image. In this context the CAPTURED Image should be
the result of a previous ‘capture’ command. This is referred to as a Stage 1 Sync. For example,
“rw image sync source-host --image source-host-IMAGE --flex”
#2 Synchronizes a CAPTURED Image (likely the result of a previous sync operation from #1 above) with
an autoprovisioned host in a cloud. An autoprovisioned host is one which is created during a Stage 2
Sync. This is referred to as an autoprovisioned Stage 2 Sync. For example,
rw image sync source-host-IMAGE --autoprovision --friendlyname target-host--clouduser
<name> <cloud specific flags> --flex
#3 Synchronizes a CAPTURED Image (likely the result of a previous sync operation from #1 above) with a
target Host. This is referred to as a preprovisioned Stage 2 Sync For example,
rw image sync source-host-IMAGE --target target-host --flex
Usage:
rw image sync <from-host-or-image> --flex --image <name> | --target <host | ipaddr > | --autoprovision [optional flags]
Using --image means that this is a Stage 1 sync, and using --target or --autoprovision means this
is a Stage 2 sync
<from-host-or-image>
The name of the source host or image that is being synced from
Page 46 of 66
[--image <imagename>]
The name of the image that is being synced to. One of --image or --target or --
autoprovision must be specified
[--target <target_hostspec>]
The target host friendlyname or ip address which is being sync’ed to. One of --
image or --target or --autoprovision must be specified
[--autoprovision]
Indicates that the target host will be created during the sync operation. One of -
-image or --target or --autoprovision must be specified). If --autoprovision is used, there is a set of flags
specific to a cloud type that must be specified.
The flags in the following subsections are divided into those that can be specified on an ‘rw image sync’
command regardless of whether or not the sync command is provisioning a host into a cloud or vcenter,
and those that should be specified only on Stage 2 syncs that are provisioning hosts into a particular
cloud or a vcenter.

[--allow-direct-fscopy <path_to_input_file>]
[-b|--bw_limit|--bw-limit <Kb/s>]
[--cancel]
[--event-script-arguments <arg1>,<arg2>,<arg3>,...]
[--exclude <file_system>,<file_system>,...]
[--exclude-san]
[--force]
[--ignore-missing]
[--include-san]
[--inplace|--in-place <filesystem,filesystem,...|ALL>]
[--no-in-place]
[--no-reboot]
[--no-xfer]
[--os <linux|windows>]
[--password <password>]
[--provision-disks <disksize list>]
Page 47 of 66
[--ssh-only]
[--target-dns <ipaddr list>
[--target-ignore-disk <diskid>]
[--target-password <username>]
[--tng]
[--user <username>]
[-v|--verbose]
[--xfer-compress]
8.4.1.2 AWS Flags

[--aws-communication-ip-type]
[--aws-disk ]
[--aws-instance-type]
[--aws-region]
[--aws-subnet-id]
[--aws-subnet-ip <pass ip present in specified subnet range >]
[--aws-vpc-id]
[--nsgs <nsg>[,…]
8.4.1.3 Azure Flags

[--azure-vnet-name <name>]
[--nsgs <nsg>[=<location>]]
[--resource-group <name>]

[--zone-name <zonename>])
8.4.1.5 Google Cloud Platform (GCP) Flags

Page 48 of 66
[--machine-type <name>]
[--zone <name>]
8.4.1.6 OCI Flags

[--av-domain <name>]
[--bare-metal]
[--image-id <ocid>]
[--no-public-ip]
[--private-ip <ip address>]
[--region <name>]
[--shape <shape>]
[--subnet <subnet-name>]
[--subnet-id <ocid>]
[--use-private-ip]
[--vcn <name>]
[--vcn-id <ocid>]
[--vcn-compartment-id <ocid>]

[--domain <name>]
[--hourly ]
8.4.1.8Vcenter Flags
[--cluster <name>]
Page 49 of 66
[--vcenter <name>]
[--vmfolder <path>]
8.4.2 Explanation of Flags

This section defines the flags of an ‘rw image sync’ command.
The set of required flags are:
--flex
This required parameter must be present on all ‘rw image sync’ commands. It
rd
indicates that this is a 3 generation “flex sync” sync.
<from-host-or-image>
if --image is specified, then this is the host that is being sync’ed from
If --target is specified, then this is image that is being sync’ed from
If --autoprovision is specified, then this is the image that is being sync’ed from
[--image <name>]
This parameter is specified on all Stage 1 Syncs. <name> is the name of an
image that has already been captured, and must have an Image State of CAPTURED. Either --image or --
target or --autoprovision must be specified on all ‘rw image sync’ commands.
[--target <name | ipaddr>]

This parameter is specified on all Stage 2 Syncs involving preprovisioned targets.
The target host must be specified by ip address on the first Stage 2 Sync involving a target host that has
not yet been discovered by the RMM. If the target has been discovered (as will be the case on all
subsequent (ie not the first one) syncs of the target host), then the target may be specified by name. A
preprovisioned target host can always be specified by ip address.
[--autoprovision]
Setting this option instructs the RMM to provision a new machine in a cloud as
the target host of the sync. If --autoprovision is used, then either ‘--clouduser <name>’ or ‘--vcenter
<name>’ must be specified. Each clouduser provider type has a set of valid flags when --autoprovision
is used; those flags are defined on a per-cloud basis at the end of this section. Similarly, --vcenter has a
set of flags defined when it is used.
With the ‘image sync’ command, there is a set of optional flags that are valid regardless of the cloud
type of the target. For Stage 2 Syncs with --autoprovision, there is also a set of flags that are specific to a
cloud type that defines where in the cloud the host should be created. The common set of optional
flags are shown first, followed by the flags specific to each cloud type.

[--allow-direct-fscopy <path_to_input_file>]
Allow-direct-fscopy is applicable only to Linux syncs.
The input file contains a list of mountpoints- one per line- whose associated
Page 50 of 66
filesystems should be directly copied from instead of copying from a snapshot. If specified, the
filesystems on a linux source server will 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.
preferable
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).
[-b|--bw_limit|--bw-limit <Kb/s >

and you wish to limit the bandwidth this sync will use, --bw-limit will limit the bandwidth to the
designated value in KB/sec
[--cancel]
This option allows an in-progress sync to be terminated. If a sync is in progress
and you don’t wish to wait for it to complete, you can cancel the capture. To do so specify “rw image
sync <host | image> --cancel”. Note that though an ‘image sync’ command has both a host and an
image, only one of those need to be specified when the --cancel option is used. The sync will then be
terminated cleanly within a few minutes.
If --cancel is used, no other optional flags should be specified.
This option is valid only when --autoprovision is specified. If --autoprovision is
specified then either --clouduser or --vcenter must be specified. The name of the clouduser must have
been previously been added with the ‘rw clouduser add’ command.
This option is valid only with a Stage 2 Sync. It 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 Stage 2 Sync so that the existing file system ids will be deleted.
The full path of an RMM event script, that will execute commands either just
before or just after an ‘image sync’ command
[--event-script-arguments <arg1>,<arg2>,<arg3>,...]
The arguments passed to the RMM event script referenced by --event-script
Page 51 of 66
[--exclude <file_system>,<file_system>,...]
number (e.g. 8:1)
Linux example:
--exclude /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:
--exclude E:,"System Reserved",'C:\Data\',1CFB-3C0C
--exclude '\\?\Volume{c557d989-f22e-41a7-9f98-01ff0250e318}\'
The first excludes E:, the drive labeled "System Reserved", the file system
mounted at C:\Data\, and the file system with volume serial number 1CFB-3C0C.
[--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, specify --exclude-san.
The parameter is the path to a filter-file.
A filter-file contains paths, one per line, to exclude or include during a sync
The file can have paths in the following formats:
Examples:
+ /opt/data
- /opt/*
- D:\SQL\DB\*
\\?\Volume{c557d989-f22e-41a7-9f98-01ff0250e318} -
\SQL3\DB3\ExcludeData
[--force]
Under unusual circumstances, a capture may fail with a relationship error. The
preferred workaround is to determine why the error occurred and fix it (see the ‘imageconfig
syncRelationshipAdd’ and ‘imageconfig syncRelationshipShow’ commands) but specifying --force will
Page 52 of 66
work as well. Use this with caution, being sure that you understand what has happened before using --
force.
[--ignore-missing]
Ignore any missing drives in microkernel. Using this option may be needed if 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 there being a multipath disk on the target. This option is also used if a 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
Example:
--exclude datavg --include /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.
[--include-san]
[--inplace|--in-place <filesystem,filesystem,...|ALL>]
In-place file syncing will be used on the listed file systems. 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.
Sets a jobname for this ‘image sync’ job; if not set, the jobname defaults to
“jobname-<source host friendlyname>”
When specified with --autoprovision, specifies that all partitions and disks on
the target should be kept the same rather than modifying them to match the source server.
Valid for a Stage 2 Sync. Specifies a new hostname for the target. When not
given the target hostname will be the same as the origin hostname.
[--no-in-place]
Do not automatically use in-place sync for full file systems.
Page 53 of 66
[--no-reboot]
Valid on a Stage 2 sync; if specified, at the end of a Stage 2 sync the target
server will remain in the RackWare kernel rather than being rebooted into the Linux or Windows OS.
Setting this option will reduce the time it takes to complete a Stage 2 sync. But if/when it is desired
that the target server be booted into Linux or Windows, the ‘rw host release’ command will need to be
issued.
[--no-xfer]
Specifying --no-xfer allows you to see what partitions would be included in the
‘image sync’ command with the flags specified in the command, without actually transferring any of the
data.
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 /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 use the --no--
xfer-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 use the --no-xfer-compress option.
To view the current settings, use the command “rw rmm show -v | grep
[--os <linux|windows>]
In general, this will not be used on an ‘image sync’ command. It is needed only
in the case where a Windows image still exists on the RMM, but the associated source host has been
deleted from the RMM. In that case --os must be used to specify if the source host is a windows host or
a linux host.
synced simultaneously. For example, if a linux server has a /dev/sda3 file system and a /dev/sda4 file
system a setting of ‘--parallel 2’ will cause /dev/sda3 and /dev/sda4 to be synced simultaneously, likely
reducing the time it takes to complete the sync. If --parallel is not specified the RMM uses “--parallel 1”.
This must be used with caution, as specifying too high of a parallel count on too
many syncs can cause the RMM to thrash. Note that the RMM capacity calculations in the RMM
Prerequisites and Operational Requirements manual assume a parallel value of 1. If only a very small
number of servers are being synced on the RMM simultaneously, then setting this to a value greater
than 1 will likely be beneficial.
[--password <password>]
In general, this will not be used on an ‘image sync’ command. It is needed only
in the case where a Windows image still exists on the RMM, but the associated source host has been
deleted from the RMM. In that case if a Windows server is being accessed via username/password
(rather than with --ssh-only) then --password is used to specify the password used to access the source
server.
Page 54 of 66
[provision-disks <disksize list>]
Can be used to specify the disk sizes that will be autoprovisioned. If not used,
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.
Supported size suffixes are B, KB, KiB, MB, MiB, GB, GiB, TB & TiB
Specifies a new size for a file system on the target when performing a Stage 2
sync (either with or without the --autoprovision option). The format for <right-size-spec> is one or
more comma-separated fields in the following format:
<fs_specifier>=<size>
Where <fs_specifier> identifies a file system. It can be a file system label
or UUID, a mount point, an LVM <vg_name>/<lv_name>, or a device node (/dev/vda2). <target_size>
specifies the new size.
Example:
. OR
dba9743b6c98}\'=1GB
Supported size suffixes:
On a Linux host, use the ‘pvs’ command to show how many free extents are
[--ssh-only]
When performing an initial Stage 2 Sync to a preprovisioned Windows target.
Indicates that the RMM will access the target server over ssh rather than with a user/password.
It is also valid on a Stage 1 Sync when a Windows image still exists on the RMM,
but the associated source host has been deleted from the RMM. In that case, it indicates that the
source host is accessed via ssh-only
Page 55 of 66
Specifies the port number used for ssh by the RMM when communicating to a
source server (in a Stage 1 Sync) or a target server (in a Stage 2 Sync). By default, port 22 is used.
[--target-dns <ipaddr list> | “SOURCE” | “TARGET”]
By default, when performing an initial Stage 2 Sync, the target DNS settings will
be left as they were initially on the target. To change that, use --target-dns as follows:
Use “SOURCE” to copy the dns server addresses from the source server
If you wish to specify one or more custom dns server ip addresses, enter them
as a comma separated list.
Use “TARGET” to retain the existing dns server addresses on the target server.
This is the default setting.
This specifies the name by which the RMM will refer to the target server. It is
only valid for autoprovisioned Stage 2 Syncs or the initial Stage 2 sync of a preprovisioned target; If it is
not specified in those cases, then the RMM will choose a target-friendly name of the form “RW-Host-
nn” where nn is a number.
When --autoprovision is specified, --target-friendlyname will be used as the
name of the instance in the cloud.
[--target-ignore-disk <diskid>]
When specified on the initial Stage 2 Sync of a preprovisioned target, the diskid
specified should be ignored when the RMM is determining on which target disks the source file systems
should be placed.
[--target-password <windows-password>]
This is valid on the 1st stage 2 sync of a Windows preprovisioned target, when
that preprovisioned host is accessible by a username/password. In that case it represents the password
of the username on the preprovisioned target.
It is also valid when used with --autoprovision, depending the on the clouduser
type specified. For example, it can be used with cloudusers of type OCI. See the definition of --target-
password in the ‘OCI Flags’ section
This is valid on the 1st Stage 2 Sync of a preprovisioned target. It represents the
username that can be used to access the preprovisioned target, in conjunction with either --target-
password or the --ssh-only option.
It is also valid when used with --autoprovision, depending on the clouduser type
specified. For example, it can be used with cloudusers of type OCI. See the definition of --target-user
in the ‘OCI flags’ section.
[--tng]
When --tng is specified on a Stage 1 sync, the RMM installs a delta tracker on
Page 56 of 66
the source (as part of capture or sync) which tracks writes on the file system at runtime. When the sync
runs, only these tracked changes (delta) are synced. This delta is the changes occurred since the last
successful sync or capture. This type of sync overcomes the inefficiency of rsync and significantly
improves the RPO as no time is spent calculating the delta during the sync.
If --tng was not specified during the ‘host capture’ command, then the first
Stage 1 Sync with --tng will install the tng delta tracker.
This option is valid only on a Stage 1 Sync.
[--user <username>]
This is used when doing an initial Stage 2 Sync to a preprovisioned target host.
For example, if a linux host has been preprovisioned in a cloud, and the RMM uses ‘opc’ to ssh to this
host, then the initial Stage 2 sync would need to include ‘--user opc’. For an initial Stage 2 Sync with a
preprovisioned host “--target-user” and “--user” are synonyms.
This should not be used on subsequent Stage 2 Syncs, because the RMM will
choose the proper username automatically; specifying an improper username will cause the sync to fail
with a SYNC_ERROR_DETERMINE_BOOTED_OS error.
[-v|--verbose]
asked to do so by Rackware Support
[--xfer-compress]
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 /opt/rackware/data/options file. If the default setting for Stage 2 syncs is in
place and you wish to have network compression done on a particular Stage 2 sync use the --xfer-
compress option on that sync. If the non-default setting for Stage 1 syncs is in place, and you wish to do
compression on a particular Stage 1 sync, then use the --xfer-compression option.
To view the current settings, use the command “rw rmm show -v | grep
compression”. A value of 1 means compression is enabled, and a value of 0 means it is disabled.
8.4.2.2 AWS Flags

The following options are valid when using --autoprovision with a clouduser that was added with a
cloudprovider of “aws”.
[--aws-communication-ip-type < Ip type (public/private) to be used to perform RMM

operations> ]
This optional parameter describes the type of IP that the RMM will use when it
communicates with the newly spawned instance. Possible values are “public” or “private”. If “private”
is used, then the vpc-id and the subnet-id of the spawned instance should be the same as the RMM. If
not specified, a value of “private” is assumed.
[--aws-disk <aws-disk-spec>]
This optional parameter defines the disks that should be associated with the
Page 57 of 66
instance being provisioned. If not specified, the RMM will choose the number of disks and the
specifications of the disks based on what is on the source server.
The <aws-disk-spec> is of the form:
‘NUM=<number>,SIZE=<size in GiB of the disk>, IOPS=<Max IOs per
second the disk is allowed to perform>, TYPE=<disk types as defined in
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html>’
Each of the 4 parts must be specified
If multiple disks need to be specified, then multiple --aws-disk statements must
be specified
Examples:
To specify 1 1000GiB disk of type st1 limited to 1600 IOPS:
--aws-disk ‘NUM=1,TYPE=st1,IOPS=1600,SIZE=1000’
To specify 2 2000GiB disks of type gp2 limited to 20000 IOPS
--aws-disk ‘NUM= 1,TYPE=gp2,IOPS=20000,SIZE=2000’ --aws-disk
‘NUM=2,TYPE=gp2,IOPS=20000,SIZE=2000’
Note - If using aws-disk with a Linux server, the first disk must be at least 30 GB ;
if using aws-disk with a Windows server, the first disk must be at least 50 GB. Disks after the first one
may be any size.

When specified, indicates that the instance being launched will have an elastic
ip. The elastic ip may be specified via an existing elastic allocation-id or an existing elastic public ip
address, or, if ‘new’ is specified, a new elastic ip will be created for this instance.
If not specified, the newly provisioned instance will not have an elastic ip.
[--aws-instance-type <Specify the instance type to be used with AWS> ]

This optional parameter defines the cpu/memory/storage/networking capacity
of the instance being launched. If not specified, the RMM will choose an instance based on the
characteristics of the source server
[--aws-region <AWS Region > ]

This needs to be specified if you wish the VM to be created in a region other
than the region of the vpc-id. If not specified, the region of the vpc-id will be used.
[--aws-subnet-id <AWS Subnet ID]

This is a mandatory parameter when using ‘--clouduser AWS’which comes from
your account. The VPC ID may be associated with multiple subnets; this parameter defines which of
those subnets should be used when launching the instance. A sample <AWS Subnet ID> is “subnet-
a234567”.
[--aws-subnet-ip <ip address>]

When specified, defines the private IP address that should be used for the newly
provisioned instance. It must be in the allowable range of ip addresses according for the subnet-id in
which the instance is being provisioned.
If not specified, AWS will select the private ip address to be used by the newly
provisioned instance.
Page 58 of 66
[--aws-vpc-id <AWS VPC Id > ]
This is a mandatory parameter when using ‘--clouduser AWS’. The VPC ID will
come from your account. Each VPC ID is in a particular region. . A sample <AWS VPC id> is “vpc-
a2345678”
[--nsgs <nsg>[,…]]
This optional parameter includes one or more network security groups. The
network security group can be identified by an nsg name or an nsg id. While network security groups for
other clouds include an optional location, in AWS a location is never used and will be ignored if
specified.
Example:
--nsgs sg-b3876125,Launch-Wizard-4
8.4.2.3 Azure Flags

The following options are valid when using --autoprovision with a clouduser name that was added with a
cloudprovider of “azurerm”.
If specified, the VM will be created with a public IP address.
Specifies the subnet name of the autoprovisioned VM in the vnet of the
autoprovisioned VM. This should be specified only when the subnet name already exists in the vnet-
name. If not specified, a subnet named <vmName-subnet> will be created in the vnet of the
autoprovisioned VM.
[--azure-vnet-name]
Specifies the virtual network name where the autoprovisioned VM will be
placed. This should be specified only if the vnet-name already exists in the resource group and the
datacenter of the Azure account. If not specified, the RMM will create a vnet named “<vmName>-vnet”
and place the autoprovisioned VM in that vnet.
The size (e.g “Basic_A1”, or “Standard_A2”, or “Standard_D2”) of the VM to be
provisioned. If not specified, the RMM will choose a size that most closely matches the source server.
[--datacenter]
The datacenter within the resource group in which the new VM should be
placed. If not specified, the datacenter that is specified in the clouduser will be used.
Provide one or more network security groups to be used. The security group
should be given as a key/value pair, where the key is the group name and the value is the location of the
Page 59 of 66
security group. The location is a resource group name and is optional. If not provided, the group will be
put in the resource group the VM will provision in. This will add the network security group to the
subnet the VM is in, as recommended by Azure. If the user needs to apply the network security group to
the VM NIC, use the --nic-nsgs option instead. Azure only supports one network security group per
subnet.
Example:
--nsgs test-nsg=test-resource-group
--resource-group <name>
This is a required parameter. It indicates the name of the resource group into
which the new VM should be placed
The name of the resource group that contains the azure-vnet-name specified in
this command. If not specified, the name used in --resource-group will be used.
[--target-ignore-disk] <disk spec>

Please refer to the description of this parameter in the subsection “Command
Syntax” of the Image Sync section. When autoprovisioning Linux servers into Azure, always specify “--
target-ignore-disk /dev/sdb” ; when autoprovisioning Windows servers into Azure, always specify “--
target-ignore-disk disk1”

cloudprovider of “oscloudstack”.
name of hypervisor on which user wants to launch target vm
Specifies a service offering name (CPU / RAM ) for target VM
Specifies an ssh keypair used to launch the target vm.
[--zone-name <zonename>]
Use with Open Source cloudstack autoprovision; specifies the zone within
which the user want to launch the target virtual machine
8.4.2.5 GCP Flags

cloudprovider of “gcp”.
[--allocate-public-ip] create VM with public IP address
Selects a GCP network
Page 60 of 66
Selects a GCP subnet
[--machine-type < GCP machine type>]

Selects a type (cpu, memory) of machine to autoprovision
[--zone <zone>]
The Zone for GCP autoprovision
8.4.2.6 OCI Flags

The flags in this section are valid when using --autoprovision with a clouduser name that was added with
a cloudprovider of “oci”.
When ‘--autoprovision is used with a clouduser name that was added with cloudprovider of oci, --av-
domain and either --subnet or --subnet-id are required flags. If --subnet is used, then --vcn or --vcn-id
must be specified.
[--av-domain <name>] (availability domain)

An OCI Availability Domain is a physical datacenter. An Availability Domain
contains one or more Fault Domains. Availability domains are physically isolated from each other so a
problem in one Availability Domain is unlikely to affect another.
--av-domain is required when ’--autoprovision --clouduser <name with oci
provider>’ is specified on the ‘host sync’ command..
For more information
see: https://docs.cloud.oracle.com/iaas/Content/General/Concepts/regions.htm#AboutRegionsandAvail
abilityDomains
[--bare-metal]
If specified, means that the launched instance should reside on a bare metal
machine
When creating an instance in OCI (via ‘rw host sync’ or ‘rw image sync’), you can
assign tags to the instance –associating metadata with the instance in the form of key value pair. OCI
supports defined tags and free form tags. RMM provides the ability to associate both defined and free
form tags for an autoprovisioned host using the --cloud-tag parameter. For OCI, the RMM supports two
type of tags:
a) Defined tags as: NameSpace.TagKey=TagValue
b) Freeform tags as: TagKey=TagValue
For example, --cloud-tag Rackware.OperatingSystem=Linux,Tag1=Value1,Tag2=Value2
For either type of tag, the tag key and tag value to use must match what is in
your OCI account.
The name of the compartment to use for finding images (if image is specified by
--image-name) and provisioning resources. If an image is specified by name, it must exist in this
Page 61 of 66
compartment. Instances and Block Volumes will be created in this compartment. If the compartment
name is unambiguous in the compartment hierarchy, it can be specified simply by name. Otherwise, the
fully qualified compartment name must be provided (i.e.
/parent_compartment/child_compartment/compartment).
If not provided, Compartment will default to the root compartment.
Either compartment” or compartment id, but not both, may be specified
The OCID of the compartment to use for finding images (if image is specified by
name) and provisioning resources. If an image is specified by name, it must exist in this compartment.
Instances and Block Volumes will be created in this compartment.
If not provided, the compartment id will default to the ocid of the root
compartment
Specifies a fault domain name to use when launching an instance. If not
provided, no Fault Domain will be provided when launching the instance, and OCI will automatically
choose a Fault Domain for the instance.
This is the name of an oci image - most likely a custom image. If specified, it
must reside in the “oci compartment”/”oci compartment id” specified above. If not provided, an image
will be chosen automatically that best matches the source machine based on the images available in OCI
[--image-id <ocid>]
This is the same as --image-name, but specified as an OCID rather than a name)

The name of a network-profile. A Network Profile defines a set of OCI flags. If a
network profile is specified, the value of its compartment, vcn, and subnet would not need to be
specified on the ‘image sync’ command. Network Profiles are currently not implemented.
This flag is used to determine a compatible shape, image and disk configuration
for a target host without actually provisioning a VM.
[--no-public-ip]
If not specified, then a public IP will be assigned to the instance in OCI. --no-
public-ip should be specified only when it is known that the RMM can reach the launched instance over
it's private ip assigned by Oracle
Provide one or more network security groups to be used. The security groups
should be given as a comma separated list of key/value pairs where the key is the nsg name (or the nsg
OCID) and the value is the location of the security group. Because this list is comma separated, network
security groups with commas in the name cannot be added during autoprovision and must be added
manually later. The location is a compartment name, path or ID and is required when the security group
Page 62 of 66
is identified by name and is in a different compartment from the VCN. Otherwise, the location is not
necessary.
Example:
nsgs nsg1,ocid1.networksecuritygroup...nsg2,nsg3=comp1,nsg4=ocid1.compartment...comp2
The first value is an nsg name with no location (because the nsg is in the same
compartment as the VCN), the second is an nsg OCID with no location, the third is an nsg name with a
compartment name for the location and the fourth is an nsg name with a compartment OCID for the
location.
[--private-ip] <ip address>

The private ip address which will be assigned to launched VM. If not specified,
then OCI will choose a private IP address in the appropriate subnet
The type of attachment to use for provisioned disks. If --provision-disk-type is
not used, the paravirtualized attachment type will be used for any block volumes being provisioned.

This field has meaning only if “no-public-ip” is not set.
If “no-public-ip” is not set, then the <ip address> parameter represents the
public ip address which will be assigned to launched VM. It must be an IP in OCI’s pool of reserved
public IP addresses.
If “no-public-ip” is not set, and the value EPHEMERAL is used, then OCI will
choose an appropriate public IP address for this instance
[--region <name>]
Specifies the region into which the autoprovisioned VM will be placed. If not
specified, the region used in the relevant ‘rw clouduser add’ command will be used.
[--shape <shape>]
Specify the shape of the launched instance. If not specified, the RMM will
choose an appropriate shape based on the memory and CPUs of the source server
[--subnet <name>] (Selects a subnet)

The name of the Subnet to use. This Subnet must exist in the VCN Compartment
. Either --subnet or --subnet id (but not both) must be specified
[--subnet-id <ocid>] (Same as subnet but using ID instead of name)

The OCID of the Subnet to use. Either --subnet or --subnet id (but not both)
must be specified.
This is the password of the username of the custom image. For Linux custom
images, it should never be specified. For Windows images, it should be specified only if the Windows
custom image is accessed via a username/password, rather than with ssh-only.
Page 63 of 66
Note that --target-password has a different meaning when not used with OCI
This is the username for the custom image. “Target User” is the name of the
Operating System user which the RMM can use to connect to “Image Name”. It should be specified only
when a custom image is being used that does not use cloud-init. All custom images that are based on
OCI provided images include cloud-init. If an Ubuntu "Image Name" is specified, and a 'Target User' is
not, then the username 'ubuntu' is assumed. If a non-Ubuntu Linux “Image Name” is specified, and a
‘Target User’ is not, then the username ‘opc’ is assumed.
If a Windows “Image Name” is specified which includes cloud-init, and a ‘Target
User’ is not, then the username and password will be generated by OCI after launching the instance and
those credentials will be used by the RMM when first connecting to the instance. If a Windows “Image
Name” is specified which does not include cloud-init, the 'Target User" must be provided.
Note that --target-user has a different meaning when not used with OCI
[--use-private-ip]
Specifying --use-private-ip will tell RMM to use the private ip of the target to
communicate with the target. Use this flag only if it is known that the target will be reachable from
RMM over its private IP
[--vcn <name>]
The name of the VCN to use. This VCN must exist in the VCN Compartment. If
the subnet is specified by name, then either vcn or vcn-id must be specified
[--vcn-id <ocid>] (Same as vcn but using ID instead of name)

The OCID of the VCN to use. This is the same as --vcn, except the vcn is
specified by ID instead of my name. The vcn-id must exist in the vcn compartment id. If the subnet is
specified by name, then either vcn or vcn id must be specified
The name of the compartment that contains the VCN referenced in this
command when the VCN is specified by name. If the compartment name is unambiguous in the
compartment hierarchy, it can be specified simply by name. Otherwise, the fully qualified compartment
name must be provided (i.e. /parent_compartment/child_compartment/compartment).
If not provided, VCN Compartment will default to the same compartment as in
the Compartment field.
[--vcn-compartment-id <ocid>] (Same as vcn-compartment but using an OCID

instead of name)

cloudprovider of “softlayer”
Page 64 of 66
[datacenter <Location of Datacenter>]
The datacenter where this VM should reside. This parameter is required when
autoprovisioning into Softlayer.
[--domain <Domain Name>]

The domain name of this VM, e.g. “rackwareinc.com”. If not specified, the value
used on the ‘clouduser add’ will be used.
[--hourly ]
Use hourly billing on this VM; if not specified, the billing type from the
‘clouduser add’ (which defaults to --monthly) will be used.

The following options are valid when --autoprovision is specified with --vcenter
[--cluster <name>]
Selects the cluster in vCenter to provision the machine on
Selects a datacenter when using --autoprovision
The name of the esx host.
[--nic
<DEVICENAME=<name>,TYPE=<type>,NETWORKNAME=<name>,IP=x.x.x.x,CIDR=24,
Specifies NIC configuration when using --vcenter:
Type may be "e1000" or "vmxnet"
NETWORKNAME is the name of the network in vmware
The --nic option may be repeated to specify multiple NICs.
resource pool when using --vcenter
Specifies network routes when using --vcenter
For example, to specify a route in 192.168.1.0/24 via 192.168.15.10, use
--route PREFIX=192.168.1.0,CIDR=24,NEXTHOP=192.168.15.10
The --route option may be repeated to specify multiple routes.
[--vcenter <name>]
Selects a vcenter to autoprovision into
[--vmfolder <path>]
vmware folder path
Page 65 of 66
8.4.3 Examples
8.4.3.1 Stage 1 Sync Examples
rw i sy lin-host-src --image lin-host-image --flex --filter /root/filter-file
rw image sync 172.26.12.12 --image lin-host-image --flex
rw image sync win-host-src --image win-host-image --flex --exclude E:
8.4.3.2 Stage 2 Examples

(1st time Stage 2 Sync of preprovisioned target)
rw image sync lin-host-image --target 172.29.54.34 --target-friendlyname linux-tgt --flex
%The preprovisioned target at 172.29.54.34 can be ssh’ed to from the RMM only by
using ‘ssh root@172.29.54.34’; once the 1st Stage 2 sync is complete, the RMM will refer to this host by
the name linux-tgt
rw image sync win-host-image --target 172.31.31.32 --target-friendlyname windows-tgt --flex --
ssh-only
%The preprovisioned target at 172.31.31.32 can be ssh’ed to using the SYSTEM
username.
rw i sy lin-IMAGE --target 193.125.172.157 --flex --user opc

%The preprovisioned target at 192.125.172.157 can be ssh’ed to from the RMM only by
using ‘ssh opc@192.125.172.157’; so the sync must include ‘--user opc’ or ‘--target-user opc’. Since --
target-friendlyname is not specified, the RMM will choose the target name, which will be of the form
RW-Host-nn
(Subsequent Stage 2 Sync using hostname with --target)

rw image sync lin-host-image --target linux-tgt --flex
rw i sy win-host-image --target windows-tgt --flex
(Subsequent Stage 2 Sync using ipaddr with --target)

rw image sync lin-host-image --target 172.29.54.34 --flex
rw image sync win-host-image --target 172.31.31.32 --flex
(Sync2 autoprovision into OCI)

rw image sync centos7-src-IMAGE --autoprovision --clouduser clouduser1 --vcn vcn-20190213-
2300 --subnet "EXT Subnet1" --av-domain hxxx:US-ASHBURN-AD-1 --flex --region us-ashburn-1 --target-
friendlyname centos7-tgt1
Page 66 of 66

RMM Product Operations CLI Guide 2.0.5

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 Product Operations CLI Guide 2.0.5

Uploaded by

Copyright:

Available Formats

APRIL 2022

RACKWARE MANAGEMENT MODULE

PRODUCT OPERATIONS (CLI) GUIDE

2 Command Line Overview

context action target[, <target>, . .] \

To illustrate the command structure consult the host show command:

Some flags stand alone and take no parameters.

2.2 CLI Grammar Constructs

<argument list> :<a comma separated list of arguments>

<az tenant id> :36 characters from <ID character set>

<file system> : up to 128 characters from <fs char set>

<ocid> : 1 to 128 characters from <ocid id char set>

<right-size-spec> : The format for <right-size-spec> is one or more

3 Migrating Servers to a Cloud using the CLI

3.1 Migrating Servers Individually

3.1.1 Two Stage Sync

3.1.1.1 Capturing an Image

3.1.1.2 Refreshing the Image - Stage 1 Sync

rw image sync my-Win-Src --image my-Win-Image --flex

3.1.1.3 Migrating to Cloud Environment - Stage 2 Sync

3.1.1.3.1 Stage 2 Sync to Preprovisioned Hosts

3.1.1.3.2 Stage 2 Sync with Autoprovisioning

3.1.2 Host Sync

rw host sync my-Win-Src --target my-Win-target

3.1.2.1 Host Sync with Preprovisioned Target

3.1.2.2 Host Sync with Autoprovisioned Target

3.1.3 Adding a Cloud User or Vcenter

rw clouduser add <name> -p <cloud provider type> <cloud specific flags>

Similarly a vcenter must be added if any VMs are to be autoprovisioned in a vcenter.

3.2 Migrating Groups of Servers in Waves

4 Protecting Servers with DR Policies

5 RMM Administration Tools

5.1 zfs Commands

USAGE: rwadm zfs <option>

configure - configure and enable zfs functionality on RMM (see below)

5.1.1 zfs configure

[root@rmm-7-4-0-378 opc]# rwadm zfs configure

RMM Storage Pool is already configured

To add an extra disk, enter “A”

[A]dd disk or [F]inished [A]: A

Enter device name/path to be configured as RMM Storage pool. [ONE AT A

[A]dd disk or [F]inished [A]:

[A]dd disk or [F]inished [A]: F

6 Diagnostic and Management Tools

rw imageconfig syncrelationship show

6.1 Relationship Commands

[root@rmm01 ~]# rw ic srs win2k19-img

[root@rmm01 ~]# rw ic srs centos78-src

[root@rmm01 ~]# rw ic sra centos78-Image --target centos78-src

[root@rmm01 ~]# rw ic srd centos78-Image --target centos78-src

6.2 Viewing zfs Pool Status

pool show | po sh [<array>[:<pool>]]

[root@rmm-7-4-0-378 opc]# rw pool show

6.3.1 rw rmm show

6.3.2 rw license generate-report

7 Adding Users and Groups

8 Commands for Migrating Individual Servers

aws Amazon EC2 (Amazon Elastic Cloud Compute)

The flags for each cloud provider type are as follows:

8.1.2 Vcenter Add

vcenter add <friendlyname>

8.2 Host Capture

[--exclude <file system list>]

rw host capture 192.168.11.200 --image win-host-image --os windows -n windows_source_host