How to Export Running VM from vCloud Director

In the past I have wrote how to import running VM to vCloud Director: here and here. Today, I will describe how to export running VM.

Let us first discuss why you would do it. There are several use cases:

  • you want to manage the VM by a different Cloud Management Platform (for example vRealize Automation)
  • you want to migrate (utilizing cross VC vMotion) to a different vCloud Director
  • you want to move the VM to a different Org VDC

Currently (as of vCloud Director 8.20) there is no direct way to export running VM. So the procedure I will describe below is kind of a workaround. But let me first describe, what it means for a VM to be managed by vCloud Director.

  • VM is ‘marked’ at vSphere level with Custom Attributes and ManagedBy extension.
  • VM has its cloud_uuid stored in its configuration parameters
  • VM has assigned CPU/RAM reservations and limits depending on its Org VDC allocation model
  • VM is running in resource pool and folder based on its Org VDC/vApp
  • VM has a name that includes its UUID
  • vCloud Director is tracking the VM in vSphere inventory even if it changes its name, location and MoRef ID.
  • vCloud Director is reserving VMs IP and MAC addresses in its IPAM.
  • vCloud Director is counting VMs resources to its Org VDC allocation.

In order to remove the VM from vCloud Director management we must take care of all these points.

Here comes the procedure I came up with. It can obviously be automated with vSphere and vCloud APIs if needed for export of large amount of VMs.

First we clean up VM at vSphere level in vCenter Server:

  1. Move VM outside the vCloud Director managed Resource Pool (this is to avoid auto-import of the VM)
  2. If necessary reconnect VM to network not managed by vCloud Director (this is for situations where the vApp or Org VDC network is going to be deleted later). Obviously as the VM is running, the new network should provide equivalent connectivity as the original one (either with L2 bridging or routing).
  3. Remove cloud-uuid from the VM configuration parameters. This can be done on running VM with PowerCLI:
    (Get-AdvancedSetting -entity $vm -Name cloud.uuid)|Remove-AdvancedSetting
  4. Remove vCloud Director related Custom Attribute values (in my case VCD_fojta_01). Do not remove the whole Custom Attribute, just the value.
  5. Remove ManagedBy extension from the VM. The easiest to do is leveraging PowerCLI script attached to KB 2032366. You will see the VM icon has changed after the extension has been removed.
    \ManagedBy.ps1 -Cmd Clear -VMs $vm
  6. Remove VM resource reservation and limits (if applicable).
  7. Rename VM (to get rid of UUID in the name).
    Now we need to take care of removing VM in vCloud Director, however even though we removed its cloud-uuid vCloud Director still sees the VM through its vCenter MoRef ID. And we cannot change MoRef ID of running VM. So here comes the workaround:
  8. Temporarily remove access to the VM for vCloud Director service account (account configured in vCloud Director for the particular vCenter Server). To do so, you assign No Access role permission on the VM object for the service account user.
  9. Now the VM has become invisible for vCloud Director and we can clean it up in vCloud Director. First Force-Stop its vApp.
  10. Now Delete the vApp. Ignore the error.
  11. Purge the vApp from stranded items with Force Delete.
  12. Now we can remove the temporary no access role permission from step #8.
  13. Clean up the vApp folder in vCenter Server if it was not removed.

Quite lengthy and not pretty procedure, however we did not do anything unsupported (like editing vCloud database) and the VM has been properly removed from vCloud Director inventory.

Last comment is about VM MAC addresses. If the VM was created in vCloud Director it will have MAC addresses from the vCloud Director range based on VCD installation ID. Have that in mind when moving VM around as duplicate MACs could be generated.

What’s New in Chargeback Manager 2.7.3

In March 2017 VMware released vCenter Chargeback Manager 2.7.3. The main reason why to upgrade to the new release is that it adds full support for vCloud Director 8.20.

So what is new? From the security standpoint TLS 1.2 is now supported and also Java and Tomcat are updated with the latest security patches. There is a new way of collection of network resources consumption. It the pre-8.20 releases of vCloud Director, the configuration of network services was stored in vCloud Director audit table and available via vCloud API used by Chargeback Cloud collector. Chargeback vShield collector was used only for collection of external network transfer using vShield API against vCNS/NSX Manager.

When advanced networking services are configured in vCloud Director 8.20, these changes are no longer tracked by vCloud Director audit table. Chargeback thus relies on NSX API to collect the status of the services. This also means, that if these services are enabled directly in NSX, Chargeback will track them.

