vCloud Air @VMWorld 2015 pt.1

VMWorld was bigger than ever this year with 23,000+ attendees. Announcements came in droves and vCloud Air certainly didn’t miss out on its fair share. I will be covering all of these in lot more detail in coming posts, but for now here’s high level summary.

Some of these announcements have been doing the rounds for a while, whilst others came out of the blue. Here is a breakdown of what got me childishly clapping at the screen whilst I watched remotely.

Hybrid Cloud Manager: is the replacement for the vCloud Air vSphere Web Client Plugin and vCloud Connector. It also adds advanced hybrid network capabilities based on NSX technology.

Enhanced Hybrid Cloud Management: Greatly improved administration and management of vCloud Air workloads from vCenter.

Enhanced Virtual Machine Migration: Replication-based migration of VMs over Direct Connect and VPN with automated cutover (ASAP, scheduled and optimised) and finally an exposed API. Oh, and the all important addition of WAN optimisation!

Infrastructure extension: Stretch multiple L2 segments (up to 200!) into vCloud Air over Direct Connect or VPN. This replaces vCloud Connector Stretch Deploy which is a very welcome addition if you have ever tried to use Stretch Deploy in any anger…

Project Skyscraper was also announced during the keynote on Day One of VMWorld and got all the ‘ooohs’ and ‘aahhs’ of a world class fireworks display. It has been a long time coming but unfortunately is still in technology preview (*sad face). It includes;

Cross-Cloud vMotion: This had to be one of the coolest demos of the entire event. vSphere vMotion into vCloud Air (and back again). Zero downtime for workload migration to public cloud. That is an absolute first! You can guarantee I will be covering this in great detail!

Cross-Cloud Content Syncsynchronise VM templates, vApps, ISOs, and scripts with their content catalog from vSphere to vCloud Air.

Advanced Networking Services: The long-awaited NSX integration into vCloud Air. There’s way too much here to go into any detail. High level enhancements include;

Enhanced Edge Services: Current vCA Edge capabilities + support for dynamic routing (eBGP/OSPF), SSL-VPN, enhanced load balancer, multi-interface trunking (True L2 Stretch), enhanced stateful edge firewall + more.

Trust groups: Stateful in-kernel L2/3 firewall (micro-segmentation), Object based rules, 5-tuples mapped to apps + more.

Compliance and operations: Enhanced API, Distributed firewall logs, Load balancer health checks + more.

Site Recovery Manager Air (SRM Air): In terms of revision, DR2C (or Disaster Recovery to Cloud) is in it’s second incarnation. v2.0 gave us reverse replication, fail-back, multi point-in-time recovery in addition to other small improvements. Enhanced Disaster Recovery aka SRM Air (or DR2C 3.0 if you will) adds SRM capabilities in a SaaS delivery model. Expect application-centric automated workflows that orchestrate testing, failover and failback of VMs to and from vCloud Air.

DR2C will also move away from a subscription model to OnDemand, metered by the minute pricing model where you only pay for the storage you consume + a per VM monthly subscription. Watch this space!

EMC & Google Cloud Object Storage: Object storage has been a cornerstone of public cloud for many years now. VMware has partnered with EMC and Google Cloud to provide the following services integrated directly into vCloud Air.

Google Cloud Object Storage: Available in three flavours. Standard, Durable Reduced Availability and Nearline. I think these services are all pretty self explanatory but for more info see here.

EMC Object Storage: Geo-protected distribution, located in the same data centers as vCloud Air, S3 compatible API. Currently only available in the US, but coming to other global vCA data centers in the near future.

vCloud Air SQL (DBaaS): Again relatively self explanatory. vCA SQL is a managed database service initially based on, you guessed it, Microsoft SQL. This was announced last year but has made it into the fold this year.

Backend-as-a-ServicevCloud Air’s first foray into the PaaS world outside of the partnership with federation brethren, Pivotal. Most impressive in my opinion is Kinvey, a vCloud Air integrated mobile development platform with complete backend services for end-to-end delivery of mobile applications: identity management, data services, business logic, analytics + more.

