Live migrate StorPool iSCSI and HAVM services

When planning maintenance activities, consider that applications using the following StorPool services may also be affected by the interruption:

• StorPool iSCSI Service

• StorPool Highly Available Virtual Machine (HAVM)

These services are designed for high availability. If a service instance becomes unavailable, StorPool automatically initiates a failover process. Existing iSCSI sessions are migrated to another active StorPool iSCSI controller. The HA VM is started on another node where the active StorPool Management Service resides.

Although service availability is maintained, applications relying on these services may experience temporary performance degradation, connectivity interruptions, or application crashes during the failover process. This can occur while iSCSI sessions are being re-established on a different controller or while the HAVM is starting on the new host.

To minimize the risk of service disruption, StorPool provides a live migration mechanism that allows services to be proactively moved to another node before performing maintenance operations. Using live migration reduces the risk of application impact and ensures a smoother service transition from one node to another.

Live migrate StorPool iSCSI sessions

On the node that is going to undergo maintenance, perform the following steps using the StorPool CLI to check for active iSCSI sessions and migrate them if any are found.

1. Check for active iSCSI sessions on the node:

   storpool iscsi sessions list controller $(storpool_showconf -ne SP_OURID)
   

2. If there are active iSCSI sessions, use the following tool to migrate them to another active node:

     /usr/lib/storpool/move_iscsi_sessions here
   
   .. note::
      An option to migrate iSCSI sessions from the StorPool GUI will be available in a future.
   

Live migrate StorPool Highly Available Virtual Machine (HAVM)

On the node that is going to undergo maintenance, perform the following steps using the StorPool CLI:

1. Check if there is an active StorPool HAVM instance and verify if the HA VM is currently running on the node (which indicates if this node holds the active management service):

   systemctl status 'storpool_havm@*.service'
   

   If the service is active, check the status of the HA VM by running:

   virsh list --all
   

   Note

   To list the names of all highly available virtual machines, run the following command: systemctl list-units --output=json 'storpool_havm@*' | jq -r '.[].unit | split("@")[1] | split(".")[0]'

   Output example:

   virsh list --all
   Id   Name       State
   --------------------------
   ...
   7    havm-nfs   running
   

2. If a HA VM is running on the node, you can live migrate it to another node by restarting the storpool_mgmt service on the current node which will move the active StorPool management also:

   systemctl restart storpool_mgmt.service
   

3. Verify that the HA VM has migrated to another node.

   Find the newly active StorPool management service:

   storpool service list
   

   Output example:

   cluster running, mgmt on node 2
         mgmt     1 running on node  1 ver 21.0.3086, started 2026-06-01 15:44:45, uptime 1 day 20:12:48
         mgmt     2 running on node  2 ver 21.0.3086, started 2026-06-01 15:09:16, uptime 1 day 20:48:17 active
         mgmt     3 running on node  3 ver 21.0.3086, started 2026-06-01 15:09:55, uptime 1 day 20:47:38
   ....
   

   Confirm that the HA VM has migrated to the node that just become the active management:

   virsh list --all
   journalctl -u storpool_havm@<VM_name>
   

   Journal log example showing successful migration:

   Jun 03 12:01:38 storage1 /usr/sbin/storpool_havm[1879]: VM havm-nfs is not running on active node. Looking for running VM on other hosts first.
   Jun 03 12:01:38 storage1 /usr/sbin/storpool_havm[1879]: find_vm: other clients: [2]
   Jun 03 12:01:39 storage1 /usr/sbin/storpool_havm[1879]: find_vm: hostname (state): storage2(running)
   Jun 03 12:01:39 storage1 /usr/sbin/storpool_havm[1879]: find_vm: _wait_client_up: client 2 up, proceeding
   Jun 03 12:01:39 storage1 /usr/sbin/storpool_havm[1879]: Migrating havm-nfs from 2 here ...
   Jun 03 12:01:39 storage1 /usr/sbin/storpool_havm[1879]: Migrating from storage2 to storage1 ...
   Jun 03 12:01:39 storage1 /usr/sbin/storpool_havm[1879]: Attach volumes ['havm-nfs-os', 'nfs'] here
   Jun 03 12:01:39 storage1 /usr/sbin/storpool_havm[1879]: Attach request: {'attachTimeout': 5, 'reassign': [{'rw': [1], 'volume': 'havm-nfs-os'}, {'rw': [1], 'volume': 'nfs'}]}
   Jun 03 12:01:39 storage1 /usr/sbin/storpool_havm[1879]: Attach response: {'ok': True, 'generation': 45781, 'info': None}
   Jun 03 12:01:39 storage1 /usr/sbin/storpool_havm[1879]: Migrate ...
   Jun 03 12:01:53 storage1 /usr/sbin/storpool_havm[1879]: Migrate out=
   Jun 03 12:01:53 storage1 /usr/sbin/storpool_havm[1879]: Detach volumes ['havm-nfs-os', 'nfs'] from 2
   Jun 03 12:01:53 storage1 /usr/sbin/storpool_havm[1879]: Detach request: {'attachTimeout': 5, 'reassign': [{'detach': [2], 'volume': 'havm-nfs-os', 'force': False}, {'detach': [2], 'volume': 'nfs', 'force': False}]}
   Jun 03 12:01:53 storage1 /usr/sbin/storpool_havm[1879]: Detach successful, response: {'ok': True, 'generation': 45782, 'info': None}
   Jun 03 12:01:53 storage1 /usr/sbin/storpool_havm[1879]: Migration successful.