control: reassign -1 libvirtd control: found 3.9.0-1 control: retitle -1 libvirtd crashes when starting a vm with IDE cdrom control: forcemerge -1 881293
Hi, On Thu, Dec 07, 2017 at 03:38:24PM +0100, Pascal Obry wrote: > > Package: libvirt > Version: 3.10 > Severity: grave > > With libvirt version 3.10 I cannot start a VM. Reverting to 3.0 > (Debian/stable) all is fine. This was initially found in GNOME-Boxes > but I have been able to reproduce on the command line using virsh. > > Note also that I had the same issue with 3.9. > > On one console: > > $ LIBVIRT_DEBUG=1 gdb /usr/sbin/libvirtd > > On a second console, I tried to start the VM: > > $ virsh start boxes-winxp > > Then I got this exception from libvirtd: > > Thread 5 "libvirtd" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7febad4a5700 (LWP 7867)] > 0x00007feb94b109c8 in virStorageFileReportBrokenChain () > from /usr/lib/libvirt/connection-driver/libvirt_driver_storage.so > (gdb) bt > #0 0x00007feb94b109c8 in virStorageFileReportBrokenChain () > from /usr/lib/libvirt/connection-driver/libvirt_driver_storage.so > #1 0x00007feb7d266da3 in qemuDomainDetermineDiskChain () > from /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so > #2 0x00007feb7d28eec2 in qemuProcessPrepareHost () > from /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so > #3 0x00007feb7d294b71 in qemuProcessStart () > from /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so > #4 0x00007feb7d2f5201 in ?? () > from /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so > #5 0x00007feb7d2f58e6 in ?? () > from /usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so > #6 0x00007febb9e5e077 in virDomainCreate (domain=0x7feb980008c0) > at ../../../src/libvirt-domain.c:6531 > #7 0x000056190ba2ed9c in ?? () > #8 0x00007febb9ec697c in virNetServerProgramDispatchCall > (msg=0x56190d9e7590, > client=0x56190d9e6fb0, server=0x56190d9d00f0, prog=0x56190d9e4f40) > at ../../../src/rpc/virnetserverprogram.c:437 > #9 virNetServerProgramDispatch (prog=0x56190d9e4f40, server=0x56190d9d00f0, > client=0x56190d9e6fb0, msg=0x56190d9e7590) > at ../../../src/rpc/virnetserverprogram.c:307 > #10 0x000056190ba3e988 in ?? () > #11 0x00007febb9da1c01 in virThreadPoolWorker ( > opaque=opaque@entry=0x56190d9ce9f0) > at ../../../src/util/virthreadpool.c:167 > #12 0x00007febb9da0f78 in virThreadHelper (data=<optimized out>) > at ../../../src/util/virthread.c:206 > #13 0x00007febb68b0519 in start_thread (arg=0x7febad4a5700) > at pthread_create.c:456 > #14 0x00007febb65f2a5f in clone () > at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97 > (gdb) > > I noticed that running with 3.0 I had a message saying that /dev/sr0 is > not accessible. And indeed I do not have a CDROM on this machine. The > .xml were migrated from a machine with a CDROM to this new one. > > Removing: > > <disk type='block' device='cdrom'> > <driver name='qemu' type='raw'/> > <source dev='/dev/sr0' startupPolicy='optional'/> > <target dev='hdc' bus='ide'/> > <readonly/> > <address type='drive' controller='0' bus='1' target='0' unit='0'/> > </disk> > > Seems to fix the issue. Yet, libvirt should not crash on this. And the > backtrace makes sense with this fix BTW. Yept. Should not crash. Looks similar to another issue I did not get around to look at. Cheers, -- Guido
