vCD – Q & A – Part 1

There has been a lot of Q&A sessions and emails flying around VMware over the past few months, so I thought I would post some up for people to read, and hopefully help answer some of the questions you may have.

vCloud Director: Installation ID

Q. During the installation of vCD, there is an optional step that says “If more than one installation of vShield Manager is connected to this network, select a unique installation ID for the vShield Manager configured to work with this Cloud Director installation using the Installation ID control.” What is the significance of this installation ID?

A. A single installation ID applies to a vCloud Director instance, even one with multiple vCenter Servers and their associated (multiple) vShield Managers.

A vCD installation ID is used to ensure network addressing uniqueness and network traffic separation between distinct vCD instances that happen to utilize the same L2 network. When vCD generates an Ethernet addresses for use by vNICs, it uses the installation ID as one octet of the MACs generated. vCD also uses the installation ID in its network isolation protocol (that backs the VCD-NI network pool).  As you can imagine, this use of the installation ID is independent of vCenters, VSMs or the number of their instances registered with a vCD instance. This ensures that different vCD instances on the same network won’t collide in particular by generating unique MAC addresses.

vCloud Director: Deploying from a Catalog—Does it matter where the vApp resides and goes?

Q. Can a template from a published catalog residing in one org vDC backed by one vCenter Server be deployed to a different org vDC backed by a second vCenter Server?

A. Yes. vCloud Director will automatically export and import the template from the vCenter Servers as needed. The source catalog/template’s org vDC and the destination org vDC need not have visibility to the same datastores when deploying templates.

vCloud Director: Which datastores are used when creating a VM?

Q. If an org vDC has multiple datastores, which one does vCD use when creating a VM?
A. vCD uses the datastore with the most free space at the time of VM creation. This algorithm round-robins and tries to fill up all datastores equally in sequence.

vCloud Director: Organizations

Q. Can an organization span vSphere clusters?
A. Yes, if an organization has access to multiple org vDCs, each mapped to a cluster. An org vDC cannot span a cluster.  An Org vDC is mapped back to a provider VDC, and each provider vDC in vCD 1.0 can have at most one resource pool backing it. (An organization is nothing but a collection of users, policies, catalogs, and org VDCs.)

vCloud Director: Moving a vApp

Q. Is it possible for a user to move a vApp between two org vDCs in an organization?

A. Yes. It’s simply an export and import operation at the vCD level so it will even work across vCenters.

vApp Deployment Error Caused by Unlicensed vShield Edge

Q. I get the following error when attempting to power on a vApp:
Internal Server Error
·         Unable to start vApp “vShield Test”.
·         Unable to start virtual machines in resource pool “0125119915-TestOrgVDC”.
·         Error creating Shield network appliance.vClould-Shield edge error: Creating/configuring the VR failed: vsmHandle.initializeEdge() net:838660745/network-28778 vse:vm-28851 VSM IP:10.91.160.173  failed.HTTP/1.1 403 Forbidden – The user does not have permission to perform this operation.

A. The operation requires a license for vShield Edge. You have to assign this in the vSphere Client. You have to perform this step on top of adding the license through vShield Manager.

vCloud Cell Failover in a Multi-Cell Environment

Q. What happens if a vCloud Cell fails?

A. This is how vCloud Director detects cell failures:
·         Every cell issues a heartbeat to the vCloud database every 30 seconds.
·         One of the cells in vCloud Director checks the health of all cells every 60 seconds. It does the following:
o   If any cell doesn’t have a heartbeat for > 5 minutes, it marks the cell as dead (failed). Thus, it may take about 5 minutes for vCloud Director to detect a cell failure.
o   The database server time is used to compare any time difference.
·         Every cell also has a local failure detection policy which kicks in every X minutes (X < 5 minutes, currently X = 4.5 minutes) and checks if the current cell has successfully written its heartbeat. If it hasn’t, it puts the cell in some form of “lockdown” mode where the cell will discard all incoming requests, vCenter API calls and writes to the database. This is done to prevent accidental data corruption as this particular cell (if it has lost network vonnectivity) is not visible to the rest of the cluster and it may be declared as failed.
·         When the cell is brought back up, it registers itself back by getting a new token and starts running a new heartbeat.

There is a URL that is available and should be used by the Load Balancer to check the health of the cell – https://<host>/cloud/server_status
As of the 1.0 release, vCloud Director tasks are not recoverable. So if a cell fails for whatever reason, all tasks executing on that cell will be marked as failed. This may leave behind some stranded objects in vCenter. However, if no tasks are running on the cell that failed and it is only the vCenter proxy that got affected, these tasks should eventually succeed when the vCenter Proxy service is failed over. The failover has to happen within a 20 minute window; otherwise, the tasks will be marked as TimedOut provided the corresponding vCenter is still up and running.

Load Balancing for Multiple vCD Cells

Q. Can vShield Edge be used as a load balancer for vCD Cells?

A. No vShield Edge 1.0 (the fully licensed one) supports HTTP load balancing, but vCD Cells need HTTPS load balancing.

vCloud Director: Creating Provider vDCs

Q. When creating a provider vDC, should you map to a cluster or resource pool?

A. For simplicity, we recommend mapping to a cluster directly so that a provider vDC has full access to all the resources in the cluster. This avoids possible contention with another resource pool at the same level (what if they were accidentally created to have expandable reservations, for example?).

When creating a Provider vDC, a Cluster or Resource Pool must be selected, this means the Resource Pool must be manually configured before creating and mapping the Provider vDC to the Resource Pool. During the creation of this Resource pool, the admin must specify the resource allocation settings. The Reservation, Shares and Limit settings of a Resource Pool are not changed dynamically when adding additional ESX hosts to the cluster. The admin must change (increase) the reservation and Limit setting each time new hosts are added to the cluster. There is also the issue of share allocations becoming unbalanced if/when you end up with an unbalanced number of powered on vCPUs between resource pools.

The second drawback of the Resource Pool model is sizing. Because multiple Provider vDC Resource Pools will exists beneath the Root Resource Pool (Cluster) level the admin/architect needs to calculate a proper resource allocation ratio for the existing Provider vDCs. Mapping a Provider vDC to a Resource Pool will require manual recalculation of the resource allocation settings each time a new tenant is introduced and when the new Org vDC joins the Provider vDC.