Hi Bertrand and thanks for joining in,
with your report that the isolated "network unix dgram," rule helps is great to
confirm the "how to fix".
But as outlined before - since this doesn't reproduce for everyone - we'd need
to find what the subset of people that hit this do to trigger it. Only then we
can really add the rule.
I was (once more) trying to trigger this, but still it just doesn't happen.
# clean new Focal system after install from a cloudimg
$ sudo apt install libvirt-clients libvirt-daemon-system
$ virsh list --all
# works, no denial
I compared the strace that tommy provided in comment #6 with one on this clean
system:
Tommy:
socket(AF_UNIX, SOCK_STREAM, 0) = 6
connect(6, {sa_family=AF_UNIX, sun_path="/var/run/libvirt/libvirt-sock"}, 110)
= 0
getsockname(6, {sa_family=AF_UNIX}, [128->2]) = 0
write(6, "\0\0\0\34 \0\200\206\0\0\0\1\0\0\0B\0\0\0\0\0\0\0\0\0\0\0\0", 28) = 28
poll([{fd=6, events=POLLIN}, {fd=7, events=POLLIN}], 2, -1) = 1 ([{fd=6,
revents=POLLIN|POLLHUP}])
read(6, "", 4) = 0
Comparison:
socket(AF_UNIX, SOCK_STREAM, 0) = 5
connect(5, {sa_family=AF_UNIX, sun_path="/var/run/libvirt/libvirt-sock"}, 110)
= 0
getsockname(5, {sa_family=AF_UNIX}, [128->2]) = 0
write(5, "\0\0\0\34 \0\200\206\0\0\0\1\0\0\0B\0\0\0\0\0\0\0\0\0\0\0\0", 28) = 28
poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}], 2, -1) = 1 ([{fd=5,
revents=POLLIN}])
read(5, "\0\0\0$", 4) = 4
Here the "good case" got something back from the socket, and the "bad one"
didn't.
The denial is on libvirt daemons side, so virsh (or virt-manager) tried to talk
to it, but communication was blocked it seems. The strace is on the client and
only sees that the receiving end doesn't get anything. From there the "bad
case" is on an exit path (but that is virsh code and not libvirtd where the
denial happened).
None of this yet explains why it happens to some users, but not others.
I also tried a B->F upgrade as some reported to see it then to no repro-luck :-/
All that still is just dancing around the symptom, as I outlined in comment #9
and #10 we'd need to have status of the services/sockets as well as a strace of
the daemon (not the client) in the bad case to get towards some next steps.
In addition anything from your config might help, e.g. a tarball of
/etc/libvirt/ maybe that will allow me to trigger and debug it. If you
(or others) need help what exactly to debug, which commands to use
please get in touch here and I can help.
For the sake of recognizing a pattern - are all of the affected seeing
this on a 18.04->20.04 upgrade or are new installs affected as well?
Also are all affected systems Desktop installs or are there Server
/Cloud-images as well?
@Bertrand - Tommy didn't yet get to answer to these questions. I think you can
now switch back to the bad state by removing that apparmor line that you added
and restarting libvirtd.
If that is true could you help to answer these questions?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890858
Title:
AppArmor profile causes QEMU/KVM - Not Connected
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1890858/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
