Back in April I published a post about my GitHub repository containing Ansible scripts that perform automated deployment of nested vSphere/NSX-T lab environments.
A lot has happened during the last 5 months and now that we’re close to making version 2 the default branch, I thought it would be a good time to give you an update of what’s been going on.
The idea
Let’s start with the one thing that hasn’t changed, namely the idea behind this project: A collection of Ansible scripts that perform fully automated deployments of nested VMware SDDC Pods.

If you’re looking to deploy complete VMware SDDC nested environments without having to manually install all of the individual components, this project might be of interest to you.
No, you can’t make this work on an Intel NUC. You will probably need some real server hardware (and decent storage too), but if your goal is to spend quality time with the latest VMware technologies like vSphere 7 and NSX-T 3 (for studies, PoC, dev/test, etc), that investment will be worth it any time.
A partner in crime
Soon after publishing my second post about this project Luis Chanu, who already was somewhat of a “trusted advisor”, stepped up to become a lead developer himself. Having Luis as my script writing partner has made a tremendous impact on the direction this project has taken. For example, in v2 the entire code base got a major overhaul. Smarter, more scalable code and many other good improvements adding a certain level of maturity to the project. Most of this is thanks to Luis hard work during the last months.
A new project name
_________________ _____ _ _
/ ___| _ \ _ \/ __ \ | | | | Developed By
\ `--.| | | | | | || / \/ | | __ _| |__ --------------------------
`--. \ | | | | | || | | | / _` | '_ \ Rutger Blom & Luis Chanu
/\__/ / |/ /| |/ / | \__/\ _ | |___| (_| | |_) | NSX vExpert VCDX #246
\____/|___/ |___/ \____/ (_) \_____/\__,_|_.__/
The old project name wasn’t really a name anyway and quite a mouthful too. “SDDC.Lab” is more catchy and to the point. It also happens to be the default domain name for the SDDC Pods that you deploy (it’s configurable of course). We hope you like it too.
New components
Alright. There are many new and improved things in version 2, but from a component perspective we have two new additions:
- vRealize Log Insight
- DNS Server (Ubuntu VM with ISC BIND)
We’re especially happy with the addition of that DNS server which also acts as an NTP server. With a zero-touch installation and pre-configured for any Pods that you will deploy, this thing will save you time and potential headaches. It is an optional component and you can still leverage your own DNS/NTP infrastructure if you want to, but we think that most people will want to include our “appliance”.
I don’t think that vRealize Log Insight needs any introduction. It’s VMware’s “syslog server on steroids” product and a very common component in VMware SDDCs. That’s why we added it to the project where it’s configured as the default syslog target.
Deploy to vCenter
Previously you were only able to deploy the nested Pods to standalone ESXi hosts. Just before freezing the code for the v2 release we managed to squeeze in the option to deploy Pods to a vCenter target. A very welcome addition that will make life easier for those with physical ESXi hosts managed by vCenter (not too uncommon I believe).
IPv6 support
In v2 the following components can be configured with IPv6:
- Nested VyOS router (all interfaces)
- NSX-T segments
- NSX-T eBGP peering with the router
Ultimately we want to offer IPv6-only Pods and this is something that has high priority in upcoming releases.
Miscellaneous improvements
A lot of other things have improved and the majority of this is “behind the scenes” stuff. I do want to highlight a couple of them:
- Utilize data structures (where possible) for improved scalability and manageability
- An improved deployment process that decreases overall deployment time
- Introduction of the software library where the required OVA/ISO files are stored
- A separate data file for license keys which are then automatically applied during a Pod deployment
- Utilize DDNS (nsupdate) for populating the DNS server with records
- Many, many Ansible script optimizations

Trying out v2
As mentioned before, we are busy with finishing touches of version 2 (when our schedules allow us to). We believe that the code is pretty much done and are now mainly working on the documentation where there are still some gaps.
If you would like to give version 2 a try today you can start by visiting the branch’s page over at GitHub and basically take it from there. Don’t forget to do a “git checkout dev-v2” after cloning the repository as v2 is not the default branch yet.
Update 6/11/2020:
SDDC.Lab version 2 is now the default branch. Have fun!
The information in the README.md is almost complete and should help you get started. We’re also working on a “Deploying your first SDDC.Lab Pod” guide which is not complete yet but could still be helpful.
Let’s us know what you think or if you have any questions or suggestions.
I tried your V1 this week, I had to make some minor changes to get it work on my AMD Ryzen9 PC, and it works! Thank you very much! I will try your v2 when I have time. I will open a pull request if someone is interested in AMD Ryzen workaround.
LikeLike
I tried your V1 this week, I had to make some minor changes to get it work on my AMD Ryzen9 PC, and it works! Thank you very much! I will try your v2 when I have time. I will open a pull request if someone is interested in AMD Ryzen workaround.
LikeLike
I’ve been using your v1 for a few weeks, looking forward to v2.
One change I’m working on making for my own uses (you’re free to use or not) is a move from VyOS to Cumulus so I can test MLAG and EVPN configurations as I don’t think VyOS has MLAG equivalent yet.
LikeLike
First of all…thanks for such great work! I’ve been looking for an easier way to auto deploy an NSX lab so this seems to be just what I need, especially being able to build custom pod configs and have multiple lab setups just minutes away.
I do have a question: with a vCenter deployment, is there a way to specify a single host only? I initially tried this but the PodConfig creation bombed because it could not create resources on the other host in my vCenter. I’ve searched around and have not been able to resolve this so hoping you might have some words of advice.
LikeLiked by 1 person
Thank you. With the current code it’s not possible to do this. A workaround might be to have the target datastore connected to just the host that you want to deploy to. We’ll have a look at if this is something that we can include in a future release.
LikeLike