Service providers can use storage policies in VMware Cloud Director to create a tiered storage offering like: Gold, Silver and Bronze or even offer dedicated storage to tenants. With the enhancement of storage policies to support VMware Cloud Director entities, Now providers has the flexibility to control how tenant use the storage policies. Providers can have not only tiered storage, but isolated storage for running VMs, containers, edge gateways, Catalog and so on.
A common use case that this Cloud Director 10.2.2 update addresses is the need for shared storage across clusters or offering lower cost storage for non-running workloads. For example, instead of having a storage policy with all VMware Cloud Director entities, you can break your storage policy into a “Workload Storage Policy” for all your running VMs and containers, and dedicate a “Catalog Storage Policy” for longer term storage. A slower or low cost NFS option can back the “Catalog Storage Policy”, while the “Workload Storage Policy”  can run on vSAN.

Starting with VMware Cloud Director 10.2.2, if Provider do not want a provider VDC storage policy to support certain types of VMware Cloud Director entities, you can edit and limit the list of entities associated with the policy, here is the list of supported entity types:

• Virtual Machines – Used for VMs and vApps and their disks
• VApp/VM Templates – Used for vApp Templates
• Catalog Media – Used for Media inside catalogs
• Named Disks – Used for Named disks
• TKC – Used for TKG Clusters
• Edge Gateways – Used for Edge Gateways

You can limit the entity types that a storage policy supports to one or more types from this list. When you create an entity, only the storage policies that support its type are available.

Use Case – Catalog-Only Storage Policy

There are many use cases of using assignable storage policies, i am demonstrating this one because many of providers has asked this feature in my discussions. so for this use case we will take entity type – Media, VApp Template

Adding Media, VApp Template entity types to a storage policy marks a storage policy as being able to be used with VDC catalogs.These entity types can be added at the PVDC storage policy layer. Storage policies that are associated with datastores that are intended for catalog-only storage can be marked with these entity types, to force only catalog-related items in to catalog only storage datastore.

When added: VCD users will be able to use this storage policy with Media/Templates. In other words, tenants will see this storage policy as an option when pre-provisioning their catalogs on a specific storage policy.

• In Cloud Director provider portal, select Resources and click Cloud Resources.
• select Provider VDCs, and click the name of the target provider virtual data center.
• Under Policies, select Storage
• Click the radio button next to the target storage policy, and click Edit Supported Types.

• From the Supports Entity Types drop-down menu, select Select Specific Entities.
• Select the entities that you want the storage policy to support, and click Save.

Validation

Lets validate this functionality by login as a tenant and go into “Storage Policies” settings and here we can see this Org VDC has two storage Policy assigned by provider.

Now lets deploy a virtual machine in the same org VDC and you can see that policy “WCP” which was marked as catalog only is not available for VM provisioning.

In the same Org VDC lets create a new “Catalog”, here you can see both the policies are visible, one exclusively for “Catalog” and another one which is allowed for all entity types.

Policy Removal: VCD users will not be able to use this storage policy with Media/Templates but whatever is there will continue to be there.

This addition to Cloud Director gives opportunity to providers to manage storage based on entity type , This is the one use case similarly one particular storage can be used for Edge Placement , another one could be used to spin up production grade Tanzu Kubernetes Cluster while default storage can be used by CSE native Kubernetes cluster for development container workloads. This opens up new Monetization opportunities for provider, upgrade your Cloud Director environment and start monetizing.

This Post is also available as Podcast

Starting with VMware Cloud Director 10.2.2, Tenants can auto scale applications depending on the current CPU and memory utilization. Depending on predefined criteria for the CPU and memory use, VMware Cloud Director can automatically scale up or down the number of VMs in a selected scale group.

Cloud Director Scale Groups are a new top level object that tenants can use to implement automated horizontal scale-in and scale-out events on a group of workloads. You can configure auto scale groups with:

• A source vApp template
• A load balancer network
• A set of rules for growing or shrinking the group based on the CPU and memory use

VMware Cloud Director automatically spins up or shuts down VMs in a scaling group based on above three settings.This blog post will help you to enable Scale Goups in Cloud Director and also we will configure Scale Groups.

Configure Auto Scale

