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

Previously we placed large files in g#get_cachedir () (usually /var/tmp). However the problem is this ties the libguestfs appliance and the virt-v2v overlay files to the same location. When virt-v2v is run in a container, or any other situation where local storage is limited, it's helpful to be able to put the overlay files on an externally mounted PVC, which might be using NFS and shared

Create two temporary directories for all the files created during the virt-v2v run: 1) tmpdir, created as $TMPDIR/virt-v2v.XXXXXX, for all the small files 2) cachedir, created as $LIBGUESTFS_CACHEDIR/virt-v2v.XXXXXX, for the big files (e.g. disks) This way there is no need to manually schedule all the temporary files and directories for removal when the application quits. --- v2v/input_ova.ml

v1 was here: https://www.redhat.com/archives/libguestfs/2020-April/msg00007.html There's a BZ for this now which I forgot to add to the commit message: https://bugzilla.redhat.com/show_bug.cgi?id=1814611 For v2: - Fix incorrect reference to $TMPDIR in existing manual. - Separate handling for small temporary files and large temporary files. Small temporary files go into $TMPDIR

Iterating over source disks and creating temporary overlays for easy rollback fits nicely into a separate function. In addition, determining their size doesn't need to wait until the guestfs is launched: the size can be obtained via disk_virtual_size() method. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/v2v.ml | 91

On Wed, Oct 21, 2015 at 03:53:33PM +0200, Pino Toscano wrote: > Use the common open_guestfs to open Guestfs handles, so we get > debugging, tracing, and other common options set. > --- > v2v/convert_windows.ml | 4 +--- > v2v/input_disk.ml | 2 +- > v2v/input_libvirt_other.ml | 2 +- > v2v/input_ova.ml | 2 +- > v2v/output_glance.ml | 2 +- >

On Thu, Apr 02, 2020 at 03:21:14PM +0200, Pino Toscano wrote: > On Thursday, 2 April 2020 14:49:18 CEST Richard W.M. Jones wrote: > > Previously we placed large files in g#get_cachedir () (usually > > /var/tmp). However the problem is this ties the libguestfs appliance > > and the virt-v2v overlay files to the same location. > > > > When virt-v2v is run in a

Iterating over source disks and creating temporary overlays for easy rollback fits nicely into a separate function. In addition, determining their size doesn't need to wait until the guestfs is launched: the size can be obtained via disk_virtual_size() method. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/v2v.ml | 91

Use the common open_guestfs to open Guestfs handles, so we get debugging, tracing, and other common options set. --- v2v/convert_windows.ml | 4 +--- v2v/input_disk.ml | 2 +- v2v/input_libvirt_other.ml | 2 +- v2v/input_ova.ml | 2 +- v2v/output_glance.ml | 2 +- v2v/output_null.ml | 2 +- v2v/output_rhev.ml | 2 +- v2v/output_vdsm.ml | 2 +-

On Thu, Apr 02, 2020 at 05:51:32PM +0200, Pino Toscano wrote: > On Thursday, 2 April 2020 17:30:39 CEST Richard W.M. Jones wrote: > > On Thu, Apr 02, 2020 at 03:21:14PM +0200, Pino Toscano wrote: > > > On Thursday, 2 April 2020 14:49:18 CEST Richard W.M. Jones wrote: > > > > Previously we placed large files in g#get_cachedir () (usually > > > > /var/tmp).

Since this new temporary directory will contain UNIX sockets for communicating with nbdkit, then its path must not be too long. Use the existing directory that libguestfs exposes for this, i.e. sockdir. --- v2v/nbdkit.ml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/v2v/nbdkit.ml b/v2v/nbdkit.ml index 65317f9b..46b20c9d 100644 --- a/v2v/nbdkit.ml +++ b/v2v/nbdkit.ml

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

On Monday, 6 April 2020 11:19:12 CEST Richard W.M. Jones wrote: > Previously we placed large files in g#get_cachedir () (usually > /var/tmp). However the problem is this ties the libguestfs appliance > and the virt-v2v overlay files to the same location. > > When virt-v2v is run in a container, or any other situation where > local storage is limited, it's helpful to be able

On Wed, 10 Jun 2020 11:31:33 +0100 "Richard W.M. Jones" <rjones@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

On Thu, Apr 02, 2020 at 05:51:32PM +0200, Pino Toscano wrote: > On Thursday, 2 April 2020 17:30:39 CEST Richard W.M. Jones wrote: > > On Thu, Apr 02, 2020 at 03:21:14PM +0200, Pino Toscano wrote: > > > On Thursday, 2 April 2020 14:49:18 CEST Richard W.M. Jones wrote: > > > > Previously we placed large files in g#get_cachedir () (usually > > > > /var/tmp).

On Thursday, 2 April 2020 17:30:39 CEST Richard W.M. Jones wrote: > On Thu, Apr 02, 2020 at 03:21:14PM +0200, Pino Toscano wrote: > > On Thursday, 2 April 2020 14:49:18 CEST Richard W.M. Jones wrote: > > > Previously we placed large files in g#get_cachedir () (usually > > > /var/tmp). However the problem is this ties the libguestfs appliance > > > and the

On Monday, 6 April 2020 19:45:44 CEST Daniel P. Berrangé wrote: > On Thu, Apr 02, 2020 at 05:51:32PM +0200, Pino Toscano wrote: > > On Thursday, 2 April 2020 17:30:39 CEST Richard W.M. Jones wrote: > > > On Thu, Apr 02, 2020 at 03:21:14PM +0200, Pino Toscano wrote: > > > > On Thursday, 2 April 2020 14:49:18 CEST Richard W.M. Jones wrote: > > > > >

On Mon, Jul 27, 2015 at 07:29:57PM +0300, Roman Kagan wrote: > In this mode, converting of the VM configuration, setting up the > rollback path for error cases, transforming the VM storage and so on is > taken care of by a third-party toolset, and virt-v2v is only supposed to > tune up the guest OS directly inside the source VM, to enable it to boot > and run under the input

On Thursday, 2 April 2020 14:49:18 CEST Richard W.M. Jones wrote: > Previously we placed large files in g#get_cachedir () (usually > /var/tmp). However the problem is this ties the libguestfs appliance > and the virt-v2v overlay files to the same location. > > When virt-v2v is run in a container, or any other situation where > local storage is limited, it's helpful to be

In this mode, converting of the VM configuration, setting up the rollback path for error cases, transforming the VM storage and so on is taken care of by a third-party toolset, and virt-v2v is only supposed to tune up the guest OS directly inside the source VM, to enable it to boot and run under the input hypervisor. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> ---

common/mlutils: Unix_utils.StatVFS.statvfs: This commit implements a full-featured binding for the statvfs(3) function. We then use this to reimplement the daemon statvfs API in OCaml. Note that the Gnulib fallback is fixed in this commit. It previously referenced non-existent field names in the fs_usage struct. --- common/mlutils/unix_utils-c.c | 138 ++++++++++++++++++++++++++++---