Migration from virtual to hw appliance

Forums Technical Forums
, ,
1

Dear all,

I’m managing an old BIG-IP VE cluster running release 12.1.1 and provisioned with LTM, ASM and APM. Now we have a new couple of BIG-IP i7600 running version 14.1.0.2 provisioned with LTM and APM modules. I need to migrate the configuration (many virtual servers and APM policies) from the virtual to the appliances but I’m not able to do this. I made some tries:

  1. Imported an ucs from the old to the new one and installed with no-license and platform-migrate flag: no success
  2. Downgraded new units from 14.0.2 to 12.1.1 and installed the ucs file as described before: no success
  3. Tried a migration with the migration tool assistant: no success

Have you any idea how to solve this? Adding new appliances on device group from old cluster is not a choice because APM doesn’t support more than 2 unit at a time. I cannot believe ther isn’t a method to migrate configurations, should I reconfigure all the virtual servers/policies/iRules and so on by hand?

I hope you can help me.

Luca

2

Hello.

I strongly recommend you to check this out →

KR,

Dario.

3

By the way, importing a UCS could be failing because of the master key. You should review logs to figure out what the problem is about.

Using this command is also a good point.

# tmsh load sys ucs <filename> platform-migrate

KR,

Dario.

4

I would also look at seeing whether you have the ability to upgrade your VE to 14.x so that you can migrate *that* UCS over to your new platforms. Do you have any spare VEs or lab licenses you can test this on?

5

Here is the process which will make it simpler

  1. Configure new HW with different self IPs and Management IPs
  2. Allow in Firewalls new Self IPs to access pool members if there is firewall between F5 and nodes.
  3. create a cluster between hardware and VE.
  4. synchronize from VE member to HW.
  5. failover to HW
  6. Check if everything works as expected.
  7. failover to VE
  8. Upgrade HW to version 14.1.0.5
  9. failover to HW
  10. Check if everything works as expected.
  11. switch off VE
  12. remove VE from Cluster device groups in HW configuration
  13. remove VE from Peer list in HW configuration

I did this 2 weeks ago without issue

6

Hi Dario,

apparently the problem isn’t related to the master key but on the modules provisioned to the hardware. Underneath you can find the log from importing the ucs with the hardware running the same version of the VE:

root@(localhost)(cfg-sync Standalone)(ForcedOffline)(/Common)(tmos)# load /sys ucs appf502_07062019_no_pass.ucs no-license platform-migrate

Replace all configuration on the system? (y/n) y

Processing UCS file: /var/local/ucs/appf502_07062019_no_pass.ucs

Installing full UCS (12.1.1) data, excluding license file.

Saving active configuration…

The hostname is set to appf502.master.local

Extracting manifest: /var/local/ucs/appf502_07062019_no_pass.ucs

Product : BIG-IP

Platform: UCS  : Z100

System: C118

Version : 12.1.1

Edition : Final

Hostname: appf502.master.local

Installing --full-- configuration on host appf502.master.local

Installing configuration…

ERROR: Module am is invalid for platform-migrate mode. Only LTM and GTM are supported.

ERROR: Module apm is invalid for platform-migrate mode. Only LTM and GTM are supported.

Post-processing…

usermod: no changes

Error detected. Skipping final load.

WARNING: There were one or more errors detected during installation.

Check the error messages and take the proper actions if needed.

ERROR: UCS installation failed.

Operation aborted.

Unexpected Error: UCS loading process failed.

7

Hi Stanislas,

I was thinking aout that but I have some problems. First my VE is made by 2 VM clustered and I now that APM module support up to 2 device in a cluster. So to perform the action I should open the VE cluster, insert an hardware platform, sync configuration, and rebuild the old cluster and the new hardware cluster. Moreover my HA VLAN is local to devices and is not transported over the network so I should reconfigure also this part. I’d prefer not modify the production environment but I understand it perhaps is the unique solution.

8

Hello Luca.

It’s important to check your logs to know what part of the process is failing

# cat /var/log/ltm

KR,

Dario.

9

Hi Dario,

I think the problem is here but I think there is no solution:

Jun 10 09:43:59 appf504.master.local warning mcpd[11039]: 010712e9:4: dag.notifyswitch is not in BigDB.dat.

Jun 10 09:43:59 appf504.master.local err mcpd[11039]: 01b9000f:3: This platform doesn’t support DoS hardware capability, which is ne

eded to disable this sys db variable.

Jun 10 09:43:59 appf504.master.local err loaddb[1749]: 01080023:3: Error return while getting reply from mcpd: 0x1b9000f, 01b9000f:3

: This platform doesn’t support DoS hardware capability, which is needed to disable this sys db variable.

10

The problem comes in the release notes

And it has solution

KR,

Dario.

11

Hi guys,

just to let you informed my problem was that the new HW appliance is not licensed with the AAM module (it is in EOL/EOS now so it can’t be added). The original UCS file has a lot of aam profile in it so it cannot be imported into the new one, the only solution is deconfigure aam and deprovision it on the VM and then export again the configuration. Obviously I cannot do it so I think I will go to manually reconfigure the new appliance I can’t see any other method. I think I would have the same problem also adding the HW appliance to the VM cluster.

Luca