I just learned from engineering neat trick related to how cell management tool can be invoked without specifying administrator credentials.

The issue is that currently you cannot use LDAP account to trigger cell management tool commands which are mostly used for quiescing and shutting down cells for maintenance. Using vCloud Director local administrator account is discouraged as it poses a security issue. However what is possible is to trigger the cell management tool as root (or with sudo) and supply via hidden flag -i the process ID of the java process.

Here is an example:

First I query the java PID with ps aux command. Then I use the standard cell-management-tool command without specifying the user with the -i flag at the end.

So you can force the administrator to log in to the cell guest OS via a LDAP account and then run the command with sudo.

Thank you Zachary Shepherd for the tip.

Offline Data Transfer (ODT) is a feature of vCloud Connector that allows migration of VMs from customer own datacenter to vCloud Air with NAS appliance which is shipped via regular mail. The point is to avoid slow wide area network connectivity and leverage awesome bandwidth but slow latency of sneakernet.

Have you ever wondered why it is supported only with vCloud Air and not with any public or private cloud based on vCloud Director? Well I am going to lay down the whole process here in this blog post so nothing is stopping anyone testing this feature on your own.

Let me first paste picture from the manual which describes in high level how the process works:

vCloud Connector (vCC) is leveraged to manage the whole process. The customer (on left) deploys his own vCloud Connector Server and Node which he attaches to his on premises infrastructure (vSphere based). He then requests the ODT service. The provider will deploy ODT node in the public cloud (on right) and also its own vCC Server to manage it. Regular NAS appliance is prepared – its only purpose is to provide storage capacity which is fast and reliable enough via NFS protocol and can be easily packaged and shipped.

Customer mounts it to his vCC Node (to a directory via NFS mount). Both the ODT and vCC Nodes are registered in his vCC Server. Then via the traditional vSphere Client and vCC Plugin only the local vSphere environment (here it differs from the traditional vCC transfer).

The actual export is done by selecting the objects to export (templates, vApps or VMs) and clicking the small Offline Data Transfer icon: Mount path is entered and links and credentials to the target Cloud and ODT node. There is also option to select if a particular VM should be deployed and connected to a network. These steps above are all described in the manual here.

But what about the provider side of the whole process?

ODT Node

ODT Node is actually regular vCloud Connector Node tweaked by running configureSneakernetNode.sh script which can be found in /opt/vmware/hcagent/scripts folder on the Node VM itself.

The ODT needs to have network access to the vCenter Server (and ESXi hosts) of the target vCloud VDC environment.

Import

The actual import is done via provider vCloud Connector server which is again the regular vCloud Connector server with no tweaks this time. The ODT Node is registered there which enables import menu in the vCC plugin GUi in vSphere Client. The shipped NAS appliance must be mounted to the ODT Node and the ODT URL and mount path is entered in the Import Wizzard. The actual physical connection of the NAS appliance can be done using dedicated VLAN with point to point connection of the second ODT network interface.

Next we need to pick the target vCenter Server and a credentials for it. ODT Node will import offline VMs which are stored as encrypted OVFs on the NAS appliance into the target vCenter Server. To do that it needs a big enough datastore and a dummy network in order to connect the imported VMs temporarily to it. Once that is done VMs are imported by vCloud Director to the target VDCs, catalogs and networks. The provider needs to have big enough datastore and create dummy standard switch port group on every host with name ‘VM Network’. This network does not need to have external access.

As you can see contrary to the regular internet vCloud Connector transfer where the VM is transfer from the original environment via on-prem node to public node to vCloud Director (through its API and transfer storage – see here for more detail) the transfer does not go through the vCloud Director cells and its transfer storage at all. This is possible thanks to handling the final step of the process by the provider himself (he has vCenter Server access) and makes also the transfer faster (potentially one less step). On the other hand this brings some security and operational process challenges (physical access to management network, vCenter credentials) which must be properly addressed.

One of my customers had deployed true hybrid vRealize Automation with multiple cloud endpoints: vCloud Air and internal vCloud Director and AWS. I was called in to troubleshoot strange issue where sometimes deployment of a cloud multimachine blueprint (vApp) would work but most often it would fail with the following message:

VCloud Clone VM failed for machine: XXX100 [Workflow Instance Id=19026]
System.InvalidOperationException: Error occurred while getting vApp template with ID: urn:vcloud:vapptemplate:a21de50d-8b5e-41a6-81d1-acfd8ab8364b
…
INNER EXCEPTION: com.vmware.vcloud.sdk.utility.VCloudException: [ 8ae6fbca-e0d2-43e7-bc94-5bc9d776bf8d ] No access to entity “com.vmware.vcloud.entity.vapptemplate:a21de50d-8b5e-41a6-81d1-acfd8ab8364b”

Endpoint was properly configured, template existed, so what could be wrong? Why were we denied the access to the template?

It turns out that by design vRealize Automation does not match a template to a particular endpoint. It identifies it just by name. So in our case sometimes it would try to deploy the blueprint to wrong endpoint where the template of the particular name did not exist.

The fix is simple:

• Define reservation policies which would identify each endpoint.
• Assign them to the proper reservations
• Assign reservation policies to the Cloud vApp blueprint. This way there will never be confusion from which template to provision to which endpoint.

A customer asked me how to track deployments of certain catalog templates. This is mainly for licensing or charging purposes where the provider creates and maintains (patches) OS templates which the tenants can consume via deployment from public catalog.

There are multiple ways how to achieve this. One involves tracking the deployment tasks from the catalog via Audit Event logs or RabbitMQ blocking tasks. The other I find very elegant is leveraging vCloud metadata which can be assigned to many vCloud Director objects. The actual feature has been present in vCloud Director for a long time (1.5) but is has had a few improvements since.

The owner of an object can create, update and delete up to 1024 name=value pairs on each particular object. An additional group of name=value pairs is under control of the system administrator who can chose visibility of such pair: hidden, read only or read/write. The metadata can be accessed both via GUI and API.

So back to our use case:

1. As System Administrator create hidden metadata entry on the catalog VM. For example: “LicensingID = AAABBB“. This must be done before adding the VM to the public catalog.
2. From now on every deployed VM from this catalog template will have this hidden metadata. The tenant user will not see it, however system admin will:

   Tenant View

   
   

   Admin View

3. Querying all VMs which contain this metadata can be done with one API call
   GET https://vcloud.fojta.com/api/query?type=adminVM&filter=(metadata@SYSTEM:LicensingID==STRING:AAABBB)

   API Response

   The response contains Org ID (highlighted in yellow) which can be used for cost allocation to each tenant.

Quick PowerCLI one-liner which displays all VMs running in vCloud Director together with their VM Tools version.

Get-CIVM |Select Name, {$_.Org.Name}, {$_.OrgVdc.Name}, {$_.ExtensionData.Section.VMWareTools.Version}

I see more and more that new and existing vCloud Director deployments leverage NSX as the networking component instead of the legacy vShield / vCloud Network and Security (vCNS). The main reasons are the announced end-of-life for vCNS and the additional features that NSX brings to the table (although most of them are not yet tenant consumable in vCloud Director – as of version 5.6.4).

When deploying NSX with vCloud Director what new considerations should be included when designing the architecture? In this post I want to concentrate on the concept of the Edge Cluster.

What is Edge Cluster?

VMware has published very good NSX-V Network Virtualization Design Guide. This is very detailed document describing all NSX concepts as well as how they should be properly architected. The concept of Edge Cluster is discussed in quite a detail as well so let me just summarize here.

NSX overlay networks allow the creation of logical networks over an existing IP network fabric. This enables highly scalable network design using Leaf / Spine architecture where the boundary between L2 and L3 networks is at the rack level (leafs) and all communication between racks is L3 only going through a set of spine routers.

