Mirek - assigned to you for procedural purposes (at least for now)

Yash - adding you as CC because we may need to think about how this ends up being delivered from a RHEL offering and whether we need to start thinking in terms of how we managed the OpenShift sandboxed containers (Kata) with a different qemu-kvm build which I'm starting to believe is what RHIVOS may end up wanting/needing.  I'm under the impression there is quite a bit of the existing qemu-kvm "package" that they perhaps don't want.

Meirav - adding you as CC to be aware of the RHIVOS request

Hi Sandro,

can you test this build [1] whether package works as required??

[1] https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=52865944

(In reply to Miroslav Rezanina from comment #2)
> Hi Sandro,
> 
> can you test this build [1] whether package works as required??
> 
> [1] https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=52865944

Yes, the team is testing it, I'll let you know the results as soon as I have them.

Notes:
- I think qemu-kvm-ui-dbus should require qemu-kvm no? just installing qemu-kvm-ui-dbus won't allow you to run qemu
- I couldn't install it on el9: nothing provides libnuma.so.1(libnuma_1.6)(64bit) needed by qemu-kvm-core-17:8.0.0-4.el9.next.candidate.x86_64

(In reply to Sandro Bonazzola from comment #4)
> Notes:
> - I think qemu-kvm-ui-dbus should require qemu-kvm no? just installing
> qemu-kvm-ui-dbus won't allow you to run qemu
> - I couldn't install it on el9: nothing provides
> libnuma.so.1(libnuma_1.6)(64bit) needed by
> qemu-kvm-core-17:8.0.0-4.el9.next.candidate.x86_64

Nope, dependency works other way. qemu-kvm package (full qemu-kvm) requires ui-dbus. We use same approach for qemu-kvm modules - they required qemu-kvm-common package. Not remmmember the reason now. 

It is strange numactl was not found and require additional repo. Were RHEL properly configured as I see the package in BaseOS compose.

(In reply to Miroslav Rezanina from comment #6)
> Nope, dependency works other way. qemu-kvm package (full qemu-kvm) requires
> ui-dbus. We use same approach for qemu-kvm modules - they required
> qemu-kvm-common package. Not remmmember the reason now. 
> 
> It is strange numactl was not found and require additional repo. Were RHEL
> properly configured as I see the package in BaseOS compose.

I guess it's because I was testing it on CentOS Stream 9 and numactl 2.0.16 has not been pushed there yet https://kojihub.stream.centos.org/koji/packageinfo?packageID=1370

We are trying to minimize the packages required there to reduce the dependency tree, so I guess we'll go with qemu-kvm-core and qemu-kvm-ui-dbus as top level and then add whatever else will be needed.

with dbus graphical device I got several selinux denials.
I tried writing some pp but it started becoming complicated, managed to run it in permissive mode.
Attaching 'ausearch -m avc' output.
Should I open a separate bug for the selinux denials?

Hi all,

I have been able to test the package on centOS Stream 9.

After installing the packages (qemu-kvm-ui-dbus and numactl-2.0.16) I run qemu+dbus display with:

   $ /usr/libexec/qemu-kvm \
       --hda /var/lib/libvirt/images/centos-stream8.qcow2 \
       -display dbus -device virtio-vga \
       -cpu host -m 4G -smp 2 -enable-kvm \
       --cdrom /var/lib/libvirt/images/CentOS-Stream-8-20230517.0-x86_64-boot.iso

Then we need to attach a frontend to see the screen and interact with it. I've built a container with libmks that can be run as:

   $ podman run -e DISPLAY \
       -v /run/user/1000/:/run/user/1000/ \
       -e XDG_RUNTIME_DIR=/run/user/1000 --ipc host \
       -e DBUS_SESSION_BUS_ADDRESS \
       --mount "type=bind,$(echo "${DBUS_SESSION_BUS_ADDRESS}" | sed -e 's/unix:path=\(.\+\)/src=\1,dst=\1/')" \
       --userns keep-id --security-opt label=disable \
       --privileged --rm -it \
       quay.io/alesgar/libmks

The command line options try to share the dbus session and display from the container environment with the host, but ultimately this works
the same as running libmks locally would. But we avoid dealing with the requirements (e.g., gtk 4.11.2).
Running this command will pop up a new gtkwidget window with the qemu-kvm guest (in my case, centos 8 installation screen).
And I am able to interact with it with my mouse and keyboard.

I can also run `dbus-monitor` to capture the interactions between qemu and mks, e.g. mouse moving:
```
   method call time=1685534632.012617 sender=:1.218 -> destination=:1.214 serial=500 path=/org/qemu/Display1/Console_0; interface=org.qemu.Display1.Mouse; member=SetAbsPosition
      uint32 71
      uint32 422
```

Thus, everything works as expected.

@mrezanin can you please review https://gitlab.com/CentOS/automotive/rpms/qemu/-/merge_requests/1 ?
I'm trying to make a build with dbus display enabled but I have some troubles there.

Tested 20230628 rebase from https://copr.fedorainfracloud.org/coprs/g/centos-automotive-sig/dui/builds/

on a clean CentOS Stream 9 system as root user and worked flawlessly without any selinux denial.
selinux-policy-targeted-38.1.15-1.el9.noarch

# cat run-script.sh 
#!/usr/bin/bash

/usr/libexec/qemu-kvm \
       --hda /var/lib/libvirt/images/centos.qcow2 \
       -display dbus -device virtio-vga \
       -cpu host -m 4G -smp 2 -enable-kvm \
       --cdrom /var/lib/libvirt/images/CentOS-Stream-9-latest-x86_64-boot.iso

# cat view.sh 
podman run -e DISPLAY \
       -v /run/user/0/:/run/user/0/ \
       -e XDG_RUNTIME_DIR=/run/user/0 --ipc host \
       -e DBUS_SESSION_BUS_ADDRESS \
       --mount "type=bind,$(echo "${DBUS_SESSION_BUS_ADDRESS}" | sed -e 's/unix:path=\(.\+\)/src=\1,dst=\1/')" \
       --security-opt label=disable \
       --privileged --rm -it \
       quay.io/alesgar/libmks

QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass.

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 (Moderate: qemu-kvm security, bug fix, and enhancement update), 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/RHSA-2023:6368