Organization VDC Permissions in vCloud Director

Update 14/04/2020: This feature is available in the Cloud Director UI from version 10.1.

As of vCloud Director 8.10 it is possible for the tenant Organization Administrator to control access to Organization VDCs. This enables the following use case:

• In one Organization there are multiple Org VDCs belonging to different business units. Each Org VDC has its own Organization VDC administrator (from the business unit) who can manage Org VDC resources (networks, Edge Gateways) in his Organization VDC but does not see VDCs of other business unit.

The capability is currently available only with vCloud API. There are also four new related user rights that system administrator can use to create new roles.

• Allow Access to All Organization VDCs
• Edit Access Control List of Organization VDCs
• View Access Control List of Organization VDCs
• Implicitly Import User/Group from IdP while Editing VDC ACL

Note that I have removed most of Organization and all User rights from the custom Org VDC Admin role which follows the described use case.

In the following example I have two Org VDCs – Production and Test in Organization ACME. The Organization Administrator (acmeadmin) created two Org VDC Admin users – acmeadminprod and acmeadmintest. Now he will create access for each to his corresponding Org VDC.

As was mentioned above, this is done with vCloud API PUT request. First we need to find out Org VDC and user references.

GET https://vcloud.fojta.com/api/admin/org/02b433db-0b37-4304-b07b-0717255ec297
Accept: application/*+xml;version=20.0 x-vcloud-authorization: 3e131f9e3bc240269a7758fdb6c1bf7f

<?xml version="1.0" encoding="UTF-8"?>

<AdminOrg xmlns="http://www.vmware.com/vcloud/v1.5" name="ACME" id="urn:vcloud:org:02b433db-0b37-4304-b07b-0717255ec297" href="https://vcloud.fojta.com/api/admin/org/02b433db-0b37-4304-b07b-0717255ec297" type="application/vnd.vmware.admin.organization+xml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vmware.com/vcloud/v1.5 http://vcloud.fojta.com/api/v1.5/schema/master.xsd">
	<Link rel="down" href="https://vcloud.fojta.com/api/tasksList/02b433db-0b37-4304-b07b-0717255ec297" type="application/vnd.vmware.vcloud.tasksList+xml"/>
	<Link rel="down" href="https://vcloud.fojta.com/api/admin/org/02b433db-0b37-4304-b07b-0717255ec297/metadata" type="application/vnd.vmware.vcloud.metadata+xml"/>
	...
	<Users>
		<UserReference href="https://vcloud.fojta.com/api/admin/user/395b2a93-d5ef-4c55-a316-ab500ea4829c" name="acmeuser" type="application/vnd.vmware.admin.user+xml"/>
			<UserReference href="https://vcloud.fojta.com/api/admin/user/46f40e2c-ed07-428f-af82-e691329f3cba" name="acmeadmin" type="application/vnd.vmware.admin.user+xml"/>
			<UserReference href="https://vcloud.fojta.com/api/admin/user/8c1af691-baa9-49db-9bf4-a5ad0562f92b" name="acmeadmintest" type="application/vnd.vmware.admin.user+xml"/>
			<UserReference href="https://vcloud.fojta.com/api/admin/user/e20edd07-e426-4a72-8f49-718b37685da6" name="acmeadminprod" type="application/vnd.vmware.admin.user+xml"/>
		</Users>
	...
	<Vdcs>
		<Vdc href="https://vcloud.fojta.com/api/vdc/18d1590d-e033-4618-8179-432f99e5c54a" name="Test" type="application/vnd.vmware.vcloud.vdc+xml"/>
		<Vdc href="https://vcloud.fojta.com/api/vdc/47564d52-9204-40b1-b315-a00d59945cfd" name="Production" type="application/vnd.vmware.vcloud.vdc+xml"/>
	</Vdcs>
	...
</AdminOrg>

Now we can construct PUT request for each Org VDC to assign user access:

Test Org VDC

PUT https://vcloud.fojta.com/api/vdc/18d1590d-e033-4618-8179-432f99e5c54a/action/controlAccess

Accept: application/*+xml;version=20.0
x-vcloud-authorization: 3e131f9e3bc240269a7758fdb6c1bf7f
Content-type: application/vnd.vmware.vcloud.controlAccess+xml

<?xml version="1.0" encoding="UTF-8"?>
<ControlAccessParams xmlns="http://www.vmware.com/vcloud/v1.5">
	<IsSharedToEveryone>false</IsSharedToEveryone>
	<AccessSettings>
		<AccessSetting>
			<Subject href="https://vcloud.fojta.com/api/admin/user/8c1af691-baa9-49db-9bf4-a5ad0562f92b" name="acmeadmintest" type="application/vnd.vmware.admin.user+xml"/>
			<AccessLevel>ReadOnly</AccessLevel>
		</AccessSetting>
	</AccessSettings>
</ControlAccessParams>

Production Org VDC

PUT https://vcloud.fojta.com/api/vdc/47564d52-9204-40b1-b315-a00d59945cfd/action/controlAccess

Accept: application/*+xml;version=20.0
x-vcloud-authorization: 3e131f9e3bc240269a7758fdb6c1bf7f
Content-type: application/vnd.vmware.vcloud.controlAccess+xml

<?xml version="1.0" encoding="UTF-8"?>
<ControlAccessParams xmlns="http://www.vmware.com/vcloud/v1.5">
	<IsSharedToEveryone>false</IsSharedToEveryone>
	<AccessSettings>
		<AccessSetting>
			<Subject href="https://vcloud.fojta.com/api/admin/user/e20edd07-e426-4a72-8f49-718b37685da6" name="acmeadminprod" type="application/vnd.vmware.admin.user+xml"/>
			<AccessLevel>ReadOnly</AccessLevel>
		</AccessSetting>
	</AccessSettings>
</ControlAccessParams>

Now we can log in as each Org VDC Administrator and verify that we see only one Org VDC:

User acmeadminprod can see only Org VDC Production:

User acmeadmintest can see only Org VDC Test:

As both Org VDCs were set as private the Organization Administrator will now have to explicitly enable access for regular users to each Org VDC with the same PUT request. There is maximum of 200 user/group references per Org VDC.

Query Guest OS Customization Status with vCloud API

Very useful new feature of vCloud Director 8.10 is the possibility to query with vCloud API guest OS customization status. Typical use case is when the tenant runs custom orchestration to deploy VM and install and configure application in it. When the VM is powered-on for the first time, the operating system boots up and vCloud Director runs customization scripts to set identity (hostname, SID), networking, administrator password, etc. Read Massimo’s blog for deep dive into guest cutomization.

Tenant’s custom orchestration then needs to wait for the customization to finish and then finally log into the VM and proceed with the application installation and configuration. The problem in the past was that there was no easy way to find out if the guest customization was finished. Not anymore.

With vCloud API you can easily query the vApp VM to get its customization status.

Example:

GET https://vcd-01a.corp.local/api/vApp/vm-22e51563-52a6-4a13-961a-d9dffa6aabf5/guestcustomizationstatus	
	
<?xml version="1.0" encoding="UTF-8"?>
<GuestCustomizationStatusSection xmlns="http://www.vmware.com/vcloud/v1.5" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.vmware.com/vcloud/v1.5 http://vcd-01a.corp.local/api/v1.5/schema/master.xsd">
	    <GuestCustStatus>GC_PENDING</GuestCustStatus>
</GuestCustomizationStatusSection>

The possible guest customization states are:

• GC_PENDING: Guest Customization is either not started or in progress.
• REBOOT_PENDING: Guest Customization is successful, but reboot is pending.
• GC_FAILED: Guest Customization failed, error is logged.
• POST_GC_PENDING: Reboot has happened, waiting for post customization script to complete
• GC_COMPLETE: Guest customization is complete