Using the VMC API to troubleshoot the connected VPC

I ran into a problem today where a customer tried to connect their native VPC to VMC on AWS, but had no subnets available, even though they knew there were subnets in the VPC.

The problem ended up being that all of the subnets in the connected VPC were shared subnets – owned by a different account and shared into the connected VPC. This is unsupported – connected VPC subnets must exist directly in the connected VPC. However, the CloudFormation stack still succeeds and connects the organization to the connected VPC.

You can obviously use the AWS console to look at your VPC subnets, but that’s not always an option. Sometimes based on project timelines and staff availability, all you do on a particular call is get the person with administrative access to run the CloudFormation stack to connect the VPC to the VMC on AWS org. You can then create the SDDC later. If you’re having a problem with no subnets showing up, you either need to wait for somebody who has access to the VPC to log on, or you can check it yourself via API.

To create a test environment, I started a new SDDC build, connected a new AWS account, then ran the Cloud Formation stack

The cloud formation stack succeeds.

Connection was successful

Now if I cancel out of the SDDC creation and start creating a different SDDC, my newly connected account starting in 77 is still available as a choice – I can continue with the SDDC creation.

In a related problem, sometimes the customer connects the wrong account and you want it removed from the list. You can also do this via the API – I show this at the bottom of the post.

Using the API

If you have the ability to pull down Python scripts from Github, the Python Client for VMware Cloud on AWS is the easiest way to make the API calls to check on connected VPC subnet compatibility. Clone the repo and put your own refresh token, Org ID, and SDDC ID in config.ini

You can then use two new commands that I just created – show-connected-accounts and show-compatible-subnets.

Run the show-connected-accounts command (output redacted). This shows us all of the native AWS accounts that are connected to our organization.

$ ./ show-connected-accounts
|                OrgID                 |
| 2axxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
| Account Number |                  id                  |
|  61xxxxxxxxxx  | 08xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
|  68xxxxxxxxxx  | 14xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
|  80xxxxxxxxxx  | 59xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |
|  82xxxxxxxxxx  | bbxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx |

Then find the connected account ID associated with the AWS account number and use it as an argument to the show-compatible-subnets command.

To show compatible native AWS subnets connected to the SDDC:
        show-compatible-subnets [LINKEDACCOUNTID] [REGION]

In this case I need to connect the AWS account number starting with 68 to an SDDC In us-east-1. So I find account 68xxx is mapped to Linked Account ID 14xxx. The command output is below, you get a list of subnets and whether they are compatible.

$ ./ show-compatible-subnets 14xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx us-east-1
|          vpc          | description |
| vpc-04xxxxxxxxxxxxxxx |     Texx    |
| vpc-0axxxxxxxxxxxxxxx |  Texxxxxxx  |
| vpc-02xxxxxxxxxxxxxxx |     xxxx    |
|      vpc-41xxxxxx     | vmcxxxxxxxx |
|         vpc_id        |        subnet_id         | subnet_cidr_block |        name        | compatible |
| vpc-04xxxxxxxxxxxxxxx | subnet-00xxxxxxxxxxxxxxx |  |       Texxx        |   False    |
| vpc-0axxxxxxxxxxxxxxx | subnet-0cxxxxxxxxxxxxxxx |  10.xxxxxxxxx/xx  |    Alxxxxxxxxxx    |    True    |
| vpc-0axxxxxxxxxxxxxxx | subnet-05xxxxxxxxxxxxxxx |   10.xxxxxxx/xx   |    Texxxxxxxxxx    |    True    |
| vpc-0axxxxxxxxxxxxxxx | subnet-08xxxxxxxxxxxxxxx |   10.xxxxxxxx/xx  |    Texxxxxxxxxx    |    True    |
| vpc-0axxxxxxxxxxxxxxx | subnet-0cxxxxxxxxxxxxxxx |   10.xxxxxxxx/xx  |    Texxxxxxxxxx    |    True    |
| vpc-0axxxxxxxxxxxxxxx | subnet-05xxxxxxxxxxxxxxx |   10.xxxxxxxx/xx  |    Texxxxxxxxxx    |    True    |
| vpc-0axxxxxxxxxxxxxxx | subnet-00xxxxxxxxxxxxxxx |  10.xxxxxxxxx/xx  |    Texxxxxxxxxx    |   False    |
| vpc-02xxxxxxxxxxxxxxx | subnet-0cxxxxxxxxxxxxxxx |   172.xxxxxx/xx   |        xxxx        |    True    |
| vpc-02xxxxxxxxxxxxxxx | subnet-00xxxxxxxxxxxxxxx |   172.xxxxxx/xx   |        xxxx        |    True    |
|      vpc-41xxxxxx     |     subnet-63xxxxxx      |   172.xxxxxxx/xx  |        xxxx        |    True    |
|      vpc-41xxxxxx     |     subnet-70xxxxxx      |   172.xxxxxxx/xx  |        xxxx        |    True    |
|      vpc-41xxxxxx     |     subnet-34xxxxxx      |   172.xxxxxxx/xx  |        xxxx        |    True    |
|      vpc-41xxxxxx     |     subnet-0cxxxxxx      |   172.xxxxxxx/xx  |        xxxx        |    True    |
|      vpc-41xxxxxx     |     subnet-25xxxxxx      |   172.xxxxxxx/xx  |        xxxx        |   False    |
|      vpc-41xxxxxx     |     subnet-1exxxxxx      |   172.xxxxxxx/xx  | vmcxxxxxxxxxxxxxxx |    True    |

If pulling down Python repositories from Github isn’t your thing, here is how to do it via API calls in the Developer Center

Go to Developer Center>API Explorer, then click VMware Cloud on AWS>General. Expand the AWS Account Connection Operations category.

Find the /account-link/connected-accounts GET request and execute it

We get back a list of AWS accounts that are connected to this org. Now we need to find which one is connected to the correct AWS account ID. Above, I made a new connection to an AWS account ID that began with 77, so normally we would look for that account ID. However, that account is completely empty with no subnets in it; I’m instead going to look for an account ID that I know has subnets in it – the account ID starts with 68.

I click until I find the one I want – I find my account ID that starts with 68 in the ConnectedAccount GUID starting with 14. I copy that GUID to my clipboard

Now find the /account-link/compatible-subnets GET request. The org ID automatically populates, paste the Linked Account ID in, then you have to enter the region where you were trying to deploy – in this case us-east-1.

All of your subnets show up – the important flag is at the bottom – ‘compatible’.

I didn’t want my empty linked account with the GUID starting with ’47’ to remain linked anymore, so I deleted it with this call.


Leave a Reply to Writing in Python – when work and life intersect – Patrick Kremer Cancel reply

Your email address will not be published. Required fields are marked *