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

Richard W.M. Jones rjones at redhat.com
Wed Jun 10 10:31:33 UTC 2020


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

Thanks Igor and Tomas for helping to get access to the environment.

Rich.


Mount entries:

overlay on / type overlay (rw,relatime,context="system_u:object_r:container_file_t:s0:c581,c761",lowerdir=/var/lib/containers/storage/overlay/l/R65BQQOII4EN66JKVROCRZX4DA:/var/lib/containers/storage/overlay/l/VK5ZPTQFJK7RG4DMBQ6IUDKVYS:/var/lib/containers/storage/overlay/l/QNYZ757HCAAQMJJZUZ6D452CSS,upperdir=/var/lib/containers/storage/overlay/76d93cb1256f566100ec2a7e5b5c4b84acc0bfa6a3cb4ebe0adbdb4a0ffc1a9c/diff,workdir=/var/lib/containers/storage/overlay/76d93cb1256f566100ec2a7e5b5c4b84acc0bfa6a3cb4ebe0adbdb4a0ffc1a9c/work)

[nfs-server]:/NFSv4_vol_cnv/ibragins-2-3.cnv-qe.rhcloud.com.pvs/pv9 on /var/tmp type nfs4 (rw,relatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.38,local_lock=none,addr=10.9.96.20)


# df -h
Filesystem                                                                                                   Size  Used Avail Use% Mounted on
overlay                                                                                                       40G   17G   24G  41% /
tmpfs                                                                                                         64M     0   64M   0% /dev
tmpfs                                                                                                        3.9G     0  3.9G   0% /sys/fs/cgroup
shm                                                                                                           64M     0   64M   0% /dev/shm
tmpfs                                                                                                        3.9G  7.2M  3.9G   1% /etc/hostname
tmpfs                                                                                                        3.9G  4.0K  3.9G   1% /data/input
devtmpfs                                                                                                     3.9G     0  3.9G   0% /dev/kvm
/dev/mapper/coreos-luks-root-nocrypt                                                                          40G   17G   24G  41% /etc/hosts
[nfs-server]:/NFSv4_vol_cnv/ibragins-2-3.cnv-qe.rhcloud.com.pvs/pv9   2.0T  945G 1002G  49% /var/tmp
[nfs-server]:/NFSv4_vol_cnv/ibragins-2-3.cnv-qe.rhcloud.com.pvs/pv15  2.0T  945G 1002G  49% /data/vm/disk1
tmpfs                                                                                                        3.9G   24K  3.9G   1% /run/secrets/kubernetes.io/serviceaccount


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW




More information about the Libguestfs mailing list