With contributions from our esteemed colleagues:

Tomas Fojta, Michael Haines, Ray Budavari, Scott Harrison, Francois Misiak, Adrian Roberts, Raghvender Arni, Les Major, Jesse Schachter, Jagan Raghu

This months topics include:

• vCloud Director and Alternative Authentication
• vCloud Director and Keystores for Certificates
• vCloud Director Transfer Areas size in the Appliance edition
• vCloud Director and configuring MS-SQL Clusters
• vCloud Director – SDRS and Media files in the catalog
• vCloud Director – Removing the *ANY* Storage Profile
• vCNS – Edge Gateway limits and scalability options
• vCNS – Pinging the Edge Gateway
• vCloud Connector – Modifying the schedule for updates (Unsupported)

 

Enjoy!

vCloud Director and Alternate Authentication

Backstory:

vCloud Director 5.1 introduced support for the vCenter 5.1 Single-Sign-On service. It added a “Federation” option that allows you add SSO as a source for authentication – along side native support for Active Director and LDAP generally.

Q. Does vCloud Director v5.1.x work with Horizon?

A. vCloud Director 5.1 supports Horizon Workspace authentication for vCloud Organizations. See the whitepaper, Using VMware Horizon Workspace to Enable SSO in VMware vCloud Director 5.1.

vCloud Director and Certificate Keystores

Backstory:

The install of vCloud Director requires two certificates held in the certificates.ks store.  One is used to secure the connection to the vCloud Director administration portal, and the second one is used for any secured connection to a virtual machine – through what is referred to as the “Console Proxy”. In a publically accessible vCloud Director both FQDN would be registered in DNS, and you would configure the “Public Addresses” to match these FQDN. So that although the internal names of the vCloud Director servers (or cells) might be vcdcell01.corp.com and vcdcell02.corp.com – they would resolve to a load-balanced IP address to an FQDN like https://mycloud.corp.com.

When you setup a multiple vCloud Director servers the .bin installation can locate these certificates from the first instance you created, so there’s no need create certificates for every vCloud Director server you setup and install.

Q. After installing vCD, where can I find the certificate keystores?

A. If you are looking for the keystore file after the installation, then the installer saves this information to the /opt/vmware/vcloud-director/etc/responses.properties file (so it can be used as an input in a multi-cell deployment). Look for the user.keystore.path entry.

Alternatively, you can find it using the command:

find / -iname certificates.ks

Note: The keystore name of “certificates.ks” is merely a convention that you will see used in all our documentation. As such its just a convention and you may find that the name used for the keystore varies in your implementation.

It’s perhaps worth mention some best practices around the securing of your PKI infrastructure files. For example it wouldn’t be wise to store the files used to complete the request process in a user directory, but hold them in generic location available to those who need rights to manage them. Many of the ancillary files generate during the certificate request phase aren’t need on the vCloud Director cell once they have been imported into the keystore. So backing them and setting passwords on private keys generated is good way of making sure that wrong people don’t end up owning your certificates infrastructure.

vCloud Director Appliance Transfer Directory Size

Backstory:

The “transfer directory” is a staging array primarily used for uploading OVFs and media (.ISO/flp) files.  When you install vCloud Director you are asked to specify the shared directory location for this storage. It is recommended that you allocate a chunk of storage external to this. In my case I used my NetApp and its NFS storage to mount these storage to vCloud Director. The appliance is not designed (or supported) for production environments and its intended a taster, demo or homelab use.  As a result, it doesn’t support multi-cell.

Q. What is the default transfer directory size for the vCD 5.1 appliance?

A. The space for transfer area is around 21GB. It’s held on the / partition which is allocated 28GB of which about 5.8GB is used leaving 21GB in size.  The transfer location is located at /opt/vmware/vcloud-director/data/transfer

vCloud Director: MS SQL Server Cluster in vApp

Backstory:

VMware has support clustering technologies inside the VM all the way back to ESX 2.x. From ESX 2.5 onwards the recommendation back then was to use “Raw Device Mappings” (RDMs) to point to the shared and quorum volumes that make up a Microsoft Cluster.  Due to this history MSCS and RDM’s have had close relationship, although many of the original requirements – such as the support requirements to have the boot disks of the cluster on local storage were removed long ago. The important thing to remember with vCloud Director is that RDMs are not supported

Q. I am trying to cluster MS SQL Server across 2 VMs in a vApp in vCD. Will this work?

A. Yes, but its recommended to use in-guest software iSCSI initiators supported by Microsoft.

vCloud Director: Copying vApps Across Catalogs

Backstory:

Each Organization with vCloud Director has a catalog for holding vApp Template and any other media the tenants require. These catalogs can be shared with people within the organization and they can also be “published” to every organization in the vCloud Director. This publishing is often done to make a standard collection of different builds available to every tenant. Often vCloud Director administrators create an “empty” organization with a published catalog purely for this purpose.

Q. Is it possible to copy a vApp from a private to a public catalog?

