VMware stubs its toe again: NSX has another VM-flattening bug

No resolution for flaw that sees VMs lose network connectivity


VMware says its NSX network virtualisation product is growing fast … perhaps too fast, because it's again been found to have a nasty bug.

Virtzilla struck trouble with NSX 6.2.3, which was first declared unsuitable for implementation and then pulled from distribution entirely.

VMware CEO Pat Gelsinger described that incident as a “stubbed toe”. What injury to what part of the anatomy might he therefore invoke given news of an NSX 6.2.4 bug that means virtual machines can sometimes lose network connectivity?

This bug's not as bad as those in 6.2.3, as only those upgrading from 6.1.x experience the problem.

But it's still not a good look.

VMware has no resolution for the problem at present. The company says it is “is actively working on a permanent fix in future NSX for vSphere releases.”

Happily, there is a workaround in the form of a script and accompanying procedure that VMware support will supply to the afflicted. There's only ~1,900 of those, because NSX remains a niche concern. But VMware says NSX is maturing to the point at which it will be embraced by more, and smaller, customers. NSX is also at the heart of the Cloud Foundation product launched at VMworld, which look to be one of VMware's key weapons with which to combat Azure Stack. VMware's Project Goldilocks security product also looks to have more than a little NSX under the hood.

Future NSX bugs will, therefore, have the potential to be more than just embarrassing inconveniences.

VMware blogger Anthony Spiteri has written a post about this problem that concludes with “VMware customers shouldn’t have to be the ones discovering these bugs!” ®

Similar topics


Other stories you might like

  • Pentester pops open Tesla Model 3 using low-cost Bluetooth module
    Anything that uses proximity-based BLE is vulnerable, claim researchers

    Tesla Model 3 and Y owners, beware: the passive entry feature on your vehicle could potentially be hoodwinked by a relay attack, leading to the theft of the flash motor.

    Discovered and demonstrated by researchers at NCC Group, the technique involves relaying the Bluetooth Low Energy (BLE) signals from a smartphone that has been paired with a Tesla back to the vehicle. Far from simply unlocking the door, this hack lets a miscreant start the car and drive away, too.

    Essentially, what happens is this: the paired smartphone should be physically close by the Tesla to unlock it. NCC's technique involves one gadget near the paired phone, and another gadget near the car. The phone-side gadget relays signals from the phone to the car-side gadget, which forwards them to the vehicle to unlock and start it. This shouldn't normally happen because the phone and car are so far apart. The car has a defense mechanism – based on measuring transmission latency to detect that a paired device is too far away – that ideally prevents relayed signals from working, though this can be defeated by simply cutting the latency of the relay process.

    Continue reading
  • Google assuring open-source code to secure software supply chains
    Java and Python packages are the first on the list

    Google has a plan — and a new product plus a partnership with developer-focused security shop Snyk — that attempts to make it easier for enterprises to secure their open source software dependencies.

    The new service, announced today at the Google Cloud Security Summit, is called Assured Open Source Software. We're told it will initially focus on some Java and Python packages that Google's own developers prioritize in their workflows. 

    These two programming languages have "particularly high-risk profiles," Google Cloud Cloud VP and GM Sunil Potti said in response to The Register's questions. "Remember Log4j?" Yes, quite vividly.

    Continue reading
  • Rocket Lab is taking NASA's CAPSTONE to the Moon
    Mission to lunar orbit is further than any Photon satellite bus has gone before

    Rocket Lab has taken delivery of NASA's CAPSTONE spacecraft at its New Zealand launch pad ahead of a mission to the Moon.

    It's been quite a journey for CAPSTONE [Cislunar Autonomous Positioning System Technology Operations and Navigation Experiment], which was originally supposed to launch from Rocket Lab's US launchpad at Wallops Island in Virginia.

    The pad, Launch Complex 2, has been completed for a while now. However, delays in certifying Rocket Lab's Autonomous Flight Termination System (AFTS) pushed the move to Launch Complex 1 in Mahia, New Zealand.

    Continue reading

Biting the hand that feeds IT © 1998–2022