This is expected behaviour as the license key is a required parameter for the workflow.
Please use the steps below to resolve this problem.
- Add the ESXi license to the VMware SDDC Manager. See the Manage License Keys for the Software in Your Cloud Foundation System documentation for more information.
- Verify the Network Pool has sufficient IPs to attempt a new Add VI workflow.
- If the Network Pool has sufficient IPs and the there are not concern about the orphaned IPs, proceed with creating the new Add VI workflow with the same domainSpec as used before.
- The FetchLicensesForDomainAction will now succeed since the license has been added .
If the Network Pool does NOT have enough IPs for a new Add VI workflow, please see the options below and the corresponding entries in the Workaround section:
- Option 1: Add a new IP range for each of the networks in the Network pool which is sufficient for a new Add VI workflow
- Option 2: Release the orphaned IPs.
Workaround:
For Option 1, please see Create a Network Pool documentation for more information. Once the additional Network Pool(s) is created, please proceed with ensuring the license(s) are added and starting a new VI workflow.
For Option 2, see the workaround steps below:
- Open an SSH session to the SDDC Manager and change to the root user:
su -
- Use the following command to obtain the task id to be used in later step as the execution id:
curl localhost/domainmanager/inventory/tasks | json_pp
- Get the ID for each network in the network pool
curl localhost/networkpools | json_pp
Example:
[
{
"networks" : [
"51fd518d-2ac9-####-####-########9e2",
"dcff1e1f-d6a0-####-####-########712"
],
"name" : "sfo-m01-np01",
"id" : "0e06eff5-9fe7-####-####-########ac0"
},
{
"networks" : [
"4f6584a4-6b7d-####-####-########60a",
"1a53e9a3-af24-####-####-########09e"
],
"name" : "sfo-w01-np01",
"id" : "8b721a9b-67d6-4125-b09b-07fceb8e5040"
}
]
- Use the Network Pool id to verify which networkId corresponds to which network:
curl localhost/networkpools/{network_id}/networks | json_pp
Example:
[
{
"type" : "VSAN",
"usedlist" : [
"172.28.223.101",
"172.28.223.102",
"172.28.223.103",
"172.28.223.104"
],
"subnet" : "172.28.223.0",
"mask" : "255.255.255.0",
"ippools" : [
{
"end" : "172.28.223.104",
"start" : "172.28.223.101"
}
],
"vlanid" : 3723,
"gateway" : "172.28.223.253",
"id" : "4f6584a4-6b7d-####-####-########60a",
"mtu" : 9000
},
{
"gateway" : "172.28.222.253",
"id" : "1a53e9a3-af24-####-####-########09e",
"mtu" : 9000,
"type" : "VMOTION",
"usedlist" : [
"172.28.222.101",
"172.28.222.102",
"172.28.222.103",
"172.28.222.104"
],
"subnet" : "172.28.222.0",
"mask" : "255.255.255.0",
"ippools" : [
{
"end" : "172.28.222.104",
"start" : "172.28.222.101"
}
],
"vlanid" : 3722
}
]
- For a Network Pool that is only being used for this VI Workload Domain, then simply take all of the 'usedList' as the IPs for the request body and skip step 5.
- If the Network Pool is shared across Workload Domains / Management Domain, run the following command to retrieve the exact IPs that match for the ESXi in this specific domainSpec using the execution ID.
curl localhost/domainmanager/internal/vault/{execution-id} | grep vsanIpAddress
curl localhost/domainmanager/internal/vault/{execution-id} | grep vmotionIpAddress
- Create a request body json for the the IPs required. Run the following commands:
vi /tmp/vsanIps.json
example:
["172.28.223.101","172.28.223.102","172.28.223.103","172.28.223.104"]
vi /tmp/vmotionIps.json
example:
["172.28.222.101","172.28.222.102","172.28.222.103","172.28.222.104"]
- Run the following API commands to release the IPs for use:
curl -X DELETE -H "Content-type:application/json"
localhost/networkpools/{networkPoolId}/networks/{networkId}/ip
-d @/tmp/vsanIps.json
curl -X DELETE -H "Content-type:application/json"
localhost/networkpools/{networkPoolId}/networks/{networkId}/ip -d
@vmotionIps.json
After the above steps have been completed, start a new Add VI workflow with the same domainSpec as original. Important: Do not retry the failed operation.