Tag: VCPP

One of the extremely exciting additions to VMware vCloud Director (vCD) is the ability to present vCenter instances securely to tenant organizations utilizing the vCD user interface – this is referred to as Central Point of Management, or what we abbreviate to as CPoM. Tom Fojta did a great job highlighting what’s new inside of vCD 9.7 here.

In this post, I am going to review the steps required to successfully deploy your first vCenter-SDDC to an organization inside of vCloud Director 9.7. You will need to utilize the CloudAPI, but do not be alarmed, I will walk you through these steps.

First off, what the heck is CPoM?

CPoM is the ability to present a dedicated vCenter instance to an organization, or tenant, via the vCloud Director user interface. In the past, we’ve had many providers providing hosted or dedicated private cloud services.

With the addition of this functionality, we can now utilize vCloud Director to manage both shared and dedicated cloud resources from a single portal.

In essence, the VMware Cloud Provider team is delivering on the promise of transforming vCloud Director into a services platform – and this additional functionality demonstrates that.

So, how do we get started?

High-Level Steps

1. Add new vCenter instance to vCD Provider Management – UI
2. Creating a new SDDC instance – API
3. Publish to specific org/tenant – API
4. Add Tenant permissions and CPoM Plugin -UI
5. Proxy Configuration – UI
6. Enjoy dedicated vCenter-SDDC access via vCD

Adding new vCenter Instance to vCD Provider Management

First up, we need to add this dedicated vCenter instance to the provider management.

My tenant is T1 and will be adding vcsa-01b.corp.local to their organization.

Before, we go into the steps, let’s review the documentation that talks about the high-level steps required.

Managing SDDCs and SDDC Proxies

One important note – you cannot attach an existing vCenter that’s utilized as a provider VDC (pVDC). This is pointed out in the documentation –

First, let’s navigate to vSphere Resources -> vCenters and click the Add button –

Let’s plug in our required connection data –

Next up is the configuration of the NSX-V Manager. I had a conversation with Engineering on this and the applicability for CPoM. While this is not mandatory for accessibility, a tenant can also proxy NSX commands via the proxy configuration. Therefore, depending on your use case, you may or may not want to set this up.

Once completed, we can now see the new vCenter (and what I called vCenter-T1 since it will be dedicated to organization T1) being added to the vCD Provider UI.

Once the operation is complete, we should see this as enabled, but not published to a SP or Tenant.

Creating a new SDDC instance

This has be done via the CloudAPI. First off, let’s explore the new API Explorer which provides some examples and how to parse this utilizing Postman, Curl, or whatever you choose. Navigate to https://vcd-fqdn/api-explorer/provider –

Under the sddcs section, we have the following commands available –

Okay, let’s get our bearer-token first. If you are new on setting up Postman for connectivity, Fojta did a great blog post on utilizing the new bearer token with the CloudAPI functionality here.

Get our initial token and pass it through as a variable –

POST https://vcd-fqdn/api/sessions

Now, I want to view the current list of sddcs inside of this vCD instance. I realize we do not have any as of yet, but let’s see what it returns.

GET https://vcd-fdqn/cloudapi/1.0.0/sddcs

As expected, we do not have any SDDCs just yet. Let’s create our first one!

Our POST command will require a JSON body like the below. There are many more fields, but these are the required fields.

{
  "name":"<name of your new SDDC>",
  "description":"<description for your new SDDC>",
  "vcId":"<ID of the VC recorded>"
}

But before we add it, we have a prerequisite – we need to get the vCenter ID of the newly added vCenter instance.

To do this, we need to run a GET command to vCenter ID. You will need to run the following:

GET https://vcd-fdqn/api/admin/extension/vimServerReferences

Okay, here’s my results –

And here is my “vCenter-T1” ID!

So for my vCenter-T1, my ID is the following:

id="urn:vcloud:vimserver:419173a9-56bd-471f-929c-3f00c287d21b"

We will add this to the body for when we add this as a new SDDC.

Creation of my JSON body –

{
  "name":"vCenter-T1",
  "description":"T1 dedicated vCenter",
  "vcId":"urn:vcloud:vimserver:419173a9-56bd-471f-929c-3f00c287d21b"
}

Alright, ready to hit the Send button…

And accepted…

I could use the Postman API to check the task, but I also see it running in the UI…

Completed!

Let’s check and see what we have from the API now. Excellent, we now see vCenter-T1 as a new SDDC –

We also see the new ID for this SDDC:

