VMware Cloud Director – Changing the Organization VDC Allocation Model

In this blog post, I am going to discuss the capability of changing the allocation model of an organization virtual data center (oVDC) within VMware Cloud Director (VCD).

Introduction to Allocation Models

To set the stage on this topic, VCD has four distinct allocation models for oVDCs. Until VCD 9.7, we had the following three:

1. Allocation Pool – capacity is reserved for the oVDC and represents a percentage of the pVDC. Directly correlated to memory-based admission control for power-on operations.
2. Pay as You Go – resources are committed to the VM on creation in the oVDC and can control overcommitment per VM. Tied to CPU and memory-based admission control.
3. Reservation Pool – all resources that are allocated to the oVDC are committed and removed from the pVDC. Admission control does not come into play here (which could lead to resource starvation from a tenant perspective).

An elastic allocation model allows a provider to span multiple resource pools. This applies to Allocation Pool or Pay As You Go models. This allows for continuous capacity growth for multi-tenant environments.

Addition of Flex Allocation Model

VCD 9.7 introduced the Flex Allocation Model as the fourth model while presenting new, distinct functionality.

In essence, a Flex Allocation Model combines a Pay as You Go-like model along with VM granular control. This presents the unique ability to set constraints or limits on a VM basis compared to limits enforced at the orgVDC level. A provider can utilize VM Sizing Policies to control these “guard-rails” on a per-VM basis.

While the Flex Allocation Model is a unique selection, this is also the standard framework for all organization VDCs. When using VCD 9.7 or greater, all newly created organization VDCs use this Flex VDC framework.

Flex oVDC allows for online, or hot, conversion to other type of allocation model types. There are some current considerations I will review later in this post.

Next, let’s change the allocation model with running workloads!

Steps on Changing an Organization VDC

To start, I will be executing the online conversion of a Pay As You Go oVDC to an Allocation Pool oVDC. This oVDC is running active VMs to demonstrate that we can do this with live workloads.

There are two steps to get to the Allocation Pool type.

1. Convert to Flex Model by applying an incompatible VM Sizing Policy – this is done through the Provider User Interface (UI)
2. Use the API to convert from Flex to Allocation Pool

From there, one would apply the VM Sizing Policy to the oVDC. This Sizing Policy would have sizing metrics that would conflict with the existing allocation model.

Therefore, this would trigger a conversion to the Flex Allocation Model.

Example Conversion: Tenant-0VDC-1 – PAYGO to Allocation Pool

In this example conversion, we will be converting Tenant-oVDC-1 from Pay As You Go to Allocation Pool.

To summarize the steps, we will utilize a temporary Sizing Policy to force the conversion for Flex. Next, we will remove this policy and then use the API to convert from Flex to the destination allocation model.

To start, we can see Tenant-oVDC-1 has an allocation model of Pay As You Go –

While I have running VMs within this orgVDC –

Step 1

To start, let’s add the VM Sizing Policy to this oVDC. Within the Provider UI, under VM Sizing Policies, select Add while checking your specific Sizing Policy (Compute Policy) –

Step 2

A prompt will be shown that shows that applying this incompatible policy will convert this VDC type to Flex.

Now, we can see that we have a new Sizing Policy and the oVDC reflects an allocation model of Flex.

Step 3

Next, we are ready to convert this to an Allocation Pool model. To do this, we need to remove the sizing policy we just assigned and then utilize the API for the conversion.

First, let’s remove the Sizing Policy –

Step 4

Finally, we need to get a token and use the legacy vCloud API to browse to the orgVDC for the modification/conversion.

A few things if one uses Postman – first, get your API token and you’ll need to find your “x-cloud-authorization” value:

There are specific headers you’ll need for the PUT call we will be using to convert to Allocation Pool. Note the Content-Type value which is specific to VDC modification.

Accept application/*+xml;version=34.0
Content-Type application/vnd.vmware.admin.vdc+xml
x-vcloud-authorization <KEY>

We are looking for the /api/admin/vdc/<ID> for this specific oVDC. For my environment, I was able to pull this from the following:

Within my organization, this was my API call:

GET https://vcd.dp-pod.zpod.io/api/admin/org/4491e6e3-d553-4a25-b805-d7a533bbe173

Once I found my specific orgVDC, this was my API call –

GET https://vcd.dp-pod.zpod.io/api/admin/vdc/1071673c-5749-4208-9557-fd23c629f20c

Now we are ready to build our entire PUT body to change the “AllocationModel” function, which is on line 56 of my output –

Before the conversion to Flex, we would have seen this as the Allocation Model, which represents Pay As You Go –

These are the values for all Allocation Models within VCD as of 10.1.1 –

AllocationVApp - Pay As You Go
AllocationPool - Allocation Pool
ReservationPool - Reservation
Flex - Flex Model

Continuing on, I built my body using Raw -> XML selection while modifying from Flex to AllocationPool –

Sending the request, we will receive a 202 that reflects the API call was correct, but not necessarily successful….

What Happened?

It failed to convert. Below is the VCD task failure.

Why? Well, we are attempting to convert to an Allocation Pool that requires a minimum allocation of CPU, which was not assigned to this orgVDC prior! Therefore, we need to update those specifics within the CPU and Memory configuration.

Within the UI, I went ahead and updated the CPU and Memory allocation for this conversion –

We can also see this within the new GET API call and reflected under <ComputeCapacity> section –

Let’s try again….

Accepted….

Success!

Now, we see that Tenant-oVDC-1 reflects the Allocation Model of Allocation Pool.

Most importantly, all of my active VM’s remained operational during this process.

Considerations and Summary

In summary, this conversion process between different types of allocation models is valuable while maintaining availability of running workloads. The provider has granular control between any type of model. We do recommend on using VM Sizing Policies when possible. However, we understand many business/financial models are tied to these existing allocation models. The Flex VDC model presents distinct, granular functionality.

A few things I’d like to point out –

1. Any type of oVDC can be changed. Any oVDC created post-9.7 has the Flex framework already applied for consumption.
2. As one can see above, you must respect the guidelines set-forth within the allocation model. You cannot convert to an Allocation Pool without a minimal allocation of CPU/Memory resources. All other allocation model guidelines apply.
3. To that point, we need to respect existing resource requirements. Please do not convert to a reservation pool without understanding the ramifications of existing workload requirements.
4. Within VCD 10.1.1, there is a known issue with converting from an Allocation Pool to Flex. This throws an NullPointerException error when attempting to convert to Flex when attaching the Sizing Policy.

Engineering is aware of this and it will be addressed in the next patch release, so please be aware of this with 10.1.1.

Overall, this is a rather simple process within the UI and the vCloud API. A special thanks to Manu Pratap Singh for his guidance and help.

-Daniel