On 11/9/18 1:08 PM, Rafael Weingärtner wrote:
> For me, that seems some restrictions in paid productions. “you are client
> type X, then you can start only Y VMs”, and this has been a legacy around
> our code base. We could very much remove this limit (on instance numbers);
> I expect operators to know what they are doing, and to monitor closely the
> platforms/systems they run. The management of other resources such as RAM,
> CPU, and others, I still consider them necessary though.
>
That might be the case indeed. I think this can be removed completely,
but it's a lot of code around this. In the end it is a boolean which
tells if the hypervisor has reached the limit or not.
I will look into it.
Wido
> On Fri, Nov 9, 2018 at 10:03 AM Wido den Hollander <w...@widodh.nl> wrote:
>
>>
>>
>> On 11/9/18 12:56 PM, Andrija Panic wrote:
>>> afaik not - but I did run once or twice intom perhaps looselym connected
>>> issue - ACS reports 100% of host RAM (makes sense) asavailable for VM
>>> deployment to ACS - so in 1-2 cases I did run into out of memory killer,
>>> crashing my VMs.
>>>
>>> It would be great to have some amount of "reserve RAM" for host OS - or
>>> simply have PER HOST RAM disableTreshold setting, similar to cluster
>> level
>>> "cluster.memory.allocated.capacity.disablethreshold", just on host
>> level...
>>>
>>
>>
>> You can do that already, in agent.properties you can set reserved memory.
>>
>> But I doubt indeed that we need such a limit in ACS at all, why do we
>> need to limit the amount of Instances on a hypervisor?
>>
>> Or at least set it to a very high number by default.
>>
>> Wido
>>
>>> On Fri, 9 Nov 2018 at 12:03, Rafael Weingärtner <
>> rafaelweingart...@gmail.com>
>>> wrote:
>>>
>>>> Do we need these logical constraints in ACS at all?
>>>>
>>>> On Fri, Nov 9, 2018 at 6:57 AM Wido den Hollander <w...@widodh.nl>
>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 11/8/18 11:20 PM, Simon Weller wrote:
>>>>>> I think these is legacy and a guess back in the day. It was 50 at one
>>>>> point and it was lifted higher a few releases. ago.
>>>>>>
>>>>>
>>>>> I see. I'm about to do a test with a bunch of 128GB hypervisors and
>>>>> spawning a lot of 128M VMs. Trying to see where the limit might be and
>>>>> also stress the VR a bit by loading a lot of DHCP entries.
>>>>>
>>>>> Wido
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ________________________________
>>>>>> From: Ivan Kudryavtsev <kudryavtsev...@bw-sw.com>
>>>>>> Sent: Thursday, November 8, 2018 3:58 PM
>>>>>> To: dev
>>>>>> Subject: Re: KVM Max Guests Limit
>>>>>>
>>>>>> Hi all, +1 for higher numbers.
>>>>>>
>>>>>> чт, 8 нояб. 2018 г. в 16:32, Wido den Hollander <w...@widodh.nl>:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I see that for KVM we set the limit to 144 guests by default, can
>>>>>>> anybody tell me why we have this limit set to 144?
>>>>>>>
>>>>>>> Searching a bit I found this:
>>>>>>> https://access.redhat.com/articles/rhel-kvm-limits
>>>>>>>
>>>>>>> "This guest limit does not apply to Red Hat Enterprise Linux with
>>>>>>> Unlimited Guests. There is no guest limit for Red Hat Enterprise
>>>>>>> Virtualization"
>>>>>>>
>>>>>>> There is always a limit somewhere, but why do we set it to 144?
>>>>>>>
>>>>>>> I would personally vote for increasing this to 500 or something so
>>>> that
>>>>>>> users don't run into it that easily.
>>>>>>>
>>>>>>> Also, the log line is printed in DEBUG mode only when a host reaches
>>>>>>> this limit, so I created a PR to set this to INFO:
>>>>>>> https://github.com/apache/cloudstack/pull/3013
>>>>>>>
>>>>>>> Any input?
>>>>>>>
>>>>>>> Wido
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> With best regards, Ivan Kudryavtsev
>>>>>> Bitworks LLC
>>>>>> Cell RU: +7-923-414-1515
>>>>>> Cell USA: +1-201-257-1512
>>>>>> WWW: http://bitworks.software/ <http://bw-sw.com/>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Rafael Weingärtner
>>>>
>>>
>>>
>>
>
>
