vCloud Director not reporting CPU Utilization

I came across a customer site recently where their vCloud Director (vCD) 5.1 implementation was not reporting CPU utilization for Organisation Virtual Datacenters (Org VDCs). RAM and storage allocation was fine, just CPU was not showing a usage bar, and the mouse over tip reported 0% allocated.

Turns out this is a known issue with vCloud Director 5.1, and VMware have released KB 2054043 relating to this issue. Their advice (via the KB) is to:

  1. Upgrade vCloud Director to version 5.1.2 or later.
  2. Enable Elastic Allocation Pool mode for vCloud Director. To do this:
    1. Login to vCD as a System Administrator user.
    2. Navigate to Home > Administration > General.
    3. Unter the Miscellaneous section, check the box next to ‘Make Allocation pool Org VDCs elastic’.
    4. Click Apply to confirm the setting.

It may take a few minutes for the Org VDCs to update their utilisation settings for vCD, but soon after application of this settings, the CPU should report in the Org VDC > Monitor view along with RAM and storage allocation.

Note: Although the KB from VMware specifically mentions this for vCloud Director 5.1.x, this also affects vCD v5.5.x as well – so those using newer vCD versions may still need to apply the elastic setting for CPU to be reported.

vCAC 6.0.1, Inaccessible Tenants, and Missing Identity Stores

With vCAC 6.0.x, there is a bug in the SSO appliance where several symptoms present all at the same time:

  • Authentication to AD or LDAP identity stores fails, returning the user to the blank authentication screen.
  • When logged-in to the default tenant as administrator (usually ‘administrator@vsphere.local’), accessing tenant identity stores results in a ‘System Exception’ error.
  • Tenant Admins cannot add or edit identity stores.

This is a documented bug, as listed in VMware KB Article 2075011, and at the time of writing there is a workaround.

The issue as documented is the administrator account in the default tenant expires 90 days after implementation of the appliance. I came across this issue, and was for a while not understanding the syntax of the commands required to complete the workaround. So, here are the steps in minutia that should work for others implementing this same fix.

Note: Whatever is in highlighted code needs to be typed as single entry lines, with a return at the end to complete the command entry.

1. SSH to the SSO server IP address. Authenticate as the SSO Root User.

2. Reset the account control flag by issuing the following commands:

/opt/likewise/bin/ldapmodify -H ldap://localhost:389 -x -D “cn=administrator,cn=users,dc=vsphere,dc=local” -W <<EOF

When typing this command, you are not returned to the usual root prompt, but rather to a simple ‘>’ prompt. This is what stumped me for a bit….. At that prompt, enter the following commands. (Note: replace tenant_name instances in the commands below with the name of your own tenant).

dn: cn=tenantadmin,cn=users,dc=tenant_name

At the > prompt, enter:

changetype: modify

At the > prompt, enter:

replace: userAccountControl

At the > prompt, enter:

userAccountControl: 0

At the > prompt, enter:

EOF

You will be prompted for LDAP password. Enter the password for the default tenant administrator (usually ‘administrator@vsphere.local’).

Once authenticated, the message ‘Response: modifying entry “cn=administrator,cn=users,dc=tenant_name.”‘ is displayed, and the command prompt returns to the usual prompt.

3. Disable password expiration

by issuing the following commands:

/opt/likewise/bin/ldapmodify -H ldap://localhost:389 -x -D “cn=administrator,cn=users,dc=vsphere,dc=local” -W <<EOF

When typing this command, you are not returned to the usual root prompt, but rather to a simple ‘>’ prompt. This is what stumped me for a bit….. At that prompt, enter the following commands:

dn: cn=DCAdmins,cn=builtin,dc=vsphere,dc=local

At the > prompt, enter:

changetype: modify

At the > prompt, enter:

add: member

At the > prompt, enter:

member: cn=administrator,cn=users,dc=tenant_name

At the > prompt, enter:

EOF

You will be prompted for LDAP password. Enter the password for the default tenant administrator (usually ‘administrator@vsphere.local’).

