vCloud Director Extender 1.1 – Add Permissions Script for Organization Admin

15June2018 Update – note this script is ONLY for vCD Extender 1.1 release. There was a permissions change with version 1.1.0.1 of vCD Extender. PLEASE review this new blog post for the latest script! 

We saw that vCloud Director Extender 1.1 was released a few weeks ago and I’m working with it in my lab. More to come with new features available in this release.

One of the nice things about this newest released is enhanced error state messages and ensuring the right permissions are applied to the organization user before the tenant can connect to the vCloud environment.

So, if we attempt to connect with the org account and it does not have the correct permissions, you will get an error like this:

We can see that the user does not have the exact permission required to successfully enroll with vCD Extender.

These are the VMware Documentation instructions on adding the correct permissions, but this adds ALL provider org admin permissions, which I’m not a fan of (nor are other Providers I support).

I’ve used Jon Waite’s script in the past here but I’ve updated and tested the exact permissions you need for vCloud Director 9.1.0.7905680 and vCD Extender 1.1 –

Step 1 – Grab PowerShell Script

Here is the current PowerShell script based on my testing on what permissions are needed. I used this in two 9.1 environments and was successful for Extender connectivity. I’m sure this can be ported to other automation tools, but this is what I was comfortable with. Save this as a ps1 file while changing OrgToUpdate and APIendpoint lines below.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
# vCloud Director Extender Permissions Setup - initially created by KiwiCloud.Ninja - modified by Daniel Paluszek - paluszek.com
# Creation Date: 2018-May-2nd
# Version 2.0 - for vCD Extender 1.1 and vCloud Director 9.1
# Adds specific permissions required for vCD Extender Org Admin to connect successfully to cloud instance.
# NOTE: These are tested on version vCD 9.1.0.7905680
# Note that Organization roles (e.g. Organizational Administrator) still need to be edited to add these rights once is executed
# NOTE: You must be connected to the vCloud API (Connect-CIServer) with a System administrative user prior to running the script for this to work.
# Add your Org name and vCD instance name below
$OrgToUpdate = '<INSERT-ORG-NAME>'
$APIendpoint = '<INSERT-IP-OR-FQDN-OF-VCD>'

Function vCloud-REST(
[Parameter(Mandatory=$true)][string]$URI,
[string]$ContentType,
[string]$Method = 'Get',
[string]$ApiVersion = '27',
[string]$Body,
[int]$Timeout = 40
)
{
$mysessionid = ($global:DefaultCIServers | Where { $_.Name -eq $APIendpoint }).SessionId
$Headers = @{"x-vcloud-authorization" = $mysessionid; "Accept" = 'application/*+xml;version=' + $ApiVersion}
if (!$ContentType) { Remove-Variable ContentType }
if (!$Body) { Remove-Variable Body }
Try
{
[xml]$response = Invoke-RestMethod -Method $Method -Uri $URI -Headers $headers -Body $Body -ContentType $ContentType -TimeoutSec $Timeout
}
Catch
{
Write-Host "Exception: " $_.Exception.Message
if ( $_.Exception.ItemName ) { Write-Host "Failed Item: " $_.Exception.ItemName }
Write-Host "Exiting."
Return
}
return $response
} # Function vCloud-REST End

