Ansible SDDC Demo Video

Following on the heels of the release of the VMware SDDC Ansible roles inside the Virtual Elephant GitHub space, here is a recording of several of the roles being leveraged to deploy and configure a set of ESXi nodes (advanced settings, DVS and VMkernel configuration) within a vCenter cluster, deploy an NSX-v Manager through ovftool and the deployment of the NSX-v Controllers.

To avoid any copyright issues, there is no sound or music playing in the background. The video was recorded and then time-lapsed to make it a quick-view of the deployment. Deploying the NSX-v Manager and Controllers were the longest-running tasks, but in it’s raw form the demo video was just under 30 minutes to perform all of the tasks you see in the video.

Leveraging Ansible can greatly enhance and reduce the time it takes a vSphere Administrator to deploy a VMware SDDC environment!


Ansible Roles for VMware SDDC Deployments

I’ve been excited for weeks now as I prepped for VMworld 2018 in Las Vegas and anticipating being able to talk more about leveraging Ansible to deploy and operate a VMware SDDC environment. As you can tell from my recent posts, I am heavily involved in automation using Ansible, both within my side projects and as a practicing architect at VMware. As an internal team, we are working hard to improve and enhance several of the upstream Ansible modules, and I hope to be able to share those externally in the future as they are contributed back.

In my spare time, I’ve been working the lab to provide a set of Ansible roles that anyone can leverage to configure ESXi hosts, deploy and configure a vCenter Server Appliance (VCSA), and deploy and configure NSX-v within their environments. I am happy to announce the initial release of these roles in the Virtual Elephant GitHub space.

The following roles have been published within the space and are operational:

  • esxi-adv-settings – Configure advanced ESXi settings on an ESXi node
  • esxi-host-config – Configure DNS, hostname and NTP settings on an ESXi node
  • esxi-services – Configure ESXi services on an ESXi node
  • esxi-vmk-interfaces – Create/delete VMkernel interfaces on an ESXi node
  • nsxv-cluster-prep – Prepare vCenter cluster for NSX-v
  • nsxv-controllers – Create/delete NSX-v controllers
  • nsxv-license – Assign NSX-v license
  • nsxv-logical-switch – Create/delete NSX-v logical switch
  • nsxv-manager-config – Configure NSX-v Manager
  • nsxv-manager-deploy – Deploy NSX-v Manager OVA to vCenter Server
  • nsxv-manager-roles – Configure NSX-v Manager user roles
  • nsxv-transport-zone – Create/delete NSX-v transport zone
  • vcenter-add-hosts – Add or remove ESXi nodes to vCenter Server
  • vcenter-cluster – Create/delete/modify vCenter cluster
  • vcenter-datacenter – Create/delete vCenter datacenter object
  • vcenter-maintenance-mode – Manage the maintenance mode state of an ESXi node
  • vcenter-networking – Create/delete DVS
  • vcenter-portgroups – Create/delete port groups

Wherever possible, each role has been written to allow the creation, deletion or modification of said objects within the SDDC environment.

In addition to the roles themselves, there are published playbooks that execute the roles in a specific order, based on dependencies, to perform the actual deployment of the SDDC environment.

  • esxi_sddc_configure.yml – Configure ESXi nodes
  • nsxv_sddc_deploy – Deploy and configure NSX-v Manager and controllers

If you are looking to start leveraging Ansible to deploy and manage your VMware SDDC environments, these roles are a great starting point. Reach out to me over Twitter, or come find me this afternoon in the VMware {code} Theatre at 1:00PM.



Updated Ansible Control Server Docker Container

The Docker container I built earlier this year, when I embarked on the Infrastructure-as-Code project, has been taken and used as the base container for the internal project to automate the SDDC using Ansible. As such, most of the recent updates I have made to the container have been only published internally. I decided to spend a few minutes updating the container on the public side to take advantage of some of the improvements and changes made.

