search for: output_allocation

When converting and throwing away the output (-o null), the input format should not really matter. However it does currently matter for a couple of reasons: (1) If the input is not raw or qcow2, then you'll get the error below because virt-v2v wants to write the same output format as input format but only allows raw or qcow2 as output formats: virt-v2v: error: output format should be

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

...v2v/create_ovf.mli +++ b/v2v/create_ovf.mli @@ -25,7 +25,7 @@ create OVF for another target management system then we would need to heavily modify or even duplicate this code. *) -val create_ovf : Types.source -> Types.target list -> Types.guestcaps -> Types.inspect -> Types.output_allocation -> string -> string list -> string list -> string -> DOM.doc +val create_ovf : Types.source -> Types.target list -> Types.guestcaps -> Types.inspect -> Types.output_allocation -> string -> string list -> string list -> string -> bool -> DOM.doc (** Cre...

I'm interested to hear opinions on whether this makes the code clearer, or not. This is virt-v2v, but many other virt-* tools work the same way, and analogous changes could be made. Currently when command line argument parsing is done in 'cmdline.ml' the list of parsed parameters is passed to the main program in a very long tuple. Each parameter is strongly typed, but not named (so

...+43,7 @@ val ovf_flavour_to_string : ovf_flavour -> string create OVF for another target management system then we would need to heavily modify or even duplicate this code. *) -val create_ovf : Types.source -> Types.target list -> Types.guestcaps -> Types.inspect -> Types.output_allocation -> string -> string list -> string list -> string -> ovf_flavour -> DOM.doc +val create_ovf : Types.source -> Types.target list -> Types.guestcaps -> Types.inspect -> Types.target_firmware -> Types.output_allocation -> string -> string list -> string list...

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

--- v2v/cmdline.ml | 5 ++++- v2v/v2v.ml | 21 ++++++++++++++------- v2v/virt-v2v.pod | 6 ++++++ 3 files changed, 24 insertions(+), 8 deletions(-) diff --git a/v2v/cmdline.ml b/v2v/cmdline.ml index d4bddce..f6e75ce 100644 --- a/v2v/cmdline.ml +++ b/v2v/cmdline.ml @@ -27,6 +27,7 @@ open Types open Utils let parse_cmdline () = + let compressed = ref false in let debug_overlays =

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 v2v/create_ovf.ml | 12 +++++++++++- v2v/create_ovf.mli | 2 +- v2v/output_rhv.ml | 6 ++---- v2v/output_rhv_upload.ml | 4 ++--

...etails. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + *) + +(** [-o rhv-upload] target. *) + +val output_rhv_upload : Types.output_allocation -> string -> string -> + string -> + Types.output +(** [output_rhv_upload output_alloc output_conn output_password output_storage] + creates and returns a new {!Types.output} object specialized for writing + output to oVirt or RHV dire...

This change (mostly) has no effect, except I changed the content of two error messages to make them consistent with the others. --- v2v/cmdline.ml | 33 +++++++++++++++++++-------------- 1 file changed, 19 insertions(+), 14 deletions(-) diff --git a/v2v/cmdline.ml b/v2v/cmdline.ml index a72aa49..c294e57 100644 --- a/v2v/cmdline.ml +++ b/v2v/cmdline.ml @@ -334,6 +334,11 @@ read the man page

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.

This adds --print-target. In addition, v2 provides a machine-readable version (in JSON format). All of the record -> JSON boilerplate in this patch could be eliminated if we moved the baseline to OCaml 4.02. Rich.

...etails. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + *) + +(** [-o rhv-upload] target. *) + +val output_rhv_upload : Types.output_allocation -> string -> string -> + string -> string -> bool -> + Types.output +(** [output_rhv_upload output_alloc output_conn output_password output_storage + rhv_cafile rhv_direct] + creates and returns a new {!Types.output} object spec...

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

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

...eived a copy of the GNU General Public License along > + * with this program; if not, write to the Free Software Foundation, Inc., > + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. > + *) > + > +(** [-o rhv-upload] target. *) > + > +val output_rhv_upload : Types.output_allocation -> string -> string -> > + string -> > + Types.output > +(** [output_rhv_upload output_alloc output_conn output_password output_storage] > + creates and returns a new {!Types.output} object specialized for writing > + ou...

...\ diff --git a/v2v/cmdline.ml b/v2v/cmdline.ml index 5b2df3555..74cc27714 100644 --- a/v2v/cmdline.ml +++ b/v2v/cmdline.ml @@ -33,10 +33,12 @@ type cmdline = { debug_overlays : bool; do_copy : bool; in_place : bool; + machine_readable : bool; network_map : Networks.t; output_alloc : output_allocation; output_format : string option; output_name : string option; + print_estimate : bool; print_source : bool; root_choice : root_choice; } @@ -49,6 +51,7 @@ let parse_cmdline () = let debug_overlays = ref false in let do_copy = ref true in let machine_readable = ref false in +...

See: https://forge.ocamlcore.org/docman/view.php/77/112/leroy-cug2010.pdf --- v2v/cmdline.ml | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/v2v/cmdline.ml b/v2v/cmdline.ml index 6aba4afb5..fdd0f2614 100644 --- a/v2v/cmdline.ml +++ b/v2v/cmdline.ml @@ -627,11 +627,9 @@ read the man page virt-v2v(1). output_format, output_alloc in { - compressed =

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

...t;http://en.wikipedia.org/wiki/Byte"; (* wtf? *) "ovf:disk-interface", (match guestcaps.gcaps_block_bus with diff --git a/v2v/OVF.mli b/v2v/OVF.mli index 3b260a5..89b96da 100644 --- a/v2v/OVF.mli +++ b/v2v/OVF.mli @@ -21,7 +21,7 @@ val create_meta_files : Types.output_allocation -> string -> string list -> Types.target list -> string list (** Create the .meta file associated with each target. - Note this does not write them, since output_rhev has to do a + Note this does not write them, since output_rhv has to do a permissions dance when writing f...