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.


NSX Ansible Module Update – nsx_manager_roles

As the previous post discussed, using the API directly through Ansible was an adequate initial step to configuring a users role within the NSX Manager. The next logical step was to include this functionality directly inside the upstream NSX Ansible module.

After an initial commit yesterday afternoon, I received some feedback from the community and posted a new update to the module today that is better inline with Ansible best practices and idempotency.

The module is now available in the masterbranch on GitHub.

The module can be used inside an Ansible role or playbook with the following code:

  1 ---
  2 - hosts: all
  3   connection: local
  4   gather_facts: False
  6   tasks:
  7     - name: Configure NSX Manager roles
  8       nsx_manager_roles:
  9         nsxmanager_spec: "{{ nsxmanager_spec }}"
 10         state: present
 11         name: "{{ nsx_uid }}"
 12         is_group: true
 13         role_type: "{{ nsx_role }}"
 14       register: add_nsx_role

The Ansible task can specify a state of present to add a new user and assign a role, modify to change the role of an existing user or group, and absent to remove a user or group.

If you run into an issues using the module, please reach out to me over Twitter or comment directly in the Issues section on GitHub for NSX Ansible.


NSX Roles Automation through Ansible

This is a bit of a quick hit.

Yesterday, while working with Ansible to fully deploy and configure an NSX-v Manager, we worked out a method to add a user or group of users and assign the appropriate role. The current NSX Ansible module does not support this functionality, so the role we are executing relies on the URI module.

 64 - name: Set NSX Permissions
 65   uri:
 66     url: "https://{{ }}/api/2.0/services/usermgmt/role/"
 67     method: POST
 68     url_username: "{{ nsxmanager_spec.user }}"
 69     url_password: "{{ nsxmanager_spec.password }}"
 70     headers:
 71       Content-Type: "application/xml"
 72       Accept: "application/xml"
 73     body: "<accessControlEntry><role>enterprise_admin</role></accessControlEntry>"
 74     body_format: raw
 75     force_basic_auth: yes
 76     validate_certs: no
 77     use_proxy: no
 78     return_content: yes
 79     status_code: 204
 80   tags: nsx_permissions
 81   delegate_to: localhost

The API call does not return a typical 200 status if the call was successful, so the task above specifies that Ansible should be looking for a 204 status.

I am currently working on adding this functionality to the NSX Ansible module published on GitHub. Time (and testing) allowing, the code will be available in the coming days.


VMworld US 2018 – Session and Schedule

With the VMworld US 2018 conference set to start in just over a month, my schedule is beginning to take shape. 2018 will be my 5th trip to the US show and I am extremely excited to be presenting again on several different stages in Las Vegas!

Sunday – TAM Day table from 4:15PM -5PM

Come find me to talk about the full vSphere SDDC, including NSX-v, NSX-T, vSphere, vCloud Director and/or the VCDX certification.

Monday – VMTN Lounge from 1PM – 1:30PM

Session ID: CODE5542U – Enhancing the SDDC with Ansible

New engineers are often unsure how to contribute to an Open Source project and timid when it is time to make their first merge request. Drawing insight from the recent Ansible automation efforts within the VMware Private Cloud team, learn how to identify areas within an Open Source project where you can contribute using a real-world use-case. In this session, we will walk through the open source Ansible VMware modules leveraged to fully automate the deployment of the software-defined datacenter, including vSphere, vSAN and NSX components. We’ll dive into how gaps in the current Ansible modules were identified and how our engineers were able to begin writing additional functionality and contributing it upstream. The presentation will also highlight how improvements to our own VMware Open Source projects on GitHub can benefit and be leveraged by our customers.

Tuesday – experts bar from 11:3oAM – 1:30PM

Come find me to talk about the full vSphere SDDC, including NSX-v, NSX-T, vSphere, PKS and/or the VCDX certification.

Tuesday – solutions exchange theatre 3:30pm – 4PM

Come learn about how VMware utilizes multiple public cloud providers, in addition to our on-premise clouds, to deliver a memorable VMworld Hands-on-Lab experience each year! I will go over the VCDX methodologies and how they were leveraged to design the Hands-on-Lab architecture.

Tuesday – meet the experts @ solutions exchange theatre from 3:30pm – 4PM

Come find me to talk about the full vSphere stack, including NSX-v, NSX-T, vSphere, PKS and/or the VCDX certification.

thursday – Transformers: How vmware IT transitioned to a services-based organization from 10:30AM – 11:30AM

Session ID: LDT1515PU

Hot on the heels of the digital transformation process sweeping across IT organizations worldwide, the VMware private cloud architects will discuss how they are leveraging their operational experience to propel VMware IT into a services-based organization. As VMware IT has learned, the digital transformation process is less about the technologies adopted and more about the people involved. In order to drive true adoption, the digital transformation starts with strong leadership, but also requires engagement from those closest to the consumers. Come discover how to drive your organization’s digital transformation initiatives and gain true adoption from a technical practitioner’s perspective. Challenges and lessons learned will also be covered.