Home > Blogs > vCloud Architecture Toolkit (vCAT) Blog

Related VMware vFabric Reference Architecture released

Now available, the highly anticipated vFabric Reference Architecture!!!

Customers, partners and VMware field can leverage the practical templates, examples and guiding principles authored by VMware’s vFabric experts to design, implement and run their own integrated vFabric middleware technology suite.

Download the vFabric Reference Architecture at www.vmware.com/go/vFabric-Ref-Arch.

vCAT 3.1 released with videos

vCAT 3.1 was released several weeks ago in time for PEX. We have added updates to vCenter Chargeback and vCloud Connector. Please see the release notes for specific details on content change.

vCAT 3.1 now includes two sets of videos in support of the vCloud Architecture Toolkit.
a) Executive videos – We have provided several short executive briefs on VMware Validated Architectures, vCAT, our use internally of vCAT, and alignment of our Cloud Infrastructure Management (Layer 1) set of technologies. Currently we have postings from Pat Gelsinger, Ray O’Farrell, Bogomil Balkanski, Scott Aronson, and Mark Egan.
b) Subject Matter Expert (SME) videos – We have included 10 videos covering the Document Center tool for viewing the documentation, and one for each of the 9 document areas.

VMware Press release
VMware Press will be publishing the vCAT 3.1 release for those wishing a printed copy.

As always, we welcome your feedback on how we can improve on our vCAT.next release. Please send feedback to ipfeedback@vmware.com.

vCloud Director Service Builder and the vCloud Director workflow run service

 

In vCAT 3 we described how we could leverage vCloud Director blocking tasks and notifications to extend vCloud Director with new capabilities and as part of the workflow examples document, provided the notification package as an implementation example leveraging vCenter Orchestrator rich library of workflows.

vCloud Director 5.1 introduced a new API extensions feature allowing a cloud provider to extend the vCloud API with developing services providing functionality not available in the vCloud API. These API extensions have been covered in details on Christopher Knowles’s theclouds.ca blog. Thomas Kraus wrote about implementing a specific service leveraging a vCenter Orchestrator workflow on his Cloud Actual blog.

Now it is my turn to release a tool to create custom services leveraging any vCenter Orchestrator workflow as a service operation. “vCloud Director Service Builder” is a wizard based workflow allowing to create new services and their operations in a few clicks.

In addition once a service operation has been started the included “vCloud Director workflow run” service allows managing the workflow life cycle.

Get vCloud Director Service Builder and the vCloud Director workflow run service and find out more information in the vCenter Orchestrator Communities.

 

Enforce System Wide CPU/Memory limits in vCloud Director

Have you ever wished you could prevent users from powering on VMs in your vCD environment with 4 or more CPUs? How about preventing VMs with more than 8 GB of memory from powering up? There may be performance benefits to enacting such limitations depending on the number of CPUs and cores the physical hosts in the underlying cluster have available.

While neither of the above items are possible with any basic settings, such control can be enforced in your vCloud Director environments. Laying out every step in detail to accomplish this task is beyond the scope of today’s post, but the basic steps are as follows:

  • Configure an AMQP server
  • Enabling the “Start vApp (Deploy from api)” blocking task
  • Specify a vCenter Orchestrator workflow to subscribe to the queue

If you find this concept interesting and feel you would benefit from such a solution, please leave me feedback as a comment to the Workflow Examples document in the Orchestrator Community.

Impact of “Greenfield” on the Organizational Constructs

 How does the Organizing for Cloud Operations section of the Operating VMware vCloud document apply to a new cloud operations organization for a “greenfield” VMware® vCloud deployment? In other words, what if we’re unencumbered by a legacy IT organization and its processes? This question has come up during several customer conversations recently. Admittedly, we’ve focused our work in this area on establishing cloud operations in the context of an existing IT organization.  By the nature and newness of the vCloud Tenant Operations organizational construct, it holds whether it’s a new organization implementation or an addition to an existing IT organization. What is impacted, though, is the Cloud Infrastructure Operations Center of Excellence (COE).   

The way I look at the impact is the Cloud Infrastructure Operations (COE) and key members of its ecosystem combine to become the new vCloud operations organization. Now, that is a bit of an oversimplification, but at its essence this is the case. As usual, the “devil is in the details.” A couple of key details I’d like to touch on are vCloud operations processes and vCloud operations role skillsets.