Apparently you can build and deploy a complete mobile application without writing a single line of code! I find this difficult to believe but I look forward to giving it a go.

There were a number of other smaller announcements which weren’t as exciting (to me at least). If you want any more info about any of the above feel free to give me a shout.

Author: @Kev_McCloud


Fusion 8 – vCloud Air Integration

True story… I spend a lot of my daytime hours working with VMware Fusion Pro for BAU and local lab tasks. Fusion has been a mainstay for me since switching to a Macbook Pro for my main workhorse a number of years ago. I test a lot of beta software, build & break stuff for training. Fusion has always had me covered.

I’ve also gotten used to working with a variety of interfaces when testing various cloud platforms, but recently most of my time has been spent in vCloud Air (obvz). So when I fired up Fusion 8 Pro this morning and found the <VMWARE VCLOUD AIR> header in my navigation pane, I was understandably excited.

vCA Login

A simple click onto the header reveals login fields and a couple of contextual links to vCloud Air (bonus points to the product team for adding <Remember Password> checkbox).

Screen Shot 2015-08-26 at 7.13.32 am

I enter my login credentials and *BAAM*. Within a couple of seconds, full access to all of my Subscriptions and VPC OnDemand. I will admit that I was surprised by how rapidly Fusion was able to display and allow interaction with my full vCA inventory across multiple SID’s / VDC’s.

I’m hoping to see a more advanced federated ID type service integrated into Fusion in the near future, but this will do for now.

VM Remote Console (VMRC)

Hands down one the best features of this Fusion release is VMRC access to vCA workloads. No messing with firewall and NAT rules. Just plain VMRC…

Screen Shot 2015-08-26 at 10.33.50 am

The result is Operations can continue to administer the vCA platform and assign access to VDC’s based on login. Developers (or users) who have no delegated administrative control in vCA can login via Fusion and get access to the resources the need. No additional URL’s to send out. No training users on the multiple interfaces. They just continue to use Fusion in the same way they always have…

Transport to vCA

As for workload transport, we can still export to OVF/OVA and upload to our Private Catalogue in vCA…

Screen Shot 2015-08-26 at 10.35.16 am

…but why would we when we can now drag ‘n drop our local VM’s into vCloud Air! Select the VM, drag to our VDC of choice, rename if required and click <Upload> to confirm. Simple.

Screen Shot 2015-08-26 at 11.37.01 am

Note: One small gotcha (why is there always a gotcha…). In order to use this method of migration we need to update Fusion tools to the latest version, and then downgrade the hardware version to a maximum of v10. The VM can be upgraded again post migration which is a small hassle (edit:when supported), but in general this method rocks!

Screen Shot 2015-08-26 at 11.48.44 am

And that’s it… A ~5GB VM took just under 10 minutes to move from Fusion to vCA (AU South). Of course the network still needs to be setup on the vCA side to support intra-VDC and external network communication, but if the VM is standalone then nothing else is required.

Screen Shot 2015-08-26 at 12.14.23 pm

More detail to come in the near future. Happy Fusion’ing 😉


Author: @Kev_McCloud

vCloud Air Dissected – pt.3 Understanding DR2C Compute

vCloud Air Disaster Recovery (aka Disaster Recovery to Cloud, aka DR2C) is by far the easiest entry point and the most in demand offering from vCloud Air. However, it also seems to be the most misunderstood service from a compute scoping perspective. Let’s break it down!

I won’t be covering DR2C in its entirety as there are numerous solution briefs, videos, white boards etc, most of which can be found in the links I featured here. My colleague @davehill99 also has a great blog covering everything from DR2C basics to advanced architecture.

DR2C Basics

DR2C is a subscription service built around VPC compute (covered in part 1 of this series) so we know that the same characteristics apply. What’s important to note is that workloads replicated from our on-premises vSphere Replication consumes storage in VCA, but does not reserve any compute. So what does this mean for the consumer?