NSX spans logical network across all racks however in the end we need to connect virtual workloads from the logical networks to the outside physical world (WAN, Internet, colocated physical servers, etc.). These networks are represented by a set of VLAN networks and because we are not stretching L2 across the racks we cannot trunk them everywhere – so they are connected only to one (or two for redundancy) rack which thus become the Edge Cluster.

So the purpose of the Edge Cluster is to host virtual routers – Edge Service Gateways that provide the connectivity between the physical world (VLANs) and virtual world (VXLAN logical switchites). Note that it does not mean that every Edge Gateway needs to be deployed there. If an Edge Gateway provides connectivity between two VXLAN logical switches – it can be deployed anywhere as logical switches span all clusters.

vCloud Director Edges

vCloud Director deploys Edge VMs in order to provide Organization VDC or vApp connectivity. The actual deployment is done through vCNS or NSX Manager but it is vCloud Director who makes decision about placement and configuration of the Edges. vCloud Director Edge Gateway provides connectivity between one or more vCloud Director External Network and one or more Organization VDC Network. It is deployed inside Provider VDC in a special System VDC Resource Pool on a datastore belonging to the Org VDC default storage policy. vCloud Director placement engine selects the most appropriate cluster where the Edge Gateway VM will be deployed – based on which clusters belong to Provider VDC, what is their available capacity and most importantly their access to the right storage and external networks.

vApp Edges provide connectivity between an Organization VDC network and a vApp network. They always have only one external and one internal interface. They are also deployed by vCloud Director to the Provider VDC System VDC Resource Pool and exist only when the vApp is in deployed mode (Powered On).

Transport Zone

Transport Zone defines the scope of a VXLAN logical switch. It consists of one or more vSphere clusters. Transport Zone can be created manually, however vCloud Director automatically creates for each Provider VDC one Transport Zone which matches the clusters that are added to the Provider VDC and associates it with a VXLAN Network Pool. When Organization VDC is created by vCloud System Administrator a Network Pool must be assigned – all Organization VDC and vApp Networks will then have its scope.

Design Option I – Traditional

In the traditional network architecture Access/Aggregation/Core the L2/L3 boundary is at the aggregation switches. This means all racks connected to the same set of aggregation switches have access to the same VLANs and thus there is no need for an Edge Cluster as the Edge connecting VLAN with VXLAN based networks can run on any given rack. In vCloud Director it means that as long as the external networks (VLANs) are trunked to aggregation switches we do not need to worry about Edge placement. The set of racks (clusters) connected to the same aggregation domain usually map to a vCloud Director Provider VDC. The transport zone is then identical to the aggregation domain.

Traditional Access/Aggregation/Core architecture

The drawback of such design is that Provider VDCs cannot span multiple aggregation domains.

Design Option II – Combined Edge/Compute Cluster

In case spine/leaf network architecture is used, VLANs backing vCloud Director external networks are trunked only to one cluster. In this design option we will call it Edge/Compute Cluster. As explained above vCloud Director placement engine will deploy Edge VMs to a cluster based on VLAN connectivity – therefore it will automatically place all Edge Gateways into the Edge/Compute cluster as this is the only cluster where the external connectivity (VLANs) exists. vCloud Director will however also opportunistically place regular tenant VMs into this cluster (hence its name Edge/Compute).

Spine/leaf with Edge/Compute Cluster

This design option has all the scale advantages of Spine/Leaf architecture however the possibility of tenant workloads taking limited space of Edge/Compute cluster is the drawback. There are two potential options how to remediate this:

1. vCloud Director Edge Gateways are always deployed by vCloud System Administrator. He/she could make sure that prior Edge Gateway deployment there is enough capacity in the Edge/Compute cluster. If not some tenant workloads can be migrated away to another cluster – this must be done from within vCloud Director (Resource Pool / Migrate to option). Live migration is however possible only if the Edge/Compute Cluster shares the same VXLAN prepared vSphere Distributed Switch (vDS) with the other clusters and this requires at least four network uplinks on the Edge/Compute Cluster hosts (two uplinks for vDS with external VLANs and two uplinks for VXLAN vDS).
2. Artificially limit the size of Edge/Compute Cluster so the placement engine does not choose it for regular tenant workloads. This can be done by leveraging Resource Pool which is created manually in the Edge/Compute cluster and attached to the Provider VDC instead of the whole cluster. Then an artificial limit is set by System Administrator and is increased only when a new Edge Gateway needs to be deployed.

Both options unfortunately provide significant operational overhead.

Design Option IIb – Combined Edge/Compute Cluster with Non-elastic VDC

While elastic Org VDC types (such are Pay-As-You-Go or Allocation type) can span multiple clusters what would be the impact of non-elastic VDC such as Reservation Pool in this design option?

In non-elastic Org VDC all tenant workloads are deployed into the primary Provider VDC resource pool. However Edge VMs can be deployed into secondary resource pools. This means as long as the Edge/Compute cluster is added as secondary Resource Pool into a Provider VDC this design option can still be used.

Spine/leaf with Edge/Compute Clsuter and non-elastic VDC

Design Option III – Dedicated Edge Cluster

This design option extends the previous one but in this case we will have dedicated Edge Cluster which is not managed by vCloud Director at all. We will also introduce new Edge Gateway type – Provider Edges. These are manually deployed by the service provider totally outside of vCloud Director into the Edge Cluster. Their external uplinks are connected to external VLAN based networks and internal interfaces are connected to transit VXLAN Logical Switch spanning all Compute and the Edge clusters (manually created transport zone with all clusters). The transit network(s) are then consumed by vCloud Director as External Network – note that little workaround is need to do so – read here.

The Provider Edges can provide all NSX functionality (dynamic routing protocols on external uplinks, L2 bridging, L2 VPN, etc.). They can scale as additional vCloud Director External Networks are added (current maximum in VCD 5.6 is 750 External Networks). The Edges deployed by vCloud Director then go into compute clusters as all their interfaces connect to VXLAN logical switches spanned everywhere in the Provider VDC.

Spine/leaf with Dedicated Edge Cluster

Read vCloud Director with NSX: Edge Cluster (Part 2) here.

In my previous article vCloud Director with NSX: Edge Cluster I described various design options of NSX Edge Cluster in vCloud Director environment. In this article I would like to discuss additional option which extends the Design Option III – Dedicated Edge Cluster. Below is the picture showing the scenario from the previous post.

Spine/leaf with Dedicated Edge Cluster

There is one Provider deployed Edge in the Edge Cluster for each Transit vCloud Director External network to which Org VDC Edge Gateways are connected to. The option works quite well for use cases where the Provider Edge is dedicated to single tenant – e.g. it is providing VPN services or L2 bridging. (Note that in L2 bridging use case the Org VDC Edge Gateway is not deployed and Org VDC networks connect directly to tenant dedicated external network).

However when we want to provide access to a shared service (for example internet) where we will deploy multiple Org VDC Edge Gateways of different tenants connected to the same external network they will all have to go through a single Provider Edge which can become a bottleneck.

As of NSX version 6.1 Edge Gateways can however be deployed in ECMP (Equal Cost Multi-Path) configuration where we can aggregate bandwidth of up to 8 Edges (8x10GB = 80 GB througput). High availability of ECMP Edges is then achieved with dynamic routing protocol (BGP or OSPF) with aggressive timing for short failover times (3 seconds) which will quickly remove failed path from the routing tables.

The problem is that (as of vCloud Director 5.6) Organization VDC Edges are deployed in the legacy (vShield/vCNS) mode and do not support ECMP routing nor dynamic routing protocols. The design I propose will get around this limitation by deploying Distributed Logical Router between Provider and Organization VDC Edges.

Spine/leaf with Dedicated Edge Cluster and ECMP Edges