vCloud operations processes are the easier of the two. Standing up a new vCloud operations organization unencumbered by existing IT operations processes means you have the advantage (luxury?) of starting from scratch. The processes can be purpose-built for vCloud operations; taking advantage of new vCloud management tools capabilities and their impact on operations processes.  For example, taking advantage of the VMware vCenter™ Operations Manager™ impact on the event, incident, problem process cycle, or moving to policy-driven compliance with vCenter Configuration Manager™, or setting up Change Management with the goal of pre-approved, standard changes for capabilities such as VMware vSphere® vMotion®, HA, or DRS. How nice would that be?

The impact of a implementing a cloud operations organization unaffected by a legacy IT organization for a greenfield vCloud deployment on the role skillsets is particularly interesting to me. I believe this opens up some impactful possibilities. I’m thinking here of individuals responsible for physical networking and physical storage, for example. Creating these roles anew for cloud operations affords the opportunity for them to become experts in virtual networking and virtual storage as well. They become the vCloud networking SME and vCloud storage SME; a very powerful combination. In the Cloud Infrastructure Operations COE as part of a legacy IT organization version, the virtual networking and virtual storage expertise would reside within the COE Cloud Architect role. The Cloud Architect would regularly interact with the “champions” from the physical networking and storage teams, but there would be a separation of expertise. This clearly isn’t as efficient, but necessary when implementing within the context of a legacy IT organization. This would apply to other ecosystem functional groups as well. 

That said, what I just described would equally apply to how the Cloud Infrastructure Operations COE and it ecosystem would change as the vCloud infrastructure scales out and becomes the primary IT infrastructure environment used. But, transitioning the Cloud Infrastructure Operations COE and its ecosystem is far more challenging than creating a purpose-built cloud infrastructure operations organization from scratch.

Finally, what are the implications of these roles in a purpose-built vCloud infrastructure operations organization from a specialist versus generalist perspective?  This is another debate that, while I wouldn’t say it’s raging, it certainly the topic of some interesting conversations. I certainly have my views on this topic, but I’ll save those for another post.

vCAT Workflow Examples – What would you like to see?

The current release of vCAT features a few different workflow examples for use with vCenter Orchestrator. Those examples were based on the needs of VMware and various client projects we had worked on.

In considering what to include as examples, we had to be sure that we could make the processes generic enough to fit into any organization’s environment. The three released examples are:

Each of the examples above may be used as they are but are commonly used as starting points to larger custom projects around vCloud Director.

We want to hear your ideas on how to make the above packages better as well as ideas for new packages. Please post your ideas as comments to the vCAT Workflow Examples document post in the communities here: http://communities.vmware.com/docs/DOC-20230

 

vCAT Software Tools

The vCloud Software Tools document provides the reader with instructions on how to use some of the tools that are available for implementing, managing and reporting on your vCloud cloud environments.

vCloud Director Audit provides automated report generation against a vCloud Director deployment, providing you with details on how the vCloud environment is configured, provisioned and being consumed by the tenants of the cloud.

vCloud Provisioner provides an automated framework for describing the configuration requirements of the cloud being provisioned and the execution of that discription against a vCloud Director implementation in order to automatically create all of the underlying vCloud objects necessary to deliver the services described in the provisioner description.

Cloud Cleaner allows you to provision a vCloud Director instance on top of a vSphere environment, perform any testing or evaluation you may wish to carry out and then clean up anything performed against the vSphere environment by vCloud Director, returning the vSphere environment to a pre-vCloud Director state. This is useful when evaluating vCloud Director, or educating yourself on how vCloud Director is implemented on an underlying vSphere environment

Orchestrating the Cloud


vCloud Suite provides all the components that are important to manage successfully a cloud. These components are integrated to provide a seamless out of the box experience for all the important operations .  This is great but there is a possibility do do a lot more.

The different components have APIs allowing to communicate with each other. Orchestration has plug-in adapters to drive these APIs in processes we can all understand : workflows.

Using Drag&Drop a cloud administrator can chain together operations from the different components to get a single new automated multi-step operation. For example in vCAT 3.0 there is a workflow example for mass import of vCenter VMs in vCloud Director including automatic remapping of their networks.