# Adds required permissions for vCD Extender connectivity - still require to apply permissions in the UI once executed!
$newrights = @{}
$newrights.Add("Organization vDC Gateway: View Firewall", "7fee6646-ec0c-34c9-9585-aff6f4d92473")
$newrights.Add("Organization vDC Gateway: View L2 VPN", "105191de-9e29-3495-a917-05fcb5ec1ad0")
$newrights.Add("Organization vDC Gateway: Configure L2 VPN", "eeb2b2a0-33a1-36d4-a121-6547ad992d59")
$newrights.Add("Organization vDC Gateway: Configure System Logging", "ff3fc70f-fd25-3c0a-9d90-e7ff82456be5")
$newrights.Add("Organization Network: Create or Delete", "60be4106-1f9f-325c-8ff4-8bf2c6d9bc0a")
$newrights.Add("Organization VDC: view metrics", "99bd8096-73d1-3abe-970f-82f08dfbd762")
$newrights.Add("Organization vDC: View", "f66d8e79-b584-3d79-a501-d71aaa2ebbf9")
$newrights.Add("Organization vDC: Extended View", "501166b9-0525-3c0e-87f5-46642c7c650f")
$newrights.Add("Right: View", "66b32e08-1eeb-37ac-9266-ffbd19b39dd8")
$newrights.Add("VCD Extension: View", "af1aa6c1-f693-39b0-baf5-455bd8f6e378")
$newrights.Add("VCD Extension: Register, Unregister, Refresh, Associate or Disassociate", "f41bed42-23e8-3422-abcb-cd78ee0a7cf8")
$newrights.Add("Provider vDC: View", "01e66fc7-c18e-3511-ac3e-89b1ede75585")
$newrights.Add("Catalog: Shadow VM View", "b2480b40-1a09-38e7-a01d-40f1bf76dd72")
$newrights.Add("Catalog: Import Media from vSphere", "fbf21e1d-55c9-30d7-9d21-6ce2e63d2d54")
$newrights.Add("vApp: Import Options", "10bb6775-87b6-327c-95ce-62090fc514cd")
$newrights.Add("vApp: VM Check Compliance", "efcdc465-ed11-3059-850c-2c1436754dca")
$newrights.Add("vApp: Shadow VM View", "7405e842-79f2-31d8-8401-360e2b7947d7")
$newrights.Add("vApp: Enter/Exit Maintenance Mode", "23e2452d-2a8a-3cf2-a95d-0d2cfbb9540d")
$newrights.Add("Datastore: View", "805f2957-f3cf-3faf-aa04-f10c4565c37e")
$newrights.Add("Datastore: Edit", "76a35a35-13fd-3702-9514-6c781c64d47c")
$newrights.Add("Host: Migrate VMs", "b853515b-398c-3658-b622-c45d98c5ecaa")
$newrights.Add("Host: View", "fa553cfc-ab48-349f-b4f3-b836b99717e7")
$newrights.Add("Resource Pool: Open", "3eae48e4-949c-3acf-99fb-eaf4896aefc9")
$newrights.Add("Resource Pool: View", "02d7a15f-2d71-3e23-854e-7a711754f87f")
$newrights.Add("Network Pool: View", "293f322e-c536-3e60-b062-08e9f2cf4efb")
$newrights.Add("Network Pool: Edit", "dca04a78-e9a5-36a3-aee7-a5f298acc34c")
$newrights.Add("Network Pool: Repair", "e323a73b-5140-3092-87aa-0ccb43412606")
$newrights.Add("Network Pool: Create or Delete", "404b4c7d-4ed3-39fa-b9a0-9389d43ec9cf")
$newrights.Add("Task: Update", "f4ac42f6-7458-3180-92f6-8ccf6140f698")
$newrights.Add("Task: Resume, Abort, or Fail", "d9515366-74dc-3e97-bebe-8b080e310549")

$myendpoint = $global:DefaultCIServers | Where { $_.Name -eq $APIendpoint }

if (!$myendpoint.IsConnected) {
Write-Host "Not connected to this vCloud endpoint, use 'Connect-CIServer' before running this script."
Exit
}

$org = Get-Org -Name $OrgToUpdate -Server $APIendpoint

if (!$org) {
Write-Host "Couldn't match organization with name $OrgToUpdate, exiting."
Exit
}

$rightsuri = 'https://' + $APIendpoint + "/api/admin/org/" + $org.Id.Substring($org.Id.LastIndexOf(':')+1) + "/rights"

[xml]$rights = vCloud-REST -URI $rightsuri -ContentType 'application/vnd.vmware.admin.org.rights+xml' -Method 'Get' -ApiVersion '27.0'

# Add the new API v27 'RightsReference' elements to the XML returned:
foreach($newrule in $newrights.Keys) {
$newright = $rights.CreateElement("RightReference", "http://www.vmware.com/vcloud/v1.5")
$newright.SetAttribute("href","https://$APIEndpoint/api/admin/right/$($newrights.Item($newrule))")
$newright.SetAttribute("name",$newrule)
$newright.SetAttribute("type","application/vnd.vmware.admin.right+xml")
$rights.OrgRights.AppendChild($newright)
}

# Update the Organization with the ammended rights:
vCloud-REST -URI $rightsuri -ContentType 'application/vnd.vmware.admin.org.rights+xml' -Body $rights.InnerXml -Method 'Put' -ApiVersion '27.0'

Step 2 – Check out the existing permissions

Go to your organization’s orgadmin role and take a look at the current permissions. You should see what’s currently available.

From the UI, we would see the following:

One could also procure this through the API by issuing a GET command with

https://<vcd-instance>/api/admin/org/<org-id>/rights

