[Qemu-devel] qemu commit 65207c59 broke libvirt's capability retrieval (apparently)

[Qemu-devel] qemu commit 65207c59 broke libvirt's capability retrieval (apparently)

[Laszlo Ersek]

[-- Attachment #1: Type: text/plain, Size: 3049 bytes --]

Hi All,

after pulling QEMU master today, my existent libvirt guests that have the following element:

  <pm>
    <suspend-to-mem enabled='yes'/>
    <suspend-to-disk enabled='no'/>
  </pm>

started to barf the following message at me:

----------
Error starting domain: unsupported configuration: setting ACPI S3 not supported

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 125, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1393, in startup
    self._backend.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 966, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: unsupported configuration: setting ACPI S3 not supported
----------

Now, I'm using RHEL-7.1.z libvirt with bleeding edge upstream qemu, so you could say this is "kinda unsupported" :), but anyway, I reckon this might be a problem with upstream libvirt too. Sorry if it's a known problem.

I found this qemu commit, ie.

commit 65207c59d99f2260c5f1d3b9c491146616a522aa
Author: Markus Armbruster <armbru@redhat.com>
Date:   Thu Mar 5 14:35:26 2015 +0100

    monitor: Drop broken, unused asynchronous command interface

with bisection. Unfortunately, the bisection was extremely painful, because between a working version and today's pull, part of the qemu history was uncompileable. It was ultimately fixed with

commit 9e472263b07d53cb3401ee49ef1b45ef195ddb84
Author: Michael S. Tsirkin <mst@redhat.com>
Date:   Mon Jun 1 21:03:59 2015 +0200

    acpi: add missing ssdt

Luckily, that commit suggests to remove the "iasl" binary from one's system, after which I could indeed continue the bisection.

If I remove the <pm> element from the domain XML, then libvirt barfs something else:

--------------
Error starting domain: unsupported configuration: hypervisor lacks deviceboot feature

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 125, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1393, in startup
    self._backend.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 966, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: unsupported configuration: hypervisor lacks deviceboot feature
--------------

Which tells me that it's not individual capabilities that are broken by qemu 65207c59, but the entire libvirt capability retrieval. Apparently libvirt is one user of that async monitor interface. (The message on commit 65207c59 itself mentions "qmp_capabilities".)

Sorry about the substandard formatting in the email, I'm in a bit of a hurry.

Bisection log attached.

Thanks
Laszlo

[-- Attachment #2: bisect.log --]
[-- Type: text/x-log, Size: 2275 bytes --]

git bisect start
# good: [e47c5ebd4da7328a448730c8179d08ef0f963397] docs: Add PXB documentation
git bisect good e47c5ebd4da7328a448730c8179d08ef0f963397
# bad: [edb783db23a7cf54ef2ef49d9fb367bfc6e954d7] i386/acpi-build: build_crs(): fetch BAR from PCI config space directly
git bisect bad edb783db23a7cf54ef2ef49d9fb367bfc6e954d7
# good: [9e472263b07d53cb3401ee49ef1b45ef195ddb84] acpi: add missing ssdt
git bisect good 9e472263b07d53cb3401ee49ef1b45ef195ddb84
# bad: [2700a976dba6b107365aa9af7fd927ffb3dd3b21] Merge remote-tracking branch 'remotes/mjt/tags/pull-trivial-patches-2015-06-03' into staging
git bisect bad 2700a976dba6b107365aa9af7fd927ffb3dd3b21
# good: [de3852877f1e452321352fdb7e678f079876a41b] configure: postfix --extra-cflags to QEMU_CFLAGS
git bisect good de3852877f1e452321352fdb7e678f079876a41b
# good: [94edf02c4c94781fa777c459fe86b52131b83cb6] hw/arm/virt: change indentation in a15memmap
git bisect good 94edf02c4c94781fa777c459fe86b52131b83cb6
# good: [be9f8a08727e46c790adb8caa8a4525a1e8e9e73] apic: convert ->busdev.qdev casts to C casts
git bisect good be9f8a08727e46c790adb8caa8a4525a1e8e9e73
# bad: [d2ceeb1d68ed8b005892408fcdb533f578aae081] Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20150602' into staging
git bisect bad d2ceeb1d68ed8b005892408fcdb533f578aae081
# good: [42d58e7c6760cb9c55627c28ae538e27dcf2f144] Merge remote-tracking branch 'remotes/sstabellini/tags/xen-15-06-02-tag' into staging
git bisect good 42d58e7c6760cb9c55627c28ae538e27dcf2f144
# bad: [4086182fcd9b106345b5cc535d78bcc6d13a7683] monitor: Propagate errors through invalid_qmp_mode()
git bisect bad 4086182fcd9b106345b5cc535d78bcc6d13a7683
# bad: [072ebe6b0351060b33287454fdef625fe79c858f] monitor: Use traditional command interface for HMP drive_del
git bisect bad 072ebe6b0351060b33287454fdef625fe79c858f
# bad: [84add864ebd2e6f3c645948ab595d8454165ebc5] monitor: Clean up after previous commit
git bisect bad 84add864ebd2e6f3c645948ab595d8454165ebc5
# bad: [65207c59d99f2260c5f1d3b9c491146616a522aa] monitor: Drop broken, unused asynchronous command interface
git bisect bad 65207c59d99f2260c5f1d3b9c491146616a522aa
# first bad commit: [65207c59d99f2260c5f1d3b9c491146616a522aa] monitor: Drop broken, unused asynchronous command interface

Re: [Qemu-devel] qemu commit 65207c59 broke libvirt's capability retrieval (apparently)

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

On 06/05/2015 03:42 PM, Laszlo Ersek wrote:

> I found this qemu commit, ie.
> 
> commit 65207c59d99f2260c5f1d3b9c491146616a522aa
> Author: Markus Armbruster <armbru@redhat.com>
> Date:   Thu Mar 5 14:35:26 2015 +0100
> 
>     monitor: Drop broken, unused asynchronous command interface
> 
> with bisection. Unfortunately, the bisection was extremely painful, because between a working version and today's pull, part of the qemu history was uncompileable. It was ultimately fixed with

> Which tells me that it's not individual capabilities that are broken by qemu 65207c59, but the entire libvirt capability retrieval. Apparently libvirt is one user of that async monitor interface. (The message on commit 65207c59 itself mentions "qmp_capabilities".)

Libvirt doesn't use async capabilities, so much as Markus accidentally
broke the QMP protocol by completely ditching support for the "id"
member that libvirt uses on every synchronous QMP command.  Several
threads already exist on the matter:

https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg01806.html
https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg01488.html

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] qemu commit 65207c59 broke libvirt's capability retrieval (apparently)

[Laszlo Ersek]

On 06/05/15 23:47, Eric Blake wrote:
> On 06/05/2015 03:42 PM, Laszlo Ersek wrote:
> 
>> I found this qemu commit, ie.
>>
>> commit 65207c59d99f2260c5f1d3b9c491146616a522aa
>> Author: Markus Armbruster <armbru@redhat.com>
>> Date:   Thu Mar 5 14:35:26 2015 +0100
>>
>>     monitor: Drop broken, unused asynchronous command interface
>>
>> with bisection. Unfortunately, the bisection was extremely painful, because between a working version and today's pull, part of the qemu history was uncompileable. It was ultimately fixed with
> 
>> Which tells me that it's not individual capabilities that are broken by qemu 65207c59, but the entire libvirt capability retrieval. Apparently libvirt is one user of that async monitor interface. (The message on commit 65207c59 itself mentions "qmp_capabilities".)
> 
> Libvirt doesn't use async capabilities, so much as Markus accidentally
> broke the QMP protocol by completely ditching support for the "id"
> member that libvirt uses on every synchronous QMP command.  Several
> threads already exist on the matter:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg01806.html
> https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg01488.html
> 

Fantastic, I was wondering how I could remedy this (without having to
rebase my work in progress onto 65207c59^). Your second link seems to
have a fix I can apply locally, temporarily. (Hm, well, your first link
does too, just with different comments, as you said.)

Many thanks!
Laszlo

Re: [Qemu-devel] qemu commit 65207c59 broke libvirt's capability retrieval (apparently)

[Markus Armbruster]

Laszlo Ersek <lersek@redhat.com> writes:

> On 06/05/15 23:47, Eric Blake wrote:
>> On 06/05/2015 03:42 PM, Laszlo Ersek wrote:
>> 
>>> I found this qemu commit, ie.
>>>
>>> commit 65207c59d99f2260c5f1d3b9c491146616a522aa
>>> Author: Markus Armbruster <armbru@redhat.com>
>>> Date:   Thu Mar 5 14:35:26 2015 +0100
>>>
>>>     monitor: Drop broken, unused asynchronous command interface
>>>
>>> with bisection. Unfortunately, the bisection was extremely painful,
>>> because between a working version and today's pull, part of the
>>> qemu history was uncompileable. It was ultimately fixed with
>> 
>>> Which tells me that it's not individual capabilities that are
>>> broken by qemu 65207c59, but the entire libvirt capability
>>> retrieval. Apparently libvirt is one user of that async monitor
>>> interface. (The message on commit 65207c59 itself mentions
>>> "qmp_capabilities".)
>> 
>> Libvirt doesn't use async capabilities, so much as Markus accidentally
>> broke the QMP protocol by completely ditching support for the "id"
>> member that libvirt uses on every synchronous QMP command.  Several
>> threads already exist on the matter:
>> 
>> https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg01806.html
>> https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg01488.html
>> 
>
> Fantastic, I was wondering how I could remedy this (without having to
> rebase my work in progress onto 65207c59^). Your second link seems to
> have a fix I can apply locally, temporarily. (Hm, well, your first link
> does too, just with different comments, as you said.)
>
> Many thanks!

Fixed in current master: commit 779cec4.  Sorry for the inconvenience!