similar to: [PATCH v2] v2v: -o openstack: -oo verify-server-certificate=(true|false) (RHBZ#1651432).

If ‘virt-v2v -oo insecure’ is used then ‘openstack --insecure’ flag is added whenever we invoke the openstack command. This turns of SSL certificate validation. --- v2v/output_openstack.ml | 14 +++++++++++++- v2v/virt-v2v-output-openstack.pod | 1 + v2v/virt-v2v.pod | 7 +++++++ 3 files changed, 21 insertions(+), 1 deletion(-) diff --git a/v2v/output_openstack.ml

Previously we allowed arbitrary flags to be passed through to the underlying openstack CLI command, provided they have the format ‘--key=value’. We want to pass the ‘--insecure’ flag through, but that doesn't have the key=value form. However a small modification to the matching rules would allow this. The effect of this change is that you can now use ‘virt-v2v -oo insecure’ to turn off SSL

The first patch restricts passthrough parameters to ones matching "os-*". This was how it was documented, but not how it was implemented. The second patch is the same as v2 here: https://www.redhat.com/archives/libguestfs/2018-November/msg00187.html Rich.

A smaller change than v2, we simply generalize the ability to pass through flags to the underlying openstack command, allowing the --insecure flag to be specified directly. Rich.

Random old patch that I had in my queue. Posting it as a backup, it is still untested. Rich.

In some cases we have observed the time taken for a Cinder volume to attach to the conversion appliance can be longer than the current 60 seconds. Increase the timeout to 5 minutes. Thanks: Ming Xie. --- v2v/output_openstack.ml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/v2v/output_openstack.ml b/v2v/output_openstack.ml index caaedf452..e395ccb37 100644 ---

v1 was here: https://www.redhat.com/archives/libguestfs/2018-August/thread.html#00287 v2: - The -oa option now gives an error; apparently Cinder cannot generally control sparse/preallocated behaviour, although certain Cinder backends can. - The -os option maps to Cinder volume type; suggested by Matt Booth. - Add a simple test.

This patch implements output to OpenStack Cinder volumes using OpenStack APIs. It has only been lightly tested, but appears to work. There are some important things to understand about how this works: (1) You must run virt-v2v in a conversion appliance running on top of OpenStack. And you must supply the name or UUID of this appliance to virt-v2v using the ‘-oo server-id=NAME|UUID’ parameter.

Improves the error message when openstack is not installed: $ virt-v2v -i disk fedora-28.img -o openstack virt-v2v: error: no binary called ‘openstack’ was found on the $PATH. We use this program to communicate with OpenStack so it must be installed to use this output mode. --- v2v/output_openstack.ml | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git

On Tuesday, 20 November 2018 11:25:10 CET Richard W.M. Jones wrote: > Previously we allowed arbitrary flags to be passed through to the > underlying openstack CLI command, provided they have the format > ‘--key=value’. We want to pass the ‘--insecure’ flag through, but > that doesn't have the key=value form. However a small modification to > the matching rules would allow

They can contain passwords or tokens if for example the ‘-oo os-password’ option is used. Thanks: Tomáš Golembiovský, Brett Thurber. --- v2v/output_openstack.ml | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/v2v/output_openstack.ml b/v2v/output_openstack.ml index 95c42cbed..3ff1e1269 100644 --- a/v2v/output_openstack.ml +++ b/v2v/output_openstack.ml @@ -177,8

Since this output method was written the code has always been capable of adding the hw_firmware_type = uefi image property, and this property has been supported since at least OpenStack 12 which is years old. Interestingly now all of the output modes support both BIOS and UEFI. --- v2v/output_openstack.ml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/v2v/output_openstack.ml

On Mon, Sep 24, 2018 at 10:00:21AM +0200, Fabien Dupont wrote: > Hi, Hi Fabien, sorry I didn't respond to this earlier as I was doing some work. If you CC me on emails then you can usually get a quicker response. > I've read the virt-v2v OpenStack output code to understand how it works and > I've seen this: > > > (* The server name or UUID of the conversion

On my current instance, the meta_data.json is the following: { "availability_zone": "nova", "devices": [], "hostname": "ims-host-1", "keys": [ { "data": "ssh-rsa

Hi, I've read the virt-v2v OpenStack output code to understand how it works and I've seen this: > (* The server name or UUID of the conversion appliance where > * virt-v2v is currently running. In future we may be able > * to make this optional and derive it from the OpenStack > * metadata service instead. > *) > server_id : string; Indeed, it can be

On Mon, Sep 24, 2018 at 6:30 PM Richard W.M. Jones <rjones@redhat.com> wrote: > On Mon, Sep 24, 2018 at 10:00:21AM +0200, Fabien Dupont wrote: > > Hi, > > Hi Fabien, sorry I didn't respond to this earlier as I was doing some > work. If you CC me on emails then you can usually get a quicker > response. > > > I've read the virt-v2v OpenStack output code

(Apologies if I missed anyone off the To: line. Please add anyone else who is interested, but keep the libguestfs public mailing list) I did some preparatory work on adding the new ‘virt-v2v -o openstack’ output mode. I've put it in a private (non-FFwd) branch here: https://github.com/rwmjones/libguestfs/tree/openstack Most of the work was refactoring virt-v2v so that we have all of the

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

On Wed, Sep 26, 2018 at 02:40:54PM +0200, Fabien Dupont wrote: > [Adding Tomas Golembiovsky] > > Well, that's mainly IMS related challenges. We're working on > OpenStack output support and migration throttling and this implies > changes to virt-v2v-wrapper. This is then the opportunity to think > about virt-v2v-wrapper maintenance and feature set. It has been >

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,