Finishing touches and testing is completed. We’re proud to announce that we’ve just released SDDC.Lab Version 5!
For those of you that are not familiar with the SDDC.Lab project, it’s a collection of Ansible Playbooks that perform fully automated deployments of nested VMware Software Defined Data Center Pods including solutions like vSphere, vSAN, and NSX.
The project is maintained at a public GitHub repository and available to anybody who’s interested in speedy and consistent provisioning of nested VMware SDDC lab environments.
Version 5 supports deploying SDDC.Lab Pods with the latest and greatest VMware technology while also maintaining backward compatibility for deploying earlier product versions. The “bleeding edge” bill of materials that SDDC.Lab v5 supports consists of the following VMware product versions:
- vCenter Server version 8.0
- ESXi version 8.0
- NSX version 18.104.22.168
- vSphere with Tanzu version 8.0
- vRealize Log Insight version 8.8.2
New Features and Improvements
We, Luis Chanu and I, recommend that you have a look at the project’s CHANGELOG.md for a comprehensive list of all the new features and improvements that were added in version 5. The list below highlights some of the main features and improvements:
- NSX-T overlay segments are automatically configured with Pod-unique IP subnets. This makes it possible to route IP traffic originating from these segments between Pods as well as between Pods and the physical environment.
- vSphere Content Libraries can be created in the nested vCenter as part of a Pod deployment. The content libraries can then be consumed by other project features like Workload VMs and vSphere with Tanzu.
- Pod configuration generation is much faster down from 1,5 hours to 7-10 minutes.
- We’ve made sure that every single Ansible task that is taking place as part of a Pod deployment can be successfully carried out using standard Linux user privileges. The use of “sudo” is no longer required nor recommended when running Pod deployments.
- Nearly all the project’s Ansible code has undergone Ansible Linting to ensure that the project is following Ansible’s proven practices, patterns, and behaviours as much as possible.
Besides these main items we’ve been working work on many smaller things like code optimization, stability, and performance.
How to Get Started?
Getting started with SDDC.Lab v5 is quite easy. You head over to the GitHub repository and read through the README.md which contains all the information you need to successfully deploy your SDDC.Lab Pods. For completeness here are the high-level steps required to deploy a Pod:
- Install an Ubuntu Linux machine with Ansible and required modules
- Prepare a Pod configuration
- Deploy a Pod
Detailed steps are available in the Preparations section of the README.md.
SDDC.Lab version 5 literally is a major release with many great improvements such as support for new product versions, new project features, and code improvements. We hope you will appreciate it.
We have many plans and ideas for the next release and a new development branch is already in place. Check it out if you want to follow the developments in the project.
I’m following your Lab and it is fantastic. In a single site all work as expected. I’ve one question in Federation. I not found a playbook and module to create global segments. In federate nsx edge you create rtep tiene imports T0 to global manager. Is the only way to do it or there is a possibility to create with a playbook for global manager and module for it?
If there is please share the procedure.
Rutger and I are very pleased that you are enjoying the lab. We’ve put a lot of hard work into it over the years, so it’s great to see people using it.
Regarding your question about creating global segments, that’s very observant of you. There is no playbook to specifically create global segments that is part of the SDDC.Lab project, just like there’s no playbook to create global groups. Here is how it’s done…
During the deployment of the various Pods that are participating in Federation, if it’s identified that Federation is enable in the config.yml file, then ONLY the Pod that is designated as being where the Global Manager will be deployed creates LOCAL overlay segments…the other sites do NOT create any overlay segments, only VLAN backed segments. Once the Global Manager is fully deployed, each location is on-boarded, one-by-one. As part of the on-boarding process, all of local objects (which includes the local segments, groups, etc.), are imported into Federation, which converts them to Global Objects. The on-boarding process is an “all or nothing” operation in terms of importation, so that’s why, once everything is deployed, all supported local objects were converted to global objects (i.e. Groups, Segments, etc.).
I hope that helps explain the inner-workings of how Federation is deployed by the SDDC.Lab project.
Co-Developer of SDDC.Lab
Thanks for your answer. I appreciate all of your hard work because it is only with the real lab deployment that i understand how many difficulties you have found during the setup of this incredible lab..
Keep in touch and good labbing for all your future project..
LikeLiked by 1 person
Perfectly explained Luis.. The Onboarding is the key as i thought.. I Will give a Try..
The on boarding process you have done manually or with a ansible playbook?
To expand a little bit more on your post and question, I’m sure there are other ways of implementing/doing it, this is just the way that we chose. We wanted to leverage the work we had already done, and this seemed like the best way to accomplish that. Beyond that, by leveraging the previous work, actually enabling Federation was really easy for end-user deploying it.
The VMware Ansible for NSX-T modules (found here: https://github.com/vmware/ansible-for-nsxt) should support creation of Global Segments via the Global Manager, but I have not tried it. Specifically, the module you would need to use for that is nsxt_policy_segment.
I hope that helps.
Co-Developer of SDDC.Lab