[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 04:34:15PM +0200, Tomáš Golembiovský wrote:
> On Wed, 10 Jun 2020 11:31:33 +0100
> "Richard W.M. Jones" <rjones at redhat.com> 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.)
> 
> The thing is that nobody can guarantee that there will be enough space.
> The underlying filesystem (not the mountpoint) is shared between all the
> containers running on the host. This is the reason why we have a PV on
> /var/tmp -- to make sure we have guaranteed free space.

This must surely be a problem for all containers?  Do containers
behave semi-randomly when the host starts to run out of space?  All
containers must have to assume that there's some space available in
/tmp or /var/tmp surely.

If we can guarantee that each container has 1 or 2 G of free space
(doesn't seem unreasonable?) then virt-v2v should work fine and won't
need any NFS mounts.

> > * /var/tmp => an NFS mount from a PVC
> > 
> > This is a large (2T) external NFS mount.
> 
> I assume that is the free space in the underlying filesystem. From there
> you should be guaranteed to "own" only 2GB (or something like that).
> 
> > 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.
> 
> You mean you run two pods based on some YAML template or you run two
> pods from Kubevirt web UI?

Two from a yaml template, however ...

> If you run the pods manually you may have
> reused the existing PV/PVC. It is the web UI that should provision you
> new scratch space for each pod. If that is not working then that is a
> bug in Kubevirt.

... the PVC name was "v2v-conversion-temp" (and not some randomly
generated name) suggesting that either the user must enter a new name
every time or else they're all going to get the same NFS mount.
Can you explain a bit more about how they get different mounts?

> > Also it uses root squash (so root:root is
> > mapped to 99:99).
> 
> IMHO this is the main problem that I have been telling them about from
> the start. Thanks for confirming it. Using root squash on the mount is
> plain wrong.

This is definitely the main problem, and is the direct cause of the
error you were seeing.  I'm still not very confident that our locking
will work reliably if two virt-v2v instances in different containers
or pods see a shared /var/tmp.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/