Each object within the NSX Advanced Load Balancer configuration is assigned a unique identity. Multiple objects in different tenants may have the same name. For instance, multiple tenants may have a virtual service named “web.” For automated interaction with NSX Advanced Load Balancer, particularly through the API, it is useful to know how to obtain the UUID of objects such as a virtual service. This topic explains the steps to find the UUID of objects using API, CLI, and UI.

For example, it is recommended to have Tenant Header (X-Avi-Tenant) set in the API calls so the Controller can resolve the name to the correct tenant. The details for the header insertion are in the SDK and API guide.

Finding UUID through the API

https://10.1.1.1/api/virtualservice?name=FTP-VS&fields=uuid

Finding UUID through the GUI

Click the virtual service.

Since the GUI is executing API calls on the NSX Advanced Load Balancer Controller, the UUID is reflected in the URL.

https://10.1.1.1/#/authenticated/applications/virtualservice/virtualservice-0523452d-c301-4817-a5e0-ee66b95bd287/analytics?timeframe=6h

Find UUID through the CLI

: > show virtualservice FTP-VS
+---------------------------+-----------------------------------------------------+
| Field                     | Value                                               |
+---------------------------+-----------------------------------------------------+
| uuid                      | virtualservice-0523452d-c301-4817-a5e0-ee66b95bd287 |
| name                      | FTP-VS                                              |
| address                   | swapnil2                                            |
| ip_address                | 10.130.129.14                                       |

Reference Objects by Name

For objects created within NSX Advanced Load Balancer, it is possible to reference objects by name rather than by UUID. However, there are objects, such as subnets, created outside of NSX Advanced Load Balancer and pushed down to the Controller, such as through OpenStack. For these objects, they must be referenced by API calls via their UUID, not through their name. Therefore, it is generally considered best practice to have API calls reference object UUIDs rather than names.