vra static ip assignment

• VMware Technology Network
• Cloud & SDDC
• VMware Aria Automation
• VMware Aria Automation Tools Discussions
• vRA 8 Set static IP assignment for selectable numb...
• Subscribe to RSS Feed
• Mark Topic as New
• Mark Topic as Read
• Float this Topic for Current User
• Printer Friendly Page

• Mark as New
• Report Inappropriate Content

vRA 8 Set static IP assignment for selectable number of networks

• All forum topics
• Previous Topic

View solution in original post

Nuggets of virtualisation, orchestration, automation and monitoring knowledge

Vrealize automation – customizing ip assignments with vro.

Today I thought I’d get back to vRealize Automation 8, in particular leveraging extensibility. Previously I have shown some examples of breaking out of the provisioning lifecycle to perform some external operations (CMDB updates etc.) however this time I want to look at how you can augment the provisioning process with information from external systems.

Note that much of this article is applicable to vRA Cloud (minor differences for authentication into vRA 8 etc.).

The Scenario

I’m going to use a very common scenario in this article, using an external system to retrieve some custom IP details that can be fed back into vRA (Cloud or 8) to override/supplement the information auto calculated by the vRA system.

It is important to note that there are other ways to achieve this goal that do not require vRO including:

• ABX with IPAM plugin
• Prompting for user info mapping directly to YAML blueprint constructs

However, what if you need the update to be done automatically without the user specifying IP information. Maybe the information the user provides can be combined to fetch an IP address from a 3rd party system (i.e. searching against a number of machine properties/capabilities that match your IPAM system). This is when ABX (without IPAM plugin) or vRO can be used.

In this scenario I am going to use vRO, purely because I can re-use some of my existing code.

Identifying The Correct Lifecycle State

In previous versions of vRA (7.x) there were a few ways of approaching this issue. One example was to front the whole request process via XaaS and custom workflows so that the IP information could be calculated way before vRA ever requested a machine to be provisioned. Event Broker Subscriptions could also be used.

With vRA 8/Cloud, using Event Broker Subscriptions is the go to method however things are not all as they used to be in 7.x. For a start the lifecycle event topics are different. In 8/Cloud there is a new topic called “Network Configure”. This is specifically for handling network configuration during the compute allocation process.

When Does This Event Fire?

Before you get to the point of coding workflows or ABX actions you need to understand when vRA generates the “Network Configure” event and what information the event contains in varying situations.

Here is a screenshot of an example blueprint I will use to illustrate things. It contains one existing vSphere network with 2 types of vSphere machines attached. The first type can have a quantity of one or more, the second type is fixed at a single VM.

When a user requests a deployment from the above blueprint my “Network Configure” event will fire multiple times, once for each machine type in the blueprint. It’s important to understand this, it is NOT once for each machine to be built!

The payload in the event for the first machine type will contain details of all the machines to be created for that type (1 or more) with the payload in the event for the second machine type only containing the details of the fixed one machine.

Planning The Workflow

Before you start writing code it’s always a good idea to create a conceptual view of how an orchestrated process will look. This gives you the opportunity to plan out code functions you may need to write, integration points as well as identify actions/workflows that already exist that you can re-use.

The key areas I have identified are:

• Payload processing
• Authentication
• Fetching network data
• Requesting IP addresses (from somewhere)
• Returning info to vRA

Putting this into a flow allows me to fine tune this list and organize into my perceived correct processing order, also identifying anything that I can re-use from other work. In my case I have at least one action I can re-use from other extensibility work.

The next step is to examine what data vRA is going to provide me. I need to make sure I am going have all the information I need to request IP addresses from the right network and have other data I need such as hostnames used to register DNS records etc. The best place to start is the schema of the event topic. I have circled a number of items in the schema that might prove useful to my workflow.

Not all of the above data will be provided when an event occurs. Some of these properties will be things that I can return to vRA to influence configuration only. Unfortunately the schema doesn’t differentiate between input and output so some experimentation is required.

A good starting point is to log everything in a simple workflow that cycles through each payload property and logs all values. In this example my workflow is taking an input properties object called “inputProperties” which is populated when vRA triggers the workflow.

The output looks as follows. Now I know what information I have to use for my workflow.

The output doesn’t contain any network names but it does contain the network profile ID and the network selection ID. These are the internal vRA ID’s which I should be able to use in API calls to vRA to extract more information. The externalIds property is holding VM names so that will also come in useful.

Constructing The Workflow

Now that I have some useful information to base my workflow on I can start putting everything together.

I’m going to start with authentication. I need to extract more information out of vRA than the event payload provides so this means I will need to get vRO to authenticate into vRA. I have a previous vRO action I used for vRA Cloud to do this however this relied on exchanging an API token created in the vRA Cloud UI for a Bearer Token. With vRA 8 an API token cannot be created so I need another method. Thankfully the vRA 8 API provides an API call to login with a username/password combo and return the Bearer Token. Here’s my code:

