December 2013 - Devel - libvirt List Archives

[libvirt] SECURITY: CVE-2013-6436: libvirtd daemon crash when reading memory tunables for LXC guest in shutoff status
by Daniel P. Berrange 20 Dec '13

20 Dec '13

Libvirt Security Notice ======================= Summary: libvirtd daemon crash when reading memory tunables for LXC guest in shutoff status Reported on: 20131209 Published on: 20131220 Fixed on: 20131220 Reported by: Martin Kletzander <mkletzan(a)redhat.com> Patched by: Martin Kletzander <mkletzan(a)redhat.com> See also: CVE-2013-6436 Description ----------- The lxcDomainGetMemoryParameters method in the LXC driver did not check whether the guest being accessed was running or not. When shutoff there will be no virCgroupPtr instance associated with the guest. Reading memory tunables involves calling methods with the virCgroupPtr object as a parameter. This will lead to a crash accessing a NULL pointer. Impact ------ A user who has permission to invoke the virDomainGetMemoryParameters API against the LXC driver will be able to crash the libvirtd daemon. Access to this API is granted to any user who connects to the read-only libvirtd UNIX domain socket. If ACLs are active, access is granted to any user with the 'read' permission on the 'domain' object, which is granted by default to all users. As a result an unprivileged user will be able to inflict a denial of service attack on other users of the libvirtd daemon with higher privilege. Workaround ---------- The impact can be mitigated by blocking access to the read-only libvirtd UNIX domain socket, with policykit or the 'auth_unix_ro' parameter in '/etc/libvirt/libvirtd.conf'. If ACLs are active, the 'read' permission should be removed from any untrusted users. This will not prevent the crash, but will stop unprivileged users from inflicting the denial of service on higher privileged users. Affected product ---------------- Name: libvirt Repository: git://libvirt.org/git/libvirt.git Branch: master Broken by: cfed9ad4fb28e268e1467a0071c2fbc0c0873969 Fixed by: f8c1cb90213508c4f32549023b0572ed774e48aa Branch: v1.0.5-maint Broken in: v1.0.5 Broken in: v1.0.5.1 Broken in: v1.0.5.2 Broken in: v1.0.5.3 Broken in: v1.0.5.4 Broken in: v1.0.5.5 Broken in: v1.0.5.6 Broken in: v1.0.5.7 Broken by: cfed9ad4fb28e268e1467a0071c2fbc0c0873969 Fixed by: 218bd2e8716bcb4c90acf6ecaf879d606b46606b Branch: v1.0.6-maint Broken in: v1.0.6 Broken by: cfed9ad4fb28e268e1467a0071c2fbc0c0873969 Fixed by: 80d682fd90bb7e97d8670be4cba1fe153438d7a0 Branch: v1.1.0-maint Broken in: v1.1.0 Broken by: cfed9ad4fb28e268e1467a0071c2fbc0c0873969 Fixed by: 30a589bc4731488ca3428515ed57ce5446a83bbd Branch: v1.1.1-maint Broken in: v1.1.1 Broken by: cfed9ad4fb28e268e1467a0071c2fbc0c0873969 Fixed by: 9a68d1354233f4cfca686655f8021e9477977e6e Branch: v1.1.2-maint Broken in: v1.1.2 Broken by: cfed9ad4fb28e268e1467a0071c2fbc0c0873969 Fixed by: 79384018480f11ec6f2c2196039e67a9196d3e3a Branch: v1.1.3-maint Broken in: v1.1.3 Broken in: v1.1.3.1 Broken by: cfed9ad4fb28e268e1467a0071c2fbc0c0873969 Fixed by: 66247dc5fffe5b9447f4db377c5adf02e6db97c4 Branch: v1.1.4-maint Broken in: v1.1.4 Broken by: cfed9ad4fb28e268e1467a0071c2fbc0c0873969 Fixed by: 09956c7db764a0958034de6fac58aaaaf8e878bf Branch: v1.2.0-maint Broken in: v1.2.0 Broken by: cfed9ad4fb28e268e1467a0071c2fbc0c0873969 Fixed by: 705f388bceb4fce21b7c5ebc6310cb467c362239 Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

1 0

[libvirt] [PATCH 0/3] libxl: improve vcpu pinning
by Dario Faggioli 20 Dec '13

20 Dec '13

Basically, by making it possible to both query and change the vcpu to pcpu pinning of a (persistent) domain, even when it is not running. That happens by providing the implementation of virDomainGetVcpuPinInfo() and virDomainPinVcpuFlags() within he libxl driver, which is what happens in the first two patches. The third patch is something that can also be seen as a bugfix, and that's why I kept it separated from the second one, for easier review (although, the 'bug' does not really manifests, until virDomainPinVcpuFlags is implemented in patch 2). The logic is a lot similar to what happens in the QEMU driver. The patches are available in the following git branch: git://xenbits.xen.org/people/dariof/libvirt.git libxl/VcpuPinX Thanks and Regards, Dario --- Dario Faggioli (3): libxl: implement virDomainGetVcpuPinInfo libxl: implement virDomainPinVcpuFlags libxl: correctly handle affinity reset in virDomainPinVcpu[Flags] src/libxl/libxl_driver.c | 171 ++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 150 insertions(+), 21 deletions(-) -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

2 5

[libvirt] [PATCH 0/3] PCI device assignment bugfixes
by Laine Stump 20 Dec '13

20 Dec '13

