similar to: [PATCH] v2v: -o rhv-upload: Allow configure commands to set the Python version.

No functional change, but it does allow downstream distributions to adjust the nbdkit Python plugin used by virt-v2v -o rhv-upload mode: ./configure --with-virt-v2v-nbdkit-python-plugin=... --- .gitignore | 1 + configure.ac | 5 +++++ m4/guestfs-v2v.m4 | 28 ++++++++++++++++++++++++++++ v2v/Makefile.am | 4 ++++ v2v/config.ml.in | 20

In case the whole conversion fails, run a new Python script to cleanup all the uploaded (and finalized) disks. --- v2v/Makefile.am | 6 ++ v2v/output_rhv_upload.ml | 29 +++++++- v2v/output_rhv_upload_deletedisks_source.mli | 19 ++++++ v2v/rhv-upload-deletedisks.py | 71 ++++++++++++++++++++ 4 files changed, 124 insertions(+), 1

Split the VM existance check out of the precheck script to a new vmcheck script, and invoke that in #prepare_targets. Invoke the precheck script in #precheck, as now it can be run with only values of command line options. This does not change which checks are performed; however, an invalid cluster name will make virt-v2v fail way earlier (even before connecting to the source). ---

This is not quite a neutral refactoring, because it means we now run the getenforce command every time virt-v2v starts up. However it's a trivial command that reads a single /sys file and it can't fail even if the command is missing or on platforms that know nothing about SELinux. --- v2v/input_libvirt_vddk.ml | 4 ---- v2v/output_rhv_upload.ml | 4 ---- v2v/utils.ml | 4

Make use of the temporary directory of the rhv-upload mode also for the Python scripts that the mode creates, instead of creating new directories. --- v2v/output_rhv_upload.ml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/v2v/output_rhv_upload.ml b/v2v/output_rhv_upload.ml index eec9c5c79..78e9145c6 100644 --- a/v2v/output_rhv_upload.ml +++

Improve the way the precheck script checks for the specified resources: - look directly for a data center with the specified storage domain - get the storage domain object from the storage domains attached to the data center found - similarly, look for the specified cluster among the ones attached to the data center found When everything is found, return the UUID of the storage domain, and of

Instead of waiting for the completion of the nbdkit transfers to get the UUIDs of the disks, use the new #disk_copied hook to do that after each disk is copied. This has almost no behaviour on rhv-upload, except for the --no-copy mode: - previously it used to hit the 5 minute timeout while waiting for the finalization of the first disk - now it asserts on the different number of collected UUIDs

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

On Thu, Sep 19, 2019 at 02:30:05PM +0200, Pino Toscano wrote: > Make use of the temporary directory of the rhv-upload mode also for the > Python scripts that the mode creates, instead of creating new > directories. > --- > v2v/output_rhv_upload.ml | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/v2v/output_rhv_upload.ml

Add an optional parameter for Python_script.create, to specific the temporary directory to use instead of creating a new one. --- v2v/python_script.ml | 13 ++++++++----- v2v/python_script.mli | 5 ++++- 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/v2v/python_script.ml b/v2v/python_script.ml index 3159373a1..6bb14ec1f 100644 --- a/v2v/python_script.ml +++

Do not assume that the Python plugin of nbdkit has the same name of the Python interpreter. Use the default upstream name of nbdkit to identify it; downstream distributions must adjust this variable, in case they rename the Python plugin of nbdkit. --- v2v/output_rhv_upload.ml | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/v2v/output_rhv_upload.ml

On Tuesday, 8 January 2019 13:29:47 CET Richard W.M. Jones wrote: > No functional change, but it does allow downstream distributions to > adjust the Python interpreter and nbdkit Python plugin used by > virt-v2v -o rhv-upload mode: > > ./configure --with-virt-v2v-python-interpreter=... What is the use case for this? The documentation for the variable in config.mli says: > +val

It makes little sense to require the oVirt certificate, especially when the verification of the connection (-oo rhv-verifypeer) is disabled by default. The only work done with the certificate in that case is checking that it is a valid certificate file. Hence, make -oo rhv-cafile optional, requiring it only when -oo rhv-verifypeer is enabled. --- v2v/output_rhv_upload.ml | 16

PROBLEMS: - Spools to a temporary disk - Need to specify direct/indirect upload via flag - Location of ca.pem - Target cluster - Delete disks on failure, or rename disks on success? - Handling of sparseness in raw format disks This adds a new output mode to virt-v2v. virt-v2v -o rhv-upload streams images directly to an oVirt or RHV >= 4 Data Domain using the oVirt SDK v4. It is more

PROBLEMS: - Spools to a temporary disk - Target cluster - Delete disks on failure, or rename disks on success? - Handling of sparseness in raw format disks - Manual page This adds a new output mode to virt-v2v. virt-v2v -o rhv-upload streams images directly to an oVirt or RHV >= 4 Data Domain using the oVirt SDK v4. It is more efficient than -o rhv because it does not need to go via the

The previous patches seem OK. On a quick glance this one also seems a good start. On Thu, 22 Feb 2018 13:57:25 +0000 "Richard W.M. Jones" <rjones@redhat.com> wrote: > PROBLEMS: > - Spools to a temporary disk > - Need to specify direct/indirect upload via flag > - Location of ca.pem We surely need a new argument for that. When running on VDSM host the certificate

On 03/08/2018 12:57 PM, Nir Soffer wrote: > On Thu, Mar 8, 2018 at 11:37 AM Richard W.M. Jones <rjones@redhat.com > <mailto:rjones@redhat.com>> wrote: > > PROBLEMS: >  - Target cluster defaults to "Default". >  - Using Insecure = True, is that bad? >  - -of qcow2 does not work, with multiple problems >  - Need to attach disks

PROBLEMS: - Target cluster defaults to "Default". - Using Insecure = True, is that bad? - -of qcow2 does not work, with multiple problems - Need to attach disks to VMs somehow This adds a new output mode to virt-v2v. virt-v2v -o rhv-upload streams images directly to an oVirt or RHV >= 4 Data Domain using the oVirt SDK v4. It is more efficient than -o rhv because it does not

This patch series fixes various issues in the rhv-upload output mode: - properly find and use RHV resources - cleanup orphan disks, and possibly the current disk transfer on failure In reality, the first 4 patches deal with resources, and the other 4 with cleanups. The latter block can be theoretically sent alone -- I just happened to start working on it as part of my "let's fix

On Thu, 8 Mar 2018 09:37:19 +0000 "Richard W.M. Jones" <rjones@redhat.com> wrote: > PROBLEMS: > - Target cluster defaults to "Default". > - Using Insecure = True, is that bad? Since you have --rhv-cafile mandatory, there is no reason to set Insecure=True. > - -of qcow2 does not work, with multiple problems > - Need to attach disks to VMs somehow