NimbostratusWe have been purchased by a new company who wants to migrate all our virtuals into their environment. We have hundreds of these and little time. Is there a good way to export all our virtuals, pools, monitors, nodes, change the ip's and import into the new company? -Secondarily, is it possible to include certs as well?
NimbostratusRun tmsh sys config file /var/tmp/backup.scf, which generates a single file with all configurations.
Set up your new F5 with appropriate routes, VLANS, SNAT pools etc.
Install all new SSL certs on the new F5 for every VIP. Don't try to import old ones.
Copy any objects you need from backup.scf to a new file, then edit file with needed changes.
To test if it will merge correctly with the new F5, run "tmsh load /sys config merge verify /var/tmp/bigip.conf.new". Using verify is crucial, because it doesn't commit the merge. It only tests it.
Once merge verify passes, you can run "tmsh load /sys config merge /var/tmp/bigip.conf.new" to commit.
Do the same thing for config/partitions/name/bigip.conf if you use them.
NimbostratusThis is great info! I have a follow up question: The new F5 places everything in a separate partition while the old one has everything in common. Is that just another edit? Can it be imported into the new partition?
CirrusPlease up-vote my answer if you find it helpful. :)
I can't understand why anything would get loaded into a new partition unless you are logged into that partition instead of common. I'm currently using 12.1.3 and am never forced to use a partition. You could try exiting that level of TMSH or in GUI change to Common (upper right). You definitely don't want to be loading these configs into a partition. It makes things much more hairy.
CirrusThe other answer recommending the use of the complete config file is a good one if you don't mind configuring your F5 from scratch by editing the system, network and other settings in the config that is generated. If your F5 is already built (sounds like it is), I'd take the more cautious approach I suggested. That said, there's no better method than save /sys config for backing up and restoring to the same F5. I agree with the comment about migrations requiring a lot of knowledge. Your statement about being stuck in a partition gave me some feelings of concern.
EmployeeThe Single Configuration File is the place to start:
K13408: Overview of single configuration files (11.x - 13.x)
This format saves all the text configuration elements into a single text file, and creates a tar file of the filestore (including ssl certificates and keys).
It is the format most amenable to being manipulated. However, as any editing of configuration files, it is easy to create a non-loadable config.
I'd recommend working carefully through the config and starting with some small changes to get the feel for how the files are structured.
NimbostratusI originally tried the "copy stuff from SCF into new LTM config" route but for anything other than very simple setups I found it to be fraught with danger. The most stable method I've found for this situation is to use iControl (the REST API) - specifically through the Python SDK.
Using the Python SDK you can pull configuration from one system, apply any transformations you'd like (change partitions, standardize profiles, etc), and import into the other system.
iControl applies the same rules as the web interface which makes operations much safer than mucking with the config files direcly. For example, you can't accidentally create a virtual server that references a profile that doesn't exist on the destination LTM.
EmployeeI certainly agree that using the iControl is a good option as well.
However, getting it set up and running for a non-programmer is not trivial.
Again, YMMV