The VMware Cloud Provider Software Business Unit has released the next iteration of vCloud Director – version 9.5. We’ve been holding to a six month cadence on major releases and this vCD version does not disappoint.
UI continues to get better and better for Tenants and Providers. With 9.5, I would say the UI is about 98% completed – most of the tenant functions should able to be accomplished through the H5 UI. In this release, RBAC capabilities are also introduced (more on that shortly).
As we can see here, we now have a ribbon at the top along with recent tasks.
RBAC Roles
This is a nice function that’s native to the H5 UI – we now have the concept of roles within the roles based access control. A Provider Admin can now “templatize” roles based off of specific functions and make it easier to manage specific tenant rights.
Cross-VDC Networking / Cross vCenter NSX Support
With vCD 9.5, we now have the ability to support xVC NSX objects inclusive of setting this up the vCD UI. Moreover, vCloud Director will instantiate the stretched network functionality to up to four orgVDCs.
This is done from the Provider set up by establishing a network provider scope –
And as expected, requires a single SSO domain between linked vCenters to support cross vCenter NSX. I am underway in my lab to test this out and will have a post soon on demonstrating this functionality and what’s possible.
vCloud Director Cell Appliance!
Yes, you heard that right – with this release we’ve introduced the vCloud Director cell appliance. This is pre-built PhotonOS appliance with the vCD code but still requires your backend vCD database (please use Postgres!), Cassandra, RMQ, and NFS share.
Please also deploy this with the Flex client as I have not seen success with the vSphere H5 client. This is the first iteration and I’m hoping the next version we will see a “database” appliance for the backend functions.
Plugins
I love this, especially when I’m using vCloud Availability for Cloud to Cloud. With 9.5, the UI extensibility continues to grow. There are some amazing plans as it relates to plugin support for our ecosystem partners and I’m seeing MANY of our partners create plugins for vCD. The possibilities are great here to showcase value added services for your tenants.
As we can see below, this is one of my deployments with C2C and showcasing the C2C plugin for 9.5 –
Again, an exciting release for vCloud Director – and more on the way.
I am excited to announce that vCloud Availability for Cloud to Cloud 1.5 (vCAv-C2C) will be released for VMware Cloud Providers at end of September. This has been a long and fruitful journey between strategic design partners and our internal teams.
In this post, I will review what’s new inside of vCloud Availability for Cloud to Cloud 1.5.
To start, our lightboard video as an intro to C2C and what’s new with 1.5 –
A quick summary of what I’ll be discussing:
Enterprise Scale
Service Provider Policies for Offer Management
Seamless and unified experience with integration to vCloud Director
vRealize Orchestrator Integration (Compatible with C2C 1.0)
vRealize Operations Day 2 Monitoring Pack (Compatible with C2C 1.0)
Public API
Enhanced Usage Reporting
Scale
Let’s talk about scalability for C2C for a moment. The BU has certified the following for C2C 1.5 –
110 concurrent failover protections
Over 3,000 active protections across 100 tenants. This is a variable number as it will depend on the number of active tenants along with protected operations. However, in discussing this with Engineering, we’ve seen 4,000 VM’s protected by vCAv-C2C.
Scale up to 7 tested replication instances.
Again, this has been an important enhancement as we have received multiple requests regarding scale. I would also say this is the maximum configuration we’ve tested so far. This does not mean our technology is limited to these numbers. If there’s something specific you’d like to see, please talk to your VMware Cloud Provider field team.
Policies
With C2C 1.5, Cloud Service Providers (CSPs) can now manage access control for vCloud Availability – Cloud to Cloud DR on per tenant organization basis. By default, all tenant organizations are disabled and CSPs can choose to enable C2C DR service for one or many organizations. This allows CSPs to deliver Cloud to Cloud DR as a value-added service to their tenants.
As we can see from above, I have the Default Policy along with “Org1 Policy” that I created that I applied to my Org1 organization.
So, if an org that has not been whitelisted for Cloud to Cloud usage, what do they see? Well, they would get an error when attempting outgoing or incoming replications such as the below:
In addition to white-listing organizations, C2C DR also allows a CSP to create and assign new policies for select organization, thus giving them an opportunity for tiered offering and providing them better control on their capacity management. Following new policies have been added:
Limit the maximum number of outgoing and/or incoming replications per organization
Limited maximum number of replicated VM’s per organization
Limited maximum number snapshots created by VM
Allow to set lower limit on RPO per organization
Again, providing a granular application to specific orgs. We could create multiple policies and have different policies associated with each of them.
Last of all, we can see the compliance state on each org –
Once C2C is deployed and registered to your vCD instance, we will see the Availability link in the context switching menu (or what we like to call the hamburger menu).
From there, the tenant user can navigate to C2C from the vCD interface, thus providing fully integrated and seamless experience and alleviating need of any console hopping.
vRealize Orchestrator Integration
While this is something that will be released post version 1.5, this is an awesome addition as now we can provide unique workflows on a per tenant/use-case basis in an automated fashion. Now, combine this with the power of the new vRO/vCD integration within the Content Library!
From vRO, we can see we have a new section vCloud Availability –
The first thing we would need to do is connect to each respective site –
From here, we have multiple options available that were built by our team, including IP address change after failover:
vRealize Operations Day 2 Monitoring Pack
We are now introducing a management pack for vRealize Operations. This will be also released post version 1.5, however, this will allow the Provider team to have a single monitoring and analytics tool for providing vCAv-C2C statistics and rollups of the environment.
There a few out of the box dashboards available –
From here, we can get a picture of what’s going on from an operational perspective, including any RPO violations set by vCAv policies. While my test environment is clean, this gives you an idea of what to expect.
As a last note – vRealize Orchestrator and vRealize Operations plug-in have their own release cycles and would typically lag a little bit behind the core Cloud to Cloud releases. The vRO and vROPs plug-ins for Cloud to Cloud are currently supported only for C2C 1.0 release). Please reach out to your VMware Cloud Provider field team if you’d like to discuss these further.
Public API
There is now an API available for C2C operations. Public API are generated through Swagger which is quickly becoming a de-facto standard for generating APIs. This allows for additional extensibility to Providers on managing C2C operations along with potential opportunity to integrate their Cloud to Cloud DR use-cases into their own Cloud management portal if this wish to do so.
Start off by going to the API documentation here –
The steps to set up the Swagger client is fairly easy. I was able to do this in a Windows environment by using the PowerShell commands.
Start with downloading the JSON file –
Then, download the swagger-codegen client and run the generate command to generate the Java client –
And now the build is ready for .java files with the C2C parameters. I hope to have time to play around with this further.
Enhanced Usage Reporting
While Usage Meter integration is underway, we can pull reports from the C2C appliances by logging into the application console – documentation is here.
We start by SSH’ing or opening the console to the C2C appliance. From there, we need to authenticate again in the h4 context so we can type in the ‘usage-report’ command –
Now, I am able to run ‘usage-report’ and find out my usage –
Again, a lot of great content and additions to C2C 1.5. Please check it out!
Today, we will be discussing pre-configured firewall rules for vApps inside of vCloud Director (vCD).
Recently, I received a request from a new provider that wants to deploy a specific vApp when they onboard a new tenant (or organization). This specific vApp will need to have NSX Distributed Firewall rules in place – the vApp will be the same for every tenant and will need to be secured accordingly.
While this is a Provider managed approach, this is a very simple way of “stamping” out vApps or other required virtual machines that need specific policies applied to them. Moreover, we would like an automatic way to pick up the associated DFW rules so it’s one less step for the Provider.
Overall Steps:
Creation of a Security Group with Dynamic Membership
Creation of a Security Policy
Activating Security Policy against Security Group
Creating vApp that meets dynamic membership criteria
Creation of a Security Group with Dynamic Membership
Navigate to Menu -> Networking and Security -> Service Composer
The first thing we are going to do is create a Security Group that will associate the VMs based on criteria.
The easiest way to do this is by using a dynamic membership policy. We want to apply this group to any VM’s that meet a specific name. In my example, I’m going to be utilizing “mgmt-pod” as my criteria –
Click Finish, and we are off to the next step.
Creation of a Security Policy
Let’s click on the Security Policies tab inside of Service Composer and create a new Security Policy –
Let’s give it a name – I am using Standard vApp DFW Rules.
From here, we can click on Firewall Rules and create our rules. In my example, I am going to let HTTPS traffic in and block everything else. Typically, for micro-seg rules, we would create granular rules to secure all types of traffic. I am using these just as an example.
Creating DFW policies is fairly straightforward in the Service Composer –
Activating Security Policy against Security Group
Now, we are ready to apply our newly created policy to our group. Click the Apply button while your newly created policy is selected –
From the pop-up window, we will select our Standard vApp Rule group as a Selected Object –
Success – now we can see it has been applied –
From the DFW view, we can see a new section created with associated DFW rules –
Solid note from Tom Fojta – “Do not forget the order of DFW sections is important. If tenant’s DFW VDC section is above and he creates any-any-allow rule it will nullify provider rules. Tenant sections are created by default on top unless forced with API to be created at the bottom.”
Creating vApp that meets dynamic membership criteria
Now from my Provider UI, I am going to go ahead and create my Management vApp for a new tenant. Again, the context is this would be managed by the Provider initially while we are inheriting the Security Group set forth above.
Once my vApp is up, I can verify that I am unable to access via ICMP which meets my criteria. We can see the Standard vApp Rule group was associated with the vApp and I am unable to ping it.
Recently, we received a post on VMware Communities forum for vCloud Usage Meter requesting clarification on the “BND” column on the Virtual Machine History Report. I’d like to spend a little more time discussing this further for others and some of the logic under the covers.
Moreover, I’m going to review a sanitized customer collection and discuss something I even learned.
Luis Ayuso and I spend a lot of time with Usage Meter, so over time, we’ve come intimately close to the inner workings of UM logic (more Luis, follow him for further updates and direction!). While UM has its quirks, it has quite a bit of logic and intelligence integrated for billing purposes.
First, here’s the BND mapping to current VCPP bundles –
Items that I want to point out:
The BND identifier does not reflect the actual bundle point value. This is by design due to the variances of past bundles.
The Standard Bundle is being retired, but will still show up in any existing or previous Usage Meter instances.
While we have a unique ID for the Standard SP Bundle with Management or Networking, the point bundle value remains the same.
The second thing I’d like to cover is the BND column inside of the Virtual Machine History report – this is column P –
We can see in the above screenshot three important columns:
Bnd Column – which is the bundle identifier. In the above example, we see VM’s reporting ID 7, which is the Standard Bundle.
vROps Column – we would see a “Y” or “N” here depicting if this VM is registered inside of vRealize Operations. What we can conclude from the above screenshot is the following:
Running vSphere Enterprise (NOT Enterprise Plus)
vRealize Operations Itemized Breakout
How? Well, Usage Meter will always pick the most cost-effective option as a bundle for the Providers. We know that the 7-point/Advanced Bundle has vSphere Enterprise Plus while the 5-point Standard bundle uses vSphere Enterprise which was EoL’d a few years ago. Moreover, if the Provider utilizes Advanced or Standard vROps, this is not in any VCPP bundle, so this will be itemized billed out. This could also be the Enterprise version since we are using the 5-point bundle.
NSX Column – in this example, we do not have any NSX detection. However, if we did, we would see:
B – NSX SP Base Version. Included in Advanced/7-Point Bundle
A – Advanced SP Version. Included in Standard with Networking (8-Point) OR Advanced with Networking Bundle (9-Point).
E – Enterprise SP Version. Included in Advanced with Networking and Management/12-Point Bundle.
As a quick refresher, here are the different versions of NSX inside of VCPP –
We can see in the below screenshot where the VM state changed – VM was registered inside of vROps. Therefore, the bundle went from BND 8 (Advanced SP) to BND 10 (Standard with Management). Why? Well, it was not utilizing vCloud Director nor NSX, so this is the most cost-effective option for this VM.
Makes sense. Moreover, this is AVERAGED over the month, so if you utilize the Advanced bundle for half of the month while utilizing Standard with Management for the rest, you only pay for the specific hours of use.
Let’s talk about an interesting scenario. I noticed that a VM was “flapping” between BND 7 and BND 13 – that’s a big change. We can see that it’s utilizing vROps and NSX Advanced, but why wasn’t defaulting to a lower point bundle?
Well, Usage Meter will append a new line for VM state change – that includes vMotions. What we can see if this VM vMotion from host-30 to host-31 (sanitized names) but were using different vSphere licenses. Ah ha!
We can see on the top line which is host-30, it was using a vSphere Enterprise license while the next three line items (host-31) were on an vSphereEnterprise Plus license.
Interesting! So, how did this look in the Monthly Usage Report?
We can see NSX Advanced in the Monthly Report. While there is no itemized NSX Advanced in the Product Usage Guide, I believe the Provider would have to just report NSX Enterprise for these VM’s.
So, what did we learn from this scenario? Make sure your licensing is configured in a uniform fashion! This will be very unlikely in the future as Enterprise is not supported after September 2018, but it’s imperative to have proper hygiene for the same hosts in the same cluster.
