Find Communities by: Category | Product

1 2 Previous Next

Everything Cloud at Dell EMC

17 Posts authored by: SteveHeg

This post demonstrates how to create proactive alerts and notifications for DELL EMC ViPR within VMware vR Ops, and also how to link associated resolutions to the VMware vRA service catalog.

DELL EMC ViPR provides a Management Pack for VMware vRealize Operations Manager (vR Ops). Through this MP, ViPR inventory, metering, and event data is imported into vR Ops and displayed through pre-configured dashboards that show collections of volume, storage port, storage system, and virtual pool data. vR Ops uses the data to compute key resource status scores. Resource details, individual metrics, and EMC ViPR event alerts are also presented in dashboard views. This is covered in more detail here.


Above is an example of one of the dashboards, ViPR - Capacity, available with the ViPR MP, but what this MP also allows us to do in vR Ops is to create alert definitions based on objects that the ViPR MP proactively monitors.

The first step is to navigate in the vR Ops UI to Content > Alert Definitions, click the Green + icon to create a new Alert Definition


This brings us to the vR Ops Alert Definition Workspace, from where we can customise our Alert to suit our requirements. The vR Ops UI provides an easy to use wizard to guide the user through the creation of an Alert Definition, walking the user through the various properties required, as displayed below:


Enter an appropriate Name and Description for the Alert. For example if we are creating an Alert for the Capacity remaining on a ViPR volume, then we can call it "ViPR Volume Capacity Remaining Low".

For the Base Object Type, we can drill down into the EMC ViPR Adapter, and from the available objects, we can select "Volume"


For the Alert Impact, we can set the  following:

  • Impact: Risk
  • Criticality: Symptom Based
  • Alert Type and Subtype: Storage Capacity



Scroll through the Symptom Definitions, select the appropriate line item, before dragging it over to the Symptoms box on the lower right-hand panel.

With the symptom definitions complete, we can then move onto inserting some of our own Recommendations in terms of resolving the ViPR issue that is being reported. Click the Green + icon


In the text field, simply enter the detail around the suggested recommendation, as shown above. Note: This is an example only, and not an official resolution

