Hi Abhishek,

I assume the ISVA appliances are KVMs right now, correct?

There is not really a lift and shift pattern for migrating ISVA KVMs.  What has worked well in the past for other customers is:

• Setup the new KVM environment.  Make sure the internal networks are using the same subnets as the current.
• Create appliance level snapshots on the source VMs.
• Create new ISVA VMs in the target KVM environment.  These should be basic matches such as network interfaces and activated modules.
• Apply the source snapshots to the respective target VMs.

I have not tested but it might be possible to:

• Export the source KVM using virsh dumpxml
• Make sure the target environment supports the basic settings such as libosinfo, cpu, etc.
• Copy the underlying disk to the same location on the target system or edit the XML as needed.
• Create a new KVM using virsh create file.xml

The process for ISVD LDAP and DB2 will be similar.

Hi Nick, We are planning to move our complete ISVA appliances and ISVD LDAP + DB2 to red hat KVM 9, can you please me to understand how smoothly it can be migrated. 

Currently it's running on EOL machine Red hat 7.9

Hi Patrick,

There is not a similar guide.  Migrating from HW to VM is really no different than migrating VMs around.  We see this especially when customers need to migrate to the Cloud VMs or from one datacenter to another.

One successful method other customers have used to migrate DCs or to a Cloud deployment is,

1) Setup a VPN between the source and target.
2) Setup appliances in the target.
3) Add them as nodes to the source cluster.  If the internal HVDB or CONFIGDB is being used it needs to be made a secondary.
4) Promote the secondary to be the Primary Master of the Cluster.  This node should have all activations that are enabled on any node.
5) If in use this has now moved the embedded LDAP and internal configdb and hvdb to the target cluster.
6) The WRP instances are exported from the source cluster and imported into the target cluster appliances using the WRP export/import feature.
7) The source nodes are slowly decommissioned and removed from the cluster.
8) The VPN is shut down and the cluster has been migrated.

Other options:

Verify Access Runtime Migration

When using external AAC Runtime configdb and hvdb databases the following feature added in 10.0.4.0 can be used,

https://www.ibm.com/docs/en/sva/10.0.4?topic=environment-exporting-runtime-configuration

This will migrate the Policy Server (and embedded LDAP if used) to a new appliance.  If using a remote LDAP, it needs to accessible via VPN or a new LDAP setup in the cloud that is then also accessible to the still existing on-prem VMs.  New WRP appliance can be build and the instance migrated using the export/import feature.  This assumes the CONFIGDB and HVDB are accessible or have been migrated as well.

Appliance Snapshots

While snapshots are really meant to be used as an exact appliance rebuild they can be used to migrate the Primary Master of a cluster.  However, the cluster must be re-configured to only have a Primary Master before a snapshot is created.

This snapshot can be applied on a target machine in the target environment built to match the source.  That is, same number of NICs, activations, etc.

Once applied the network settings will need to be reconfigured using the console CLI.  The snapshot cannot be altered beforehand with the target network information.  Snapshots have a checksum for security purposes.  This method has been successful as well.

Is there any migration guide from hardware appliance to virtual machine since the end of support for appliances is September 2025?

Hi Mubashir,

You can follow the docs for that.  It is really no different than going from say 9070 to 9072.  See https://www.ibm.com/docs/en/sva/10.0.3?topic=overview-upgrading-current-version for details.

That being said make sure to check https://www.ibm.com/support/pages/node/6340107 for the upgrade path.

Also, I recommend going to 10.0.3.1 which was released today.  It fixes some issues that you may hit when going to 10.0.3.0.  Going to 10.0.3.1 is a cleaner upgrade.

Hi Nick,

Do we have documentation for migration like the above from 9.0.7.2 to 10.0.3 ?

thanks

You may want to update the document, since it contains some outdated links inside, like http://www-01.ibm.com/support/knowledgecenter/SSPREK_6.1.1/com.ibm.itame.doc_6.1.1/am611_admin281.htm%23chcert?lang=en

Thanks.