similar to: [PATCH v2 0/2] v2v: machine type for oVirt

Add oVirt specific elemnt to OVF. It represents the combination of machine type (i440fx/q35) and firmware (BIOS/UEFI). Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> --- v2v/create_ovf.ml | 20 +++++++++++++++++++- v2v/create_ovf.mli | 2 +- v2v/output_rhv.ml | 6 ++---- v2v/output_rhv_upload.ml

The main reason for creating different OVF is that it can be used to create VM by oVirt REST API. The RHV export domain flavor cannot be used that way. v1 -> v2: - introduced flavour types instead of booleans - instead of referring to the new flavour as "standard OVF" or "fixed OVF" I refer to it as oVirt flavour. While it is more conforming than the one used in export

The main reason for creating different OVF is that it can be used to create VM by oVirt REST API. The RHV export domain flavor cannot be used that way. Tomáš Golembiovský (3): v2v: tests: check generated OVF v2v: ovf: Create OVF more aligned with the standard v2v: vdsm: add --vdsm-fixed-ovf option v2v/cmdline.ml | 5 ++ v2v/create_ovf.ml

This is just a bit of preparatory refactoring ... Rich.

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.

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.

The first two patches implement the change discussed here: https://www.redhat.com/archives/libguestfs/2016-April/msg00178.html The third patch fixes the mapping of inspection data to OVF VmType which was inherited directly from old virt-v2v and had never been changed. It had a number of problems. The fourth patch is only slightly related to the others. It adds an extra slow test to ensure that

On Friday, 12 October 2018 15:02:31 CEST Richard W.M. Jones wrote: > On Wed, Oct 10, 2018 at 07:25:48PM +0200, Tomáš Golembiovský wrote: > > changes in v2: > > - split patch in two > > - changed as per suggestions > > > > Tomáš Golembiovský (2): > > v2v: ovf: add firmware and machine type element > > v2v: enable UEFI for oVirt/RHV outputs > >

v6 was here: https://www.redhat.com/archives/libguestfs/2018-March/msg00126.html This makes a number of significant changes: - Input and output options now use a uniform set of -io and -oo parameters. - For -o rhv-upload, we use ‘-oo rhv-cafile=/tmp/ca.pem’ etc. The ‘--rhv*’ options have been dropped. - Rearranges the documentation. - As before includes (untested) support for zero,

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

Previous versions: v3: https://www.redhat.com/archives/libguestfs/2018-March/msg00000.html v2: https://www.redhat.com/archives/libguestfs/2018-February/msg00177.html v1: https://www.redhat.com/archives/libguestfs/2018-February/msg00139.html This completely rethinks the approach taken by the previous patches. Instead of trying to involve qemu's curl driver, this uses a small Python 3

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.

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

This patch isn't quite complete (see ‘assert false’). Currently we have a bunch of ad hoc options like --vddk* and --vdsm* (and proposed to add --rhv*) to handle extra parameters for input and output modes/transports. This complicates the command line parsing and also the clarity of the command line (becauseit's not very obvious which options apply to which side of the conversion).

On Tue, Oct 16, 2018 at 02:06:06PM +0200, Tomáš Golembiovský wrote: > On Fri, 12 Oct 2018 17:54:39 +0200 > Pino Toscano <ptoscano@redhat.com> wrote: > > > On Friday, 12 October 2018 15:02:31 CEST Richard W.M. Jones wrote: > > > On Wed, Oct 10, 2018 at 07:25:48PM +0200, Tomáš Golembiovský wrote: > > > > changes in v2: > > > > - split patch in

v2: - Fix virt-p2v messages too. 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

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,

This changes the infrastructure to allow the target_file to be a QEMU URI. Rich.

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