We start our import with a brand new, blank SDDC.
We have to generate a refresh token and retrieve the org and SDDC ID, the same way we did in the prior post for the export. But this time, we populate the destination fields instead of the source fields. Don’t worry about leaking the refresh token – I disabled it long before posting this screenshot. I left it in here to show people unfamiliar with the tokens what they should look like. But you should take care not to leak your own refresh tokens!
The script shows us which org and SDDC are going to receive the import. You can input ‘n’ here to run the import in test mode, or input ‘y’ to import the data into the destination SDDC. In this example I input ‘n’.
The import moves through the various SDDC configurations. Here we see it importing network segments in test mode. Test mode moves very quickly because it doesn’t actually perform any API calls – all it does is open exported JSON files and validates that that the files can be read.
This is what the import looks like in live mode – there are screenshots of importing network segments, public IP addresses, and VPN configurations. Note that it is impossible to copy Elastic IP addresses between SDDCs. The tool will request new Elastic IP addresses in the destination SDDC, then remap your NATs to the new Elastic IP addresses.
The import process creates a file named public_ip_old_new.json which contains the mapping of old to new Elastic IP addresses. You can read this file if you need to automate any changes like DNS updates.
Our previously empty SDDC now has the exported configuration loaded. Here are a couple of screenshots – you can see the segments and VPN configuration.
That’s all for importing!
In Part IV, we look at how to find VMC API calls to implement a new feature in this project.