Preamble
Note: I was curious to find out where the image/tale of man sat on a branch, cutting down the very branch he’s sat on – came from. As former student of English/American Literature/History I’m always curious to know the origins of words, phases and stories. Turns out the story is attributed to Mullah Nasruddin. To paraphrase Wikipedia he “was a Seljuq satirical Sufi, believed to have lived and died during the 13th century in Akshehir, near Konya, a capital of the Seljuk Sultanate of Rum, in today’s Turkey. He is considered a populist philosopher and wise man, remembered for his funny stories and anecdotes. He appears in thousands of stories, sometimes witty, sometimes wise, but often, too, a fool or the butt of a joke. A Nasreddin story usually has a subtle humour and a pedagogic nature.”
I found small paraphrased version of the story here. I quite like the idea of satirical religious dude who teaches important moral truths via humour. I wonder why?
The Main Part:
Like many products vCloud Director does an awful lot of background behind the scene work to protect you from…. well, yourself. Most modern products now have many dependencies – from settingA to settingB, but just as critically from one feature or configuration to another within the same application – such a situation exists in both vCloud Director and Site Recovery Manger. In fact every product I’ve learned usually has its own internal configuration dependencies – so configuration F is dependent on E, D, C, B and A.
Such as situation exists with Organization Networks. I recently had cause to create a new OrgNetwork to give a VM direct access to a NFS and ISCSI Target. It was a bit of experiment (that initially went wrong, but later I fixed) so I want to remove the Organization Network but found I couldn’t. If vCloud Director finds the OrgNetwork “in use” it won’t allow you to delete it. I think that’s perfectly reasonable – and I wish saws came with the same protection – so if I was sat on branch, and tried to saw my own branch off – the saw LCD display would say:
“I find your trying to saw through a branch your are actually sat on. I’m not going to allow this action to happen for fear you landing on your head and ending up even more stupid than you are now…”
The tricky thing is finding out in vCD where this “object” is in use, and then removing the associations. The most obvious place to look is at your vApps because they are usually connected to the OrgNetwork directly or via their own vApp Network… Also don’t forget that vApps in the catalog may also referencing the OrgNetwork as well.
Generally, you will find where the OrgNetwork is “in use” by right-clicking the OrgNetwork and using the option called “Connected vApps”
That’s should open up a dialog box that list all the vApps (and vApp Templates). In my case I did this on the CorpHQ-CorpOrgNetwork – because nearly everything I run is connected by hook or by crook to this OrgNetwork. This means the screen grab contains both vApps and vApp templates that I added to the catalog that once resided on the OrgNetwork directly.
Remember its possible for an OrgNetwork to be “Shared” amongst the Organization Virtual Datacenter. That sharing feature is great and saves you heaps of times – so these Organization Networks can be visable in different Organization Virtual Datacenters. The CorpHQ Cloud Nesting resides in my “Test & Dev” OrgVDC whereas the rest are in the Production OrgVDC. Because of the dependencies removing the OrgNetwork requires its removal from the vApps that are leveraging it. That involves two main steps.
Firstly, the VMs within the vApp that are configured for it – need to be powered off and their configuration altered so its no longer in use – this means entering the “Hardware” tab of each affected VM, and modifying the OrgNetwork (or vApp Network for that matter if it was a vApp Network you wanted to delete)…
Secondly, the OrgNetwork needs to be removed from the vApp itself. This is done from the “Networking” Tab of the vApp. If the “option” to delete the network is dimmed its because the vApp itself is still powered on.
As you might have already experienced – powering off individual VMs within a vApp does not mark the vApp itself as powered off. It’s like the vApp itself is a process under the context of vCloud Director. This leaves the vApp in a “Partially Running” state that will stop you from removing the reference to the Organization Network that is backing the vApp. So not only do the VMs need powering off, but so does the vApp itself.
So to properly stop the vApp you can either right-click and choose “Force Stop” or before you begin this process – power off the vApp (which in turn powers off all the VMs within it) and leaves in a state which allows you to remove the reference to the Organization Network.
Delete the offending network and then click the Apply button – “Repeat & Rinse” as our American cousins are found of saying for each affect vApp. You should eventually find the option see “Connected vApps” on a Organization Network when selected leaves you with empty or blank dialog box.
Once the OrgNetwork is no longer in use on any vApp. You should be then free to delete the OrgNetwork itself…
Conclusions:
Writing this post got me think about how handle changes were the change is one that has knock on consequences. Firstly, any software must “protect” the admin from making casual and catastrophic changes – otherwise you end up like Mullah Nasruddin. Secondly, were the change is desired – because the change affects many moving parts – you have to ask yourself if the change is really worthwhile, and if it can be avoided – and whether the change will have any positive or desirable outcomes OR is it just change for change sake because something annoys you. Thirdly, you need to be able to measure the impact of executing the change – and put the appropriate request in before hand with the required maintenance windows to be able to reasonably affect change without unduly upsetting the users. We normally call this “Change Management” or the “Change Process”. I would hope that for most folks these should be a “given”. It’s think its also worth knowing the impact of these changes upfront so in your design, you design for minimal change… So correct planning and upfront design of both your external and organization networks is imperative. Once you have a gzillion vApps and VMs hanging of these core constructs then you won’t want to have to change them.
These thoughts made wonder if we could express as a law or in maths this type of change. For example if the dependencies are A>B>C>E>D. Changing D is almost trivial, but changing A exponential as it may require or necessitate changes in B, C, E, and D. I was thinking that the further back you have to go the in the dependency structure the bigger the impact of the change. Such that changes at LevelA or LevelB should be avoided at all costs. The impact is so great on the “Change Process”. The other thing to consider is B, C, E, D are often “branches”. Think of A as root of a tree, and B as the first branch of A. From B they can be MANY branches. So consider one Organization Network can have MANY vApps connected to it, and many VMs within those vApps may or may not be connect to the Organization Network.
So how to express that “law” in words or maths. The impact of change is exponentially increased the closer change is to the root of the dependency. Anyone care to express that in maths for me?