Step 3 – Execute PowerShell Script

I imported the script into PowerShell ISE (I was working on a few modifications so I just ran it there, you can always ./ it too) and executed it.

Remember, you need to fill out lines 8 and 9 with the Organization and vCD instance name respectively.

Let’s execute!

Let’s take a look at the org admin permissions now. We do see new boxes to check.

We can also see the specific permissions required under the vApp category that are required.

Step 4 – Connect via Extender

Based on my testing, this was the only permissions needed for an org-admin user. After testing this in two instances, I was successful with connectivity inside of vCloud Director Extender.

From here, you can continue with your vCloud Director Extender migrations and L2 VPN connections (or what’s called DC Extensions). Special thanks to Jon Waite for his initial script and Sean Smith for his assistance on testing. More to come here, I’ll be reviewing some of the new functionality of vCD Extender 1.1! Thanks.

-Daniel

VMware Lightboard – Intro to vCloud Director Extender

This was my first VMware Lightboard and was a lot of fun! However, it was definitely more challenging than I anticipated. I started off twice and ended within 20 seconds each time because I didn’t like my initial dialog. However, what you see below is my third time. I think I did okay for the first lightboard.

We are definitely getting a lot of questions about the newest release of VMware vCloud Director and vCloud Director Extender. This lightboard should serve as an introduction to vCD Extender and what it can do for providers and consumers of vCloud environments.

I look forward to my next lightboard video! Oh, and there’s been a new release of vCloud Director Extender with some new editions – check it out here! 

-Daniel

A deeper look at vCloud Director and NSX Distributed Logical Router and Firewall Services with Usage Meter feature detection

Need to work on my titles, but that’s what I have for now. I want to spend some time reviewing how NSX Distributed, Edge, and DLR Firewall services behave in respect to vCloud Director and vCloud Usage Meter.

Some may know vCloud Usage Meter provides automated feature detection on a per-VM basis – essentially allowing granular-level billing for tenants. For example, tenant ACME may have 5 VM’s that need Distributed Firewall out of 20 – why charge them for all if they aren’t using it? Since version 3.6 of Usage Meter, this feature has been applied on a per VM level, for the most part.

There are three different versions of NSX available in the Cloud Provider Program –

We can see that your basic fundamentals are available in SP Base: your distributed switching and routing, Edge Firewall services, NAT’ing, etc. Advanced adds in Distributed Firewalling, Service Insertion and other advanced functionality while Enterprise is adding in X-vCenter NSX, HW VTEP integration.

Second, let’s take a look at the chart for NSX Editions by Feature. This comes from our vCloud Usage Meter Feature Detection whitepaper. Don’t have it? Get on VMware Partner Central and grab a copy.

Take note at the statement of “All VMs on all networks serviced by the edge” – this means even if you have a VM on that edge that does not use that feature, it will charge for it since it still has access to it. For example, if you set up a L2VPN on an Edge, be aware that any other connected networks will be charged for NSX Enterprise even though they may not be able to traverse to that tunnel!

Lab Setup

I wanted to design a DLR environment within vCD along with using Edge and Distributed Firewall rules. I came up the following design in my 9.x environment:

  1. Creating an NSX Distributed Logical Router (DLR) is pretty easy. Select the Advanced Gateway box and check Enable Distributed Routing. You can also enable Distributed Routing on any existing Advanced Edge – 
  2. The great thing about how vCloud Director creates Distributed Routing is it’s actually two Edges – a standard perimeter edge along with the DLR southbound. The transit interface is created as a /30 while applying static routes for any connected DLR interface. DLR’s default gateway is the Edge transit interface. Below is what I can see inside of NSX. 

Using the NSX Distributed Logical Router is in the NSX Base bundle and covered by Advanced SP Bundle, which is great for providers. However, Edge Firewall services are only available in the NSX Base bundle, where some providers may want to provide “high-powered” firewalling services.

The key difference between Edge and Distributed Firewall services is we do not hairpin for forwarding decisions in the DFW model: the decision is made inside of the hypervisor before the packet ever egresses anywhere. Hence, provides better throughput and capability compared to Edge or traditional firewall services – check out Wissam’s discussion on DFW capabilities here. 

vCD Access to Edge Firewall vs Distributed Firewall

I think Tomas did a great job of summarizing vCD Firewall capabilities and pointing out some of the architecture differences between the two firewall technologies.