An important note, the container is not what I would call lightweight. It is intended to be used as a development container, where it can provide a base-level of libraries and binaries for running Ansible against a vSphere, vCenter or NSX-v endpoint.

The first major change I’ve made is to move where the repo lives in GitHub. I’ve broken out the repository from the virtualelephant/vsphere-kubernetes repo and placed it in the virtualelephant/containers repo (link here).

Running the container

The default CMD of the container will display the installed version of Ansible and default version of Python.

The container continues to clone several useful community Ansible modules, including vmware/nsxansible and OpenShift/ansible-ansible-contrib. I have modified the Dockerfile to copy these modules into the directory /opt/ansible/modules. The ansible.cfg file has been modified to leverage the new module location.

Another change is how the container is pulling the nsxraml spec and making it available. The container currently pulls down both the NSX-v 6.3 and 6.4 branches of the nsxraml spec and places them in /opt/nsxraml. The specs should be backwards compatible, however it is possible some future version will not be. Therefore, I have created a symlink in the container that will always point to the most recent version of the RAML spec, while leaving the other branches there in case a consumer of the container requires them.

How is this leveraged?

Well, within my Ansible dictionary variable for the nsxmanager_spec, I always point the RAML file to /opt/nsxraml/current/nsxvapi.raml.

Finally, the container includes clean-up of the git repositories reduce its size.

Learn More at VMworld

If you are going to be at VMworld, be sure to VMware {code} session  CODE5542U on Monday afternoon. I will be talking more about the internal Ansible project and will have some exciting news regarding new Ansible modules available to VMware users!

Otherwise, feel free to pull the container or the repo and leverage it based on your needs!


VCDX Quick Hit: Convey Credibility

A few months ago I participated in a ‘Trusted Adviser’ training internally at VMware. The focus of the seminar was to help us learn how to become a trusted adviser with a customer with little or no previous contact prior to the engagement. During the seminar a few things stood out as relating to the VCDX certification and defense. Similar to how we strive to become trusted adviser’s to our customers when we have an engagement, the role of a VCDX candidate (in part) is to convey credibility to the member of the panel.

be in command of the content

Whether you are defending an architecture you designed entirely on your own or worked on as part of a team, being in command of the content is a key factor in successfully defending it in front of the panel. During the defense, you should demonstrate to the panelists that no one understands the design better than you. This is especially important if you did work on the design as part of a team — you are expected to know every facet of the design, the reasoning behind all of the design decisions made, the risk and implications introduced as if you had been the sole architect working on the project.

Demonstrate to the panelists you are the authority on the design.

Being able to effectively communicate this authority, clearly and concisely, will come as you practice your initial 10-15 minute presentation over and over again leading up to the defense itself. Critically assess your design prior to the defense by anticipating areas where the panelists may have questions or where you believe the design could have been improved if the requirements or constraints of the design had been different.

be honest and believable

This might seem trite, but being honest during your defense is critical. It is okay to not have an answer for every question the panel asks you. We talk about this during the VCDX workshop, responding to a question with “I don’t know” or “I would need to investigate that further” is an adequate occasional response. Explain what you do know or understand about the question and then move on. Generally speaking, people (and the panelists are people) can tell when a person is being deceptive within a few minutes time.

Just be mindful of how often “I don’t know” is your answer — see above about commanding the content.


The VCDX defense day is relatively short compared to the number of hours invested in the process of becoming a VCDX candidate invited to defend. However, in that limited time you need to be consistent in your messaging and reasoning behind the design decisions you made in your design and during the design scenario. Our previous experiences have a direct impact on how we address requirements, constraints and risks inside our designs.

These experiences are different for each architect, however they are what make up our core beliefs. Be consciously aware of what your core beliefs are and let them shine through to the panel by being consistent during your defense.

be concise

