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

Pino Toscano ptoscano at redhat.com
Tue Jun 16 09:06:28 UTC 2020


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.

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20200616/62d1c3c9/attachment.sig>


More information about the Libguestfs mailing list