[libvirt-users] snapshot create error, unable to find cgroup for vm
Hello: Yesterday I yum update libvirt from 0.9.10 to 0.10.2 ,after update I got some error in libvirtd.log like this: 2013-05-10 07:39:09.440+0000: 18824: warning : virCgroupMoveTask:885 : no vm cgroup in controller 3 2013-05-10 07:39:09.440+0000: 18824: warning : virCgroupMoveTask:885 : no vm cgroup in controller 4 2013-05-10 07:39:09.440+0000: 18824: warning : virCgroupMoveTask:885 : no vm cgroup in controller 6 so,I restarted cgconfig and libvirtd daemon : service cgconfig restart ; service libvirtd restart after that ,I cannot create snapshot for vm anymore.and error log message below: 2013-05-16 01:13:23.638+0000: 28848: error : qemuDomainSnapshotCreateDiskActive:11299 : internal error Unable to find cgroup for vm1 my version info : # rpm -q libvirt libvirt-0.10.2-18.el6_4.4.x86_64 # rpm -q qemu-kvm qemu-kvm-0.12.1.2-2.295.el6_3.1.x86_64 in /cgroup dir I cannot find anything about vm1.how can I recover the missing cgroup for vm ? thanks !
On 05/15/2013 07:32 PM, Gao Yongwei wrote:
Hello: Yesterday I yum update libvirt from 0.9.10 to 0.10.2 ,after update I got some error in libvirtd.log like this: 2013-05-10 07:39:09.440+0000: 18824: warning : virCgroupMoveTask:885 : no vm cgroup in controller 3 2013-05-10 07:39:09.440+0000: 18824: warning : virCgroupMoveTask:885 : no vm cgroup in controller 4 2013-05-10 07:39:09.440+0000: 18824: warning : virCgroupMoveTask:885 : no vm cgroup in controller 6
Red herring. This is a warning, and has nothing to do with the actual error (it has since been patched in upstream libvirt).
so,I restarted cgconfig and libvirtd daemon :
service cgconfig restart ; service libvirtd restart
after that ,I cannot create snapshot for vm anymore.and error log message below: 2013-05-16 01:13:23.638+0000: 28848: error : qemuDomainSnapshotCreateDiskActive:11299 : internal error Unable to find cgroup for vm1
my version info : # rpm -q libvirt libvirt-0.10.2-18.el6_4.4.x86_64
Are you using RHEL? If so, please open a support incident with Red Hat. If not, can you reproduce the problem when you upgrade to libvirt 1.0.5? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Are you using RHEL? If so, please open a support incident with Red Hat.
If not, can you reproduce the problem when you upgrade to libvirt 1.0.5?
Hello Blake ,I am using CentOS6.4 ,but I got this trouble in my production environment . I will test 1.0.5 later ,now I am very worried ;(
2013/5/16 Gao Yongwei <itxx00@gmail.com>
Are you using RHEL? If so, please open a support incident with Red Hat.
If not, can you reproduce the problem when you upgrade to libvirt 1.0.5?
Hello Blake ,I am using CentOS6.4 ,but I got this trouble in my production environment . I will test 1.0.5 later ,now I am very worried ;(
Hello Blake, I've submited a new bug :
2013/5/16 Gao Yongwei <itxx00@gmail.com>
2013/5/16 Gao Yongwei <itxx00@gmail.com>
Are you using RHEL? If so, please open a support incident with Red Hat.
If not, can you reproduce the problem when you upgrade to libvirt 1.0.5?
Hello Blake ,I am using CentOS6.4 ,but I got this trouble in my production environment . I will test 1.0.5 later ,now I am very worried ;(
Hello Blake, I've submited a new bug :
Hello Blake ,here are some debug log info : http://paste.ubuntu.com/5669714/ thanks.
On 05/15/2013 10:32 PM, Gao Yongwei wrote:
Are you using RHEL? If so, please open a support incident with Red Hat.
If not, can you reproduce the problem when you upgrade to libvirt 1.0.5?
Hello Blake ,I am using CentOS6.4 ,but I got this trouble in my production environment . I will test 1.0.5 later ,now I am very worried ;(
Hello Blake, I've submited a new bug : https://bugzilla.redhat.com/show_bug.cgi?id=963514 thanks.
Hello Blake ,here are some debug log info : http://paste.ubuntu.com/5669714/
An ubuntu pastebin for a CentOS issue seems a bit... odd. Unfortunately, pastebins tend to expire, so linking to them in mail isn't always the most reliable, compared to just pasting relevant sections inline. 2013-05-16 04:08:11.063+0000: 21636: debug : qemuDomainObjBeginJobInternal:813 : Starting async job: snapshot 2013-05-16 04:08:11.103+0000: 21636: debug : virFileClose:72 : Closed fd 23 2013-05-16 04:08:11.103+0000: 21636: debug : virCgroupNew:617 : New group /libvirt/qemu/testvm 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupDetect:273 : Detected mount/mapping 0:cpu at /cgroup/cpu in 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupDetect:273 : Detected mount/mapping 1:cpuacct at /cgroup/cpuacct in 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupDetect:273 : Detected mount/mapping 2:cpuset at /cgroup/cpuset in 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupDetect:273 : Detected mount/mapping 3:memory at /cgroup/memory in 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupDetect:273 : Detected mount/mapping 4:devices at /cgroup/devices in 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupDetect:273 : Detected mount/mapping 5:freezer at /cgroup/freezer in 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupDetect:273 : Detected mount/mapping 6:blkio at /cgroup/blkio in 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupMakeGroup:535 : Make group /libvirt/qemu/testvm 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupMakeGroup:560 : Make controller /cgroup/cpu/libvirt/qemu/testvm/ 2013-05-16 04:08:11.106+0000: 21636: error : qemuDomainSnapshotCreateDiskActive:11299 : internal error Unable to find cgroup for testvm 2013-05-16 04:08:11.106+0000: 21636: debug : qemuProcessStartCPUs:2825 : Using lock state '(null)' At this point, all I can say is that our logging for cgroups is LOUSY. Can you retry with the just-released 1.0.5.1 or even libvirt.git, as it makes no sense trying to debug stale versions unless we can prove the problem also affects the latest? There have been some recent cgroups patches. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
An ubuntu pastebin for a CentOS issue seems a bit... odd. Unfortunately, pastebins tend to expire, so linking to them in mail isn't always the most reliable, compared to just pasting relevant sections inline.
2013-05-16 04:08:11.063+0000: 21636: debug : qemuDomainObjBeginJobInternal:813 : Starting async job: snapshot 2013-05-16 04:08:11.103+0000: 21636: debug : virFileClose:72 : Closed fd 23 2013-05-16 04:08:11.103+0000: 21636: debug : virCgroupNew:617 : New group /libvirt/qemu/testvm 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupDetect:273 : Detected mount/mapping 0:cpu at /cgroup/cpu in 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupDetect:273 : Detected mount/mapping 1:cpuacct at /cgroup/cpuacct in 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupDetect:273 : Detected mount/mapping 2:cpuset at /cgroup/cpuset in 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupDetect:273 : Detected mount/mapping 3:memory at /cgroup/memory in 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupDetect:273 : Detected mount/mapping 4:devices at /cgroup/devices in 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupDetect:273 : Detected mount/mapping 5:freezer at /cgroup/freezer in 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupDetect:273 : Detected mount/mapping 6:blkio at /cgroup/blkio in 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupMakeGroup:535 : Make group /libvirt/qemu/testvm 2013-05-16 04:08:11.105+0000: 21636: debug : virCgroupMakeGroup:560 : Make controller /cgroup/cpu/libvirt/qemu/testvm/ 2013-05-16 04:08:11.106+0000: 21636: error : qemuDomainSnapshotCreateDiskActive:11299 : internal error Unable to find cgroup for testvm 2013-05-16 04:08:11.106+0000: 21636: debug : qemuProcessStartCPUs:2825 : Using lock state '(null)'
At this point, all I can say is that our logging for cgroups is LOUSY. Can you retry with the just-released 1.0.5.1 or even libvirt.git, as it makes no sense trying to debug stale versions unless we can prove the problem also affects the latest? There have been some recent cgroups patches.
Thanks. :-) I'll try 1.0.5.1 later.
participants (2)
-
Eric Blake -
Gao Yongwei