Bug 871273 - [regression]The libvirtd service will be dead after qemu-attach domain PID
Summary: [regression]The libvirtd service will be dead after qemu-attach domain PID
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Gunannan Ren
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-30 06:21 UTC by Xuesong Zhang
Modified: 2014-07-06 19:31 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-09 21:20:12 UTC


Attachments (Terms of Use)
libvirtd.log (64.12 KB, application/octet-stream)
2012-10-30 06:34 UTC, Xuesong Zhang
no flags Details

Description Xuesong Zhang 2012-10-30 06:21:19 UTC
Description of problem:
The libvirtd service will be dead after qemu-attach domain PID.
It is one regression bug, if I use the previous libvirt build (libvirt-0.10.2-2.el6.x86_64), I can get the expected result.
Another Info for your reference, I find this bug while I verifying another bug 825820, I'm not sure whether it is caused by that bug.

Version-Release number of selected component (if applicable):
libvirt-0.10.2-6.el6
qemu-kvm-rhev-0.12.1.2-2.330.el6
kernel-2.6.32-335.el6
seabios-0.6.1.2-25.el6

How reproducible:
100%

Steps to Reproduce:
1. make sure the libvirtd service is running
#service libvirtd status
libvirtd (pid  9325) is running...

2. create a img
# qemu-img create /var/lib/libvirt/images/foo.img 1G
Formatting '/var/lib/libvirt/images/foo.img', fmt=raw size=1073741824 

3. start a domain not under libvirt management:
# /usr/libexec/qemu-kvm -cdrom /var/lib/libvirt/images/foo.img -monitor unix:/tmp/demo,server,nowait -name foo -uuid cece4f9f-dff0-575d-0e8e-01fe380f12ea  &
[1] 1688

4. attach the domain
#virsh qemu-attach 1688
  
Actual results:
It will report the following error and the the libvirtd servcie dead.

error: End of file while reading data: Input/output error
error: Failed to reconnect to the hypervisor

# service libvirtd status
libvirtd dead but pid file exists

Expected results:
The domain can be attached successfully, and the libvirtd service is still running

Additional info:

Comment 2 Xuesong Zhang 2012-10-30 06:34:33 UTC
Created attachment 635348 [details]
libvirtd.log

Attached is the libvirtd.log for your reference

Comment 3 Min Zhan 2012-10-30 07:18:34 UTC
Add Regression Keyword per the bug description.

Comment 5 Gunannan Ren 2012-10-30 07:51:00 UTC
Backtrace:

#0  0x00000037efd27a9a in __strcmp_sse42 () from /lib64/libc.so.6
#1  0x00007fd39a7c5de1 in qemuCapsGetCanonicalMachine (caps=0x7fd3940d1540, name=0x0)
    at qemu/qemu_capabilities.c:1855
#2  0x00007fd39a82a9c8 in qemuCanonicalizeMachine (def=0x7fd380000af0, 
    caps=<value optimized out>) at qemu/qemu_driver.c:1520
#3  0x00007fd39a82ac26 in qemuDomainAttach (conn=0x7fd384000c60, pid_value=4379, 
    flags=<value optimized out>) at qemu/qemu_driver.c:12397
#4  0x0000003cde800e20 in virDomainQemuAttach (conn=0x7fd384000c60, pid_value=4379, 
    flags=0) at libvirt-qemu.c:176
#5  0x000000000040f70e in qemuDispatchDomainAttach (server=<value optimized out>, 
    client=0xd24d10, msg=<value optimized out>, rerr=0x7fd3a0186bc0, args=0x7fd380000ac0, 
    ret=0x7fd3800008c0) at qemu_dispatch.h:111
#6  qemuDispatchDomainAttachHelper (server=<value optimized out>, client=0xd24d10, 
    msg=<value optimized out>, rerr=0x7fd3a0186bc0, args=0x7fd380000ac0, 
    ret=0x7fd3800008c0) at qemu_dispatch.h:91
#7  0x0000003cde369f22 in virNetServerProgramDispatchCall (prog=0xd1f110, server=0xd16380, 
    client=0xd24d10, msg=0xd25f70) at rpc/virnetserverprogram.c:431
#8  virNetServerProgramDispatch (prog=0xd1f110, server=0xd16380, client=0xd24d10, 
    msg=0xd25f70) at rpc/virnetserverprogram.c:304
#9  0x0000003cde36ae3e in virNetServerProcessMsg (srv=<value optimized out>, 
    client=0xd24d10, prog=<value optimized out>, msg=0xd25f70) at rpc/virnetserver.c:171
---Type <return> to continue, or q <return> to quit---
#10 0x0000003cde36b9fb in virNetServerHandleJob (jobOpaque=<value optimized out>, 
    opaque=<value optimized out>) at rpc/virnetserver.c:192
#11 0x0000003cde2735be in virThreadPoolWorker (opaque=<value optimized out>)
    at util/threadpool.c:144
#12 0x0000003cde272ba6 in virThreadHelper (data=<value optimized out>)
    at util/threads-pthread.c:161
#13 0x00000037f0007851 in start_thread () from /lib64/libpthread.so.0
#14 0x00000037efce890d in clone () from /lib64/libc.so.6

Comment 7 Gunannan Ren 2012-11-01 10:42:11 UTC
patch sent to upstream
https://www.redhat.com/archives/libvir-list/2012-November/msg00022.html

Comment 8 Gunannan Ren 2012-11-02 04:54:30 UTC
commit 1851a0c8640f0b42e20a2ccfd5cdb9a9409517ec
Author: Guannan Ren <gren@redhat.com>
Date:   Thu Nov 1 19:43:03 2012 +0800

    qemu: use default machine type if missing it in qemu command line
    
    BZ:https://bugzilla.redhat.com/show_bug.cgi?id=871273
    when using virsh qemu-attach to attach an existing qemu process,
    if it misses the -M option in qemu command line, libvirtd crashed
    because the NULL value of def->os.machine in later use.
    
    Example:
    /usr/libexec/qemu-kvm -name foo \
                          -cdrom /var/lib/libvirt/images/boot.img \
                          -monitor unix:/tmp/demo,server,nowait \
    
    error: End of file while reading data: Input/output error
    error: Failed to reconnect to the hypervisor
    
    This patch tries to set default machine type if the value of
    def->os.machine is still NULL after qemu command line parsing.

Comment 9 Cole Robinson 2012-12-09 21:20:12 UTC
Closing since this is an upstream BZ


Note You need to log in before you can comment on or make changes to this bug.