From a vCD UI access point of view, you have to access the firewall services in two different places.

  1. Edge Firewall services are accessed by right-clicking on the Edge Gateway and selecting Edge Services. Makes sense, right? 
  2. Now Distributed Firewall management is accessed by right-clicking on the organization VDC and clicking on Manage Firewall. Not my favorite and doesn’t state DFW, but this is how it’s accessed today in the Flex UI. 

NSX Distributed Firewall Changes

Okay, let’s get into a few scenarios and test out how Usage Meter will put up the changes.

  1. I freshly created my three vApps: T1-App-1, T1-DB-01, T1-DLR-tclinux-01/02a (Web Servers). We can run a VM History Report and pick them up and see they all have been associated with the Advanced Bundle initially. I will try to point out the vROps and NSX column in the following discussion, but we will be looking for a checkmark and an “A” that refers to Advanced usage. 
  2. So let’s go ahead and crack open the DFW and start carving up some rules. This is a simple 3-tier architecture so I’m going to lay out allowing web, web to app traffic, app to DB, allowing SSH to App and DB, and blocking everything else in Web, App, and DB Tiers. 
  3. As you can see, the Applied To for my deny rule is only applied to my three Distributed Routing tiers (or routed Org VDC Networks). Not only is this a good NSX practice, this cuts down on who gets charged for NSX Advanced!
  4. Now looking at the DFW rules from vCenter, I can see vCD created the tenant folder and applied the policies in order. Very streamlined. 
  5. Now let’s check to see if my new rules work. Yep, I can still SSH to my VM’s but do not receive any ICMP replies. Perfect! 

How did Usage Meter detect the changes?

  1. So let’s now take a look at the Usage Meter VM History Report. What’s fascinating is Usage Meter tracks every move called state change. We can see in my tclinux-vApp (or Web) that it tracked when it started using Base NSX usage, then switched to Advanced, then my vROPs Enterprise instance picked it up and added it to its inventory. All in a very short timespan. Very useful! 
  2. With the DB and App layers, we see something very similar – vROps Enterprise, however, picked up these VM’s first and then we see Advanced NSX usage. 
  3. Now, I can see a few new line items populated on my Customer Monthly Usage and Monthly Usage report. I now see Advanced Bundle with Networking, Advanced Bundle with Management, Advanced Bundle with Networking and Management.
  4. This is to be expected since my VM’s went through a few iterations – my Web VM’s initially went with NSX Advanced without vROps which falls in the Advanced with Management while DB/App started using NSX Advanced without vROps registration (Advanced with Networking bundle). Last of all, all three are now assigned to the Advanced w/Networking and Management since we are using NSX Advanced features along with vROps Enterprise.
  5. While I see the new line items, I don’t see any units to be reported. Why? Well, I have some very small VM’s (256MB in vRAM) and they just ran a few hours during this testing. Keep in mind Usage Meter averages out the usage over the entire calendar month (720 hours for a 30 day period or 744 hours in a 31 day period). Again, to be expected but was pleased that new categories were added immediately.

In summary, Usage Meter does a great job of detecting NSX feature usage and bills it accordingly based on a specific service – Distributed Firewall being one of them. Thanks!

-Daniel

New VMware Cloud Provider Hands on Labs (HOL) Available!

I’ve been bantering on vCloud Director 9 and Usage Meter for some time now – wouldn’t it be great to test out these great solutions on-demand and at no charge? VMware HOL is the way to go

Well, here you go. My esteemed colleague, Eric Stine, has been working significantly on updating the VMware Hands-on Labs (HOLs) for our VMware Cloud Provider partners to utilize and demonstrate the functionality.

For the first HOL, we have introduced our standard, multi-tenant vCloud Director stack that shows the key features of vCD. This has been updated to version 9.0 to see the new functionality that we’ve been discussing. This is a great way to experience the new tenant HTML5 interface, play with NSX Distributed Logical Router conversions inside of vCD, and many other items.

Launch the vCloud Director HOL here

Second, we have the VMware Cloud Provider Program – Tools and Offerings HOL that has a lot of other affiliated goodies. You will see the following in here:

  1. vRealize Operations with our Tenant App for vCD – check out Sean Smith’s install review of the Tenant App for vCD
    1. Another value add that provides vROps data inside of a multi-tenant and vCD hierarchy.
  2. Usage Meter
    1. Everyone’s favorite metering tool – this is inclusive of 3.6x which provides feature detection based on itemized VM billing.
  3. vCloud Availability

Launch the Tools and Offerings HOL here. 

Happy HOL’ing!

-Daniel