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