similar to: [PATCH v5] v2v: Add --print-estimate option to print copy size estimate.

v4: - Same as v3, but depends on and uses new --machine-readable work. Rich.

v6: - Make the text output a bit nicer. - Changes as suggested to Measure_disk module temp file & json parsing. - Use jq to test JSON output. - Retest.

I rethought this again, as I think that it's a dangerous assumption to bake qemu-img measure output into our API. This patch series runs qemu-img measure behind the scenes, but then parses the output and sums it to a single number which we print. Doing that required a bit of reworking, moving the Jansson [JSON parser] bindings from virt-builder into the common directory and a couple of other

This option prints the estimated size of the data that will be copied from the source disk. For interest, the test prints: 3747840 ../test-data/phony-guests/windows.img Estimate: 3710976 --- v2v/Makefile.am | 2 ++ v2v/cmdline.ml | 17 ++++++++++-- v2v/cmdline.mli | 2 ++ v2v/test-v2v-print-estimate.sh | 47 +++++++++++++++++++++++++++++++++

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.

Patch v2 was here: https://www.redhat.com/archives/libguestfs/2019-April/thread.html#00114 There's no change here except that I've rebased it against the latest master branch and retested. There was a comment by Pino (https://www.redhat.com/archives/libguestfs/2019-April/msg00117.html) which isn't incorporated into this patch. Rich.

RHV was connecting to the VMware source in order to find out the virtual disk size of the source disk(s), duplicating logic that virt-v2v already provides. This makes that information available using a new ‘virt-v2v --print-target option’. Note in order to get all the information, this has to actually perform the conversion step, so it takes 30 seconds or so before we reach the point where the

Essentially identical to v1 except that it now uses (overloads?) the --mac option to supply this data. Rich.

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

On Thu, 15 Mar 2018 17:37:46 +0000 "Richard W.M. Jones" <rjones@redhat.com> wrote: > This is analogous to --print-source, except that it prints the overlay > and target disk information. > > The output looks like below. Note there is one overlay and one target > section per disk. > > Overlay and Target information (--print-target option): > >

Since this new temporary directory will contain UNIX sockets for communicating with nbdkit, then its path must not be too long. Use the existing directory that libguestfs exposes for this, i.e. sockdir. --- v2v/nbdkit.ml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/v2v/nbdkit.ml b/v2v/nbdkit.ml index 65317f9b..46b20c9d 100644 --- a/v2v/nbdkit.ml +++ b/v2v/nbdkit.ml

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 option prints the estimated size of the data that will be copied from the source disk. Currently this overestimates by the size of the qcow2 header, but for real disk images that doesn't matter much. For example: $ virt-builder fedora-27 $ virt-v2v -i disk fedora-27.img -o null --print-estimate [...] virt-v2v: This guest has virtio drivers installed. [ 44.0] Mapping filesystem data to

This option prints the estimated size of the data that will be copied from the source disk. Currently this overestimates by the size of the qcow2 header, but for real disk images that doesn't matter much. For example: $ virt-builder fedora-27 $ virt-v2v -i disk fedora-27.img -o null --print-estimate [...] virt-v2v: This guest has virtio drivers installed. [ 44.0] Mapping filesystem data to

v3: Change the flag from --vdsm-compat-11 to --vdsm-compat=1.1 Also the --machine-readable output has changed. I have also added a test. Rich.

This option prints the estimated size of the data that will be copied from the source disk. Currently this overestimates by the size of the qcow2 header, but for real disk images that doesn't matter much. For example: $ virt-builder fedora-27 $ virt-v2v -i disk fedora-27.img -o null --print-estimate [...] virt-v2v: This guest has virtio drivers installed. [ 44.0] Mapping filesystem data to

This option prints the estimated size of the data that will be copied from the source disk. Currently this overestimates by the size of the qcow2 header, but for real disk images that doesn't matter much. For example: $ virt-builder fedora-27 $ virt-v2v -i disk fedora-27.img -o null --print-estimate [...] virt-v2v: This guest has virtio drivers installed. [ 44.0] Mapping filesystem data to

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

This is built on top of the following patch series: https://www.redhat.com/archives/libguestfs/2019-April/msg00054.html Rich.

--- v2v/windows.ml | 24 ++++++++++++++++++++++++ v2v/windows.mli | 6 ++++++ 2 files changed, 30 insertions(+) diff --git a/v2v/windows.ml b/v2v/windows.ml index 23d589b00..dde64e677 100644 --- a/v2v/windows.ml +++ b/v2v/windows.ml @@ -19,6 +19,7 @@ open Printf open Common_gettext.Gettext +open Std_utils open Tools_utils open Utils @@ -45,3 +46,26 @@ and check_app { Guestfs.app2_name