First off let’s cover the two scenarios which would require access to active compute in DR2C. Unlike a VPC Virtual Data Centre (VDC), DR2C is not intended to run active VM’s outside of Testing or Recovery, defined as follows:

Testing: Launch protected VM’s in an isolated VDC for a period of 7 days. VM data continues to be asynchronously replicated for the entire duration of the test.

Recovery (or planned migration): Launch protected VM’s, accessible in a predefined production topology for 30 days (and beyond if required). VM replication is ceased (on-premises > vCA) for the entire duration that recovery workloads are active. Note: reverse replication and failback is available for DR2C 2.0 customers (vR & vCenter 6.0 and above).

Screen Shot 2015-08-19 at 2.27.01 pm

Scoping DR2C Compute…

Scoping compute for DR2C is a little different from other cloud services as we really need to analyse our procedures for testing and recovery. Let me explain…

DR2C compute is procured in the same blocks as VPC (10GHz/20GB) and scales in exactly the same way. In order to keep the cost of the service low (for the consumer) it is recommended that we only procure as much compute as we need to guarantee. I’ll come back to this in a second.

Screen Shot 2015-08-20 at 7.38.46 am
Note: This figure is conceptual and not intended to show any relationship between compute & storage

The above example shows a VDC capable of supporting 10GHz CPU / 20GB memory / 4TB standard storage. Conceptually let’s say that we need 40Ghz CPU / 80GB memory to fully stand up our replicated VM’s for a test. Using this allocation only allows us to test (or recover) a subset of our total footprint within the core subscription.

This is where temporary add-ons come in. We can procure additional compute resources on a temporary basis (1 week for testing, 1 month for recovery) from My VMware to support any additional compute we will need for both scenarios. This gives us the flexibility to test individual application stacks within the confines of the core subscription, or temporarily extended to full capacity to test (or recover) everything at once.

Screen Shot 2015-08-19 at 2.36.02 pm
Temporary subscription compute add-ons

How much to guarantee?..

The quantity of compute we choose to guarantee is completely dependent on our risk profile and overall Recovery Time Objective (RTO). The more compute we guarantee, the more our monthly cost goes up, much like an insurance policy.

Procuring add-ons will add a small amount of time to our overall recovery, but in reality this is a small inconvenience considering the potential cost savings. A simple rule of thumb would be to protect critical workloads (Tier 1) with guaranteed compute to reduce downtime, but scale up with add-ons for everything else (Tier 2 & 3).

It’s also important to remember that we can utilise active capacity in VPC, VPC OnDemand and DPC to augment our DR strategy. The VMware solution brief on Advanced Architecture for DR2C really helps to understand how different vCA services hang together to form a complete solution.

…and there you have it. Pretty simple once we know the limitations. That said, most of the complexity in DR strategy lies in the network. I’ll save that for the next post.



vCloud Air Dissected – pt.2 Understanding DPC Compute

So we’ve already covered some of the basic elements of scoping vCA compute in part 1. Let’s delve into Dedicated Private Cloud (DPC) to show how the compute differs from the services built on Virtual Private Cloud (VPC, DR2C and OnDemand).

Again, if any of this seems unfamiliar please check out pt.1 Understanding VPC Compute or have a fish around Cloud Academy for some vCA goodness.

DPC compute basics

Unlike the multi-tenanted Virtual Private Cloud service, Dedicated Private Cloud (DPC) assigns physically dedicated host’s to each tenant (as the name might suggest). This has numerous benefits for compute, specifically;

  • Physical isolation for the purpose of security and licensing compliance
  • The ability to split resources across multiple VDCs
  • The ability to control oversubscription at a VDC/VM level

Note: There are other benefits for network, which I will cover in a another post.

From a consumer perspective the services are almost identical, however there are a few additional parameters which can be configured from both the vCA and vCD web portals within the DPC service.

Physical allocation

