I don't know what you mean by "proxy filesystem."
I tried to change it so kvm runs as root, but the libvirt daemon seems to fail
as soon as virt-manager tries to contact it. I don't see anything even written
to the system logs at that time, and my .xsession-errors has only the usual
noise (this is running as a regular user that is in the libvirt group):
<.xsession-errors>
/usr/share/virt-manager/virt-manager.py:306: DeprecationWarning: Importing
dbus.glib to use the GLib main loop with dbus-python is deprecated.
Instead, use this sequence:
from dbus.mainloop.glib import DBusGMainLoop
DBusGMainLoop(set_as_default=True)
import dbus.glib
</.xsession-errors>
More details:
Edited /etc/libvirt/qemu.conf so that clear_emulator_capabilities = 0. I
thought this might cause kvm to run as root (it didn't) and hoped that it would
help with bridged networking problems (it seemed to). I shutdown all the VMs
and restarted libvirt to test.
Added
user=root
group=root
to qemu.conf and /etc/init.d/libvirt-bin
When I started virt-manager it said it could not contact libvirt
<error>
Unable to connect to libvirt.
Cannot recv data: Connection reset by peer
Libvirt URI is: qemu:///system
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/connection.py", line 1185, in
_open_thread
self.vmm = self._try_open()
File "/usr/share/virt-manager/virtManager/connection.py", line 1167, in
_try_open
flags)
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 102, in openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: Cannot recv data: Connection reset by peer
</error>
And /etc/init.d/libvirt-bin status says "libvirtd not running failed!". The
same status request run immediately before the virt-manager launch show
libvirtd is running.
I repeated this exercise several times, always with the same result.
Finally, a couple comments on my original report. I thought that kvm was
running as root because libvirtd was; instead it's libvirt-qemu as you said.
This makes some of the permission problems I was having more understandable.
P.S. I tried running virt-manager from root, and got the same failure.
________________________________________
From: Guido Günther [a...@sigxcpu.org]
Sent: Tuesday, March 31, 2015 1:25 AM
To: Boylan, Ross
Cc: 781...@bugs.debian.org; rossboy...@stanfordalumni.org
Subject: Re: [Pkg-libvirt-maintainers] Bug#781283: libvirt-bin: Permission
denied with 9p file system
On Fri, Mar 27, 2015 at 04:49:43PM +0000, Boylan, Ross wrote:
> Thanks for the fast response.
>
> The UID's match on host and guest. Notice that the problems with directory
> listing occurred as root (UID 0). The copy problem was as ross. Most of the
> files are owned by ross (UID 1000).
>
> Eventually, I'll want to operate from the guest with a UID not present on
> the host, although I could add it to the host if necessary.
>
> Although it's possible this is a KVM issue, a significant number of similar
> problems reported on the net were the result of libvirt, usually the security
> framework (selinux or apparmor--are either relevant for Debian?), but
> sometimes also the exact mode choices. The fact that I can't access host
> files as root from the guest, with libvirt daemon running as root (I think)
> on the host suggests something is getting in the way. The apparent logic is
> "group and other have no access rights to the file; file's owner UID = 1000;
> accessing process UID=0; no acesss."
Using accessmode=mapped works fine if the directory/files are writeable
by the user running libvirt (libvirt-qemu by default). For passthrough
run kvm/qemu as root.
Proxy filesystem is currently not supported by libvirt.
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