Next I need some code to extract data from the event payload. Remember I am following the order I laid out in my conceptual diagram.

The payload contains a multi-dimensional array containing the network selection IDs for all VMs covered by the payload. All of my machines have one network adapter and are attached to the same network so I have statically set this extraction to [0][0][0] rather than doing anything more complex. You may need to enhance this depending on your blueprint configuration.

Now that I have the network selection ID I can use this to fetch the details that relate to this ID. There are 2 types of network in vRA, an IaaS network and a fabric network. The IaaS networks are those that are discovered by vRA when a Cloud Account is added (and are displayed under “Resources > Networks”) where as a fabric network is an IaaS Network within a Network Profile. The network selection ID within the event payload relates to a fabric network.

Once I have the network details as a string from the above action I can then extract the data that I need from it. In my case I have no actual 3rd party IPAM solution in my environment but I am assuming having the name of the network and it’s CIDR would give me all the info I need to locate the network in an IPAM system and request a IP address.

I’m not going to cover requesting an IP address from the IPAM system for obvious reasons so next I am going to construct the return object that will be fed by to vRA as the output of the workflow. A key difference between old vRA and vRA 8/Cloud here is that the return object is not a single complex properties object that you fill with all the schema updates you require. In the new world each schema property you wish to return must be an individual workflow output.

As I’m returning IP addresses I need to construct the “addresses” output object. Referring to the schema I can see that it’s a 2 dimensional string array. Here, I have initiated the array and pushed 2 string arrays into it. Each string array contains an IP address I wish to use.

This is obviously hard-coded as an example and would only work if the user has requested 1 or 2 of a particular component in my blueprint. For something more dynamic you would process the externalIds in the input payload and fetch the corresponding number of IP addresses before assembling the addresses array with the correct data.

Note: The order that the addresses array should be populated in would be the same order as the machine names in the externalIds array are provided. If the input array contains VMs in the order “VM1, VM2, VM3” then the order you populate the addresses array would be “VM1, VM2, VM3”.

I hope this has given you an insight into performing some vRA extensibility that involves manipulating vRA.

Share this:

2 thoughts on “ vrealize automation – customizing ip assignments with vro ”.

Pingback: vRA 8 and phpIPAM - Jesse Boyce

Pingback: vRA 8.3 IPAM integration using phpipam and ABX – Part 1 | Micronauts

Comments are closed.

• Already have a WordPress.com account? Log in now.
• Follow Following
• Copy shortlink
• Report this content
• View post in Reader
• Manage subscriptions
• Collapse this bar

You are using an outdated browser. Please upgrade your browser to improve your experience.

In vRealize Automation , cloud administrators can view and edit the network resources that have been data-collected from the cloud accounts and integrations that are mapped to your project.

After you add a cloud account to your Cloud Assembly infrastructure, for example by using the Infrastructure > Connections > Cloud Accounts menu sequence, data collection discovers the cloud account's network and security information. That information is then available for to use in networks, network profiles, and other definitions.

Networks are the IP-specific components of an available network domain or transport zone. If you're an Amazon Web Services or Microsoft Azure user, think of networks as subnets.

You can display information about the networks in your project by using the Infrastructure > Resources > Networks page.

• Networks and load balancers that are defined externally in the network domain of your cloud account, for example in vCenter , NSX-T , or Amazon Web Services .
• Networks and load balancers that have been deployed by the cloud administrator.
• IP ranges and other network characteristics that have been defined or modified by your cloud administrator.
• External IPAM provider IP ranges for a particular address space in an provider-specific external IPAM integration.

For more information about networks, see the following information, signpost help for various settings on the Networks page, and Learn more about network profiles in vRealize Automation .

vSphere networks, regular NSX networks, and global (federated) NSX networks are supported.

You can view and edit networks and their characteristics, for example to add tags or remove support for public IP access. You can also manage network settings such as DNS, CIDR, gateway, and tag values. You can also define new, and manage existing, IP ranges within a network.

For existing networks you can change the IP range and tag settings by selecting the network's checkbox and selecting either Manage IP Ranges or Tags . Otherwise you can select the network itself to edit its information.

Tags provide a means for matching appropriate networks, and optionally network profiles, to network components in cloud templates. Network tags are applied to every instance of that network, regardless of any network profiles in which the network may reside. Networks can be instanced into any number of network profiles. Regardless of network profile residency, a network tag is associated with that network wherever the network is used. Network tag matching occurs with other components in the cloud template after the cloud template has been matched with one or more network profiles.

Machine tags are defined in the cloud template and apply to the machine if deployed to a vCenter . Machines that are connected to an NSX-T local manager or global manager are also tagged in the cloud template. Note that machine tagging is different than machine NIC (network interface) tagging.

NSX-T global networks are networks that are defined by the NSX-T global manager and apply to one or more NSX-T local managers. For global networks, existing and public networks are supported for NSX-T global manager and local manager cloud accounts and the vCenter cloud accounts that are associated to the local managers. Local manager representation of stretched networks is defined within a transport zone. The transport zone is an NSX-T local manager construct that defines the span of NSX-T networks for vCenter Server hosts and clusters.