A. No, you can copy only from a public catalog to a private catalog, not the other way. As a workaround, you can give the org temporary catalog publishing privileges, make the private catalog public and then from the other org (which owns the genuine public catalog) initiate the copy. Of course, another option would be a more mundane download of the vApp to an OVF file in the private catalog, followed by uploading the OVF file to the public catalog – if this something that happens frequently

vCloud Director: Deploying Red Hat Enterprise Linux and Network Issues

Backstory:

Despite every attempt to standardize the deployment of VMs and guest operating systems within – differences and defaults with the GOS can and do result in unexpected outcomes – not least with Linux distributions.

Q. In vCD, when I deploy a RHEL template with a single vNIC, I receive a network interface name of eth1 or 2 or 3 and not eth0. Is this correct?

A. This is a known bug with RHEL. To fix this, go into the file /etc/udev/rules.d/70-persistant-net.rules which creates your ethX (Interfaces). RHEL always appends an entry to this file with a new MAC address. As a workaround, before you turn a VM into a template in vCD, delete all entries from that file, and delete all /etc/sysconfig/network-scripts/ifcfg-ethX files.

Q. When using vCD and RHEL customization, when RHEL is configured to use Network Manager it does not set the DNS entries in the /etc/resolv.conf file. How do I work around this?

A. Disable network manager and perform re-customization. Use the command:

ntsysv < remove tick from network manager service.

Then Shutdown and power on the VM with force re-customization option through vCD.

SDRS and vCloud Director Media

Backstory:

vCloud Director 5.1 introduced support for Storage DRS. Storage DRS supports a maintenance mode which much like maintenance mode for compute DRS can trigger the evacuation of datastores.

Q. I have all my vCD media stored in a datastore with Storage DRS enabled. When I placed the datastore in maintenance mode, all VMs got migrated off but the media files remained. Is this to be expected?

A. Yes. Media files are objects unknown to vSphere infrastructure, so SDRS maintenance mode cannot migrate them.

vCloud Director: Moving Out of the *(Any) Storage Profile

Backstory:

vCloud Director 5.1 introduced support for Storage Profiles – which allow you to classify your storage into different tiers or classes. The Storage Profiles are defined in the vSphere layer, and then are accessible from vCloud Director.

There is one Storage Profile that you will see within vCloud Director that you will not see or have to create within vSphere.  This is the ‘Any’ storage profile.  The ‘Any’ storage profile is a pseudo storage profile that refers to any available storage, including local attached storage.  This can be helpful in the event that you have ESX hosts that are not licensed to use Storage Profiles or if you have a older ESX host that does not support Storage Profiles.

Q. Can I move a vCD object out of the *(any) storage profile? For example, I noticed the Edge Gateway devices get placed there by default?

A. You can reconfigure vCD to stop using the *(any) storage profile using KB2045534.

vCNS 5.1 Edge Limits

Backstory:

When you define an Organization – you get the option to deploy an Edge Gateway at the same time. The Edge Gateway can be deployed into different sizes – by default vCloud Director offers “Compact” and “Full”.

Once deployed it can be upgraded from “compact” to “full” (but it cannot be downgraded). By right-clicking the Edge Gateway and selecting “Upgrade to Full Configuration”

If on the other hand you are using vCNS directly from vSphere, without vCloud Director – a right-click on vShield Manager allows you to change the size of the Edge Gateway from the “Actions” menu.

 

IMPORTANT: Technically, X-Large isn’t supported by vCloud Director just “compact” and “large”. I’m just showing this graphic here to be complete.

Q. What are the limits for vCNS 5.1 Edge devices? For example, maximum throughput based on Edge size (compact, large, X-large)?

A. The KB article KB2042799, vCloud Networking and Security 5.1 Edge configuration limits and throughput. There are two comparison tables in this KB that will give you an idea of the differences in terms of throughput:

vCNS Edge Ping

BackStory:

When an Organization or vApp Network is created there’s a good chance you will be using the vCNS Edge Gateway to keep the vApp(s) network configuration unique. The VMs within that network are likely to get their IP address from either DHCP range or from Static Pool of IP Addresses assigned to that pool. This IP assignment will include the “Default Gateway” address that is the “internal” interface of their respective Edge Gateway. Despite being on the same network, and internal – the Edge Gateway does not respond to pings.

Q. Does an Edge device respond when pinged?

A. Only if you create a rule for ICMP in the firewall settings. This is not on by default.

vCloud Connector: Scheduling Content Sync

Q. It appears that the synching of templates using the Content Sync feature in vCC takes place every 6 hours. Is this schedulable?

A. No. The scheduler feature is a good one and we didn’t get around to implementing it for vCC 2.0. The default polling interval for synchronization is 6 hours. It can be changed, but the change is unsupported—to do this, edit the file on the vCC Server:

/usr/local/tcserver/vfabric-tc-server-standard/server/webapps/agent/WEB-INF/spring/appServlet/task.xml

Look for <property name=”jobExecutionIntervalInMinutes” value=”360″ />. After the change, restart the server.