[EN] Changing IP Addresses in HPE SimpliVity (OmniStack) Environments

What This Guide Covers

Data center relocations, network redesigns, subnet consolidations, and IP plan revisions all eventually require changing the IP addresses of SimpliVity nodes.

This is not the same as changing an IP on a standalone server. In SimpliVity, every node participates in a distributed file system (svtfs) and a configuration database (cfgdb) in which peers identify each other by IP address.

An IP change performed in the wrong order can drop a node out of the federation, render datastores inaccessible, and interrupt running VMs.

This article walks through the four distinct addresses that may need to change on a SimpliVity node:

#	Address being changed	Where it lives	Disruption level
1	ESXi host management IP (vmk0)	ESXi hypervisor	– Medium – host must be re-added to vCenter inventory
2	OVC Management IP	OmniStack Virtual Controller	– Low – svtfs failover covers it
3	OVC Federation IP	OmniStack Virtual Controller	– Low – svtfs failover covers it
4	OVC Storage IP	OmniStack Virtual Controller	– High NFS mounts are affected

2. Before You Start: Understanding the Architecture

Each SimpliVity node is really two separate entities, and both carry their own IP addresses:

The ESXi host (the physical server):

• vmk0 → Management network (the address vCenter uses to talk to the host)
• vmk1 → Storage network (where NFS traffic flows)

The OVC / OmniStack Virtual Controller (a VM running on that host):

• eth0 → Management — vCenter integration, CLI/GUI access
• eth1 → Federation — inter-node replication and synchronization
• eth2 → Storage — presents NFS datastores to ESXi hosts

The critical point is this: when an ESXi host’s IP changes, every OVC that presents datastores to that host must learn the new address. Likewise, when an OVC’s IP changes, the peer records on the other OVCs in the federation must be updated.

The dsv-host-interface-add and dsv-peer-reset commands in these procedures exist precisely to perform that reconciliation.

General Prerequisites and Warnings

1) Rules That Apply to Every Scenario

• Provision the new IP addresses in advance. Depending on the scenario, an ESXi host IP change may also require a new OVC management IP — plan for two addresses rather than one.
• Verify that every system in the federation is reachable and operating normally. Never begin an IP change while a node is already degraded.
• Do not change IP addresses on multiple federation members simultaneously. Work through nodes one at a time, letting each one fully stabilize before moving on.
• Confirm that all VMs are Storage HA Compliant. This guarantees that I/O fails over cleanly to the remaining nodes when svtfs is stopped.
• Migrate business-critical VMs to another host beforehand. IP Failover is designed to keep VMs running through the change, but critical workloads are not worth the risk.
• The dsv-* and svtctl commands are not customer-accessible. These procedures must be carried out with an authorized HPE SimpliVity support provider.

2) VMware vCenter 5.1 and Later Disable Network Rollback

VMware’s Network Rollback feature automatically reverts a configuration change when it detects a loss of management connectivity.

Changing an ESXi host’s IP address looks exactly like such a loss, so Rollback will undo your change. Disable the feature temporarily before you begin and re-enable it once the work is complete.

Refer to the “Disable Network Rollback” topic in the VMware vSphere Documentation Center for the exact steps.

Link : https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-networking/network-rollback-and-recovery/rollback/disable-network-rollback.html

3) If Non-SimpliVity (Legacy) ESXi Hosts Are Present

If non-SimpliVity ESXi hosts share SimpliVity datastores, additional steps are required;

1. Unshare the datastores.
2. After the IP change, edit /etc/hosts on the legacy host to add the new member IP address.
3. Reboot the legacy ESXi host.
4. Share the datastores with the legacy host again.

Scenario A – Changing the ESXi Host Management IP Address

Worked example: ESXi host management address 10.131.2.10 → 10.131.2.11; vCenter at 10.131.50.4.

Step 1 – Connect to the OVC and Elevate Privileges

SSH to the OVC running on the affected host, switch to the support account, elevate to root, and load the command environment:

svtcli@omnicube-ip5-130:~$ su svtsupport
svtsupport@omnicube-ip5-130:/home/svtcli$ sudo su
root@omnicube-ip5-130:/home/svtcli# source /var/tmp/build/bin/appsetup

The appsetup script places the dsv-* commands on your PATH. Skip this step and every subsequent command will fail with “command not found.“

Step 2 – Introduce the New Host Interface to the Datastores

This is the most important step in the procedure. The dsv-host-interface-add command makes existing datastores aware of a new ESXi host interface in effect, it adds the new address to the NFS export list.

It must be run before you change the IP otherwise the host will be unable to reach its datastores on the new address:

dsv-host-interface-add --host 10.131.2.10 --ipaddress 10.131.2.11

• --host → the host’s current (old) IP address
• --ipaddress → the new IP address to be added

