Copying VMWare AM from One Array to Another Array Issues

[RogerBerntson]

Good Day All,

Has anyone in a clustered VSphere setup with an array attached had to move data from array to another?  Our array attached to our vmware servers is not supported by newer versions of VMWare.  So we have to move all data from one array to a new array.  This basically requires shutting down the VM, copying/moving data from one array to the new array, registering the moved VMX file in vmware and praying everything works.  We decided to copy everything so that we have a backup on the old array in case anything goes bad.  This worked perfectly for all windows servers, vmware appliances, etc. with the exception of...you guessed it...Authentication Manager.  

When you copy the vmdk and vmx files to the new array and active it on vmware, it runs the setup program (asks for IP address) all over again.  I am going to try to copy the entire directory of the VM from one array to another to see if that works but I am out of ideas.

I can't believe I am the only person who has every attempted this.  Has anyone ever tried to copy AM from one array to another array and then activate it in VMWare successfully??  Ugh, please say yes I have no desire to migrate the data to new instance or demote/promote...

Thanks in advance..

[EricHarris]

This has bitten us twice, and while this is an older post, I figured it might be worthwhile to share the knowledge we learned and then re-learned. If the MAC address of the server changes, that'll cause the network to break on RSA Authentication Manager VM's (Hyper-V, VMWare, etc.)

Login to server or server console as rsaadmin

Change to root: ~> sudo -i

Network Files

# cd /etc/sysconfig/network/

1. Remove the old ifcfg-eth0 and ifroute-eth0 files

      # rm ifroute-eth0 ifcfg-eth0

2. Rename the ifcfg-eth1 and ifroute-eth1 to eth0

      # mv ifcfg-eth1 ifcfg-eth0

      # mv ifroute-eth1 ifroute-eth0

3. Edit Network Files

     # vi ifroute-eth0

      Change eth1 to eth0 and Teth1 to Teth0 in the file:

      default Gateway_IP - eth0 table Teth0

      Subnet_IP/Netmask - - eth0 table Teth0

4. Edit Routes File

      # vi routes

      Change eth1 to eth0:

      default Gateway_IP - eth0

  5. Edit Rules File

      # vi rules

      Change Teth1 to Teth0:

      Server_IP/Netmask Teth0 70

6. Edit Route Table Pointers

      # vi /etc/iproute2/rt_tables

      Change Teth1 to Teth0:

      252 Teth0

Network Rules

7. Network Startup File Modification

      Option A: Move startup file to allow auto re-creation

      # mv /etc/udev/rules.d/70-persistent-net.rules /tmp/.

      Option B: Manually modify startup file

      # cd /etc/udev/rules.d/

      # vi 70-persistent-net.rules

      Note: The comment before the line differs between virtual hosting environments:

• VMWare: # PCI Device xyz
• Hyper-V: # net device ()

      Delete the 3 lines for the existing eth0 entry

      # net device ()

      SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="MAC:ADDRESS",       ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

      Rename eth1 to eth0 in the remaining entry

      # net device ()

      SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="MAC:ADDRESS",

      ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

8. Restart Server

      # init 6

Encryption Key

Following the reboot, you may need to fix the Encryption Key.

If the network is up, but RSA services fail to start, check the file: /opt/rsa/am/server/logs/AdminServerWrapper.log

If the error listed is Failed to reload password database, you will need to fix the Encryption Key.

To fix the issue, you’ll need an Operations Console username and Password and then issue this command from the RSA console (logged in as rsaadmin, not super user):

rsaadmin@server:> /opt/rsa/am/utils/rsautil manage-secrets -a recover