These were all found as a result of researching Bug 1035490. Patch 1 fixes the originally reported problem, Patch 2 fixes the cause of incorrect error reporting in a later comment of that bug, and Patch 3 fixes a behavior that I encountered while searching for the cause. Laine Stump (3): qemu: properly set MaxMemLock when hotplugging with VFIO qemu: avoid duplicate security label restore on hostdev attach failure qemu: re-add hostdev interfaces to hostdev array on libvirtd restart src/conf/domain_conf.c | 9 ++++++--- src/qemu/qemu_hotplug.c | 22 +++++++++++----------- 2 files changed, 17 insertions(+), 14 deletions(-) -- 1.8.3.1

2 4

[libvirt] [BUG] pinvcpu before migration
by Wangyufei (James) 20 Dec '13

20 Dec '13

hi , I am confused by pinvcpu before migration. I have two physical machine. One has 12 CPUs (E5645 2*6 ) as src and the other has 8 CPUs (2*4) as des. Step 1 : VM is running on src host (E5645 2*6 CPUs) with its VCPUs pinned on some PCPUs Step 2 :Because PCPU count is different between src and des , I should pin VCPUs to all PCPUs . virsh vcpupin vmname 0 0-11 --config --live Step 3: Do migrate ,and it failed with error in des libvirt log "Unable to set cpuset.cpus: Invalid argument" I find that VM's cpu bitmap on src turns to <vcpupin vcpu='0' cpuset='0-11'/> . vm start fails on des due to its pin info cpuset='0-11' in vm->def. In usual case, after I pin VCPU to all PCPU, vcpupin info will be deleted in vm->def. -- qemuDomainPinVcpuFlags -- if (virBitmapIsAllSet(pcpumap, pCpuCount)) doReset = true; -- if (doReset) if (virDomainVcpuPinDel(vm->def, vcpu) < 0) I debug libvirt and find that on src which PCPU count is 12 (2*6) virBitmapIsAllSet(pcpumap, pCpuCount) return false pcpumap->max_bit is 16. pcpumap = virBitmapNewData(cpumap, maplen) --> bitmap = virBitmapNew(len * CHAR_BIT); //here len is 2. Although my physical machine only has 12 PCPUs , but here pcpumap->max_bit is len*CHAR_BIT . So bitmap is 0000 1111 1111 1111 ,and it's not ALL SET (ALL SET is 1111 1111 1111 1111). I tried to fix the bug in this case , but I have not found a good solution. Any suggestions will be thankful. Best Regards, -WangYufei

2 1

[libvirt] [PATCH] virnettlscontexttest fails with GNUTLS 3.0.28
by Cédric Bosdonnat 20 Dec '13

20 Dec '13

Changed the constraints on gnutls to 3.1+ --- tests/virnettlscontexttest.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/virnettlscontexttest.c b/tests/virnettlscontexttest.c index fc512fc..d9a4e9d 100644 --- a/tests/virnettlscontexttest.c +++ b/tests/virnettlscontexttest.c @@ -268,7 +268,8 @@ mymain(void) * be rejected. GNUTLS < 3 does not reject it and * we don't anticipate them changing this behaviour */ - DO_CTX_TEST(true, cacert4req.filename, servercert4req.filename, GNUTLS_VERSION_MAJOR >= 3); + DO_CTX_TEST(true, cacert4req.filename, servercert4req.filename, + GNUTLS_VERSION_MAJOR >= 3 && GNUTLS_VERSION_MINOR >= 1); DO_CTX_TEST(true, cacert5req.filename, servercert5req.filename, true); DO_CTX_TEST(true, cacert6req.filename, servercert6req.filename, true); -- 1.8.4.4

4 4

[libvirt] [PATCH 0/2] Fix crash handling memory parameters in LXC
by Daniel P. Berrange 20 Dec '13

20 Dec '13

The first of these 2 issues is a security issue CVE-2013-6436 Both patches have been pushed to GIT master. Martin Kletzander (2): CVE-2013-6436: fix crash in lxcDomainGetMemoryParameters Fix crash in lxcDomainSetMemoryParameters src/lxc/lxc_driver.c | 153 +++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 130 insertions(+), 23 deletions(-) -- 1.8.4.2

1 2

[libvirt] [PATCH] Fix explicit usage of default video PCI slots
by Ján Tomko 20 Dec '13

20 Dec '13

