Bug 1283198

posted.

Fix included in qemu-kvm-1.5.3-113.el7

The patch adding support for that uses
#if SPICE_SERVER_VERSION >= 0x000c06 /* release 0.12.6 */

but rhel-7.3 will still be using spice 0.12.6. Once there is a spice build with spice_qxl_set_max_monitors() in the buildroot (bug #1283202), the version requirements in the QEMU patch will need to be lowered, and QEMU rebuilt.

I've requested tagging of spice-0.12.4-18.el7 in the build roots, this should have the needed symbol.

I still see the #if SPICE_SERVER_VERSION >= 0x000c06 /* release 0.12.6 */ checks in latest qemu-kvm dist-git. Has anyone been able to test this?

(NB: QE testing of the SPICE-side of this is failing, which is why I'm asking, see rhbz#1283202 )

Gerd, were you able to confirm the patch works as expected?

It worked with my local builds, but I have a newer spice-server version installed here for virgl testing.

Looking at the RHEL-7.3 spice-server package:  Mucking with server/spice-server.syms like 0083-server-allows-to-set-maximum-monitors.patch does breaks symbol versioning.  Please remove/revert the patch.

To fix this bug qemu-kvm needs a rebuild after spice-server rebased to 0.12.6 (or newer).  Which at this point pretty much implies RHEL-7.4.  Setting back to assigned, updating flags.

(In reply to Gerd Hoffmann from comment #12)
> Looking at the RHEL-7.3 spice-server package:  Mucking with
> server/spice-server.syms like
> 0083-server-allows-to-set-maximum-monitors.patch does breaks symbol
> versioning.  Please remove/revert the patch.

Is it that bad of a breakage? Imo while not 100% nice from a versioning point of view, this should not be causing too many issues. Only things I can think of is that in some corner cases, it will be possible to install rpms depending on the newer symbol version, but still get missing symbols. I don't think this could trigger during regular RHEL upgrades.

(In reply to Christophe Fergeau from comment #13)
> (In reply to Gerd Hoffmann from comment #12)
> > Looking at the RHEL-7.3 spice-server package:  Mucking with
> > server/spice-server.syms like
> > 0083-server-allows-to-set-maximum-monitors.patch does breaks symbol
> > versioning.  Please remove/revert the patch.
> 
> Is it that bad of a breakage? Imo while not 100% nice from a versioning
> point of view, this should not be causing too many issues. Only things I can
> think of is that in some corner cases, it will be possible to install rpms
> depending on the newer symbol version, but still get missing symbols.

Correct.

> I don't think this could trigger during regular RHEL upgrades.

If you only upgrade and never downgrade packages, and if you never cherry-pick
updates, then yes, you wouldn't hit it.  To be exact: you wouldn't need symbol
versioning at all in that case.

But if you jump forward/backward with qemu and spice builds, for example to pinpoint which build introduced some regression, you can easily run into this.  Also when testing 7.4 qemu builds on a 7.3 install (as far I know QE does this before 7.4 snapshot composes are available), without also installing newer spice because rpm thinks everything is fine even though it is not.

Bottom line: There is a reason why symbol versioning exists in the first place,
and IMO it is not acceptable to break it.

In this case, the whole upstream version block is
SPICE_SERVER_0.12.6 {
global:
    spice_qxl_set_max_monitors;
    spice_replay_free;
    spice_replay_new;
    spice_replay_next_cmd;
    spice_replay_free_cmd;
} SPICE_SERVER_0.12.5;

I don't expect the spice_replay API to be widely used, especially not right now, so we could just keep this suboptimal versioning in 7.3 as it is, and plan for a proper rebase in 7.4 in order to fix these potential issues.

Alternatively, having a stub spice_replay_ API in 7.3 which is a noop could work too.

> I don't expect the spice_replay API to be widely used, especially not right
> now, so we could just keep this suboptimal versioning in 7.3 as it is, and
> plan for a proper rebase in 7.4 in order to fix these potential issues.

Maybe.  I'll go forward any fallout from this to you.

(In reply to Gerd Hoffmann from comment #16)
> Maybe.  I'll go forward any fallout from this to you.

Works for me. (famous last words /o\ )

So, we missed the 7.3 boat, lets have a look at 7.4 ...
What is the spice-server plan?  Rebase to 0.12.6 or newer?

If I remember is all in libvirt team shoulder.
For 7.4 we are planning to rebase on 0.13.2 (or 0.13.3).

(In reply to Frediano Ziglio from comment #20)
> If I remember is all in libvirt team shoulder.
> For 7.4 we are planning to rebase on 0.13.2 (or 0.13.3).

OK, so we don't need to patch the version check in downstream qemu for 7.4, once qemu is build against rebased spice-server everything should work fine.

BTW: I guess 0.13.3 should better be 0.14.0, or the "0.12 (even) is stable, 0.13 (odd) is devel" declaration should be updated on https://www.spice-space.org/download.html.  Current situation is quite confusing, with fedora shipping a release declared as "devel", and RHEL doing the same wouldn't improve it ...

7.4 will be rebased to latest 0.12.x, 7.5 should get 0.13.x which by then will get a 0.14 version number.

7.4 has been rebased to 0.12.8 now.

(In reply to Christophe Fergeau from comment #23)
> 7.4 has been rebased to 0.12.8 now.

Hi,

  KVM QE see qemu-kvm-rhev 2.8 doesn't get the max_outputs for qxl, should we also import this option to qemu-kvm-rhev?

BR/
Guo, Zhiyi

(In reply to Guo, Zhiyi from comment #24)
> (In reply to Christophe Fergeau from comment #23)
> > 7.4 has been rebased to 0.12.8 now.

new spice must be tagged into the buildroot so it is actually used for builds, and qemu must be build after that.

Meanwhile this seems to have happened, I can see the max_outputs option with build qemu-kvm-rhev-2.8.0-6.el7.x86_64.

Same for qemu-kvm: It either should be there already, or the next build should happen against new spice and the new option should show up.

(In reply to Gerd Hoffmann from comment #25)
> (In reply to Guo, Zhiyi from comment #24)
> > (In reply to Christophe Fergeau from comment #23)
> > > 7.4 has been rebased to 0.12.8 now.
> 
> new spice must be tagged into the buildroot so it is actually used for
> builds, and qemu must be build after that.
> 
> Meanwhile this seems to have happened, I can see the max_outputs option with
> build qemu-kvm-rhev-2.8.0-6.el7.x86_64.
> 
> Same for qemu-kvm: It either should be there already, or the next build
> should happen against new spice and the new option should show up.

So this BZ is TestOnly + FailedQA. What's the next step? Still wait for a new build, or retest with what's there already? Gerd, can you tell us which versions should have the fix?

> So this BZ is TestOnly + FailedQA. What's the next step? Still wait for a
> new build, or retest with what's there already? Gerd, can you tell us which
> versions should have the fix?

/me checks brew ...

According to the build dates qemu-kvm-1.5.3-134.el7 & newer should work.
Yes, please retest with build 134 or 135.

(In reply to Gerd Hoffmann from comment #27)
> > So this BZ is TestOnly + FailedQA. What's the next step? Still wait for a
> > new build, or retest with what's there already? Gerd, can you tell us which
> > versions should have the fix?
> 
> /me checks brew ...
> 
> According to the build dates qemu-kvm-1.5.3-134.el7 & newer should work.
> Yes, please retest with build 134 or 135.

Thanks for checking. Changing status to MODIFIED.

Test against qemu-kvm-1.5.3-140.el7.x86_64 and kernel 3.10.0-679.el7.x86_64(guest & host):

qemu cli used:
/usr/libexec/qemu-kvm -name rhel-sp4 -m 4G -machine pc,accel=kvm\
        -S \
        -cpu SandyBridge,check,enforce \
        -smp 2 \
        -monitor stdio \
        -qmp tcp:0:4444,server,nowait \
        -serial unix:/tmp/console,server,nowait \
        -drive file=rhelsp4.qcow2,if=none,id=drive-scsi-disk0,format=qcow2,cache=none,werror=stop,rerror=stop -device virtio-scsi-pci,id=scsi0,addr=04 -device scs
i-hd,drive=drive-scsi-disk0,bus=scsi0.0,scsi-id=0,lun=0,id=scsi-disk0,bootindex=1 \
        -netdev tap,id=idinWyYp,vhost=on -device virtio-net-pci,mac=42:ce:a9:d2:4d:d7,id=idlbq7eA,netdev=idinWyYp \
        -spice port=3003,disable-ticketing,agent-mouse=on \
        -device virtio-serial-pci -chardev spicevmc,id=vdagent,debug=0,name=vdagent \
        -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \
        -device qxl-vga \

Check multi heads from remote-viewer: View -> Displays, there are Display (2), (3), (4) there and both of them can be enabled without problem.

Boot guest with similar qemu cli but add option max_outputs=2 to qxl-vga(-device qxl-vga,max_outputs=2), check multi heads, only Display (2) there and  it can be enabled and display correct.

Hi Gerd,

   Is this enough to verify the bug per comment 31? Thanks!

BR/
Guo, Zhiyi

(In reply to Guo, Zhiyi from comment #32)
> Hi Gerd,
> 
>    Is this enough to verify the bug per comment 31? Thanks!

Yes.

Can you also check that it works with '-vga qxl -global qxl-vga.max_outputs=2'?

(In reply to Martin Kletzander from comment #34)
> Can you also check that it works with '-vga qxl -global
> qxl-vga.max_outputs=2'?

Yes, after check, the behavior is same as -device qxl-vga,max_outputs=2.

Boot rhel7.4 guest with option "-vga qxl" only and check multi heads from remote-viewer: View -> Displays, there are Display (2), (3), (4) there and both of them can be enabled without problem.

Boot guest again but with option "-vga qxl -global qxl-vga.max_outputs=2", check multi heads, only Display (2) there and  it can be enabled and display correct.

Per comment 31 -35 mark as verified

Shouldn't this bug be closed/released already?

(In reply to Martin Tessun from comment #37)
> Shouldn't this bug be closed/released already?

Yes.  Seems the "fixed in version" field wasn't set for some reason, so the release scripts didn't pick this up on 7.4 release.