These operations are not limited to VMware components. Several vendors provide plug-in adapters for their own technologies so they can be automated in the same way. If there is no specific vendor plug-in adapter available then there are generic adapters such as SOAP, REST, PowerShell, SSH, SQL, mail, XML allowing to communicate with most third parties applications.
In vCAT 3.0 there is a “Custom deploy vApp” provisioning workflow that can be expanded to call out to these systems. For example this is used to get IP addresses from an IPAM system.

These custom workflows can be started directly by end users in several ways:

  • By the cloud admins and operators with using the vSphere Web Client as single pane of glass user interface.
  • By the cloud end users with using our self service catalog vCloud Automation Center
  • If necessary, workflows can be called automatically by an existing custom portal using the REST API of vCO.

In addition workflows are used indirectly:

  • Scheduled : For example recurrent maintenance operations.
  • As an extension of an existing process : For example the workflow example section contains a “blocking tasks and notification workflow” allowing to associate a specific workflow for a given vCLoud Director blocking task or notification. This is used for example to perform pre or post provisioning tasks or approvals.
  • As a new service providing new processes with leveraging the vCloud Service extensions : Creating a new URL for the vCloud API and associate it with a workflow to enable new services that can drive any of the internal or external components.
  • As a remediation system by leveraging vCenter Orchestrator policies triggering workflows on incoming events. For example vCenter Operations can trigger a workflow to remediate the issue that has been observed.

For further information on the workflow examples please check vCAT 3.0.
For further information on vCenter Orchestrator please check the product page and the blog page.

The Lifecycle of Cloud Services

For this update, I’d like to step away from the purely technical areas of vCAT and talk about some operational process areas that I’m spending some time on at the moment.

Within the Operating a VMware vCloud document of vCAT 3.0 we talk about Service Lifecycle Management. From a high level, I’d like to build on this and start identifying the steps required to get a standardized service available to our customers and who’s responsible for each step.

What does the customer want?

Depending on your cloud model, if you’re offering a cloud with a level of end-customer service, then there should probably be a Customer Relationship Manager in place for your customers, or at the very least for the major customers who are active users of your cloud. This Customer Relationship Manager will know and understand the needs that the customer has for the cloud and it’s services. It’s those customer needs that will drive the next services to be offered from your cloud, as they are the ones with the business focus and the problems that the cloud will help solve. Remember, internal IT is now a Cloud Provider in a competitive market and is competing with other external Cloud Providers for your customers Cloud services. IT now needs to start focusing on providing Business Services rather than on supplying IT.

Create Cloud Service Roadmap Based on Need

The Cloud service portfolio needs to take on these customer needs, and it will be the Portfolio Manager who will require a process for taking these customer needs from all of the Customer Relationship Managers and determine their applicability. By performing this function, the Portfolio Manager is able to identify common requests for services from multiple customers.  They can then create a prioritized list of potential services to be offered based on demand and function. This list will form the basis of the cloud services roadmap that IT will be offering to their customers and should be shared with these customers.

Take Ownership of the Service

At the point that a service on the roadmap is to be created, a service owner should be identified who will be responsible for the service from this moment forward. This service owner will be responsible for the evolution of the service, from detailed requirements gathering, to its design, development, release, ongoing support and finally its retirement.

Add the Service to the Cloud Service Catalog

At the point that the decision is made by the Service Owner to start developing the service, the service catalog will need to be updated with the services current status. Ideally the service catalog, service portfolio and the self-service portal will all be connected so the transition of a service through its lifecycle can be automated, thus reducing the potential for inaccuracies.

Develop the Service

The development of the service should be undertaken utilizing a blueprinting approach. This will provide the benefit of speeding up the development cycle, as well as increasing reliability as standardized, repeatable and approved blueprints are being used.

Release the Service

On completion of the development cycle, the next phase is to go through the testing/QA/Release cycle to eventually have the service released into the cloud self-service portal thus making the service live. The Service Owner is now responsible for the ongoing support and availability of this service being offered.

When is it Time to Retire the Services?

Finally, the Customer Relationship Manager, Service Owner and Portfolio Manager will perform continued assessment of the service offering until the point comes when the customers no longer require the service. At that point the retirement of the service will need to be undertaken with the service being removed from the service catalog and the self-service portfolio.

