Bug#780093: [Pkg-libvirt-maintainers] Bug#780093: libvirt: error: unsupported configuration: QEMU 2.1.2 is too new for help parsing

2015-03-17 Thread Guido Günther 
reassign 780093 libvirt-daemon
severity 780093 normal
retitule 780093 Fails capability parsing in a bind mounted amd64 chroot on x32

On Mon, Mar 16, 2015 at 03:43:10PM +0100, Thorsten Glaser wrote:
 severity 780093 important
 thanks
sigh

 
 On Wed, 11 Mar 2015, Guido Günther wrote:
 
  That said having the logs and maybe stracing the daemon should
  provide more insights.
 
 Did you get any more insights?

This is a special setup that fails to parse the capabilities using a
qemu wrapper on x32 to run in a x86_64 chroot (as far as I understand
it yet). I'd be good to find out why. I'm currently lacking the time
(and internet connectivity to build chroots) to reproduce this. In any
case if somebody else wants to step in having your schroot and vm
configuration would help.

I'd be also good to have the requested logs at debug level. There
might already be the solution in there.

 In the meantime, I downgraded libvirt0 (and the three dependants
 libvirt-clients libvirt-daemon libvirt-daemon-system) to 1.2.9-8
 from 1.2.9-9, and my VMs start up again.
 
 So, whatever you did in 1.2.9-9, it introduced a severe regression.

It fixed a severe regression on since it didn't fall back to broken
help parsing preventing VMs to start on fresh installations.

Cheers,
 -- Guido


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780093: [Pkg-libvirt-maintainers] Bug#780093: libvirt: error: unsupported configuration: QEMU 2.1.2 is too new for help parsing

