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

[Richard W.M. Jones]

On Tue, Jun 16, 2020 at 11:06:28AM +0200, Pino Toscano wrote:
> On Wednesday, 10 June 2020 12:31:33 CEST Richard W.M. Jones wrote:
> > I finally got access to the container.  This is how it's configured:
> > 
> > * / => an overlay fs.
> > 
> > There is sufficient space here, and there are no "funny" restrictions,
> > to be able to create the libguestfs appliance.  I proved this by
> > setting TMPDIR to a temporary directory under / and running
> > libguestfs-test-tool.
> > 
> > There appears to be quite a lot of free space here, so in fact the
> > v2vovl files could easily be stored here too.  (They only store the
> > conversion delta, not the full guest images.)
> > 
> > * /var/tmp => an NFS mount from a PVC
> > 
> > This is a large (2T) external NFS mount.  I actually started two pods
> > to see if they got the same NFS mount point, and they do.  Also I
> > wrote files to /var/tmp in one pod and they were visible in the other.
> > So this seems shared.  Also it uses root squash (so root:root is
> > mapped to 99:99).  For both reasons this cannot be used for the
> > appliance.  If it was mounted at another location it might be used for
> > the v2vovl files.
> > 
> > I've attached the exact mount details at the end of this email.
> > 
> > My conclusion is that we could do one of two things:
> > 
> > Either:
> > 
> > (1) Easiest solution is simply not mount anything under /var/tmp, and
> > let it be local storage.  Assuming all these containers are getting ~40G
> > of local storage, that's more than enough for virt-v2v to run and
> > store the appliance and overlays.  Everything should just work once
> > you remove that /var/tmp mountpoint and leave it as local storage.
> > 
> > ie these lines are removed:
> >     - mountPath: /var/tmp
> >       name: v2v-conversion-temp
> > 
> > Or:
> > 
> > (2) We could implement more fine-grained temporary directory control,
> > allowing the appliance and v2vovl* files to be placed separately.
> > However it would still be wrong to mount the place where libguestfs
> > creates the appliance (by default /var/tmp) on NFS.
> > 
> > If you do this then you'd want to mount the large NFS storage
> > somewhere else, and there would be a new environment variable
> > (V2V_TMPDIR was my proposal IIRC) which you would point to the NFS
> > mount.  /var/tmp would be local storage, and used for the appliance.
> > (There are other ways to do this if for some reason /var/tmp must be NFS.)
> 
> Or:
> 
> (3) set LIBGUESTFS_CACHEDIR away from /var/tmp or NFS-mounted places,
> so we avoid any root_squash issue, and avoid any sharing of temporary
> files that linger after the container execution.

Sure, but it's kind of like the same as (1).  IMHO /var/tmp simply
shouldn't be shared and shouldn't be on NFS.  We can do (3) if for
some reason fixing the pod configuration cannot be done.

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