[libvirt-users] cgroup for VM - does it work properly?

[sylecn]

Hi Eric,

Sorry to hijack this thread.

Have you used vcpu_quota in production? I have come across a CPU stall
problem when vcpu_quota is effective not long ago and I'm still looking for
an answer.

For example, when I set
virsh schedinfo <id> --set vcpu_quota=5000

Then no matter the vm is loaded or idle, in about two weeks, sometimes
sooner, the vm will have CPU stall in dmesg log. The CPU stall problem
makes system not responsible and results in network failure, i.e. ping and
ssh will fail. I have tried a few guest distro (ubuntu, CentOS, debian)
with different kernel version (3.2, 3.8) and they all have this problem.

Do you have any idea what's behind the scenes?

The software I am running:
hypervisor os: ubuntu 12.04.3
hypervisor kernel: 3.8.0-35-generic
vm os: ubuntu 12.04  // I have tried other OSes.
vm kernel: 3.2.0-56-virtual
libvirt: 1.1.1-0ubuntu8~cloud2



*YY Inc. is hiring openstack and python developers. Interested? Check
http://www.nsbeta.info/jobs <http://www.nsbeta.info/jobs>*

--
Thanks,
Yuanle


On Thu, Mar 6, 2014 at 7:42 AM, Eric Blake <eblake at redhat.com> wrote:

> On 03/05/2014 04:32 PM, Martin Pavlásek wrote:
> > Hi
> >
> > I tried to restrict usage of some running VM by cpu.shares (i.e. set to
> > 10 from original 1024) on loaded system and it seem doesn't work as I
> > expected... all running processes has same CPU usage (by htop) :-/
>
> How exactly are you changing the cgroup settings?  Are you trying to
> directly modify cgroup files (unsupported), or using the libvirt API
> (such as via virsh schedinfo)?
>
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
> _______________________________________________
> libvirt-users mailing list
> libvirt-users at redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20140306/13c1cb4a/attachment.htm>