Re: [Libguestfs] [PATCH virt-v2v] v2v: Allow temporary directory to be set on a global basis.

On Tue, Apr 07, 2020 at 02:33:20PM +0200, Pino Toscano wrote: > On Tuesday, 7 April 2020 14:18:47 CEST Richard W.M. Jones wrote: > > On Tue, Apr 07, 2020 at 01:25:02PM +0200, Pino Toscano wrote: > > > The important thing is still that that you need to have space for the > > > temporary files somewhere: be it /var/tmp, /mnt/scratch, whatever. > > > Because of this, and the fact that usually containers are created > > > fresh, the cache of the supermin appliance starts to make little sense, > > > and then a very simple solution is to point libguestfs to that extra > > > space: > > > > > > $ dir=$(mktemp --tmpdir -d /path/to/big/temporary/space/libguestfs.XXXXXX) > > > $ export LIBGUESTGS_CACHEDIR=$dir > > > $ export TMPDIR=$dir # optionally > > > $ libguestfs-test-tool > > > [etc] > > > $ rm -rf $dir > > > > > > Easy to use, already doable, solves all the issues. > > > > So AIUI there are a few problems with this (although I'm still > > investigating and trying to make a local reproducer): > > > > - The external large space may be on NFS, with the usual problems > > there like root_squash, no SELinux labels, slowness. This means > > it's not suitable for the appliance, but might nevertheless be > > suitable for overlay files. > > If that is the only big storage space attached to a container, I do > not see any alternative than use it, with all the caveats associated. > > Also, if we take as possible scenario the situation where /var/tmp is > not that big, then we need to consider that may not be big enough to > even store the cached supermin appliance (which is more than > 300/350MB). In another message in this thread, Rich indicates the appliance is being built at the time the container image itself is built. As such the appliance will already be present in /var/tmp when the container starts, so there's no disk space issue for it. The issue of lack of space only applies to files created after the container is running.