This will be important as we will need this to publish it to the organization T1. First, let’s check and ensure it’s not published to anyone yet.

GET https://vcd-fdqdn/cloudapi/1.0.0/sddcs/urn:vcloud:sddc:29bf292b-07df-4d2f-9155-97dce2bad95d/tenants

As expected, no one has this from a tenant perspective –

Next pre-requisite – we need to get the orgID so we can create the body for the POST to publish this to T1. Our body will need to look like this:

[
 {
 "name":"org1Name", 
 "id":"URN-ID"
 }
]

Okay, let’s do a GET to /api/org –

Now, let’s crack open the T1 org further – /api/org/<org-ID> to get the URN –

So for my T1 organization, my ID is:

id="urn:vcloud:org:efb57814-44f2-4f60-9848-215be81f1294"

Assembling my body for the POST –

[
 {
   "name":"T1",
   "id":"urn:vcloud:org:efb57814-44f2-4f60-9848-215be81f1294"
 }
]

Let’s send it!

Got a 200 OK –

Now, if I do a GET to see what tenants/orgs have it..

GET https://vcd-fqdn/cloudapi/1.0.0/sddcs/urn:vcloud:sddc:29bf292b-07df-4d2f-9155-97dce2bad95d/tenants

We can see T1 has it published:

Behold, I can see the new vCenter-T1 from my T1 Org Admin! But why is it showing a red X?

Because by default, when you add the new SDDC, it defaults to false on “enabled”

So we have to enable it, here’s the body for my PUT – (changed it from false to true)

{
     "name": "vCenter-T1",
     "id": "urn:vcloud:sddc:29bf292b-07df-4d2f-9155-97dce2bad95d",
     "enabled": true,
     "vcId": "urn:vcloud:vimserver:419173a9-56bd-471f-929c-3f00c287d21b"
 }

Successful….

And green check mark in the T1 org admin view!

Add Tenant permissions and CPoM Plugin

By default, the rights bundles and the organization admin global role does not have SDDC access. Also, we need to publish the CPoM Plugin. Let’s do that first.

Under Provider UI, hit the hamburger menu -> Customize Portal, check the CPoM Extension and Publish –

Publish to selected tenants –

Let’s now provide the correct permissions.

On the Provider UI, toggle to Administration -> Tenant Access Control -> Rights Bundles – select the respective rights bundle you need to provide SDDC access and click Edit:

Under Infrastructure – SDDC, we can see the SDDC View and Manage option. Click View –

Ensure this rights bundle is published to your respective organizations –

Now, under Organization Administrator for the Global Role, add this new view permission –

Finally, publish –

Now, any organization admin can see the associated/published SDDC from their login. This can also apply to another role you might deem necessary.

Proxy Configuration and Logging In

There are three steps that need to take place for successful login:

1. Checking out the default proxy to line up to the vCD VIP/cells
2. Activating the proxy
3. Downloading and configuring the proxy configuration file
4. Importing the .PEM for certificate management

First, let’s GET the existing proxy configuration –

https://vcd-fdqn/cloudapi/1.0.0/sddcsProxies

Now let’s get the explicit body for this default proxy –

GET https://vcd-fqdn/cloudapi/1.0.0/sddcProxies/urn:vcloud:sddcProxy:625ddc5a-66ee-4d1a-94a3-603a83604cd2

Now if I wanted to create a specific one, I can do a POST and do the following –

We can now see I have two proxies now. So, this is a great way to explicitly state what you’re trying to do.

Next, click on Manage Proxies –

Activate the default proxy –

Now activated, one can download the proxy configuration file, configure it to your browser and also download the proxy certificate (and upload it).

The proxy configuration file is pretty basic –

We can also see how it does the redirection from the cell to the T1-vCenter (check the bottom URL):

Again, before we can successfully login, ensure you’ve configured your browser for the PAC/proxy configuration. If you click the ? icon, there is a tutorial on configuring it for Chrome, Firefox, etc.

Once clicked, you are prompted for the org user along with the access token, and voila! Login.

Conclusion

I am extremely pleased with this new functionality inside of vCloud Director. While you need to know how to utilize the CloudAPI for initial configuration, it’s quite simple and elegant to utilize with Postman. The API-Explorer provides examples too. This is the first iteration of the CPoM service and will only get better as time progresses.

I believe this is a solid use case for dedicated private cloud alongside existing cloud organization VDCs – great way to provide distinct cloud services in a secure manner.

More to come, enjoy!

-Daniel