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

v5: - Normal output modified approx as suggested in previous email. - Machine readable output uses JSON.

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

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.

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

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.

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

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): > >

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

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.

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 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

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.

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

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.