Repeat the same command for the storage network address if that is changing as well.

Step 3 – Record the Current ESXi Interface Addresses

SSH to the ESXi host and capture the existing configuration:

[root@velikadirkozan:~] esxcli network ip interface ipv4 get

Name  IPv4 Address   IPv4 Netmask   IPv4 Broadcast   Address Type  DHCP DNS
----  ------------   ------------   --------------   ------------  --------
vmk0  10.131.2.10    255.255.0.0    10.131.255.255   STATIC        false
vmk1  10.205.1.152   255.255.0.0    10.205.255.255   STATIC        false

Here vmk0 is the management interface and vmk1 the storage interface. Make a note of the netmask — you will need to supply the same value in the next command.

Step 4 – Change the IP Address

[root@velikadirkozan:~] esxcli network ip interface ipv4 set -i vmk0 -I 10.131.2.11 -N 255.255.0.0 -t static

Parameters:

• -i → interface name (vmk0)
• -I → new IP address
• -N → subnet mask
• -t static → address type

Note: Your SSH session will drop the moment this command executes. That is expected reconnect using the new IP address.

Step 5 – Verify the Change

[root@velikadirkozan:~] esxcli network ip interface ipv4 get

Name  IPv4 Address   IPv4 Netmask   IPv4 Broadcast   Address Type  DHCP DNS
----  ------------   ------------   --------------   ------------  --------
vmk0  10.131.2.11    255.255.0.0    10.131.255.255   STATIC        false
vmk1  10.205.1.152   255.255.0.0    10.205.255.255   STATIC        false

Step 6 – Update the Identity Store (OmniStack 3.x and Later)

The identity store introduced in OmniStack 3.x persists vCenter credentials and node identities.

When the host IP changes, that record becomes stale and must be rebuilt. Run the following on the OVC:

root@omnicube-ip2-15:/home/svtcli# dsv-identitystore-init Administrator <new_host_ip> root <password>

The command prompts for confirmation:

This will restart hyperproxy and event manager service, delete any existing
identity store record and reinitiate new one, are you sure you want to proceed? y[n]: y

Answering y stops the svt-hyperproxy-server and svt-event-manager services, recreates the identity store, and restarts the services.

A successful run ends with output along these lines:

Successfully set auth certificate for node com.simplivity.<node-guid>
Successfully updated vCenter credential.
svt-hyperproxy-server (0) start/running, process 11201
svt-event-manager (0) start/running, process 11254

Step 7 – Re-register the Host in VMware vCenter Inventory

After the IP change the host appears disconnected in the vSphere Web Client.

Because vCenter still knows the host by its old address, a simple “Reconnect” will not work:

1. Right-click the disconnected host and choose Remove from Inventory.
2. Right-click the cluster and select Add Host.
3. Enter the new IP address in the wizard and add the host back to the cluster.

Step 8 – Update the VMware vCenter Registration

Refresh the OVC’s registration with vCenter:

dsv-update-vcenter --server 10.131.50.4 --username administrator --password <password>

The command issues a warning first:

ATTENTION
Virtual Controller will be rebooted at the end of this operation.
Is it ok to proceed to update system for new vCenter 10.150.50.37? Y/[N]: y

Verifying credentials ...
Successfully verified credentials with the vCenter
Updating authentication information for 10.150.50.37 ...
Successfully updated authentication information for 10.150.50.37
Updating vApp information ...
Successfully updated vApp information

Step 9 – Reboot the OVC

At the end of the command you are prompted to press ENTER, which triggers the OVC reboot;

Rebooting the system... this may take a few minutes, please do not kill this window.

Important: Do not close the window or terminate the process. The reboot can take several minutes.

Step 10 – Clean Up the Old Address

Once the OVC is back up and the federation is healthy, remove the now-unused old host interface from the datastore export list:

dsv-host-interface-delete --host 10.131.2.11 --ipaddress 10.131.2.10

Note the reversal: --host now refers to the new address, while --ipaddress identifies the old address to be removed. Skipping this cleanup leaves a stale entry in the export list that will cause confusion later.

Scenario B : Changing the OVC Management or Federation IP Address

The same procedure applies to both the OVC Management (eth0) and Federation (eth1) interfaces; only the --interface value differs.

Step 1 – Connect to the OVC

SSH to the OVC of the member being changed, log in to the support account, and elevate to root so you can use the dsv-* and svtctl commands.

Step 2 – Stop svtfs

# stop svtfs

This fails I/O services over to the other member systems in the data center, allowing the IP change to happen without disrupting guest VMs running on that member.

Expected behavior: Yellow alarms on VMs and on other OVCs after stopping svtfs are normal. They clear on their own once the work is complete and the VMs return to Storage HA compliance.

Step 3 – Change the Address

As the root user:

$ dsv-address-change --interface [Federation|Management] --address <IPV4_address>

