Home > Blogs > VMware vCloud Blog > Monthly Archives: November 2011

Monthly Archives: November 2011

vCD Custom Portals and Backend Integrations in a Service Provider Environment

By: Massimo Re Ferre', vCloud Architect

This topic is (rightly so) coming up a lot lately with the Service Providers (SPs) I am working with so I thought I'd share some high level ideas on how we are engineering those clouds. This short article is meant to share some guiding principles on how to engineer custom portals and backend integrations for SPs that are adopting vCloud Director. Please note that this is a very broad topic and if we were to get into all of the details and potential ramifications we would need a book and not a blog post to describe this.

So what makes this so unique? SPs have been building portals and integrations forever. Why would a vCD based solution be any different? Well, let's make a step back. There are two main reasons why Service Providers want to use vCloud Director:

  • Avoid reinventing the wheel and use an out-of-the-box product that delivers the cloud backbone (RBAC, virtual data centers, security, multitenancy, etc), on top of which they can create their own solution and value.

  • Exposing the native vCloud APIs to enable federation with customers that are using VMware technologies (either vSphere or vCloud Director in so called "private cloud" deployments).

The next picture shows, at the very high level, the vCD architecture. A more detailed description can be found here if you are interested.

VCD1APIs. APIs. APIs. If there is anything that matters in the cloud that is the APIs. In other words a programmable infrastructure. If you are a Service Provider interested in vCloud Director you are probably interested in the vCloud APIs because that means that, as we mentioned above, you can reach out to a vast amount of VMware customers, allowing them to connect to an "online compatible infrastructure". You can read more of this hybrid cloud opportunity here and this is a high level representation of this concept:

VCD2

Browser based access to the cloud is a no brainer. You can read more here about how to use vCC (vCloud Connector) to connect to a public cloud. You can read more here if you are interested in connecting your vCO (vCenter Orchestrator) instance to a VMware cloud. These are just two examples that describe how the end-user can leverage a vCD based public cloud. VMware, and the ecosystem as a whole, is coming out with a number of tools that interact with the vCloud APIs natively. VMware vFabric AppDirector is another good example of these tools consuming these programmable interfaces. I encourage you to have a look at the brief demo video available here.

If it isn't clear yet, this is the reason for which developing a ton of logic right above the vCloud APIs isn't a good strategy if SPs want to offer a VMware compatible cloud service. You want the vCloud APIs to be widely available and well exposed. Not obscured by "a ton of scripts and workflows". That is to say that building something that looks like the following picture may not be a good idea if you want to be part of what I call the vCloud bus:

VCD3Do not do that. Please.

Having this said, let's dig into what the SPs need and what their requirements are. An oversimplification of what they would like to achieve can be summarized as follows:

  • They want to have a customized portal where they can keep their own traditional look and feel and potentially expose additional services.

  • They need to integrate into their backend systems through a mix of business and technical orchestration tools.

So let's try to take this apart and start with the first requirement. Ideally the SP would need to build a brand new portal (the out of the box vCloud Director web portal cannot be customized) or reuse an existing portal that they want to complement with the new vCloud Director based IaaS cloud services. As you can see this allows the SP to mesh vCD native services with other services that need to be exposed. These could be other VMware services that are not yet integrated into the vCloud API framework (VMware Chargeback or vShield App come to mind) or totally different services that the SP would like to make available to external customers. 

VCD4There is only one principle that the SP needs to be conscious of when building this custom portal: the additional services exposed in the custom portal needs to be loosely coupled from the vCloud Director services. In other words the architect designing this needs to make sure that accessing vCD services through the native APIs doesn't break the consistency. Basically the custom portal cannot inhibit users to access vCD through the out of the box UI or the native vCloud APIs if basic native functionalities is what the users need to access. Putting it in (yet) another way, accessing the cloud via the native vCloud APIs / UIs shouldn't break the consistency of the whole solution but only limit the users in what they can do (as opposed to accessing a custom portal that has more advanced functionalities).

This is, in essence, the reason for which we removed the "Orchestration / Logic" from the top of the vCloud APIs. Should the SP build the logic on top of those APIs they are essentially obscuring them. In fact, allowing a user to access obscured vCloud APIs would lead to bypassing the logic which in turns would make the whole solution inconsistent.

So what do we do to satisfy the SPs requirements of synchronizing the backend according to events that may occur at the vCloud Director level? The typical example SPs usually refer to is a scenario where an end-user deploys a new vApp and there must be some logic (somewhere) that intercepts this event to update a CMDB with the relevant information. Now, we can spend the remaining of this post discussing the value of capturing a self-service vApp deployment in the cloud into such CMDB but we will leave this discussion for another post. The question is: if we can't put this logic between the user and the vCloud APIs to intercept this event, how can the SP know what happened to track it properly (the CMDB is just an example, it could be any backend system such as ticketing or anything really).

In vCD 1.5 VMware introduced a new feature called "vCloud Messages" also known as "notifications" or "call-outs". Essentially vCloud Director 1.5 is able to track internal events and notify them via an AMQP message bus for an external module to consume this information. The picture below shows the flow where vCloud Director informs the AMQP bus that an event has occurred and the Orchestrator will take the proper action to update the backend systems:

VCD5

In this example a vApp is deployed using the vCloud APIs, vCloud Director puts a message on the AMQP bus that the vApp has been created, the orchestrator module reads this message and it then updates the CMDB. Note that the module where the logic is implemented connects to basically all modules in the infrastructure since the notification may require actions that go beyond those of updating a back-end system.

It is also important to note that the diagram above is a logical representation. The "Additional Cloud Services" illustrated above can either be delivered via the Orchestration / Logic components or by totally different subsystems that are available in the Service Provider infrastructure. In other words there should also be a virtual link from the Custom Portal to the Orchestrator / Logic components. The very same principles discussed above apply here as well. Exposing additional services (made available by the orchestration layer) shouldn't inhibit and limit end-users from accessing their resources via the native vCloud APIs (or UI for that matter).

Perhaps it is worth spending a minute to better characterize the Orchestration / Logic brick. In a complex organization like a Service Provider this may be comprised potentially of multiple modules and products. Usually there are at least a couple of components inside that brick and they are what I refer to as a Business Orchestrator and a Technical Orchestrator. The former is responsible for interacting with the back-end systems (it may even be considered part of the back-end systems) whereas the latter is responsible for interacting with the actual infrastructure components and modules. Graphically, it means this:

VCD6

