severity 780093 normal thanks On Wed, Mar 11, 2015 at 03:09:11PM +0100, Thorsten Glaser wrote: > On Wed, 11 Mar 2015, Guido Günther wrote: > > > qemu. Also it would help to rund libvitd with debug level when > > starting the domain and see the output. > > sudo env LIBVIRT_DEBUG=1 /etc/init.d/libvirtd start #, thus. > > This is interesting. For the VMs created by virt-manager, which > have /usr/bin/kvm as emulator, it says KVM not supported by this > target. This matches the command line: > > tglase@tglase:~ $ kvm > KVM not supported for this target > No accelerator found! > > This is probably an x32 issue with src:qemu. > > For the VMs using qemu-in-chroot, it instead tries to start it with > -qmp unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait > and then fails to connect there. That being said, /var/lib/libvirt > is already in the list of schroot bind-mount directories, so this > should work. And indeed, if I run… > > LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin > HOME=/ /usr/local/bin/qemu-in-chroot -S -no-user-config -nodefaults > -nographic -M none -qmp > unix:/var/lib/libvirt/qemu/capabilities.monitor.sock,server,nowait -pidfile > /var/lib/libvirt/qemu/capabilities.pidfile > > … manually, then check the “mount” output, the directory is bindmounted. > > tglase@tglase:~ $ sudo ls -l /var/lib/libvirt/qemu/ > > total 20 > srwxr-xr-x 1 root root 0 Mär 11 15:05 > capabilities.monitor.sock > -rw------- 1 root root 6 Mär 11 15:05 capabilities.pidfile > drwxr-x--- 3 libvirt-qemu libvirt-qemu 4096 Okt 28 09:17 channel > drwxr-xr-x 2 root root 4096 Okt 28 09:17 dump > drwxr-xr-x 2 libvirt-qemu libvirt-qemu 4096 Okt 28 09:17 save > drwxr-xr-x 2 libvirt-qemu libvirt-qemu 4096 Okt 28 09:17 snapshot
I wonder why you still have capabilities.* sockets. Maybe these are tipping up things? They shouldn't belong to root but libvirt after all IIRC and they disappear after caps probing. I'm lowering the severity since the issue looks pretty much related to your x32 + wrapper setup. That said having the logs and maybe stracing the daemon should provide more insights. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
