similar to: [PATCH] v2v: Add --compressed option to produce compressed qcow2 files (RHBZ#1279273).

In this mode, converting of the VM configuration, setting up the rollback path for error cases, transforming the VM storage and so on is taken care of by a third-party toolset, and virt-v2v is only supposed to tune up the guest OS directly inside the source VM, to enable it to boot and run under the input hypervisor. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/cmdline.ml | 7

On Thu, Aug 27, 2015 at 09:39:30PM +0300, Roman Kagan wrote: > On Thu, Aug 27, 2015 at 04:08:43PM +0100, Richard W.M. Jones wrote: > > On Tue, Aug 11, 2015 at 08:00:34PM +0300, Roman Kagan wrote: > > > + let overlays = > > > + if not in_place then create_overlays source.s_disks > > > + else [] in > > > + let targets = > > > + if not

In this mode, converting of the VM configuration, setting up the rollback path for error cases, transforming the VM storage and so on is taken care of by a third-party toolset, and virt-v2v is only supposed to tune up the guest OS directly inside the source VM, to enable it to boot and run under the input hypervisor. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- changes from v1: -

Several tools handle --debug-gc command-line option, by explicitly forcing GC on every exit path. This is tedious and prone to forgetting some of the exit paths. Instead, add a generic handler for --debug-gc, which installs an at_exit hook to do the GC consistency check, and which can be called right in the command-line parser. Also adjust all users of --debug-gc to use that handler.

Besides, it doesn't need guestfs handle open so move this step earlier in the process. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/v2v.ml | 73 ++++++++++++++++++++++++++++++++------------------------------ 1 file changed, 38 insertions(+), 35 deletions(-) diff --git a/v2v/v2v.ml b/v2v/v2v.ml index b3dfa07..c20cbf0 100644 --- a/v2v/v2v.ml +++ b/v2v/v2v.ml @@ -144,40

--- v2v/Makefile.am | 3 +- v2v/cmdline.ml | 31 ++++++++++++++------ v2v/cmdline.mli | 16 ++++++++++- v2v/test-v2v-bad-networks-and-bridges.sh | 49 ++++++++++++++++++++++++++++++++ v2v/v2v.ml | 4 +-- 5 files changed, 91 insertions(+), 12 deletions(-) create mode 100755

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 =

Opening the source VM and amending the properties in its internal representation in accordance with command-line options fit nicely into two isolated functions. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> --- v2v/v2v.ml | 71 +++++++++++++++++++++++++++++++++----------------------------- 1 file changed, 38 insertions(+), 33 deletions(-) diff --git a/v2v/v2v.ml b/v2v/v2v.ml index

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 --machine-readable --print-estimate [...] virt-v2v: This guest has virtio drivers installed. [ 44.0] Mapping

On Tue, Aug 14, 2018 at 8:29 PM Richard W.M. Jones <rjones@redhat.com> wrote: > 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 > Why not use qemu-img measure on the overlay? It gives a conservative estimate that

On Mon, Jul 27, 2015 at 07:29:57PM +0300, Roman Kagan wrote: > In this mode, converting of the VM configuration, setting up the > rollback path for error cases, transforming the VM storage and so on is > taken care of by a third-party toolset, and virt-v2v is only supposed to > tune up the guest OS directly inside the source VM, to enable it to boot > and run under the input

For Linux the guest itself remembers the IP address associated with each MAC address. Thus it doesn't matter if the interface type changes (ie. to virtio-net), because as long as we preserve the MAC address the guest will use the same IP address or the same DHCP configuration. However on Windows this association is not maintained by MAC address. In fact the MAC address isn't saved

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 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): overlay file: /home/rjones/d/libguestfs/tmp/v2vovlc687fe.qcow2 overlay device name: sda overlay virtual disk size: 6442450944

On Tue, Aug 11, 2015 at 08:00:34PM +0300, Roman Kagan wrote: > + let overlays = > + if not in_place then create_overlays source.s_disks > + else [] in > + let targets = > + if not in_place then init_targets overlays source output output_format > + else [] in This doesn't solve the problem I raised before which is that overlays and targets should never be empty

In this mode, converting of the VM configuration, setting up the rollback path for error cases, transforming the VM storage and so on is taken care of by a third-party toolset, and virt-v2v is only supposed to tune up the guest OS directly inside the source VM, to enable it to boot and run under the input hypervisor. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> ---

Use Getopt.Symbol for options with a fixed list of choices, so there is no need to check them on our own. --- v2v/cmdline.ml | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/v2v/cmdline.ml b/v2v/cmdline.ml index 2d0a10a..96e0509 100644 --- a/v2v/cmdline.ml +++ b/v2v/cmdline.ml @@ -83,8 +83,7 @@ let parse_cmdline () = | "libvirt" -> input_mode

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

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

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