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

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