<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Apr 26, 2017 at 4:37 PM Niels de Vos <<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
We're trying to improve the debugability of Gluster backed VMs and one<br>
of the features for this is to be able to gather "statedumps". These<br>
statedumps include memory allocation details and other information about<br>
the Gluster client. QEMU is one of the applications that can be<br>
configured to use libgfapi.so Gluster client.<br>
<br>
Gluster provides the /var/run/gluster/ directory and the libgfapi.so<br>
library that qemu (in block/gluster.c) uses that. Would there be a<br>
problem for the "qemu" packages to use add the "qemu" user to a<br>
"gluster" group? </blockquote><div><br></div><div>Yes, if we go in this way, we will have to add qemu to the gluster group for</div><div>for debugging gluster: urls, rbd group for rbd: url, etc. This is not maintainable.</div><div><br></div><div>If qemu process writes a statedump running as qemu user, it should keep</div><div>it in the only location in the file system where qemu user can write.</div><div><br></div><div>But I think the right place for this discussion is qemu-devel, not ovirt-devel.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not sure yet how this is done for other packages<br>
with their own users, but there would be a dependent installation order<br>
of some kind (needs rpm triggers?).<br>
<br>
What is your opinion on this issue, or would you recommend an other<br>
approach?<br>
<br>
Thanks,<br>
Niels<br>
<br>
PS: <a href="https://bugzilla.redhat.com/1445569" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/1445569</a> can be used to reply as well<br>
<br>
<br>
>From <a href="http://lists.gluster.org/pipermail/gluster-devel/2017-April/052629.html" rel="noreferrer" target="_blank">http://lists.gluster.org/pipermail/gluster-devel/2017-April/052629.html</a>:<br>
On Tue, Apr 25, 2017 at 07:53:06PM +0200, Niels de Vos wrote:<br>
> Hi,<br>
><br>
> Recently a new ability to trigger statedumps through the Gluster-CLI [0]<br>
> has been added. This makes it possible to get statedump from<br>
> applications that use gfapi. By default, statedumps are saved under<br>
> /var/run/gluster/... and this directory is only writable by root.<br>
> Applications that use gfapi do not require root permissions (like QEMU),<br>
> and therefore fail to write the statedump :-/<br>
><br>
> One approach would be to create a "gluster" group and give the group<br>
> permissions to write to /var/run/gluster/... Other 'fixes' include<br>
> setting ACLs on the directory so that specified users can write there.<br>
> because many daemons have a "home directory" that does not exist, it<br>
> probably is not a good idea to use $HOME to store statedumps.<br>
><br>
> What suggestions do others have?<br>
><br>
> Thanks,<br>
> Niels<br>
><br>
><br>
> 0. <a href="https://github.com/gluster/glusterfs/blob/master/doc/debugging/statedump.md" rel="noreferrer" target="_blank">https://github.com/gluster/glusterfs/blob/master/doc/debugging/statedump.md</a><br>
<br>
<br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a></blockquote></div></div>