Today (8th February 2021), I’m delighted to announce the release of our new Fling : SDDC Import/Export for VMware Cloud on AWS.
A common request from VMware Cloud (VMC) on AWS customers and partners is the ability to save the configuration of a VMC environment (a Software-Defined Data Center – SDDC) and restoring it to another VMC SDDC. This would be used for a multitude of use cases:
- Save the configuration of an SDDC before a change.
- Save the configuration of an SDDC before it expires (1-node SDDC only live up for up to 30 days as VMware will not encourage customers to run workloads on an environment that offers no resilience) and applying to a new SDDC.
- Set up identical test labs with a template SDDC (very useful for training).
- Speeding up deployment of SDDC configuration
- SDDC-to-SDDC Migration (for example, when one of the components of the SDDC is changing – such as when SDDCs were migrated from NSX-V to NSX-T or when we move from i3 to another bare metal type).
- Integration with Disaster Recover – such as VMware Cloud Disaster Recovery – to inject a template/golden configuration as soon as a DR SDDC is deployed (trust me, you don’t want to manually input hundreds of network rules when dealing with a severe outage).
In my three years working with the service, I would have LOVED to have a tool that could provide this functionality – save/load, backup/restore or export/import. Eventually, I decided to build it myself. Thankfully I came across folks who had similar ideas and even prototypes.
My main partner in crime for the project is Patrick Kremer, who, as you can see above, was very quick to collaborate with me on the project when I pitched the idea in our internal Slack channel.
Conveniently, his script was written in Python, which was our preferred programming language for the tool (I also re-used a large bit of code and logic from PyVMC).
Working as a team and presenting the tool internally really enabled us to add more and more features, like saving the configuration to an AWS S3 bucket or exporting multiple configuration files. The tool has now grown to over 2,000 lines of code.
Patrick and I tried to write this as closely as we think developers and product teams would build a piece of software – collaborating and documenting through a version control system (using our internal VMware GitLab), defining a list of features for a Minimum Viable Product, capturing feature requests into a roadmap, capturing issues and bugs, etc…
We also went to the extent of having a logo created by the VMware Brand team – looks nice, doesn’t it?
Before I go through how to use the tool, let me just say something:
Many of us who come from the infrastructure or networking world often encounter the imposter syndrome the first time we dip our toes into coding. We often think to ourselves: “My code is not good enough” or “I’m not a real developer”. Or we abandon quickly as we don’t find an actual project or use case where to apply our burgeoning coding skills.
I frankly don’t know what the criteria for being a developer is and I doubt I will ever consider myself one. But… even if you don’t think you are a ‘coder’ – with enough practice, a good use case, a basic understanding of APIs and excellent teamwork, you can, like us, create something that could save hours of work to hundreds of users.
Patrick has put together a great blogging series that works through it in a lot of details.
In short, go the Fling portal here and download the Zip:
This video (with audio) summarizes the workflow. Hopefully it shows how straight-forward it is (you simply need Python3, a VMware Cloud on AWS SDDC and a token and you’re good to go).
There are many ways to customize the tool (in particular you can decide which parts of the configuration you want to export and import) but to keep it simple, to export the configuration from an existing SDDC, just run the command:
python3 sddc_import_export.py -o export
And same for the import:
python3 sddc_import_export.py -o import
We can export and import most of the configuration that would be time-consuming to recreate, including:
- Network Segments
- Security Groups and Services
- Security Rules (MGW, CGW and DFW)
- VPN (L3VPN and L2VPN)
- NAT rules and Public IPs
We are limited with the last two by the fact that we cannot transfer a public IP to another SDDC (it’s as if you would ask AWS to transfer a public IP from an account to another) so the public IPs used by applications and for VPNs won’t be the same. However, we “re-map” their configuration across to the new SDDC.
For example, if you had saved the configuration of an SDDC that had a web service running on IP 220.127.116.11, with a description of “web_server” and natted to private IP 10.10.10.10, the import will request a public IP with the description of “web_server”. While the public IP will be different (as it comes from the pool of IP addresses owned by AWS), the tool will automatically recreate an NAT rule from the new public IP address to 10.10.10.10. It means the only change required on your side would typically be a DNS change.
For VPNs, the VPN settings – including PSK and VPN encryption parameters – would be recreated but the remote end of the VPN would need to point to the new VPN Public IP reserved for the SDDC.
If you have any requests, please get in touch via Twitter or raise it on the Fling portal. In the coming days, the source code will be published on the VMware Labs GitHub page where we will track feature requests and bugs. You will be welcome to contribute to it.
It’s a Fling, so no, it’s not officially supported. We have done as much testing as we can and frankly I am still amazed the stuff actually works. But it does.
However, if you do spot any issues, let us know.
One thing I will remind the users is that we expect the destination SDDC (where we import the saved configuration) to be a brand new one, with no other configuration. We don’t check (yet) what’s already deployed – we just push the previously saved configuration.
There are many features we are looking at for the roadmap, such as providing a User Interface for the tool and looking at helping customers moving from environments such as VMware Cloud Foundation or NSX-T on-premises.
We’re looking forward to hearing feedback from internal and external users: that will ultimately drive the roadmap.
I should also say that some customers might eventually prefer to go down the Infrastructure-As-Code route, which would remove the need for a tool like ours. Or hopefully, there might be in the future a tool within the VMware Cloud console where you can save and load SDDC configuration. Until then, our tool is there to help.
One more thing: as this Fling was being about to be published, I coincidentally submitted my third Fling. By far the most sophisticated – leveraging Angular, Clarity, Go, Ansible and Terraform under the hood – but then I am working with some very smart people on it.
Hopefully it will come out by April. Looking forward to sharing what we’ve built.
Thanks for reading and we hope you like the tool.