Bug 1061654
Summary: | libvirtd hangs in virDomainCreateXML | ||
---|---|---|---|
Product: | [Community] Virtualization Tools | Reporter: | Richard W.M. Jones <rjones> |
Component: | libvirt | Assignee: | Libvirt Maintainers <libvirt-maint> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | acathrow, berrange, dallan |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-02-05 10:45:31 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 910269 |
Description
Richard W.M. Jones
2014-02-05 10:34:21 UTC
Hmm, maybe this is actually qemu which is broken. I notice there is a qemu process which is consuming CPU but not proceeding anywhere. $ ps ax | grep qemu 13673 ? Sl 4:15 /usr/bin/qemu-system-x86_64 -name guestfs-8jzjfp15twxg0yil -S -machine pc-i440fx-1.7,accel=tcg,usb=off -m 500 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid ab2bbfd9-4cd2-4c30-b220-42d409ccc298 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/rjones/.config/libvirt/qemu/lib/guestfs-8jzjfp15twxg0yil.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-reboot -no-acpi -boot strict=on -kernel /home/rjones/d/libguestfs/tmp/.guestfs-1000/kernel.13471 -initrd /home/rjones/d/libguestfs/tmp/.guestfs-1000/initrd.13471 -append panic=1 console=ttyS0 udevtimeout=600 no_timer_check lpj=3411128 acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=xterm-256color -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/home/rjones/d/libguestfs/tmp/libguestfs1kzChX/scratch.1,if=none,id=drive-scsi0-0-0-0,format=raw,cache=unsafe -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive file=/home/rjones/d/libguestfs/tmp/libguestfs1kzChX/overlay2,if=none,id=drive-scsi0-0-1-0,format=qcow2,cache=unsafe -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0 -chardev socket,id=charserial0,path=/home/rjones/d/libguestfs/tmp/libguestfs1kzChX/console.sock -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/home/rjones/d/libguestfs/tmp/libguestfs1kzChX/guestfsd.sock -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 The libvirtd stack trace doesn't show any signs of trouble. Any time you see the virThreadPoolWorker function blocked on virCondWait this indicates that libvirtd thread is idle waiting for an API request. The primary thread looks normal too, waiting in poll for socket I/O OK forget it. This turns out to be the kernel hanging bug: http://rawhidewatch.wordpress.com/2014/02/04/boot-failures-with-recent-rawhide-kernels/ |