The following networking services are tracked by Chargeback:

New networking services:

  • Dynamic routing (OSPF/BGP)
  • L2 VPN
  • SSL VPN
  • Distributed firewall (enabled at Org VDC level)

Legacy networking services:

  • DHCP
  • Edge Firewall
  • Edge Gateway High Availability
  • NAT
  • Static routing
  • Enabled IPSec VPN Tunnel Count
  • Load Balancer

Metering of external networks is unchanged.

Client Integration Plugin, vCloud Director and Compatible Browsers

Just a quick post to recap my experience with usage of Client Integration Plugin in vCloud Director and its compatibility with current browsers.

Client Integration Plugin (CIP) is needed in vCloud Director 8.20 only for import and export of templates and media images. It is not bundled in vCloud Director binaries anymore, instead the user is redirected to KB article with downloads for particular browser/OS combination.

If you downloaded CIP and you still cannot get through to the catalog download/upload dialog, here are some steps to try:

  • Cleanup your installed Client Integration plugins. Reboot your PC and install the one you need.
  • Google Chrome seems to be working the best. It requires CIP version 5.6 as opposed to the other browser that need version 6.2.
  • The newest Mozilla Firefox needs a tweak. Open URL: about:config and accept loss of warranty ;-). Create new boolean type row by right-clicking in an empty space, name it  plugin.load_flash_only and assign value false. Reopen Firefox.
  • Alternatively, you can download ESR release of Firefox which works out of the box from here.
  • For Internet Explorer 11 you need to enable compatibility mode and add vCloud Director URL to the trusted sites.
  • While Edge browser is supported for vCloud Director, it does not support any plugins and will not work with CIP.

Note: VMware is working hard on removing these limitations in the future releases.

Architecting a VMware vCloud Availability for vCloud Director Solution

Another vCloud Architecture Toolkit whitepaper that I authored was published on the vCAT SP website – it discusses how to architect vCloud Availability solution in large production scenarios.

It is based on real live deployments and includes the following chapters:

 

 

 

  • Introduction
  • Use Cases
    • Disaster Recovery
    • Migration
  • vCloud Availability Architecture Design Overview
    • vCloud Availability Architecture
    • Network Flows
    • Conceptual Architecture
  • vCloud Availability Management Components
    • Logical Architecture
    • vCloud Availability Portal
    • Cloud Proxy
    • RabbitMQ
    • Cassandra Database
    • VMware Platform Services Controller
    • vSphere Replication Cloud Service
    • vSphere Replication Manager
    • vSphere Replication Servers
    • ESXi Hosts
    • vCloud Availability Metering
    • vRealize Orchestrator
    • Management Component Resiliency Considerations
  • vCloud Director Configuration
    • User Roles
    • Tenant Limits and Leases
    • Organization Virtual Data Center
    • Network Management
    • Storage Management
    • vApps and Virtual Machines
  • Billing
  • vRealize Orchestrator Configuration
    • On-Premises Deployment
    • In-the-Cloud Deployment
    • Provider Deployment
    • Failover Orchestration
  • Monitoring
    • Component Monitoring
    • VM Replication Monitoring
    • Backup Strategy
  • Appendix A – Port Requirements / Firewall Rules
  • Appendix B – Glossary
  • Appendix C – Maximums
  • Appendix D – Reference Documents
  • Appendix E – Tenant API Structure
  • Appendix F – Undocumented HybridSettings vCloud API
  • Appendix G – Monitoring

Download from the vCAT-SP website: https://www.vmware.com/solutions/cloud-computing/vcat-sp.html or direct link to pdf.

vCloud Director 8.20: Granular Role Based Access Control

vCloud Director 8.20 introduces the possibility to create granular roles at tenant and system level. This is important for service providers who want to differentiate which tenants have access to specific features (for example advanced networking services). This also gives opportunity to tenants to create their own roles that correspond to their team structure (e.g. network administrator). And lastly, system administrator can create additional roles in system context with access to subset of features.

A role is a set of rights which can be assigned to a user or a group. There are many new rights in vCloud Director 8.20. A few examples:

Access to Distributed Firewall:

  • Enable / Disable Distributed Firewall

Gateway Advanced Services

  • Configure IPSEC VPN
  • Configure Load Balancer
  • Configure BGP Routing
  • Configure OSPF Routing
  • Configure SSL VPN
  • Configure Firewall
  • Configure DHCP
  • Configure NAT
  • Configure L2 VPN
  • Configure Static Routing

