• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

KB article about SvMotion / VDS / HA problem republished with script to mitigate!

Duncan Epping · May 16, 2012 ·

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.

http://kb.vmware.com/kb/2013639

Share it:

  • Tweet

Related

Server 5.0, ha, vds, vSphere

Reader Interactions

Comments

  1. Bilal Hashmi says

    16 May, 2012 at 19:22

    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.

  2. Diego Cogo says

    16 May, 2012 at 19:33

    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?

  3. William Lam says

    16 May, 2012 at 20:32

    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

  4. William Lam says

    17 May, 2012 at 02:13

    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

  5. Diego Cogo says

    17 May, 2012 at 12:48

    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”

  6. Rhett says

    17 May, 2012 at 15:30

    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.

  7. Lincoln says

    17 May, 2012 at 16:54

    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.

  8. Diego Cogo says

    17 May, 2012 at 18:22

    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

  9. William Lam says

    17 May, 2012 at 19:02

    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

Primary Sidebar

About the author

Duncan Epping is a Chief Technologist in the Office of CTO of the Cloud Platform BU at VMware. He is a VCDX (# 007), the author of the "vSAN Deep Dive", the “vSphere Clustering Technical Deep Dive” series, and the host of the "Unexplored Territory" podcast.

Upcoming Events

29-08-2022 – VMware Explore US
07-11-2022 – VMware Explore EMEA
….

Recommended Reads

Sponsors

Want to support Yellow-Bricks? Buy an advert!

Advertisements

Copyright Yellow-Bricks.com © 2022 · Log in