The picture above shows two Provider ECMP Edges (can scale up to 8) with two physical VLAN connections each to upstream physical router and one internal interface to the Transit Edge logical switch. Distributed Logical Router (DLR) then connects the Transit Edge logical switch with the Transit vCloud Director External Network to which all tenant Org VDC Edge Gateways are connected to. The DLR has ECMP routing enabled as well as OSPF or BGP dynamic routing peering with the Provider Edges. The DLR will provide two (or more) equal paths to upstream Provider Edges and will choose one based on hashing algorithm of source and destination IP of the routed packet.

The two shown Org VDC Edge Gateways (which can belong to two different tenants) then will take advantage of all the bandwidth provided by the Edge Cluster (indicated with the orange arrows).

The picture also depicts the DLR Control VM. This is the protocol endpoint which peers with Provider Edges and learns and announces routes. These are then distributed to ESXi host vmkernel routing process by the NSX Controller Cluster (not shown in the picture). The failure of DLR Control VM has impact on routing information learned via OSPF/BGP protocol even if DLR is highly available in active standby configuration due to the protocol aggressive timers (DLR control VM failover takes more than 3 seconds). Therefore we will create static route on all ECMP Provider Edges for the Transit vCloud Director External network subnet. That is enough for north – south routing as Org VDC subnets are always NATed by the tenant Org VDC Edge Gateway. South – north routing is static as the Org VDC Edge Gateways are configured with default gateway defined in the External Network properties.

The other consideration is placement of DLR Control VM. If it fails together with one of ECMP Provider Edges the ESXi host vmkernel routes are not updated until DLR Control VM functionality  fails over to the passive instance and meanwhile route to the dead Provider Edge is black holing traffic. If we have enough hosts in the Edge Cluster we should deploy DLR Control VMs with anti-affinity to all ECMP Edges. Most likely we will not have enough hosts therefore we would deployed DLR Control VMs to one of the compute clusters. The VMs are very small (512 MB, 1 vCPU) therefore the cluster capacity impact is negligible

My colleague George Kobar recently wrote blog post about running Nested ESXi on vCloud Air. The gist of the article is the description how to solve networking issues around nested virtualization that usually result in the need to have promiscuous mode enabled on the virtual distributed switch which is not possible to do in public cloud environment. The trick is to use nested vMACs identical to those assigned by vCloud Air to virtual ESXi hosts.

I had the opportunity to test the practical viability of the approach when I needed to test quite complex architecture which involved NSX, multiple vSphere 6 racks with spine and leaf network architecture and vCloud Director version 8 (currently in public beta). If you read my previous article about vCloud Director and NSX you will recognize the topology.

I have 3 racks each with two ESXi hosts running in different subnets and all communication between racks is routed over the spine router. For nested storage I am using HP VSA which provides iSCSI storage and then there are some management components (Domain Controller, Windows based vCenter Server with MS SQL database, NSX Manager and vCloud Director cell). On the virtual ESXi hosts are running nested VMs – NSX Controller, Edge Gateways, DLR control VM and some linux test VMs.

Here is how I set the whole nested lab:

• One vCloud Air Edge Gateway is simulating the spine router. It has 8 7 Org VDC networks attached. For each rack there is ESXi management network (used for ESXi management, vMotion and iSCSI traffic) and transport network used for VXLAN fabric. Then there is one management network for management workloads and one for Internet access which is also routed to Internet to allow out of band RDP access to vCenter Server which acts as jump host so I do not need to use vCloud Air console.
• Another vCloud Air Edge Gateway is used to simulate WAN router with external access for virtual workloads with Internet Org VDC network. As my vCloud Air VDC is in Advanced Networking Services beta I could even leverage OSPF peering between the Edge and my nested Edges.
• Edge rack virtual ESXi hosts have plenty of NICs in order to have enough vMACs that can be used by nested objects (VMkernel ports and VMs). I used the following strategy:
  • One NIC is used for ESXi management. ESXi uses the ‘physical’ MAC address for vmk0 so no worries and management/vMotion and iSCSI networking works out of the box (and if not check this KB). Standard Switch is used.
  • Second NIC is used for VXLAN VTEP. When you prepare VXLAN fabric on nested hosts random MACs are assigned to VTEP vmk1. These need to be changed after the preparation so they are identical to MACs assigned to virtual ESXi hosts. This is done by editing /etc/vmware/esx.conf on each host and rebooting. Do VXLAN pings to check if your fabric is set up properly. Any VM connected to VXLAN network will have its traffic encapsulated by VTEPs and thus properly work in the nested environment.
  • ECMP Edges have uplink interface connected to VLAN network. I used the 3rd ESXi NIC on each Edge Rack host for one Edge. When you deploy the Edge via NSX Manager you specify the corresponding MAC of the virtual ESXi host. As the Edge cannot be vMotioned (its MAC wouldn’t match ESXi host MAC) I deployed it to local storage of the virtual ESXi host and the VLAN was presented on local standard switch. BTW tying ECMP Edges to particular host is recommended practice anyway.
  • The last challenge is the deployment of the NSX Controller (I deployed only one which is enough for testing needs). The NSX Controller needs to be deployed to regular non-VXLAN portgroup and it is not possible to set its MAC address as it is deployed by NSX Manager in automated fashion. So I deployed another Edge (called Controller router) on one of the Edge rack ESXi hosts again with uplink MAC set to MAC of the 4th NIC of the ESXi host. Then I created portgroup for the NSX Controller deployment and deployed the Controller. As long as the NSX Controller VM is on the same host as the Controller router (both deployed to local storage) the connectivity is local and then routed to the outside world with the Controller VM MAC.
  • EDIT 9/23/2015 Do not forget to add custom static route on the spine router (vCA Edge Gateway) to the NSX Controller subnet via its nested Controller router.

Here are some screenshots showing different views of the nested lab:

vCloud Air vApp View

Nested vCenter View

Nested Networking View

Once the base of the nested lab is set up it can be used for many different things – vCloud Director or vRealize Automation testing or testing upgrades (I personally upgraded the lab from vSphere 5.5 to 6).

When VMware NSX 6.0 came out about more than one year ago, one of the new great features it had on top of the its predecessor VMware vCloud Network and Security (vCNS) was L2VPN service on Edge Service Gateway which allows stretching layer 2 network segments between distant sites in different management domains. NSX 6.1 further enhanced the functionality by introducing Standalone Edge which can be deployed on top of vSphere without an NSX license and acts as L2VPN client.

Many vCloud Service Providers are now deploying their public cloud with vCloud Director and NSX instead of vCNS so I am often asked how could they leverage NSX in order to provide L2VPN service to their tenants.

As of today neither vCloud Director 5.6 nor 8.0 (in beta at the moment) can deploy NSX Edges and manage the L2VPN service. However it is still possible for the SP to provide L2VPN as a managed service for his tenants.

Let me demonstrate how would it work on the following artificial example.

The customer has an application that resides on 3 different VLAN based networks (subnet A, B and C) routed with existing physical router. He would like to extend subnets A and B into the cloud and deploy VMs there. The VMs in the cloud should access the internet in order to connect to external SaaS services through the provider connection (egress optimization) but should still be able to reach database running on subnet C which is hosted on premises.

The diagram below shows the whole architecture (click for larger version):

On the left is the customer on premises datacenter with physical router and three VLAN based networks. On the right is the public cloud with NSX design I proposed in one of my previous blog articles. While the unimportant parts are grayed out what is important is how the customer Org VDC and the NSX Edge Gateways is deployed.

