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 _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
