vCD SP 8.10 New Features Part 2 – Affinity Rules and New API Functions

vCloud Director SP 8.10 has been out for about a month now and the general buzz around this release has been extremely positive. The decision to expose the previously API only features has been warmly welcomed by most vCloud Air Network Service Providers and I have heard of quiet a few looking to deploy or plan deployment of vCD SP 8.10 into their hosting platforms.

In Part One I went through the new NSX supportability improvements and for Part Two I am going to focus on a couple of Virtual Datacentre improvements that Organisational Clients can take advantage off with the upgrade. One of the key features now exposed directly to tenants is the ability to configure VM affinity and anti-affinity rules. I’ll also mention a couple of non UI exposed features like more granular vDC permissions, and being able to import running VM.

Virtual Machine Affinity Rules:

Support has been added for creation of affinity and anti-affinity rules for VMs. This is available via the vCD UI or the vCD API to create affinity rules that allow you to spread a group of virtual machines across different hosts or keep a group of virtual machines on a particular host. This is welcomed feature as it’s been a common question from customers who have asked us to keep or split VMs from the backend. I believe it’s also something that’s unique in the IaaS space and allows tenants greater control of VM placement that allows them to configure for certain applications or services requirements.

To configure this as a tenant head to the Administration Menu of the vCD UI and double-click on the Virtual Datacenter. From there you should see the Affinity Rules Tab as shown below.

Once there you have two sections where you can configure Affinity or Anti-Affinity Rules.

To configure the Rules, click on the + button, enter in a Rule Name and select the VMs you want to keep together or split up.

Note that it will error out if a VM is part of an existing rule as shown below.

You can not have the same VM of the same type in more than one rule. If you attempt this you will get a fairly unhelpful error complain talking about an incorrect or missing values.

Taking a look at vCenter, under the Clusters DRS Rules you will see the System created rules as shown below.

What I found interesting looking at the vCenter while the initial rules where create from the vCD UI was that a tiny drsShellVM (1 vCPU, 4MB RAM, No HDD, No Network) gets created during the process. At this stage I have not found out what this does or it’s purpose, but I was intrigued by it’s creation…if anyone can shed some light please comment below.

Overall this is an excellent feature and again…one that tenants will welcome.

vDC Permissions and Live VM Migrations:

I am not going to go dig deep into these features as Tom Fojta has already put through a couple of awesome posts around these and given some examples about how to make the API calls to configure them, but they are worth listing out and mentioning as they do extend the granularity of control in vDC permissions and allow for the importing of a running VM into vDC which had previously been an offline only thing.

Organization VDC Permissions in vCloud Director

Import Running VM to vCloud Director

The implication of the live running import is that together with xVC-vMotion you could think about doing cross VC imports either between IaaS providers or from a customers on-premises site…given the right networking is in place.

References:

https://fojta.wordpress.com/ 

http://www.virtuallyghetto.com/2015/02/did-you-know-of-an-additional-cool-vmotion-capability-in-vsphere-6-0.html 

http://pubs.vmware.com/Release_Notes/en/vcd/8-10/rel_notes_vcloud_director_8-10.html

4 comments

  • Hi Anthony

    Quite enjoy your blog posts, thanks for the content you provide.

    Out of interest have you found any information around the drsShellVm that gets created automatically?

    Kind Regards,
    Benjamin Coetzer

  • Pranshu Jain

    Hi Anthony and Benjamin,

    Regarding your question about the need of drsShellVm and why is it created: In short, In case you end up creating a DRS rule from VCD which comprises of VMs belonging to different clusters in VC, then it is possible that one of the rules may have a single VM as a part of a DRS rule (which is not allowed). So, a dummy VM is created so that each rule can have a minimum of two VMs and is created successfully on VC.

    For more details, I think this post answers it perfectly:

    http://www.vscratchpad.com/vcd-affinity-rules-and-drsshellvm/

    Thanks to Dave for explaining it.