Step 4 – Monitor the Command Output

The operation should complete quickly. Typical output:

Setting address 10.10.7.156 on eth1
 * Running /etc/init.d/networking restart is deprecated because it may not enable
   again some interfaces
 * Reconfiguring network interfaces... ssh stop/waiting
ssh start/running, process 19614
ssh stop/waiting
ssh start/running, process 19657
ssh stop/waiting
ssh start/running, process 19700
   [ OK ]

The first line (confirming the correct address on the correct interface) together with the trailing [ OK ] confirms success.

Step 5 – Reconnect and Start svtfs

If the Management address changed, your SSH session is disconnected. Reconnect on the new address, elevate to root, and start svtfs:

# start svtfs

(If only the Federation address changed, the SSH session survives — but you still need to start svtfs.)

Step 6 – Determine the OVC GUIDs

List the GUIDs of the nodes in the federation:

$ dsv-cfgdb-get-sync-status --ip 127.0.0.1

----------------------------------------------------------------------
                          Node Sync Status
----------------------------------------------------------------------
Node ID                               Node Name          Last Transaction Log
----------------------------------------------------------------------
564d7a4f-a04b-e635-f8fc-801d006c0894  OmniCube VC 9.115  715
564d6143-3a63-503f-3eda-2da537c3314e  OmniCube VC9.165   167

Take two pieces of information from this output:

• The GUID of the node that changed (used as --peerid in the next step)
• The lowest GUID among the nodes that did not change (this is where you run the peer reset)

Step 7 – Reset the Peer Record

Log in to the OVC with the lowest GUID among the unchanged nodes in the data center and elevate to root. Then inform the federation of the old-to-new address mapping for the changed node:

# dsv-peer-reset --peerid <GUID_of_changed_node> --old <old_IP> --new <new_IP>

Example:

# dsv-peer-reset --peerid 564d9c9c-9eb4-3d8b-99e5-11c9bda8820f --old 10.150.5.26 --new 10.150.5.28

If this step is skipped, the other nodes continue looking for the changed node at its old address and federation synchronization breaks down.

Step 8 – Start svtfs and Verify

# start svtfs

The yellow alarms observed in Step 2 self-clear as the VMs return to Storage HA compliance. Allow a few minutes, then re-check federation health.

Scenario C : Changing the OVC Storage IP Address

This is the most demanding scenario, because the storage address directly feeds the NFS datastore mounts. The procedure has two phases.

Critical constraint: The OVC must remain running throughout this operation, which means putting the ESXi host into maintenance mode is not possible — VMs must be migrated manually.

Phase 1 – Redirect Non-SimpliVity (Legacy) ESXi Hosts

Point every legacy host that shares SimpliVity storage at another member’s storage address instead of the one you are about to change.

1.1 Use vMotion to move all VMs that use SimpliVity storage to other legacy ESXi hosts.

1.2 Edit /etc/hosts on the legacy host and repoint the omni.cube.io entry to a different member’s storage address:

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1       localhost.localdomain localhost
# Any line beginning with a pound sign is a comment and will not be read.
10.10.1.8       omni.cube.io omnicube1

Replace 10.10.1.8 with the storage IP of the new target member.

1.3 Put the legacy ESXi host into maintenance mode if it belongs to a cluster. This ensures it is not using the .vSphere-HA directory on any datastore, which would otherwise prevent the datastore from being unmounted.

1.4 Log in to the host as root and determine the current NFS mounts and GUIDs:

~ # esxcli storage nfs list

Record the /mnt/svtfs/0/{GUID} path — you will need that GUID to recreate the mount.

1.5 Remove the NFS mounts:

~ # esxcli storage nfs remove -v vctest1

You may see output with Accessible set to false, indicating the mount was disrupted by the address change:

Vol Name  Host          Share                  Accessible  Mounted  Hardware Acceleration
--------  -----------   -------------------    ----------  -------  ---------------------
vctest1   omni.cube.io  /mnt/svtfs/0/{GUID}    false       true     Unknown

1.6 (Optional — storage IP change only) Recreate the NFS mounts:

~ # esxcli storage nfs add -H omni.cube.io -v vctest1 -s /mnt/svtfs/0/<GUID>

Where <GUID> is the value you recorded in step 1.4.

1.7 Verify the mounts and name resolution:

~ # esxcli storage nfs list

Vol Name   Host          Share                 Accessible  Mounted  Hardware Acceleration
--------   ------------  -------------------   ----------  -------  ---------------------
vctest1    omni.cube.io  /mnt/svtfs/0/<GUID>   true        true     Unknown

Confirm with vmkping that omni.cube.io now resolves to the new address:

~ # vmkping omni.cube.io