2015-03-17 Thread Thorsten Glaser 
On Tue, 17 Mar 2015, Guido Günther wrote:

 This is a special setup that fails to parse the capabilities using a
 qemu wrapper on x32 to run in a x86_64 chroot (as far as I understand

It also fails to parse them *without* the chroot, with…

emulator/usr/bin/kvm/emulator

… which is what virt-manager creates. But that’s probably
a bug in the qemu-kvm package (plus one in virt-manager if
/usr/bin/kvm is not supposed to be used). Changing it to…

emulator/usr/bin/qemu-system-x86_64/emulator

… and changing domain type='kvm' to domain type='qemu'
makes this succeed, so that’s unrelated. (Mentioning this
because I mentioned it earlier in this bugreport, so we
know this is not the problem.)

 case if somebody else wants to step in having your schroot and vm
 configuration would help.

OK. A small reproducer is here:

domain type='kvm'
  named-i-amd64/name
  uuid2affcd84-73f4-bbb2-2fd5-fd920b9806b7/uuid
  memory unit='KiB'524288/memory
  currentMemory unit='KiB'524288/currentMemory
  vcpu placement='static'1/vcpu
  os
type arch='x86_64' machine='pc-1.1'hvm/type
boot dev='network'/
  /os
  features
acpi/
apic/
pae/
  /features
  clock offset='utc'/
  on_poweroffdestroy/on_poweroff
  on_rebootrestart/on_reboot
  on_crashrestart/on_crash
  devices
emulator/usr/local/bin/qemu-in-chroot/emulator
controller type='usb' index='0'
  address type='pci' domain='0x' bus='0x00' slot='0x01' 
function='0x2'/
/controller
controller type='pci' index='0' model='pci-root'/
interface type='bridge'
  mac address='52:54:00:02:9c:44'/
  source bridge='br0'/
  model type='virtio'/
  address type='pci' domain='0x' bus='0x00' slot='0x03' 
function='0x0'/
/interface
serial type='pty'
  target port='0'/
/serial
console type='pty'
  target type='serial' port='0'/
/console
input type='tablet' bus='usb'/
input type='mouse' bus='ps2'/
input type='keyboard' bus='ps2'/
graphics type='vnc' port='-1' autoport='yes'/
video
  model type='cirrus' vram='9216' heads='1'/
  address type='pci' domain='0x' bus='0x00' slot='0x02' 
function='0x0'/
/video
memballoon model='virtio'
  address type='pci' domain='0x' bus='0x00' slot='0x05' 
function='0x0'/
/memballoon
  /devices
/domain

The other files (hopefully all relevant ones) are:

/etc/schroot/schroot.conf:

[sid-amd64]
description=Debian sid/amd64 (unstable)
type=directory
directory=/home/AMD64
root-users=libvirt-qemu,tglase,root
#personality=linux64
command-prefix=linux64,eatmydata
setup.fstab=fstab.qemu

sed 's/^X//' etc/schroot/fstab.qemu  'END-of-etc/schroot/fstab.qemu'
X# fstab: static file system information for chroots.
X# Note that the mount point will be prefixed by the chroot path
X# (CHROOT_PATH)
X#
X# file system mount point   type  options   dump  pass
X/proc   /proc   nonerw,bind 0   0
X/sys/sysnonerw,bind 0   0
X/dev/devnonerw,bind 0   0
X/dev/pts/dev/ptsnonerw,bind 0   0
X/home   /home   nonerw,bind 0   0
X/tmp/tmpnonerw,bind 0   0
X
X# It may be desirable to have access to /run, especially if you wish
X# to run additional services in the chroot.  However, note that this
X# may potentially cause undesirable behaviour on upgrades, such as
X# killing services on the host.
X#/run   /runnonerw,bind 0   0
X#/run/lock  /run/lock   nonerw,bind 0   0
X#/dev/shm   /dev/shmnonerw,bind 0   0
X/run/shm   /run/shmnonerw,bind 0   0
X
X/var/lib/libvirt /var/lib/libvirt none rw,bind 0   0
X/var/cache/pbuilder /var/cache/pbuilder none  rw,bind 0   0
END-of-etc/schroot/fstab.qemu

 I'd be also good to have the requested logs at debug level. There
 might already be the solution in there.

I’d sent them to you already, in separate direct eMail, due to size.

  In the meantime, I downgraded libvirt0 (and the three dependants
  libvirt-clients libvirt-daemon libvirt-daemon-system) to 1.2.9-8
  from 1.2.9-9, and my VMs start up again.
  
  So, whatever you did in 1.2.9-9, it introduced a severe regression.
 
 It fixed a severe regression on since it didn't fall back to broken
 help parsing preventing VMs to start on fresh installations.

Let’s meet in the middle and say it swapped a severe regression
with another severe regression.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.

Bug#780093: [Pkg-libvirt-maintainers] Bug#780093: libvirt: error: unsupported configuration: QEMU 2.1.2 is too new for help parsing

2015-03-16 Thread Thorsten Glaser 
severity 780093 important
thanks

On Wed, 11 Mar 2015, Guido Günther wrote:

 That said having the logs and maybe stracing the daemon should
 provide more insights.

Did you get any more insights?

In the meantime, I downgraded libvirt0 (and the three dependants
libvirt-clients libvirt-daemon libvirt-daemon-system) to 1.2.9-8
from 1.2.9-9, and my VMs start up again.

So, whatever you did in 1.2.9-9, it introduced a severe regression.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780093: [Pkg-libvirt-maintainers] Bug#780093: libvirt: error: unsupported configuration: QEMU 2.1.2 is too new for help parsing

2015-03-11 Thread Guido Günther 
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 root0 Mär 11 15:05 
 capabilities.monitor.sock
 -rw--- 1 root root6 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-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780093: [Pkg-libvirt-maintainers] Bug#780093: libvirt: error: unsupported configuration: QEMU 2.1.2 is too new for help parsing

2015-03-11 Thread Thorsten Glaser 
On Wed, 11 Mar 2015, Guido Günther wrote:

 I wonder why you still have capabilities.* sockets. Maybe these are

Nonono, these are happening *during* my tests, in which I removed
the daemonising parameter from the qemu call.

 I'm lowering the severity since the issue looks pretty much related to
 your x32 + wrapper setup.

The qemu used is in a chroot. When I ask the amd64 qemu for its
capabilities, I get an empty array, IIUC:

{
  QMP: {
capabilities: [

],
version: {
  package:  (Debian 1:2.1+dfsg-11),
  qemu: {
major: 2,
micro: 2,
minor: 1
  }
}
  }
}

(pretty-printed)

So, is this correct? Does this confuse libvirt?

I’ll send one batch of logs per PM.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780093: [Pkg-libvirt-maintainers] Bug#780093: libvirt: error: unsupported configuration: QEMU 2.1.2 is too new for help parsing

2015-03-11 Thread Thorsten Glaser 
On Wed, 11 Mar 2015, Guido Günther wrote:

 Please do a:
 
 grep usedQMP /var/cache/libvirt/qemu/capabilities/*.xml

root@tglase:~ # grep usedQMP /var/cache/libvirt/qemu/capabilities/*.xml
/var/cache/libvirt/qemu/capabilities/04f7ed9deb8a0351be750a8a1c4632481a4a0d230cc6a3a7b04048de811f77b3.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/06167c9b895ea7ab421df06e033dc9191e66e8c13ca1228e8268781460574cdb.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/065697b54cace5750c81605e09ad550812a395badc1cfe6908dbb6212962ea20.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/0ad54346623871452df24f8f1874a98f35e9ec442a178537598576e22c527d09.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/3a103308fa27eaf89cdce3012d683c03992c32ed1f4ce0d021dee0b861a013c1.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/3b4aa2e96c8beff35a23c55885e3ceab0e96bd68d3086046281ff63c6781356a.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/491db0c56c1ec4767e9318821abbd95265d89129e189f53034fb45f55eb45ae6.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/4b21437223cbdecdb4e776fe0bb40302a421554fc350bfbb986908518557721d.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/62083361a5e41939a82a3d2d25c4b1f750524b164b2e8b9db92bb101e18166f2.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/6f185fa01c51ba508ff8e75421e02b82053c3ebbe2acce77ed3c1772a5ad395e.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/7468d4cc96179096e1f0d36ff57c0bdbe0dec6d6d4d19d595efe576201dc9e07.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/87ec9299b933cd6b566ae822928e0c2effac281ced4939efcabd4bb8e6aa643b.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/926803a9278e445ec919c2b6cbd8c1c449c75b26dcb1686b774314180376c725.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/a013a09a30bf35fbea5b0236d43e579da4a041eaea677bc2f449290e5b7a5d5e.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/b3a57e99a43969756b075c47edc1e2f052f32867c3cdf5c5e296cbb45657f47d.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/b5cd104190c35fb4be904c7a1b60334c076a6b9e2b1de71598f704cbb8c7e821.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/c53fc183ccc508bf479a4cf1aaf177cd01deec2fd538768f80424f86ce4593ed.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/da2557db089d471f34cd87cca5f993e7a92c8fa664a3b33a0dce94b53b367a5c.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/dc8586db4ee7ec8dd97a1f390df64a1b8784a20690a2861b63673d04e1c8ee55.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/dd1df1169130ace90ab0a84c9c9c5ef04ccb975ad1b1223186b7365f31278c42.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/e0d8fff7434f454a924cdaec7f23a99b9c31fb79996e371676a3a2d675277d45.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/e1caee7051f35870d7e8e4ab2c531b5f3d362fb42332ef2ad935123c82b04da1.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/f11008721aacc79c97e592178e61264d75be551864cd79cc41fe820e31262f27.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/f7ac86dc1cb75a6fef7c6a75bdb4376a356454ee67fac93fb4212d674a69be64.xml:
  usedQMP/
/var/cache/libvirt/qemu/capabilities/fc71922a33655f783c5f81d792e9d80a2ef61c052a160a8725f21a2a8b396375.xml:
  usedQMP/

 if it doesn't find any matches do a

Hm, it does.

 something seems to be wrong with your capabilities parsing of
 qemu. Also it would help to rund libvitd with debug level when
 starting the domain and see the output.

How do I do that? Can’t find anything in the init script or
defaults file.

Thanks,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780093: [Pkg-libvirt-maintainers] Bug#780093: libvirt: error: unsupported configuration: QEMU 2.1.2 is too new for help parsing

2015-03-11 Thread Guido Günther 
On Tue, Mar 10, 2015 at 12:28:40AM +0100, Thorsten Glaser wrote:
 On Mon, 9 Mar 2015, Guido Günther wrote:
 
  wrapping qemu/kvm by a skript or something?
 
 Yes, necessarily:
 
 tglase@tglase:~ $ virsh -c qemu:///system dumpxml MirBSD | fgrep emul 

 emulator/usr/local/bin/qemu-in-chroot/emulator
 tglase@tglase:~ $ cat /usr/local/bin/qemu-in-chroot
 #!/bin/sh
 exec schroot -c sid-amd64 -u root -- qemu-system-x86_64 -enable-kvm $@

 Otherwise I cannot assign more than 2047 MiB RAM.
 
 *But*:
 
 tglase@tglase:~ $ virsh -c qemu:///system dumpxml SuSE_Linux_1.0 | fgrep emul
 emulator/usr/bin/kvm/emulator
 tglase@tglase:~ $ virsh -c qemu:///system start SuSE_Linux_1.0
 error: Failed to start domain SuSE_Linux_1.0
 error: unsupported configuration: QEMU 2.1.2 is too new for help parsing
 
 So this also happens for VMs created by virt-manager and
 then untouched.

Please do a:

grep usedQMP /var/cache/libvirt/qemu/capabilities/*.xml

if it doesn't find any matches do a

rm /var/cache/libvirt/qemu/capabilities/*.xml

something seems to be wrong with your capabilities parsing of
qemu. Also it would help to rund libvitd with debug level when
starting the domain and see the output.

 
  Does
  
  virsh capabilities
  
  show the same error?
 
 No, it shows a bunch of XML things (capabilities/{host,guest}/…).

Good.
 -- Guido


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780093: [Pkg-libvirt-maintainers] Bug#780093: libvirt: error: unsupported configuration: QEMU 2.1.2 is too new for help parsing

2015-03-11 Thread Thorsten Glaser 
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 root0 Mär 11 15:05 
capabilities.monitor.sock
-rw--- 1 root root6 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

If I connect to this from outside the chroot, I get:

tglase@tglase:~ $ sudo nc -U /var/lib/libvirt/qemu/capabilities.monitor.sock
{QMP: {version: {qemu: {micro: 2, minor: 1, major: 2}, package:  
(Debian 1:2.1+dfsg-11)}, capabilities: []}}

Does this help?

For the record, if I go into a (the same) chroot manually, start qemu
with -qmp, then connect to that inside the same chroot, I get the same
output. The presence or absence of -enable-kvm also does not change it.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780093: [Pkg-libvirt-maintainers] Bug#780093: libvirt: error: unsupported configuration: QEMU 2.1.2 is too new for help parsing

2015-03-11 Thread Guido Günther 
On Wed, Mar 11, 2015 at 01:24:48PM +0100, Thorsten Glaser wrote:
[..snip..]
  something seems to be wrong with your capabilities parsing of
  qemu. Also it would help to rund libvitd with debug level when
  starting the domain and see the output.
 
 How do I do that? Can’t find anything in the init script or
 defaults file.

https://libvirt.org/logging.html#log_daemon

Cheers,
 -- Guido


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780093: [Pkg-libvirt-maintainers] Bug#780093: libvirt: error: unsupported configuration: QEMU 2.1.2 is too new for help parsing

2015-03-09 Thread Guido Günther 
On Mon, Mar 09, 2015 at 10:05:02AM +0100, Thorsten Glaser wrote:
 Package: libvirt-clients
 Version: 1.2.9-9
 Severity: grave
 Justification: renders package unusable
 
 tglase@tglase:~ $ virsh -c qemu:///system start MirBSD
 error: Failed to start domain MirBSD
 error: unsupported configuration: QEMU 2.1.2 is too new for help parsing

That is because it should use the more reliable QMP probing. Are you
wrapping qemu/kvm by a skript or something?

Does

virsh capabilities

show the same error? Anything in the daemon logs (if not please try
increasing the debug level).
Cheers,
 -- Guido


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780093: [Pkg-libvirt-maintainers] Bug#780093: libvirt: error: unsupported configuration: QEMU 2.1.2 is too new for help parsing

2015-03-09 Thread Thorsten Glaser 
On Mon, 9 Mar 2015, Guido Günther wrote:

 wrapping qemu/kvm by a skript or something?

Yes, necessarily:

tglase@tglase:~ $ virsh -c qemu:///system dumpxml MirBSD | fgrep emul   
 
emulator/usr/local/bin/qemu-in-chroot/emulator
tglase@tglase:~ $ cat /usr/local/bin/qemu-in-chroot
#!/bin/sh
exec schroot -c sid-amd64 -u root -- qemu-system-x86_64 -enable-kvm $@

Otherwise I cannot assign more than 2047 MiB RAM.

*But*:

tglase@tglase:~ $ virsh -c qemu:///system dumpxml SuSE_Linux_1.0 | fgrep emul
emulator/usr/bin/kvm/emulator
tglase@tglase:~ $ virsh -c qemu:///system start SuSE_Linux_1.0
error: Failed to start domain SuSE_Linux_1.0
error: unsupported configuration: QEMU 2.1.2 is too new for help parsing

So this also happens for VMs created by virt-manager and
then untouched.

 Does
 
 virsh capabilities
 
 show the same error?

No, it shows a bunch of XML things (capabilities/{host,guest}/…).

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org