VMware Networking Community
KBricksBuilder
Enthusiast
Enthusiast
Jump to solution

Deploying Edge via the API fails with error 10086

Goal:
Deploy an NSX Edge via the API. Doing so manually works perfectly fine, but when utilizing the API an error occurs which I cant seem to find the solution to.

Error:

{"errorCode":10086,"details":"Traffic shaping policy can be set only for a Vnic connected to a VMware distributed virtual portgroup configured with static port binding. Invalid portgroup network-738.","rootCauseString":null,"moduleName":"vShield Edge","errorData":null}

My current query iteration looks as follows with anonymization:

curl -k -X POST -H 'Content-Type: application/xml' -u user:password -d '<edge><datacenterMoid>datacenter-2</datacenterMoid><name>APICreated-LBSS-Edge</name><tenant>Default</tenant><vseLogLevel>info</vseLogLevel><appliances><applianceSize>compact</applianceSize><appliance><resourcePoolId>Physhost</resourcePoolId><datastoreId>VRTX-Test-VD0</datastoreId></appliance></appliances><vnics><vnic><index>0</index><name>APICreated-LBSS-Edge-Interface</name><type>uplink</type><portgroupId>network-738</portgroupId><addressGroups><addressGroup><primaryAddress>123</primaryAddress><secondaryAddresses><ipAddress>123</ipAddress></secondaryAddresses><subnetPrefixLength>28</subnetPrefixLength></addressGroup></addressGroups><mtu>1500</mtu><enableProxyArp>false</enableProxyArp><enableSendRedirects>false</enableSendRedirects><isConnected>true</isConnected><inShapingPolicy><averageBandwidth>20000000</averageBandwidth><peakBandwidth>20000000</peakBandwidth><burstSize>0</burstSize><enabled>true</enabled><inherited>false</inherited></inShapingPolicy><outShapingPolicy><averageBandwidth>20000000</averageBandwidth><peakBandwidth>20000000</peakBandwidth><burstSize>0</burstSize><enabled>true</enabled><inherited>false</inherited></outShapingPolicy></vnic></vnics><cliSettings><userName>admin</userName><password>123</password><remoteAccess>false</remoteAccess></cliSettings></edge>' 'https://123/api/4.0/edges'

The portgroupID has been found via the guide on page 16 of the API manual:
https://docs.vmware.com/en/VMware-NSX-Data-Center-for-vSphere/6.4/nsx_64_api.pdf

portgroupidinterface.png

It looks like my portgroupID is wrong or the resource is not valid, but im unsure why, it looks correct to me and ive tried both the name and the ID. Anyone who has successfully deployed an Edge via the NSX API who can spot what I'm doing wrong?
(If you feel comfortable sharing your own API query for my inspiration, that would be very appreciated as well.)

Have a nice Saturday everyone
// Kasper

Reply
0 Kudos
1 Solution

Accepted Solutions
KBricksBuilder
Enthusiast
Enthusiast
Jump to solution

The issue has now been resolved in cooperation with a co-worker.
With the original query it turned out there were multiple issues:

1. Problem: Use of the properties inShapingPolicy and outShapingPolicy, which are not supported by Standard portgroups.    

    Solution: Remove these properties from the query.

2. Problem: The property resourcePoolId caused errors.

    Solution: Instead of using the value "Physhost" which is more akin to the name than the id, use the actual id equivalent, in our case "domain-c123". As far as I can tell this value is not visible anywhere from the NSX webinterface, hence it was pretty friggin hard to know this. The way we became aware of its existence was to query an existing Edge for its configurations with the following command: curl -k -X GET -H "Accept: application/xml" -H "Content-Type: application/xml" -u user:password 'https://123.123.123.123/api/4.0/edges/edge-7

And from resulting output we spotted the "domain-c123" value and attempted to reuse it with success.

3. Problem: The Edge CLI password didnt include an uppercase letter.

   Solution: Include uppercase letter.

