vCloud Design Patterns Weds 10:30

- Packed session - mostly architects in the audience.
- vCloud Director is several integrated products aimed at bridging private and public clouds - you may need further 3rd party tools until VMware plug any gaps.
- Virtualization of the infrastructure continues to be the basis - vCloud is an additional layer - aim is for consumer not to know what's going on "under the hood"
- vCloud Director includes the vCloud API
- vCenter Chargeback and vShield Edge (virtual appliance) and Manager (one per vCenter) are critical components to bring protection and billing
- vRequest Manager brings the workflow piece
- One vCloud Director database supports multiple vCloud Director instances
- vCloud Director needs Oracle which, due to licencing, may exclude the use of a VM for vCloud Director!
- Best practice is to separate the management of clusters of resources from vCloud reource management
- Create your VM clusters based on service qualities.  Create VDCs around consumer organisations.  So a VDC may use resources from across the VM clusters
- The VM clusters have networks to external resources, organisations have networks and vApps have networks between them
- No longer need to create resource pools in the VM clusters - vCloud director becomes the manager of resources
(Comment - there are 3 presenters and they are clearly feeling their way through this stuff as they "clarify" each others' presentation.  Lots of use of the term "we're trying to" which doesn't come across as completely confident)
- Organisations are the security boundaries
- An Organization vDC maps 1:1 for a provider vDC service offering - So Org A Gold, Org A Silver, Org B Gold, Org B Silver etc.
- vApps allow templates of VMs - e.g. 3 tier apps as one package - installed, configured and then booted in the correct order.
- vShield can apply at vApp network to Organisation network and/or from Organisation network to External network
- Some use cases being demonstrated
- Cloud resource group restrictions - no FT, no SRM - need to discuss back up solutions with storage suppliers if they are using vStorage API.  A bit fuzzy on who needs to recover from back ups - looks like its not the consumer
- Organisation vDCs can use a number of different resource allocations and aligned chargeback models, including metered pay as you go

Looks like it would be good to try this for dev and test environments where we can tie down SLA and resource allocations to dev groups and charge appropriately - they can then deploy and destroy vApp stacks as they wish within the organisation.