A great place to start is understanding what we have access to when working with DPC. The physical specification of the hosts is identical to VPC (2x 8 core, x86 Intel processors @2.6GHz and 256GB RAM in AU South at the time of writing). This gives us access to a core subscription of 35Ghz CPU and 240GB RAM (the remaining resources are reserved for the hypervisor).

From a compute standpoint our workloads have access to a single host’s resources, but in reality we actually have two host’s (1x Active / 1x HA) within our DPC environment. High Availability has been a critical component of vSphere for many years now and by no means is it excluded from vCA.

Screen Shot 2015-08-04 at 1.59.21 pm
DPC core subscription = 1x Active + 1x HA hosts

DPC scales in this manner until we reach 7 hosts (1x core & 6x add-ons) where a second HA host is added into our DPC environment. As a rule every 7 hosts in your allocation adds a HA host, capped at 28 which maxes out the underlying cluster of 32 hosts (28x Active + 4x HA).

Screen Shot 2015-08-04 at 2.00.08 pm
DPC core + 6x compute add-ons

So why is this important? Probably the most obvious reason (other than curiosity) is licensing compliance. For the more restrictive software vendors (*cough*Oracle) it is critical to know how many hosts are in our environment as a whole.

Correction: Since I wrote this post the model has changed to horizontally scale HA hosts from 16 hosts onwards (ie. one HA host until you reach 14x active hosts where a second is added).

DPC compute consumption

As DPC compute is dedicated to a single (master) tenant, all compute resources are 100% guaranteed. It is completely up to the account administrator(s) how resources are split over a single or multiple VDC’s within the organisation.

The ability to create multiple VDC’s is a powerful tool as it gives us the choice to run heavily oversubscribed (think test/dev) or with room to stretch (think mission critical) within the same subscription. It’s also useful as a subtenancy construct for service providers (to be covered in a later post).

Screen Shot 2015-08-04 at 6.04.33 pm
VDC resource config

Once we dive into the configuration for an individual VM we can set shares, reservations and limits as a mechanism to balance workloads according to priority when our VDC is in contention. By default the reservation is set to ‘0’ (as pictured below) for both CPU and memory (unlike VPC which automatically reserves 100% of the memory allocation for powered on VM’s).

Screen Shot 2015-08-04 at 6.11.42 pm
VM compute resource config

Sticking with the default configuration (NORMAL, 0, Unlimited) will allow us to run heavily oversubscribed within our VDC with all workloads having equal access to resources. We get far greater control over the individual performance of each VM once we start pulling levers (read: configuring shares, reservations and limits). We’re not going to cover the specifics of resource management in this post, but I recommend reading this blog from @FrankDenneman as a start.


… is not as straight forward as VPC where we can use memory as a measure for sizing the environment (assuming memory is the most common resource for contention). If you are familiar with scoping and building a vSphere environment from scratch then this shouldn’t be too much of a chore.

When you are moving VM’s from an existing vSphere environment to vCA there are a number of tools that can be used to predictively analyse virtual resource utilisation like vRealize Operations Manager or VMware Infrastructure Planner. If not concerned with peak utilisation we can also use a point-in-time capture tool like RVTools. The key is to understand CPU and memory utilisation across a known resource quantity. As long as we know what is currently being consumed, we know how to size the compute for DPC.

For example, if we take a typical vSphere environment with 3 hosts (100GHz CPU / 384GB RAM) with a 15% and 50% utilisation respectively then we can conclude we need 15GHz CPU and 192GB RAM which is within the thresholds of a core subscription (35GHz / 240GB). However if memory utilisation is high, let’s say 75% (288GB) then we need a minimum of a core subscription plus a single compute add-on (70GHz / 480GB).

Before anyone gets fired up, I realise that the above is a drastic oversimplification for anything but the simplest migrations. It’s only intended to show that we don’t need to go to ridiculous lengths to get an indicative scope.

Note: We can use the same methodology for VPC, however we need would need to right-size the workloads before being migrated as vRAM is 100% reserved for powered on VMs.

Simple right?


Author: @Kev_McCloud

