similar to: [PATCH v2v v2 0/2] rhv-upload: Validate UUIDs and check they don't exist already

My stab v3 at fixing this: https://bugzilla.redhat.com/show_bug.cgi?id=1789279 It took me quite some time to go through the whole rfc 4122 just to realize we do not need to do anything with the versions. v3: - Do the check in precheck - Fix for Lazy evaluation of regexp UUID v2: - https://www.redhat.com/archives/libguestfs/2020-January/msg00221.html - Use EEXIST instead of EINVAL - Put the

My stab at fixing this: https://bugzilla.redhat.com/show_bug.cgi?id=1789279 It took me quite some time to go through the whole rfc 4122 just to realize we do not need to do anything with the versions. Martin Kletzander (2): rhv-upload: Validate UUIDs passed to -oo rhv-disk-uuid (RHBZ#1789279) rhv-upload: Check that rhv-disk-uuid is not already taken (RHBZ#1789279)

On Wed, Jan 29, 2020 at 03:34:48PM +0100, Martin Kletzander wrote: >The validation helps us fail early and with a sensible error message. The NIL >UUID is not valid for oVirt, but other than that there is no other logic in >there merely because the UUID types are a matter of the generator and they are >just forwarded in this partucular case. > >Signed-off-by: Martin Kletzander

This is actually not required, because ovirtsdk4 will use the system's global trust store if necessary. Therefore we can make it optional in all cases. --- docs/virt-v2v-output-rhv.pod | 5 ++++- v2v/output_rhv_upload.ml | 2 -- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/virt-v2v-output-rhv.pod b/docs/virt-v2v-output-rhv.pod index 04a894268..4520c9184 100644 ---

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

On Thu, Jan 23, 2020 at 11:12:22PM +0100, Martin Kletzander wrote: > The validation helps us fail early and with a sensible error message. The NIL > UUID is not valid for oVirt, but other than that there is no other logic in > there merely because the UUID types are a matter of the generator and they are > just forwarded in this partucular case. > > Signed-off-by: Martin

The validation helps us fail early and with a sensible error message. The NIL UUID is not valid for oVirt, but other than that there is no other logic in there merely because the UUID types are a matter of the generator and they are just forwarded in this partucular case. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> --- v2v/output_rhv_upload.ml | 12 ++++++++++++ 1 file changed,

The validation helps us fail early and with a sensible error message. The NIL UUID is not valid for oVirt, but other than that there is no other logic in there merely because the UUID types are a matter of the generator and they are just forwarded in this partucular case. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> --- v2v/output_rhv_upload.ml | 10 ++++++++++ 1 file changed,

The validation helps us fail early and with a sensible error message. The NIL UUID is not valid for oVirt, but other than that there is no other logic in there merely because the UUID types are a matter of the generator and they are just forwarded in this partucular case. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> --- v2v/output_rhv_upload.ml | 12 ++++++++++++ 1 file changed,

v7 was here: https://www.redhat.com/archives/libguestfs/2018-March/msg00143.html Since then: - Earlier patches are now upstream. - The to-do list is moved from the commit message to the TODO file. - This version forces -of raw + -oa sparse and gives an error in any other mode. We intend to lift these restrictions later. - Tested against latest imageio which supports longer timeouts,

v8 was here: https://www.redhat.com/archives/libguestfs/2018-April/msg00022.html v8 -> v9: - Addresses the only feedback from Tomáš. Rich.

v5 was here: https://www.redhat.com/archives/libguestfs/2018-March/msg00032.html There is only a single patch in this version because the other patches went upstream. This patch adds the virt-v2v -o rhv-upload mode (https://bugzilla.redhat.com/show_bug.cgi?id=1557273). Compared to v5, this adds the ability to make zero, trim and flush requests to the oVirt imageio server

This way it is possible to override the UUIDs of the uploaded disks, instead of letting RHV generate them. This can be useful to force certain UUIDs, and to specify the disks in --no-copy mode (which now can be used). --- v2v/output_rhv_upload.ml | 43 ++++++++++++++++++++++++++++++++----- v2v/rhv-upload-plugin.py | 2 ++ v2v/virt-v2v-output-rhv.pod | 23 ++++++++++++++++++++ 3 files

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 Wednesday, 29 January 2020 15:34:49 CET Martin Kletzander wrote: > This makes the code fail with a sensible error message instead of cryptic error > from ovirtsdk. > > Signed-off-by: Martin Kletzander <mkletzan@redhat.com> > --- > v2v/rhv-upload-plugin.py | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/v2v/rhv-upload-plugin.py

This patch set is still for discussion only. See 3/3 for the current list of problems. However this will upload an image to an oVirt or RHV server, although you must have absolutely the latest snapshot version of 4.2 for it to work. Rich.

The first four patches are straightforward. The final patch adds the -o rhv-upload output mode. It is still spooling into a temporary file because I've had some trouble getting streaming conversions working. There are other problems as outlined in the commit message, so this patch is not ready for upstream but is good for discussion. Also I hit this, which I'm assuming for now will be

v2 -> v3: - Lots of code cleanups. - Documentation. However this is still spooling the file into a temporary before the upload. It turns out that fixing this is going to require a small change to qemu. Rich.

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

Mainly minor fixes and code cleanups over the v4 patch. There are still several problems with this patch, but it is in a reviewable state, especially the Python code. Rich.