Don't set the PCI address of primary video to the default if it's already occupied by another device. Without this, a primary video card that doesn't have an address gets the default one on the 1st pass of PCI address allocation, even if it's occupied. This address gets picked up by the second pass, and a conflict occurs: XML error: Attempted double use of PCI slot 0000:00:02.0 (may need "multifunction='on'" for device on function 0) Also fix the test that was supposed to catch this. --- src/qemu/qemu_command.c | 50 +++++++++++++++++++++--------------------------- tests/qemuxml2argvtest.c | 3 ++- 2 files changed, 24 insertions(+), 29 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index d723dc8..2a64cd1 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -2379,7 +2379,6 @@ qemuValidateDevicePCISlotsPIIX3(virDomainDefPtr def, size_t i; virDevicePCIAddress tmp_addr; bool qemuDeviceVideoUsable = virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIDEO_PRIMARY); - virDevicePCIAddressPtr addrptr; char *addrStr = NULL; qemuDomainPCIConnectFlags flags = QEMU_PCI_CONNECT_HOTPLUGGABLE | QEMU_PCI_CONNECT_TYPE_PCI; @@ -2446,22 +2445,17 @@ qemuValidateDevicePCISlotsPIIX3(virDomainDefPtr def, */ virDomainVideoDefPtr primaryVideo = def->videos[0]; if (primaryVideo->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI) { - primaryVideo->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI; - primaryVideo->info.addr.pci.domain = 0; - primaryVideo->info.addr.pci.bus = 0; - primaryVideo->info.addr.pci.slot = 2; - primaryVideo->info.addr.pci.function = 0; - addrptr = &primaryVideo->info.addr.pci; - - if (!(addrStr = qemuDomainPCIAddressAsString(addrptr))) + memset(&tmp_addr, 0, sizeof(tmp_addr)); + tmp_addr.slot = 2; + + if (!(addrStr = qemuDomainPCIAddressAsString(&tmp_addr))) goto cleanup; - if (!qemuDomainPCIAddressValidate(addrs, addrptr, + if (!qemuDomainPCIAddressValidate(addrs, &tmp_addr, addrStr, flags, false)) goto cleanup; - if (qemuDomainPCIAddressSlotInUse(addrs, addrptr)) { + if (qemuDomainPCIAddressSlotInUse(addrs, &tmp_addr)) { if (qemuDeviceVideoUsable) { - virResetLastError(); if (qemuDomainPCIAddressReserveNextSlot(addrs, &primaryVideo->info, flags) < 0) @@ -2472,8 +2466,11 @@ qemuValidateDevicePCISlotsPIIX3(virDomainDefPtr def, "QEMU needs it for primary video")); goto cleanup; } - } else if (qemuDomainPCIAddressReserveSlot(addrs, addrptr, flags) < 0) { - goto cleanup; + } else { + if (qemuDomainPCIAddressReserveSlot(addrs, &tmp_addr, flags) < 0) + goto cleanup; + primaryVideo->info.addr.pci = tmp_addr; + primaryVideo->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI; } } else if (!qemuDeviceVideoUsable) { if (primaryVideo->info.addr.pci.domain != 0 || @@ -2535,7 +2532,6 @@ qemuDomainValidateDevicePCISlotsQ35(virDomainDefPtr def, size_t i; virDevicePCIAddress tmp_addr; bool qemuDeviceVideoUsable = virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_VIDEO_PRIMARY); - virDevicePCIAddressPtr addrptr; char *addrStr = NULL; qemuDomainPCIConnectFlags flags = QEMU_PCI_CONNECT_TYPE_PCIE; @@ -2619,22 +2615,17 @@ qemuDomainValidateDevicePCISlotsQ35(virDomainDefPtr def, */ virDomainVideoDefPtr primaryVideo = def->videos[0]; if (primaryVideo->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI) { - primaryVideo->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI; - primaryVideo->info.addr.pci.domain = 0; - primaryVideo->info.addr.pci.bus = 0; - primaryVideo->info.addr.pci.slot = 1; - primaryVideo->info.addr.pci.function = 0; - addrptr = &primaryVideo->info.addr.pci; - - if (!(addrStr = qemuDomainPCIAddressAsString(addrptr))) + memset(&tmp_addr, 0, sizeof(tmp_addr)); + tmp_addr.slot = 1; + + if (!(addrStr = qemuDomainPCIAddressAsString(&tmp_addr))) goto cleanup; - if (!qemuDomainPCIAddressValidate(addrs, addrptr, + if (!qemuDomainPCIAddressValidate(addrs, &tmp_addr, addrStr, flags, false)) goto cleanup; - if (qemuDomainPCIAddressSlotInUse(addrs, addrptr)) { + if (qemuDomainPCIAddressSlotInUse(addrs, &tmp_addr)) { if (qemuDeviceVideoUsable) { - virResetLastError(); if (qemuDomainPCIAddressReserveNextSlot(addrs, &primaryVideo->info, flags) < 0) @@ -2645,8 +2636,11 @@ qemuDomainValidateDevicePCISlotsQ35(virDomainDefPtr def, "QEMU needs it for primary video")); goto cleanup; } - } else if (qemuDomainPCIAddressReserveSlot(addrs, addrptr, flags) < 0) { - goto cleanup; + } else { + if (qemuDomainPCIAddressReserveSlot(addrs, &tmp_addr, flags) < 0) + goto cleanup; + primaryVideo->info.type = VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI; + primaryVideo->info.addr.pci = tmp_addr; } } else if (!qemuDeviceVideoUsable) { if (primaryVideo->info.addr.pci.domain != 0 || diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 847e96f..5a2bfcc 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -1193,7 +1193,8 @@ mymain(void) DO_TEST("video-device-pciaddr-default", QEMU_CAPS_KVM, QEMU_CAPS_VNC, QEMU_CAPS_DEVICE, QEMU_CAPS_DEVICE_VIDEO_PRIMARY, - QEMU_CAPS_DEVICE_QXL, QEMU_CAPS_DEVICE_QXL_VGA); + QEMU_CAPS_DEVICE_QXL, QEMU_CAPS_DEVICE_QXL_VGA, + QEMU_CAPS_DEVICE_PCI_BRIDGE); DO_TEST("virtio-rng-default", QEMU_CAPS_DEVICE, QEMU_CAPS_DEVICE_VIRTIO_RNG, QEMU_CAPS_OBJECT_RNG_RANDOM); -- 1.8.3.2

4 5

[libvirt] Segfault in libxl_osevent_occurred_timeout [Was: Re: [libvirt-users] About debugging of libvirt.]
by Dario Faggioli 20 Dec '13

20 Dec '13

[Moving this to libvir, libvir-users in Bcc. Also, added xen-devel] Jim, cooldharma06 reports having issues when destroying VMs with libvirt 1.2.0 and Xen 4.2.1 (is that the case, cooldharma06)? Look at the stack trace at the end of this message, or here: https://bugzilla.redhat.com/show_bug.cgi?id=1044838 Ian, since it looks like events are involved... Any idea? cooldharma06, about the Xen 4.2.1, thing, is there a specific reason why you use it instead, of, e.g., 4.3.x ? Since you are building from source anyway, could you at least try Xen 4.3, to see whether the issue could be a bug in 4.2's libxl? I'm asking because, with both Xen 4.3 and the curret git tip, I don't have issues destroying domains with virsh. Thanks and Regards, Dario On gio, 2013-12-19 at 15:42 +0530, cool dharma06 wrote: > i did the debugging as you said. Kindly refer the following logs: > > > (gdb) c > Continuing. > thread apply all bt > [New Thread 0x7fc337c6b700 (LWP 29520)] > > > Program received signal SIGSEGV, Segmentation fault. > 0x0000000000000000 in ?? () > (gdb) thread apply all bt > > > Thread 12 (Thread 0x7fc337c6b700 (LWP 29520)): > #0 0x00007fc33509f18d in read () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #1 0x00007fc32b1555c4 in read_all (fd=26, data=0x7fc3380e0a70, > data@entry=0x20, len=len@entry=16, nonblocking=nonblocking@entry=0) at > xs.c:365 > #2 0x00007fc32b1556d8 in read_message (h=h@entry=0x7fc324013ee0, > nonblocking=nonblocking@entry=0) at xs.c:1071 > #3 0x00007fc32b156005 in read_thread (arg=0x7fc324013ee0) at > xs.c:1137 > #4 0x00007fc335097b50 in start_thread () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #5 0x00007fc3349daa3d in clone () > from /lib/x86_64-linux-gnu/libc.so.6 > #6 0x0000000000000000 in ?? () > > > Thread 11 (Thread 0x7fc330e7f700 (LWP 29170)): > #0 0x00007fc33509c2d4 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #1 0x00007fc3371ae9ea in virCondWait (c=c@entry=0x7fc3380dbd80, > m=m@entry=0x7fc3380dbd58) at util/virthreadpthread.c:117 > #2 0x00007fc3371af0cb in virThreadPoolWorker > (opaque=opaque@entry=0x7fc3380db870) at util/virthreadpool.c:103 > #3 0x00007fc3371ae686 in virThreadHelper (data=<optimized out>) at > util/virthreadpthread.c:161 > #4 0x00007fc335097b50 in start_thread () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #5 0x00007fc3349daa3d in clone () > from /lib/x86_64-linux-gnu/libc.so.6 > #6 0x0000000000000000 in ?? () > > > Thread 10 (Thread 0x7fc33067e700 (LWP 29171)): > #0 0x00007fc33509c2d4 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #1 0x00007fc3371ae9ea in virCondWait (c=c@entry=0x7fc3380dbd80, > m=m@entry=0x7fc3380dbd58) at util/virthreadpthread.c:117 > #2 0x00007fc3371af0cb in virThreadPoolWorker > (opaque=opaque@entry=0x7fc3380db640) at util/virthreadpool.c:103 > #3 0x00007fc3371ae686 in virThreadHelper (data=<optimized out>) at > util/virthreadpthread.c:161 > #4 0x00007fc335097b50 in start_thread () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #5 0x00007fc3349daa3d in clone () > from /lib/x86_64-linux-gnu/libc.so.6 > #6 0x0000000000000000 in ?? () > > > Thread 9 (Thread 0x7fc32fe7d700 (LWP 29172)): > #0 0x00007fc33509c2d4 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #1 0x00007fc3371ae9ea in virCondWait (c=c@entry=0x7fc3380dbd80, > m=m@entry=0x7fc3380dbd58) at util/virthreadpthread.c:117 > #2 0x00007fc3371af0cb in virThreadPoolWorker > (opaque=opaque@entry=0x7fc3380db870) at util/virthreadpool.c:103 > #3 0x00007fc3371ae686 in virThreadHelper (data=<optimized out>) at > util/virthreadpthread.c:161 > #4 0x00007fc335097b50 in start_thread () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #5 0x00007fc3349daa3d in clone () > from /lib/x86_64-linux-gnu/libc.so.6 > #6 0x0000000000000000 in ?? () > > > Thread 8 (Thread 0x7fc32f67c700 (LWP 29173)): > #0 0x00007fc33497cb9f in realloc () > from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x00007fc3349eec85 in __vasprintf_chk () > from /lib/x86_64-linux-gnu/libc.so.6 > ---Type <return> to continue, or q <return> to quit--- > #2 0x00007fc3371aac0a in vasprintf (__ap=0x7fc32f67b6d0, > __fmt=0x7fc337391017 "%llu: %s : %s:%d : %s\n", __ptr=0x7fc32f67b830) > at /usr/include/x86_64-linux-gnu/bits/stdio2.h:199 > #3 virVasprintfInternal (report=report@entry=false, domcode=0, > filename=0x0, funcname=0x0, linenr=0, strp=0x7fc32f67b830, > fmt=fmt@entry=0x7fc337391017 "%llu: %s : %s:%d : %s\n", > list=list@entry=0x7fc32f67b6d0) at util/virstring.c:337 > #4 0x00007fc3371aad1b in virAsprintfInternal > (report=report@entry=false, domcode=domcode@entry=0, > filename=filename@entry=0x0, funcname=funcname@entry=0x0, > linenr=linenr@entry=0, strp=strp@entry=0x7fc32f67b830, > fmt=fmt@entry=0x7fc337391017 "%llu: %s : %s:%d : %s\n") at > util/virstring.c:358 > #5 0x00007fc33718cb59 in virLogFormatString (str=<optimized out>, > priority=VIR_LOG_DEBUG, funcname=0x7fc337394734 "virObjectRef", > linenr=293, msg=0x7fc32f67b830) > at util/virlog.c:719 > #6 virLogVMessage (source=VIR_LOG_FROM_TRACE, priority=VIR_LOG_DEBUG, > filename=0x7fc337394597 "util/virobject.c", linenr=293, > funcname=0x7fc337394734 "virObjectRef", > metadata=0x0, fmt=fmt@entry=0x7fc3373945f1 "OBJECT_REF: obj=%p", > vargs=vargs@entry=0x7fc32f67b8c0) at util/virlog.c:846 > #7 0x00007fc33718cfc7 in virLogMessage > (source=source@entry=VIR_LOG_FROM_TRACE, > priority=priority@entry=VIR_LOG_DEBUG, > filename=filename@entry=0x7fc337394597 "util/virobject.c", > linenr=linenr@entry=293, funcname=funcname@entry=0x7fc337394734 > "virObjectRef", > metadata=metadata@entry=0x0, fmt=fmt@entry=0x7fc3373945f1 > "OBJECT_REF: obj=%p") at util/virlog.c:778 > #8 0x00007fc33719c3d7 in virObjectRef (anyobj=0x7fc338102720) at > util/virobject.c:293 > #9 0x00007fc32af1824f in libxlDriverConfigGet > (driver=driver@entry=0x7fc338108930) at libxl/libxl_conf.c:1124 > #10 0x00007fc32af1a50e in libxlVmCleanup > (driver=driver@entry=0x7fc338108930, vm=vm@entry=0x7fc32400f530, > reason=reason@entry=VIR_DOMAIN_SHUTOFF_DESTROYED) > at libxl/libxl_driver.c:264 > #11 0x00007fc32af20274 in libxlVmReap (driver=0x7fc338108930, > vm=0x7fc32400f530, reason=VIR_DOMAIN_SHUTOFF_DESTROYED) at > libxl/libxl_driver.c:338 > #12 0x00007fc32af207de in libxlDomainDestroyFlags (dom=0x7fc3380e3770, > flags=<optimized out>) at libxl/libxl_driver.c:1507 > #13 0x00007fc33723cd37 in virDomainDestroy > (domain=domain@entry=0x7fc3380e3770) at libvirt.c:2342 > #14 0x00007fc337cb9ba4 in remoteDispatchDomainDestroy (args=<optimized > out>, rerr=0x7fc32f67bcd0, client=0x7fc32400ee60, server=<optimized > out>, msg=<optimized out>) > at remote_dispatch.h:3165 > #15 remoteDispatchDomainDestroyHelper (server=<optimized out>, > client=0x7fc32400ee60, msg=<optimized out>, rerr=0x7fc32f67bcd0, > args=<optimized out>, > ret=<optimized out>) at remote_dispatch.h:3143 > #16 0x00007fc3372b4d79 in virNetServerProgramDispatchCall > (msg=0x7fc324014070, client=0x7fc32400ee60, server=0x7fc3380dbba0, > prog=0x7fc324007750) > at rpc/virnetserverprogram.c:435 > #17 virNetServerProgramDispatch (prog=0x7fc324007750, > server=server@entry=0x7fc3380dbba0, client=0x7fc32400ee60, > msg=0x7fc324014070) at rpc/virnetserverprogram.c:305 > #18 0x00007fc3372aea78 in virNetServerProcessMsg (msg=<optimized out>, > prog=<optimized out>, client=<optimized out>, srv=0x7fc3380dbba0) at > rpc/virnetserver.c:165 > #19 virNetServerHandleJob (jobOpaque=<optimized out>, > opaque=0x7fc3380dbba0) at rpc/virnetserver.c:186 > #20 0x00007fc3371af02e in virThreadPoolWorker > (opaque=opaque@entry=0x7fc3380db640) at util/virthreadpool.c:144 > #21 0x00007fc3371ae686 in virThreadHelper (data=<optimized out>) at > util/virthreadpthread.c:161 > #22 0x00007fc335097b50 in start_thread () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #23 0x00007fc3349daa3d in clone () > from /lib/x86_64-linux-gnu/libc.so.6 > #24 0x0000000000000000 in ?? () > > > Thread 7 (Thread 0x7fc32ee7b700 (LWP 29174)): > #0 0x00007fc33509c2d4 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #1 0x00007fc3371ae9ea in virCondWait (c=c@entry=0x7fc3380dbd80, > m=m@entry=0x7fc3380dbd58) at util/virthreadpthread.c:117 > #2 0x00007fc3371af0cb in virThreadPoolWorker > (opaque=opaque@entry=0x7fc3380db870) at util/virthreadpool.c:103 > #3 0x00007fc3371ae686 in virThreadHelper (data=<optimized out>) at > util/virthreadpthread.c:161 > ---Type <return> to continue, or q <return> to quit--- > #4 0x00007fc335097b50 in start_thread () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #5 0x00007fc3349daa3d in clone () > from /lib/x86_64-linux-gnu/libc.so.6 > #6 0x0000000000000000 in ?? () > > > Thread 6 (Thread 0x7fc32e67a700 (LWP 29175)): > #0 0x00007fc33509c2d4 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #1 0x00007fc3371ae9ea in virCondWait (c=c@entry=0x7fc3380dbe18, > m=m@entry=0x7fc3380dbd58) at util/virthreadpthread.c:117 > #2 0x00007fc3371af0eb in virThreadPoolWorker > (opaque=opaque@entry=0x7fc3380db640) at util/virthreadpool.c:103 > #3 0x00007fc3371ae686 in virThreadHelper (data=<optimized out>) at > util/virthreadpthread.c:161 > #4 0x00007fc335097b50 in start_thread () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #5 0x00007fc3349daa3d in clone () > from /lib/x86_64-linux-gnu/libc.so.6 > #6 0x0000000000000000 in ?? () > > > Thread 5 (Thread 0x7fc32de79700 (LWP 29176)): > #0 0x00007fc33509c2d4 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #1 0x00007fc3371ae9ea in virCondWait (c=c@entry=0x7fc3380dbe18, > m=m@entry=0x7fc3380dbd58) at util/virthreadpthread.c:117 > #2 0x00007fc3371af0eb in virThreadPoolWorker > (opaque=opaque@entry=0x7fc3380db870) at util/virthreadpool.c:103 > #3 0x00007fc3371ae686 in virThreadHelper (data=<optimized out>) at > util/virthreadpthread.c:161 > #4 0x00007fc335097b50 in start_thread () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #5 0x00007fc3349daa3d in clone () > from /lib/x86_64-linux-gnu/libc.so.6 > #6 0x0000000000000000 in ?? () > > > Thread 4 (Thread 0x7fc32d678700 (LWP 29177)): > #0 0x00007fc33509c2d4 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #1 0x00007fc3371ae9ea in virCondWait (c=c@entry=0x7fc3380dbe18, > m=m@entry=0x7fc3380dbd58) at util/virthreadpthread.c:117 > #2 0x00007fc3371af0eb in virThreadPoolWorker > (opaque=opaque@entry=0x7fc3380db640) at util/virthreadpool.c:103 > #3 0x00007fc3371ae686 in virThreadHelper (data=<optimized out>) at > util/virthreadpthread.c:161 > #4 0x00007fc335097b50 in start_thread () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #5 0x00007fc3349daa3d in clone () > from /lib/x86_64-linux-gnu/libc.so.6 > #6 0x0000000000000000 in ?? () > > > Thread 3 (Thread 0x7fc32ce77700 (LWP 29178)): > #0 0x00007fc33509c2d4 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #1 0x00007fc3371ae9ea in virCondWait (c=c@entry=0x7fc3380dbe18, > m=m@entry=0x7fc3380dbd58) at util/virthreadpthread.c:117 > #2 0x00007fc3371af0eb in virThreadPoolWorker > (opaque=opaque@entry=0x7fc3380db870) at util/virthreadpool.c:103 > #3 0x00007fc3371ae686 in virThreadHelper (data=<optimized out>) at > util/virthreadpthread.c:161 > #4 0x00007fc335097b50 in start_thread () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #5 0x00007fc3349daa3d in clone () > from /lib/x86_64-linux-gnu/libc.so.6 > #6 0x0000000000000000 in ?? () > > > ---Type <return> to continue, or q <return> to quit--- > Thread 2 (Thread 0x7fc32c676700 (LWP 29179)): > #0 0x00007fc33509c2d4 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #1 0x00007fc3371ae9ea in virCondWait (c=c@entry=0x7fc3380dbe18, > m=m@entry=0x7fc3380dbd58) at util/virthreadpthread.c:117 > #2 0x00007fc3371af0eb in virThreadPoolWorker > (opaque=opaque@entry=0x7fc3380db640) at util/virthreadpool.c:103 > #3 0x00007fc3371ae686 in virThreadHelper (data=<optimized out>) at > util/virthreadpthread.c:161 > #4 0x00007fc335097b50 in start_thread () > from /lib/x86_64-linux-gnu/libpthread.so.0 > #5 0x00007fc3349daa3d in clone () > from /lib/x86_64-linux-gnu/libc.so.6 > #6 0x0000000000000000 in ?? () > > > Thread 1 (Thread 0x7fc337c4d7c0 (LWP 29169)): > #0 0x0000000000000000 in ?? () > #1 0x00007fc32ace881e in libxl_osevent_occurred_timeout > (ctx=<optimized out>, for_libxl=0x7fc3380edf38) at libxl_event.c:1039 > #2 0x00007fc32af199c7 in libxlDomainObjTimerCallback > (timer=<optimized out>, timer_info=0x7fc3380e3310) at > libxl/libxl_domain.c:216 > #3 0x00007fc33717cf7d in virEventPollDispatchTimeouts () at > util/vireventpoll.c:451 > #4 virEventPollRunOnce () at util/vireventpoll.c:644 > #5 0x00007fc33717b70b in virEventRunDefaultImpl () at > util/virevent.c:274 > #6 0x00007fc3372b0065 in virNetServerRun (srv=0x7fc3380dbba0) at > rpc/virnetserver.c:1112 > #7 0x00007fc337c9851c in main (argc=<optimized out>, argv=<optimized > out>) at libvirtd.c:1513 > (gdb) > (gdb) > > > **** > > > regards, > cooldharma06. > > > On Thu, Dec 19, 2013 at 3:30 PM, Daniel P. Berrange > <berrange(a)redhat.com> wrote: > On Thu, Dec 19, 2013 at 03:09:14PM +0530, cool dharma06 wrote: > > I am newbie to this gdb debugging. now i did the bt in the > debugging. In my > > side still it showing the error. Following are the > stacktrace which i got. > > Kindly refer the following logs for full information: > > > > **** > > [New Thread 0x7f8503695700 (LWP 20012)] > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x0000000000000000 in ?? () > > (gdb) bt > > #0 0x0000000000000000 in ?? () > > #1 0x00007f84f671281e in libxl_osevent_occurred_timeout > (ctx=<optimized > > out>, for_libxl=0x7f8503bbbc38) at libxl_event.c:1039 > > #2 0x00007f84f69439c7 in libxlDomainObjTimerCallback > (timer=<optimized > > out>, timer_info=0x7f8503bb5930) at libxl/libxl_domain.c:216 > > #3 0x00007f8502ba6f7d in virEventPollDispatchTimeouts () at > > util/vireventpoll.c:451 > > #4 virEventPollRunOnce () at util/vireventpoll.c:644 > > #5 0x00007f8502ba570b in virEventRunDefaultImpl () at > util/virevent.c:274 > > #6 0x00007f8502cda065 in virNetServerRun > (srv=0x7f8503ba6ba0) at > > rpc/virnetserver.c:1112 > > #7 0x00007f85036c251c in main (argc=<optimized out>, > argv=<optimized out>) > > at libvirtd.c:1513 > > (gdb) > > > In this case, that stack trace looks like it ought to be > sufficient > to identify the problem - a clear NULL pointer reference. In > general > though you want to capture a stack trace of all threads in a > program > > eg instead of 'bt', do 'thread apply all bt' next time. > > Regards, > Daniel > -- > |: http://berrange.com -o- > http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- > http://virt-manager.org :| > |: http://autobuild.org -o- > http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- > http://live.gnome.org/gtk-vnc :| > > -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

4 5

[libvirt] JNA Error Callback could cause core dump.
by Benjamin Wang (gendwang) 20 Dec '13

20 Dec '13

Hi, When I changed code as following: public class Connect { // Load the native part static { Libvirt.INSTANCE.virInitialize(); try { ErrorHandler.processError(Libvirt.INSTANCE); } catch (Exception e) { e.printStackTrace(); } + Libvirt.INSTANCE.virSetErrorFunc(null, new ErrorCallback()); } The server will generate the following core dump: Program terminated with signal 6, Aborted. #0 0x0000003f9b030265 in raise () from /lib64/libc.so.6 (gdb) where #0 0x0000003f9b030265 in raise () from /lib64/libc.so.6 #1 0x0000003f9b031d10 in abort () from /lib64/libc.so.6 #2 0x0000003f9b06a84b in __libc_message () from /lib64/libc.so.6 #3 0x0000003f9b07230f in _int_free () from /lib64/libc.so.6 #4 0x0000003f9b07276b in free () from /lib64/libc.so.6 #5 0x00002aaaacf46868 in ?? () #6 0x0000000000000000 in ?? () The problem was caused that when JNA call setErrorFunc, it will create ErrorCallback object. But when GC is executed, the object is GCed. But even I change code as following. When GC is excuted, the callback object will be moved. Then C can't find this object. Both of scenarios will cause core dump. It seems that JNA mustn't provide ErrorCallback Class, Because nobody can use this. Please correct me. public class Connect { + private static final ErrorCallback callback = new ErrorCallback(); // Load the native part static { Libvirt.INSTANCE.virInitialize(); try { ErrorHandler.processError(Libvirt.INSTANCE); } catch (Exception e) { e.printStackTrace(); } + Libvirt.INSTANCE.virSetErrorFunc(null, callback); } B.R. Benjamin Wang

2 4

[libvirt] [PATCH] Block info query: Add flag to allow failure if not active
by John Ferlan 20 Dec '13

20 Dec '13

Currently the qemuDomainGetBlockInfo will return allocation == physical for most backing stores. For a qcow2 block backed device it's possible to return the highest lv extent allocated from qemu for an active guest. That is a value where allocation != physical and one would hope be less. However, if the guest is not running, then the code falls back to returning allocation == physical. This turns out to be problematic for rhev which monitors the size of the backing store. During a migration, before the VM has been started on the target and while it is deemed inactive on the source, allocation is returned as physical triggering the code to extend the file unnecessarily. Thus, this patch will check a new flag to the call to determine whether a failure should be returned to indicate to the caller that the code is unable to fetch the allocation value. This will allow the caller to decide how to proceed. Note that I chose not to return a failure as a more general rule mostly because of backwards compatability and current expectations reasons. Changing a default return action could be an unexpected action. Although returning allocation == physical perhaps is incorrect, it is how the code has been functioning. Having a 'virsh domblkinfo' return a failure for "some" inactive domains while succeeding for others could be confusing. A flag forces the caller to decide how to operate. As it turns out, there seems to be quite a bit of history regarding this. Details can be found in the BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1040507 Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- NOTE: Trying to keep this as simple as possible since it needs to be backported. If someone has a better idea for a flag name - I'm open to suggestions... include/libvirt/libvirt.h.in | 23 ++++++++++++++++++++--- src/libvirt.c | 11 ++++++++++- src/qemu/qemu_driver.c | 33 +++++++++++++++++++++++++++------ 3 files changed, 57 insertions(+), 10 deletions(-) diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in index 6f79c49..420642b 100644 --- a/include/libvirt/libvirt.h.in +++ b/include/libvirt/libvirt.h.in @@ -2095,7 +2095,8 @@ int virDomainBlockResize (virDomainPtr dom, /** virDomainBlockInfo: * - * This struct provides information about the size of a block device backing store + * This struct provides information about the size of a block device + * backing store * * Examples: * @@ -2108,13 +2109,29 @@ int virDomainBlockResize (virDomainPtr dom, * * - qcow2 file in filesystem * * capacity: logical size from qcow2 header - * * allocation, physical: logical size of the file / highest qcow extent (identical) + * * allocation, physical: logical size of the file / + * highest qcow extent (identical) * * - qcow2 file in a block device * * capacity: logical size from qcow2 header - * * allocation: highest qcow extent written + * * allocation: highest qcow extent written for an active domain * * physical: size of the block device container */ + +/** + * virDomainGetBlockInfoFlags: + * + * Flags available for virDomainGetBlockInfo(). + */ +typedef enum { + VIR_DOMAIN_BLOCK_CHECK_ACTIVE = 1 << 0, /* If not active, then return + * failure when attempting to + * fetch data from an inactive + * domain, such as allocation + * from a qcow2 block device + */ +} virDomainGetBlockInfoFlags; + typedef struct _virDomainBlockInfo virDomainBlockInfo; typedef virDomainBlockInfo *virDomainBlockInfoPtr; struct _virDomainBlockInfo { diff --git a/src/libvirt.c b/src/libvirt.c index d15d617..2159eaf 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -9027,7 +9027,7 @@ error: * @domain: a domain object * @disk: path to the block device, or device shorthand * @info: pointer to a virDomainBlockInfo structure allocated by the user - * @flags: extra flags; not used yet, so callers should always pass 0 + * @flags: bitwise-OR of supported virDomainGetBlockInfoFlags * * Extract information about a domain's block device. * @@ -9038,6 +9038,15 @@ error: * can be found by calling virDomainGetXMLDesc() and inspecting * elements within //domain/devices/disk. * + * If the VIR_DOMAIN_BLOCK_CHECK_ACTIVE flag is set, then for any block + * information data that could differ depending on whether the domain was + * active or not, the hypervisor will return a failure when the domain + * is deemed to be inactive or unable to provide the data, such as may be + * the case during a migration. For example, the 'allocation' value for + * a qcow2 block device backed storage can return the highest extent written. + * However, this can only be determined if the domain is active. For an + * inactive domain, the allocation and physical values would be returned + * as identical. * Returns 0 in case of success and -1 in case of failure. */ int diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 45d11cd..6303ce2 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -9799,9 +9799,10 @@ static int qemuDomainGetBlockInfo(virDomainPtr dom, struct stat sb; int idx; int format; + int activeFail = false; virQEMUDriverConfigPtr cfg = NULL; - virCheckFlags(0, -1); + virCheckFlags(VIR_DOMAIN_BLOCK_CHECK_ACTIVE, -1); if (!(vm = qemuDomObjFromDomain(dom))) goto cleanup; @@ -9897,15 +9898,24 @@ static int qemuDomainGetBlockInfo(virDomainPtr dom, /* Set default value .. */ info->allocation = info->physical; - /* ..but if guest is running & not using raw - disk format and on a block device, then query - highest allocated extent from QEMU */ + /* ..but if guest is not using raw disk format and on a block device, + * then query highest allocated extent from QEMU + */ if (disk->type == VIR_DOMAIN_DISK_TYPE_BLOCK && format != VIR_STORAGE_FILE_RAW && - S_ISBLK(sb.st_mode) && - virDomainObjIsActive(vm)) { + S_ISBLK(sb.st_mode)) { qemuDomainObjPrivatePtr priv = vm->privateData; + /* If the guest is not running, then success/failure return + * depends on whether the caller requested a failure on an + * inactive domain. + */ + if (!virDomainObjIsActive(vm)) { + activeFail = true; + ret = 0; + goto cleanup; + } + if (qemuDomainObjBeginJob(driver, vm, QEMU_JOB_QUERY) < 0) goto cleanup; @@ -9916,6 +9926,7 @@ static int qemuDomainGetBlockInfo(virDomainPtr dom, &info->allocation); qemuDomainObjExitMonitor(driver, vm); } else { + activeFail = true; ret = 0; } @@ -9931,6 +9942,16 @@ cleanup: if (vm) virObjectUnlock(vm); virObjectUnref(cfg); + + /* If we failed to get data from a domain because it's inactive and + * this flag is set, then we'll return failure + */ + if (activeFail && (flags & VIR_DOMAIN_BLOCK_CHECK_ACTIVE)) { + virReportError(VIR_ERR_OPERATION_INVALID, "%s", + _("unable to get allocation, domain is not running")); + ret = -1; + } + return ret; } -- 1.8.3.1

3 4