vCloud Director Fundamentals E-learning Course

VMware released free vCloud Director Fundamentals e-learning course. It is based on the latest vCloud Director v 8.10 and goes into quite a depth in about 3-4 hours.

VCD Fundamentals

Course Outline:

  1. Cloud Computing and VMware vCloud Director – OVerview
  2. VMware vCloud Director Architecture and Components
  3. VMware vCloud Director Installation and Configuration
  4. VMware vCloud Director Administration
  5. Network Administration in VMware vCloud Director
  6. VMware vCloud Director End-User Tasks

Register for the e-learning course here.

Limit Maximum Size of Disk in vCloud Director

Although cloud services are providing access to abstracted seemingly infinite physical resources, the truth is that the physical infrastructure is not limitless. Pooling and distributed resource scheduling for compute, storage and network helps but at the end there is always a physical host, LUN or network uplink which constraints the granularity of scaling.

When it comes to storage it is the datastore size that limits the maximum size of virtual disk a cloud consumer can attach to his/her VM. While thin and fast provisioning and dedupe (NFS/VSAN) can be used to fit more data and storage DRS can shuffle the data around when a particular datastore is filling up at the end the service provider should not allow creation of arbitrary size of vdisks (vSphere maximum is 62 TB) to avoid datastore out of space condition. For example letting customers provision 4 TB thin disks on 3 TB LUNs is just asking for trouble.

Before vCloud Director 8.10 service providers were leveraging blocking tasks with custom orchestration to check if provisioned VM is within provider specified limits (RAM size, vDisk size, max vCPUs). There is reference implementation published here: CPU and Memory Limit enforcement for vCloud Director.

vCloud Director 8.10 brings hidden configuration option where service provider can globally set the maximum allowed size of virtual disk.

The option can be set with cell-management-tool command on a vCloud cell with the following syntax:

$VCLOUD_HOME/bin/cell-management-tool manage-config -n vmlimits.disk.capacity.maxMb -v 1000000

which would set maximum size of disk to 1000000 MB which is 1 TB.

Note: the command is run on one vCloud cell and its impact is immediate (no need to restart anything).

If the tenant tries to provision larger vDisk he will get the following error:

Disk Limit

Note that the limit is not enforced for system administrators and existing disks are not affected.

What should be the limit is out of scope for this post as there are many considerations that should be taken into account:

  • datastore size
  • can datastore grow?
  • thin provisioning
  • fast provisioning
  • tenant snapshots
  • provider snapshots (backup software generated)
  • yellow and red datastore thresholds
  • Storage DRS
  • deduplication on the array

Organization VDC Permissions in vCloud Director

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

Org VDC Admin Role

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.

Users

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</pre>

<?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:

Prod Org VDC

User acmeadmintest can see only Org VDC Test:

Test Org VDC

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

Import Running VM to vCloud Director

Another nice little feature in the recently released vCloud Director 8.10 (read eight dot ten) is the ability to import running VM under vCloud Director management.

In the past the vCloud system administrator could import virtual machine running in vCloud Director managed vSphere environment, however that VM had to be turned off.

Import from vSphere

Now in vCloud DIrector 8.10 the VM can be running which enables new use cases:

  • You can take existing vSphere environment under management of vCloud Director without impacting the workloads. Example would be going from vSphere only managed services to self service with vSphere + vCloud Director
  • Migrations of running VMs from vSphere to vCloud Director or between vCloud Directors. Cross vCenter Server vMotion nicely complements this feature. Cross-Cloud vMotion.

There are currently some limitations and considerations:

  • It is API only feature. The GUI button (above) can be used to import only powered-off VMs.
  • VM must be running on resources that are available to the Org VDC where it is being imported. That includes compute (cluster), storage policies and network port group. Obviously the networking is the most complex to get it right during the migration and requires some thought.
  • Import of VM with IDE controller is not supported.
  • A new vApp is created for the imported VM. You cannot import VM to an existing vApp.
  • As an input to the API call MoRef ID of the VM must be provided. The existing vCloud API call to list vSphere VMs outside of vCloud Director management however does not list running VMs. Therefore the MoRef ID must be acquired with vSphere API.

Example:

POST https://vcd-01a.corp.local/api/admin/extension/vimServer/3702cc8f-c23f-4a66-b9f3-73fc4b58ba82/importVmAsVApp

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


<?xml version="1.0" encoding="UTF-8"?>
<ImportVmAsVAppParams xmlns="http://www.vmware.com/vcloud/extension/v1.5" name="ImportedTestVM" sourceMove="true">
   <VmMoRef>vm-86</VmMoRef>
   <Vdc href="https://vcd-01a.corp.local/api/vdc/a10bdf92-18dc-474b-aafc-42d31ba83207" />
</ImportVmAsVAppParams>