Slashdot Mirror
Massive VMware Bug Shuts Systems Down
mattmarlowe writes "Imagine if Red Hat released a version of Linux, and after it was deployed, customers noticed that any processes with a start date of today would refuse to run? Well, that's what happened to VMware — a company that wants nearly all server applications running in virtual machines within a matter of years." Supposedly a fix will be available ... in 36 hours.
I don't get license management measures in software that is only going to be used by major corporations.
If someone wants to run virtual machines at home or in a small business, they're likely going to be more than satisfied with VMWare Virtual Server (formerly GSX) and wouldn't even consider the much more complex ESX.
In a major corporation, fear of massive fines and prosecution is enough to stop them from pirating your software. Hardware dongles, software license managers and the like only hurt your paying customers.
I'm a big tall mofo.
any processes with a start date of today would refuse to run? Supposedly a fix will be available... in 36 hours.
Good thing the fix will be available tomorrow, because if it was available today nobody would be able to run the update process
If libertarians are so opposed to effective government, why don't they all move to Somalia?
I stick to virtualbox. I'm not going to pretend I've audited the source code, but if I need to, I can.
Say YES to freedom.
Do you even lift?
These aren't the 'roids you're looking for.
If you read the article, you'd know it's the license-management code. Licenses expire.
A workaround is possible Turn off NTP time on the host. And manually (using the VIC) change that date to one week backwards in time. Voila all set to work.
"Never EVER mess with a jumper you don't know about, even if it's labeled 'sex and free beer'." - Dave Haynie
My head hurts reading that article. Who the fuck wrote it? A ten year old mental retard?
It's like ............... this and VM's this VM's that (Yes, notice the spelling?). Ooooh and the cyberwarfare boogeyman! You can't even find this much Hollywood scenario fear mongering from Hollywood themselves. Oh noes! Our entire infrastructure will be killed by evil cyber terrorists because it runs on VMware!
Oh and and lovely parts like 'w/' instead of 'with'. Hey douchebag, this is not SMS, is it so hard to hit another 2 keys on your keyboard? Oh and for the love of $DEITY$, please learn basic HTML and use links so I don't have to copy paste text into the address bar.
As for Slashdot editors, why the fuck did they pick the worse possible article from the Firehose when plenty others look *WAY* more professional?
But the real bug is license enforcement in the first place. Why would you run the risk of making your business depend on the whims of someone else's IP policies and enforcement?
Now, I'm somewhat realistic. I know that there isn't (yet) an adequate replacement for every piece of closed proprietary software out there. But for my own business (admittedly small) I am building with nothing but GPL/BSD/Apache license code. And it is working. I don't trust closed code. Of course my software will have bugs, some of them serious. But I won't have stuff shutting down because of "license" issues. Why do people go quietly into enforced licenses? Why do people accept remote kill switches on their servers? Why doesn't this strike everyone as a crazy thing to do?
Ah, see, another reason why free software always is better
Taxation is legalized theft, no more, no less.
"Temporary Maintenance - Knowledge Base
This section of the VMware website is currently unavailable while we make important user improvements and upgrades to the site. We apologize for any inconvenience this may cause."
I hope it wasn't running on a VM.
VMWare licenses for ESX server cost something like $5k apiece. My company uses VMWare and I don't quite get it. We pay for expensive blade hardware ($8k each for those, not to mention the chasis), then we pay $5k per virtual server. And for what? Adding virtualization overhead to the runtime cost.
Meanwhile, in articles like this, people are showing how to run many applications and different versions within a single container. A single node in the cluster can run any application. There are always busy, keeping the hardware fully utilized. Isn't that the promise of utility computing? Rack up a bunch of cheaper (but not cheap/shoddy) servers and let your cluster go to town.
So, my question is, why are we (as an industry) embracing virtualization when apps written for a smart container (like OSGi) give the same benefits without all the additional co$t and runtime overhead?
...Says it all, I think. Perhaps you should reconsider the ramifications of making your business critically dependent on software that contains code specifically design to make it stop working.
Consider this: to a proprietary vendor the only safe failure mode for "license management code" is one where everything stops.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Um, isn't today Patch Tuesday? This could be worse than we thought.
One of our competitors trademarked the term "hypothesis". From now on, we will call them "boneheaded ideas".
Unless something has changed dramatically, an expired license won't bring down any already deployed VMs. It simply won't allow you to deploy undeployed ones. It doesn't shut down the VMs as the headline makes it sound nor is it a bug in the hypervisor. Yes it's embarrassing that this got out but can we have a less sensationalist headline and summary?
EvilCON - Made Famous by
Virtualbox has USB support...
The Open Source Model gets a leg up again after this nonsense. A client of mine just ported all their VMs and said good bye to VMware. That's 280 VMs by the way. Thank God we had a contingency plan for switching VM providers for a DR exercise a year ago and here we go.
Management is pretty upset and I doubt we will be switching back any time soon to VMWare products after this.
On a side note this scenario did prove one thing:
Having a VM-agnostic storage makes migration easy. We changed a mount point, powered on the alternate VM host and we were off and running just that quick. We lost the ability to do live migrations for now but beyond that is was a good opporunity to see just how important an VM-agnostic disk storage array is. (I'm not the admin of those machines but I believe we are using iSCSI).
On my side though I had about 50 scripts tapping VMWare via PERL but I guess I can start building workarounds now... No more batch submission and dynamic routing for a week or two... The part I hate the most was I had a nice script to take a batch submission and if necessary migrate a utility node to bigger hardware to accomidate the batch... pisses me off but what can I do, thank you Vmware, that aquisition seems to be improving your product as much as when Symantec aquired Ghost Corp!
-=[ Who Is John Galt? ]=-
VMware is suggesting setting the system time backwards to work around their license manager problem. That's a desperation move. Not only will it mess up everything from Kerberos to CVS to "make", if you're running certain licensed software, in particular software licensed via FlexLM, that software will stop working. FlexLM will disable your licenses if the clock goes backwards by more than 24 hours. Now your expensive high-end software protected by FlexLM (Rational, Avid, Matlab, National Instruments, ANSYS, Cisco Unity, Clearcase, Nokia network management, etc.) will stop working. Setting the clock forward again may not re-enable it, either; there's tamper detection.
Also, if you have server/client licensing with FlexLM, or multiple license servers, and the clocks disagree significantly, FlexLM gets suspicious and turns licenses off.
You know that you should read ./ before you do any actual work. Don't you?
:)
hany
In a major corporation, fear of massive fines and prosecution is enough to stop them from pirating your software.
Sadly, not true in the real world, as my company has discovered on more than one occasion.
Support for USB, iSCSI and RDP (along with USB-over-RDP) are only available in the closed source variants of VirtualBox.
The opensource edition of Virtual Box doesn't have them.
Also the USB support may lock the system when in fast emulation/patching/ring-2 mode, and only works flawlessly when using the slower mode with virtualisation CPU extensions (my brother tried using it to get old USB hardware accessible when moving to Vista 64 but since then he ended up buying newer hardware)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
If a virtual machine would support something like DirectX or OpenGL so that I could have the kids running their games in a virtual machine (and being able to install them, etc.) I would have them set up with a locked down OS with a virtual system for their games. {...} But I'm sure the technology is getting closer.
Yup. Indeed. /. mentioned recently "VMGL".
The extension is open source but currently only works for X11 OSes at both end.
But as you said, a working acceleration layer is bound to be developed in the near future for Windows too.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
*sigh*
Well, it's for real. I've confirmed it here, and my whole data center is affected.
It's time like this when I wish I hadn't left the Army; at least there, you can shoot back.
This is going to be one hell of a long night. :(
Regards;
I've been weighing up whether to migrate from VMware Server for our limited set of operations and move to ESXi and then ESX. This has made up my mind now. I'd rather wait for the hype of virtualisation to really settle down, use it in a pretty limited capacity and then run more stuff on technology and a host system that gets it right - KVM and Linux. I don't care too much about waiting, because as far as I'm concerned this just isn't acceptable. Many organisations will be brought to their knees by something like this, and over something that is totally unnecessary as well. I could understand pretty much any other issue, but not this. Sorry VMware.
but if I don't know what the hole looks like, I can't carve a peg to fit it
There are some I know who will put their pegs into any hole
Know your pads. One time pad: good for cryptography. Two timing pad: where to take your mistress.
I was thinking about the very problem of trusting your compiler, and the only thing I could come up with is building one from an open assembler.
I built gcc (1.4) with a C interpreter. It was slow as hell (and we did it mainly to stress-test the interpreter), but when I fed the source of gcc to the result, it did what I expected--built a system the same as the one that regular gcc built.
But the simple fact of the matter is that a little common sense should reveal that the whole notion is impossible in the real world. At the time Thompson wrote, there was, basically, one C compiler and one version of login, and neither one changed very much, so it was at least theoretically possible for a fairly simple program to recognize them. The sources to gcc have changed too much over the years to be recognizable to anything less than a hard-AI system, i.e., something that doesn't exist (and if it did, you'd notice, since it would take hours to compile even the simplest app). Toss in drastically different compilers from vendors like Sun, IBM, Intel and HP, and the whole thing becomes even more ridiculous. But if you really want to check, write your compiler in another language (one that doesn't compile to assembler, like Java or Python).
How can you reference Ken Thompson's "Reflections on Trusting Trust" (HTML/non-PDF version) without also mentioning David A. Wheeler's "Countering Trusting Trust" (as found via Bruce Schneier's blog)? So to answer your question:
What if you can't even trust your compiler?
Well so long as I have another set of compilers AND at least one is trustworthy then there is process I can follow to build a compiler I can trust. After spotting differences in the resulting binary I would also need to (ah-ha) examine the source code of the used compilers and find out which one is mis-generating the binary and fix it.
At some point I need to be able to understand binary and read the source of the compiler that generated that binary to ensure that someone else is not jacking me.
but...
If you actually know what you are doing, Access is actually a pretty good development platform. It really is what VB should have been all along. Doing it correctly isn't for the faint of heart nor the inexperienced "guy who knows computers in the department" developer though. It's a LOT of work.
The biggest issue is that MS markets it as a database app, not a dev platform.
But there are some caveats to its use.
1. Never bind controls that can be edited to any datasource. Sorry, but you really need to write code to fill them in, check them, then write them to the back end.
2. Never store any data in an MDB file. Always use a real backend server such as MSSQL, Oracle, or even Postgres or MySQL.
3. Once it works, create an MDE file and only run MDEs on clients, never the "source" MDB.
4. You are checking your db schema revision and comparing it to allowed client app revisions, right?
Still, there are newer platforms available, and quite often a web-based app will be easier to build and maintain.
The article also says that he'd recommend disabling DRS because that would remove resource pools, and goes on to say set the sensitivity to 5. What would be the more correct course of action, would be to set your DRS Cluster to Manual, which is indicating no automation, DRS will not place or move VMs.