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

[Tomáš Golembiovský]

On Tue, 16 Jun 2020 22:06:58 +0100
"Richard W.M. Jones" <rjones at redhat.com> wrote:

> 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.

My understanding is that the container should not require significant
amount of free space for runtime. If you need a permanent data storage
or larger amount of temporary storage you need to use a volume.

> 
> 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.

NFS is just one of the methods to provision a volume. There is also a
host-local provisioner that makes sure there is enough space on the
local storage -- which seems what you are suggesting -- but I do not
recall what were the arguments against using it.


> > > * /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?

Oh, I see. That seems wrong then and is probably a bug in Kubevirt web
UI. Do you still have access to the testing environment?

> 
> > > 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.

They should not. If they do then it is a bug somewhere else and not in
virt-v2v.

    Tomas

> 
> 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/
> 


-- 
Tomáš Golembiovský <tgolembi at redhat.com>