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

[Daniel P. Berrangé]

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

In a container world /var/tmp usually won't be persistent. Each
boot of the container will typically start with a pristine copy of
the filesystem, so a fresh & empty /var/tmp. Any changes to the
/var/tmp, or anywhere else in the default root filesystem tree
will get thrown away at container shutdown.

NB It is technically possible to start a container, stop it, and then
boot it against from the same FS instance, but it isn't very common
to do that IME.

Extra storage will be made available to the container at admin
specified paths, and though (as a user) you don't typically know
what kind of storage this is, most commonly it will be something
network backed, whether glusterfs, or nfs, or ceph, while the
default / will usually be local storage. 

> That said, it is not clear to me why /var/tmp should be shared among
> containers.

I wouldn't ever expect to see /var/tmp shared in containers. Even the
add-on persistent storage that you can make available is usually
dedicated to a single container & wiped / freshly formatted.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|