I’m in the middle of redeploying my lab and got to the point where I’m re-deploying the Enterprise PKS solution on top of my Workload Domain with NSX-T. Now, saying that this has gone a little rougher than normal is a bit of an understatement. I’d forgotten to do a couple of pre-requisite items and am on my third try to enable Enterprise PKS using the VCF workflow. That being said, these prereqs are now taken care of, and everything should proceed as expected.
As it goes through the motions, it fails during the installation… again. Digging a little deeper, I see that the SDDC Manager workflow has failed on creating the Principal Identity for NSX-T integration.
During a previous run, it had succeeded in creating the PI user in NSX-T, so it’s unable to move forward due to the fact that it can’t create something that’s already there. To get past this, you can do the following:
curl -k -X GET "https://<NSX-Manager-FQDN>/api/v1/trust-management/principal-identities" -u "<username>:<password>"The results should look similar to that below. We’re looking for the pks-nsx-t-superuser created earlier. We need the value of its ‘id’ parameter.
Now, let’s get rid of it.
curl -k -X DELETE "https://<NSX-Manager-FQDN>/api/v1/trust-management/principal-identities/<PI-UUID>" -u "<username>:<password>"Then, to make sure it’s gone.
Next, we need to delete the certificate itself.
curl -k -X GET "https://<NSX-Manager-FQDN>/api/v1/trust-management/certificates" -u "<username>:<password>"And in the slew of certificates returned, find the PI certificate. Once again, we’re looking for its ‘id’ value so we can use that to delete the cert.
Now, to delete the cert.
curl -k -X DELETE "https://<NSX-Manager-FQDN>/api/v1/trust-management/certificates/<cert-UUID>" -u "<username>:<password>"And to verify its deletion.
Now I restart my task in SDDC Manager, wait a bit, and presto.
Recent Comments