Hi Nicolas,
you are right, the log shows exactly the right values. Those numbers
are exactly what is sent to libvirt using currentMemory field in
So if the VM does not have enough memory, we will have to start looking there.
Best regards
Martin Sivak
On Wed, Mar 29, 2017 at 11:04 AM, <nicolas(a)devels.es> wrote:
Hi Martin,
I do, I'm attaching it. I merged the full day's log into one. Significant
hours start at 11:24:57 (log time). The interesting machine is called
jbaspre01, and as per what I can deduce, the values in log are correct (it
never goes under the threshold of 1GB, which is its minimum). However, my
colleagues and I are 100% sure we saw this machine having about 600K KiB
when running top.
This machine has:
Memory size: 8196 MB
Minimal guaranteed memory: 1024 MB
If you need additional information don't hesitate to ask.
Regards.
El 2017-03-29 09:44, Martin Sivak escribió:
>
> Hi Nicolas,
>
> KiB Mem tells you how much memory the host has. I am actually more
> interested in the VM. Do you still have the mom.log from the time this
> happened? We keep the logs for some time (they are rotated).
>
> Best regards
>
> Martin
>
> On Wed, Mar 29, 2017 at 10:28 AM, <nicolas(a)devels.es> wrote:
>>
>> El 2017-03-28 15:33, Martin Sivak escribió:
>>>>
>>>>
>>>> min guaranteed should be respected, adding mom maintainer Martin
>>>
>>>
>>>
>>> I can't really help without the mom.log and the virsh dumpxml output
>>> of that VM in the final state (all memory ballooned).
>>>
>>> Min guaranteed should be respected, but the question is how the
>>> physical memory was measured (which number from top was used).
>>>
>>> --
>>> Martin Sivak
>>> SLA / oVirt
>>>
>>
>> Hi Martin,
>>
>> I tried to reproduce the issue again and I was unable to. I had a host
>> with
>> ~90% of RAM utilization and in mom.log I could see that ballooning was
>> indeed happening, but I couldn't see a VM going under its minimum
>> guaranteed
>> threshold (at least not significantly).
>>
>> On top, I was using the 'KiB Mem' value to compare. I know this is in
KiB
>> and that oVirt has its values as MB in the webadmin, but when I sent this
>> message the difference was quite more significant (1024MB of minimum
>> guaranteed and about 640K KiB on the VM).
>>
>> It's also true that meanwhile we upgraded from 4.0.2 to 4.1.1 and this
>> time
>> I couldn't reproduce it anymore.
>>
>> If at some point I am able to reproduce it again, I'll send detailed logs
>> of
>> the issue.
>>
>> Thanks.
>>
>>
>>> On Tue, Mar 28, 2017 at 4:29 PM, Michal Skrivanek
>>> <michal.skrivanek(a)redhat.com> wrote:
>>>>
>>>>
>>>>
>>>>> On 27 Mar 2017, at 23:15, Nicolás <nicolas(a)devels.es> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I don't really know if this question is suitable on this list, as
I
>>>>> doubt it's an oVirt bug, neither I know if it shall be considered
a
>>>>> bug.
>>>>>
>>>>> We recently run a VM on a host that was memory over-used (around 80%
>>>>> of
>>>>> usage). The VM booted correctly, then we run "top" and saw
how
>>>>> physical RAM
>>>>> started decreasing every two seconds. At first it was 4GB, then less
>>>>> and
>>>>> less until it stabilized at around 600MB.
>>>>>
>>>>> Based on this (correct me if I'm wrong), we believe this is an
effect
>>>>> of
>>>>> having this VM with ballooning enabled, as it does exactly this: It
>>>>> adds/removes RAM depending on host decision. Thing is that this VM
had
>>>>> a
>>>>> minimal guaranteed RAM of 1GB, so even if this happened due to
>>>>> ballooning,
>>>>> I'm not sure if it should have honored the minimum guaranteed
RAM.
>>>>>
>>>>> When this happened, we run a 'ps' to see with what options
the qemu
>>>>> process was invoked, and parameters seemed correct (that's why I
don't
>>>>> know
>>>>> if it should be posted here or even if it's a bug).
>>>>
>>>>
>>>>
>>>> It does belong here, it’s a different component doing it “externally”
>>>> to
>>>> the qemu process- mom.
>>>>
>>>>>
>>>>> Is this the expected behavior?
>>>>
>>>>
>>>>
>>>> min guaranteed should be respected, adding mom maintainer Martin
>>>>
>>>> Thanks,
>>>> michal
>>>>
>>>>>
>>>>> Thanks.
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users(a)ovirt.org
>>>>>
http://lists.ovirt.org/mailman/listinfo/users
>>>>>
>>>>>
>>>>