Retaining Resource Pools using Webclient

So a few days ago I posted up an article about what happens if you disable DRS in a vCD environment…..

Well I stumbled across this article in VMware’s knowledgebase:

“Great”…… I thought….. “I can use the snapshot functionality within Webclient to capture the resource pools!”……the only problem is, upon deeper digging I stumbled across a blog entry by Frank Denneman:

Turns out that VMware knowledgebase article is great for standard vSphere environments, but it won’t work with vCloud environments….. >_<”
And this is all down to the old MoRef IDs I mentioned in my previous article about using SRM to protect your vCloud!

Unfortunately it seems that the ‘RP snapshot’ feature just captures the old tree structure of your resource pools and rebuilds a new tree structure, it doesn’t capture the old MoRef IDs which are so important as they are used to correlate objects between vCD and the underlying vSphere/vCenter layer… change the MoRef IDs and vCD won’t recognise the object as it won’t exist in the vCD DB.

Man…. VMware really need to sort out this MoRef issue! ;oP

Exciting times ahead for VMware and SDDC?

Software Defined Data Center……

Virtualising Compute, Network and Storage……. (among other things)

VMware already did the compute side of things……. Buying Nicira gave them the network side of things……. Buying Virsto gave them the storage side of things…..

Looks like 2013 maybe a good year for VMware with lots of new shiny things coming out the pipeline…….


….. which basically means more things to add to my growing list of tech I need to brush up on!! >_<“

DO NOT disable DRS within a vCloud environment!!

I remember watching this video when going through my vCloud Director training, and stumbled across it again a few days ago… thought I’d share it with you all!

Basically by disabling DRS on your vCloud resource cluster you remove all resource pools in vCenter (unfortunate side effect of DRS).
Now vCloud Director relies heavily on these resource pools, in fact by disabling DRS you pretty much destroy your vCloud environment!! O_o”

When you create your vCloud, you usually create a Provider virtual DataCenter (PvDC) which is usually assigned to a HA cluster within vCenter. When you start to create Organisations and then the relevant resources you wish to assign to that Organisation, you create Organisation virtual DataCenters (Org vDCs – which basically is a pot of resources you’ve carved off the PvDC).
It’s these Org vDCs which are backed up by resource pools within vCenter, hence why if you disable DRS, you pretty much destroy all your Org vDCs within your cloud!!

There really isn’t an easy way around this (restoring a backup of your vCenter Server DB will go some way to repairing your vCloud)…..

As the video shows, whilst the VMs within a vApp will keep running if powered on (or warm booted), if you power them off then they die (because the resource pool it belonged to was destroyed)!
Plus you won’t be able to manage the vApp or doing anything within vCloud Director (like deploy a catalog template, power on another vApp, etc).

There’s a more indepth article by Chris Colotti that goes into what happens when you disable DRS:

Distrusting the Cloud (article from The Reg)

So a very interesting article on the Reg…… and in a way I have to agree with some of the points the author raises:

  1. The reality is, Cloud is here to stay! It’s been a buzzword for the past year or so but has only just started to get real traction in the industry as IT looks at the next stage after consolidation and virtualisation!
    I’m seeing a lot more clients wanting to learn about ‘The Cloud’ and how they can use it in their environment…. IMO, it’s no longer a terminology that clients and consultants can throw around to make themselves sound “knowledgeable”!
    In fact I can see that a lot of IT integrators, ISPs and consultants are really going to get found out if they keep babbling on about ‘Cloud’ without fully understanding the concepts and constructs of one (Let’s face it, there’s so much BS in the market at the moment! However, customers have started to get wise to it as more and more articles appear about Cloud Computing).
  2. Everyone is trying to sell ‘The Cloud’…. but everyone has a different idea of what ‘The Cloud’ is supposed to be! No two cloud service provider have the same offering! And that’s probably due in part to how wishy-washy the cloud standard is (and the different ways you can approach self service, orchestration and automation)!
  3. Every sales guy wants to sell a large cloud offering at the enterprise level, but in reality C-board members have been so badly ‘cloud-washed’ that it’s usually down to the IT director to determine whether they can push their IT into the cloud! I’ve yet to speak to anyone higher than an IT director about cloud! And more often than not the IT guy only wishes to put their test/dev into a cloud – and nothing else! (Afterall, IT admins are protective of their own little world….. the cloud is too big and fluffy for their liking!)
  4. Trust & Security…… This is a huge bugbear to IT administrators and CIOs!! With the recent revelations that the NSA and even GCHQ are snooping at online data, if you can’t explain the security of data in the cloud to your client, then you can pretty much kiss goodbye to any opportunities!! Security of a clients data on the cloud will become #1 priority over the next few months – if it’s not already!

To be honest, whilst Cloud is a fancy term that has been pandered around for ages, more and more people are looking at making it a reality within their business. But many are still put off by the reliability of the public cloud offerings (*cough* Amazon *cough*), or the ability to exit a cloud at short notice and pull data and services in house if required (*cough* Azure *cough*… and even when companies go tits up…. *cough* 2e2 *cough*).

