Bug 829241

(In reply to comment #0)
........
> 
> Expected results:
> For step 3, should not get error, and get same result as step 4 and step 5.
> 
Sorry,  Expected results  should be " For step 4, should not get error, and get same result as step 5 and step 6."

> Additional info:
> For superior value will not get error.

I have to confirm this, but most probably this is a dup of Bug #767921. Could you run libvirtd with LIBVIRT_DEBUG=1, reproduce it and attach a /var/log/libvirt/lxc/toy.log when you have some spare time? Thanks

Please see next two comments:
1.libvitd.log for LIBVIRT_DEBUG=1;
2.toy.log.

Created attachment 590371 [details]
libvirtd.log

Created attachment 590372 [details]
toy.log

This is the same problem as with Bug #767921, for which there will be a workaround, however still this is a duplicate.

*** This bug has been marked as a duplicate of bug 767921 ***

Hi Martin,

I can still reproduce this bug with the latest package:
libvirt-0.10.2-16.el6.x86_64

# virsh -c lxc:/// define toy.xml 
Domain toy defined from toy.xml

# virsh -c lxc:/// start toy
Domain toy started

# virsh -c lxc:/// list 
 Id    Name                           State
----------------------------------------------------
 15353 toy                            running

# virsh -c lxc:///
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # list --all
 Id    Name                           State
----------------------------------------------------
 15353 toy                            running

virsh # dominfo toy
Id:             15353
Name:           toy
UUID:           386f5b25-43ee-9d62-4ce2-62c3809e47c1
OS Type:        exe
State:          running
CPU(s):         1
CPU time:       0.0s
Max memory:     500000 KiB
Used memory:    476 KiB
Persistent:     yes
Autostart:      disable
Managed save:   unknown

virsh # setmem toy 300
error: operation failed: Failed to set memory for domain

----> the first time to run this command will get error.

virsh # setmem toy 300

----> the second time do not get error.

virsh # dominfo toy
Id:             15353
Name:           toy
UUID:           386f5b25-43ee-9d62-4ce2-62c3809e47c1
OS Type:        exe
State:          running
CPU(s):         1
CPU time:       0.0s
Max memory:     500000 KiB
Used memory:    252 KiB
Persistent:     yes
Autostart:      disable
Managed save:   unknown

Was this a wrong closing as the Bug 767921(which this bug duplicated to) closed as duplicate to Bug 767921, and Bug 767921 has been verified?

Or this issue is caused by Bug 854552 - Cgroup out of memory ?

Should I re-open this bug or file another one ?

Thanks,
EricLee

The situation you're describing is reproducible without libvirt and everything comes from the kernel.  But I wouldn't necessarily say it is a bug.  When I check the memory usage, it is more than 300KiB before the limitation.  Limiting to 300KiB doesn't succeed, because kernel doesn't swap it out quickly enough.  The second try it succeeds, because enough of the data is swapped out already.

What is weird, though, is that I'm not experiencing this with kernel version 3.7.3 and process with bigger memory footprint, even though the neither the mem_cgroup_resize_limit() code nor MEM_CGROUP_RECLAIM_RETRIES has changed significantly between these two versions.  But I'm not a kernel developer, so that statement has most probably zero value.

I'd try reopening this on kernel to see if there is a possibility to fix it in an easy way.  I see it's not a dup of 767921 now, so sorry for that.

Per comment 9 , i reopen this bug to 6.5 with TestOnly flag only for tracking

Test again with
libvirt-0.10.2-29.el6.x86_64
kernel-2.6.32-426.el6.x86_64

virsh # dominfo test
Id:             2797
Name:           test
UUID:           2241b339-99e2-8224-3b10-102b5d9b689f
OS Type:        exe
State:          running
CPU(s):         1
CPU time:       0.0s
Max memory:     1048576 KiB
Used memory:    684 KiB
Persistent:     yes
Autostart:      disable
Managed save:   unknown

virsh # setmem test 300
error: operation failed: Failed to set memory for domain

virsh # setmem test 300
error: operation failed: Failed to set memory for domain

virsh # setmem test 300

virsh # dominfo test
Id:             2797
Name:           test
UUID:           2241b339-99e2-8224-3b10-102b5d9b689f
OS Type:        exe
State:          running
CPU(s):         1
CPU time:       0.0s
Max memory:     1048576 KiB
Used memory:    284 KiB
Persistent:     yes
Autostart:      disable
Managed save:   unknown


So does it need move to 6.6 or change back to assign ?

I think comment 9 still applies. Have you tried to open a bug for kernel as Martin suggested there?

Yes , see the depends on bug 908254

Ah, I'm apparently blind. I don't think we can do much without changing kernel behavior. Hmm, actually, I guess we could make it behave the same way it works in qemu driver where setmem is just a polite request to shrink the memory. If a specific errno is returned by kernel when shrinking memory doesn't succeed immediately because swapping takes some time, we could detect that error condition and ignore it. This way, setmem would succeed even though the memory was not shrunk to the requested size. In case this is not a viable solution, I suggest closing as CANTFIX. In any case, let's move this bug to 6.6 for further investigation.

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.