using BeeGFS parallel file system inside a singularity container
253 views
Skip to first unread message
Dr . Stefan Vollmar
Sep 30, 2016, 9:52:32 AM9/30/16
to singu...@lbl.gov
We have just started to play with singularity and think about using it on our HPC systems - thanks for a great new tool!
Our HPC clusters are connected via infiniband to a parallel file system (BeeGFS, formerly known as FhGFS) which we want to use inside a singularity container.
On the host, this is mounted as /beegfs and I have provided the same mount point inside the container. Also the container has a /etc/singularity/singularity.conf file with a "bind path = /beegfs” line (is that being used?) - anything else we need to do?
Many thanks in advance!
Best,
Stefan
--
Dr. Stefan Vollmar
Max Planck Institute for Metabolism Research
Our HPC clusters are connected via infiniband to a parallel file system (BeeGFS, formerly known as FhGFS) which we want to use inside a singularity container.
On the host, this is mounted as /beegfs and I have provided the same mount point inside the container. Also the container has a /etc/singularity/singularity.conf file with a "bind path = /beegfs” line (is that being used?) - anything else we need to do?
Many thanks in advance!
Best,
Stefan
--
Dr. Stefan Vollmar
Max Planck Institute for Metabolism Research
Lito Bejarano
Oct 1, 2016, 7:43:08 AM10/1/16
to singu...@lbl.gov
That should be enough. /beegfs will be available inside the container using whichever underlying filesystem is used on the host.
Regards--
You received this message because you are subscribed to the Google Groups "singularity" group.
To unsubscribe from this group and stop receiving emails from it, send an email to singularity+unsubscribe@lbl.gov.
Gregory M. Kurtzer
Oct 1, 2016, 10:46:32 PM10/1/16
to singularity
Hi Stefan,
Thanks!
To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov.
--
You received this message because you are subscribed to the Google Groups "singularity" group.
To unsubscribe from this group and stop receiving emails from it, send an email to singularity+unsubscribe@lbl.gov.
Gregory M. Kurtzer
HPC Systems Architect and Technology Developer
Lawrence Berkeley National Laboratory HPCS
University of California Berkeley Research IT
Singularity Linux Containers (http://singularity.lbl.gov/)
University of California Berkeley Research IT
Singularity Linux Containers (http://singularity.lbl.gov/)
Warewulf Cluster Management (http://warewulf.lbl.gov/)
vol...@sf.mpg.de
Oct 2, 2016, 5:07:46 AM10/2/16
to singularity
Sorry for the noise: I can now happily answer my own question - the way we installed singularity 2.1.2 (without prefix) after building in /usr/local/src resulted in a file /usr/local/etc/singularity/singularity.conf which is apparently evaluated when /usr/local/bin/singularity is called.
This works:
(1) created directory (mount point) /beegfs in the container
(2) added line "bind path = /beegfs” in the singularity.conf that is actually used...
A little benchmarking with iozone showed no discernible performance degradation when running the benchmark from within the container - excellent!
Feature suggestion 1:
This did not work at first for us (and hence the original posting) because we did not know which singularity.conf was used. Maybe the documentation could be a bit clearer about that - or, even better, singularity could have a commandline option for querying which config files are being used.
Feature suggestion 2:
It was also not clear to us whether we needed to provide infiniband or other packages/configurations normally required to mount our parallel file (BeeGFS/FhGFS) system inside the container. It turns out - and this is a killer feature of singularity - none of this hassle is needed inside the container for this use case (but it is, obviously, required on the host). We could have deduced that from the documentation - but maybe this is something that could feature more prominently in the documentation (not least because it is such a convenient feature).
This works:
(1) created directory (mount point) /beegfs in the container
(2) added line "bind path = /beegfs” in the singularity.conf that is actually used...
A little benchmarking with iozone showed no discernible performance degradation when running the benchmark from within the container - excellent!
Feature suggestion 1:
This did not work at first for us (and hence the original posting) because we did not know which singularity.conf was used. Maybe the documentation could be a bit clearer about that - or, even better, singularity could have a commandline option for querying which config files are being used.
Feature suggestion 2:
It was also not clear to us whether we needed to provide infiniband or other packages/configurations normally required to mount our parallel file (BeeGFS/FhGFS) system inside the container. It turns out - and this is a killer feature of singularity - none of this hassle is needed inside the container for this use case (but it is, obviously, required on the host). We could have deduced that from the documentation - but maybe this is something that could feature more prominently in the documentation (not least because it is such a convenient feature).
Best,
Stefan
On Sunday, October 2, 2016 at 4:46:32 AM UTC+2, Gregory M. Kurtzer wrote:
Hi Stefan,Just as Lito described! Additionally (if overlayFS is not enabled), you will need to make sure the directories exist within the container.Thanks!
On Sat, Oct 1, 2016 at 4:42 AM, Lito Bejarano <jor...@gmail.com> wrote:
That should be enough. /beegfs will be available inside the container using whichever underlying filesystem is used on the host.Regards
--On Thu, Sep 29, 2016 at 8:16 PM, Dr . Stefan Vollmar <vol...@sf.mpg.de> wrote:We have just started to play with singularity and think about using it on our HPC systems - thanks for a great new tool!
Our HPC clusters are connected via infiniband to a parallel file system (BeeGFS, formerly known as FhGFS) which we want to use inside a singularity container.
On the host, this is mounted as /beegfs and I have provided the same mount point inside the container. Also the container has a /etc/singularity/singularity.conf file with a "bind path = /beegfs” line (is that being used?) - anything else we need to do?
Many thanks in advance!
Best,
Stefan
--
Dr. Stefan Vollmar
Max Planck Institute for Metabolism Research
--
You received this message because you are subscribed to the Google Groups "singularity" group.
To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov.
You received this message because you are subscribed to the Google Groups "singularity" group.
To unsubscribe from this group and stop receiving emails from it, send an email to singularity...@lbl.gov.
Gregory M. Kurtzer
Oct 2, 2016, 11:03:50 AM10/2/16
to singularity
Hi Stefan,
No apologies necessary. I think you are correct, we need better documentation on both fronts (making changes to the singularity.conf and the dependencies of the host and containers). I am hoping the first will be available soon with the new site and documentation effort, and the latter will be contributed by people who wish to post recipes for particular things.
Thank you for the feedback and the results of your testing!
Greg
To unsubscribe from this group and stop receiving emails from it, send an email to singularity+unsubscribe@lbl.gov.
Dr . Stefan Vollmar
Oct 4, 2016, 10:08:36 AM10/4/16
to singu...@lbl.gov
Sorry for the noise: I can now happily answer my own question - the way we installed singularity 2.1.2 (without prefix) after building in /usr/local/src resulted in a file /usr/local/etc/singularity/singularity.conf which is apparently evaluated when /usr/local/bin/singularity is called.
What we did:
(1) created directory (mount point) /beegfs in the container
(2) added line "bind path = /beegfs” in singularity.conf (see above)
A little benchmarking with iozone showed no discernible performance degration when running the benchmark from within the container - excellent!
Feature suggestion:
This did not work at first for us (and hence the original posting) because we did not know which singularity.conf was used (maybe the documentation could be a bit clearer about that - or singularity could have a commandline option for querying which config files are being used).
Feature suggestion:
It was also not clear to us whether we needed to provide infiniband or other packages/configurations normally required to mount our parallel file system inside the container. It turns out - and this is a killer feature of singularity - none of this hassle is needed inside the container (it is, obviously, required on the host). We could have deduced that from the documentation - but maybe this is something that could feature more prominently in the documentation (not least because it is such a convenient feature).
Best,
Stefan
Tobias Kühn
Dec 12, 2018, 4:17:09 AM12/12/18
to singularity, vol...@sf.mpg.de
Hello Stefan,
excuseme for hijacking this thread, but how do you manage to start beegfs Client in a singularity container?
Greeting Tobi
Reply all
Reply to author
Forward
0 new messages