Me and other 15 vExperts/VCDXs were invited to Early Access Program for the VMware vCloud Hybrid Service (vCHS). Even though I am a VMware Employee I was not involved in the vCHS project and this was my first chance to get some hands on time with this new service.
As architect working for Professional Services I do build vCloud Director based clouds for service providers so I was curious how is vCHS different from the clouds I designed.
This blog post therefore will not talk about what vCHS is and how it can be consumed (read Massimo Re Ferre’s vCHS: Stop Thinking About Building a Cloud, Start Thinking About How to Consume It post) but how it differs from the typical private or public vCloud Director based cloud. It is therefore assumed that the reader has at least vCloud Director Administrator equivalent knowledge.
A Service Not A Product
First of all vCHS is a service not a product. Sure it uses vCloud Director, vSphere and other VMware products, but as it is not tied to Enterprise (slow) software product release schedule new features can be incorporated during much faster release cycles. The new features will eventually get to the standard product releases.
I need to put a disclaimer here that because vCHS is a service some of the features I describe here might change until the GA which is around Q3 as the Early Access Program period is used to collect feedback and act upon it.
Cloud of Clouds
Although vCloud Director is pretty scalable (up to 25 vCenter Servers) it might not be enough if we start to think in Amazon AWS scales. vCHS is able to federate multiple vCloud Directors in multiple locations. Customers can purchase dedicated vCloud Director instances or a shared virtual private clouds.
See YouTube video: vCloud Hybrid Service – The “Cloud of Clouds”
Interesting observation I made that I guess in order to simplify Organization VDC access management there is always 1:1 relationship between Organization and Organization VDC. This has some consequences on how the customer transfers workloads or catalog images between Organization VDCs – vCloud Director does not support inter Organization transfers therefore vCloud Connector must be used. You also cannot share Org VDC networks which cannot span Organization boundaries – Edge Gateway SL VPN connection would have to be created instead.
vCHS has new web based portal. It is not vCloud Automation Center nor is it the vCloud Evaluation web portal. Those should not be confused.
vCHS has brand new portal which is simple to use and less confusing for regular users than vCloud Director portal but the tenant still has the option to use the native portal. Note that some advanced features are not yet available in the vCHS portal and must be performed directly in vCloud Director (Edge Gateway or Catalog management). As mentioned above new portal features might appear quickly.
I should confess I have not spent too much time playing with the vCHS portal as I am much more comfortable in the vCloud Director interface.
This is where it gets interesting. vCHS uses different user roles than those that are in vCloud Director. Even if you buy dedicated cloud instance you will not get vCloud System Administrator rights. Also in the shared Virtual Private Cloud instance you will not get Organization Administrator rights. Instead you will get different vCHS level rights that somehow map to subset of vCloud Director rights – see KB 2053484 for more detail. This was mainly done to disable the vCloud Director local accounts and instead enforce global access management that spans cloud instances. You will not be able to directly access vCloud Director GUI with your vCHS account. It is instead needed to first log in to the vCHS portal and then thanks to Single-Sign-On go to the right vCloud Director organization.
API access works with the vCHS account (not sure how that was achieved). As even the most powerful vCloud Director role – VPC Administrator (in KB above listed as Virtual Infrastructure Administrator) does not have access to User management (either from vCloud Director GUI or vCloud API) it can break some applications that rely on this. One of them is vCloud Automation Center (read my other article Integration of vCloud Automation Center with vCloud Director for the details) which at the end of provisioning process (done under a service account) maps the provisioned VMs to a vCAC user account. If that account does not exist it tries to create it.
I assume this issue will be quickly resolved with a vCAC custom property hard user mapping or identity provider federation at the vCHS user management level.
So if you have some automation tools that leverage vCloud API you must take these limitations into account and do some testing. Even if you buy dedicated cloud you will not be able to use provider vCloud APIs – tools like vCDAudit, vCenter Operations with vCloud Adapter will not work.
Each vCloud Director instance has its own vCloud Connector (vCC) shared node. I was able to connect my vCloud Connector Server to it without any problems and quickly transfer first workloads in and out. Besides the simplicity of the setup an additional advantage is that it does not consume any allocated storage space and does not take away internet bandwidth as opposed to private vCloud Connector Node deployed inside Org VDC. It is vCC version 2.5 which has transfer path optimizations which speeds up the transfer as it is not staging the OVF vApp files on the nodes but instead is continuously streaming.
What is also nice that you get vCloud Connector Advanced license which enables in my opinion the killer feature – Content Sync. You can publish your private vSphere folder with templates to automatically sync with connected clouds. This makes the catalog management really easy.