Yellow Bricks

by Duncan Epping

BC-DR

Schedule it today, VMworld Europe 2011, sign up for #VSP1682 and #GD43

· ·

I just looked at the VMworld website and it seems that most sessions are filling up quickly, including my sessions. If you want to to attend these sessions make sure you schedule them rather sooner than later! These are my sessions:

  • Tuesday 13:30 – EXPERTS-01  – Knowledge Experts One-on-One
    These are 15 minute one-on-one session where you will get the chance to ask me anything. So if you want to sit down and discuss something make sure to schedule / book it!
  • Wednesday 15:00 – VSP1682  VMware vSphere Clustering Q&A  (Twitter hashtag: #VSP1682)
    Our Q&A session… Frank Denneman and I will be answering anyone question related to HA, DRS, DPM or Storage DRS. Chris Colotti will be moderating it! We will be giving away a bunch of signed copies of our book again to those who manage to ask a question which stumps us. As Chris likes to call it stump the chumps.
  • Thursday 11:00 – GD43  vSphere Clustering with Duncan Epping (Twitter hashtag: #GD43)
    This is a true group discussion. Room for roughly 50 people and I will ask several questions around HA / DRS / SDRS and we will discuss scenarios / environments / challenges. Make sure to sign up quickly as there are only 50 spots available!

Frank and I are also planning a book signing session, as soon as we have the details we will fill you in!

Does SRM support Storage DRS? No it does not!

· ·

During VMworld I received multiple questions around support for vSphere Storage DRS with vSphere Site Recovery Manager (SRM), we even had this question during our session and my answer was “Yes it does”. During some of the other sessions presenters stated that it was unsupported. Scott Lowe also mentions recalling the fact that it was mentioned somewhere down the line to be unsupported. Now although the Resource Management Guide for vSphere 5.0 on page 91 currently says it is supported it is not supported. Yes I know I stated it was supported but unfortunately the document is incorrect and the information provided to me was outdated. Although I verified the facts, I was not informed about this change. Hopefully this will not happen again and my apologies for that.

Now lets give the raw facts first, SRM does not support Storage vMotion and SRM does not support Storage DRS. The reason that SRM does not support Storage vMotion (and subsequently Storage DRS) is because it changes the location of the virtual machine without SRM being aware of it. After the location of the virtual machine has changed the VM that was originally protected by SRM will not be protected anymore which can have an impact on your RTO. These are the raw facts. I have requested the SRM team to document this in a KB to make sure everyone understands the reason and the impact.

The question of course is… will it work? My colleague Cormac has tested it and you can read his observations here.

This statement is documented in the SRM releasenotes: http://www.vmware.com/support/srm/srm_releasenotes_5_0_0.html

Interoperability with Storage vMotion and Storage DRS:
Due to some specific and limited cases where recoverability can be compromised during storage movement, Site Recovery Manager 5.0 is not supported for use with Storage vMotion (SVmotion) and is not supported for use with the Storage Distributed Resource Scheduler (SDRS) including the use of datastore clusters.

** update: I followed the documentation which apparently was incorrect. Documentation bug has been filed, should be update in the near future. **
** update: Link to SRM releasenotes with statement added. **

Mandatory DRS Rules and HA

· ·

On twitter Mike Laverick asked a question around DRS Affinity Rules and if HA would respect these. In this particular instance the question was around VM-Host affinity rules and I noticed multiple tweeps responding and figured it would not hurt to repeat this.

There are two different types of VM-Host affinity rules:

  1. Must aka mandatory
  2. Should aka preferential

The difference between these two with regards to HA is that HA will always respect a must rule. These are mandatory, even if that results in downtime for the VM. The should rule is also known as the preferential rule. In others words it would be nice if this rule can be respected, but if it can’t… no harm.

How does HA know which VM belongs to which host with regards to DRS rules? Well that is fairly straight forward. HA keeps track of which VM is compatible with which hosts. This “VM to Host compatibility list” is used for portgroups and datastores but also for DRS rules. Check the screenshot below for a hint…

Mandatory DRS Rules and HA

Please note, this is a very old article about HA, there are tons of new articles on this topic. Just do a search on my blog, or download my ebook freely available via Rubrik.

Partitioned Cluster with HA vSphere 5, who owns what?

· ·

I received a question today about a partitioned clusters (in vSphere 5.0) with HA. The question was which Master would own which VMs when a partition exists and how is determined which master can own which VM? I have already briefly explained the difference between an isolation and a partition. Now it is good to realize that when a partition exists the new master may take responsibility for VMs. I used “may” intentionally as there is no guarantee it will own any VMs at that point, so why is this and how does it take ownership of VMs?

A master takes ownership of VMs by locking a file on the datastores it is connected to. As soon as the master has an exclusive lock it owns the virtual machines that have their config file on the datastore. (Note that HA cares about the .vmx file and not the VMDK of the VMs.) The file is called “protectedlist” and is stored on each of the datastores under the .vSphere-HA folder as shown in the screenshot below.

Now a master will only release the lock on that file when it is placed in to maintenance mode, removed from the cluster, loses access to the datastore, is rebooted etc. If and when that would happen the other master(s) would take ownership of the VMs which are located on that datastore by locking that file. So what does that mean?  That does indeed mean that in a “normal” situation even though you have two or more masters in a cluster, due to the fact the cluster is partitioned, you would still only have 1 master being responsible for all VMs in that cluster. Unless… unless that master is indeed placed in maintenance mode, loses access to the datastore etc.

Hope that clarifies things,

** edit: changed the wording to clarify the behavior of the master with regards to owning VMs **