Installing the DRM Appliance

DRM ships as a virtual appliance — a single OVA image containing one Go binary (the embedded web UI plus a SQLite database) on a minimal Ubuntu base. There is nothing to compile and no reverse proxy to configure: the appliance terminates HTTPS itself and runs as an ordinary VM on your hypervisor, exactly the way VMware SRM ships.

You deploy one appliance per site — one at the primary site and one at the recovery site — each connected to that site's Cockpit. There is no DRM-to-DRM process link; the two appliances only exchange recovery-plan definitions.

Where this fits

This page gets the appliance running. Once its console answers on https://<address>:7772/, continue with Getting Started to license it, connect it to Cockpit, and pair the two sites.

Before you begin

Resource	Appliance default	Notes
vCPU	2	Control plane only — DRM is never on the replication data path.
RAM	2 GB
Disk	10 GB (thin)	Holds the OS, the SQLite database, and the self-signed TLS material.
Network	1 NIC	Reaches the site's Cockpit and, across sites, the peer DRM on port 7772.

Deploy on shared / HA storage

DRM has no application clustering by design — instance availability is delegated to Cockpit's VM-HA, which restarts a failed host's VMs elsewhere but skips VMs that sit on local disks. Place the appliance on a shared / HA datastore and enable VM-HA for it. On local storage, a host failure takes the appliance down with no automatic restart.

1. Download the OVA from the enterprise portal

Sign in to the enterprise portal, open the DRM product, and download the latest appliance release (platform generic — the OVA runs on any hypervisor). You get a file named drm-appliance-<version>.ova.

The release page also publishes the OVA's SHA-256 checksum. Verify your download before importing it:

sha256sum drm-appliance-<version>.ova
# compare the output against the checksum shown on the portal release page

2. Import the OVA into your hypervisor

An OVA is a tar archive of an OVF descriptor and a streamOptimized VMDK disk. Import it through Cockpit or directly through Vapor.

Using Cockpit

1. Upload the appliance disk into a datastore using the datastore browser. If your workflow needs a native format, unpack the OVA first (tar -xf drm-appliance-<version>.ova) and convert the VMDK to qcow2:

   qemu-img convert -O qcow2 drm-appliance-<version>-disk1.vmdk drm-appliance.qcow2

2. Open the VM Provisioning Wizard and create a new VM with the sizing from Before you begin. At the Storage step choose Attach Existing and select the disk you uploaded; at the Network step attach one NIC on the management network the appliance should answer on. Place the VM on a shared / HA datastore.

See the Cockpit guide on virtual machines and storage & datastores for the datastore and wizard details.

Using Vapor directly

Upload the disk into a Vapor storage pool with the storage-pool browser, then create a VM from the existing disk with the sizing above and a single NIC. See Storage Pools and Virtual Machines.

VMware target

On a VMware site the OVA imports directly — deploy it with Deploy OVF Template and keep the appliance's defined hardware.

3. Power on and find the address

Start the VM. On first boot the appliance:

• brings its NIC up over DHCP;
• runs a one-time setup that generates this instance's secrets (so every appliance is unique — nothing is baked into the image), issues its own self-signed TLS certificate, and starts the DRM service;
• firewalls down to SSH (22) and the DRM console (7772) only.

Find the address it picked up from your DHCP server's leases, or read it from the VM console (next step).

4. Open the console and set the login

Open the VM's console. Log in with the built-in console account:

Account	Username	Password
Console (SSH / VM console)	drm	drm

You are required to change this password at first login. This console account is only for host-level access (reading the address, host maintenance); it is separate from the DRM web administrator you create next.

Confirm the address and that the service is up:

ip -4 addr            # the appliance's address
systemctl is-active drm drm-update.path   # both should report: active

5. Open the DRM console and complete first-run setup

Browse to:

https://<address>:7772/

The certificate is self-signed (the appliance is reached by IP, where no public CA will issue a certificate), so your browser warns on the first visit — accept it once. This is deliberate: it keeps the admin password and every later request off plaintext HTTP.

On a fresh appliance DRM shows a first-run setup wizard that creates the first web administrator account and logs you in.

Do not expose the appliance to the public internet

Keep the appliance on your management network. It orchestrates failover across both sites and holds encrypted Cockpit credentials; it is not hardened to sit on a public address.

6. Repeat at the second site

Deploy a second appliance the same way at the recovery site. Each appliance is independent and self-contained — do not clone a configured appliance to make the second one, because the generated secrets must differ. Install a fresh OVA.

Keeping the appliance updated

DRM updates itself in place without a reinstall — the database, paired sites, recovery plans, and secrets all carry over.

• From the dashboard: Settings → Updates shows the installed version and any newer release, with an Install Update button.
• From SSH: sudo drm update (or sudo drm update --check to only look).

Updates come from the enterprise portal's release feed over HTTPS. The updater re-verifies the download's checksum, runs the new binary once before trusting it, refuses to downgrade, and refuses to restart while a recovery-plan run is in progress. An air-gapped site can disable update checks or point them at an internal signed feed.

Next steps

With the console answering at https://<address>:7772/ on both appliances, continue with:

1. Getting Started — prerequisites, licensing, and connecting each DRM to its local Cockpit.
2. Pairing Two Sites — connect the primary and recovery Cockpits, and pair the DRM instances.
3. Protecting Workloads — enroll your first VM for replication.