• The provider deploys tenant dedicated NSX Edge Service Gateway outside of vCloud Director manually and configures it based on customer requirements. The provider creates two logical switches (VXLAN 5005 and 5006) which will be used for extending customer subnets A and B. The switches are trunked to the NSX Edge and the Edge interface IP addresses are assigned identical to the IP addresses of the physical router on-premises (a.a.a.1 and b.b.b.1).
• The two logical switches are configured in vCloud Director as External Networks with the proper subnets A and B and pool of unused IPs.
• Two Org VDC networks are created inside tenant’s Org VDC as directly connected to the two External Networks.
• L2VPN server is configured on the NSX Edge (with encryption algorithm, secret, certificate and stretched interfaces). Also Egress Optimization Gateway Address is configured (both physical gateway IPs are entered – a.a.a.1 and b.b.b.1). This will filter ARP replies of the two gateways sharing the same IPs in the tunnel and allow NSX Edge to act as the gateway to the internet.
• The tenant will install Standalone Edge which is distributed as OVF inside his datacenter and set it up: he must map VLANs to tunnel IDs supplied by the provider, configure Edge Server public IP and port and encryption details.

Now what about the subnet C? How can VMs deployed in the cloud get to it if the physical router is unreachable due to the enabled egress optimization? Following trick is used:

• Another subnet z.z.z.0/30 is used for P2P connection between the NSX Edge in the cloud and the physical router.
• IP address z.z.z.1/30 is configured on the physical router on one of the stretched subnets (e.g. A).
• The second IP z.z.z.2/30 is configured on the NSX Edge on the same subnet.
• Finally static route is created on the NSX Edge pointing subnet C to the next hop address z.z.z.1.

Some additional considerations:

• In case the tenant has licensed NSX on-premises he can obviously use ‘full’ NSX Edge Service Gateway. The advantages are that it is much easier to deploy and configure. It can also stretch VXLAN based networks as opposed to only VLANs which are supported by Standalone Edge.
• Standalone Edge can be connected either to Standard Switch or Distributed Switch. When Standard Switch is used promiscuous mode and forged transmits must be enabled on the trunk port group. VLANs ID 4095 (all) must be configured to pass multiple VLANs.
• When Distributed Switch is used it is recommended to use Sink Port instead of promiscuous mode. Sink Port receives traffic with MAC addresses unknown to vDS.
• Sink Port creation is described here. It requires vDS edit via vCenter Managed Object UI. While Sink Port can be also created with net-dvs –EnableSink command directly on the ESXi host with Standalone Edge VM running it is not recommended as the host configuration can be overridden by vCenter Server.
• RC4-MD4 encryption cipher should not be used as it is insecure and has been deprecated in NSX 6.2.

One of the reasons I have been quiet on my blog lately was today released for public: vCloud Architecture Toolkit for Service Providers.

If you are designing vCloud Director based public cloud I hope you will find design considerations and recommendation included helpful. Let me highlight a few in my opinion interesting topics from the Architecting a VMware vCloud Director Solution document:

• Virtual Machine metric Cassandra database
• RabbitMQ messaging infrastructure
• Considerations around NSX Edge Cluster and NSX Controllers
• Consumption of NSX services
• VSAN impact on vCloud Director catalogs
• OAuth authentication

While vCloud Director offers impressive scalability with possibility to manage up to 20 vCenter Servers there are valid reasons why service providers deploy multiple vCloud Director instances due to fault domains (availability zones) or latency (multiple geographical regions) requirements.

In such case a single tenant (end-customer) has multiple organization accounts in multiple vCloud Director instance each with access to subset of VDCs, catalogs, VMs, etc. The service provider would usually hide this under one custom overarching portal however when the tenant wants to discover and manage his resources in programmable fashion he has to access multiple vCloud API endpoints of the vCloud Director instances.

vCloud Director version 8.0 offers a new feature: Organization Associations. If you search through vCloud API v 9.0 you will see new Admin Types:  OrgAssociationType  and OrgAssociationsType and related new Admin Element OrgAssociationMember. So what it is and how does it work?

The service provider can associate multiple Organizations (belonging to the same customer) together and simplify discovery of all cloud resources through single API endpoint.

Example

In my lab I have two different vCloud Director instances with URLs vcloud.fojta.com and vcloud2.fojta.com. In the first instance I have created two organizations belonging to the same customer: ACME and ACME2. In the second instance I have created organization ACME. All three organizations use the same identity source (in my case LDAP) and the same user exists in all of them with Organization Administrator credentials.