One of the reasons for this split is because the business orchestrator module plays a key role in the governance of the solution but doesn't usually have the full range of adapters and connectors to talk to the infrastructure modules. Because of this it leverages a technical orchestrator module to deal with that part. In most situations the Service Provider already have such a business orchestrator in place. Most of the time though, based on my experience, what's missing is a more technical orchestrator module that interacts with the lower level infrastructure components. This leads to lots of extra in-house development that is expensive, time consuming and hard to maintain.

This is where vCenter Orchestrator comes in. We have previously mentioned, at the beginning of this post, you can use vCO as a cloud end-user tool to consume the vCloud APIs, but where vCO really shines is as a technical orchestrator acting in the back of the cloud to pull all the infrastructure pieces together.  There is also a nice article that talks about how to extend vCloud Director capabilities using vCenter Orchestrator (this ties back to the concept that additional cloud services exposed in the custom portal could be delivered by the orchestrator directly).

Note that what I have discussed here so far is the logical high level architecture of the solution. Different modules do not necessarily mean different products (although they often do). For example there may be situations where a single product could deliver both a portal and business orchestration modules. VMware Service Manager is an example of these products. As I said big Service Providers often have this part historically covered already anyway.

In conclusion, it is advisable (if not imperative) for Service Providers to be able to expose the native vCloud APIs to maximize market opportunities and value to existing VMware customers. In order to do so SPs need to follow proper design principles for backend integration and custom portals design. This brief blog post is only meant to be a starting point for outlining the criticalities associated.

Massimo currently works as at VMware as a Staff Systems Engineer, vCloud Architect. He works with Service Providers and Outsourcers to help them shape their Public Cloud services roadmap based on VMware cloud technologies. Massimo also blogs about Next Generation IT Infrastructures on his personal blog, IT 2.0.

Stopping and Starting the vShield Edge Security Services

By: Michael Haines (Senior Cloud Security Architect)

In my last blog, I covered how you, as the Network and Security System Administrator at “Example Systems,” used the vShield Edge REST API.

In the final blog of this series, you will learn how to ‘Stop’ and ‘Start’ the vShield Security Services using the vShield Edge REST API.

If you haven’t already done so, be sure to check out the previous installments in this blog series. In my first blog, I introduced a hypothetical Network and Security System Administrator in a hypothetical scenario and showed how to get started using the vShield API. In my second and third blogs, I detailed how you as the Network and Security System Administrator could utilize the Automation tools with vShield App for scalability through the REST APIs.

Stopping the vShield Edge Security Services (Load Balancer) (Basic)

Mhaines5_1

To stop the vShield Edge Load Balancer server run the following command VSE-LB-Stop.bat

Mhaines5_2

Note: The above command must be executed on one line, so if you are experiencing any problems check for carrage returns and line breaks.

Stopping the vShield Edge Security Services (Load Balancer) (Advanced)

Mhaines5_3

Now that you as the Network and Security System Administrator know the status of the vShield Edge Services, you can now begin to 'Stop', 'Start' and 'Configure' them. You will first check and confirm the status of the vShield Edge Services Load Balancer using the following request:

Next, you are going to 'stop' the vShield Edge Services Load Balancer and then check the status of the Load Balancer as in the above example. The main points of interest from a Network and Security System Administrator point of view are as follows. In the first request to stop the vShield Edge Service:

  1. The VERB has now changed from a 'GET' to a 'POST' (1)
  2. The HTTP result code has changed from 'On Success: 200 OK ' (2)

NOTE:

The return status code 204 No Content is not an error. In this case the server has fulfilled the request but does not need to return an entity-body. For a full list of the HTTP/1.1: Status Code Definitions please see http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.

