Automating syslog configuration on NSX

If you’re here, you’ve probably already found VMKB2092228 and been frustrated by the lack of an easy and consistent way to configure all the NSX components to send log data.  Me too.

I put together a vRO workflow to help configure (and reconfigure) syslog on NSX.

1. It prompts for the NSX manager connection info and Syslog server info
2. Creates a REST host for the NSX manager using the admin super-user account
3. Adds several REST operations to the NSX Manager REST host
4. Deletes and readds the syslog configuration on the NSX Manager
5. Optionally configures Activity Monitoring on the NSX Manager
6. Identifies each running Controller; deletes and readds the syslog config on each
7. Identifies each deployed and “Green” Edge (including DLRs); deletes and readds the syslog config on each
8. Removes the NSX Manager REST host created earlier

Notes

• It must use the NSX Manager admin account – it’s the only superuser account that can update teh manager config.
• If a Controller is not running when the workflow runs, its syslog config will not be updated
• If an Edge’ state is not “green” or is not fully deployed, its syslog config will not be updated
• REST-HTTP plugin for vRO is required
• Tested with vRO 6.0.2 and NSX 6.2.1

1. Get the package Download Here
   

   By downloading any code, package or file, you acknowledge that:There is no explicit or implied warranty or support for the code.  Neither Brian Ragazzi, his employer nor anyone else is responsible for any problems, errors, omissions, unexpected behavior, breakage, trauma, outage, fatigue, lost time, lost work or incontinence that may occur as a result of using the code or package.

2. Import package into vRO
3. Run the ConfigureSyslogNSX workflow

   

   Workflow Step 1

   

   Workflow Step 2

Advertisement

Setting the Machine Name of a vCAC-provisioned VM using vCO

This is a follow-up to the series of posts named “Setting the Machine Name of a vCAC-provisioned VM to comply with a Corporate Standard“. In this case, I wanted to use vCenter Orchestrator instead of Powershell to generate the name from the component values.

For this sequence, we’ll still use part 1 to set up the Build Profile and Property Dictionary, but these steps will replace part 2 and some of part 3.

Review

Recall that for this example, the name should use the initials of the Business Group, “V” for Virtual, a single letter for the OS (“W” for Windows, “L” for Linux, “S” for Solaris, “O” for other), a three character “role” and a two digit sequence number for uniqueness.

Example Naming convention:
BG1VWAPP14
BG1 = Business Group initials
V = Virtual
W = Windows
APP = APPlication server
14 = Sequence number

vCenter Orchestrator Workflow

1. Create a Folder for your workflows outside of the “Library” and other folders
2. Inside this folder, create a new workflow.  I named mine “vCAC.MachineName“.  The workflow will be opened for editing.
3. Navigate to the “In” tab, add this attribute
   

   Name	Type	Value	Description
   CharacterToReplace	String	–	What Character in the original name will be replaced

4. Navigate to the “Inputs” tab, add these Parameters:
   

   Name	Type	Description
   OriginalName	string	ex: SUP-02
   OperatingSystem	string	ex: Windows 2008 R2
   Role	string	ex: SQL

5. Navigate to the “Outputs” tab, add this Parameter:
   

   Name	Type	Description
   newMachineName	string	Name created from component values

6. From the “Generic” pane, drag the “scriptable task” item to the blue arrow.

   

   Default schema

7. Mouseover the scriptable task item in the schema and click the Pencil icon to edit the item

   

   Edit the Scriptable Task

8. On the “IN” tab of the scripting task properties, click the “Bind to workflow parameter/attribute” button to add these parameters:

   

   Scriptable Tasks IN Parameters

9. On the “OUT” tab of the scripting task properties, click the “Bind to workflow parameter/attribute” button to add these parameters:

   

   Scriptable Tasks OUT Parameter

10. Open the Schema tab of the Workflow.
11. Paste the following:
    

    
var OS;
OS="O" //"O" not zero, for "Other"
OperatingSystem = OperatingSystem.toUpperCase();
if (OperatingSystem.search("WIND")> -1) {OS="W"};
if (OperatingSystem.search("RHEL")> -1) {OS="L"};
if (OperatingSystem.search("SLES")> -1) {OS="L"};
if (OperatingSystem.search("SOLA")> -1) {OS="S"};
Role='V'+OS+Role.substring(0,3); //"V" for Virtual
newMachineName = OriginalName.replace(CharacterToReplace,Role).toUpperCase();


    I’m not much of a javascript coder, so this is probably not the best way to write this. But, it worked for me. Close the scriptable task editing window.

12. Back on the Schema tab of the workflow, let’s test our code. Click the “Run” button, enter some values in the fields and click submit.

    

    Test Run workflow

13. When the workflow finishes, check the Variables tab on the right to confirm that the newMachineName parameter has the expected value.

    

    Resulting newMachineName

14. If satisfied, click “Save and close” to save your new workflow

vCAC Workflow

There are only two changes to be made from the steps outlined here.  The first is in Step 3, instead of using a variable named “PowerShellOutVar“, we’re just going to name it “OutVar” for obvious reasons.  The second change is a replacement of step 7, do this instead:

• From the DynamicOps.VcoModel.Activities toolbox, drag “InvokeVcoWorkflow” to the designer.

  

  InvokeVcoWorkflow

• Click the ellipsis button to  display a list of the workflows in vCO, select the workflow we made earlier (vCAC.MachineName in this case).  Note that you can filter on the Folder to make it easier to find.
• Set the parameters
  

  Direction	Name	expression/value
  Input	OriginalName	vmName
  Input	OperatingSystem	vmwareOS
  Input	Role	machineRole
  Output	newMachineName	OutVar

  

  Variables & Parameters

• Continue with the remainder of the steps, remembering that when you link it up in step 12, you’ve replaced “InvokePowerShell” with “InvokeVcoWorkflow“

Good luck!