Bug 1283198 - RFE: backport max monitor limitation from Qemu upstream
RFE: backport max monitor limitation from Qemu upstream
Status: VERIFIED
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
7.3
All Unspecified
high Severity unspecified
: rc
: 7.4
Assigned To: Gerd Hoffmann
Guo, Zhiyi
Jiri Herrmann
: FutureFeature, TestOnly
Depends On:
Blocks: 1075798 1283202 1283207 1395265
  Show dependency treegraph
 
Reported: 2015-11-18 07:41 EST by Frediano Ziglio
Modified: 2017-06-19 22:49 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Frediano Ziglio 2015-11-18 07:41:20 EST
Description of problem:
This is to support https://bugzilla.redhat.com/show_bug.cgi?id=1075798 in newer RHEL version.


Version-Release number of selected component (if applicable):
N/A

How reproducible:
Always.

Steps to Reproduce:
1. Try to set monitor number from interface (like virt-manager).
2. Open spice client
3. Try to open more monitors than configured number

Actual results:
Displays are opened without problems.

Expected results:
Failure and client should not even prompt for such setting.

Additional info:
Needs to backport to Qemu commit 567161fdd47aeb6987e700702f6bbfef04ae0236 and a52b2cbf218d52f9e357961acb271a98a2bdff71.
Comment 3 Gerd Hoffmann 2016-05-13 12:10:05 EDT
posted.
Comment 4 Jeff Nelson 2016-05-28 11:57:36 EDT
Fix included in qemu-kvm-1.5.3-113.el7
Comment 7 Christophe Fergeau 2016-07-01 11:20:52 EDT
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.
Comment 8 Christophe Fergeau 2016-07-01 12:18:10 EDT
I've requested tagging of spice-0.12.4-18.el7 in the build roots, this should have the needed symbol.
Comment 9 Christophe Fergeau 2016-09-02 08:50:32 EDT
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?
Comment 10 Christophe Fergeau 2016-09-02 08:52:20 EDT
(NB: QE testing of the SPICE-side of this is failing, which is why I'm asking, see rhbz#1283202 )
Comment 11 Jeff Nelson 2016-09-02 09:10:41 EDT
Gerd, were you able to confirm the patch works as expected?
Comment 12 Gerd Hoffmann 2016-09-05 04:41:42 EDT
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.
Comment 13 Christophe Fergeau 2016-09-05 05:04:14 EDT
(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.
Comment 14 Gerd Hoffmann 2016-09-05 08:23:45 EDT
(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.
Comment 15 Christophe Fergeau 2016-09-05 10:48:52 EDT
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.
Comment 16 Gerd Hoffmann 2016-09-06 08:49:12 EDT
> 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.
Comment 17 Christophe Fergeau 2016-09-07 11:44:05 EDT
(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\ )
Comment 19 Gerd Hoffmann 2017-01-10 06:13:35 EST
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?
Comment 20 Frediano Ziglio 2017-01-10 06:28:56 EST
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).
Comment 21 Gerd Hoffmann 2017-01-10 07:23:12 EST
(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 ...
Comment 22 Christophe Fergeau 2017-01-10 07:38:07 EST
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.
Comment 23 Christophe Fergeau 2017-01-24 09:15:34 EST
7.4 has been rebased to 0.12.8 now.
Comment 24 Guo, Zhiyi 2017-03-07 05:15:13 EST
(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
Comment 25 Gerd Hoffmann 2017-03-14 04:45:56 EDT
(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.
Comment 26 Ademar Reis 2017-03-31 17:13:20 EDT
(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?
Comment 27 Gerd Hoffmann 2017-04-03 01:43:12 EDT
> 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.
Comment 28 Ademar Reis 2017-04-03 08:38:17 EDT
(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.
Comment 31 Guo, Zhiyi 2017-06-13 00:05:36 EDT
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.
Comment 32 Guo, Zhiyi 2017-06-13 00:09:16 EDT
Hi Gerd,

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

BR/
Guo, Zhiyi
Comment 33 Gerd Hoffmann 2017-06-13 06:50:06 EDT
(In reply to Guo, Zhiyi from comment #32)
> Hi Gerd,
> 
>    Is this enough to verify the bug per comment 31? Thanks!

Yes.
Comment 34 Martin Kletzander 2017-06-14 04:55:26 EDT
Can you also check that it works with '-vga qxl -global qxl-vga.max_outputs=2'?
Comment 35 Guo, Zhiyi 2017-06-14 05:10:18 EDT
(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.
Comment 36 Guo, Zhiyi 2017-06-19 22:49:25 EDT
Per comment 31 -35 mark as verified

Note You need to log in before you can comment on or make changes to this bug.