Once authenticated, the message ‘Response: modifying entry “cn=DCAdmins,cn=builtin,dc=vsphere,dc=local”‘ is displayed, and the command prompt returns to the usual prompt.

4. Retry vCAC login to either the default or user tenants – the problem should be resolved and the login should work as normal.

Public Catalog Access for vApp Authors fails post-v5.5.1 Upgrade

vAppAuthorThis one stumped me for a little bit.

The private cloud in my lab is fairly simple in layout – 2 RHEL cells with a vCNS load balancer, shared NFS server and DB server. The Organisations are provisioned such that of the 3 tenants, one is a master tenant that is only used for creating and maintaining vApp templates, via a Public Catalog for sharing the templates for cloud provisioning and vCAC blueprint testing.

Running this configuration in with no changes to the default vCloud Director (vCD) roles worked fine – delegated LDAP users in the 2 user organisations were able to select vApp templates from the Public Catalog and deploy them locally. All good.

The issue came when the cells for vCD were upgraded to the latest v5.5.1 build. All of a sudden – vApp Author users out of the box could not see the public catalog despite having the role description ‘Rights given to a user who uses catalogs and creates vApps’.

After much digging and testing, I found that during the upgrade, the default permissions for the pre-defined roles in vCD had changed. Prior to the 5.5.1 update, the specific permission ‘View Shared Catalogs from Other Organisations’ was checked by default, so users with this role had this permission by default. Post-5.5.1 upgrade, this had been removed.

Solution. Simple enough – log in to the vCD instance as a System Administrator user, select ‘Administration > Roles’. Edit the vApp Author role, and open ‘All Rights > Catalog’. Check the box next to: ‘View Shared Catalogs from Other Organisations’. Click OK and return to vCD.

All the assigned users who have this permission will be updated in global fashion, but those already logged-in to the vCD portal may need to re-authenticate to obtain the new permission settings.

South West UK VMUG (3rd June 2014)

I think it’s safe to say that the first South West VMUG back in February was very successful. Our next one will be held at the same venue (Bristol’s mShed) on June 3rd 2014.

We’ve got some good sessions lined up and we’d love to have as many of you along as possible. So, if you’d like a day of discussion and learning with lots of people from the virtualisation community, then please sign up via the VMUG site.

Session Times Session Description
10:30:00 11:00:00    Registration / Coffee
11:00:00 11:15:00 Welcome and Introduction
11:15:00 12:00:00 VMware Session on vCAC
12:00:00 12:45:00 Nimble Storage (Nick Dyer)
12:45:00 13:30:00    Lunch / Vendor Area
13:30:00 14:15:00 vCD Experience (Julian Regal – Capita)
14:15:00 15:00:00 Troubleshooting Panel
15:00:00 15:15:00    Tea / Coffee
15:15:00 16:00:00 PowerCLI / Automation (Jonathan Medd)
16:00:00 16:45:00 PernixData (James Smith)
16:45:00 17:00:00 Close

Afterwards we’ll be de-camping across the other side of the dock at the Pitcher & Piano for some vBeers (kindly sponsored by PernixData):

vBeers at the Pitcher & Piano

vCAC 5.2.1 Released

I missed this on Thursday. It slipped out quite quietly. However, VMware have now released version 5.2.1 of vCloud Automation Center.

Possibly the best way to view this release is as an update-rollup as it includes features and fixes introduced in each of the following Hotfixes to 5.2:

Also included are a few changes that seem to me to be aimed at closing a few gaps between 5.2 and 6.0.

As far as upgrades go, the upgrade path seems to be from 5.2 only or 5.2.1 can be installed from scratch. There are a couple of installation / upgrade gotchas to be aware of so it’s worth reading the release notes before planning an upgrade. I’ll be giving it a try in the next few days.

It’s not 100% clear if this will be the final release for vCAC in the 5.x branch. I’m thinking that it will very much depend on when VMware release a version of 6.x that supports upgrades from 5.x.