In the second request the Network and Security System Administrator is verifying the vShield Edge Service Load Balancer status. Here again the main points of interest are as follows:

  1. Return HTTP result code status (3)
  2. Status of the VPN Service (4

The View from the vSphere Client (Services Stopped)

Mhaines5_4

Here the Network and Security System Administrator has just confirmed the status of the vShield Edge Services using the vSphere Client. As you can see, the Service Status is the same from the UI as it is from the vShield REST API.

Starting the vShield Services (Load Balancer) (Basic)

Mhaines5_5

To start the vShield Edge Load Balancer server run the following command VSE-LB-Status-Start-Status.bat

Mhaines5_6

Note: The above command must be executed on one line, so if you are experiencing any problems check for carrage returns and line breaks.

Starting the vShield Services (Load Balancer) (Advanced) 

Mhaines5_7

The Network and Security System Administrator is now going to 'Start' the vShield Edge Services Load Balancer. Here you will first check and confirm the status of the vShield Edge Services Load Balancer using the following request and then 'Start' the Load Balancer.

  1. The VERB has now changed from a 'GET' to a 'POST' (1)
  2. The HTTP result code has changed from 'On Success: 200 OK '(2

In the second request you are verifying the vShield Edge Service Load Balancer status. Here again the main points of interest are as follows:

  1. Return HTTP result code status (3)
  2. Status of the VPN Service (4)

The View from vSphere Client (Services Started)

Mhaines5_8

Here the Network and Security System Administrator has just confirmed the status of the vShield Edge Services using the vSphere Client. As you can see again, the Service Status is the same from the UI as it is from the vShield REST API. A few points to note:

  1. Be sure to reload the 'Refresh Status' button (1)
  2. Check the 'Service Status'
  3. Here you can see the 'Service Status' of the Load Balancer which is 'Running' 

Returning the vShield Services Configuration (Load Balancer)

Mhaines5_9

As the Network and Security System Administrator you are now at a stage where you now want to 'check' the current configuration if one exists, 'delete' any existing configuration if one exists and 'add' a new Load Balancer configuration to the vShield Edge device. You will first start by issuing a request to get the current configuration details of the vShield Services Load Balancer as in the example above. As you can see, there is quite a lot of information that is returned and in this case the Network and Security System Administrator needs to know and understand what is the important information related to the Load Balancer service configuration. With that in mind first look at the vshieldEdgeConfiguration as denoted by (1) and (2) which represents the full configuration present on the vShield Edge device. The next step is to locate and read the Load Balancer configuration information which is denoted by (3) and (4). You can see that there is already a Load Balancer configured with the following information: 

External IP: 192.168.110.207 Load Balancer Servers: 10.10.10.30 on Port: 80 Load Balancer Servers: 10.10.10.31 on Port: 80 Algorithm: round-robin Log: true 

Returning the vShield Services Configuration (Load Balancer) (Basic)

Mhaines5_10

To get and return the vShield Edge configuration information run the following command VSE-LB-Configuration.bat

Mhaines5_11

Note: The above command must be executed on one line, so if you are experiencing any problems check for carriage returns and line breaks.

vShield Manager View of the Load Balancer Configuration (Advanced)

Mhaines5_12

The Network and Security System Administrator can also see the vShield Edge Load Balancer Configuration in the vShield Manager UI.

Deleting the Current vShield Services Configuration (Load Balancer) (Basic)

Mhaines5_13

To delete the vShield Edge Load Balancer configuration run the following command VSE-LB-Delete.bat

Mhaines5_14Note: The above command must be executed on one line, so if you are experiencing any problems check for carriage returns and line breaks.

Deleting the Current vShield Services Configuration (Load Balancer) (Advanced)

Mhaines5_15

You are now ready to delete the current vShield Services Load Balancer configuration. The Network and Security System Administrator issues the following request as in the above example. After successfully completing this if you, as the Network and Security System Administrator, wanted to get the current configuration you would not see any reference to the load balancer configuration. Here again the main points of interest for you as the Network and Security System Administrator are as follows:

  1. The VERB has now changed from a 'GET' to a 'POST' (1)
  2. The HTTP result code has changed from 'On Success: 200 OK ' (2)

vShield Manager View after Deleting the Current vShield Services Configuration (Load Balancer)

Mhaines5_16

Once you have deleted the current vShield Service configuration, you can go to the vShield Manager UI to verify the status of the Load Balancer. 

Adding the New vShield Services Configuration (Load Balancer) (Basic)

Mhaines5_17

To Add the vShield Edge Load Balancer configuration run the following command VSE-LB-Add.bat
Mhaines5_18 Mhaines5_19

Note: The above command must be executed on one line, so if you are experiencing any problems check for carriage returns and line breaks.

Adding the New vShield Services Configuration (Load Balancer) (Advanced)

Mhaines5_20

As the Network and Security System Administrator you are now required to implement a new vShield Services Load Balancer configuration to load balance between the Web Servers in your organization. To accomplish this you will issue the following request as in the above example.

After successfully completing this if you were to get the current configuration you would see the newly created load balancer configuration. Here again the main points of interest as the Network and Security System Administrator are as follows:

  1. The VERB has now changed from a 'GET' to a 'POST' (1)
  2. The HTTP result code has changed from 'On Success: 200 OK ' (2)

Verifying the vShield Services Configuration (Load Balancer) 

Mhaines5_21

You are now able to verify the vShield Services Load Balancer Configuration using the above request or using the vShield Manager. Again, you can verify the Load Balancer information is correct by looking at the beginning (1) and end (2) of the Load Balancer configuration. You will also note the VERB has changed from a 'GET' to a 'POST' (3) and the HTTP result code has changed from 'On Success : 200 OK ' (4)

As the Network and Security System Administrator you have been able to get the current Load Balancer vShield Services Configuration, Delete the current Load Balancer vShield Services Configuration and Add a New Load Balancer vShield Services Configuration using the vShield REST API. 

Special thanks to Kaushal Bansal, Sr MTS at VMware for all his help and support. I hope this blog series was useful for understanding the vShield API implementation. For future updates and blog posts, be sure to follow @vCloud and @VMwareSP on Twitter!

Beginning to Work with the vShield Edge REST API

By: Michael Haines (Senior Cloud Security Architect)

Welcome to the fourth installment in my vShield blog series, featuring a hypothetical Network and Security System Administrator at the company, “Example Systems.” In the first blog in this series, I introduced the Example Systems company and described how it intended to use the vShield REST API to rapidly provision security and to turn its Tier-1 Applications into a business offering to multiple organizations. In the second and third blogs in this series, I discussed how the Network and Security System Administrator utilized the Automation tools with vShield App for scalability through the REST APIs.

In this installment, the Network and Security System Administrator is now ready to begin work with the vShield Edge REST API.

Before you can start to use the vShield Edge REST API you must:

1. Get and return the list of all vShield Edge’s installed with vShield Manager. This will provide you with the following details on the vShield Edge device(s):

  • PortGroup on which the vShield Edge device is installed
  • Mode of installation
  • vShield Edge version
  • REST compatibility mode
  • Features that are licensed

2. Provide the correct vShield Authorization.

  • All vShield REST requests require authorization and which by default (in the product documentation) use the following basic authorization: Basic YWRtaW46ZGVmYXVsdA==

Where YWRtaW46ZGVmYXVsdA== represents the Base 64 encoding of the vShield Manager default login credentials which are admin:default.

Getting Started with the vShield Edge REST API Lab

Mhaines4_1

In the following sections you will be running various commands, which in turn will be executing the vShield REST APIs to fulfill your requests. To get started please do the following:

  1. Start a Command Prompt
  2. Once the Command Prompt has started, cd to the directory where you have installed the scripts. As in the above example:

Desktop\vShield-REST-API\Edge

Here you will find all the example commands that will be run in this section of the blog.

cURL Command Line

Using simple, proven tools such as cURL, we can consume the vShield REST API. There is no need for fancy document descriptions, as we need to only hit each URL with the appropriate method and data to cause an immediate response.

What Is cURL? cURL, sometimes written as curl, is a set of C-based libraries in PHP that supports HTTP “GET”.

The cURL command line can get a little messy. There are lots of options available for controlling exactly how you want cURL to interface with the remote server. For this particular blog we will be using the following command line options.

- i (HTTP) Include the HTTP-header in the output. The HTTP-header includes things like server-name, date of the document, HTTP-version and more…
- k Allow connections to SSL sites without certificates.
- H Specify a custom HTTP header to pass to the server.
- X Specifies a custom request method to use when communicating with the HTTP server. The specified request will be used instead of the method otherwise used (which defaults to GET). Read the HTTP 1.1 specification for details and explanations. Common additional HTTP requests include POST and DELETE.

Getting the vShield Edge Device Capability (Basic)

Mhaines4_2

To get the vShield Edge Capability run the following command VSE-Capability.bat

Screen shot 2011-11-22 at 1.50.37 PM Screen shot 2011-11-22 at 1.50.27 PMNote: The above command must be executed on one line, so if you are experiencing any problems check for carriage returns and line breaks.

Getting the vShield Edge Device Capability (Advanced)

Mhaines4_5

In the example, the Network and Security System Administrator has provided the appropriate authorization and we see the correct HTTP result code status (1). You can now start to determine what information from the above output is required. One of the key pieces of information required in order for the Network and Security System Administrator to proceed, is to obtain the list of all the edges installed on the vShield Manager and also the portGroup information which can be identified in the field “networkId” for each vShield Edge device as shown above (2).

Getting the vShield Edge Device Capability on a Specific Portgroup (Basic)

Mhaines4_6

To get the specific vShield Edge Portgroup run the following command VSE-Capability-Portgroup.bat

Mhaines4_7Note: The above command must be executed on one line, so if you are experiencing any problems check for carriage returns and line breaks.

Getting the vShield Edge Device Capability on a Specific Portgroup (Advanced)

Mhaines4_8

Now that you as the the Network and Security System Administrator have the basic entry level information required, you can now start to get the information and return the capabilities of the vShield Edge device installed on a specific portgroup. In this particular case you are going to use what is termed the “<vc-moref-id>” to return details of the:

  • Portgroup on which the vShield Edge device is installed (1)
  • vShield Edge version (2)
  • REST compatibility mode (3)
  • Features that are licensed (4) (For clarity only ‘one’ feature is shown as an example)
  • Return HTTP result code status (5) 

Checking the Status of the vShield Services (Load Balancer) (Basic)

Mhaines4_9
To get the status of the vShield Edge Load Balancer run the following command VSE-LB-Status.bat

Mhaines4_10Checking the Status of the vShield Services (Load Balancer) (Advanced)

Mhaines4_11

As the Network and Security System Administrator you are now at a stage where you can start to interact with the vShield Edge Services. The first task as the Network and Security System Administrator is to check the status of the vShield Edge Services, such as the Load Balancer, DHCP and IPsec (VPN) Services. This will provide you with the status of whether the service is “up” or “down” as per the service daemon running on the vShield Edge device. In this example above the Network and Security System Administrator is checking the status of the Load Balancer service.

  • Load Balancer Service (1)
  • Return HTTP result code status (2)
  • Status of the Load Balancer Service (3)

Checking the Status of the vShield Services (DHCP) (Basic)

Mhaines4_12

To get the status of the vShield Edge DHCP Server run the following command VSE-DHCP-Status.bat
Mhaines4_13Note: The above command must be executed on one line, so if you are experiencing any problems check for carriage returns and line breaks.

Checking the Status of the vShield Services (DHCP) (Advanced)

Mhaines4_14

In this instance above you can see that the DHCP service has not been configured and thus the DHCP Service has not been started. In order to start the DHCP Service a DHCP Pool must be created.

  • DHCP Service (1)
  • Return HTTP result code status (2)
  • Status of the DHCP Service (3)

Checking the Status of the vShield Services (VPN) (Basic)

Mhaines4_15

To get the status of the vShield Edge Site-to-Site IPsec VPN Server run the following command VSE-VPN-Status.bat
Mhaines4_16
Mhaines4_17

Note: The above command must be executed on one line, so if you are experiencing any problems check for carriage returns and line breaks.

Checking the Status of the vShield Services (VPN) (Advanced)

Mhaines4_18

In this final instance above, the Network and Security System Administrator can see that the VPN service has not been started and thus the VPN Service is not available.

  • VPN Service (1)
  • Return HTTP result code status (2)
  • Status of the VPN Service (3)

You have now observed the ‘three’ cases in which a vShield Service can be in. That is:

  1. Up
  2. Down
  3. Not Configured

Special thanks to Kaushal Bansal, Sr MTS at VMware for all his help and support. In my final installment of this series, you as the Network and Security System Administrator will learn how to ‘Stop’ and ‘Start’ the vShield Services using the vShield REST API. Be sure to follow @vCloud and @VMwareSP for future updates on this series.

Automation tools with vShield App for scalability through REST APIs: Part 2

By: Michael Haines (Senior Cloud Security Architect)

In the first blog of this series, I introduced a “Network and Security System Administrator” at the company, “Example Systems” – a hypothetical scenario to help best describe how to use the vShield API.

Example Systems intends to use vShield REST API to rapidly provision security and to turn their Tier-1 Applications into a business offering to multiple organizations. In the second blog in this series, we discussed how the Network and Security System Administrator experienced Automation tools with vShield App for scalability through the REST APIs, and in this installment, the Network and Security System Administrator is now ready to use the RESTClient Firefox extension to test the RESTful Web services using the vShield API.

Introducing the RESTClient Firefox Extension

Mhaines3_1

In this example, the Network and Security System Administrator is now going to use the RESTClient Firefox extension to test the RESTful Web services using the vShield API. This extension is available from https://addons.mozilla.org/en-US/firefox/addon/restclient/.

The RESTClient supports all HTTP methods RFC2616 (HTTP/1.1). As a Network and Security System Administrator you will also construct custom HTTP requests (custom method with resources URI and HTTP request Body) to directly test requests against the vShield Manager.

When you first start the RESTClient you will be presented with the following UI. This lab will show you the basics of how to use this RESTclient.

Adding a HIGH Precedence Firewall Rule – STEP 1 (Basic)

Mhaines3_2

Get the current vShield App firewall configuration.

1.VERB GET (1)
2.REST API request (2)
3.Add Request Header (3)
4.Add Request Header (4)
5.Press Send (5)
6.Check Request Response (6)

Mhaines3_3 Mhaines3_4The following code represents the script vShield-App-Firewall-Add.bat

Note: The above command must be executed on one line, so if you are experiencing any problems check for carriage returns and line breaks.

Adding a HIGH Precedence Firewall Rule – STEP 2 (Basic)

Mhaines3_5

Add the request body vShield App firewall configuration.

  1. VERB POST (1)
  2. REST API request (2)
  3. Add Request Header (3)
  4. Requested Headers Added (4)
  5. Press Send (5)
  6. Check Request Response (6)

Adding a HIGH Precedence Firewall Rule (Advanced)

Mhaines3_6

Based on an example of your corporate security policy, you are now going to add a high precedence firewall rule. As the Network and Security System Administrator remember that vShield App is a hierarchal firewall and you can configure the firewall rules at the Datacenter (DC), Cluster and Portgroup level. When you apply the actual firewall rules they are applied to all the three levels and the rule set on the vShield App appliance looks like the following:

Datacenter High
Cluster
Portgroup/Network/DvPG
Datacenter Low
Datacenter Default

As the Network and Security System Administrator you have decided based on the organizations security policy that you want to allow HTTP in the organizations Datacenter (DC), but to allow access to a specific Cluster or PortGroup without actually modifying the DC rules. Here you can:

  1. Add a Datacenter (DC) Low precedence HTTP ALLOW rule
  2. Now if a Portroup or Cluster wants to override this, then as the Network and Security System Administrator you can add a HTTP deny rule, which will deny HTTP in that particular Cluster or Portgroup, but not for others in the organization.
  3. Similarly if you as the Network and Security System Administrator want to deny something and does not want this to be overruled, you can add a High Level rule and no one can override this. Note: The Precedence feature is ONLY available at Datacenter (DC) level.

The Network and Security System Administrator is now going to add a High precedence rule for ANY->Cluster TCP 80 Allow. In this example you will use the REST Client for Firefox as in the above example.

Note: There are three important things that you as the Network and Security System Administrator must be aware of before you can add a firewall rule:

  1. The VERB is a POST (1)
  2. The actions is a save (2)
  3. The If-Match (3) header should contain the value of Etag Header from the response of the GET request call.
  4. The vShield App rule that will be added should have a ruleId as ’0′. (4)
  5. The vShield App precedence IDs should match the response of the GET request call. (5)

Getting only the HIGH Precedence Rules from the vShield App Firewall Configuration (Basic)

Mhaines3_7

To get the HIGH Layer 3 precedence vShield App firewall rules run the following command vShield-App-Firewall-Rules-Layer3-HIGH.bat

Mhaines3_8Note: The above command must be executed on one line, so if you are experiencing any problems check for carriage returns and line breaks.

Getting only the HIGH Precedence Rules from the vShield App Firewall Configuration (Advanced)

Mhaines3_9

In this example, the Network and Security System Administrator wants to get only the HIGH precedence rules from the vShield App Firewall Configuration for the context datacenter-2. To do this you issue the following request as in the above example (1).

Please note the REST Request Method (2) and precedence level (3).

Getting only the LOW Precedence Rules from the vShield App Firewall Configuration (Basic)

Mhaines3_10

To get the LOW Layer 3 precedence vShield App firewall rules run the following command vShield-App-Firewall-Rules-Layer3-LOW.bat

Mhaines3_11Note: The above command must be executed on one line, so if you are experiencing any problems check for carriage returns and line breaks.

Getting only the LOW Precedence Rules from the vShield App Firewall Configuration (Advanced)

Mhaines3_12

In this example, the Network and Security System Administrator wants to get only the LOW precedence rules from the vShield App Firewall Configuration for the context datacenter-2. To do this you issue the following request as in the above example (1). As you can see, the Network and Security System Administrator has not added any LOW precedence rules, hence the request response is NULL.

Please note the REST Request Method (2)

Deleting All the Rules from the vShield App Firewall Configuration (Basic)

Mhaines3_13

To delete all the vShield App firewall rules run the following command vShield-App-Firewall-Delete.bat

Mhaines3_14Note: The above command must be executed on one line, so if you are experiencing any problems check for carriage returns and line breaks. 

Deleting All the Rules from the vShield App Firewall Configuration (Advanced)

Mhaines3_15

In this final step as the Network and Security System Administrator you have decided to delete all the firewall rules from the Datacenter (DC), other than the default rules. In this example, you want to delete all the rules from the vShield App Firewall Configuration for the context datacenter-2 . To do this you will issue the following request as in the above example (1).

Please note the REST Request Method (2).

Also, note that you can see the Response Code as in (3). This is NOT an error state. This is actually correct and the server has fulfilled the request but does not need to return an entity-body. In fact the 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.

Note. If the default rules have been modified, they will be reset to default values.

Now this workflow is at the Datacenter level, but it is possible to perform and follow a similar workflow for Cluster and Portgroup. If you recall cluster or portgroup does not contain any default rules.

Special thanks to Kaushal Bansal, Sr MTS at VMware for all his help and support. In my next blog, I’ll show how the Network and Security System Administrator can begin to work with the vShield Edge REST API. For future updates about this series, be sure to follow @vCloud and @VMwareSP on Twitter.

The Important Role of Virtualization in Securing the Cloud

According to David Hunter, CTO of platform security at VMware, “Security in the cloud is better as a result of virtualization,” making the cloud “even more secure than your physical datacenter.

How does virtualization achieve this? Because virtualization consolidates multiple physical components so that they can be managed in one place, it mitigates the complexity of monitoring these components across both internal and external infrastructure. For example, through virtualization, IT teams can standardize VM images and create back up versions of critical VMs more frequently than in the past, simplifying recovery.

By virtualizing your company’s infrastructure, IT admins can also create trust zones around information, applications and endpoints that can be adapted to follow workloads through the cloud. Automated policies can then assess risk and immediately initiate remediation with security problems arise.

In short, virtualization enables organizations to have greater control and better visibility into their infrastructure, simplifying security management for the cloud.

Furthermore, according to a recent report by Enterprise Strategy Group, many virtualization, cloud computing, and security vendors are integrating solutions and building virtualization intelligence into security technology, in order to “bake” security into virtualization and cloud computing technology. This effort will ultimately make virtualization and cloud computing solutions even more secure than legacy technologies.

With VMware vShield, VMware uses virtualization technology to address the important concerns for security and compliance in the cloud. The latest edition of vShield, vShield 5, allows customers to leverage virtualization technology to simplify their datacenter security, deploy a security model that scales for the cloud, and assess and automate compliance requirements. VMware’s network of partners also gives customers the flexibility for fast and dynamic reconfiguration of resources across datacenters.

For more information on security in the cloud, download our recent whitepaper with CSO, and be sure to follow @vCloud and @VMwareSP on Twitter for future updates.  

Announcing the General Availability of vCloud Connector 1.5

By Neha Sampat

Today VMware is happy to announce the general availability of vCloud Connector 1.5, helping to make public and hybrid cloud computing a reality for the enterprise. 

This hybrid cloud tool gives companies the freedom to move workloads between private Sphere and vCloud Director environments, from their private vCloud environments to public clouds and back, or from one vCloud service provider to another.

With vCloud Connector 1.5, customers can transfer workloads between clouds more reliably and efficiently than ever.  Users can also view VMs and templates across multiple clouds and perform basic operations through a new Web-based UI of vcloud.vmware.com.

Now Access vCloud Connector through a Browser

Ecosystem_vcc

Feature Highlights in vCloud Connector 1.5: 

More Reliable Transfer of Workloads: Transfer virtual machines and templates between clouds more reliably and efficiently with features like multi-part transfer, built-in compression and checkpoint restart.

Single Pane of Glass, Now through Web UI: Continue to view VMs and templates across multiple clouds and perform basic operations such as power and console access within the vSphere client, now also accessible through Web-based UI of vcloud.vmware.com.

Support for latest version of vSphere (5.0) and vCloud Director (1.5)

Search Function: Finds specific VMs, vApps, and templates by name in large clouds

New Search Function in vCloud Connector 1.5

ViewWorkloads_search

Learn more about what’s new in the vCloud Connector 1.5 Release Notes.

An Early Response from Customers

Here’s a sample of what IT professionals, architects and engineers ranging from small businesses to large enterprises have had to say after beta testing vCloud Connector 1.5: 

On Ramp to Public Cloud

"vCloud Connector has made cloud-services accessible to our organization and has given us an on-ramp to the public cloud.”  

“vCloud Connector allows me to effortlessly transfer workloads from cloud to cloud, and vCenter to cloud instances.  It is a very handy tool to have!”

“vCloud Connector helps get us started with hybrid clouds. It is the perfect tool to help our customers make the transition to public vClouds.”

“vCloud Connector 1.5 allows me to reliably transfer VMs, vApps and templates across private clouds and public vCloud Services. VMware vCloud Connector makes hybrid cloud computing possible in the real world.”

Simplifies Workload Transfer

“VMware vCloud Connector makes it possible to move workloads from different clients to and from their own systems to our Public cloud, making our service much easier to get.”

“vCloud Connector 1.5 allows my team to quickly move/migrate virtual resources in one well-defined ‘environment,’ being less prone to error.” 

“A much needed bridge solution which enabled us to move our VMs around without additional management headaches.” 

Oxford University's Journey to the Cloud

At Oxford, cloud and virtual technology brings research into twenty first century and beyond.  A recent blog post captures Oxford's efforts to build a virtual infrastructure with database as a service for researchers and how vCloud Connector was used to help them move data to the cloud.

View additional customer testimonials and case studies related to the use of vCloud Connector 1.5 through an early look at our customer research results:

Feedback from vCloud Connector 1.5 Beta Users

Techvalidate

Test Drive a Public Cloud

At VMworld 2011 in Las Vegas, VMware launched vcloud.vmware.com, an online destination designed to help make enterprise public cloud computing a reality.  Join the users who have connected with a vCloud Service Provider and applied to test drive a public cloud today.

Learn more about the new features available in vCloud Connector 1.5

Check out our blog where we introduced the public beta of VCC 1.5. Our guest blogger, David Davis, also wrote a great blog highlighting the ‘Must Knows’ of vCloud Connector 1.5 (including videos and screenshots).  

Feel free to comment or tweet us your feedback via @vCloud and @VMwareSP!

Automation tools with vShield App for scalability through REST APIs: Part 1

By: Michael Haines (Senior Cloud Security Architect)

In my last blog, I introduced a hypothetical situation using a Network and Security System Administrator at the company, “Example Systems,” in order to best describe how to get started with the vShield API. Their company intends to use vShield REST API to rapidly provision security and turn CodeNebulous' Tier-1 Application into a business offering to multiple organizations. The Network and Security System Administrator has already learned some basic principles about REST and the vShield API and is now ready to use Automation tools with vShield App for scalability through REST APIs.

The Network and Security System Administrator Begins to Work with the vShield App REST Firewall API

The Network and Security System Administrator is now ready to start configuring the vShield App Firewall rules. They have a choice to make with regards to how they want to configure the Firewall rules. The Network and Security System Administrator can choose either:

  1. Datacenter
  2. Cluster
  3. Portgroup or Network

With vShield App there will be 'Two' default rules (1 Layer3 , and 1 Layer2) which are configured at DC level. There are 'None' at Cluster and 'None' at Portgroup level.

Before the Network and Security System Administrator can start to use the vShield App REST API Firewall API they must:

1.Get and return vShield's App stat for a datacenter. This will provide them with the status of vShield App.

2.Provide the correct vShield Authorization.

  • All vShield REST requests require authorization and which by default (in the product documentation) use the following basic authorization: Basic YWRtaW46ZGVmYXVsdA== 

Where YWRtaW46ZGVmYXVsdA== represents the Base 64 encoding of the vShield Manager default login credentials which are admin:default

How the Network and Security System Administrator Determines the Datacenter Context Identifier

Mhaines2_1

Before the Network and Security System Administrator can submit any requests to the vShield App Firewall there is a key piece of information that they are required to supply. But how are they going to obtain this information. The first task is for the Network and Security System Administrator to login to the Virtual Center as in this example (1)

Providing the Virtual Center Credentials

Mhaines2_2

Once the Network and Security System Administrator has completed the above step they are asked for the Virtual Center 'username' and 'password'. But what is the username and password? Well the username can be obtained from the vShield Manager as in the following example. The Network and Security System Administrator goes to Settings and Reports (1) and the Administrators User Name is shown as denoted by (2). 

The Network and Security System Administrator now Logs In

Mhaines2_3

Once the Network and Security System Administrator has successfully logged in they will see the ManagedObjectReference:ServiceInstance. 

Traversing the ManagedObjectReferenceServiceInstance

Mhaines2_4The Network and Security System Administrator has successfully logged in and is now presented with the following. They now select the 'content' URI as shown by (1).

Traversing the Data Object Type ServiceContent

Mhaines2_5

After selecting the content property the Network and Security System Administrator now is presented with the ServiceInstance properties. Here the Network and Security System Administrator is looking for the rootFolder as in the example above (1) and on the rightmost side they should be seeing something like group-d1 (Datacenters) (2). The Network and Security System Administrator selects the group-d1 (Datacenters).

Getting the Datacenter ID

Mhaines2_6

After the Network and Security System Administrator selects the group-d1 (Datacenters) they can see the ManagedObjectReference group-d1. The important piece of information they require is shown in the ManagedObjectReference:ManagedEntity[] as shown in the example above (1). 

The vShield Manager View of the Datacenter

Mhaines2_7

The Network and Security System Administrator can also see the reference to CORP within the vShield Manager as shown here (1)

Getting the State of vShield App (Basic)

Mhaines2_8

To get the state of vShield App run the following command vShield-App-State.bat

Mhaines2_9Note: The above command must be executed on one line, so if you are experiencing any problems check for carriage returns and line breaks. 

Additionally, There is no REST call like firewall state. As soon as you install App on any of the ESX host, it configures to allow rules on the datacenter and publish them on the appliance. So default state is firewall on with everything allowed. The status call actually tells whether the rules are successfully published on the appliance. 

Getting the State of vShield App (Advanced)

Mhaines2_10

In this example, the Network and Security System Administrator wants to get the basic state of vShield App. To do this they issue the following request as in the above example (1).

Mhaines2_11

Note: The above command must be executed on one line, so if you are experiencing any problems check for carriage returns and line breaks.

Getting the Status of vShield App (Advanced)

Mhaines2_12

In this example, the Network and Security System Administrator wants to get the status of vShield App. To do this they issue the following request as in the above example (1).

Mhaines2_13

Note: The above command must be executed on one line, so if you are experiencing any problems check for carriage returns and line breaks. 

Getting the Complete vShield App Firewall Configuration (Basic)

Mhaines2_14

To get the complete vShield App firewall configuration run the following command vShield-App-Current-Configuration.bat

Mhaines2_15Note: The above command must be executed on one line, so if you are experiencing any problems check for carriage returns and line breaks. 

Getting the Complete vShield App Firewall Configuration (Advanced)

Mhaines2_16

In this example, the Network and Security System Administrator wants to get the complete vShield App Firewall configuration for the context datacenter-2 . To do this they issue the following request as in the above example (1).

Mhaines2_17

Note: The above command must be executed on one line, so if you are experiencing any problems check for carrage returns and line breaks.

Special thanks to Kaushal Bansal, Sr MTS at VMware for all his help and support. In my next blog, I will introduce the Network and Security System Administrator to the RESTClient Firefox Extension.  Make sure you catch the next installment in this series by following @vCloud and @VMwareSP on Twitter.

Getting Started with the vShield API

By: Michael Haines (Senior Cloud Security Architect)

In order to best explain how to get started using the vShield API, we’regoing to introduce a hypothetical example of an implementation using a traditional Network and Security System Administrator at the company,“Example Systems.” This is the first in a five-part blog series on usingthe vShield API.

The Network and Security System Administrator has found out that Example Systems intends to turn their Tier-1 Application into a business offering to multiple organizations and now needs a way to repeatedly and rapidly deploy the same application every time a new customer comes online. To help with this the Network and Security System Administrator intends to use the vShield REST API's to rapidly provision security.

But before the Network and Security System Administrator can begin to use and work with the vShield REST API they need to understand some of the basic principles about REST and vShield API.

  • The vShield Manager requires ports 80/TCP and 443/TCP to be open for the vShield REST API requests to pass through.
  • All vShield REST requests require authorization. You can use the following basic authorization: Authorization: Basic YWRtaW46ZGVmYXVsdA== (I will cover this in more detail in the following lessons).
  • There is no login required as in other similar REST based applications.
  • The Network and Security System Administrator will need to use the vShield REST APIs to determine the mo-refs Id of the VI managed Objects like datacenter, cluster etc.

——–

When the Network and Security System Administrator has successfully implemented the security policy and security architecture using the vShield products, they will want to start looking at how to use and implement the vShield API.

This section of the blog introduces the Network and Security System Administrator to the VMware vShield API. In these series of blogs the Network and Security System Administrator will get hands on programming experience with the vShield API and learn how to consume the API in their own programs and applications. The Network and Security System Administrator does not need to be a developer, although basic programming concepts will help them understand the vShield API better.

An introduction to the vShield REST API, and some of the background concepts for Network and Security System Administrator's can be found at the end of this post. Feel free to forward to the end and read the basics before proceeding if you are completely new to programming.

The vShield REST API uses HTTP requests (which are often executed by a script or other higher‐level language) as a way of making what are essentially remote procedure calls that create, modify, or delete the objects defined by the API. This vShield REST API (and others) is defined by a collection of XML documents that represent the objects on which the API operates. The operations themselves (HTTP requests) are generic to all HTTP clients.

The vShield REST work flows fall into a pattern that includes only two fundamental operations:

1. Make an HTTP request (typically GET, PUT, POST, or DELETE). The target of this request is either a well‐known URL (such as the vShield Manager) or a link obtained from the response to a previous request. 

2. Examine the response, which can be an XML document or an HTTP response code. If the response is an XML document, it may contain links or other information about the state of an object. If the response is an HTTP response code, it indicates whether the request succeeded or failed, and may be accompanied by a URL that points to a location from which additional information can be retrieved.

Special thanks to Kaushal Bansal, Sr MTS at VMware for all his help and support. In our next blog, we will introduce the Network and Security System Administrator to Automation tools with vShield App for scalability through REST APIs. Be sure to follow @vCloud and @VMwareSP on Twitter to catch the next post in this blog series!

For better context:

A More In-Depth Look at REST

Definitions:

REST Representation State Transfer

  • REST is an architecture design for building that loosely couples services, highly scalable and can use HTTP protocol.

Resources

  • A resource is anything that is identified by a URI. Although this appears to be a circular definition, there is no formal definition of what might be a resource. It can be anything.

Representation

  • A representation is an encapsulation of the information (state, data or markup) of the resource, encoded using a format (e.g., HTML).

HTTP HyperText Transfer Protocol

  • HTTP is based on a request and response synchronous communication; it is stateless, distributed and very scalable.

URI Uniform Resource Identifier Uniquely identify a resource on the server which provides a service

  • A client such as a web browser sends a request to a server using one of four methods and expects some service performed. The methods are POST, GET, PUT and DELETE.

REST stands for "Representational State Transfer", which may make things less clear to understand. So, instead of trying to dissect what this means, let us consider a simple web based application, something you do everyday.

1. (client) User goes to the home page and clicks a button.
2. (client) The browser submits an HTTP request to the server.
3. (server) The server send back a responds with an HTML document containing some links and forms for example.
4. (client) User fill's in a form and submits it.
5. (client) The browser submits another HTTP request to the server
6. (server) The server processes the request, and responds with another page.

The above exchange will continue until you stop browsing. Except for a few exceptions, most web sites and web based applications follow the same logic.

Let's take a closer look, and see how this is related to REST. 

Putting it all Together 

The key concept here is of a stateless client-server architecture where clients send requests to servers, which in return send back responses. Pretty simple, eh? Rather than the client and the server maintaining state, the state is transferred in the requests and responses. This is what "representational" means, in that there is some representation of the state exchanged between client and server. There are a number of things that REST architectures impose. If you adhere to these constraints, your architecture is considered RESTful (I will discuss this a little later). It just means that your architecture obeys the REST constraints.

REST is not new, but it has become in-vogue fairly recently. Basically the entire web is built on REST concepts. Every time you click a button on a web page in a web browser (client) you're sending a request to a web server, which in turn sends back a response. This does not mean that all web services are REST-based, of course, just that they share some of the characteristics. A good example of a RESTful application is Google Mail. When you log into Google Mail, it sends a request to get the contents of your inbox (actually the latest n messages). The Google Mail server sends back a *representation* (the R in REST) of your inbox, which the client displays. You can then click on a message to read it, which sends a request to the server for the contents of the message. Actually, it's a little more complicated than this, since Google Mail can be doing things behind the scenes while you are reading messages. The point is that the Google Mail server has no idea which set of messages you are reading or which message is currently displayed. It keeps no state (i.e., it's "stateless".)

If it helps, you can consider the client being "at rest" when it's not actively engaged in communication with the server.

Also note that RESTful architectures do not have to be based on the HTTP protocol. You could implement them over any protocol you like. It's just that typically, HTTP is what RESTful implementations are based on.

Note carefully the list of 6 Constraints.

Summary

In this short background, I have attempted to provide an introduction into the concepts behind REST. A RESTful HTTP approach to exposing functionality is different from RPC, Distributed Objects, and Web services, it takes some mind shift to really understand this difference. Being

Objects, and Web services, it takes some mind shift to really understand this difference. Being aware about REST principles is beneficial whether you are building applications that expose a Web UI only or want to turn your application API into a good Web citizen.

More REST References and Resources:

There are many sources of information about vShield and REST, here are a few to get you started:

The Public Cloud Diaries Part II – How Communications and Healthcare Organizations Have Benefited from the Public Cloud

We recently introduced our first installment of the Public Cloud Diaries – an ongoing project that showcases the various business situations and challenges that companies have experienced when moving to the public cloud. In Part I, we detailed the experiences of four companies in the Business Services Industry, and the ROI they achieved in moving to the public cloud.

In our second installment, we’ll take a look at the experiences of four companies from the Communications and Healthcare industries. 

Communications

Company 1: Media and Communications Firm for Pharmaceutical Companies
The Needs: The firm was searching for a cloud vendor with value-added services, managed services expertise, and unparalleled reliability.  In addition, because it served the healthcare industry, it needed to comply with strict guidelines
The Solution: The vCloud Service Provider they chose provided 99.999% up time and complied with HIPAA and SAS 70 guidelines of the healthcare industry.
The ROI: The company did not have to hire more IT staff or a special SAS 70 consultant to help implement the cloud solution. 

Company 2: Telecommunications Company
The Needs: The company needed a cloud provider for data back up with managed services and expertise, as well as the ability to operate in a hybrid cloud with their own internal private and public clouds.
The Solution: A vCloud Service Provider with multiple virtual servers at two physical locations was chosen; this configuration allowed them to restore rapidly should a disaster occur.
The ROI: The VMware solution provided reliability, IT efficiency, the ability to restore a single file via a GUI in minutes and the complete removal of hardware responsibility. 

Healthcare

Company 1: Software Company that Provides Services and Scrub Engines for Healthcare Claims Processing
The Needs: Initially this company wanted to build its own IT team and datacenter but realized that a cloud solution would be more suitable due to the fluctuations in demand for its service.  However, any cloud solution they used had to comply with stringent healthcare industry guidelines.
The Solution: A vCloud Service Provider that was compliant with SAS 70 Type 2 and HIPAA guidelines provided a 99.9% up time for the company and implemented the cloud infrastructure in a few months.
The ROI: The company avoided the major cost of building and maintaining its IT structure in-house, which enabled it to focus on its core business.

Company 2: Beta-mode Healthcare Startup that Provides Access to Online Database for Evaluating Risk of Skin Conditions and Wounds
The Needs: The startup first used Amazon Web Services cloud, and while it was affordable, it offered no free support besides through a forum. Amazon Web Services also provided little information on how the cloud was secured or where data was stored.  The company was looking for a solution with more services and security.
The Solution: A vCloud Service Provider offered security knowledge and existing credentials for the healthcare industry, as well as a high level of support.
The ROI: The startup enjoyed savings by reducing upfront costs and eliminating the need to find an experienced cloud operations or healthcare compliance consultant.  Also, it found a solution that can grow with the company.

Next week we’ll highlight the experience of four companies in the Insurance, Non-Profit and Retail Industries who moved to the cloud with VMware.

For more info on these diary entries, download the complete Public Cloud Diaries, and be sure to follow @vCloud and @VMwareSP to catch our third installment in this series. 

Best Practices for Providers Offering vCloud Powered Services Part 3: Help Customers Stay Ahead with VMware vFabric Hyperic

Many customers of providers who offer vCloud Powered services are IT organizations that have customers of their own, and thus, have specific service-level agreements (SLAs) that they must meet. In order to support their customers’ SLAs, service providers can utilize VMware vFabric Hyperic to manage the performance and availability of web applications in cloud environments. This is the third installment in our series of ‘best practices’ for providers who offer vCloud Powered services.

vFabric Hyperic enables service providers to discover and monitor all of the virtual machines supporting an application. This ability makes it possible for providers and customers to work together and ensure that business-critical applications are able to run with the performance and availability that is required to meet specific SLAs.

In addition, providers who offer vCloud Powered services can utilize vFabric to provide multiple tiers of service to customers, and in turn, increase the amount of revenue received per virtual machine. By creating multiple service tiers, customers have the ability to opt into a provider’s base offering for ad-hoc jobs that don’t need a specific level of service, or purchase a premium level of service for mission-critical workloads. These multiple tiers of service can help customers meet their SLAs while also affording them the flexibility to pay only for the levels of service they require. These tiers also allow service providers to establish and charge more for higher levels of service provided by their cloud environments. 

Hyperic can also provide customers with other value services. For example, providers offering vCloud Powered services can use Hyperic to automatically scale applications according to workload demand, to monitor changes to an application’s virtual infrastructure (so that they can keep track of customer changes that may affect service levels) and to receive alerts when performance thresholds are exceeded—that way, service providers can respond to performance issues quickly and avoid the penalties of not meeting SLAs. 

By helping their customers meet strict SLAs, providers who offer vCloud Powered services are able to strengthen not only their own offerings, but also the offerings of their customers.

Keep an eye out for our final installment in this series, in which we will be covering how service providers offering vCloud Powered services can make their cloud offerings safe, secure, and easy with VMware vShield technologies. Be sure to follow @vCloud and @VMwareSP for future updates.