Just a second ago the GSS/KB team republished the KB article that explain the vSphere 5.0 problem around SvMotion / vDS / HA. I wrote about this problem various times and would like to refer to that for more details. What I want to point out here though is that the KB article now has a script attached which will help preventing problems until a full fixed is released. This script is basically the script that William Lam wrote, but it has been fully tested and vetted by VMware. For those running vSphere 5.0 and using SvMotion on VMs attached to distributed switches I urge you to use the script. I expect that the PowerCLI version will also be attached soon.
Bilal Hashmi says
Just so that there is no confusion, this still means that the issue still exists. Which means the fix should be followed by every storage vMotion. This also means, it would be best to disable SDRS until a fix is provided like Duncan stated in his earlier posts. This is a workaround for when you have to storage vMotion a VM managed by vCenter 5 and to ensure HA will protect it when the time comes.
Diego Cogo says
I’m using this recommended script, but I’m getting a lot of “Unable to check VM NAMEOFTHEVM” errors.
BTW, I’m using the proper credentials because some VMs could be fixed with this script.
Any ideas?
William Lam says
You can create an alarm which will automatically remediate a VM that has been SvMotion, here is an article with the details http://www.virtuallyghetto.com/2012/04/automatically-remediating-svmotion-vds.html
This way you’ll ensure that your environment is re-protected for every SvMotion (manual/automated)
-William
William Lam says
Hi Diego,
Could you provide some details about your environment? Version, # of hosts, # of VMs, vCLI version or using vMA? Are you able to query for impacted VMs, but just when remediation that’s having the problem?
–William
Diego Cogo says
Hi William,
I have vCenter 5.0 Build 455964 with ESXi 5.0.
40 hosts and aroung 130 VMs now.
I’m using latest vMA.
Some impacted VMs were successfully fixed but a lot of them are showing the message: “Unable to check VM NAMEOFVM”
Rhett says
I also getting the “Unable to check VM *vmname*” entries. I’m running ESXi 5, vCenter 5 with the N1KV. I’ve tried running the script against vCenter and host the hosts individually with no success. This happens when running just the query and with the fix=true flag.
Lincoln says
Hey Diego, I was having the same “Unable to check VM” problem and tracked it down to using spaces in our datastore names. The script parses the vmx path by splitting on spaces so the datastore name gets screwed up. And yes I am renaming my stores to avoid this in the future.
To fix the script find this line:
my ($datastoreName,$junk) = split(‘ ‘,$vmConfigPath);
and replace with these two:
my ($datastoreName,$junk) = split(‘] ‘,$vmConfigPath);
$datastoreName = $datastoreName . “]”;
Hope that helps.
Diego Cogo says
Hi Lincoln,
That did the trick! It’s working now.
I hope William updates his awesome script to reflect this change.
Thank you very much!
-Diego Cogo
William Lam says
Hi Lincoln/Diego,
Thanks for your feedback and identifying/fixing the issue. I will get in touch with our KB team to get this updated into the script and re-published.
Thanks and feel free to post here or on my personal blog if you run into any issues.
Thanks