I still have to agree with VMware’s view (from last year) where they were insisting any sort of Cloud adoption should first be a Private Cloud which allows the IT admins to still ‘hug’ their hardware! Plus it allows them to evaluate whether ‘The Cloud’ is really for them whilst still keeping control over their data.
IMO, a Public Cloud is still a step too far for clients to adopt as their entry to the cloud.


Edit Note: ……. Hmm…. after reading my blog post I’ve realised it’s quite a load of rambling nonsense…… ^_^”
Hopefully I’ve managed to get some of my points across. One of these days I really need to sit down and write a proper entry with industry references…… I blame the early Monday morning, the heatwave in UK, and my lack of coffee for my ramblings!


Auto-deploy… now that’s a function that I’ve barely used…. but many see it as the future of deploying a cloud infrastructure.
Obviously automation & orchestration is key to the cloud, so I’m not surprised that more and more articles are being written about auto-deployment.

Read an article in the Reg today that got me thinking about the need for me to start learning about using the auto-deployment functionality in VMware (for ESXi deployment) as well as other applications readily available on the market that will help deploy OS & apps….

Having briefly messed around with Puppet on a previous vCD project, I think this is a tool I’m seriously going to have to learn in order to automate the process of OS deployment. Looks like a very handy tool!

So “What is Puppet?” – Well it’s an automation software that helps you manage your infrastructure throughout its lifecycle – from provisioning and configuration to orchestration and reporting.
And whilst that may sound like VMware Configuration Manager, one of the big differences is it covers quite a large number of OSes (Windows, Linux and Mac) as well as physical, virtual and cloud constructs!

*sigh* Yet another piece of software to add to my vastly growing list of stuff to learn!!

(For more info about Puppet – download their learning VM:

SRM & datastore names

By default, when doing a failover with SRM the VMFS Datastores will be labeled with a “snap-xxxxxxx-name” because they will have been re-signatured during the failover process.

This can cause issues for applications that may utilise the datastore name (for example some backup applications).

To stop the renaming of the datastores edit the Advanced Settings of each SRM server using vSphere Client, then navigate to storageProvider -> storageProvider.fixRecoveredDatastoreNames and ensure that the check box is ticked.


Protecting your Cloud (vCloud & SRM)

So one of the BIG problems at the moment is that SRM does not fully support protecting your vCloud environment.

It supports protecting your management cluster (so the vCenter servers, vCD cells, vCNS manager, vCM, DBs, etc), but it doesn’t yet protect your resource cluster….. so all those VMs you’ve deployed in your organisations under vCD – well they’re not protected by SRM!

Definitely NOT COOL if your primary site goes tits up!!

From what I can gather, this is mainly due to the way SRM work….. When you setup SRM for DR, you have to ‘pre-create’ resources at the recovery site in order to map the resources from the protected site to them (stuff like resource pools, folders, network, placeholder VMs). Unfortunately vCD likes to have full control of a resource cluster and manages all the resource itself – this basically means that the vCD cells are not aware of the objects that have been created in the recovery site for SRM. It doesn’t matter if the names are the same, what matters is the Management object Reference IDs (MoRef ID) have changed and this is what vCD uses to construct its environment…..

MoRef IDs are used to correlate objects between vCD and the underlying vSphere/vCenter layer. Any changes to these identifiers will result in the loss of functionality because vCD will not be able to manage these objects as it will not be aware of them (ie the MoRef IDs will not exist inside the vCD DB).
The use of SRM would result in a change of the MoRef ID on the vCenter Server layer, resulting in an incorrect reference in the vCD database – and so leaving the object (eg. a VM) unmanageable from a vCD perspective. I believe SRM also re-signatures the storage volumes which will also confuse vCD.

About a year ago Chris Colotti and Duncan Epping wrote an article on how vCloud DR could be achieved, this involved the clever idea of putting the resource ESXi hosts at the recovery site into the same resource cluster as the resource ESXi hosts at the protected site (but in maintenance mode as obviously it won’t see the storage located at the protected site so can’t be used by vCD). Then using vSphere HA to take the ESXi hosts out of maintenance mode to handle the recovered workloads…. However, this solution did involved manual intervention to fail over the vCD resources correctly:

Earlier this year, another white paper was released which described how the majority of this manual process (ie the VMware bits) could be automated using PowerCLI:

However, what’s missing is the automation of the whole storage piece – breaking the replication and making the volumes read/write….. but then I guess this is really more storage-vendor dependent! =)
I guess if the storage vendor has exposed the array to VMware using VASA then it could be possible to script the storage steps as well….! =)

Anyways, it’s been an interesting read…… and definitely a problem I see VMware sorting out for the next release of SRM!

Given how powerful PowerCLI is, I really need to find some time to learn how to use it!!