search for: do_copi

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

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

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

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.

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

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

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.

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

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

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 =

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

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 series is an attempt to add a mode of virt-v2v operation where it leaves the config and disk image conversion, rollback on errors, registering with the destination hypervisor, etc. to a third-party toolset, and performs only tuning of the guest OS to run in the KVM-based hypervisor. Roman Kagan (3): v2v: add --in-place mode v2v: document --in-place v2v: add test for --in-place ---

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

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

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

All callers of robust_rename() call copy_file() if EXDEV is received. This patch moves the copy_file() call into robust_rename(). Patch Summary: -12 +1 backup.c -15 +2 rsync.c -9 +33 util.c -------------- next part -------------- patchwork diff util.c --- util.c 2004-02-17 09:58:44.000000000 -0500 +++ util.c 2004-02-17 10:21:22.000000000 -0500 @@ -355,16 +355,40 @@

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