Login to Cloud Director 10.2.2 cell with admin/root credential and eanble metric data collection and publishing by setting up the metrics collection in a Cassandra database or collect metrics without metrics data persistence. in this post we are going to configure without metrics data persistence, to collect metrics data without data persistence, run the following commands:

#/opt/vmware/vcloud-director/bin/cell-management-tool manage-config -n statsFeeder.metrics.collect.only -v true 

#/opt/vmware/vcloud-director/bin/cell-management-tool manage-config -n statsFeeder.metrics.publishing.enabled -v true

Now the second step is to create a file named “metrics.groovy” file in the /tmp folder of cloud director appliance with the following contents:

configuration {
    metric("cpu.ready.summation") {
        currentInterval=20
        historicInterval=20
        entity="VM"
        instance=""
        minReportingInterval=300
        aggregator="AVERAGE"
    }
}

Change the file permission appropriatly and import the file using below command:

$VCLOUD_HOME/bin/cell-management-tool configure-metrics --metrics-config /tmp/metrics.groovy

Lets enable auto scalling plugin by running below commands on Cloud Director Cell:

$VCLOUD_HOME/bin/cell-management-tool configure-autoscale --set enabled=true
$VCLOUD_HOME/bin/cell-management-tool configure-autoscale --set username=<username> (should having admin priveldge account)
$VCLOUD_HOME/bin/cell-management-tool configure-autoscale --encrypt --set password=<password> ( Password for the above account)

If you see in the Cloud Director provider console, under customize portal , there will be a plugin which provider can enable to tenants who needs auto scale functionality for the applications or can be made available to all tenants.

Since Auto Scale released with VMware Cloud Director 10.2.2, which allows service providers to grant tenant rights to create scale groups.Under Tenant Access Control, select Rights Bundles and then select the “vmware:scalegroup Entitlement” bundle, and click Publish.

Also ensure provider Add the necessary VMWARE:SCALEGROUP rights to the tenant roles that want to use scale groups.

Tenant Self Serive

On the Tenant portal after login, select Applications and select the Scale Groups tab and Click New Scale Group.

Select an organization VDC in which tenant want to create the scale group.

Or Tenant can also access scale groups from a selected organization virtual data center (VDC) by going in to specific organization VDC

• Enter a name and a description of the new scale group.
• Select the minimum and maximum number of VMs to which you want the group to scale and click Next.

Select a VM template for the VMs in the scale group and a storage policy, and click Next. Template needs to be pre-populated in catalog by tenant or can be by provider and published for tenants.

Next step is to select a network for the scale group.If Tenants oVDC is backed by NSX-T Data Center and NSX ALB (AVI) has been published as a load balancer by provider, then tenant can choose NSX ALB load Balancer edge on which load balacing has been enabled and Server pool has been setup by tenant before enabling Scale Groups.

If tenant want to manage the load balancer on your own or if there is no need for a load balancer, thenn select I have a fully set-up network, Auto Scale will automatically adds VM to this network.

VMware Cloud Director starts the initial expansion of the scale group to reach the minimum number of VMs, besically it will start creating a VM from template that tenant selected while creating scale group and it will continue to spin up to minimum number VM spacified in the scale group section.

Add an Auto Scaling Rule

1. Click Add Rule.
2. Enter a name for the rule.
3. Select whether the scale group must expand or shrink when the rule takes effect.
4. Select the number of VMs by which you want the group to expand or shrink when the rule takes effect.
5. Enter a cooldown period in minutes after each auto scale in the group.The conditions cannot trigger another scaling until the cooldown period expires and cooldown period resets when any of the rules of the scale group takes effect.
6. Add a condition that triggers the rule.The duration period is the time for which the condition must be valid to trigger the rule. To trigger the rule, all conditions must be met.
7. To add another condition, click Add Condition. tenant can add multiple conditions.
8. Click Add.

From the details view of a scale group, when you select Monitor, you can see all tasks related to this scale group. For example, you can see the time of creation of the scale group, all growing or shrinking tasks for the group, the rules that initiated the tasks, in side Virtual Machine section which VM has been created at what time and what is the IP address of the VM etc…

here is the section showing scale takes which trigered and its status.

Virtual Machine section as said provides scale group VM information anf its details.

