Bug 1195176

Patch series posted upstream as RfC:
https://lists.gnu.org/archive/html/qemu-devel/2015-02/msg04342.html

Qemu patches will probably be merged upstream for 2.4,
so more a 7.3 than a 7.2 target, updated flags.

Guest update: submitted driver for review.

Partly (virtio-gpu-device) merged upstream now.

Remaining bits (virtio-gpu-pci, virtio-vga) are expected to be merged for 2.4 too.

Oh, and btw: The guest driver (linux kernel) is in -next and will probably merged in 4.2

> Remaining bits (virtio-gpu-pci, virtio-vga) are expected to be merged for
> 2.4 too.

Landed in qemu master branch now.

sent a rfc series: https://www.redhat.com/archives/libvir-list/2015-November/msg00844.html

Patches pushed upstream:

commit 06198b9c73ff07d70560c4d72f3d73f00e1ef9fa
Author:     Marc-André Lureau <marcandre.lureau>
AuthorDate: Wed Nov 25 09:42:33 2015 +0100
Commit:     Michal Privoznik <mprivozn>
CommitDate: Fri Nov 27 16:48:53 2015 +0100

    qemu: add virtio-gpu virgl support
    
    Check if virtio-gpu provides virgl option, and add qemu command line
    formatter.
    
    It is enabled with the existing accel3d attribute:
    <model type='virtio' heads='1'>
     <acceleration accel3d='yes'/>
    </model>
    
    Signed-off-by: Marc-André Lureau <marcandre.lureau>
    Signed-off-by: Michal Privoznik <mprivozn>

commit 21373feb4eeb1d447ccbc9a10d28f3927f650c09
Author:     Marc-André Lureau <marcandre.lureau>
AuthorDate: Wed Nov 25 09:42:32 2015 +0100
Commit:     Michal Privoznik <mprivozn>
CommitDate: Fri Nov 27 16:48:53 2015 +0100

    qemu: add virtio video device
    
    qemu 2.5 provides virtio video device.  It can be used with -device
    virtio-vga for primary devices, or -device virtio-gpu for non-vga
    devices. However, only the primary device (VGA) is supported with this
    patch.
    
    Reference:
    https://bugzilla.redhat.com/show_bug.cgi?id=1195176
    
    Signed-off-by: Marc-André Lureau <marcandre.lureau>
    Signed-off-by: Michal Privoznik <mprivozn>

commit 806ae4993320804b82a6ec1da5237625cc081ad6
Author:     Marc-André Lureau <marcandre.lureau>
AuthorDate: Wed Nov 25 09:42:31 2015 +0100
Commit:     Michal Privoznik <mprivozn>
CommitDate: Fri Nov 27 16:48:53 2015 +0100

    domain: replace bool accel{2d, 3d} with a tristate
    
    Allowing to have the extra undefined/default state.
    
    Signed-off-by: Marc-André Lureau <marcandre.lureau>
    Signed-off-by: Michal Privoznik <mprivozn>

commit 56a4fe2818beffee0b32e88d61aab39c23a90c24
Author:     Marc-André Lureau <marcandre.lureau>
AuthorDate: Wed Nov 25 09:42:30 2015 +0100
Commit:     Michal Privoznik <mprivozn>
CommitDate: Fri Nov 27 16:48:53 2015 +0100

    Replace support{2d,3d} with accel{2d,3d}
    
    Following the domain XML naming
    
    Signed-off-by: Marc-André Lureau <marcandre.lureau>


v1.2.21-168-g06198b9

Gerd made the following comment in a recent conversation:

"live migration with 3d/virgl is *alot* harder than live migration with
2d only.  live migration with 3d enabled will probably not be supported
for that reason, so user will have to pick between 3d support and live
migration support.

That is one possible reason why users might want turn off 3d support and
why we need a switch for libvirt to enable/disable 3d support in
libvirt."

What's the current status in libvirt? Can I switch live-migration on/off and 3d accell on/off simultaneously, or will 3d imply live-migration=off?

(In reply to Ademar Reis from comment #10)
> Gerd made the following comment in a recent conversation:
> 
> "live migration with 3d/virgl is *alot* harder than live migration with
> 2d only.  live migration with 3d enabled will probably not be supported
> for that reason, so user will have to pick between 3d support and live
> migration support.
> 
> That is one possible reason why users might want turn off 3d support and
> why we need a switch for libvirt to enable/disable 3d support in
> libvirt."
> 
> What's the current status in libvirt? Can I switch live-migration on/off and
> 3d accell on/off simultaneously, or will 3d imply live-migration=off?

There's no API to switch from 2d to 3d at domain runtime. The only possibility is to supply different domain XML on migration where 3d would be disabled. But I see two problems with that: 1) I'm not sure how qemu will cope with that - it's possibly guest ABI breakage. 2) there's no way how to enable 3d once domain is migrated and started on the dst. So I guess it's that of 3d is on, live migration is off. Although since this is a hypervisor implementation limitation I am not sure if libvirt should workaround this somehow.

There is no switch to enable/disable migration in libvirt, although it does check for some unsupported features (like non-USB hostdevs or the invtsc CPU flag) and refuses to migrate if they are present.

I would prefer not including checks for features which are not implemented yet, especially if libvirt can't reliably probe if QEMU supports them or not upfront.

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Is virt-manager support planned?

(In reply to Niccolò Belli from comment #15)
> Is virt-manager support planned?

It should be. But to make sure we will not miss that I'm cloning this bug over to virt-manager.

Verify with build:
libvirt-2.0.0-3.el7.x86_64
qemu-kvm-rhev-2.6.0-14.el7.x86_64

step:
1: define a guest with virtio-gpu
.......
<video>
      <model type='virtio' heads='1' primary='yes'/>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
.......
2: start the guest
check qemu cmd line:
.........
-device virtio-vga,id=video0,bus=pci.0,addr=0x2 -device intel-hda,id=sound0,bus=pci.0,addr=0x4
.......
3: destroy the guest,add another video to guest and start
.....
 <video>
      <model type='qxl' ram='65536' vram='65536' vgamem='16384'/>
      <alias name='video1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </video>
.....
check qemu cmd line:
........
-device virtio-vga,id=video0,bus=pci.0,addr=0x2
-device qxl,id=video1,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,bus=pci.0,addr=0x8

........
4: destroy the guest, edit primary to qxl video and save 
error: unsupported configuration: non-primary video device must be type of 'qxl'

for spice opengl support:
test with xml:
.....
 <graphics type='spice' autoport='yes'>
      <listen type='address'/>
      <gl enable='yes'/>
    </graphics>
.....
    <video>
      <model type='virtio' heads='1' primary='yes'>
        <acceleration accel3d='yes'/>
      </model>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
.....
# virsh start rhel7
error: Failed to start domain rhel7
error: unsupported configuration: This QEMU doesn't support spice OpenGL

per comment 17, move to verified.

If you want spice gl you can't listen to an address, you have to use a socket instead: https://bugzilla.redhat.com/show_bug.cgi?id=1337290

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://rhn.redhat.com/errata/RHSA-2016-2577.html