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

[Richard W.M. Jones]

On Thu, Apr 02, 2020 at 05:51:32PM +0200, Pino Toscano wrote:
> On Thursday, 2 April 2020 17:30:39 CEST Richard W.M. Jones wrote:
> > On Thu, Apr 02, 2020 at 03:21:14PM +0200, Pino Toscano wrote:
> > > On Thursday, 2 April 2020 14:49:18 CEST Richard W.M. Jones wrote:
> > > > Previously we placed large files in g#get_cachedir () (usually
> > > > /var/tmp).  However the problem is this ties the libguestfs appliance
> > > > and the virt-v2v overlay files to the same location.
> > > > 
> > > > When virt-v2v is run in a container, or any other situation where
> > > > local storage is limited, it's helpful to be able to put the overlay
> > > > files on an externally mounted PVC, which might be using NFS and
> > > > shared between containers.  But putting the libguestfs appliance on
> > > > NFS in a shared location is certainly not recommended.
> > > > 
> > > > This allows the two locations to be set separately:
> > > > 
> > > >   VIRT_V2V_TMPDIR - location of large temporary files, can use NFS
> > > >                     and may be shared
> > > > 
> > > >   LIBGUESTFS_CACHEDIR - location of libguestfs appliance
> > > > 
> > > > Another motivation for this patch is to allow more reliable cleanup of
> > > > temporary files by an external process, as described in the updated
> > > > documentation.
> > > > ---
> > > 
> > > I do not understand the motivation behind this, which adds yet another
> > > location with temporary files in addition to:
> > > - LIBGUESTFS_TMPDIR - $TMPDIR by default (which itself is /tmp by
> > >   default)
> > > - LIBGUESTFS_CACHEDIR - /var/tmp by default (with a .guestfs-$UID
> > >   subdirectory for the appliance)
> > > 
> > > Before this patch, almost all the temporary files are stored directly
> > > or in subdirectories of $TMPDIR, except big files such as overlays and
> > > OVA extracted content that are in CACHEDIR. With the proposed changes,
> > > _all_ the temporary files will be in CACHEDIR, so there are the
> > > following problems:
> > > - this directory will be cluttered with a lot more files than before
> > > - if it is shared, then other places where it is mounted will see the
> > >   same files
> > > - if it is shared, then creating temporary files will possibly mean
> > >   doing network I/O
> > > - if virt-v2v exits uncleantly, there will be a lot more files to
> > >   cleanup than now
> > > - even without being shared, /var/tmp is persistent unlike /tmp (which
> > >   can be tmpfs-backed on some distros/setups), meaning old temporary
> > >   files will linger way more
> > 
> > How about if we confine the change to just large files (ie. ones
> > which are currently placed in cachedir)?
> 
> This is already the case, isn't it?
> 
> > However the way that virt-v2v works at the moment means you cannot put
> > the large files (especially v2vovl*.qcow2) in a different place from
> > the libguestfs appliance.  This means that if you have only "some"
> > space in /var/tmp -- enough for the appliance, but not enough for the
> > potentially much larger space required by v2vovl*.qcow2 with multiple
> > copies of virt-v2v running -- then you cannot separate the overlays to
> > another directory.  This isn't just a problem for containers.
> 
> /var/tmp is a temporary directory, hence it ought to have enough space
> for big temporary files. This is nothing special for libguestfs or
> virt-v2v.
> 
> I do not see what makes v2vovl*.qcow2 files so special in this regard,
> requiring them to be handled specially than other big temporary files
> already stored by libguestfs/virt-v2v. Examples:
> - the appliance
> - the temporary directory for qemu when using the libvirt backend
> - the extracted content of an OVA, in case we cannot read it directly
> - the disks when exporting to glance (-o glance)

"Because containers" is the only answer I can give to this.
Containers have weird constraints, in that /var/tmp may be
big, but not big enough for the overlay files.

I still think the principle of being able to put the
libguestfs appliance and the other big temporary files
in different places is not a bad one.

(CC-ing Dan, and Igor who is the bug reporter)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top