similar to: [PATCH v2v] Add -ou option for setting output UUID.

On Thu, Sep 19, 2019 at 12:38:41PM +0200, Pino Toscano wrote: >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 ++++++++++++++++++++++++++++++++----- >

On Thursday, 19 September 2019 13:16:01 CEST Martin Kletzander wrote: > On Thu, Sep 19, 2019 at 12:38:41PM +0200, Pino Toscano wrote: > >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).

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

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

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

This option is needed by vdsm for writing the ovf to a specific directory. The default is current directory. Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1176598 Signed-off-by: Shahar Havivi <shaharh@redhat.com> --- v2v/cmdline.ml | 5 +++++ v2v/output_vdsm.ml | 16 +++++++--------- v2v/output_vdsm.mli | 1 + v2v/test-v2v-o-vdsm-options.sh |

This option is needed by vdsm for writing the ovf to a specific directory. The default is current directory. Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1176598 Signed-off-by: Shahar Havivi <shaharh@redhat.com> --- v2v/cmdline.ml | 5 +++++ v2v/output_vdsm.ml | 16 +++++++--------- v2v/output_vdsm.mli | 1 + v2v/test-v2v-o-vdsm-options.sh |

On Wed, Oct 09, 2019 at 02:19:46PM +0200, Martin Kletzander wrote: > Even though this option is not to be used according to the manual, it: > > a) still might be useful even for machine-readable logs > > b) should not break the machine-readable output I'm a bit confused what you're trying to do here. Rich. > Signed-off-by: Martin Kletzander

This option is needed by vdsm for writing the ovf to a specific directory. The default is current directory. Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1176598 Signed-off-by: Shahar Havivi <shaharh@redhat.com> --- v2v/cmdline.ml | 5 +++++ v2v/output_vdsm.ml | 16 +++++++--------- v2v/output_vdsm.mli | 1 + v2v/test-v2v-o-vdsm-options.sh |

Hi Thank you for your quick response, do you know when the build 1.27.53 will be available ? Alain Alain VONDRA Chargé d'exploitation des Systèmes d'Information Direction Administrative et Financière +33 1 44 39 77 76 UNICEF France 3 rue Duguay Trouin 75006 PARIS www.unicef.fr -----Message d'origine----- De : Richard W.M. Jones [mailto:rjones@redhat.com] Envoyé : mardi 23

This option is needed by vdsm for writing the ovf to a specific directory. The default is current directory. Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1176598 Signed-off-by: Shahar Havivi <shaharh@redhat.com> --- v2v/cmdline.ml | 5 +++++ v2v/output_vdsm.ml | 16 +++++++--------- v2v/output_vdsm.mli | 1 + v2v/test-v2v-o-vdsm-options.sh |

This option is needed by vdsm for writing the ovf to a specific directory. The default is current directory. Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1176598 Signed-off-by: Shahar Havivi <shaharh@redhat.com> --- v2v/cmdline.ml | 5 +++++ v2v/output_vdsm.ml | 16 +++++++--------- v2v/output_vdsm.mli | 1 + v2v/test-v2v-o-vdsm-options.sh |

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

Hi, We all agree that it's not specific to virt-v2v. I managed to reproduce the same double fault on "normal" L2 boot - without libguestfs interference. And as Paolo wrote already, he will take a look at it. Thanks, Rom On Tue, Jan 21, 2014 at 3:05 PM, Richard W.M. Jones <rjones@redhat.com>wrote: > On Tue, Jan 21, 2014 at 04:38:30PM +0100, Kashyap Chamarthy wrote: >

[Shahar: Let's discuss virt-v2v & oVirt integration on the public mailing list from now on.] New in 1.27.27: * What we previously called `-o ovf' -- ie the ability to export just the OVF metadata -- has been implemented but in a slightly different way. You can now use: virt-v2v [...] -o rhev --no-copy -os remote:/esd ^^^^^^^^^ This means do the

Hi, I meet an amazing issue, when I convert a raw file to the oVirt environment using virt-v2v. All seems to work fine, my VM is composed of 9 disks, the processes finishes without any trouble, the files are well present in the right import volume, but only the first system disk appear un my oVirt Import VM. I've retried twice and had the same issue . Here the results of the conversion : [

Hey everybody, Any news about the topic? I could not find anything relevant yet. Thanks, Rom On Tue, Jan 21, 2014 at 3:34 PM, Rom Freiman <rom@stratoscale.com> wrote: > Hi, > > We all agree that it's not specific to virt-v2v. > > I managed to reproduce the same double fault on "normal" L2 boot - without > libguestfs interference. > And as Paolo wrote

On Tue, Nov 20, 2018 at 05:04:15PM +0000, Richard W.M. Jones wrote: > >From 9aca67b9875ab31bea7f3aeec411dad3ed990f17 Mon Sep 17 00:00:00 2001 > From: "Richard W.M. Jones" <rjones@redhat.com> > Date: Tue, 20 Nov 2018 17:00:33 +0000 > Subject: [PATCH] v2v: -o rhv-upload: Fix test so it doesn't fail if > Content-Length header missing. > > If the

On Fri, Feb 27, 2015 at 05:28:58PM +0300, Roman Kagan wrote: > Make the location of the Windows virtio drivers overridable with the > environment variable VIRTIO_WIN_DIR, in the same vein as is done for > virt-tools. > > Signed-off-by: Roman Kagan <rkagan@parallels.com> > --- > v2v/convert_windows.ml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) >

Hi, Thank you Richard for your work, but I have also like Jeff Forbes a new issue : libguestfs: trace: hivex_node_set_value = 0 libguestfs: trace: upload "/usr/share/virtio-win/drivers/amd64/Win2008/viostor.sys" "/Windows/Drivers/VirtIO" libguestfs: trace: upload = -1 (error) libguestfs: trace: hivex_close libguestfs: trace: hivex_close = 0 virt-v2v: error: libguestfs error: