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

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

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

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

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

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

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

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.

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 =

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

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

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

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

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

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

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

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