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

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.