Similarly to the first point, adequate preparation prior to the defense should include anticipating areas of the design where the panelists may pose questions. When answering a question posed by a panelist, be concise in your answers, avoid tangents or repeating the question back to the panel. Time is limited and having concise answers prepared for the potential questions, will help you manage the time.

Remember (generally) the more questions you can be asked and answer, will increase the probability of receiving a passing score and earning the VCDX certification.

For any potential VCDX candidates, I hope these personal insights will be helpful to you on your journey towards earning the VCDX certification.

NSX Ansible Module Update – nsx_manager_syslog




I alluded to this post yesterday on Twitter, and after committing the code early this morning to the upstream repo on GitHub, here it is!

Similar to how the configuration of the user roles in NSX Manager were initially being done using the Ansible URI module, the configuration of the remote syslog server as utilizing the same method. The code originally looked like this:

 43 - name: Set syslog configuration on NSX Manager
 44   uri:
 45     url: "https://{{}}/api/1.0/appliance-management/system/syslogservers"
 46     method: PUT
 47     url_username: "{{ nsxmanager_spec.user }}"
 48     url_password: "{{ nsxmanager_spec.password }}"
 49     headers:
 50       Content-Type: "application/json"
 51       Accept: "application/json"
 52     body:
 53       syslogServersList: '[{"syslogServer": "{{ syslog_server }}", "port": "514", "protocol": "UDP"}]'
 54     body_format: json
 55     force_basic_auth: yes
 56     validate_certs: no
 57     use_proxy: no
 58     return_content: yes
 59   tags: nsx_syslog_enable
 60   delegate_to: localhost

This worked and the configuration was updated accordingly. However, I wanted to expand the NSX Ansible module to include this functionality natively. Fortunately, the definition exists within the NSX RAML file and writing a small amount of Python code was a very easy lift.

 5961   /system/syslogserver:
 5962     displayName: systemSyslogServer
 5963     description: |
 5964       Working With Syslog Server
 5965       -----
 5966     get:
 5967       displayName: systemSyslogServerRead
 5968       description: Retrieves only the first syslog server among the servers configured.
 5969       responses:
 5970         200:
 5971           body:
 5972             application/xml:
 5973               example: |
 5974                 <syslogserver>
 5975                   <syslogServer></syslogServer>
 5976                   <port>514</port>
 5977                   <protocol>UDP</protocol>
 5978                 </syslogserver>
 5979     put:
 5980       displayName: systemSyslogServerUpdate
 5981       description: Configures one syslog server. If there are syslog server(s) already configured, this API replaces the first one in the list.
 5982       body:
 5983         application/xml:
 5984           example: |
 5985             <syslogserver>
 5986              <syslogServer>name-2</syslogServer>
 5987                 <port>port-2</port>
 5988                 <protocol>protocol-2</protocol>
 5989             </syslogserver>
 5990           schema: systemSyslogServerUpdate
 5991     delete:
 5992       displayName: systemSyslogServerDelete
 5993       description: Deletes all the syslog servers.

The module is now available in the master branch on GitHub.

The module will work with NSX-v versions 6.4 and lower. To leverage the module within an Ansible playbook or role, the following code example can be used:

  1 ---
  2 - hosts: all
  3   connection: local
  4   gather_facts: False
  6   tasks:
  7     - name: Configure NSX Manager syslog
  8       nsx_manager_syslog:
  9         nsxmanager_spec: "{{ nsxmanager_spec }}"
 10         state: present
 11         syslog_server: "{{ syslog_server }}"
 12         syslog_port: "{{ syslog_port }}"
 13         syslog_protocol: "{{ syslog_protocol }}"
 14       register: nsxv_syslog

It important to note that in NSX-v 6.4, an additional syslog API call was added that supports setting multiple syslog servers within the NSX Manager. The module above, supports the API call that only modifies a single syslog server. I will likely be adding support for the additional API call in the near future, in the meantime this module can be leveraged to configure syslog on your NSX Managers.