Partnering NSX with vRealize Automation creates some really intriguing possibilities when you look at taking tasks that a 3rd tier engineer would typically do, and being able to create a workflow that places a tight enough box around the task that a 1st or 2nd tier worker can complete the same task, in less time. This free’s up your 3rd tier engineers to focus on the real complex tasks.
From personal experience, tasks like VLAN creation in the physical network realm have always taken a long time to complete. Physically logging into switches, tagging/trunking VLANs, bringing interfaces up, replicating those changes across firewalls…its always been a very manual process. Manual processes are prone to human error. Human error is bad. Human error creates rework. Nothing good can come of this.
In this post, we’ll go through a simple workflow example that allows us to take a network, plug it into an XaaS (Anything as a Service) workflow, and create a usable subnet in NSX out of it. This will in turn create a Virtual Wire in vCenter for us to consume. Furthermore, we’ll also bring the IP interface up, so that our OSPF configuration within NSX will start broadcasting the route - making it available to end users. With no firewall rules setup for it, it’ll be caught by our default denies - so security is maintained. The end result is a task that may have taken 2 weeks before, taking minutes with our workflows!
Lets get to it! This blog post assumes that you’ve already added your NSX manager(s) to your vRealize Orchestrator installation, and that your plugins are functional. You can check this by going to your plugins tab, and expanding the NSX section
Let’s pop over to our Workflow Tab and create a new workflow. I’m to name it “Create NSX vWire / Add to Interface”
It’s a good time to mention, that when you leverage NSX within vRealize Orchestrator, you get all of these really cool workflows that you can build bigger workflows out of. We’re going to make use of this, and make our job a lot easier. There are 2 workflows we’re going to consume within our “new” workflow, these are “Create Logical Switch” and “Connect Logical Switch to Router”.
You might be thinking “Wait…that’s it? This was a waste”. Nay sir. There is very much more to this. These workflows exist, but require inputs. The inputs aren’t the most user friendly. An administrator in the platform could put it together - but we’re trying to make this easy here!
Let’s go ahead and drag these workflows out onto our vRO canvas so we can see what we’re working with. We’ll highlight the first of the 2 workflows, “Create Logical Switch”
Creating Our Logical Switch
We notice a couple of items right away:
- vRO wants us to add the activities parameters to the current workflow
- When we select the “in” tab (expected input parameters), there’s some confusing stuff being asked of us.
In its current state. The workflows clearly not usable. We have 2 choices. Either we build logic to support providing these inputs within vRO, OR we create real inputs and ask the user to enter them. The answer is both. Lets talk about each of these items:
- connection- Relates to the NSX manager connection. We have 2 NSX managers, so we’ll create a scriptable task that switches between them based on what Data Center the user is selecting. In the interest of simplicity, we’re going to assume the user is NOT using Universal Networks to stretch VXLANs across data centers.
- scopeid- An NSX term for the ID of the Transport Zone. In our lab, we’re only using 1 Transport Zone. This is an easy one, we’ll use an attribute for this one.
- logicalSwitchName - Cmon, really?
- description - Again?
- tenantId - Another NSX term relating to the actual ID of the “tenant” system. This one isn’t even required. We’re going to nuke it.
We’re going to breeze through this next part pretty quickly. We need to build a “scriptable task” to support switching between 2 datacenters. Below you can see a screenshot of the final product.
There’s a lot happening in these 7 lines.
- We’ve created our first Inputs in this workflow. Since we have 2 Sites, we need to be able to switch between the 2 of them pretty easily. To facilitate this, we’ve created the “Site” input as a string, and are using an if/then statement to switch between the 2.
- Server.findForType - Learn it, love it, use it. We’ve created an “nsx” output that is a “NSX:Connection” type, we then use vRealize Orchestrator native code to parse through all of the NSX Managers to find one with a matching GUID. We got these GUIDs from the NSX Plugins screen.
- Finally, once we’ve determined the NSX manager we’re using - we’re building our standardized logical switch name (logicalSwitchName, clever huh?). We created 2 more inputs to support this, which will also be used later. Name, and the network address. We want out Virtual Wires to be easily identifiable to what network they support. We’re creating these all as /24’s, so we tack that on too. We take this variable, and turn it into an Output, as a String attribute. You actually have to bind it though, which I didn’t do in the screenshot above.
Your inputs and attributes should match what I have below
At this point we’ve handled our “switching” between NSX managers. We also have inputs for our network address, and our Network name. So much progress. Lets see what we can bind to our first imported workflow item, Create Logical Switch.
Using the visual bindings screen, we can setup which Outputs/Inputs/Attributes will feed into the next workflow.
Hmm. Not phenomenal progress. This far in and we’ve only got 2? Lets fix that. We know the tenantId isn’t needed so we’ll destroy it, and scopeId is static. Description is also just a free text entry, lets fix those. We’ll create an attributes for our scopeid, and an input field for Description. Things are looking much better now.
We’ll bind the tenantId to null since the workflow requires it to be bound to something.
At this point, if we didn’t have the second workflow in here - we could actually run this with the data plugged in, and it would go ahead and create a logical switch for us on our transport zone. It wouldn’t be attached to a Distributed Logical Router (DLR), so it woulnd’t have an interface, subnet, or anything fun - but we would at least have SOMETHING functional.
We’re going to create an output attribute thats a “NSX:VirtualWire” type, act as an output for the logicalSwitch result from this workflow. It’s going to be piped into the later workflow.
Creating the Interface and Attaching to the Router and Switch
When we look at this workflow, we can see there’s a lot of information it needs. Some of this is really though - and we’ve already built!
- connection - We got that :)
- routerId - This is the ID of the actual logical router in NSX. We’ll get that from the plugin.
- logicalSwitchID - This is a property of our logical switch “Output” object we created earlier, we can use native vRO functions to pull that value out
- primaryIpAddress - This is our default gateway. We’re always going to use the .1 address, but we’ll make this an input field anyways
- subnetMask - Were doing all /24’s so we can set this as an attribute to enforce it - obviously this isn’t scalable in an enterprise, but I’m a small blog with small dreams, sue me.
- routerInterfaceIndex - A router can have many indexes, this isn’t required, so we’ll null it out.
- routerInterfaceType - NSX can have internal and uplink interfaces. Internal interfaces are for VXLANs typically, uplink interfaces are connecting into other infrastructure, like an Edge Services Gateway (ESG) or uplinking to your physical infrastructure. We’re automating internal interfaces, so we’ll make an attribute with that.
We drag another “scriptable task” into the vRO canvas and begin our work…
We have a couple of IDs we need to pull out of the logical switch, so we’ll small vRO call to pull this out, and then send it as an “output”. We’ll need to bind the logical switch object to this scriptable task via the “In” tab in order to make it work. Here’s a screen shot of the final product.
We’re also going to add those attributes I told you about before…see below for the new attribute list
And our new Inputs
Finally our bindings again
Running Your Workflow
At this point, when you look at our workflow in the vRO screen, you can click validate and you will notice there shouldn’t be anymore errors. The workflow is ready to run.
A few things to think about…
- Theres no error handling. If someone puts in invalid values, it will create the switch and leave it there…maybe you should create a catch for if it fails, to clean up after itself?
- Everything is a type in input. Maybe you should play with the vRO Presentation to make it cleaner?
- Manual input of the subnet is scary, maybe defining out a list in a SQL table, and piping that list in for a selection would be a better idea?
- Renaming your workflow items that are within the canvas can make it clearer what each step is doing. Do this. Its smart.
- Save you work, and use vRO’s native versioning to keep track of your own changes!
Here’s an example of a more fleshed out and complete version of this workflow…