For extra bonus points, for the Enterprise Hybrid Cloud solution, we can also link this recommendation to the vRA portal, and point the user the EHC Storage-as-a-Service catalog item. This can be done by highlighting some of the text, click the Hyperlink icon above the textfield, and enter the appropriate URL (e.g. https://<vRAvipFQDN>/vcac/org/<tenantName>/) as shown below:


Once the hyperlink is complete and you are happy with the content of the recommendation, click Save.

From the list of available Recommendations on the left side of the screen, filter for or scroll through the list to find the Recommendation that you just created, and drag it into the Recommendations field on the right side of the screen, as shown below:


On clicking this hyperlink, the user, if entitled to EHC STaaS operations (e.g. the vR Ops user would also have EHC STaaS privileges), would immediately be routed to the EHC portal, from where they could provision additional storage, as shown below:


More information on EHC Storage as a Service can be found here.

Once we have the Alert Definition(s) in place, the final step is to configure the notifications for those alerts.

Back in the main Content section of the vR Ops UI, navigate to Notifications, and click the Green + icon.

We are presented with an Add Rule window within which we can enter a suitable name for the notification e.g. ViPR Volume Capacity Remaining Low, select the notification method using either of the Rest Notification or Standard Email plugins, and of course the Recipients of the Notification.


In the Filtering Criteria section, select Object Type and drill down into the ViPR Adapter object tree to select Volume.

For Notification Trigger, select Alert Definition, filter by 'vipr' and select the Alert Definition that was created previously e.g. ViPR Volume Capacity Remaining Low.

Happy with everything? Click Save. You're done.

I hope that this quick example helps. The EHC solution supports many vR Ops Management Packs (e.g. vRA, NSX, ViPR, ESA:Avamar, ESA:RP4VM, VCE, vCloud Air, etc, more covered here) which provide us with the ability to create custom alerts and notifications across the entire Hybrid Cloud solution.


More vR Ops Alerting resources:

Official VMware documentation here

The release of Enterprise Hybrid Cloud v4.0 has enabled EHC customers to leverage EHC services across multiple sites. This multi-site functionality is one of the major themes for the v4.0 release and is based upon the ability to provide EHC services to multiple vCenter endpoints.

This post will explain some of the options available to EHC customers.

The EHC user portal and service catalog uses VMware vRA, which has the native ability to connect to multiple endpoints. These endpoints can be private or public, and include platforms such as vCenter, KVM, Hyper-V, Amazon EC2, OpenStack, vCloud Air, or  vCloud Director.

EHC services are VMware vCenter-based for the private cloud, and leverage vCloud Air for Public Cloud services. For private cloud instances, EHC offers the following services:


Of course vRA itself has always been able to connect to multiple vCenter endpoints and sites. This meant that those endpoints could offer mainly IaaS, but didn't have the ability to leverage the automated Data Protection or Storage Services that EHC provides.


Enterprise Hybrid Cloud MultiSite Services


As of EHC v4.0, the full EHC services are available for up to 4 vCenter Server endpoints, enabling customers to provision workloads to multiple sites from a single Catalog, with each site capable of full EHC services.

EHC services can implemented in different combinations across the sites, with various protection services. Some sites may have replication for Disaster Recovery, some with Continuous Availability, or a mix of each as required. The following are some (not all) examples:

Example 01: 4 Sites / 4 vCenter Endpoints / No inter-site replication


In example 01 we have 4 separate sites, each with their own CI platform(s) which could be VxBlock or VxRack. Each site is independent from the other, with no replication or recovery between sites.

Most EHC management components are located at the primary site, with remote agents (vRA), collectors (vR Ops) and forwarders (Log Insight) deployed at the remote sites as appropriate on smaller scale EHC Management clusters. Advanced networking services with VMware NSX are possible on each of the sites where the platform allows it (Currently VxBlock only. VxRack coming soon!).

All EHC services are available from the single portal and service catalog as follows:

  • IaaS -  Virtual machines can be deployed to each of the sites
  • BaaS - Each site also has it's own Avamar instance to enable BaaS at each site, where all VM backups will be to the local Avamar instance.
  • STaaS - Storage is managed and provisioned to all sites from the primary ViPR instance, with SMI-S components deployed local to each site if/where required.
  • Custom services are possible at each of the sites. EHC uses a clustered vRO instance at the primary site. Additional vRA DEMs can be deployed at the remote sites as required for custom (non-Out-of-the-Box EHC) work.



Example 02: 4 Sites / 4 vCenter Endpoints / 2-site VM-level Inter-site DR


In example 02 we have 4 separate sites, each with their own CI platform(s) which could be VxBlock or VxRack. Disaster Recovery services are configured between Site A and Site B, proving replication and full DR capabilities for all cloud management services as well as the tenant workloads.

EHC DRaaS can be implemented using either RecoverPoint with VMware SRM providing storage-level replication, or with RP4VM providing VM-level replication. Where VMware NSX is used, EHC DRaaS with RP4VM leverages Cross-vCenter NSX with Universal Objects.

Again, all EHC services are available from the single portal and service catalog as follows:

  • DRaaS - Disaster recovery services are available, bi-directional, between the DR-paired sites, allowing production services to run on each site, using each other as their DR target. All EHC management services, tenant VMs, and backups are protected across sites, so in the event of a full site failover, all Cloud services, including portal and provisioning services resume as well as the tenant workload VMs.
  • IaaS -  Virtual machines can be deployed to each of the sites. DR-protected VMs on Site A or Site B will be replicated to their DR site (A to B, and B to A)
  • BaaS - Each site also has it's own Avamar instance to enable BaaS at each site, where all VM backups will be to the local Avamar instance. For the DR-protected Sites, VM backups are replicated to their DR partner site, to be used for continued backup services in the event of a site failover/recovery.
  • STaaS - Storage is managed and provisioned to all sites from the primary ViPR instance, with SMI-S components deployed local to each site if/where required. All sites can contain local-only storage, while Site A and Site B can use RP/SRM protected storage also. If RP4VM is used for DRaaS, then the replication is at the VM-level, not the storage level.
  • Custom services are possible at each of the sites. EHC uses a clustered vRO instance at the primary site. Additional vRA DEMs can be deployed at the remote sites as required for custom (non-Out-of-the-Box EHC) work.



Example 03: 5 Sites / 4 vCenter Endpoints / CA / DR / Single Site

EHC_Multisite - EHC_Global_Blocks_Racks02-FullDR_CA_SS.png

This example may sound a bit strange at first, as in "How do we manage 5 sites, with 4 vCenter server Endpoints?".

To explain: EHC Continuous Availability use a single vCenter Server endpoint, but stretches all operations across 2 sites, using VMware vMotion and HA combined with VPLEX Metro to stretch the solution.

In example 03 we have 5 separate sites, each with their own CI platform(s), with 2 different protection levels configured between the sites, as well as single ROBO site.

  • Disaster Recovery protection services are configured between Site A and Site B, providing replication and full DR capabilities for all cloud management services as well as the tenant workloads.
  • Continuous Availability protection services across Site C and Site D, providing disaster avoidance protection for the EHC solution.

Again, all EHC services are available from the single portal and service catalog as follows:

  • DRaaS - Disaster recovery services are available, bi-directional, between the DR-paired sites, allowing production services to run on each site, using each other as their DR target. All EHC management services, tenant VMs, and backups are protected across sites, so in the event of a full site failover, all Cloud services, including portal and provisioning services resume as well as the tenant workload VMs.
  • Continuous Availability - A single EHC instance is stretched across both sites, providing the ability to  online migrate/vMotion all systems, both Management and tenant, from either site to the other.
  • IaaS -  Virtual machines can be deployed to each of the sites. DR-protected VMs on Site A or Site B will be replicated to their DR site (A to B, and B to A). CA-protected VMs will be deployed to either Site C or SiteD, with the ability to vMotion to the other site (C to D, or D to C)
  • BaaS - Each site also has it's own Avamar instance to enable BaaS at each site, where all VM backups will be to the local Avamar instance. For the DR and CA-protected Sites, VM backups are replicated to their partner site, to be used for continued backup services in the event of a site failover/recovery.
  • STaaS - Storage is managed and provisioned to all sites from the primary ViPR instance, with SMI-S components deployed local to each site if/where required. All sites can contain local-only storage, while Site C and Site D require stretched (VPLEX Metro) storage also for CA operations. When RP4VM is used for DRaaS, then the replication is at the VM-level, not the storage level.
  • Custom services are possible at each of the sites. EHC uses a clustered vRO instance at the primary site. Additional vRA DEMs can be deployed at the remote sites as required for custom (non-Out-of-the-Box EHC) work.


That's a lot of services and a lot of protection for a lot of virtual machines, all managed from a common portal!

There are other options for a multisite EHC deployment, but the options listed above should provide a good idea of the flexibility possible with the available protection levels.

Keep in mind that Public Cloud endpoints can also be leveraged within the solution, as well as standard vCenter endpoints in vRA that can be used for IaaS (e.g. VxRail). This is where the endpoints could start to expand somewhat:


The maximum number of Virtual machines that vRA can manage: 50,000 VMs

The general maximum for vCenter endpoints is 10, which is not a vRA or EHC limit, but a VMware SSO limit. This is due to the to the maximum number of vCenter servers supported in a single VMware SSO domain is 10.

Below is a summary of which services are possible on which CI platforms (at this time):

  • VxBlock: IaaS, STaaS, BaaS, DRaaS, CA, NSX
  • VxRack Flex: IaaS, STaaS, BaaS, DRaaS (RP4VM only)
    • Why no CA? VPLEX does not support ScaleIO
    • Why no DR with RP/SRM? ScaleIO does not have an RP splitter
    • Why no NSX? Coming soon
  • VxRail: IaaS
    • Why no STaaS? ViPR does not support VSAN
    • Why no BaaS? EHC code changes required (It's a future!)
    • Why no CA? VPLEX does not support VSAN
    • Why no DR with RP/SRM? VSAN does not have an RP splitter


More detailed information can be found in the EHC v4.0 Concepts and Architecture Guide.

Hope that helps!

We wanted to upgrade our EHC lab instance of vRealize Business Standard (v6.2.3) to vRealize Business for Cloud (v7.1.0). Using vRB v7.x has been a common request for some of our Financial customers who required vRB to support the Swiss Franc.

So after a quick glance at the vRB 7.x Install Guide, we realised that this is a migration, not an upgrade.

The fact that a migration is required is not entirely clear if you (don't read the docs and jump straight in!) try to upgrade vRB directly from the vRB Appliance.


If you go to the Update tab within the vRB web console @ https://<vRB_IPAddress>:5480 it would be fair to assume that you could perform a simple upgrade. To Assume makes an *** out of u and me ... etc etc


So as per the vRB Install Guide, we need to deploy new vRB appliance first, and then migrate to it.

Why? The earlier versions of vRealize Business Standard were based on 11 SLES, whereas, the 7.0 and later versions are based on SUSE Linux Enterprise Server (SLES) 12. So, the 6.2.3 upgrade process to 7.x.x involves deployment of the server and then migration of data.

Anything else to be aware of? After you upgrade, the cost trend of demand analysis and its details are lost. Also, the Demand Analysis option is renamed to Consumption Analysis with additional features.

vRA v6.2.3 is now supported with vRB v7.1, as per the VMware Interop Matrix, so we deployed the new ova for vRB v7.1.0.

For the record/posterity etc, this is what the old vRB v6.2.3 dashboard looks like in vRA


Onwards and upwards then!

This new instance of vRB v7.1 needs to initially run in parallel to the older instance of vRB v6.2.3, so we had to use a new IP address and FQDN. We updated DNS of course, and proceeded to deploy the new vRB v7.1 ova.

Once the new instance of vRB v7.1 was deployed and ready, we logged into the appliance @ https://<newvRBIPAddress>:5480 and navigated to the Migrator tab


From there we entered the details of the old/original vRB v6.2.3 instance, clicked Migrate, and waited a few minutes before being presented with a Data Migration Completed message, as shown below:


Next step stated in the vRB Install doc is to register this vRB instance with vRA, but for our environment, we needed to create and apply CA-signed certificates for this new vRB v7.1 machine, so we did that first.

I know, I know, you really don't want to create and use a signed CA cert, but you should. You really should. Deep breaths, it will be ok

So once we had our certificate request (.csr file) created, we submitted it to our local CA server, using the correct Certificate template.


Once submitted, we downloaded the certificate locally as 'Base 64 encoded', and renamed the file to rui.crt (this requires changing the file extension).

Next step is to replace the certificate on the vRB v7.1 appliance. Browse to the vRB web console @ https://<newvRBIPAddress>:5480 and navigate to Administration > SSL. For this we need 2 files:

  • rui.key (created earlier with the certificate request)
  • rui.crt


As indicated in the screenshot above, copy and paste the entire contents (including the BEGIN and END lines) of the rui.key and rui.crt files into the RSA Private Key and Certificate fields respectively.Click Replace Certificate, and hopefully, if all is well, the certificate wil be replaced successfully, as shown below:


So onto the next step which is to register vRA and SSO credentials with this new vRB v7.1 machine.


Browse to the vRB web console @ https://<newvRBIPAddress>:5480 and navigate to Registration > vRA from where we need to enter the following credentials:

  • Hostname e.g vRealize Automation Server (vra-vip-FQDN)
    • Important note - Use the vRA vip, not the machine name!
  • SSO Default Tenant e.g. vSphere.local
  • SSO Admin User e.g. administrator (case sensitive!)
  • SSO Admin Password

Once entered, click Register, and all being well, vRA will register with vRB successfully, as shown below:



Note: It was at this stage that I remembered to shutdown the original instance of vRB v6.2.3. This could probably have been done as soon as the Migration completed successfully, but I didn't see it mentioned anywhere!

All good so far, next step is to check the Business Management tab in vRA

Log into vRA portal e.g. https://vipvra.ppsilver.lab.local/vcac/org/<tenantURL> as a vRA Tenant Admin, click on the Business Management tab, and you should be presented with a field requiring the license to be entered, as shown:


Enter the license, and away you go with a spanky new vRB for Cloud user interface, as shown:



Business Management Overview





vRB Cloud Comparison



On the licensing front be aware of the management capabilities between the vRB for Cloud Standard and Advanced editions, as highlighted below:


More vRB for Cloud comparison information here

vRB v7.1 Release Notes here

So that's it for the upgrade from vRB Standard to vRB for Cloud. Long gone are the days of ITBM, everything is Cloud now!

Will need some time to play around with this new version to see what else we can do or what else may need to be fixed. Right away I have spotted a red status alert for vCenter that needs some TLC!

Hope that helps anyway!

The Enterprise Hybrid Cloud solution provides fully automated data protection backup and restore services for virtual machines, with EHC Backup as a Service (BaaS).

At virtual machine deployment time, cloud users in the vRealize Automation self-service portal, can choose to protect their machines with a predefined backup service level. This automatically adds data protection backup to their virtual machine, but also enables them to initiate on-demand, point-in-time backups and restores of their virtual machines.



To provision a VM with data protection backup, all that a cloud user need do is select the relevant catalog item from their vRA catalog, and select the Backup Service Level that they want to apply to their new virtual machine, as shown below:



Note: Creating  Backup Policies/Service Levels (BSL) is covered here @ Enterprise Hybrid Cloud: Creating a Backup Service Level

Once the VM is deployed, the user can avail of the Day-2 VM on-demand actions such as Point-in-time Backup and Restore, as well as an on-demand backup report, as shown below:



Note: EMC Data Protection Advisor provides 2 additional reporting services at the VM level, but DPA is not installed in this environment right now

So that's what the user sees once the VM is deployed, but what was done to get here?

First of all the VM Blueprint had to be created by a user with the Business Group Manager or Service Architect role. When configuring the VM Blueprint, the BackupandRestoreFunctions Build Profile was selected under Blueprint>Properties>Build Profiles, as shown below:




Note: The SiteAffinityFunctions Build Profile is separate to BaaS, and is specific to multi-site with EMC VPLEX.

This build profile is one of the many packages installed as part of the EHC Data Protection Backup package in vRealize Orchestrator. It is the customisations and workflows called from within that Build Profile that enable the BaaS features at VM deployment time, as well as the Day2 on-demand VM actions.

When the user requests a new VM from the vRA catalog, using this VM Blueprint, then a number of post-deployment tasks are involved. The new VM is automatically added to the corresponding vCenter folder and Avamar Policy, as shown below:


EHC_AvamarUI_BackupPolicy_vCenter - New Page

Note: VMs without EHC BaaS will by default be placed in the VRM folder in vCenter

The storage on which the new VM has been deployed will already have been configured for backup on the Avamar Proxy servers. This configuration is part of the STaaS workflow and operations.

The first virtual machine backup will execute according to the Backup Service Level schedule. This will be a full backup, with all subsequent backups being incremental.

The vRA user experiences no interruption in VM services during the VM backup, and is unaware of the tasks being automated in the background. Below is how the backup operation looks in the Avamar UI:


For Avamar to take an image-level VM backup requires a vm snapshot to be created. Below are the tasks visible in vCenter where the vm snapshot is created and mounted to the Avamar proxy server, before being unmounted and removed.


Coming back to the vRA user, the owner of the protected VM, they also have the ability to create on-demand backups in addition to the scheduled backups.


From their vRA portal under VM Actions an On-Demand Backup can be requested quickly and easily. Click on the action, and enter request details, as shown below:



The vRA user can view and select from the available backups for VM restore as required. Below is an example of requesting Backup Status, which will send an email to the user:


By the way, this is what those same backups look like in the Avamar UI:



The vRA user can also initiate an On-Demand Restore which will query Avamar for available backups for the selected VM, and present them with the available point-in-time backups from a drop-down menu in vRA, as shown below:


While these on-demand actions are available to the vRA users, it is possible to restrict various actions using the vRA Entitlements. So for example if a particular user group were to be allowed to backup their VMs, but not restore their VMs on-demand, then this could be configured under the vRA Entitlements, as suggested below:


Note/Bug: In vRA, if a user/usergroup is entitled to certain VM-level actions e.g. EHC BaaS, then these actions will be displayed for any other VMs that user owns that do not use EHC BaaS. This will not break anything, as the actions will simply fail. Not sure at this time if this issue is resolved in later versions of vRA.

For Dual-Site EHC environments, whether it's DR using RecoverPoint, or Continuous Availability/Disaster Avoidance using VPLEX, all VM backups and VM-level services are replicated and fully available after a DR or migration event. This requires EMC Avamar appliances on both sites, with replication configured between them.

That's it for this post, hope that helps understand EHC BaaS a little better!


Originally posted @ Scamallach

The latest release of EMC Storage Analytics (ESA) for VMware vRealize Operations Manager went GA May 2nd 2016, and among the many new features and supported objects is EMC Avamar.

This post will walk through the installation and configuration of the Avamar Adapter in vR Ops and show some of the available Avamar dashboards.



  • vRealize Operations v6.1 or 6.2.0a
  • vCenter v5.5/6.0
  • ESA v4.0.2
  • Avamar v7.2

As mentioned in EMC Storage Analytics & vR Ops each EMC product within the ESA requires it's own adapter instance, and each of those adapter instances depends upon/requires the EMC Adapter instance for vCenter.


As shown above, where the ESA vCenter adapter is named EHC Cloud vCenter, this adapter instance does not pull in any metrics, it's only job is to map the relationships between the EMC adapter components and the VMware vCenter objects. Make sure to add the EMC/vCenter adapter first!.

Install the Avamar Adapter Instance


Once the EMC ESA itself has been installed, to add the required Adapter for Avamar, in the vR Ops Admin UI go to Administration > Solutions, select the EMC Adapter and click the Green + icon

  • Provide a suitable display name
  • Use the IP address of the Avamar server where MCS is running
  • Use the credentials of the MCUser account, or another Avamar Administrator user e.g. app_vrops_avamar@PPSILVER.lab.local (member of my Avamar Admins AD Group)



Click Test Connection and if successful, click Save Settings

Note that Avamar must be running v7.2. I tried to configure this on Avamar v7.1.1 but couldn't get the connection to succeed!

Once configured you should see the Adapter collecting and receiving, as shown below:



Using the Avamar Dashboards


So now onto the good part, using the Avamar Dashboards in vR Ops, which can be accessed from the Dashboard List drop-down menu, as shown below:


There are 4 Avamar dashboards available:

  • Avamar Metrics
  • Avamar Overview
  • Avamar Properties
  • Avamar Topology


Avamar Metrics



The Avamar Metrics dashboard provides the user with the ability to select from the available Avamar objects and view the related metrics.

Avamar Overview



The Avamar Overview dashboard provides various heatmaps, scorecards and status widgets, displaying information relative to most Avamar operations, such as success/failure of backups and restores, capacity used/protected, etc.

Avamar Properties



The Avamar Properties dashboard displays every object discovered and monitored by the Avamar Adapter. The user can discover/view the Properties associated with each object and drill down for further detail.

Avamar Topology



The Avamar Topology dashboard enables the user to select any of the discovered Avamar objects (e.g. Avamar Client), and view their relationship with other Avamar objects (e.g. Backup Policy/Group) as well as associated VMware vCenter objects such as the protected Virtual Machine. The overall topology mapping and relationships of the Avamar adapter instance are as shown below (taken from ESA Admin Guide):


What this diagram illustrates is the relationship(s) between any of the discovered Avamar objects. So if you select any one of them, you will see the associated parent/child object or VMware relationship. All of these Avamar objects are available for any vR Ops user that wants to create their own custom dashboards.ESA/VMAX customers, go look at the great VMAX-orientated ESA 4.0 post from my colleague Drew Tonnesen here.


The ESA v4.0 is supported right now with vR Ops v6.1 and v6.2.0a. From an Avamar perspective, only Avamar v7.2 is supported.Existing ESA/VMAX2 or EMC/VPLEX customers looking to upgrade to ESA v4.0, or to install new, should be aware that ESA v4.0 no longer provides support for VMAX2, and only supports VPLEX GeoSynchrony v5.4.1.



Hope that helps!


Originally posted @ Scamallach

One of the services provided by the Enterprise Hybrid Cloud Solution (EHC) is Backup-as-a-Service (BaaS), which enables cloud users to manage and consume data protection backup services through a single user portal. The EHC solution leverages service levels throughout the solution, using policies to control resources such as compute, storage, network, and data protection.

In the EHC solution, a Backup Service Level = an EMC Avamar Backup Policy, but there's a bit more gets configured under the covers.


EHC Cloud Backup Administrators can create Backup Service Levels through the VMware vRealize Automation (vRA) portal without ever accessing the EMC Avamar Administrator UI. The Backup Service Levels should be configured to satisfy business requirements. Not all virtual machines and applications will require the same level of data protection, therefore it is normal to have multiple backup service levels.


EHC users who have entitlements to the Data Protection Backup service in vRA can select the 'Create Backup Service Level' catalog item to initiate the request.

The user will then be guided through a configuration wizard which will prompt for all of the necessary inputs required to create the appropriate Avamar Backup Policy. Once the user has entered a name for the Backup Service Level, which should be descriptive (e.g. 2xDailyBackup, MonthlyBackup,  etc), they can then select the Backup Target which can be either Avamar itself, or a Data Domain.


The next couple of steps then create and define the schedule and retention period for the new backup service level.


The Backup Schedule provides 3 options:

  • Daily - specify one or more time intervals (for example, 03:00 and 03:30)
  • Weekly - specify the day on which the backup will take place (backup time follows the default backup window)
  • Monthly - specify the week in which the backup will take place (backup time follows the default backup window)

Click the Retention tab and specify or create a retention policy appropriate for this backup service level.


You can specify or create one of several types of retention policies. You can:

  • Retain the backups forever.
  • Retain the backups for a certain number of days/weeks/months/years.
  • Retain the backups until a certain date.
  • Define a custom retention period.

To keep the backups for a certain number of days, weeks, months, or years, select the for option, type a number, and select days, weeks, months, or years from the menu. To define a backup retention period of forever, select forever.

To keep the backup until a certain date, select Until, which enables you to choose any future date.The Long Term Retention Policy is the length of time that you want to retain a final backup of the virtual machine. This final backup is taken during the VM destroy/decommission process.

While the wizard provides the primary schedule settings, you can also apply a custom retention schedule based on each of the backup types by making selections from all of the possible parameters available.

Once the required inputs have been collected, and the Submit button is clicked, EHC will kick off the CreateServiceLevel vRealize Orchestrator workflow which will take the inputs, validate if the underlying environment is single or multi-site containing Avamar replication, and then go create the required objects such as :

  • Avamar Backup Policy (see Avamar Admin UI image below)
    • Define Dataset/Schedule/Retention/Proxy servers
    • Enable Encryption Method (set to High)
  • vCenter Folders
  • vRA objects such as the Build Profile and Property Dictionary
  • vCenter SRM mappings (if DR environment)


Once the operation has successfully completed, the new EHC Backup Service Level will be available at deployment time to any virtual machines to which Data Protection Backup is applied to their Blueprint, as shown below.


Once the VM is deployed, it is added to the appropriate vCenter folder and Avamar Policy, as shown below:

EHC_AvamarUI_BackupPolicy_vCenter - New Page

Later posts will explain how to add EHC BaaS to VM deployments in vRA, what happens under the covers when the scheduled backups kicks off, as well as the on-demand backup and restore operations which are outside of the defined backup schedule.

Hope this helps!


Originally posted @ Scamallach

The Enterprise Hybrid Cloud solution provides fully automated Backup and Recovery services to its users. While technically an optional add-on to the foundation EHC solution, Backup-as-a-Service (BaaS) is designed for all instances and configurations of EHC.

EHC BaaS configurations range from local single-site, to replicated multi-site implementations, with fully replicated and recoverable virtual machine backups, while all the time maintaining full backup/recovery services after DR events. Every feature and function of the EHC solution takes backup and recovery into consideration.

EHC BaaS leverages unique customisations and workflows in vRealize Automation and vRealize Orchestrator, with the features and functionality of EMC Avamar, EMC Data Domain, and EMC Data Protection Advisor software.

  • VMware vRealise Automation provides the self-service catalog and user portal
  • vRealize Orchestrator is the orchestration engine
  • EMC Avamar is the backup appliance
  • EMC Data Domain can be used as backup target behind the Avamar appliance
  • EMC Data Protection Advisor can be used to provide on-demand VM-level reports


VMware vCenter is the private cloud endpoint ... and the EHC Data Protection Backup customisations & workflows tie them all together!

All EHC data protection backup services are accessed through the vRA portal and self-service catalog.

EHC3_5_DataProtection_ArchOverview01 - WhiteBackground.png

  • Abstracts and simplifies self-service backup and restore operations for cloud users
  • Provides full image backups for running virtual machines
  • Eliminates the need to manage backup agents for each virtual machine
  • Uses VMware vStorage APIs – Data Protection, which provides Changed Block Tracking (CBT) for faster backup and restore operations
  • Minimizes network traffic by deduplicating and compressing data

The underlying technology and efficiencies supporting and enabling the backup and restore operations in this solution are completely abstracted from the cloud users.EHC data protection backup services have multiple consumers in the cloud. Infrastructure or backup administrators as well as end users consume the backup and recovery services available:

  • vRA cloud administrators use their vRA service catalog to create and manage the appropriate backup service levels (Backup Policies), as shown below:




  • When creating virtual machine blueprints, vRA service architects or business group managers can choose to enable/attach backup services for the user.
  • At virtual machine deployment time, cloud users can choose to protect their machines with a predefined backup service level.
  • Day2 VM-level actions are also available to the virtual machine users, whereby they can execute on-demand backup and restore operations, as well as on-demand reports, as shown below:




In later posts, we will discuss in more detail the user roles listed above, showing how they each consume EHC data protection backup services and their associated use cases.

In the meantime, if you just.cant.wait.that.long, you can always  go to EHC Demo for the EHC experience and demos!

In response to a request from a colleague, I had grabbed screenshots of each of the Management Packs installed in vRealize Operations Manager, expanding each to display what dashboards were available within.

This could possibly be the least technical post on here, but anyway, it may be useful to some!


The Federation EHC solution recommends the following Management Packs be used in vR Ops:

  • vSphere
  • vRealize Automation
  • NSX
  • EMC ViPR
  • EMC Storage Analytics (ESA)


Other vR Ops Management Packs can be used also such as Brocade, Cisco UCS, etc as appropriate, so long as they are managing components that are part of the Federation EHC solution.

EHC vROps Managed Resources_min.png

The following are screen grabs of each Management Pack, displaying their respective Dashboards:

vSphere Dashboard:



vRealize Automation:









EMC Storage Analytics - VNX:



EMC Storage Analytics - VMAX:



EMC Storage Analytics - VNXe:



EMC Storage Analytics - VPLEX:



EMC Storage Analytics - XtremIO:



EMC Storage Analytics - RecoverPoint for VMs:



EMC Storage Analytics - ScaleIO:



EMC Storage Analytics - Isilon:



And that's about it for what is currently installed in the lab, hopefully that info or the graphics are of use to people ....

Product versions used in this post:

  • vRealize Operations Manager v6.0.3
  • EMC ViPR v2.3
  • EMC Storage Analytics v3.4
  • vRA Management Pack v6.0.2
  • NSX Management Pack v2.0.3

The EMC Storage Analytics (ESA) management pack integrates the features and functionality of vRealize Operations Manager with a wide range of EMC products. The ESA delivers custom analytics and visualisations that provide detailed visibility into the EMC infrastructure, enhancing troubleshooting and proactively identifying storage performance and capacity issues for remediation.


This post will focus on the installation, configuration and operations provided by the VNX adapter (mainly because that's all that I have in the lab right now!)


The latest ESA supports the following EMC products:


  • XtremIO
  • VNX
  • VMAX
  • RecoverPoint for VMs
  • ScaleIO
  • Isilon
  • VNXe


ESA enables the following default dashboards in the vRealize Operations Manager custom portal:

  • Storage Topology - Displays resources and relationships between storage and virtual infrastructure objects
  • Storage Metrics - Displays resources and metrics for all storage systems
  • Array-specific dashboards - Displays resources and metrics for individual storage systems


Installation of the ESA with VNX Adapter:


Logged into the vR Ops UI with admin privileges, under Administration > Solutions > Add Upload the relevant ESA .pak file, accept the EULA, and click Finish.


In order to display connections between the VMware objects and the EMC storage arrays objects, you must first install an EMC Adapter instance for vCenter. All storage system adapter instances require the EMC Adapter instance for vCenter (If the vCenter adapter instance is not configured, other adapter instances will function normally but will not display the VMware to EMC array connections).


Once installed, the EMC adapter should be selected under Administration > Solutions and click the Configure icon above the list of Solutions, and click the Green Plus icon to add an adapter.





Configure the following properties in the pop-up window:

  • Display name: Can be any friendly/intuitive name
  • Management IP: IP address or FQDN of vCenter Server
  • Connection Type: VMware vSphere
  • License: leave blank
  • Credential: Create and use a valid credential (Read Only) to access the vCenter server


Click OK, then Test Connection to verify successful communications. If successful, then click Save Settings and click OK.


To configure an adapter for VNX, click the Green Plus icon again and configure as shown below:




Configure the following properties in the pop-up window:

  • Display name: Can be any friendly/intuitive name
  • Management IP: IP address of either VNX Storage Processor
  • Connection Type: VNX Block
  • License: Insert a valid license
  • Credential: Create and use a valid credential to access the VNX


Click OK, then Test Connection to verify successful communications. If successful, then click Save Settings and click OK.


Once the adapter has pulled in sufficient data, you can start to take advantage of the various VNX dashboards. The ESA provides 5 different dashboards specific to VNX arrays, displayed as follows:




The VNX Overview dashboard provides heat-maps of various performance, utilisation, and capacity counters on VNX, including CPU and FAST Cache performance, Storage Pool capacity, and LUN and Filesystem performance, as shown below:




The VNX Topology dashboard establishes mappings and correlations between storage system components and vCenter objects (using the vCenter adapter), which enables health scores and alerts for storage system components, such as storage processors and disks, to be shown in the context of vCenter objects, such as LUNs, datastores, and virtual machines.




You can see details for every object in every widget by selecting the object and clicking the Resource Detail icon at the top of each widget. ESA displays all related VMware objects, which enables end-to-end navigation into the underlying storage array components, from vSphere datastore clusters and virtual machines to storage groups and ports.


The VNX Metrics dashboard displays a graph with each VNX resource and the metrics associated with it. Navigation is from the top down. After choosing the storage system and a specific resource, you can select multiple metrics for display




The VNX adapter also provides 2 other Top-N dashboard with respect to both Block and File storage. Our lab is not using any file storage but the view of block storage is as follows:




Multiple adapters can be configured under the primary EMC Adapter in vR Ops. The vRealize Operations Manager requires an adapter instance for each resource to be monitored. The instance specifies the type of adapter to use and the information needed to identify and access the resource, as shown below:




In relation to the Federation Enterprise Hybrid Cloud solution, the ESA is not a mandatory requirement, but it is widely used in order to provide deeper insight into the individual storage arrays managed by EMC ViPR (which also has a great Adapter for vR Ops, here).



Product versions referenced in this post:

  • VMware vRealize Operations Manager v6.0.2
  • EMC Storage Analytics v3.4



Related posts include:


EMC ViPR & vR Ops


vROps Management Packs


vRA & vR Ops

Appearance matters, so when you make the effort to install and configure vRA itself or as part of the Federation EHC solution, it makes sense that you should customise/brand the vRA catalog services. This is especially important if the environment is customer-facing, be it a demo/PoC or a real customer environment.

I like vRO, but seeing a vRA catalog full of vRO logos is a bit of a let down, especially when it could look so much better. A lot of work goes into developing the logic and workflows behind the services so it's important to present those services as professionally as possible.

The following is an example of a vRA Service Catalog with a decent range of services, each of which (bar one) have been customised with their own logo.


Fair to say that it looks a lot better than this (which at least has some customisations applied!):


In the sample vRA Catalog above, some EHC services such as Storage-as-a-Service (STaaS), Cluster Onboarding and Infrastructure-as-a-Service (IaaS) have already been customised, but the EHC Data Protection Service and catalog items are at default.

So which objects can be customised and what needs to be done? The following objects in vRA Service Catalog can be customised:

  • Services (left side of the screen/navigational pane)
  • Catalog items (main page/target pane)
  • VM Actions (technically not in the catalog, but visible to the user at the VM level)
  • Main vRA portal


The Services on the left side contain the related catalog items (Keep in mind that the user will only see what they are entitled to, configured via vRA Entitlements).

Although the main 'All Services' icon (Blue Lego brick) cannot be customised, all of the other Services can be, quite easily.

Logged in with one of the vRA Tenant Admin/Service Architect/Business Group Manager roles, navigate to Administration > Catalog Management > Services and click the Service that you want to customise, as shown below:


Taking the EHC Data Protection Services as an example, once you click on it you are presented with the ability to edit the Service, including selecting the desired icon, as shown below. Browse to the file locally and upload. Click 'Update' to apply the new icon.


Once applied the Service then greets the world with it's brand new icon, as  shown below:


Now that the main Data Protection Services icon is set, we can see that the associated catalog items are all in need of a makeover. These are configured from almost the same location at Administration > Catalog Management > Catalog Items.


Simply click the item and you will be presented with the Configure Catalog Item screen, from where the icon can be selected (Recommended icon image size is 100x100px), as highlighted below where, using the EHC Create Backup Service Level catalog item, we have selected an EMC Avamar image.


Again, once applied by clicking 'Update', the catalog item will display it's new image in place of the default vRO icon. This Repeat as appropriate for all other catalog items, and you get a much nicer vRA catalog experience, as shown below:


These icons will also be displayed when the user requests any of the catalog items, as shown below:


So that's the main vRA Catalog prettied up, but we can also go a bit further and customise some of the VM Actions. See the image below where a number of the EHC specific data protection backup VM actions are displaying the default icons:


These icons can also be configured at Administration > Catalog Management > Actions. Same again, simply click on the Action to edit it. Highlighted below are the 3 Actions that need to be customised:


Once in the Configure Action screen, the icon can be selected by browsing locally to the file. Click 'Update' to apply the new icon.


Repeat as appropriate for each of the VM Actions, return to the VM and view your handiwork, as below:


So that's pretty much it for customisation of the vRA catalog, but if you want to go all out for a complete re-branding of the vRA portal, then you can also apply your own company/customer logo to the vRA portal.

Logged in as with the vRA  System Admin or Tenant Admin role, navigate to Administration > Branding, deselect the 'Use Default' setting.


From here you can choose the required solution or company logo and apply your own Product name, as shown above. Colour palette can also be edited as well as header Footer details.

The end result is as follows:



A great resource for vRA icons can be found here courtesy of @VMtoCloud

And if you don't bother to customise your vRA portal? Shame.On.You

Hope you find this post useful.


Product versions referenced in this post:

  • VMware vRA v6.2.x
  • Federation Enterprise Hybrid Cloud v3.1



VMware vRealize Automation 6.2 Documentation Center


Blog originally posted to Scammallach

vRealize Automation integrates with vRealize Operations Manager in a couple of ways, and it may not immediately be apparent which integration point is responsible for what functionality.

A vRA Management Pack is available for vR Ops that provides cloud administrators with tenant-aware operational visibility of the infrastructure supporting their hybrid cloud, as shown below:


This vRA Management Pack provides 3 separate dashboards in vR Ops:

  • vRA Tenant Overview
  • vRA Cloud Infrastructure Monitoring
  • vRA Top-N Dashboard

For information on installing the vRA Management Pack for vR Ops, go look at the great write-up from @virtualjad here.

Besides this vR Ops Management Pack, vRA also provides it's virtual machine users with vR Ops-based health badges so that they can have visibility of the health of their virtual machines, as shown below:


This health badge visibility must be enabled/configured in vRA and is not dependent on the previously mentioned vR Ops Management Pack. Logged into vRA as a Tenant Admin, navigate to Administration > Tenant Machines > Metrics Provider Configuration and enter the required details.

  • URL: https://<vROps FQDN>/suite-api/
    • Note: Ensure to include the '/suite-api/' in the vR Ops endpoint details
  • Username:This user need only be assigned the ReadOnly role, and Object rights to the vCenter Adapter and Cloud vCenter Server, as displayed below:


  • Password: Password for the vR Ops ReadOnly user



Once the details have been entered, hit the Test Connection button to validate. Once complete, you're good to go!

Product versions referenced in this post:

  • VMware vRealize Automation v6.2.1
  • VMware vRealize Operations Manager v6.0.3
  • Federation Enterprise Hybrid Cloud v3.1


Official Documentation:

VMware vRA 6.2 Documentation Center

One new configuration requirement that I have come across recently working with vRealize Automation is the increased integration and permissions between vRealize Business Standard, vCenter and vRealize Operations Manager.

For internal lab environments it may be common to use the 'admin' or 'root' user accounts when configuring credentials for various product integrations. However in the real world, where proper accounts of least required privilege should be used, this means that specific roles and permissions need to be created and used.

This particular issue raised it's head when the Storage Profiles could not be determined from vCenter in the Business Management tab in vRA Business Management > Cloud Cost > Storage Cost > Edit as shown below:


Instead of displaying the various storage profiles for Storage Monthly Costs, all storage was collapsed as 'uncategorized'.

Storage Profiles and Metering in EHC are discussed here

So what was wrong?

When we checked the status of the vCenter connection, in the vRA portal under Business Management > Cloud Cost > Status  we observed the following error:


vRealize Business Standard has a requirement that the user/credentials used to manage the vCenter Server connection (Read Only) must have additional privileges in vR Ops Manager.

In addition to the vCenter Read Only role, the vRB role requires the following additional vR Ops permissions:

  • Storage views.View
  • Profile-driven storage.Profile-driven storage view
  • Global.vRealize Operations Read Only Role



In our EHC v3.1 lab environment, we use application service accounts to identify which application is talking to which, in the form of app_<source>_<target>. So for vRB integrating with vCenter, and vR Ops Manager we use the following:

  • vRB to vCenter: app_vRB_vCenter
    • Read Only + vROps permission (as stated above)
  • vRB to vR Ops: app_vRB_vROps
    • Read Only

While configuring vRealize Business Standard, logged into vRA as the Tenant Admin, the vCenter and vRealize Operations Manager connections can be configured under Administration > Business Management, as shown below



  • For the vCenter Server connection, the vCenter FQDN can and should be used
  • For the vRealize Operations Server connection:
    • Enter the vR Ops Server IP Address instead of FQDN (not a best practice, but currently the FQDN will not work here)
    • The vR Ops Username should not include domain suffix



One other integration point to verify is correct, is the vCenter Adapter in vR Ops, configured in the vR Ops  UI under Administration > Solutions > VMware vSphere > Configure where the vCenter Server address should be in the format of https://<serverName>/sdk as shown below


Once these settings and user permissions have been set correctly, the Storage Profiles will be read correctly from vCenter and will be displayed accordingly in vRA Business Management, as shown below:


The vRA Business Management System Status also now displays all green ticks, as shown below:


... and they all lived happily ever after! #funfunfun

Software versions referenced in this post:

  • vRealize Automation v6.2.1 b2553372
  • vRealize Business Standard v6.1.0 b2548009
  • vRealize Operations Manager v6.0.3 b3041065
  • vCenter Server v5.5.0 b3142196 (5.5 Update3a)
  • Federation Enterprise Hybrid Cloud v3.1

To correlate build numbers to VMware product versions, please ref hereOfficial VMware Doc References:

The Federation EHC solution uses VMware vRealize Log Insight for centralised and automated log management, analyzing log events from any component that supports syslog forwarding, providing system analytics, aggregation and search capabilities.

The log-forwarding configurations are enhanced with VMware and EMC  (and 3rd party as required) content packs.

Log Insight has a ton of great features and use cases, with a lot of great information available here from @smflanders.

One particularly interesting use case in terms of the EHC solution is the ability to see how the VMware vCenter Server is being accessed by the other components in the EHC solution. I touched on this and the related integration points in an earlier post here.

So many individual products now have integration with vCenter that it may go unnoticed just how much load the vCenter server is under from other components, for example who is accessing vCenter and how often.

The image below is a high level representation of some of the primary components in the EHC solution which are directly integrated with the vCenter server.

vCenter_Connections - Integration Points

As discussed in other posts, the EHC solution, as with all Production environments, requires identifiable service accounts for all interactions and services between the various EHC components.

Using the vSphere Content Pack, which ships by default with Log Insight, we can create a view of interactions between EHC components, showing which components are accessing the Cloud vCenter server, how often, and which mode of communication is being used.


As we can see in the screen-grab above from our EHC v3.1 lab, vRealize Automation (app_vra_vcenter) is by far the main consumer/requestor of vCenter information (~2600 events), with vRealize Business (app_vrb_vcenter) the next closest (~600 events).

  • The legend on the upper-right displays the service accounts accessing the vCenter server. The service accounts in use here are displayed in the format of DOMAIN\application_<source>_<target> e.g. ppsilver\app_vra_vcenter.
    • vmw_vc_auth_user
  • The X-axis displays the Count of Events
  • The Y-axis displays the authentication type for the connections
    • vmw_vc_auth_type

From this display you can click into any of the bars and will be directed to all of the related events.These constraints are configured as highlighted below:


This custom information can easily be saved and exported as a custom dashboard, using the appropriately named 'Add to Dashboard' button in the top-right corner of the main page.


EHC customers can use this feature to create their own custom EHC Log Insight dashboard, displaying the information most relevant to them.Some of the other EHC-related Content Packs that can be used are vRealize Operations Manager, vRealize Automation, NSX, vRA, VMAX, VNX, as displayed below.


The content pack for vRealize Operations Manager presents and analyses all of the logs that are redirected from a vR Ops instance. The queries and dashboards provided by the content pack can be used to monitor and troubleshoot issues in the vR Ops Manager environment.In addition to the content pack, vR Ops can be integrated in the following independent ways:

  • vRealize Log Insight can send notification events to vR Ops Manager.
  • The Launch in context menu of vR Ops Manager can display actions related to vRealize Log Insight.

The vRealize Automation content pack for Log Insight provides important information across all components of the vRA environment and key dependencies such as vCenter Orchestrator and vCenter Single Sign-On (SSO).Product versions referenced in this post:

  • VMware vRealize Log Insight v3.0
  • VMware vCenter v5.5 Update 3a
  • Federation Enterprise Hybrid Cloud v3.1



Official VMware vRealize Log Insight Product Page

VMware vRealize Content Packs

EMC ViPR provides a Management Pack for VMware vRealize Operations Manager. This is one of the many EMC-VMware integrations included in the Federation EHC solution.

The EMC ViPR Analytics Management Pack provides custom analytics and visual representation of the resources within the EMC software-defined infrastructure.

EMC ViPR inventory, metering, and event data is imported into vR Ops and displayed through pre-configured dashboards that show collections of volume, storage port, storage system, and virtual pool data. vR Ops uses the data to compute key resource status scores. Resource details, individual metrics, and EMC ViPR event alerts are also presented in dashboard views.

Installing this ViPR Management pack in vR Ops is quite straightforward.

Logged into the vR Ops UI with admin privileges,under Administration > Solutions > Add Upload the relevant ViPR .pak file, accept the EULA, and click Finish.

Once installed, the ViPR adapter should be selected under Administration > Solutions and click the Configure icon above the list of Solutions, as shown below:


Configure the following properties in the pop-up window:

  • Adapter Instance Name: e.g. EHC ViPR Adapter
  • Host Name: e.g. vipr.domain.local
  • Enable Filtering: Turn filtering on or off (On recommended)




  • Credential: Add the relevant credentials for vR OPS to contact ViPR using full domain name e.g. adp_vrops_vipr@domain.local



This user/credential must have System Monitor role in the EMC ViPR Virtual Data Center Role Assignment.

The format of the credential used above aligns with EHC service and application account naming structure of adapter_<source>_<target> where vR Ops is the source and ViPR is the target.

Click OK, then Test Connection to verify successful communications. If successful, then click Save Settings and click OK.Once the analytics pack is created, it can take several minutes for the initial data collection to complete, as shown below:


The preconfigured dashboards provided by the EMC ViPR Analytics Pack, available in the vR Ops UI Homepage under Dashboard Lists, include capacity, performance, and higher-level at-a glance information, as shown below:


  • The ViPR Capacity dashboard enables users to monitor virtual storage pool capacity and datastore disk usage.
  • The ViPR Performance dashboard enables users to monitor storage network and datastore latency performance data.
  • The ViPR At-a-Glance dashboard enables users to monitor performance and capacity data from a single dashboard.

Another significant Management Pack for VMware vR Ops is EMC Storage Analytics, which provides custom analytics and visualisations at the individual EMC storage array level, supporting VMAX, VNX, VNXe, Isilon, ScaleIO, XtremIO, VPLEX, and RecoverPoint for VMs. The ESA is not covered here in this post but may be covered at a later stage in a separate post.

Product versions referenced in this post:

  • VMware vRealize Operations Manager v6.0.2
  • EMC ViPR v2.3



EMC ViPR Controller Analytics Pack for vROPs Installation and Configuration Guide

The Federation EHC solution uses VMware vRealize Business (vRB) Standard to provide chargeback information on the resources consumed in the hybrid cloud.


vRB Standard is integrated with vRealize Automation (vRA) and is displayed within the vRA self-service portal for users with a Business Management role. As vRA uses VMware vCenter Server as a private cloud endpoint, so vRB is configured to monitor that vCenter Server.

After an administrator enters the appropriate credentials for the vCenter Server and establishes a connection, vRB can monitor the vCenter inventory where it can import existing resource hierarchies, folder structures, and vCenter tags to organise hybrid cloud resource usage with business units, departments, and projects.

When it comes to billing for storage, vRB provides the ability to automatically categorise and monitor the utilisation of the storage resources provided by EMC ViPR. As the various tiers of storage are presented to vCenter by EHC STaaS provisioning operations, VM Storage Profiles are created in the Cloud vCenter Server based on the storage capabilities of each type of storage presented.


These storage capabilities of the vSphere datastore are presenter to vCenter by the storage provider running on the ViPR controller. The vSphere storage administrator creates storage profiles, as shown above, based on the storage capabilities of the ViPR storage. The ViPR Storage Provider will display the ViPR Virtual Pool name and the storage type (Block/File). In the examples shown above and below, the ViPR Pool name is simply .Tier-2'.


This integration enables vRealize Business to automatically discover, group, and meter datastores in line with their storage profile.

(Note that storage capabilities are only visible in the traditional VMware vSphere® Client™ and not in vSphere Web Client. vSphere Web Client uses virtual machine storage policies instead of virtual machine storage profiles)

Newly provisioned datastores inherit the storage properties of the ViPR pool in which they are configured. Storage profiles group datastores by their storage capabilities and report that information through vRB, as shown below.


vRB discovers the storage cost profiles that were created in vCenter, and applies and displays the appropriate costs, as shown above. This enables the vRB administrator to group tiered datastores that are provisioned with ViPR and set the monthly cost per gigabyte as needed.

The various tiers of storage are consumed by the VMs provisioned onto the devices. vRA will have storage reservations on the storage devices and the placement of VMs onto a particular tier of storage is controlled by the Storage Reservation Policy configured in the vRA VM Blueprint, as shown below.


Hopefully this post helps explain some of the connections involved between vRA, vRB, vCenter and ViPR.


(Originally posted @ Billing/Chargeback for EHC STaaS | Scamallach)

Filter Blog

By date:
By tag: