Mouse integration not working

Hi Kev,
there is a bunch of issues in relation to Wayland on either the host, the guest or both.
In most cases like this it is "just" that.
The uploads I plan to virt-manager and more of the virt stack should cover this.
Once ready we should evaluate your case, but until then I have to ask for your pardon to wait.

I'll tag this bug so I ping once the update is avail, but this is a cahin of dependencies and virt-manager is rather at the end of the chain.

@paelzer

Hi Christian - using this on Xubuntu, host and guest(s) - no wayland ;)

FTR - had the same during the artful cycle.

Thanks for looking.

On Mon, Jan 8, 2018 at 6:50 PM, Kev Bowring <email address hidden> wrote:
> @paelzer
>
> Hi Christian - using this on Xubuntu, host and guest(s) - no wayland ;)
>
> FTR - had the same during the artful cycle.

Interesting, but also killing parts of my hope/theory :-/
I tried a bit around (I'm not the most UI focussed guy to admit) but
could not reproduce (for me integration worked in the cases I tried).

So for now I unfortunately will keep it open and lacking other actions
to take right now will ask you to retry once I have the new qemu in
(that at least is some plan).

If you have more details that might help tracking the source of the
issue let me know.

What is the guest release you are running btw?

@paelzer -

I get no mouse integration with any of the current *buntu guests - and bionic of course.

If there are some sort of logs (either host or guest) which I could supply that would help - just ask and I'll do so asap.

Hi Kev,
there are major changes everywhere in 18.04 still.
Do you think you have a chance to test your 18.04 with everything updated to the latest plus the following ppa?

https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3108

@paelzer - absolutely can ;)

But ...

Error connecting to graphical console:
internal error: unable to execute QEMU command 'getfd': No file descriptor supplied via SCM_RIGHTS

Possibly to do with my change to /etc/libvirt/qemu.conf

Upgrading asked me whether to change this file to default - I said no ...

I have this

user="wolf"

in that file under the # The user for QEMU processes run by the system instance. section so that iso's it uses aren't consequently owned by root - which I do not want to happen.

Thanks for your fast response, you are in my top league of bug reporters!

I'd not assume it is qemu.conf.

But I have seen a similar issue in the past.
This should be fixed since bug 1668681.
Sanity check ... yes the latest package did not by accident drop it.
Your file: /etc/apparmor.d/abstractions/libvirt-qemu
Should contain:
  # allow connect with openGraphicsFD to work
  unix (send, receive) type=stream addr=none peer=(label=/usr/sbin/libvirtd),
If not, that is your missing rule to get that working again.

If the above was not the reasons - when you trigger that bug of "Error connecting to graphical console" could you check if demesg reports any apparmor Denies at that time?
Maybe we need something new for your kind of setup.

Seeing the apparmor deny (if any) could be quickly integrated once I see it. So I'm looking forward to your next reply.

Grumpy Note: I need a second desktop to better test such things :-/ It works in 16.04 + LXD with Bionic's Virtualization Stack.

@ paelzer

ok - apparmor file did in fact contain the line you quote.

I re-added the ppa and upgraded, following the upgrade dmesg had this:

[ 2764.569019] audit: type=1400 audit(1516979522.226:28): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="virt-aa-helper" pid=7658 comm="apparmor_parser"
[ 2764.630541] audit: type=1400 audit(1516979522.287:29): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/libvirtd" pid=7662 comm="apparmor_parser"
[ 2764.654446] audit: type=1400 audit(1516979522.311:30): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/libvirtd//qemu_bridge_helper" pid=7662 comm="apparmor_parser"

I then ran virt-manager, got the error and then dmesg added this:

[ 2797.579995] audit: type=1400 audit(1516979555.237:31): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libvirt-50fea9df-e318-490a-aca6-725c8bcb75e3" pid=8298 comm="apparmor_parser"
[ 2797.706189] audit: type=1400 audit(1516979555.363:32): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-50fea9df-e318-490a-aca6-725c8bcb75e3" pid=8301 comm="apparmor_parser"
[ 2797.826802] audit: type=1400 audit(1516979555.484:33): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-50fea9df-e318-490a-aca6-725c8bcb75e3" pid=8304 comm="apparmor_parser"
[ 2797.947926] audit: type=1400 audit(1516979555.605:34): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="libvirt-50fea9df-e318-490a-aca6-725c8bcb75e3" pid=8307 comm="apparmor_parser"
[ 2797.952235] virbr0: port 2(vnet0) entered blocking state
[ 2797.952237] virbr0: port 2(vnet0) entered disabled state
[ 2797.952270] device vnet0 entered promiscuous mode
[ 2797.952395] virbr0: port 2(vnet0) entered blocking state
[ 2797.952396] virbr0: port 2(vnet0) entered listening state
[ 2798.074354] audit: type=1400 audit(1516979555.732:35): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libvirt-50fea9df-e318-490a-aca6-725c8bcb75e3" pid=8315 comm="apparmor_parser"
[ 2798.178971] audit: type=1400 audit(1516979555.836:36): apparmor="DENIED" operation="file_receive" profile="/usr/sbin/libvirtd" pid=8341 comm="qemu-system-x86" family="unix" sock_type="stream" protocol=0 requested_mask="send receive" denied_mask="send receive" addr=none peer_addr=none peer="libvirt-50fea9df-e318-490a-aca6-725c8bcb75e3"
[ 2798.218621] audit: type=1400 audit(1516979555.876:37): apparmor="DENIED" operation="file_receive" profile="/usr/sbin/libvirtd" pid=8341 comm="qemu-system-x86" family="unix" sock_type="stream" protocol=0 requested_mask="send receive" denied_mask="send receive" addr=none peer_addr=none peer="libvirt-50fea9df-e318-490a-aca6-725c8bcb75e3"
[ 2799.981577] virbr0: port 2(vnet0) entered learning state

A couple of denied there.

Hope that helps ;) (re "... you are in my top league of bug reporters!" - that's the social contract we all should follow - I'll report bugs and hope someone who knows what's there can look - I'll always do my level best to give people what they need in a report :)

Thank,
so that comes down to
operation="file_receive" profile="/usr/sbin/libvirtd" pid=8341 comm="qemu-system-x86" family="unix" sock_type="stream" requested_mask="send receive" denied_mask="send receive" addr=none peer_addr=none peer="libvirt-50fea9df-e318-490a-aca6-725c8bcb75e3"

operation="file_receive" profile="/usr/sbin/libvirtd" pid=8341 comm="qemu-system-x86" family="unix" sock_type="stream" protocol=0 requested_mask="send receive" denied_mask="send receive" addr=none peer_addr=none peer="libvirt-50fea9df-e318-490a-aca6-725c8bcb75e3"

We have:
apparmor/libvirt-qemu
unix (send, receive) type=stream addr=none peer=(label=/usr/sbin/libvirtd),

That seems to be vice versa to the new virtualization stacks DENIED message.
So instead of the old where qemu contacted libvirt, this is libvirt contacting qemu (maybe due to an upstream change).

I tried to reproduce your case, but it doesn't trigger for me (yet - i'm going on to try differently).

Could you add the following line:
  unix (send, receive) type=stream addr=none peer=(label=libvirt-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*),
to the file:
  /etc/apparmor.d/local/usr.sbin.libvirtd

Then restart libvirtd (systemctl restart libvirtd) and then try again?
That should allow the connection in said direction.

If the above is not working we could fall back to a simpler pattern like:
  unix (send, receive) type=stream addr=none peer=(label=libvirt-*),

Note: about the original issue of the integration, there are many things around wayland still.
I heard that the Desktop Team will switch back to X11 for stability in 18.04 - didn't happen yet but should be on the way and resolve many similar issues.