vCloud Air Dissected – pt.1 Understanding VPC Compute


In this series of posts I will be dissecting areas of vCloud Air (vCA) that I get grilled on regularly. Before reading on, please note that I am writing these blogs from the vCA Consumer perspective. For the vSphere Admin, interacting at purely the consumption layer can seem unnatural. I’m hoping this series will reveal enough detail to demonstrate VMware’s objectives in designing a global public cloud platform with the vSphere Admin in mind.

I’m going to assume some basic reader understanding of the key differences between Virtual Private Cloud (VPC), VPC OnDemand and Dedicated Private Cloud. There is a wealth of 101 style vCloud Air info covered in Cloud Academy to get you started if you are not already armed with this knowledge. In addition I’ll point you to a great blog from @mreferre who has the perfect vehicular analogy for the basic Virtual Data Centre (VDC) construct. With that out of the way, lets get started.

Screen Shot 2015-07-27 at 3.04.40 pm

VPC compute basics…

One of the areas I get questioned on regularly is how CPU is consumed and scoped for vCloud Air. In this post we are going to focus on CPU consumption within a VPC VDC.

VPC compute is made up of securely shared memory and CPU, procured as blocks of 10GHz vCPU / 20GB vRAM. vRAM is relatively easy to understand as whatever has been allocated (read: configured) to your powered on VMs equates to what is consumed within your VDC. The upside to this characteristic is that vRAM within your VDC is 100% guaranteed which is key to vCA’s multi-tenancy performance. Note: The logical vRAM maximum for a single VM is limited to what is available on a single host, minus the hypervisor overhead (~240GB at the time of writing).

Screen Shot 2015-07-20 at 6.36.23 pm

Core VPC Allocation

vCPU is a little trickier to explain as consumption is not static like vRAM. vCA CPU is procured in aggregated GHz ie. pooled clock cycles across a number of physical hosts. This however does not mean that a single workload’s processing is distributed. Regardless of how many vCPU’s have been configured a VM can only execute on a single host. It’s important to remember that vCA’s underlying hypervisor is vSphere and therefore the same rules apply in vCloud Air.

Going back to my introduction briefly, those who have familiarity with vSphere will want details on guarantees, oversubscription etc. The key to working with multi-tenanted cloud is to accept that low level functions (like the ability to set reservations, limits and shares) are often abstracted from the consumer. In principal this is how vCA ensures equal resources to all tenants. Wouldn’t be fair to have some customers more equal than others, right?

Note: DPC does allow the consumer to configure compute shares and reservations at a VM level however I will cover this in part 2 of this series.

How VPC compute is consumed…

VPC’s current architecture utilises hosts with 2x 8 core Intel x86 processors rated at 2.60GHz (at the time of writing). Contrary to popular belief vCPU is not throttled within vCA, therefore you can run a theoretical max of ~2.6GHz per vCPU. Conceptually, within a 10GHz allocation you could run 3x single vCPU VMs at 100% utilisation before you would potentially run into resource contention ie. 3x 2.6 = 7.8GHz leaving 2.2GHz.
Screen Shot 2015-07-27 at 1.17.14 pm

If we were to launch the fourth VM the expected behaviour is for the scheduler to balance all VMs within the VDC resulting in throttling by the percentage of the overcommitment.

Screen Shot 2015-07-27 at 1.15.55 pm

Note: In the above example this could theoretically be ~100MHz penalty per VM however this would be a point in time snapshot of the potential impact to workloads. The scheduler executes thousands of transactions per second therefore any impact would not be uniform across all workloads. This scenario is pretty unrealistic, but helps me to articulate the limits in this explanation.

If we were using a larger compute allocation (50GHz CPU, 100GB RAM) we could potentially run a single VM with 16x vCPUs running at a maximum clock speed of ~2.4GHz on a single host. The remaining host compute is reserved for hypervisor overhead and this is not included as part of our overall consumption.

Screen Shot 2015-07-26 at 6.27.26 pm

