Not in a deep way; in response to people worried about administrative control policies. Here's how it works now: A Virtual Data Center contains a collection of VM templates, a collection of available public IP addresses, and a single Cluster resource. A Cluster resource contains, along with some actuator URIs, a collection of private networks, a collection of virtual machines, and zero or more child clusters. The idea is that the general-purpose Cluster grouping resource now acts just like a nested filesystem. Private networks belong to clusters, but only for administrative purposes; they can be attached to any VM in any cluster. (What's changed? Previously, clusters didn't nest and private- networks were allocated at the VDC level). The motivation is, we hear from people, especially private-cloud people, that they want to hand out authorization rights to control particular sets of VMs and private-networks, but not others. It wasn't obvious how you'd go about doing this. So now everything that you might reasonably want to control/administer has a primary association to a Cluster object, making that the obvious hook to attach administrative-rights policies. (If people don't want these FYI posts about parallel work in another API-building effort, say so and I'll shut up). -Tim