On the apparmor Deny we found while testing as I mentioned I tried different setups.
Any \o/ I can now it seems:
[618537.428380] audit: type=1400 audit(1517220862.040:2924): apparmor="DENIED" operation="file_receive" namespace="root//lxd-bionic-test_<var-snap-lxd-common-lxd>" profile="/usr/sbin/libvirtd" pid=21372 comm="qemu-system-x86" family="unix" sock_type="stream" protocol=0 requested_mask="send receive" denied_mask="send receive" addr=none peer_addr=none peer="libvirt-fa4e8f6b-0211-4fb6-9e7e-93fe66133ced"

This is a crazy 16.04 - lxd-container 18.04 cloud image - 18.04 Desktop guest
                                   ^ ssh + virt-manager here
So results may vary, but that should be enough to iterate on the rule to suggest just "one" to you.
back in a bit ...

Ok, the following is what you can add to your local override until in the next version of libvirt:
Add to "/etc/apparmor.d/local/usr.sbin.libvirtd"

unix (send, receive) type=stream addr=none peer=(label=libvirt-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*),
# required if guests run without security module
unix (send, receive) type=stream addr=none peer=(label=unconfined),

Afterwards run
$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.libvirtd

Then the display of the guest in virt-manager should work again.
I'll tag this bug along the fix on the next upload.

For the original issue of the mouse integration (not to be forgotten).
I'd be pleased to hear if that now works for you (it does for me on my crazy setup btw).
But if not (yet) I'd really say we need to wait until 18.04 is back on X11.
You can in advance change that like in [1] - probably worth for your test.

[1]: https://itsfoss.com/switch-xorg-wayland/

libvirt_4.0.0-1ubuntu1~ppa5 is building in the ppa and once available (~1h) will have the fix included.

Did all those things - before my cuppa ...

vm's now boot so the apparmor thing appears to have done the trick there - thanks very much :)

Re The Original Issue ...

Just to be sure we're both on the same page re mouse integration - currently I'm having to Ctrl+AltL to release mouse to host, VBox works fine here (have it installed for when qemu/virt-manager falls over locally)

I still have that.

You though appear to have forgotten that I'm running Xubuntu - Xfce, and thus us, don't use Wayland, I'm still using Xorg so have no need to switch things here.

I do have the following things waylandish installed (assuming qt5 dev and vlc reasons):

ii libqt5waylandclient5:amd64 5.9.3-0ubuntu1 amd64 QtWayland client library
ii libqt5waylandcompositor5:amd64 5.9.3-0ubuntu1 amd64 QtWayland compositor library
ii libwayland-bin 1.14.0-1 amd64 wayland compositor infrastructure - binary utilities
ii libwayland-client0:amd64 1.14.0-1 amd64 wayland compositor infrastructure - client library
ii libwayland-cursor0:amd64 1.14.0-1 amd64 wayland compositor infrastructure - cursor library
ii libwayland-dev:amd64 1.14.0-1 amd64 wayland compositor infrastructure - development files
ii libwayland-egl1-mesa:amd64 17.2.4-0ubuntu2 amd64 implementation of the Wayland EGL platform -- runtime
ii libwayland-server0:amd64 1.14.0-1 amd64 wayland compositor infrastructure - server library
ii qtwayland5:amd64 5.9.3-0ubuntu1 amd64 QtWayland platform plugin
ii wayland-protocols 1.11-1 all wayland compositor protocols

> Just to be sure we're both on the same page re mouse integration -
> currently I'm having to Ctrl+AltL to release mouse to host, VBox works
> fine here (have it installed for when qemu/virt-manager falls over
> locally)

Hmm - for Ubuntu guests on Ubuntu host with the stack from Bionic +
the ppa I have seamless mouse integration.
So no keycode to enter/leave focus, but seamless mouse in/out.

> You though appear to have forgotten that I'm running Xubuntu - Xfce, and
> thus us, don't use Wayland, I'm still using Xorg so have no need to
> switch things here.

