One of my friends over in VMware support just gave me a heads-up on this issue. It affects virtual machines with anti-affinity VMDK rules defined (for keeping virtual machine disks on different datastores in a datastore cluster) when changing the Storage DRS automation level via scheduled tasks. The rule will be removed if you use the Storage DRS scheduler to change Storage DRS automation level from automatic to manual and then back to automatic. The result is that a VM which had an anti-affinity rule and has its VMDKs on different datastores could end up with its VMDKs on the same datastore after the scheduler runs.
I tried this out for myself on vSphere 5.1. I built my datastore cluster and placed it into Fully Automated mode. I then deployed a VM with two VMDKs and created an anti-affinity rule to keep my VMs on different datastores.
I then created my schedules, the first which sets the automation level of my Storage DRS from Fully Automated to Manual and the second to return my Storage DRS automation level from Manual back to Fully Automated.
Why would you do this? Well, it prevents any Storage vMotion operations occurring during certain parts of the day, for instance when you are backing up your virtual machines (note that it continues to surface recommendations, but does not automatically move any VMs). After the schedule has run, the rule is removed.
What I’ve noticed is that this appears to be an issue that can be reproduced if the configuration is done via the C# client. It does not appear to be reproducible if the configuration is done via the new web client. Anyway, we are aware of the issue and are working on a solution. However, if you use (or plan to use) the Storage DRS scheduler for changing the automation level of the cluster for whatever reason, watch out for this.
Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @VMwareStorage