IP Customization

When a workload fails over to the recovery site, the recovery network is often a different subnet from the primary. IP Customization re-addresses the recovered VM's guest NICs automatically as it boots at the recovery site, so it comes up with the right address, gateway, and DNS.

DRM offers two ways to express the mapping, and you can use them together:

Method	Where you configure it	Best for
Subnet mapping rules (Method 1)	Settings → IP Mapping	Many VMs that move between two known subnets — one rule covers them all, host numbers preserved
Per-VM custom address (Method 2)	The Protect / Enroll dialog	A single VM that needs an exact address at the recovery site

Both are applied in the guest through the qemu-guest-agent at failover, and both configure static IPv4 addressing.

Prerequisites — read this first

• The guest must have qemu-guest-agent installed and running. Without it, DRM cannot re-address the guest and the VM boots with its original addressing.
• The guest NIC must use static addressing. If a DHCP client is active in the guest, it will re-assert the old lease shortly after re-addressing and the new address will not stick. Set the NIC to static in the guest before protecting it.
• IP Customization is IPv4 only and sets static configuration (no DHCP).

When it is applied

• It runs during a planned failover and an emergency (unplanned) failover, right after the recovery VM boots.
• It does not run during a test failover — a test keeps the workload's original addressing inside the isolated test network. Verify re-addressing during a real planned failover, or inspect the mapping in the recovery VM's console after one.
• After boot, DRM waits for the guest agent (up to 5 minutes by default) before applying the configuration, so a slow-booting guest is still re-addressed.

Method 1 — Subnet mapping rules

A subnet mapping rule shifts an entire source subnet to a recovery subnet for a given recovery site, preserving the host number. A VM whose NIC sits in the source subnet is re-addressed into the recovery subnet automatically:

192.168.1.50  (source 192.168.1.0/24)   →   10.1.2.50  (recovery 10.1.2.0/24)

One rule covers every protected VM that moves between those two subnets — you do not configure anything per VM.

Create a rule

1. Open Settings → IP Mapping.

2. Under Subnet Mapping Rules, choose:

   Field	Meaning
   Recovery Site	The site this rule applies to when a VM fails over there
   Source Subnet (CIDR)	The primary-site subnet to match, e.g. 192.168.1.0/24
   Recovery Subnet (CIDR)	The recovery-site subnet to move into, e.g. 10.1.2.0/24
   Gateway (optional)	Default gateway to set at the recovery site
   Nameservers (optional)	Comma-separated DNS servers, e.g. 8.8.8.8, 1.1.1.1

3. Select Add Rule. The rule appears in the table below and takes effect on the next failover.

To remove a rule, select Delete on its row.

How the match works

At failover DRM reads each recovered NIC's current IPv4 address (via the guest agent) and applies the first rule whose Source Subnet contains it. A NIC whose address is not inside any rule's source subnet is left unchanged. The source and recovery subnets may be different sizes; the host offset is preserved from the start of each network.

Method 2 — Per-VM custom address

Use this when one workload needs a specific address at the recovery site. You can set it when you first protect the VM, or add and change it any time afterward.

Set it when protecting the VM

1. In the DRM Workloads view, start Protect (or Enroll Workload) for the VM.

2. Fill in the usual target site, datastore, RPO, and recovery points (see Protecting Workloads).

3. Enable Customize Guest IP at Recovery Site.

4. For each guest NIC, in order, provide:

   Field	Meaning
   Target Address (CIDR)	The exact address to assign at the recovery site, e.g. 10.20.0.5/24
   Gateway	Default gateway at the recovery site
   Nameservers	Comma-separated DNS servers
   Source Network (optional)	A label for your own reference

5. Use Add NIC for multi-NIC VMs — the entries are applied to the guest's non-loopback interfaces in order. Select Configure Protection to finish.

Add or change it on an already-protected VM

You do not need to unprotect a VM to set or adjust its address. In the Workloads view, each protected VM has an Edit IP Customization action (the network icon in its action row). It opens a dialog prefilled with the VM's current per-VM addresses, where you can:

• Add an address to a VM that was protected without one,
• Change an existing address, gateway, or nameservers, or
• Clear the per-VM addresses (remove every NIC row and save) so the VM falls back to any matching subnet rule (Method 1), or to its original addressing.

This is a configuration-only change: it does not interrupt replication or trigger a new baseline, and it takes effect at the next failover. (The new address rides along to the recovery site with the next scheduled sync, so an emergency failover uses it too.)

Using both together — precedence

When a VM has both a per-VM entry and a matching subnet rule:

• A per-VM address (Method 2) wins for that NIC — it is applied in order to the guest's interfaces.
• Subnet rules (Method 1) fill the rest — any NIC without an explicit per-VM entry is matched against the rules by its live address.

This lets you set a blanket subnet rule for a site and override just the few VMs that need a fixed address.

Verify it worked

After a planned failover:

1. Open the recovered VM's console at the recovery site and check the NIC's address, default route, and /etc/resolv.conf.

2. On the recovery host, the Vapor log records each change, for example:

   [Readdress] my-vm-dr (eth0): re-addressed to 10.1.2.50/24

Troubleshooting

Symptom	Cause / Fix
Address did not change at all	The guest agent isn't running (install/start qemu-guest-agent), or it didn't come up within the wait window on a very slow boot.
New address appears, then the old one comes back	A DHCP client is still running in the guest and re-leased the old address. Set the NIC to static in the guest.
A subnet rule didn't fire	The NIC's live address was not inside the rule's Source Subnet, or a per-VM entry took precedence for that NIC.
Nothing changed during a test failover	Expected — re-addressing runs only on a real failover, not a test.
Only some NICs changed	Per-VM entries are positional; make sure there is an entry (or a matching rule) for each NIC that needs it.

Related

• Protecting Workloads — enroll a VM and set a per-VM address
• Failover & Recovery — where re-addressing is applied
• Site Pairing — recovery sites that rules target