So from a high level, this is the lifecycle for cloud services. In further articles, I’ll talk about each stage in more detail.

Please post a comment if you have any questions or if you have suggestions.

 

Re: Working with the vCloud Networking and Security API

Working with with the vCloud Networking and Security API

By: Michael Haines ( Senior Cloud Networking and Security Architect)

In vCAT 3.0 we discuss many of the vCloud Networking and Security components as well as aspects of design principals and best practices to follow. In this blog we take this one step further and show you how to get started with the very powerful and feature rich vCloud Networking and Security API. I will also show you one very important, but overlooked aspect, which is how to interpret the XML data of the Edge device for example, which can be daunting and very hard to read as it is currently enumerated and presented.

The vCloud Networking and Security REST API REST uses HTTP requests (which are often executed in an automated manner, using 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 vCloud Networking and Security REST API 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 vCloud Networking and Security 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 vCloud Networking and Security 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.

Lets take a look at some of the basic elements and examples of actally using the vCloud Networking and Security REST API.  In my examples that follow, I will be using a command-line tool called cURL to consume the vCloud Networking and Security REST API. There is no need for fancy document descriptions here, as we need to only hit each URL with the appropriate method and data to cause an immediate response. 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, as there  are lots of options available for controlling exactly how you want cURL to interface with the remote server.

So, the first thing you will want to do is get a list of the vCloud Networking and Security Edge Gateway devices installed in a Datacenter:

$ curl -i -k -H “content-type: application/xml” -H “host: <vCNS-IP-Address>” -H
“Authorization: Basic YWRtaW46ZGVmYXVsdA==” -X GET https://<vCNS Manager-IP-Address>/api/3.0/edges/

NOTE: YWRtaW46ZGVmYXVsdA== is the base64 encoded string which when decoded.

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID=ED9F79E5921E89A5EFDBB59E7F6DDA0F; Path=/; Secure; HttpOnly
Content-Type: application/xml
Transfer-Encoding: chunked
Date: Mon, 19 Nov 2012 12:12:35 GMT

<?xml version=”1.0″ encoding=”UTF-8″?>
<com.vmware.vshield.edge.dto.EdgePageDto><edgePage><pagingInfo><pageSize>256</pageSize><startIndex>0</startIndex><totalCount>1</totalCount><sortOrderAscending>true</sortOrderAscending><sortBy>objectId</sortBy></pagingInfo><edgeSummary><objectId>edge-3</objectId><type><typeName>Edge</typeName></type><name>test</name><revision>6</revision><objectTypeName>Edge</objectTypeName><extendedAttributes/><id>edge-3</id><state>undeployed</state><datacenterMoid>datacenter-2</datacenterMoid><datacenterName>testbed</datacenterName><apiVersion>3.0</apiVersion><recentJobInfo><jobId>jobdata-27</jobId><status>SUCCESS</status></recentJobInfo><numberOfConnectedVnics>1</numberOfConnectedVnics><appliancesSummary><vmVersion>5.1.0</vmVersion><applianceSize>compact</applianceSize><fqdn>vShield-edge-3</fqdn><numberOfDeployedVms>0</numberOfDeployedVms></appliancesSummary></edgeSummary></edgePage></com.vmware.vshield.edge.dto.EdgePageDto>
$

Next, how can I get the status of a particular Edge gateway:

$ curl -i -k -H “content-type: application/xml” -H “host: <vCNS-IP-Address>” -H
“Authorization: Basic YWRtaW46ZGVmYXVsdA==” -X GET https://<vCNS-IP-Address>/api/3.0/edges/<edge-identifier>/status

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID=D88C4882CCA194760785BE546E537058; Path=/; Secure; HttpOnly
Content-Type: application/xml
Transfer-Encoding: chunked
Date: Mon, 19 Nov 2012 12:12:12 GMT

<?xml version=”1.0″ encoding=”UTF-8″?>
<edgeStatus><timestamp>1342440732007</timestamp><edgeStatus>GREY</edgeStatus><publishStatus>PERSISTED</publishStatus><version>6</version><edgeVmStatus/><featureStatuses><featureStatus><service>highAvailability</service><status>not_configured</status></featureStatus><featureStatus><service>nat</service><status>not_configured</status></featureStatus><featureStatus><service>loadBalancer</service><status>not_configured</status></featureStatus><featureStatus><service>firewall</service><status>Configured</status></featureStatus><featureStatus><service>dns</service><status>not_configured</status></featureStatus><featureStatus><service>staticRouting</service><status>not_configured</status></featureStatus><featureStatus><service>syslog</service><status>not_configured</status></featureStatus><featureStatus><service>ipsec</service><status>not_configured</status></featureStatus><featureStatus><service>dhcp</service><status>not_configured</status></featureStatus><featureStatus><service>sslvpn</service><status>not_configured</status></featureStatus></featureStatuses></vice>edgeStatus>

NOTE: The edge-identifier: It is the edge identifier generated by vCloud Networking and Security Manager to identify an Edge device uniquely within the vCloud Networking and Security Manager.

All Edge operations in vCloud Networking and Security v5.1.x follow this addressing scheme now where the Edge is addressed using its edge-id/edge-identifier.

As you can see from the above examples, the XML data that is enumerated and returned in not easy to read and interpret. Remember, this is a basic example, (as basic as it gets). So, what would happen if you had many Edge devices that was using many of the features? Yes, it would be a lot more complex. So, f you are working with the vCloud Networking and Security REST API, and thus XML you maybe asking yourself how on earth do I read the output of the XML in a more readable fashion?

In the following example I am enumerating a specific Edge device using the following command:

$ curl -i -k -H “content-type: application/xml” -H “host: <vCNS-Manager
-IP-Address>” -H “Authorization: Basic YWRtaW46ZGVmYXVsdA==” -X GET https://<vCNS-Manager-IP-Address>/api/3.0/edges/edge-5
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID=DC63EB7BD4A641E38C62C62F5B4D53AE; Path=/; Secure;
HttpOnly
Content-Type: application/xml
Transfer-Encoding: chunked
Date: Tue, 19 Nov 2012 15:05:35 GMT

<?xml version=”1.0″ encoding=”UTF-8″?><pagedEdgeList><edgePage><pagingInfo><pageSize>256</pageSize><startIndex>0</startIndex><totalCount>2</totalCount><sortOrderAscending>true</sortOrderAscending><sortBy>id</sortBy></pagingInfo><edgeSummary><objectId>edge-5</objectId><type><typeName>Edge</typeName></type><name>vCNS-Edge-Tenant1</name><revision>13</revision><objectTypeName>Edge</objectTypeName><extendedAttributes/><id>edge-5</id><state>deployed</state><datacenterMoid>datacenter-2</datacenterMoid><datacenterName>Cloud Datacenter</datacenterName><apiVersion>3.0</apiVersion><recentJobInfo><jobId>jobdata-47</jobId><status>SUCCESS</status></recentJobInfo><numberOfConnectedVnics>2</numberOfConnectedVnics><appliancesSummary><vmVersion>5.1.0</vmVersion><applianceSize>compact</applianceSize><fqdn>vShield-edge-5</fqdn><numberOfDeployedVms>1</numberOfDeployedVms><activeVseHaIndex>0</activeVseHaIndex><vmMoidOfActiveVse>vm-64</vmMoidOfActiveVse><vmNameOfActiveVse>vCNS-Edge-Tenant1-0</vmNameOfActiveVse><hostMoidOfActiveVse>host-37</hostMoidOfActiveVse <hostNameOfActiveVse>10.129.139.7</hostNameOfActiveVse><resourcePoolMoidOfActiveVse>resgroup-20</resourcePoolMoidOfActiveVse><resourcePoolNameOfActiveVse>Resources</resourcePoolNameOfActiveVse><dataStoreMoidOfActiveVse>datastore-38</dataStoreMoidOfActiveVse><dataStoreNameOfActiveVse>datastore1(2)</dataStoreNameOfActiveVse><statusFromVseUpdatedOn>1351609518000</statusFromVseUpdatedOn></appliancesSummary></edgeSummary><edgeSummary><objectId>edge-6</objectId><type><typeName>Edge</typeName></type><name>vCNS-Edge-Tenant2</name><revision>13</revision><objectTypeName>Edge</objectTypeName><extendedAttributes/><id>edge-6</id><state>deployed</state><datacenterMoid>datacenter-2</datacenterMoid><datacenterName>Cloud Datacenter</datacenterName><apiVersion>3.0</apiVersion><recentJobInfo><jobId>jobdata-39</jobId><status>SUCCESS</status></recentJobInfo <numberOfConnectedVnics>2</numberOfConnectedVnics><appliancesSummary><vmVersion>5.1.0</vmVersion><applianceSize>compact</applianceSize><fqdn>vShield-edge-6</fqdn><numberOfDeployedVms>1</numberOfDeployedVms><activeVseHaIndex>0</activeVseHaIndex><vmMoidOfActiveVse>vm-63</vmMoidOfActiveVse><vmNameOfActiveVse>vCNS-Edge-Tenant2-0</vmNameOfActiveVse><hostMoidOfActiveVse>host-39</hostMoidOfActiveVse <hostNameOfActiveVse>10.129.139.8</hostNameOfActiveVse><resourcePoolMoidOfActiveVse>resgroup-22</resourcePoolMoidOfActiveVse><resourcePoolNameOfActiveVse>Resources</resourcePoolNameOfActiveVse><dataStoreMoidOfActiveVse>datastore-40</dataStoreMoidOfActiveVse><dataStoreNameOfActiveVse>datastore1(3)</dataStoreNameOfActiveVse><statusFromVseUpdatedOn>1351609519000</statusFromVseUpdatedOn></appliancesSummary></edgeSummary></edgePage></pagedEdgeList>

WOW, I hear you say! How in earth can I read and interpret this? To help make this more readable perform the following:

1.  Re-direct the output of the REST API query to a file:

$ curl -i -k -H “content-type: application/xml” -H “host: <vCNS-Manager
-IP-Address>” -H “Authorization: Basic YWRtaW46ZGVmYXVsdA==” -X GET
https://<vCNS-Manager-IP-Address>/api/3.0/edges/edge-5 > edge-xml.xml

2. Remove the Cntrl M characters if they exist. If you use vi then perform the following. Note: ^v is a CONTROL-V character and ^m is a CONTROL-M:

$ vi edge-xml.xml
$ %s/^M//g
$ Save the NEW file to edge-xml-converted.xml

3. Edit the file edge-xml-converted.xml and remove all lines before and including <?xml version=”1.0″ encoding=”UTF-8″?>

4. Now, you should be able to view the contents of the edge xml file with some legability:

$ xmllint -format edge-xml-converted.xml

<?xml version="1.0"?>
<edge>
   <id>edge-5</id>
   <version>17</version>
   <status>deployed</status>
   <datacenterMoid>datacenter-2</datacenterMoid>
   <datacenterName>Cloud Datacenter</datacenterName>
   <name>vCNS-Edge-Tenant1</name>
   <fqdn>vShield-edge-5</fqdn>
   <enableAesni>true</enableAesni>
   <enableFips>false</enableFips>
   <enableTcpLoose>false</enableTcpLoose>
   <vseLogLevel>info</vseLogLevel>
   <vnics>
     <vnic>
       <index>0</index>
       <name>External</name>
       <type>uplink</type>
       <portgroupId>dvportgroup-26</portgroupId>
       <portgroupName>vSE-External</portgroupName>
       <addressGroups>
         <addressGroup>
           <primaryAddress>10.129.139.5</primaryAddress>
           <subnetMask>255.255.255.0</subnetMask>
         </addressGroup>
       </addressGroups>
       <mtu>1500</mtu>
       <enableProxyArp>false</enableProxyArp>
       <enableSendRedirects>false</enableSendRedirects>
       <isConnected>true</isConnected>
     </vnic>
     <vnic>
       <index>1</index>
       <name>Internal-Tenant-1</name>
       <type>internal</type>
       <portgroupId>dvportgroup-18</portgroupId>
       <portgroupName>Tenant-1</portgroupName>
       <addressGroups>
         <addressGroup>
           <primaryAddress>172.16.0.1</primaryAddress>
           <subnetMask>255.255.0.0</subnetMask>
         </addressGroup>
       </addressGroups>
       <mtu>1500</mtu>
       <enableProxyArp>false</enableProxyArp>
       <enableSendRedirects>false</enableSendRedirects>
       <isConnected>true</isConnected>
     </vnic>
     <vnic>
       <index>2</index>
       <name>vnic2</name>
       <type>internal</type>
       <addressGroups/>
       <mtu>1500</mtu>
       <enableProxyArp>false</enableProxyArp>
       <enableSendRedirects>true</enableSendRedirects>
       <isConnected>false</isConnected>
     </vnic>
     <vnic>
       <index>3</index>
       <name>vnic3</name>
       <type>internal</type>
       <addressGroups/>
       <mtu>1500</mtu>
       <enableProxyArp>false</enableProxyArp>
       <enableSendRedirects>true</enableSendRedirects>
       <isConnected>false</isConnected>
     </vnic>
     <vnic>
       <index>4</index>
       <name>vnic4</name>
       <type>internal</type>
       <addressGroups/>
       <mtu>1500</mtu>
       <enableProxyArp>false</enableProxyArp>
       <enableSendRedirects>true</enableSendRedirects>
       <isConnected>false</isConnected>
     </vnic>
     <vnic>
       <index>5</index>
       <name>vnic5</name>
       <type>internal</type>
       <addressGroups/>
       <mtu>1500</mtu>
       <enableProxyArp>false</enableProxyArp>
       <enableSendRedirects>true</enableSendRedirects>
       <isConnected>false</isConnected>
     </vnic>
     <vnic>
       <index>6</index>
       <name>vnic6</name>
       <type>internal</type>
       <addressGroups/>
       <mtu>1500</mtu>
       <enableProxyArp>false</enableProxyArp>
       <enableSendRedirects>true</enableSendRedirects>
       <isConnected>false</isConnected>
     </vnic>
     <vnic>
       <index>7</index>
       <name>vnic7</name>
       <type>internal</type>
       <addressGroups/>
       <mtu>1500</mtu>
       <enableProxyArp>false</enableProxyArp>
       <enableSendRedirects>true</enableSendRedirects>
       <isConnected>false</isConnected>
     </vnic>
     <vnic>
       <index>8</index>
       <name>vnic8</name>
       <type>internal</type>
       <addressGroups/>
       <mtu>1500</mtu>
       <enableProxyArp>false</enableProxyArp>
       <enableSendRedirects>true</enableSendRedirects>
       <isConnected>false</isConnected>
     </vnic>
     <vnic>
       <index>9</index>
       <name>vnic9</name>
       <type>internal</type>
       <addressGroups/>
       <mtu>1500</mtu>
       <enableProxyArp>false</enableProxyArp>
       <enableSendRedirects>true</enableSendRedirects>
       <isConnected>false</isConnected>
     </vnic>
   </vnics>
   <appliances>
     <applianceSize>compact</applianceSize>
     <appliance>
       <highAvailabilityIndex>0</highAvailabilityIndex>
       <vcUuid>421c8d1d-aed4-1003-8c46-282ff75f94c9</vcUuid>
       <vmId>vm-64</vmId>
       <resourcePoolId>resgroup-20</resourcePoolId>
       <resourcePoolName>Resources</resourcePoolName>
       <datastoreId>datastore-38</datastoreId>
       <datastoreName>datastore1 (2)</datastoreName>
       <hostId>host-37</hostId>
       <hostName>10.129.139.7</hostName>
       <vmFolderId>group-v3</vmFolderId>
       <vmFolderName>vm</vmFolderName>
       <vmHostname>vShield-edge-5-0</vmHostname>
       <vmName>vCNS-Edge-Tenant1-0</vmName>
       <deployed>true</deployed>
       <edgeId>edge-5</edgeId>
     </appliance>
   </appliances>
   <cliSettings>
     <remoteAccess>true</remoteAccess>
     <userName>admin</userName>
   </cliSettings>
   <features>
     <featureConfig/>
     <firewall>
       <version>3</version>
       <enabled>true</enabled>
       <defaultPolicy>
         <action>accept</action>
         <loggingEnabled>false</loggingEnabled>
       </defaultPolicy>
       <firewallRules>
         <firewallRule>
           <id>131074</id>
           <ruleTag>131074</ruleTag>
           <name>firewall</name>
           <ruleType>internal_high</ruleType>
           <source>
             <vnicGroupId>vse</vnicGroupId>
           </source>
           <action>accept</action>
           <enabled>true</enabled>
           <loggingEnabled>false</loggingEnabled>
           <description>firewall</description>
         </firewallRule>
         <firewallRule>
           <id>131073</id>
           <ruleTag>131073</ruleTag>
           <name>default rule for ingress traffic</name>
           <ruleType>default_policy</ruleType>
           <action>accept</action>
           <enabled>true</enabled>
           <loggingEnabled>false</loggingEnabled>
           <description>default rule for ingress traffic</description>
         </firewallRule>
       </firewallRules>
     </firewall>
     <dns>
       <version>0</version>
       <enabled>false</enabled>
       <cacheSize>16</cacheSize>
       <listeners>
         <ipAddress>any</ipAddress>
       </listeners>
       <logging>
         <enable>false</enable>
         <logLevel>info</logLevel>
       </logging>
     </dns>
     <sslvpnConfig>
       <version>0</version>
       <enabled>false</enabled>
       <logging>
         <enable>false</enable>
         <logLevel>info</logLevel>
       </logging>
       <advancedConfig>
         <enableCompression>false</enableCompression>
         <forceVirtualKeyboard>false</forceVirtualKeyboard>
         <randomizeVirtualkeys>false</randomizeVirtualkeys>
         <preventMultipleLogon>false</preventMultipleLogon>
         <clientNotification/>
         <enablePublicUrlAccess>false</enablePublicUrlAccess>
         <timeout>
           <forcedTimeout>0</forcedTimeout>
           <sessionIdleTimeout>10</sessionIdleTimeout>
         </timeout>
       </advancedConfig>
       <clientConfiguration>
         <autoReconnect>true</autoReconnect>
         <upgradeNotification>false</upgradeNotification>
       </clientConfiguration>
       <layoutConfiguration>
         <portalTitle>VMware</portalTitle>
         <companyName>VMware</companyName>
         <logoExtention>jpg</logoExtention>

<logoUri>/3.0/edges/edge-1/sslvpn/config/layout/images/portallogo</logoUri>
         <logoBackgroundColor>FFFFFF</logoBackgroundColor>
         <titleColor>996600</titleColor>
         <topFrameColor>000000</topFrameColor>
         <menuBarColor>999999</menuBarColor>
         <rowAlternativeColor>FFFFFF</rowAlternativeColor>
         <bodyColor>FFFFFF</bodyColor>
         <rowColor>F5F5F5</rowColor>
       </layoutConfiguration>
       <authenticationConfiguration>
         <passwordAuthentication>
           <authenticationTimeout>1</authenticationTimeout>
           <primaryAuthServers/>
           <secondaryAuthServer/>
         </passwordAuthentication>
       </authenticationConfiguration>
     </sslvpnConfig>
     <staticRouting>
       <version>7</version>
       <enabled>true</enabled>
       <defaultRoute>
         <vnic>0</vnic>
         <gatewayAddress>10.129.139.253</gatewayAddress>
         <mtu>1600</mtu>
       </defaultRoute>
       <staticRoutes/>
     </staticRouting>
     <highAvailability>
       <version>2</version>
       <enabled>false</enabled>
       <vnic>any</vnic>
       <declareDeadTime>6</declareDeadTime>
       <logging>
         <enable>false</enable>
         <logLevel>info</logLevel>
       </logging>
     </highAvailability>
     <syslog>
       <version>0</version>
       <enabled>true</enabled>
     </syslog>
     <featureConfig/>
     <loadBalancer>
       <version>0</version>
       <enabled>false</enabled>
       <accelerationEnabled>false</accelerationEnabled>
     </loadBalancer>
     <ipsec>
       <version>0</version>
       <enabled>false</enabled>
       <logging>
         <enable>false</enable>
         <logLevel>info</logLevel>
       </logging>
       <sites/>
       <global>
         <caCertificates/>
         <crlCertificates/>
       </global>
     </ipsec>
     <dhcp>
       <version>0</version>
       <enabled>false</enabled>
       <staticBindings/>
       <ipPools/>
       <logging>
         <enable>false</enable>
         <logLevel>info</logLevel>
       </logging>
     </dhcp>
     <nat>
       <version>4</version>
       <enabled>true</enabled>
       <natRules/>
     </nat>
     <featureConfig/>
   </features>
   <autoConfiguration>
     <enabled>true</enabled>
     <rulePriority>high</rulePriority>
   </autoConfiguration>
</edge>

There is a great deal more to using the vCloud Networking and Security REST API, but I hope this has given you a little insight into how you can use it more effectively.