I've seen people do this before, yep it's a VM killer!

If it is only a VM killer, a problem inside the VM, it will be no problem... Then i can say, my fault, reconfigure and restart the VM.

The really big problem was, that the VM can't be managed. I logged in to the host and tryed to power off the VM, not possible...

I am of the opinion, this behavior must be prevent.

I meant the VM as a manageable entity, not only the guest OS and all services - everything about it as an object.

So what sense make it, to make it possible, to enter here a "0", with such fatal impact.

What can i do that my suggestion will be heraed/discussed etc.

But when you tell me that this a VM killer, so VMware seems to be aware of that problem.

Will there be a change in the future?

Me telling you what I’ve said doesn’t mean that VMware are aware, nor do I have any idea whether the setting will be changed in future.

I used to work for training partners as an instructor, that’s when I saw this happen, it was probably on ESX v3 at the time.

Log a support request (if you have a contract).

O.k. the customer has a contract, but i was thinking, when vmware is aware of this problem, there is no need to open a case and i can spend my time for more important things.

I am repeating myself, just because I have seen this before (a long time ago) does not mean “VMware is aware” - consider also that this is a community forum, not an official support forum.

I am stepping off this thread now.

Sorry for my bad english, my last post should be read as comment, not as question....

I would suggest to regard this issue as just another flaw in the web ui.

If you run into issues like this - unregister the VM and edit the vmx-file manually and register the VM again.

But in this situation the VM was powered on, i can't unregister.

The only way was to "kill" the VM tasks on the host. When the VM is powered off, i was able co correct the setting.

If you have a test environment, power on a test VM, when running set a CPU limit to "0", save and try to do something with that VM after that change.

i had this issue today on 2 VMs 

the first i managed to shutdown and change the CPU limit to unlimited ok (the second I had to reboot host)

if you initiate a shutdown in VC the job will just fail, but if you initiate a reset or hard stop the job will hang (important).

if you follow this advice Unable to Power off a Virtual Machine in an ESXi host (1014165) (vmware.com)

then as long as there is a job queued to perform this action you should be ok.

otherwise if you kill the VM then you still can't power it off from the host and you have to evacuate all the other VMs on the host and reboot

(be careful if you have HA enabled as will failover with the same settings! i just managed to make the change before HA kicked in).

I am happy to file a bug against this, but I guess even 1MHz as a minimum wouldn't help much as it would probably bring the VM also to a full stop

Requested a warning to be added. In general I have advocated to move these settings somewhere else to begin with, there aren't many useful usecases for limits.

I don't think that someone will enter here a CPU limit of 1 or 10, the problem is that i was thinking 0 will disable the limit -> "0=unlimitd"

I think it will be o.k. that a 0 will not be accepted or 0 will be interpreted as unlimited.

To be honest, I went through the workflow, and when you click the dropdown it is pretty obvious (to me) that 0 is not disabled, but I have asked to get is clarified.

As i wrote in my first post: "i didn't noticed the drop down field where i can select unilimited."

Direct above is the "Reservation", where 0 is no reservation, it is a filed to enter a value by hand, here i don't expect a drop down field.

But this is a misatke which will be done only a single time, this i will remeber for ever.

Yeah, I just did this today thinking that entering "0" was unlimited  

 now it's stuck and I have to go through those annoying steps

ugh have they still not fixed this? hmm

Unfortunately not fixed, I filed a bug for it a while back, asked the engineers to look at it again.