here is the another section showing scale takes which trigered and thier status , start time and completion time.

Auto Scale Group in Cloud Director 10.2.2 brings very important functionality nativily to cloud director which does not require any external configuration like vRealize Orchestrator or vRops and does not incure addional cost to tenant or provider. go ahead uprade your cloud director , enable it and let the tenant enjoy this cool functionality.

In continuation of my last post on the same topic, in this post we will deploy and configure Cloud Director App Launchpad.

With App Launchpad VMware cloud providers can now deliver their own catalog based applications or VMware Cloud Marketplace certified 3rd party Cloud Applications, and Bitnami catalog applications directly to customers through a simple catalog interface from a VMware Cloud Director plugin. This capability allows Cloud Providers to deliver application Platform as a Service to customers who needn’t know anything about the supporting infrastructure for the catalog applications they deploy.

NOTE – In this release Tenant using App Launchpad 1.0, can launch single-VM applications.

Prerequisites for App Launchpad Installation

Before we install and configure App Launchpad, it requires few external components and supports specific versions that you must deploy and configure.

• Create a new Virtual Machine with below requirement
  • 
• Ensure Rabbit MQ is installed and configured under Cloud Director extensibility before deploying App Launchpad.

• Inside same Rabbit MQ Server create a new Exchange with type as “direct” and a dedicated AMQP user that has full permissions to the virtual host of the AMQP broker.

  • This slideshow requires JavaScript.

Install Cloud Director App Launchpad

Deployment of  App Launchpad can be done by installing an RPM package on a dedicated Linux virtual machine.Download Application Launchpad from here and transfer the file to ALP server and installation is very simple process:

• Open an SSH connection to the installation target Linux virtual machine and log in by using a user account with sufficient privileges to install an RPM package.
• Install the RPM package by running the installation command.
  • yum install -y vmware-vcd-alp-1.0.0-1593616.x86_64.rpm
  • 

Connect App Launchpad with Cloud Director

To configure App Launchpad with Cloud Director, we will use the alp command line utility. By using this utility:

• We will establish a connection between App Launchpad and VMware Cloud Director
• Define or create the App-Launchpad-Service account
• and install the App Launchpad user interface plug-in for VMware Cloud Director.
• The alp connect command also configures App Launchpad with your AMQP broker.

• #alp connect --sa-user alpadmin --sa-pass <PASSWORD> --url https://10.96.98.50 --admin-user admin@system --admin-pass <PASSWORD> --amqp-user alp --amqp-pass <PASSWORD> force --amqp-exchange alpext

• Accept “EULA” and “certificate”
  • 
• if you have put correct information then it should show successfully configured
• Restart ALP service using

  • #systemctl restart alp

• You can run #alp show to verify the connection
  • 

Configure App Launchpad

• Now you can go to Cloud Director and check installed ALP plugin in Cloud Director.
  • 
• Click on “LAUNCH SETUP” to configure it to offer Applications as a Service
• If you want to configure the infrastructure for App Launchpad automatically, select Yes and software will setup everything automatically.
  • 
• In case you chosen “No i will set it up on my own”, pre-requisite you need to setup manually.
  • 
• App Launchpad supports the use of applications from the Bitnami applications catalog that is available in the VMware Cloud Marketplace.

  You can also create catalogs of your custom, in-house applications and configure App Launchpad to work with these catalogs.

• Create sizing templates for the applications.
  1. Enter a name for the sizing template.
  2. Enter a vCPU count, a memory size (in GB), and a disk size (in GB)
• To complete the initial configuration of App Launchpad, click Finish.

  • This slideshow requires JavaScript.
• If everything is goes fine and have enough resources in Cloud Director , you will see “App Launchpad Setup Complete”
  •  

Onboarding Bitnami Applications

VMware Cloud providers can import applications from the Bitnami applications catalog that is available in the VMware Cloud Marketplace. To begin, provider must log in to the VMware Cloud Marketplace and subscribe to the Bitnami application you wish to deploy. Follow these steps:

• Log in to the VMware Cloud Marketplace.
• From the “Catalog” page, find the Bitnami application you wish to deploy (With App Launchpad 1.0, tenant users can only run single-VM applications) and select it to subscribe.

