[Bug 1144527] Virtualization/libvirt: Bug Call to virDomainCreateWithFlags failed: internal error: Process exited prior to exec: libvirt: error : Failed to bind /dev/null on to /var/run/libvirt/qemu/496-tests_testing-15.0-a.dev/null: Permission denied
https://bugzilla.suse.com/show_bug.cgi?id=1144527 https://bugzilla.suse.com/show_bug.cgi?id=1144527#c10 James Fehlig <jfehlig@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(dcermak@suse.com) --- Comment #10 from James Fehlig <jfehlig@suse.com> --- (In reply to Dan ��erm��k from comment #9)
Should we forward this to the libvirt and/or apparmor maintainers?
IMO we need a better understanding of the problem first. In the original description you said you "frequently" encounter the problem, so I assume it does work on occasion?
I have the suspicion that once one user creates a domain, any other user (including root) can no longer create them
Can you verify this suspicion? :-)
Call to virDomainCreateWithFlags failed: internal error: Process exited prior to exec: libvirt: error : Failed to bind /dev/null on to /var/run/libvirt/qemu/496-tests_testing-15.0-a.dev/null: Permission denied
This error, along with your DENIED messages from audit.log, indicate building the VM's namespace failed. /dev/null on the host could not be bind mounted to the VM's private namespace. However a lot has changed in libvirt since 6.0.0, including moving the namespace creation from the qemu process to the libvirtd process https://gitlab.com/libvirt/libvirt/-/commit/8da362fe62766b4eee209cd3ce591ceb... https://gitlab.com/libvirt/libvirt/-/commit/9048dc4e627ddf33996084167bece7b5... The first commit describes the rational, the second one uses it for basic /dev nodes. There are several subsequent commits doing the same for disks, hostdevs, chardevs, etc. Bottom line is the patch I suggested in #8 is not needed with libvirt >= 6.7.0 since mounting is done within the libvirtd process. Is it possible for you to verify the issue does not exist on TW, or SLES15 SP3 betas if that is easier? -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com