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

[Richard W.M. Jones]

On Tue, Apr 07, 2020 at 02:16:49PM +0100, Daniel P. Berrangé wrote:
> 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.

To clarify: there are two different configs we're considering.  The
"fixed appliance" one is where we prebuild the appliance and put it in
the container (but it runs into the problem with sparse files not
being supported properly, since it is a very large sparse file).  The
other is the normal one where we run virt-v2v and the appliance is
created and cached the first time.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html