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.
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.
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?
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
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
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”
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.
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.
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
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