• On the “Settings” page, choose “VCD” as the platform and select the correct version. Set the subscription type to “BYOL”. Click “Next” to proceed.

  • This slideshow requires JavaScript.
• The subscription will now be added to your Cloud Director App Launchpad organization , which tenants can use it.
• Make sure the “App Launchpad” organization has right permission.
  • 

Onboarding In-house Applications

Cloud Provider can also add your own in-house applications to the content library of the “AppLaunchpad" provider organization and upload your applications manually , to do so

• Provider admin need to Navigate to the “Content Libraries -> vApp Templates” page and click on “NEW”..
  • 
• By default, in-house applications neither has logo nor has summary.
  • 

To give these apps better user experience, service provider can set metadata on vApp templates by GUI or vCloud API , here is GUI Way to do so:

• Go to Content Library and click on application which you have recently updated and go to metadata and click on “Edit” and add following items:
  • 
  • title – Title of Application
  • summary – Summary of Application which will be displayed on Application tile.
  • Description – Description of Application
  • version – Displays version number of Application.
  • logo – Provider can choose a logo using Internal/External web location like S3.
  • screenshot – Provider can choose default snapshot using Internal HTTP/HTTPs server or External web location like S3
• 

This completes the installation and configuration of Cloud Director App Launchpad and as i said in my last post – App Launchpad is a free component for VMware Cloud Director, and doesn’t necessitate the use of Bitnami catalogs, providers can use their own appliances, so go ahead and give it a try, start delivering a PAAS like solutions to your Tenants.

In the Part-1 & Part-2 we configured HyTrust KeyControl Cluster & vCenter, In this post we will configure Cloud director to utilize what we have configured till now…

Attach Storage Policy to Provider VDC

To update the information in the vCloud Director database about the VM storage policies which we had created in underlying vSphere environment, we must refresh the storage policies of the vCenter Server instance.

• Login to Cloud Director with cloud admin account and go to vSphere resources and choose vCenter on which we had created policies and click on “REFRESH POLICIES”
  • 
• You can add a VM storage policy to a provider virtual data center, after which you can configure organization virtual data centers backed by this provider virtual data center to support the added storage policy.
  • Login to Cloud Director, go to Provider VDCs and choose PVDC which is backed by the cluster where we had created storage policies.
  • Click on “ADD”
  • 
• Choose the Policy that we created in previous post.
  • 
  • 

Attach Storage Policy to Organization VDC

You can configure an organization virtual data center to support a VM storage policy that you previously added to the backing provider virtual data center.

• Now click on Organization VDCs, and click the name of the target organization virtual data center like 
  • 
• Click the Storage tab, and click Add.
  • 
• You can see a list of the available additional storage polices in the source provider virtual data center
• Select the check boxes of one or more storage policies that you want to add, and click Add.
  • 

Self Services Tenant Consumption

When Provider’s tenant try to create a VM/vAPP (A virtual machine can exist as a standalone machine or it can exist within a vApp) , he can use the encryption policy that we have created previously.

• This is new VM creation wizard from template , Tenant user must choose “use custom storage policy” and select the “encryption policy”
  • 
• Once VM is provisioned , user can go and check the Storage policy by clicking on VM.
  • 
• User can also go in to “Hard Disk” section of VM and check disk policy.
  • 

Encrypt Named Disks

Named disks are standalone virtual disks that you create in Organization VDCs.When you create a named disk, it is associated with an Organization VDC but not with a virtual machine. After you create the disk in a VDC, the disk owner or an administrator can attach it to any virtual machine deployed in the VDC. The disk owner can also modify the disk properties, detach it from a virtual machine, and remove it from the VDC. System administrators and organization administrators have the same rights to use and modify the disk as the disk owner.

• Here we will create a new encrypted “Named Disk” by choosing storage policy as “Encryption Policy”.
  • 
• Cloud Director allow users to connect these named disks
• Click the radio button next to the name of the named disk that you want to attach to a virtual machine, and click Attach
• From the drop-down menu, select a virtual machine to which to attach the named disk, and click Apply.
  • 

This competes three part Cloud Director encryption configuration and use by the tenants , this features enables VMware Cloud Providers new offering and monetisation opportunities, go ahead , deploy and start offering additional/deferential services.