Cloud Assembly enumerates, or data collects, existing and public networks. You can create a global network by adding an existing or public network on an NSX-T global manager. The global network can then be consumed by all the associated local managers. Global networks can span one, all, or a subset of the associated local managers.

You can provision a machine on a global network by using a static IP assignment. DHCP is not supported.

• Overlay - an overlay network is associated with a Tier-0/Tier-1 local manager and automatically stretches to all the sites connected to the Tier-0/Tier-1 local manager. For each local manager, the default overlay transport zone is used.
• VLAN - a VLAN network applies to a single local manager and the transport zone can be manually selected.

Global networks are listed on the Infrastructure > Resources page with all the cloud accounts that they apply to.

• Reconfigure a network in a cloud template definition from a global network to a local network and vice versa.
• Scale-out/scale-in of machines on global networks.

For more information about using global networks in cloud templates, see More about network resources in vRealize Automation cloud templates .

You can provision NSX-T VLAN segments by specifying one or more VLAN IDs on a private NSX network type. Use this technique when, for example, your overall design prohibits you from provisioning overlay networks on NSX-T . This option requires that you select a VLAN transport zone in a supporting network profile.

When using non-federated networks, you can provision private NSX on-demand VLAN segments when the network segments are used with a Policy API-type of NSX-T cloud account. VLAN segments are not connected to a Tier-1 router, therefore only private networks support VLAN segment specification. Once created, VLAN segments that are provisioned by vRealize Automation can also be used as existing networks in other VMware cloud templates.

To use VLAN segments, you must first configure the intended network profile to allow subnet isolation for the on-demand network. You must specify a VLAN transport zone in the network profile. If you specify an overlay transport zone, the network profile cannot be used for VLAN specifications. An example of VLAN transport zone selection in a network profile is shown below. For related information about configuring network profiles, see Learn more about network profiles in vRealize Automation .

You specify one or more VLAN segments, or arrays of VLAN IDs, by using the vlanIds property in the Cloud.NSX.Network component in the VMware cloud template YAML. To specify multiple vlanIds values in the private network Cloud.NSX.Network component, use a separate row entry for each value. The vRealize Automation API requires that you specify multiple VLAN values in a comma-separated list, but using that format in the cloud template YAML is unsupported. The supported VLAN values range between 0 to 4094. For sample cloud template YAML code, see Networks, security resources, and load balancers in vRealize Automation .

Use an IP range to define or make changes to the start and end IP address for a particular network in your organization. You can display and manage IP ranges for listed networks. If the network is managed by an external IPAM provider, you can manage IP ranges in connection with the associated IPAM integration point.

Click New IP Range to add an additional IP range to the network. You can specify an internal IP range , or if there is a valid IPAM integration available you can specify an External IP range .

You cannot include the default gateway in an IP range. The subnet IP range cannot include the subnet gateway value.

If you are using an external IPAM integration for a particular IPAM provider, you can use the External IP range to select an IP range from an available external IPAM integration point. This process is described within the context of an overall external IPAM integration workflow at Configure a network and network profile to use external IPAM for an existing network in vRealize Automation .

vRealize Automation allows you to apply and manage an IP address range across multiple vSphere and NSX networks. Shared IP range support is provided for both internal and external IPAM. You can set a single IP range on an NSX stretch network such that machines on that network can use IP addresses that are assigned from the single IP address even if they are deployed to different vCenters.

IP Addresses

You can see the IP addresses that are currently used by your organization and display their status, for example available or allocated . The IP addresses that are displayed are either IP addresses that are managed internally by vRealize Automation or IP addresses that are designated for deployments that contain an external IPAM provider integration. External IPAM providers manage their own IP address allocation.

If the network is managed internally by vRealize Automation , and not by an external IPAM provider, you can also release IP addresses.

• During the release timeout period, relevant IP addresses are listed as released. When the release timeout period has expired, they are listed as available.
• The system checks every 5 minutes for newly released IP addresses, so even if the release timeout value is 1 minute it can take between 1 and 6 minutes for released IP addresses to become available, depending on when the last check was run. The 5 minute checking interval applies to all values other than 0.
• If you set the release timeout value to 0, IP addresses are released immediately and become available immediately.
• The release timeout value applies to all cloud accounts in the organization.

Updating vSphere networks after NSX migration to C-VDS

For information about updating vSphere networks in vRealize Automation after NSX-T migration from N-VDS to C-VDS, see Updating networking resources in vRealize Automation after N-VDS to C-VDS migration in NSX-T .

Load Balancers

You can manage information about available load balancers for the account/region cloud accounts in your organization. You can open and display the configured settings for each available load balancer. You can also add and remove tags for a load balancer.

For more information about using load balancers in cloud templates, see More about load balancer resources in vRealize Automation cloud templates .

Network Domains

The network domains list contains related and non-overlapping networks.