PING omni.cube.io (10.205.0.230): 56 data bytes
64 bytes from 10.205.0.230: icmp_seq=0 ttl=64 time=0.115 ms
64 bytes from 10.205.0.230: icmp_seq=1 ttl=64 time=0.102 ms
64 bytes from 10.205.0.230: icmp_seq=2 ttl=64 time=0.102 ms

1.8 Take the legacy host out of maintenance mode and vMotion the VMs back to it.

At the end of this phase, none of the legacy ESXi hosts in the data center should be targeting the member whose storage IP you intend to change.

Phase 2 – Change the OVC Storage IP Address

2.1 Manually vMotion (Migrate → Change Host) all VMs except the OVC off that ESXi host to other hosts in the data center.

Warning: Do not shut down or power off the member OVC. It must stay running for the duration of the operation.

2.2 Confirm that all VMs are HA compliant.

2.3 On the OVC whose storage address is changing, stop svtfs to fail I/O services over to the other OmniCube systems:

# svtctl stop

This allows the IP change to occur without disrupting any guest VMs hosted by that member. Yellow alarms are again expected.

2.4 Change the address:

# dsv-address-change --interface Storage --address <new-ip-address>

2.5 Reboot the member.

2.6 Use vMotion to move the VMs back to the member.

Note: After a storage IP change, shared datastores may need to be remounted and some services restarted.

Quick Reference: Command Summary

Command	Run on	Purpose
source /var/tmp/build/bin/appsetup	OVC (root)	Puts the dsv-* commands on PATH
dsv-host-interface-add --host X --ipaddress Y	OVC (root)	Adds a new host address to the datastore export
dsv-host-interface-delete --host Y --ipaddress X	OVC (root)	Removes the old host address from the export
esxcli network ip interface ipv4 get	ESXi host	Lists current vmk addresses
esxcli network ip interface ipv4 set -i vmk0 -I ... -N ... -t static	ESXi host	Changes a vmk interface address
dsv-identitystore-init Administrator <ip> root <password>	OVC (root)	Rebuilds the identity store
dsv-update-vcenter --server ... --username ... --password ...	OVC (root)	Refreshes vCenter registration (reboots the OVC)
stop svtfs / start svtfs	OVC (root)	Triggers / reverses I/O failover
svtctl stop	OVC (root)	Stops svtfs (storage scenario)
dsv-address-change --interface <type> --address <ip>	OVC (root)	Changes an OVC interface address
dsv-cfgdb-get-sync-status --ip 127.0.0.1	OVC	Shows node GUIDs and sync status
dsv-peer-reset --peerid ... --old ... --new ...	Unchanged OVC (root)	Updates the peer address record in the federation
esxcli storage nfs list / remove / add	ESXi host	NFS datastore mount management
vmkping omni.cube.io	ESXi host	Verifies storage address resolution

Pre-Change Checklist

• [ ] New IP address(es) provisioned and confirmed free of conflicts
• [ ] Authorized HPE SimpliVity support provider engaged
• [ ] All federation members reachable and healthy
• [ ] All VMs Storage HA Compliant
• [ ] Business-critical VMs migrated to another host
• [ ] Network Rollback disabled (vCenter 5.1+)
• [ ] Legacy (non-SimpliVity) ESXi host inventory taken and /etc/hosts plan prepared
• [ ] Current esxcli network ip interface ipv4 get and esxcli storage nfs list output captured
• [ ] Maintenance window scheduled and rollback plan defined
• [ ] Plan confirms only one federation member will be changed at a time

Post-Change Verification Checklist

• [ ] New address appears correctly in esxcli network ip interface ipv4 get
• [ ] Host shows as Connected in vCenter
• [ ] All datastores accessible and mounted
• [ ] All nodes synchronized in dsv-cfgdb-get-sync-status output
• [ ] Yellow alarms cleared
• [ ] vmkping omni.cube.io responds (storage scenario)
• [ ] Old address removed with dsv-host-interface-delete
• [ ] VMs migrated back to their original hosts
• [ ] Network Rollback re-enabled

Troubleshooting

Symptom	Likely cause	Resolution
IP change reverts on its own	vCenter Network Rollback is active	Temporarily disable Network Rollback
dsv-* command not found	appsetup was not sourced	Run source /var/tmp/build/bin/appsetup
Host cannot reach datastores on the new IP	dsv-host-interface-add was skipped or run after the IP change	Re-run the command referencing the old address
Host stays disconnected in vCenter	Only “Reconnect” was attempted	Remove the host from inventory and re-add it with the new IP
Other nodes cannot see the changed node	dsv-peer-reset was not run	Run peer reset on the unchanged OVC with the lowest GUID
NFS mount shows Accessible: false	Storage address changed; mount still targets the old address	Remove and recreate the mount using the recorded GUID
Yellow alarms do not clear	VMs have not yet returned to Storage HA compliance	Confirm svtfs is running and allow synchronization to finish