After doing the above 3 steps, we ended up with the following NSX API query which worked like a charm to deploy the Edge via the API(Yay!):

curl -k -X POST -H 'Content-Type: application/xml' -u user:password -d '<edge><datacenterMoid>datacenter-2</datacenterMoid><name>APICreated-LBSS-Edge12345</name><tenant>Default</tenant><vseLogLevel>info</vseLogLevel><appliances><applianceSize>compact</applianceSize><appliance><resourcePoolId>domain-c123</resourcePoolId><datastoreId>datastore-736</datastoreId></appliance></appliances><vnics><vnic><index>0</index><name>APICreated-LBSS-Edge-Interface</name><type>uplink</type><portgroupId>network-738</portgroupId><addressGroups><addressGroup><primaryAddress>123.123.123.123</primaryAddress><secondaryAddresses><ipAddress>123.123.123.123</ipAddress></secondaryAddresses><subnetPrefixLength>28</subnetPrefixLength></addressGroup></addressGroups><mtu>1500</mtu><enableProxyArp>false</enableProxyArp><enableSendRedirects>false</enableSendRedirects><isConnected>true</isConnected></vnic></vnics><cliSettings><userName>admin</userName><password>thisIsadummyPassword123!</password><remoteAccess>false</remoteAccess></cliSettings></edge>' 'https://123.123.123.123/api/4.0/edges'

View solution in original post

Reply
0 Kudos
1 Reply
KBricksBuilder
Enthusiast
Enthusiast
Jump to solution

The issue has now been resolved in cooperation with a co-worker.
With the original query it turned out there were multiple issues:

1. Problem: Use of the properties inShapingPolicy and outShapingPolicy, which are not supported by Standard portgroups.    

    Solution: Remove these properties from the query.

2. Problem: The property resourcePoolId caused errors.

    Solution: Instead of using the value "Physhost" which is more akin to the name than the id, use the actual id equivalent, in our case "domain-c123". As far as I can tell this value is not visible anywhere from the NSX webinterface, hence it was pretty friggin hard to know this. The way we became aware of its existence was to query an existing Edge for its configurations with the following command: curl -k -X GET -H "Accept: application/xml" -H "Content-Type: application/xml" -u user:password 'https://123.123.123.123/api/4.0/edges/edge-7

And from resulting output we spotted the "domain-c123" value and attempted to reuse it with success.

3. Problem: The Edge CLI password didnt include an uppercase letter.

   Solution: Include uppercase letter.

After doing the above 3 steps, we ended up with the following NSX API query which worked like a charm to deploy the Edge via the API(Yay!):

curl -k -X POST -H 'Content-Type: application/xml' -u user:password -d '<edge><datacenterMoid>datacenter-2</datacenterMoid><name>APICreated-LBSS-Edge12345</name><tenant>Default</tenant><vseLogLevel>info</vseLogLevel><appliances><applianceSize>compact</applianceSize><appliance><resourcePoolId>domain-c123</resourcePoolId><datastoreId>datastore-736</datastoreId></appliance></appliances><vnics><vnic><index>0</index><name>APICreated-LBSS-Edge-Interface</name><type>uplink</type><portgroupId>network-738</portgroupId><addressGroups><addressGroup><primaryAddress>123.123.123.123</primaryAddress><secondaryAddresses><ipAddress>123.123.123.123</ipAddress></secondaryAddresses><subnetPrefixLength>28</subnetPrefixLength></addressGroup></addressGroups><mtu>1500</mtu><enableProxyArp>false</enableProxyArp><enableSendRedirects>false</enableSendRedirects><isConnected>true</isConnected></vnic></vnics><cliSettings><userName>admin</userName><password>thisIsadummyPassword123!</password><remoteAccess>false</remoteAccess></cliSettings></edge>' 'https://123.123.123.123/api/4.0/edges'

Reply
0 Kudos