Configuring and licensing a BIG-IP virtual device on
VMware NSX creates a Service Instance Runtime (SIR). Creating this SIR allows
vCenter users to deploy load-balanced virtual servers (referred to in the VMware
interface as Service Profiles). You can make one virtual device for each defined NSX
Edge.
Tip: The objective of this task is to assemble a data parameter and use it
as the payload for a REST API call that updates the configuration of the load
balancer and specifies an NSX SIR. Because this parameter can be somewhat complex,
you will probably want to use a tool that allows you to assemble multiple lines of
content together to include in your REST API call. A script editor or a command line
tool that can send files using URL syntax (such as curl) may be very helpful.
-
In the vSphere web client user interface, create a new NSX Edge in an
un-deployed state.
Make sure that the NSX Edge you create identifies the Cluster/Resource Pool
and the Datastore, but does not identify any interfaces. Otherwise, follow your
standard practice for NSX Edge creation.
-
Authenticate with the VMware NSX REST API.
Important: Refer to the VMware API Reference documentation for the
most authoritative detail about using the VMware APIs required for this
task.
-
Use a REST API call to the NSX API to retrieve information about the pools and
monitors used by the NSX Edge. Copy the REST response to an editor for use in
compiling the remainder of the data parameter.
<NSX-Manager-IP-address>/api/4.0/edges/<NSX-Manager-IP-address>loadbalancer/config
GET
-
After you copy the content to the editor, edit the value of the
enabled and
enableServiceInsertion parameters. Change the
value of each parameter to true.
The following example illustrates a typical response to this API call.
<loadBalancer>
<version>1</version>
<enabled>true</enabled>
<enableServiceInsertion>true</enableServiceInsertion>
<accelerationEnabled>false</accelerationEnabled>
<monitor>
<monitorId>monitor-1</monitorId>
<type>tcp</type>
<interval>5</interval>
<timeout>15</timeout>
<maxRetries>3</maxRetries>
<name>default_tcp_monitor</name>
</monitor>
<monitor>
<monitorId>monitor-2</monitorId>
<type>http</type>
<interval>5</interval>
<timeout>15</timeout>
<maxRetries>3</maxRetries>
<method>GET</method>
<url>/</url>
<name>default_http_monitor</name>
</monitor>
<monitor>
<monitorId>monitor-3</monitorId>
<type>https</type>
<interval>5</interval>
<timeout>15</timeout>
<maxRetries>3</maxRetries>
<method>GET</method>
<url>/</url>
<name>default_https_monitor</name>
</monitor>
<logging>
<enable>false</enable>
<logLevel>info</logLevel>
</logging>
</loadBalancer>
-
Configure the next element in the data parameters for the REST API call that
will create your new VMware NSX Service Instance.
Important: Insert the parameters assembled in this step just before
the end of the </loadBalancer> element obtained in the previous
step.
-
Specify the description and name fields. Specify values that help you
identify the service and its purpose.
The following code snippet illustrates the field values discussed in
this step.
<globalServiceInstance>
<description>edge-16__LB__dummy</description>
<name>edge-16__LB__dummy</name>
-
Use a REST API call to the NSX API to determine the value of the
serviceId parameter.
You can see all of the NSX connectors using
<NSX-Manager-IP-address>/api/2.0/si/servicemanagers
GET
In the REST response, look for the <basicinfo> element in the
<services> element, and then find the name of the connector you
provided when you created the NSX connector. Use the <objectId>
associated with that connector name as the value for the
serviceId parameter.
-
Use the just obtained serviceID to make a REST API call to the NSX API
to determine the value of the serviceName
parameter.
<NSX-Manager-IP-address>/api/2.0/si/service/<serviceID>
GET
When you get the REST response, locate the <name> parameter and use
that value for the serviceName parameter.
In the following example, the name parameter value is:
NSX-conn-sample-20140717-113002-22123-0.
<objectId>service-446</objectId>
<objectTypeName>Service</objectTypeName>
<vsmUuid>42388336-FE9B-225A-ECAF-1085628911B2</vsmUuid>
<revision>6</revision>
<type>
<typeName>Service</typeName>
</type>
<name>NSX-conn-sample-20140717-113002-22123-0</name>
-
Use a REST API call to the NSX API to determine the value of the
instanceTemplateUniqueId and
instanceTemplateId parameters.
<NSX-Manager-IP-address>/api/2.0/si/service/<serviceID>
GET
When you get the REST response, look in the
<serviceInstanceTemplates> element and locate the name of the
service instance template that you plan to use (the default template
that is built when you create an NSX connection is F5 ADC - Make a
BIG-IP VE. Locate the <id> parameter and use that numeric string
value for the instanceTemplateId parameters.
-
For the instanceTemplateTypedAttributes element, specify
the type attributes that are required for the service instance template.
There are several attributes to configure. Some are required, some are
optional. Each one is identified by the value of the attribute key.
-
For the F5-BIG-IP-MAKE-VE key, leave the
<name> field alone and specify yes for the <value>
field
-
For the F5-BIG-IP-VE-FQ-HOST-NAME key, specify the
host name that you want the template to use, or leave it blank to use
the default host name.
Tip: This step is optional. If you do not
specify a host name, the template uses the default host name.
-
For the F5-BIG-IP-VE-OVF key, specify the name
you want to specify for the template.
Tip: If you have already created a node template,
than specify the name of it here. If you are creating a node template, then
specify a name to go along with the URL that you specify in the next
step.
-
For the F5-BIG-IP-VE-OVF-URL key, specify
the URL that describes the location
of the OVF file that the BIG-IQ device uses to create the BIG-IP VE.
Tip: This step is optional. You only need to specify the URL if the node template has not already been created.
-
For the F5-BIG-IP-VE-ADMIN-PASSWORD key, specify
the admin password so that you can easily log in as admin to this BIG-IP
VE from NSX.
Tip: When the BIG-IP VE is initially provisioned,
root login is disabled. To access the VE using root login, you must log in
as admin and set the root password.
Tip: If you choose to let NSX generate a
password, you can view the password by submitting a REST API call:
mgmt/cm/cloud/connectors/vmware-nsx/<connectorId>/nodes<nodeID>
GET. Examine the REST response for the value of the
DeviceMgmtPassword field.
-
For the runtimeNicInfo field, specify details for each of
the four network interfaces (NICs).
| Option |
Description |
| index |
The value of this field indicates which of the four NICs you are configuring. |
| label |
Specifies a name for the NIC you are configuring. |
| objectId field in the network parameter |
Specifies which network interface to use for the NIC you are configuring. |
| connectivityType |
Specifies whether the NIC you are configuring is for data (DATA) or control plane (MGMT) use. |
| ipAllocationType |
Specifies the mode to use for IP address allocation. Generally, IP_POOL, is used,
but you can also use MANUAL or DHCP. |
| objectId field in the ipPool parameter |
Identifies which IP pool to use for the IP addresses allocated to this NIC. |
- The first vNIC you specify provides the DHCP-enabled control plane
network on which the BIG-IP VE boots. Choose the name specified
previously that corresponds to the IP pool
192.168.11.0/24.
- The next vNIC you edit provides the external data network on which the
BIG-IP creates virtual servers. Choose the name specified previously
that corresponds to the IP pool
10.22.0.0/16.
- The next vNIC you edit provides the internal data network on which
load-balanced pool members are located. Choose the name specified
previously that corresponds to the IP pool
10.33.0.0/16.
- The last vNIC you edit provides the control plane network on which the
BIG-IQ device discovers and manages BIG-IP devices. Choose the name
specified previously that corresponds to the IP pool
192.168.44.0/24.
-
In the objectId field of the service
parameter, specify the name of the service manager you want to use.
You can retrieve this name using
<NSX-Manager-IP-address>/api/2.0/si/serviceinstance
GET
-
Once you have completed the data parameter assembly, you can create the SIR by
making a REST API call to the NSX API.
<NSX-Manager-IP-address>api/4.0/edges/<edge objectId>/loadbalancer/config
PUT
The following example illustrates a typical data parameter for this API
call.
<loadBalancer>
<version>1</version>
<enabled>false</enabled>
<enableServiceInsertion>false</enableServiceInsertion>
<accelerationEnabled>false</accelerationEnabled>
<monitor>
<monitorId>monitor-1</monitorId>
<type>tcp</type>
<interval>5</interval>
<timeout>15</timeout>
<maxRetries>3</maxRetries>
<name>default_tcp_monitor</name>
</monitor>
<monitor>
<monitorId>monitor-2</monitorId>
<type>http</type>
<interval>5</interval>
<timeout>15</timeout>
<maxRetries>3</maxRetries>
<method>GET</method>
<url>/</url>
<name>default_http_monitor</name>
</monitor>
<monitor>
<monitorId>monitor-3</monitorId>
<type>https</type>
<interval>5</interval>
<timeout>15</timeout>
<maxRetries>3</maxRetries>
<method>GET</method>
<url>/</url>
<name>default_https_monitor</name>
</monitor>
<logging>
<enable>false</enable>
<logLevel>info</logLevel>
</logging>
<instanceTemplateTypedAttributes>
<typedAttribute>
<key>F5-BIG-IP-MAKE-VE</key>
<name>F5-BIG-IP-MAKE-VE</name>
<value>yes</value>
<type>STRING</type>
</typedAttribute>
<typedAttribute>
<key>F5-BIG-IP-VE-OVF</key>
<name>Name of BIG-IP node template?</name>
<value />
<type>STRING</type>
</typedAttribute>
<typedAttribute>
<key>F5-BIG-IP-VE-FQ-HOST-NAME</key>
<name>Fully qualified host name of BIG-IP VE? Optional - remains default if unspecified.</name>
<value />
<type>STRING</type>
</typedAttribute>
<typedAttribute>
<key>F5-BIG-IP-VE-ADMIN-PASSWORD</key>
<name>Admin password of BIG-IP VE? Leave blank to have random strong password generated.</name>
<value />
<type>STRING</type>
</typedAttribute>
</instanceTemplateTypedAttributes>
<baseRuntimeConfig>
<deploymentScope>
<resourcePool>domain-c35</resourcePool>
<datastore>datastore-49</datastore>
<nics>
<runtimeNicInfo>
<index>0</index>
<label>mgmt</label>
<network>
<objectId>network-44</objectId>
</network>
<connectivityType>MGMT</connectivityType>
<ipAllocationType>IP_POOL</ipAllocationType>
<ipPool>
<objectId>ipaddresspool-4</objectId>
</ipPool>
<ipAddress>10.144.63.213</ipAddress>
<subnetMask>255.255.240.0</subnetMask>
<gatewayAddress>10.144.63.203</gatewayAddress>
</runtimeNicInfo>
<runtimeNicInfo>
<index>1</index>
<label>external</label>
<network>
<objectId>network-46</objectId>
</network>
<connectivityType>DATA</connectivityType>
<ipAllocationType>IP_POOL</ipAllocationType>
<ipPool>
<objectId>ipaddresspool-3</objectId>
</ipPool>
</runtimeNicInfo>
<runtimeNicInfo>
<index>2</index>
<label>internal</label>
<network>
<objectId>network-47</objectId>
</network>
<connectivityType>DATA</connectivityType>
<ipAllocationType>IP_POOL</ipAllocationType>
<ipPool>
<objectId>ipaddresspool-2</objectId>
</ipPool>
</runtimeNicInfo>
<runtimeNicInfo>
<index>3</index>
<label>ha</label>
<network>
<objectId>network-47</objectId>
</network>
<connectivityType>MGMT</connectivityType>
<ipAllocationType>IP_POOL</ipAllocationType>
<ipPool>
<objectId>ipaddresspool-2</objectId>
</ipPool>
</runtimeNicInfo>
</nics>
</deploymentScope>
</baseRuntimeConfig>
</config>
<service>
<objectId>input-service-id-here</objectId>
</service>
</serviceInstance>
</loadBalancer>
After you submit the API call, VMware NSX and the BIG-IQ software engage in a
sequence of calls and responses. When this sequence completes successfully, the NSX API
status returns an IN_SERVICE message to indicate that the device
provisioning is complete.
You can confirm that the provisioning sequence completed successfully, by making a
REST API call to the NSX API similar to this one:
<NSX-Manager-IP_address>/api/2.0/si/serviceinstance/<
serviceinstance-id>/runtimeinfo/<serviceruntime-id> GET
The API response IN_SERVICE indicates that provisioning completed
successfully.
Tip: If the status does not update to indicate success, you may be able to
determine where the sequence broke down by analyzing the call and response sequence.
For detail on this sequence, refer to Provisioning call flow sequence.