Or system level rights like:

Host

  • Upgrade Host
  • Repair Host
  • Migrate Host VMs
  • Open a Host in vSphere
  • Enable / Disable a Host
  • Prepare / Unprepare a Host
  • View Host

Prior vCloud Director 8.20

  • Only global roles could be created by system administrator next to handful of predefined roles (vApp Author, Organization Administrator, …).
  • Every organization would have access to the global and predefined roles.
  • Organization administrator could assign the roles to organization users.
  • Service provider could not differentiate access to features among different tenants.
  • There was only one system administrator role with access to everything.

vCloud Director 8.20

  • Roles are no longer global, but instead are organization specific.
  • Former global and predefined roles become role templates.
  • Service provider can create new role templates.
  • Role templates are used to instantiate organization specific roles.
  • Service provider can selectively grant rights to specific organizations.
  • Organization administrator can create own organization specific roles from subset of granted rights.
  • New roles can be created in the system context from subset of system administrator rights.

The transition from pre-vCloud Director 8.20 role management happens during upgrade to 8.20. Existing roles are transferred to role templates and each organization gets its own roles instantiation based on the role templates. The UI has changed and now includes Organization column and filter. A new System organization is added with default System Administrator role.

vCloud Director 8.10 UI
vCloud Director 8.20 UI

Tenant Rights and Role Management

When a new organization is created it will have access to all rights that are used in role templates. System administrator can grant additional rights to the organization with vCloud API only:

GET /api/admin … get references to all rights in VCD instance

GET /api/admin/org/<org-id>/rights … get references to all rights in the organization

PUT /api/admin/org/<org-id>/rights edit rights in the organization

System administrator or Organization Administrator can create new roles in its organization with vCloud API only:

POST /admin/org/<org-id>/roles

Note: While system administrator can edit tenant roles in the UI, editing of a role based on role template would change the role template and thus change it for all organizations (more below).

How to Create Global Role

The UI no longer allows creation of global roles, only organization specific roles can be created that way.

However, there is a way to create global role (actually role template) with the legacy API (e.g. version 9.0, 20.0 but not 27.0). Here is an example:

POST /api/admin/roles
Header:
Accept: application/*;version=9.0
Content-Type: application/vnd.vmware.admin.role+xml

Body:

<?xml version="1.0" encoding="UTF-8"?>
<Role xmlns="http://www.vmware.com/vcloud/v1.5" name="New Global Role">
	<Description>My new global role</Description>
	<RightReferences>
		<RightReference href="https://vcloud.fojta.com/api/admin/right/0b8c8cd2-5af9-32ad-a0bd-dc356503a552" name="General: Administrator View" type="application/vnd.vmware.admin.right+xml"/>
		<RightReference href="https://vcloud.fojta.com/api/admin/right/5e579955-fe9d-3f0b-bc6b-a3da4db328f1" name="Group / User: View" type="application/vnd.vmware.admin.right+xml"/>
		<RightReference href="https://vcloud.fojta.com/api/admin/right/2cd2d9d7-262c-34f8-8bee-fd92f422cc2c" name="General: Administrator Control" type="application/vnd.vmware.admin.right+xml"/>
	</RightReferences>
</Role>

Note: Using above API call with API version 27.0 would create the role in the system organization.

How to Edit Global Roles?

Again with legacy vCloud API we can list all global (template) and system organization roles:

GET /api/admin
Header:
Accept: application/*;version=9.0
Response:
<RoleReferences>
	...
	<RoleReference href="https://vcloud.fojta.com/api/admin/role/75717adf-8700-419e-afe1-d5e2ea3b0bd6" name="User Admin" type="application/vnd.vmware.admin.role+xml"/>
	...
</RoleReferences>

After finding the right role reference we can delete the role template with the following call:

DELETE /api/admin/role/<role-id>
Header:
Accept: application/*;version=9.0

Addition and removal of rights from a role template:

  • In UI add/remove the right from the role which is based on role template from any organization.
  • To add a new right, the organization needs to have access to the right. If it does not have, add it first with the API calls mentioned above.
  • Adding or removing rights to a role based on role template will affect all other organizations.
    • Adding right: other organizations will see the new right if their instance of role template has been granted the right. If the organization did not have access to the right, the right will not be added!
    • Removing right: in other organizations the right will be removed from the role based on the role template

 

The post was written with kind support of John Kilroy.