Bug 1283207

Another round posted upstream:

https://www.redhat.com/archives/libvir-list/2016-March/msg00410.html

Current version is this one now:

https://www.redhat.com/archives/libvir-list/2016-March/msg01198.html

v4: https://www.redhat.com/archives/libvir-list/2016-March/msg01436.html

Is this still planned for 7.3? Just double checking before adding the needed patches to the spice package.

The question is: how does this look upstream?  I just received question yesterday about one thing in the patches and it basically was about why don't we go the way of another version.  So it's just waiting for reviews and people caring about how do we handle compatibility.

(In reply to Martin Kletzander from comment #6)
> The question is: how does this look upstream?

Oh sorry for the ping then, I did not pay enough attention to the upstream mailing list lately and assumed this had been merged already.

No problem.  I would update this BZ if there was a change.  I'll keep this BZ posted.

Fixed upstream with v1.3.5-29-g6e81a1f9ef21..v1.3.5-30-g3484c05ce0dc: 

commit 6e81a1f9ef21e0e01f7fda996f19070f51bd63a8
Author: Martin Kletzander <mkletzan>
Date:   Fri Dec 11 14:26:24 2015 +0100

    qemu: Check for qxl's max_outputs parameter
    
commit 3484c05ce0dc34064cc2f81636482b93771803ad
Author: Martin Kletzander <mkletzan>
Date:   Fri Dec 11 14:43:10 2015 +0100

    qemu: Add support to QXL's max_outputs parameter

hi, Martin,

The depend on BZ 1283198 and 1283202 are all moved to RHEL7.4, we can not verify this libvirt bug, should we move this bug to RHEL7.4 also? Thanks.

Are there any packages you could verify this with?  If not, then probably just move it to next release, set the TestOnly Keyword and write the reason for that in this BZ.  Or I guess your comment and mine are enough of a description for that =)

Test with latest libvirt and qemu-kvm-rhev, it seems that qemu-kvm-rhev doesn't support max_outputs for now.

Builds:
libvirt-2.0.0-8.el7.x86_64
qemu-kvm-rhev-2.6.0-23.el7.x86_64

Steps:
1.Prepare a domain with the following xml, set head='3' for video device:
...
    <video>
      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='3' primary='yes'/>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </video>

2. Start guest

3. Check qemu command line, no max_outputs option is added:
..-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,bus=pci.0,addr=0x6 ...

4. Try to start qemu with the following command line:
# /usr/libexec/qemu-kvm -device qxl-vga,max_outputs=2
qemu-kvm: -device qxl-vga,max_outputs=2: Property '.max_outputs' not found

# /usr/libexec/qemu-kvm -device qxl,max_outputs=2
qemu-kvm: -device qxl,max_outputs=2: Property '.max_outputs' not found

