qemu packaging - add the "qemu" user to a "gluster" group?
--ofZMSlrAVk9bLeVm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, We're trying to improve the debugability of Gluster backed VMs and one of the features for this is to be able to gather "statedumps". These statedumps include memory allocation details and other information about the Gluster client. QEMU is one of the applications that can be configured to use libgfapi.so Gluster client. Gluster provides the /var/run/gluster/ directory and the libgfapi.so library that qemu (in block/gluster.c) uses that. Would there be a problem for the "qemu" packages to use add the "qemu" user to a "gluster" group? I'm not sure yet how this is done for other packages with their own users, but there would be a dependent installation order of some kind (needs rpm triggers?). What is your opinion on this issue, or would you recommend an other approach? Thanks, Niels PS: https://bugzilla.redhat.com/1445569 can be used to reply as well =46rom http://lists.gluster.org/pipermail/gluster-devel/2017-April/052629.h= tml: On Tue, Apr 25, 2017 at 07:53:06PM +0200, Niels de Vos wrote:
Hi, =20 Recently a new ability to trigger statedumps through the Gluster-CLI [0] has been added. This makes it possible to get statedump from applications that use gfapi. By default, statedumps are saved under /var/run/gluster/... and this directory is only writable by root. Applications that use gfapi do not require root permissions (like QEMU), and therefore fail to write the statedump :-/ =20 One approach would be to create a "gluster" group and give the group permissions to write to /var/run/gluster/... Other 'fixes' include setting ACLs on the directory so that specified users can write there. because many daemons have a "home directory" that does not exist, it probably is not a good idea to use $HOME to store statedumps. =20 What suggestions do others have? =20 Thanks, Niels =20 =20 0. https://github.com/gluster/glusterfs/blob/master/doc/debugging/statedu= mp.md
--ofZMSlrAVk9bLeVm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJZAKJrAAoJECXo5AApwsWzvQgP/RQqbBW/rZ6K6/bJsOr4cY16 j8Ts9hubHpPQeGsM5auL7x58f/Yk1v8DZGLMpgihriKA7wrWygeEjGZiYUqw5sKH oW6wYbMvEjwSZJF7/MN6jq0U9wPY8waOpxNpvdM3mvNvy8EGzT4Yo/SqXmkwcLQM Q9v22rOffd9LiuvZmr6N7ftE6xwkbe24P0wD9Rsw9E99R33hr8oCAjdNtVo3jgKa 7ZKMwr5AwQPCVmEkY8sa7AKJi7KLB7oitawGsIvlfwyjQRZO0EMvrDxwxnSLwIlg 6X6SjP7XyBNixM35KKDvBoxgBoE7xmh9kniXkqvEmZRPMG3te7/yPoVh55f4UuDK gtHXgb+xnQ09Z5eJ5+x23mG26jxXCE/18bOPPUpA4APmyfypPO2JpYO6RABrKmrK IMurqEnuwpY/rBD4UXUnQiLJtB3tBx8kGtc3Hb8VXLCvJhpnzWQNgRGXsuSLcbTs W29ZWFr97C5VJcMdMsZJ0haGB7bNyrSOcF6xcUtc8Eg6ELz++c6y2t7IlyKaniVW PAtuZ3ZlaUt8pw6aLJ4UgaE9kfKUgeEMPFgQIQe8UkTNp3H6N+A9P3QGe9fvl16c LkjXd5wTZuIDxCEKn/iRSx7oJaVoRsd9BmQB61a7XRPSOJI8yyf4JfMN0kL36UUy c/y5huVBKyY4sTNzYpu2 =mYzO -----END PGP SIGNATURE----- --ofZMSlrAVk9bLeVm--
On Wed, Apr 26, 2017 at 3:36 PM, Niels de Vos <ndevos@redhat.com> wrote:
Hi,
We're trying to improve the debugability of Gluster backed VMs and one of the features for this is to be able to gather "statedumps". These statedumps include memory allocation details and other information about the Gluster client. QEMU is one of the applications that can be configured to use libgfapi.so Gluster client.
Gluster provides the /var/run/gluster/ directory and the libgfapi.so library that qemu (in block/gluster.c) uses that. Would there be a problem for the "qemu" packages to use add the "qemu" user to a "gluster" group? I'm not sure yet how this is done for other packages with their own users, but there would be a dependent installation order of some kind (needs rpm triggers?).
What is your opinion on this issue, or would you recommend an other approach?
Adding Miroslav, Karen and Doron. I'm not sure about how libgfapi is consumed by qemu-kvm(-ev/-rhev) but if its support is enable by default and doesn't require additional qemu-kvm sub packages to be enabled, I would suggest to just follow https://fedoraproject.org/wiki/Packaging:UsersAndGroups and add the qemu user to the gluster group in %pre.
From oVirt point of view, I think it shouldn't affect us very much. On CentOS Virt SIG we'll consume whatever will come from qemu-kvm-rhev.
Thanks, Niels
PS: https://bugzilla.redhat.com/1445569 can be used to reply as well
From http://lists.gluster.org/pipermail/gluster-devel/2017- April/052629.html: On Tue, Apr 25, 2017 at 07:53:06PM +0200, Niels de Vos wrote:
Hi,
Recently a new ability to trigger statedumps through the Gluster-CLI [0] has been added. This makes it possible to get statedump from applications that use gfapi. By default, statedumps are saved under /var/run/gluster/... and this directory is only writable by root. Applications that use gfapi do not require root permissions (like QEMU), and therefore fail to write the statedump :-/
One approach would be to create a "gluster" group and give the group permissions to write to /var/run/gluster/... Other 'fixes' include setting ACLs on the directory so that specified users can write there. because many daemons have a "home directory" that does not exist, it probably is not a good idea to use $HOME to store statedumps.
What suggestions do others have?
Thanks, Niels
0. https://github.com/gluster/glusterfs/blob/master/doc/ debugging/statedump.md
-- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
On Wed, Apr 26, 2017 at 4:37 PM Niels de Vos <ndevos@redhat.com> wrote:
Hi,
We're trying to improve the debugability of Gluster backed VMs and one of the features for this is to be able to gather "statedumps". These statedumps include memory allocation details and other information about the Gluster client. QEMU is one of the applications that can be configured to use libgfapi.so Gluster client.
Gluster provides the /var/run/gluster/ directory and the libgfapi.so library that qemu (in block/gluster.c) uses that. Would there be a problem for the "qemu" packages to use add the "qemu" user to a "gluster" group?
Yes, if we go in this way, we will have to add qemu to the gluster group for for debugging gluster: urls, rbd group for rbd: url, etc. This is not maintainable. If qemu process writes a statedump running as qemu user, it should keep it in the only location in the file system where qemu user can write. But I think the right place for this discussion is qemu-devel, not ovirt-devel.
I'm not sure yet how this is done for other packages with their own users, but there would be a dependent installation order of some kind (needs rpm triggers?).
What is your opinion on this issue, or would you recommend an other approach?
Thanks, Niels
PS: https://bugzilla.redhat.com/1445569 can be used to reply as well
From http://lists.gluster.org/pipermail/gluster-devel/2017-April/052629.html: On Tue, Apr 25, 2017 at 07:53:06PM +0200, Niels de Vos wrote:
Hi,
Recently a new ability to trigger statedumps through the Gluster-CLI [0] has been added. This makes it possible to get statedump from applications that use gfapi. By default, statedumps are saved under /var/run/gluster/... and this directory is only writable by root. Applications that use gfapi do not require root permissions (like QEMU), and therefore fail to write the statedump :-/
One approach would be to create a "gluster" group and give the group permissions to write to /var/run/gluster/... Other 'fixes' include setting ACLs on the directory so that specified users can write there. because many daemons have a "home directory" that does not exist, it probably is not a good idea to use $HOME to store statedumps.
What suggestions do others have?
Thanks, Niels
0. https://github.com/gluster/glusterfs/blob/master/doc/debugging/statedump.md
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
--r7tUYVWcdYzDJoZW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 28, 2017 at 11:42:24AM +0000, Nir Soffer wrote:
Hi,
We're trying to improve the debugability of Gluster backed VMs and one of the features for this is to be able to gather "statedumps". These statedumps include memory allocation details and other information about the Gluster client. QEMU is one of the applications that can be configured to use libgfapi.so Gluster client.
Gluster provides the /var/run/gluster/ directory and the libgfapi.so library that qemu (in block/gluster.c) uses that. Would there be a problem for the "qemu" packages to use add the "qemu" user to a "gluster" group? =20 =20 Yes, if we go in this way, we will have to add qemu to the gluster group = for for debugging gluster: urls, rbd group for rbd: url, etc. This is not
On Wed, Apr 26, 2017 at 4:37 PM Niels de Vos <ndevos@redhat.com> wrote: =20 maintainable.
Indeed, this is one of the issues that I see as well. It would also introduce an installation order dependency, or different packages would need to add/update different users. This seems tricky to get right. - qemu package creates the "qemu" user - glusterfs package creates the "gluster" group - which package should add the "qemu" user to the "gluster" group? - what about updating existing installations - ...
If qemu process writes a statedump running as qemu user, it should keep it in the only location in the file system where qemu user can write.
This is an option we could add. It will require an configuration option through a (to be added) libgfapi.so function, and QEMU will need to be updated to use it. Those are not real problems, but it will not help current users. I also thought about using getcwd() as fallback location, but libvirt seems to run QEMU with / as working directory.
But I think the right place for this discussion is qemu-devel, not ovirt-devel.
=20
I'm not sure yet how this is done for other packages with their own users, but there would be a dependent installation order of some kind (needs rpm triggers?).
What is your opinion on this issue, or would you recommend an other approach?
Thanks, Niels
PS: https://bugzilla.redhat.com/1445569 can be used to reply as well
From http://lists.gluster.org/pipermail/gluster-devel/2017-April/052629.html: On Tue, Apr 25, 2017 at 07:53:06PM +0200, Niels de Vos wrote:
Hi,
Recently a new ability to trigger statedumps through the Gluster-CLI = [0] has been added. This makes it possible to get statedump from applications that use gfapi. By default, statedumps are saved under /var/run/gluster/... and this directory is only writable by root. Applications that use gfapi do not require root permissions (like QEM= U), and therefore fail to write the statedump :-/
One approach would be to create a "gluster" group and give the group permissions to write to /var/run/gluster/... Other 'fixes' include setting ACLs on the directory so that specified users can write there. because many daemons have a "home directory" that does not exist, it probably is not a good idea to use $HOME to store statedumps.
What suggestions do others have?
Thanks, Niels
0. https://github.com/gluster/glusterfs/blob/master/doc/debugging/statedum=
Yes, maybe. The request to improve debugging came from oVirt developers or users, so I am interested to hear those opinions first. Once I have a better feeling for an acceptible solution, I'll make sure to get the QEMU folks on board too. Thanks for your reply! Niels p.md
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
--r7tUYVWcdYzDJoZW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJZA1HtAAoJECXo5AApwsWzcBkQAIJ0lkRrNnJB/3FZplogle63 IS6AA1w6BXiqvSHpOQpJZibiwu/HQlgw7wq1jUBEl/gfe383I/I9fZ8U41MmtyIP 9GmpUUCEsMOnn3uBBwfyLKRD4qY97wtjj8Xnruan8kV66iU2TxurFIEEFkTAYtlk kaZgPh7HgvoJlqEiCP0VUnoMIKZtRLA6RQJMGvxR7LGq1d8XR1kpbBMDRUR9up1O pHKFBvP5wGY+0WMS8sJ0zfug19YEQbkUqjRq8w/iqoNkRGraNcwVFkMcXsH+Rf5C rP1v7ahyVonzPTmGKBBr+lHQ6etADlWhSUCeAJmKcuGtRBA6DoSMFEOT+7mWlBcb SRPQiVx6Sz2i9CZgh0VvKB/uyL7PjRlru4qCo7tGpQSuq7KoC45aNzrcfKIt6Iyv /6EMyrfz69UEW6KJutOm4rLgwY/mGdb2Tp7mrV1//EA9E81pr4BXODjo3/NOCiqe aRmDUDXj4PcMpre/QTSt3SHxz5oIinmluytQtjBStHBtcYhO8voRskuRwWjfkhSD gU8udZkvWLNhEoHOGXqve5WFn9lAlVhyatbjkvd430b7dMF0G49e5vKt3+cPvfrH V/leqrp86IcCg1DbWiEwrkZ89ILgrVz9fB6rhrtgxkvwGUEGi36b5gdF/SJb9x7v gQeK+KmxWQChP7Bmxh7r =55t6 -----END PGP SIGNATURE----- --r7tUYVWcdYzDJoZW--
participants (3)
-
Niels de Vos -
Nir Soffer -
Sandro Bonazzola