1. The system administrator creates the organization associations. In this example I have associated org: ACME in the second instance with ACME and ACME2 in the first instance. This is done with the following vCloud API call:

   PUT https://vcloud2.fojta.com/api/admin/org/ca5295f0-a521-4d4c-8b2e-322f154fbbea/associations
   Content-Type: application/vnd.vmware.admin.organizationAssociations+xml
   
   Body:
   <?xml version="1.0" encoding="UTF-8"?>
   <OrgAssociations xmlns="http://www.vmware.com/vcloud/v1.5">
       <OrgAssociationMember href="https://vcloud2.fojta.com/api/admin/org/ca5295f0-a521-4d4c-8b2e-322f154fbbea/associations/02b433db-0b37-4304-b07b-0717255ec297" type="application/vnd.vmware.admin.organizationAssociation+xml">
           <MemberUrl>https://vcloud.fojta.com/api/org/02b433db-0b37-4304-b07b-0717255ec297</MemberUrl>
           <MemberName>ACME</MemberName>
           <MemberEndpointCertificate>-----BEGIN CERTIFICATE-----
   MIIFfzCCBGegAwIBAgITTgAAARuwZOW3iRv9KQABAAABGzANBgkqhkiG9w0BAQsF
   ADBCMRMwEQYKCZImiZPyLGQBGRYDY29tMRUwEwYKCZImiZPyLGQBGRYFZm9qdGEx
   FDASBgNVBAMTC2ZvanRhLURDLUNBMB4XDTE1MDExNTE2NTAwNFoXDTE3MDExNDE2
   NTAwNFowZzELMAkGA1UEBhMCQ1oxDzANBgNVBAcTBlByYWd1ZTESMBAGA1UEChMJ
   Zm9qdGEuY29tMRgwFgYDVQQLEw92Q2xvdWQgRGlyZWN0b3IxGTAXBgNVBAMTEHZj
   bG91ZC5mb2p0YS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1
   UeaPIsHjRQb8PkybTv7tfCe6oyq8UUxc7tiwX+nWvHWKJ9X6ASis1v/gT0CCa4cG
   fP+tezXayXMrwFSRu6OvanBSTVYvaAbUQl5CsVnQaaeCC5bTAMfGlDsl/q+LnqzW
   i0eG4hTpWG78v88AZkaHjIZdr5CQuDaPGJUqzOgrHjpYTLDJs+oK+S7ScpMyKhia
   hgeRKDfrEeQGGvSEMdHhg3Bg8RK8eyLQLjwCSCVkhYTrM5wyt4fow65beoMnOBbx
   LO+QpB6/amy5mJuVLVx+WJivVvuId2hmELorm2iJMjUAabybLmbMPmqHTTGyZaYw
   vxaDRDr0DbTMUYFyOh6LAgMBAAGjggJHMIICQzAdBgNVHQ4EFgQUi1Dhxpbkz9Dh
   tYOljP+MW/9GF+AwHwYDVR0jBBgwFoAUs0GCJG1KfknG9couJQXq4CZq4SQwgfoG
   A1UdHwSB8jCB7zCB7KCB6aCB5oaBr2xkYXA6Ly8vQ049Zm9qdGEtREMtQ0EoMSks
   Q049REMyLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2
   aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZvanRhLERDPWNvbT9jZXJ0aWZpY2F0
   ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9u
   UG9pbnSGMmh0dHA6Ly9EQzIuZm9qdGEuY29tL0NlcnRFbnJvbGwvZm9qdGEtREMt
   Q0EoMSkuY3JsMIG7BggrBgEFBQcBAQSBrjCBqzCBqAYIKwYBBQUHMAKGgZtsZGFw
   Oi8vL0NOPWZvanRhLURDLUNBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2
   aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZvanRhLERDPWNv
   bT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1
   dGhvcml0eTAhBgkrBgEEAYI3FAIEFB4SAFcAZQBiAFMAZQByAHYAZQByMA4GA1Ud
   DwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDATANBgkqhkiG9w0BAQsFAAOC
   AQEArNmceh3GkHx5Qf9s/NUlG7lh+i5nPUzlbnlhTJQeOJXSKG3DzU8ocb1xWguT
   x1ICyLZTQq11q3D3/3xgi9KJJaWzo8X5O/Mj81x4V8Jp9d8OgERc7lrVyrAJPbJA
   k7q/4tY41VOu8P5i+A21Pxuo3xELkOt5rcb2qt6QH1QizSA8Dzjq8uwCpdDo8eCP
   ZWUwc2lNUOyCmhFD7boNecHRJZN92i3W0YKfV+BC0cIXnqU2Y+4YEKAHWwH/gRm0
   ZI41oyatyoHpTjCGFtKzrSo/mxitIoj5ZTY9wwSNPlcmziw29hOTM1fOx//rqgrW
   17CREB/BoFj12Hd9bVXFgMGUSg==
   -----END CERTIFICATE-----</MemberEndpointCertificate>
       </OrgAssociationMember>
       <OrgAssociationMember href="https://vcloud2.fojta.com/api/admin/org/ca5295f0-a521-4d4c-8b2e-322f154fbbea/associations/13e52807-3d0a-4c0f-abdb-62d8fccb36ea" type="application/vnd.vmware.admin.organizationAssociation+xml">
           <MemberUrl>https://vcloud.fojta.com/api/org/13e52807-3d0a-4c0f-abdb-62d8fccb36ea</MemberUrl>
           <MemberName>ACME2</MemberName>
           <MemberEndpointCertificate>-----BEGIN CERTIFICATE-----
   MIIFfzCCBGegAwIBAgITTgAAARuwZOW3iRv9KQABAAABGzANBgkqhkiG9w0BAQsF
   ADBCMRMwEQYKCZImiZPyLGQBGRYDY29tMRUwEwYKCZImiZPyLGQBGRYFZm9qdGEx
   FDASBgNVBAMTC2ZvanRhLURDLUNBMB4XDTE1MDExNTE2NTAwNFoXDTE3MDExNDE2
   NTAwNFowZzELMAkGA1UEBhMCQ1oxDzANBgNVBAcTBlByYWd1ZTESMBAGA1UEChMJ
   Zm9qdGEuY29tMRgwFgYDVQQLEw92Q2xvdWQgRGlyZWN0b3IxGTAXBgNVBAMTEHZj
   bG91ZC5mb2p0YS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC1
   UeaPIsHjRQb8PkybTv7tfCe6oyq8UUxc7tiwX+nWvHWKJ9X6ASis1v/gT0CCa4cG
   fP+tezXayXMrwFSRu6OvanBSTVYvaAbUQl5CsVnQaaeCC5bTAMfGlDsl/q+LnqzW
   i0eG4hTpWG78v88AZkaHjIZdr5CQuDaPGJUqzOgrHjpYTLDJs+oK+S7ScpMyKhia
   hgeRKDfrEeQGGvSEMdHhg3Bg8RK8eyLQLjwCSCVkhYTrM5wyt4fow65beoMnOBbx
   LO+QpB6/amy5mJuVLVx+WJivVvuId2hmELorm2iJMjUAabybLmbMPmqHTTGyZaYw
   vxaDRDr0DbTMUYFyOh6LAgMBAAGjggJHMIICQzAdBgNVHQ4EFgQUi1Dhxpbkz9Dh
   tYOljP+MW/9GF+AwHwYDVR0jBBgwFoAUs0GCJG1KfknG9couJQXq4CZq4SQwgfoG
   A1UdHwSB8jCB7zCB7KCB6aCB5oaBr2xkYXA6Ly8vQ049Zm9qdGEtREMtQ0EoMSks
   Q049REMyLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2
   aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZvanRhLERDPWNvbT9jZXJ0aWZpY2F0
   ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9u
   UG9pbnSGMmh0dHA6Ly9EQzIuZm9qdGEuY29tL0NlcnRFbnJvbGwvZm9qdGEtREMt
   Q0EoMSkuY3JsMIG7BggrBgEFBQcBAQSBrjCBqzCBqAYIKwYBBQUHMAKGgZtsZGFw
   Oi8vL0NOPWZvanRhLURDLUNBLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2
   aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZvanRhLERDPWNv
   bT9jQUNlcnRpZmljYXRlP2Jhc2U/b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1
   dGhvcml0eTAhBgkrBgEEAYI3FAIEFB4SAFcAZQBiAFMAZQByAHYAZQByMA4GA1Ud
   DwEB/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDATANBgkqhkiG9w0BAQsFAAOC
   AQEArNmceh3GkHx5Qf9s/NUlG7lh+i5nPUzlbnlhTJQeOJXSKG3DzU8ocb1xWguT
   x1ICyLZTQq11q3D3/3xgi9KJJaWzo8X5O/Mj81x4V8Jp9d8OgERc7lrVyrAJPbJA
   k7q/4tY41VOu8P5i+A21Pxuo3xELkOt5rcb2qt6QH1QizSA8Dzjq8uwCpdDo8eCP
   ZWUwc2lNUOyCmhFD7boNecHRJZN92i3W0YKfV+BC0cIXnqU2Y+4YEKAHWwH/gRm0
   ZI41oyatyoHpTjCGFtKzrSo/mxitIoj5ZTY9wwSNPlcmziw29hOTM1fOx//rqgrW
   17CREB/BoFj12Hd9bVXFgMGUSg==
   -----END CERTIFICATE-----</MemberEndpointCertificate>
       </OrgAssociationMember>
   </OrgAssociations>
   

   As can be seen I am supplying URI for each Organization, its name and endpoint certificate.