(In reply to JinFangge from comment #13)
You can try it with upstream QEMU if you want to verify this bug.

(In reply to Martin Kletzander from comment #14)
> (In reply to JinFangge from comment #13)
> You can try it with upstream QEMU if you want to verify this bug.

hi, Martin,

We add the current verify result and steps in comment 13 for reference. Per comment 11, 12 and 13, we'd like to move this bug to RHEL7.4 and mark as Testonly. We are not sure if this feature will be working well with the upstream QEMU now, since this feature will be implemented with spice(BZ1283202), qemu(BZ1283198) and libvirt(this BZ) components together, this feature is still not working well in spice and qemu till now, you can see the details in the other bugs.
So, we'd like to move this bug to RHEL7.4 with testonly, I think it's ok for your per comment 12, right?

(In reply to Xuesong Zhang from comment #15)
Sure, that works for me.

Per comments 11 to 16, move this bug to RHEL7.4 and add keyword "testonly" since the patches are included in current build already.

Verify with build:
libvirt-3.2.0-3.el7.x86_64
qemu-kvm-rhev-2.9.0-1.el7.x86_64


Steps:
1. Prepare a guest with spice graphic and video->head set to 3:
...
    <video>
      <model type='qxl' ram='65536' vram='16384' vgamem='16384' heads='3' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </video>
    <video>
      <model type='qxl' ram='65536' vram='16384' vgamem='16384' heads='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </video>
...

2. Start guest:
# virsh start rhel7.4

3. Check qemu command line, max_outputs is set correctly:
...
-device qxl-vga,id=video0,ram_size=67108864,vram_size=16777216,vram64_size_mb=0,vgamem_mb=16,max_outputs=3,bus=pci.0,addr=0x7 
-device qxl,id=video1,ram_size=67108864,vram_size=16777216,vram64_size_mb=0,vgamem_mb=16,max_outputs=4,bus=pci.0,addr=0x8
...

I fear we've regressed since libvirt-2.0:

$ rpm -q libvirt-daemon ; cat libvirt_vms/qxl.xml ; virsh domxml-to-native qemu-argv libvirt_vms/qxl.xml 
libvirt-daemon-3.2.0-9.el7.x86_64
<domain type='kvm'>
  <name>qxl</name>
  <memory unit='MiB'>32</memory>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
  </os>
  <devices>
    <graphics type='spice'/>
    <video>
      <model type='qxl' heads='2'/>
    </video>
  </devices>
</domain>
LC_ALL=C PATH=/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/djasa/.local/bin:/home/djasa/bin HOME=/home/djasa USER=djasa LOGNAME=djasa QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name qxl -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off -m 32 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 55e1d942-7512-49b5-8278-7274a861c28e -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/djasa/.config/libvirt/qemu/lib/domain--1-qxl/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -no-acpi -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -spice port=0,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -global qxl-vga.vgamem_mb=16 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -msg timestamp=on

--> no max_outputs=<num> in the qemu CLI (nor it is in some full-blown domain xmls needed to do end-to-end test)

(In reply to David Jaša from comment #22)
I don't have a rhel7 machine handy, but upstream work fine.  What's your qemu version?  Since this is in unit tests, which are, I believe, ran during build, it would fail building in case it wouldn't work.

What is the output of `qemu-system-x86_64 -device qxl,\? 2>&1 | grep max_` on your system?  And without the grep?

(In reply to Martin Kletzander from comment #23)
> (In reply to David Jaša from comment #22)
> I don't have a rhel7 machine handy, but upstream work fine.  What's your
> qemu version?  Since this is in unit tests, which are, I believe, ran during
> build, it would fail building in case it wouldn't work.
> 
> What is the output of `qemu-system-x86_64 -device qxl,\? 2>&1 | grep max_`
> on your system?  And without the grep?

I retested with:
current el7 qemu: qemu-kvm-1.5.3-140.el7.x86_64
current RHV qemu: qemu-kvm-rhev-2.6.0-28.el7_3.10.x86_64
future RHV qemu: qemu-kvm-rhev-2.9.0-9.el7.x86_64

only to-be-released RHV qemu 2.9 advertises the qxl.max_outputs=uint16 knob and with it, libvirt adds the option successfully (see below). So we can go back to VERIFIED and I'm sorry for the noise.


$ rpm -q qemu-kvm{,-rhev} ; /usr/libexec/qemu-kvm -device qxl,\? 2>&1 | grep max_outputs ; virsh domxml-to-native qemu-argv libvirt_vms/qxl.xml 
package qemu-kvm is not installed
qemu-kvm-rhev-2.9.0-9.el7.x86_64
qxl.max_outputs=uint16

LC_ALL=C PATH=/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/home/djasa/.local/bin:/home/djasa/bin HOME=/home/djasa USER=djasa LOGNAME=djasa QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -name guest=qxl,debug-threads=on -object secret,id=masterKey0,format=raw,file=/home/djasa/.config/libvirt/qemu/lib/domain--1-qxl/master-key.aes -machine pc-i440fx-rhel7.4.0,accel=kvm,usb=off,dump-guest-core=off -m 32 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 763338e8-db27-4ead-83d9-173a0342fdce -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/home/djasa/.config/libvirt/qemu/lib/domain--1-qxl/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -no-acpi -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -spice port=0,disable-ticketing,seamless-migration=on -device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=2,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -msg timestamp=on

Sorry for the noise again, I noticed something weird in the outputs for qemu 1.5:

$ rpm -q qemu-kvm{,-rhev} ; /usr/libexec/qemu-kvm -device qxl,\? 2>&1 | grep max_outputs ; virsh domxml-to-native qemu-argv libvirt_vms/qxl.xml 
qemu-kvm-1.5.3-140.el7.x86_64
package qemu-kvm-rhev is not installed
qxl.max_outputs=uint16

^^^   <-- qemu advertises capability

... -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -global qxl-vga.vgamem_mb=16 ...

and no max_outputs are here.

Libvirt also generates old CLI format for qemu 1.5 instead of new one used by Virt QE for qemu test in bug 1283198 comment 31:

...
>         -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.

(In reply to David Jaša from comment #25)
That's because of Bug 981094 and has nothing to do with this one.  If you encounter yet another issue, please ask before moving already verified bug to assigned or create another bug.  Thank you.

OK, you might actually have a point there.  We need to test it with qemu-kvm-rhev as well as qemu-kvm as well since there are different command line arguments used for that.  I'll post a patch in a while.

I can confirm that -global qxl-vga.max_outputs=2 works OK.

Additional tiny fix posted upstream:

https://www.redhat.com/archives/libvir-list/2017-June/msg00606.html

Reproduced with builds:
libvirt-3.2.0-10.el7.x86_64
qemu-kvm-1.5.3-141.el7.x86_64

Verify with builds:
qemu-kvm-1.5.3-141.el7.x86_64
libvirt-3.2.0-15.el7a.x86_64
 
1) single video
config:
    <video>
      <model type='qxl' ram='65536' vram='16384' vgamem='16384' heads='3' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
 
active:
    <video>
      <model type='qxl' ram='65536' vram='16384' vgamem='16384' heads='3' primary='yes'/>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
 
qemu command line:
   -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=16777216 -global qxl-vga.vgamem_mb=16 -global **qxl-vga.max_outputs=3**
                                            
 
2) multiple videos
config:
    <video>
      <model type='qxl' ram='65536' vram='16384' vgamem='16384' heads='3' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <video>
      <model type='qxl' ram='65536' vram='16384' vgamem='16384' heads='3'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </video>
 
 
active:
    <video>
      <model type='qxl' ram='65536' vram='16384' vgamem='16384' heads='3' primary='yes'/>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <video>
      <model type='qxl' ram='65536' vram='16384' vgamem='16384' heads='3'/>
      <alias name='video1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </video>
 
qemu command line:
-vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=16777216 -global qxl-vga.vgamem_mb=16 -global **qxl-vga.max_outputs=3** -device qxl,id=video1,ram_size=67108864,vram_size=16777216,vram64_size_mb=0,vgamem_mb=16,max_outputs=3,bus=pci.0,addr=0x8

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1846

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1846

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1846