Sorry for replying late, I was on vacation since 24Jan.
On 2014?01?24? 11:29, Aline Manera wrote:
On 01/22/2014 11:43 AM, Royce Lv wrote:
>
>
> Guys,
>
> When testing with kimchi nfs feature, I filed two issues related to
> nfs image permission problem:
>
> 1. volume creation failure: Because of storage pool permission is
> not configured to make write
>
permission.(https://github.com/kimchi-project/kimchi/issues/261)
> 2. vm with volume cannot be started: Root users are mapped to
> nobody, so img it created cannot be accessed by libvirt-qemu(on ubuntu)
>
user.(https://github.com/kimchi-project/kimchi/issues/267)
>
> After discussed with Mark Wu, we would like to propose the
> following to resolve these two problem:
>
> 1. To allow creation: export with all_squash(gid = kimchi_guid) and
> group allow write permission. Also with planned nfs-pool prevalidation
> (a timeout try mount in a process), we can check if the gid and
> permission is right. This will save us from future trouble.
>
It is only related to NFS server setup, right?
/home/alinefm *(rw,all_squash,anongid=<kimchi-gid>)
So for that we should only write instructions to user on README or
other doc file.
True
> 2. To allow qemu process(started by libvirt) to access img, we add
> uid ('qemu' under fedora and 'libvirt-qemu' under ubuntu) which
running
> qemu process to 'kimchi' group to allow the write access of the img.
>
For that we need to create a group with the same kimchi gid used for
NFS server
and then add 'qemu/libvirt-qemu' to this group?
Is that right?
Right, and we validate when mount a nfs pool to check if the
permission
is right.
> I am also investigating other possibilities like using storage pool
> permissions and so on.
> Welcome thoughts on it!
>