Using this same example, you can assign up to 32 vCPUs to a single VM* (deployed from vCloud Director UI), however vCPUs would be capped at ~1.2MHz when executing simultaneously due to hyper-threading on the underlying host processors. It’s important to note that multithreading characteristics are also dependent on the OS and application and should be taken into consideration when sizing a vCA environment.

*Interestingly, when deploying a new VM from the vCloud Director Web Interface you have the ability to assign up to 64 vCPUs to a single VM, but you will be swiftly issued with a error message upon creation.

vCA CPU Reservation

Definition: A reservation is a guarantee of the specified amount of physical resources regardless of the total number of shares in the environment.

What’s not immediately obvious (and can’t be observed from the basic vCA dashboard) is that a powered on VM automatically reserves 260MHz per vCPU and will scale up its reservation in 260MHz blocks. Theoretically you could power on 38x single vCPU VMs all using less than 260MHz before admission control stopped you from powering on subsequent VMs within you VDC.

Screen Shot 2015-07-26 at 4.37.30 pm

Again, this scenario is unrealistic but would help to explain why your dash may be showing available CPU that you cannot access. It is also important to note that the dash is not realtime (updated every 5 mins) and therefore not a reliable source of data for troubleshooting. Monitoring is a broad topic on it’s own so I’ll have to cover it in a later post.

When it comes to scoping typically most VMware environments are RAM bound and CPU usually clocks in at anywhere between 5-30% utilisation during non-peak periods. With this in mind (and the info in this post) it is pretty simple to put together some basic math to calculate the minimum requirements for a VPC environment (but don’t forget to factor in overhead for peak periods). VPC compute add-ons are also instantaneous when procured from My VMware, so if your math is a little skewed don’t worry, we got you covered.

I hope that this post has been useful in understanding some of the nuances of vCA Compute. Feel free to message me if you want more info on VPC compute or any aspect of vCA in general. -K


Author: @Kev_McCLoud


10 Useful vCloud Air Links…

I’ve spent the past few months trawling through everything vCloud Air, so I decided to post some of the useful public links I’ve found lying around the web. This should get you well on the way to moving all of your precious workloads into vCloud Air. What you waiting for?

vCloud Air Blog – A window into the minds of some of the most talented people within the vCloud Air Team. I check this everyday for interesting tidbits.

vCloud Air Home Page – Everything from service descriptions to FAQ’s, pricing calculators to deep dive solution briefs.

vCloud Air Cloud Academy – Videos and briefs on everything from vCA basics to advanced concepts and integrated solutions.

vCloud Air Documentation & Knowledge Base – Everything you need to know (and if it’s not here, you can ask me).

vCloud Air Portal – Once you’ve signed up, this is where you play.

My VMware – The centralised portal to manage vCloud Air funds, alerts, permissions, global provisioning and support requests in addition to your perpetual licensing.

Hybrid Cloud Hands On Labs (HOL) – Great way to get practical experience in a live environment with some of the tools of the trade.

vCloud Air Feature Walkthroughs – Constantly updated with new products and revisions including install, configure, manage and administration best practice walkthroughs.!/vcloud-air

vCloud Air Community Page – One of the great things about VMware has always been the strength of it’s community.

vCloud Air Market Place – A bazar (read ‘catalogue’) of supported third party solutions you can use with vCloud Air.

Edit: I’ll be adding to this list periodically as new resources come online. The below don’t make the top 10, but are useful non the less.

vCloud Air Beta Community – If you’re invited to participate in a vCA beta or early access program, this is where everybody throws their rocks at the PM’s.

GitHub / VCA-CLI – Repo for everything VCA-CLI and the pycloud SDK.

GitHub / RaaSCLI – Repo for “Recovery-as-a-Service” CLI, required for DR automation when using DR VPC.

Github / EMC GoAir – Repo for multi-platform (OS X/Docker/Linux/Windows/FreeBSD) CLI tool. Deploying machines / container and configuring network services for on-demand vCloud Air compute services.