2. I can review organization associations with GET /admin/org/{id}/associations call or I can add or remove single association with similar POST / DELETE calls.
3. Now when the end-user authenticates against the organization that has these associations he can run query calls that will run against all associated organizations. To make the query federated he must add federated=global string to the Accept header.

   GET https://vcloud2.fojta.com/api/query?type=organization
   Accept: application/*;version=9.0;federated=global
   x-vcloud-authorization: 4a1f241b371b46f5a36abac85f5962c7
   

   The reply lists all three organizations:

   <?xml version="1.0" encoding="UTF-8"?>
   <QueryResultRecords xmlns="http://www.vmware.com/vcloud/v1.5" name="organization" page="1" pageSize="128" total="3" href="https://vcloud2.fojta.com/api/query?type=organization&amp;page=1&amp;pageSize=128&amp;format=records" type="application/vnd.vmware.vcloud.query.records+xml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vmware.com/vcloud/v1.5 http://vcloud2.fojta.com/api/v1.5/schema/master.xsd">
       <Link rel="alternate" href="https://vcloud2.fojta.com/api/query?type=organization&amp;page=1&amp;pageSize=128&amp;format=references" type="application/vnd.vmware.vcloud.query.references+xml"/>
       <Link rel="alternate" href="https://vcloud2.fojta.com/api/query?type=organization&amp;page=1&amp;pageSize=128&amp;format=idrecords" type="application/vnd.vmware.vcloud.query.idrecords+xml"/>
       <OrgRecord canPublishCatalogs="false" deployedVMQuota="0" displayName="ACME Corporation" isEnabled="true" isReadOnly="false" name="ACME" numberOfCatalogs="1" numberOfDisks="0" numberOfGroups="7" numberOfVApps="1" numberOfVdcs="2" storedVMQuota="0" href="https://vcloud.fojta.com/api/org/02b433db-0b37-4304-b07b-0717255ec297" numberOfRunningVMs="1"/>
       <OrgRecord canPublishCatalogs="false" deployedVMQuota="0" displayName="ACME Inc." isEnabled="true" isReadOnly="false" name="ACME2" numberOfCatalogs="0" numberOfDisks="0" numberOfGroups="1" numberOfVApps="1" numberOfVdcs="1" storedVMQuota="0" href="https://vcloud.fojta.com/api/org/13e52807-3d0a-4c0f-abdb-62d8fccb36ea" numberOfRunningVMs="0"/>
       <OrgRecord canPublishCatalogs="false" deployedVMQuota="0" displayName="Acme Inc." isEnabled="true" isReadOnly="false" name="ACME" numberOfCatalogs="0" numberOfDisks="0" numberOfGroups="1" numberOfVApps="0" numberOfVdcs="0" storedVMQuota="0" href="https://vcloud2.fojta.com/api/org/ca5295f0-a521-4d4c-8b2e-322f154fbbea" numberOfRunningVMs="0"/>
   </QueryResultRecords>
   

Design Considerations

• Only GET requests for the top level Org Level data (org, sessions, tasks, templates/catalogs) and all Query Service requests by Org users can be federated.
• All System Admin query request span single vCloud Director instance and cannot be federated.
• All non-GET requests cannot be federated.
• All associated organizations must use the same identity source as the user is authenticated against all organizations and vCloud Director stores the session tokens for subsequent requests. Local accounts are not supported.
• OAuth identity source offers the lowest administration overhead  when managing multiple organizations belonging to the same end-user as the user/role management can be performed centrally (see vCAT-SP for more information).
• Association works only in one direction: when organization A is associated with organization B it does not mean that organization B is associated with A. Bidirectional association must be explicitly configured for both organization.

In order to access external network resources from internal Org VDC networks Source NAT (SNAT) rule must be created on the Edge Gateway which translates internal IP address to a sub-allocated IP address of a particular external interface.

The internal source IP address can be entered in these formats:

• Single IP address
• Range of IP addresses
• CIDR format

As you can see it is not possible to put ‘Any’ as it is with firewall rules configuration.

After investigating what would be the easiest option to use, this is what I found out:

In case where Edge Gateway is deployed by NSX Manager then it is possible to use following CIDR entry 0.0.0.0/0.

Unfortunately this is not working with Edge Gateway deployed by vShield Manager (vCNS) where Edge configuration fails with the following error:

…- java.util.concurrent.ExecutionException: com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (15012): Invalid IP Address input ‘0.0.0.0/0’ for field ‘rules.natRulesDtos[4].originalAddress’.
– com.vmware.vcloud.fabric.nsm.error.VsmException: VSM response error (15012): Invalid IP Address input ‘0.0.0.0/0’ for field ‘rules.natRulesDtos[4].originalAddress’.
– VSM response error (15012): Invalid IP Address input ‘0.0.0.0/0’ for field ‘rules.natRulesDtos[4].originalAddress’.

The alternative is to use the following IP range: 0.0.0.1-255.255.255.253.

I got interesting question from a colleague if vCloud Director portal can be accessed over IPv6. I suspected the answer is yes so I had little bit of fun and did a quick test.

With NSX load balancer in front of my two VCD cells I created IPv6 VIPs for HTTP, HTTPs and VMware Remote Console (TCP 443) traffic and used the existing IPv4 pools. I also added these IPv6 addresses to my DNS servers so name resolution and certificates would work and was ready to test.

As I terminate SSL session on the LB and insert client IP into the header with X-Insert-For-HTTP I could observe both IPv6 and IPv4 clients in the vCloud Director logs:

Client coming from IPv6 fd13:5905:f858:e502::20:

2015-01-16 19:06:06,431 | SECURITY | pool-eventPublishing-4-thread-1 | SyslogEventPublisher           | Event [id=6869f13c-0643-4afc-b083-982ecc920341, timestamp=1421431566380, type=com/vmware/vcloud/event/session/login, serviceNamespace=com.vmware.vcloud, properties={
...
currentContext.user.clientIpAddress=fd13%3A5905%3Af858%3Ae502%3A%3A20,
entity.name=administrator,
currentContext.user.proxyAddress=10.0.1.1,



Client coming from IPv4 10.0.2.104:


2015-01-16 19:29:46,879 | SECURITY | pool-eventPublishing-4-thread-1 | SyslogEventPublisher | Event [id=6a414e3f-19e7-45c2-83b7-5e0a7d90758b, timestamp=1421432986823, type=com/vmware/vcloud/event/session/login, serviceNamespace=com.vmware.vcloud, properties={
...
currentContext.user.clientIpAddress=10.0.2.104,
entity.name=administrator,
currentContext.user.proxyAddress=10.0.1.1,


Where 10.0.1.1 is load balancer internal interface. Remote Console proxy and OVF Tool also work.

As discussed in my older article VXLAN routed transport network requires to set default gateway of vxlan stack on each ESXi host. While NSX has concept of IP Pools which allows automatic VTEP configuration (including gateway), older vCloud Network and Security (vShield) technology does not have this feature and VTEP IP address must be configure via DHCP or manually.

Following quick and dirty PowerCLI script shows how this can be automated at cluster level:


$hosts = Get-Cluster Cluster1 |Get-VMHost
foreach($vihost in $hosts){
$esxcli = get-vmhost $vihost | Get-EsxCli
$vihost.name
$result=$esxcli.network.ip.route.ipv4.add("10.40.0.1","vxlan","default")
$esxcli.network.ip.interface.ipv4.get("","vxlan")|format-list IPv4Address
$esxcli.network.ip.route.ipv4.list("vxlan")|Format-Table
}


The script sets vxlan stack default gateway to 10.40.0.1 on each host in the cluster ‘Cluster1‘ and displays each host name, VTEP IP address and vxlan routing table.

Credit for esxcli to PowerCLI command conversion goes to Virten.net.

About two years ago I have written a blog post describing how service provider (with cloud based on vCloud Director) can replace hardware without tenants actually noticing this. The provider can stand up new vSphere cluster with new hardware and migrate whole Provider VDC to it with running virtual machines. In my mind this is one of the distinguishing features from other cloud management systems.

Recently I had an opportunity to test this in large environment with vCloud Director 5.5 and would like to report how it is even more simplified compared to vCloud Director 5.1 which the former post was based on. No more API calls are needed and everything can be done from vCloud Administrator GUI in the following five steps:

1. Prepare new cluster and create new provider VDC on it.
2. Merge it with the old provider VDC. Disable its resource pool(s).
   
3. Migrate all VMs from the old resource pool to the new one in vCloud Director (not in vSphere!!!)
   
4. Redeploy all Edge Gateways running on the old hardware.
5. Detach the old resource pool.
   

While the first 4 steps are identical as in vCloud Director 5.1 the step 5 is where the simplification is. The last step takes care of both migration of catalog templates and deletion of shadow VMs.

As before this is possible only with Elastic VDCs (Pay-As-You-Go or Elastic Allocation Pool).

I am working on a few vCloud and NSX API scripts that collect data about Edge Gateways and needed to test how they work at scale. With this little PowerShell script leveraging NSX API I created 500 Edges in 500 seconds. And yes – I cheated as they were in undeployed state.

get-date
$NumberOfEdges = 500
$Username = "admin"
$Password = "default"
$NSXManager="nsx01.fojta.com"


$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Username + ":" + $Password))
$head = @{"Authorization"="Basic $auth"}
$Request = "https://$NSXManager/api/4.0/edges"


$count=0
DO
{
$count++
$body = "
<edge>
	<datacenterMoid>datacenter-2</datacenterMoid>
	<name>$count</name>
	<description>TEST</description>
	<vnics>
		<vnic>
			<label>vNic_0</label>
			<name>vnic0</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>0</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_1</label>
			<name>vnic1</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>1</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_2</label>
			<name>vnic2</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>2</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_3</label>
			<name>vnic3</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>3</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_4</label>
			<name>vnic4</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>4</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_5</label>
			<name>vnic5</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>5</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_6</label>
			<name>vnic6</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>6</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_7</label>
			<name>vnic7</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>7</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_8</label>
			<name>vnic8</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>8</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
		<vnic>
			<label>vNic_9</label>
			<name>vnic9</name>
			<addressGroups/>
			<mtu>1500</mtu>
			<type>internal</type>
			<isConnected>false</isConnected>
			<index>9</index>
			<enableProxyArp>false</enableProxyArp>
			<enableSendRedirects>true</enableSendRedirects>
		</vnic>
	</vnics>
	<appliances>
		<deployAppliances>false</deployAppliances>
	</appliances>
</edge>"

$Response = Invoke-WebRequest -Uri $Request -Method 'Post' -Headers $head -ContentType "application/xml" -Body $body
Write-Host -NoNewline "#";
} Until ($count -ge $NumberOfEdges)
Write-Host
Write-Host "I have created $count Edges"
get-date

Well and you probably do not want to delete them by hand either.

Get-Date
$Username = "admin"
$Password = "default"
$NSXManager="nsx01.fojta.com"

$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Username + ":" + $Password))
$head = @{"Authorization"="Basic $auth"}
$Request = "https://$NSXManager/api/3.0/edges"

$r = Invoke-WebRequest -Uri ($Request+"?startIndex=0&pageSize=1000") -Headers $head -ContentType "application/xml" -ErrorAction:Stop

foreach ($Edge in ([xml]$r.content).pagedEdgeList.edgePage.edgeSummary)
{
$edgeId = $Edge.objectId
If ($Edge.description -eq "TEST")
	{
	$count++
	$Response = Invoke-WebRequest -Uri ($Request+"/"+$edgeId) -Method 'Delete' -Headers $head -ContentType "application/xml"
	Write-Host Deleting Edge $edgeId
	}
}
Write-Host
Write-Host "I have deleted $count Edges"
Get-Date

Note: You need at least PowerShell 3.0.

NSX Edge Service Gateways are virtual machines deployed by NSX Manager that provide network services (routing, bridging, load balancing, VPNs, DNS relay, DHCP, …). This makes them quite a critical component in the infrastructure and thus there might be a need to keep a close eye on their availability.

While NSX Manager reports the status of the Edges in the GUI and logs it might take some time to register a change in the health. If you want up-to-date status of an Edge health you need to query the NSX Manager with NSX API. The NSX Manager then retrieves the current status of the Edge. The mechanism of the communication between NSX Manager and Edge appliance(s) depends on the Edge version and the vSphere cluster status:

VIX Communication

This is the legacy mode of communication. NSX Manager utilizes VIX API to query vCenter Server and the ESXi Host which runs the Edge appliance who then via VM Tools talks to the actual VM. This mode of communication is used for the legacy Edges version 5.5.x (deployed via  the compatibility vShield v2 API) and as failback mode when for some reason Message Bus Communication mode is not possible.

source: https://www.vmware.com/support/developer/vix-api/guestOps50_technote.pdf

Message Bus Communication

This is direct (and faster) communication between NSX Manager and the ESXi host (vsfwd process) running the Edge appliance. During the Edge deployment the cluster where the Edge is deployed to must be prepared for NSX and without any issues.

source: NSXvSphereDesignGuidev2.1.pdf

To query the Edge health is an expensive operation – it takes time and creates load on NSX Manager. If there is large number of Edges (for example in service provider scenario) this should be considered.

To test the viability of checking at least once in a given time the status of all Edges health I have created simple Powershell function Get-NSXEdgeHealth:

function Get-NSXEdgeHealth {
<#
.SYNOPSIS Gathers Health Status of a NSX Edge
.DESCRIPTION Will query NSX Manager for the health of a particular NSX Edge
.NOTES Author: Tomas Fojta
.PARAMETER NSXManager
The FQDN or IP of your NSX Manager
.PARAMETER Username
The username to connect with. Defaults to admin if nothing is provided.
.PARAMETER Password
The password to connect with
.PARAMETER EdgeId
ID of the Edge to gather health data for.
.EXAMPLE
PS> Get-NSXEdge -NSXManager nsxmgr.fqdn -Username admin -Password password -EdgeId EdgeId
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true,Position=0)]
[String]$NSXManager,
[Parameter(Mandatory=$false,Position=1)]
[String]$Username = "admin",
[Parameter(Mandatory=$true)]
[String]$Password,
[Parameter(Mandatory=$true)]
[String]$EdgeId
)
Process {
### Ignore TLS/SSL errors
add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
### Create authorization string and store in $head
$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Username + ":" + $Password))
$head = @{"Authorization"="Basic $auth"}
$HealthRequest = "https://$NSXManager/api/3.0/edges"+"/"+$EdgeId+"/status"

$h = @{} | select Health, Detail

$r = Invoke-WebRequest -Uri $HealthRequest -Headers $head -ContentType "application/xml" -ErrorAction:Stop
[xml]$rxml = $r.Content
$h.Health = $rxml.edgeStatus.edgeStatus
$Details = @()
foreach ($Feature in $rxml.edgeStatus.featureStatuses.featureStatus)
{
$n = @{} | select Service, Status
$n.Service = $Feature.service
$n.Status = $Feature.status
$Details += $n
}
$h.Detail = $Details

return ,$h

} # End of process

PowerShell 3.0 or higher and (at least audit) credentials (and connectivity) to NSX Manager are needed.

Usage example:

As can be seen the function needs the Edge ID parameter and then returns the overall Edge health and also detailed status of all its network services.

Following health states are defined:

• green – good. This is the only state that guarantees that the Edge is functional.
• red – no backing appliance is in service state
• grey – unknown status (for example undeployed Edge)
• yellow – intermittent health check failures (if more than 5 consecutive health checks fail the status goes to red)

Following function Get-NSXEdges will collect all Edges in the environment:

function Get-NSXEdges {
<#
.SYNOPSIS Gathers NSX Edges from NSX Manager
.DESCRIPTION Will inventory all of your NSX Edges from NSX Manager
.NOTES Author: Tomas Fojta
.PARAMETER NSXManager
The FQDN or IP of your NSX Manager
.PARAMETER Username
The username to connect with. Defaults to admin if nothing is provided.
.PARAMETER Password
The password to connect with
.EXAMPLE
PS> Get-NSXEdges -NSXManager nsxmgr.fqdn -Username admin -Password password
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true,Position=0)]
[String]$NSXManager,
[Parameter(Mandatory=$false,Position=1)]
[String]$Username = "admin",
[Parameter(Mandatory=$true)]
[String]$Password
)

Process {
### Ignore TLS/SSL errors
add-type @"cd
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
### Create authorization string and store in $head
$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Username + ":" + $Password))
$head = @{"Authorization"="Basic $auth"}
### Connect to NSX Manager via API
$Request = "https://$NSXManager/api/3.0/edges"
$r = Invoke-WebRequest -Uri ($Request+"?startIndex=0&pageSize=1") -Headers $head -ContentType "application/xml" -ErrorAction:Stop
$TotalCount = ([xml]$r).pagedEdgeList.edgePage.pagingInfo.totalCount

$r = Invoke-WebRequest -Uri ($Request+"?startIndex=0&pageSize="+$TotalCount) -Headers $head -ContentType "application/xml" -ErrorAction:Stop
[xml]$rxml = $r.Content

### Return the NSX Edges

$Edges = @()

foreach ($EdgeSummary in $rxml.pagedEdgeList.edgePage.edgeSummary)
{
$n = @{} | select Name,Id
$n.Name = $edgeSummary.Name
$n.Id = $edgeSummary.objectId
$Edges += $n
}
return ,$Edges

} # End of process

} # End of function

And here is a sample script leveraging both functions above that continuously displays health status of all the Edges in the environment and also displays the time needed to go through all of them.

$NSXManager = "nsx01.fojta.com"
$Username = "admin"
$Password = "default"

$AllEdges = Get-NSXEdges -NSXManager $NSXManager -Username $Username -Password $Password

DO
{
$StartTime = get-date
foreach ($Edge in $AllEdges)
{
$Health = Get-NSXEdgeHealth -NSXManager $NSXManager -Username $Username -Password $Password -EdgeId $Edge.Id
Write-Host $Edge.Name $Health.Health
}
$Duration = (get-date) - $StartTime
Write-Host
Write-Host "Duration:" $Duration.Minutes "Minutes" $Duration.Seconds "Seconds"
Write-Host
} While ($true)

In my lab it took at least cca 2 seconds to get status of an Edge (depending on the mode of communication and its actual health). It is obvious that most time NSX Manager spends on communication with the ESXi host – so the task should and can be parallelized. While running 5 sessions at the same time the retrieval of health status of one Edge went up to 3-4 seconds (for a green Edge) while the load on NSX Manager went up 14 % (I run NSX Manager only with 2 vCPUs in my lab).

While the article mentions only NSX the scripts should work also with vShield / vCloud Networking and Security Manager.

After almost 4 years working for professional services at VMware I am transferring to new Architect role in Global Cloud Practice – vCloud Air Network. I am taking up the challenge to work in a global team of cloud architects with half of them VCDX certified which will support the largest vCloud Air Network Service Provider partners.

During my PSO days as Consulting Architect I was consulting, designing and implementing private and public clouds for global, large and also smaller customers all over Europe with most of them in German-speaking countries. Whenever I encountered an interesting problem I blogged about it on this blog and recently the most often topics blogged about were about vCloud Director and NSX.

So I feel it is a perfect fit for me that In the new role I will specialize on public cloud only for handful of large SPs which means you can expect more articles about vCloud Director and NSX :-).

Stay tuned…

Recently one of my customers changed naming convention of vCloud Director Edge Gateways. He renamed them in vCloud Director however the names of virtual machines backing the Edge Gateways stayed the same. Also the names in vShield Manager or NSX Manager did not change. He quickly found out that there is no way to change the name in the GUI of vShield/NSX Manager. This is unfortunate especially for troubleshooting purposes.

Just today I saw the same question internally on our mailing list and the answer is that you can rename the Edge via API. Just GET the particular edge configuration and PUT it back with the changed name. As I recently wrote Powershell scripts that leveraged NSX API I quckly modified it and created two functions – RenameEdgeV5 and RenameEdgeV6.

They both rename the Edge, however only the first one works with vShield Manager. (EDIT 11 June 2015: Unfortunately vShield Manager does not allow renaming of Edges. You will get following error: Edge name cannot be updated. Specified name … does not match … Error code 15013.)

When using NSX Manager you have to use the one that matches the Edge version. The legacy Edges deployed by vCloud Director are version 5. The new NSX Edges are version 6. The API calls to retrieve the Edge info and change it are very similar one uses api 3.0 the other api 4.0.

Here are the scripts:

function RenameEdgeV5 {
<#
.SYNOPSIS Renames vShield Edge
.DESCRIPTION Renames vShield or NSX legacy v5 Edge
.NOTES Author: Tomas Fojta
.PARAMETER NSXManager
The FQDN or IP of your vShield or NSX Manager
.PARAMETER Username
The username to connect with. Defaults to admin if nothing is provided.
.PARAMETER Password
The password to connect with
.PARAMETER EdgeId
.EXAMPLE
PS> RenameEdge -NSXManager nsxmgr.fqdn -Username admin -Password password -EdgeId EdgeId -Name newname
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true,Position=0)]
[String]$NSXManager,
[Parameter(Mandatory=$false,Position=1)]
[String]$Username = "admin",
[Parameter(Mandatory=$true)]
[String]$Password,
[Parameter(Mandatory=$true)]
[String]$EdgeId,
[Parameter(Mandatory=$true)]
[String]$Name
)
Process {
### Ignore TLS/SSL errors
add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
### Create authorization string and store in $head
$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Username + ":" + $Password))
$head = @{"Authorization"="Basic $auth"}
$HealthRequest = "https://$NSXManager/api/3.0/edges"+"/"+$EdgeId
$s = Invoke-WebRequest -Uri $HealthRequest -Headers $head -ContentType "application/xml" -ErrorAction:Stop
[xml]$sxml = $s.Content
$sxml.edge.name = $Name
$r = Invoke-WebRequest -Uri $HealthRequest -Method Put -Headers $head -ContentType "application/xml" -Body $sxml.OuterXML -ErrorAction:Stop

return $r.StatusCode

function RenameEdgeV6 {
<#
.SYNOPSIS Renames NSX Edge
.DESCRIPTION Renames NSX Edge
.NOTES Author: Tomas Fojta
.PARAMETER NSXManager
The FQDN or IP of your NSX Manager
.PARAMETER Username
The username to connect with. Defaults to admin if nothing is provided.
.PARAMETER Password
The password to connect with
.PARAMETER EdgeId
.EXAMPLE
PS> RenameEdge -NSXManager nsxmgr.fqdn -Username admin -Password password -EdgeId EdgeId -Name newname
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true,Position=0)]
[String]$NSXManager,
[Parameter(Mandatory=$false,Position=1)]
[String]$Username = "admin",
[Parameter(Mandatory=$true)]
[String]$Password,
[Parameter(Mandatory=$true)]
[String]$EdgeId,
[Parameter(Mandatory=$true)]
[String]$Name
)
Process {
### Ignore TLS/SSL errors
add-type @"
using System.Net;
using System.Security.Cryptography.X509Certificates;
public class TrustAllCertsPolicy : ICertificatePolicy {
public bool CheckValidationResult(
ServicePoint srvPoint, X509Certificate certificate,
WebRequest request, int certificateProblem) {
return true;
}
}
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy
### Create authorization string and store in $head
$auth = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Username + ":" + $Password))
$head = @{"Authorization"="Basic $auth"}
$HealthRequest = "https://$NSXManager/api/4.0/edges"+"/"+$EdgeId
$s = Invoke-WebRequest -Uri $HealthRequest -Headers $head -ContentType "application/xml" -ErrorAction:Stop
[xml]$sxml = $s.Content
$sxml.edge.name = $Name
$r = Invoke-WebRequest -Uri $HealthRequest -Method Put -Headers $head -ContentType "application/xml" -Body $sxml.OuterXML -ErrorAction:Stop

return $r.StatusCode

} # End of process

} # End of function

Usage example:

vSphere Client recent task activity:

And NSX Manager Edge Gateway view.

Related to my previous post about monitoring Edge Gateways my customer asked me if he could leverage vCenter Server alarms as they are integrated with their monitoring and alerting infrastructure.

So basically is there a way to create vCenter alarm via scripted action (for example with PowerCLI)?

The answer is yes and it is not that difficult. There are two types of vCenter alarms: based on condition/state or an event. And it is possible to create custom user event via Loguserevent method of entity manager via vSphere API.

This is example of PowerCLI code the creates user event “Edge Gateway event” at the root datacenter folder.

$DCFolderEntity = Get-Folder -Name datacenters
$eventMgr = Get-View EventManager
$eventMgr.LogUserEvent($entity.ExtensionData.MoRef,"Edge Gateway event")

Now it is easy to create custom alarm based on the user logged event. Create the alarm at the vCenter Server root level, as alarm type pick monitor vCenter Server and as triggers manually enter (type):

Event; vim.event.GeneralUserEvent 

That’s it.