Yes I have forgotten, I beg your pardon :-/
Just too many other similar things depend on that, so that I'm tending
to shortcut there.

Just to be sure, I assume your xml is as virt-manager usually defines
it, but could you share the output of
$ virsh dumpxml <guestname>
So that we can check the graphics backend that it has registered for you?

Here it is:

(assuming you're just after the graphics which is (I was sure qxl):

virsh dumpxml xub_64 |grep qxl
      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/>

If not - here is the whole thing:

virsh dumpxml xub_64
<domain type='kvm'>
  <name>xub_64</name>
  <uuid>50fea9df-e318-490a-aca6-725c8bcb75e3</uuid>
  <memory unit='KiB'>393216</memory>
  <currentMemory unit='KiB'>393216</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc-i440fx-artful'>hvm</type>
    <bootmenu enable='yes'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state='off'/>
  </features>
  <cpu mode='custom' match='exact' check='partial'>
    <model fallback='allow'>Haswell-noTSX</model>
  </cpu>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/kvm-spice</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/mnt/Data/Virtual Machines - KVM/xub_64.qcow2'/>
      <target dev='hda' bus='ide'/>
      <boot order='2'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/mnt/Data/iso/Xubuntu/18.04/bionic-desktop-amd64.iso'/>
      <target dev='hdb' bus='ide'/>
      <readonly/>
      <boot order='1'/>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:8c:b3:41'/>
      <source network='default'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
  ...

Yes I was after the video part, but as I assumed we both have the same default.
Hmm, I'm soon out of ideas :-/ (maybe trying with the different video devices, no not really)

OTOH the next thing I wanted to check were input devices - and there is a difference that might be related.

I have this in addition to your setup (added by virt-manager by default):
  <input type='tablet' bus='usb'>
    <address type='usb' bus='0' port='1'/>
  </input>

In virt manager that appears as:
Virtual Input Devive
Type: EvTouch USB Graphics Tablet
Mode: Absolute Movement

Should be something like: virtual machine details > Add Hardware > Input > EvTouch USB Graphics Tablet to get one.

I remember that this absolute positioning tablet device was a requirement for the seamless integration - I think it is worth a try to add that on your side.

As usual - now that I know what I look for - I found [1] which pretty much points to the same direction.

[1]: https://serverfault.com/questions/457603/any-way-to-release-focus-on-a-kvm-guest-in-virt-manager-without-having-to-click

On 30/01/18 06:55, ChristianEhrhardt wrote:
> Yes I was after the video part, but as I assumed we both have the same default.
> Hmm, I'm soon out of ideas :-/ (maybe trying with the different video devices, no not really)
>
>
> OTOH the next thing I wanted to check were input devices - and there is a difference that might be related.
>
> I have this in addition to your setup (added by virt-manager by default):
> <input type='tablet' bus='usb'>
> <address type='usb' bus='0' port='1'/>
> </input>
>
> In virt manager that appears as:
> Virtual Input Devive
> Type: EvTouch USB Graphics Tablet
> Mode: Absolute Movement
>
> Should be something like: virtual machine details > Add Hardware > Input
>> EvTouch USB Graphics Tablet to get one.
> I remember that this absolute positioning tablet device was a
> requirement for the seamless integration - I think it is worth a try to
> add that on your side.
>
> As usual - now that I know what I look for - I found [1] which pretty
> much points to the same direction.
>
> [1]: https://serverfault.com/questions/457603/any-way-to-release-focus-
> on-a-kvm-guest-in-virt-manager-without-having-to-click
>
Just prior to reporting this bug - I had been scouting about, and found
that page and indeed many others all saying the same thing - add tablet.
So I tried and still came up short.

Since then I've added your ppa - just added the tablet this time and
success - mouse integration.

Assuming that what's in the ppa lands in repos - then thank you very much :)

Changes are already in proposed, so soon to be fully fix released.

Reported issue solved, and the apparmor update we found is now released as well.