similar to: [PATCH] v2v: Use Std_utils.qemu_input_filename instead of prefixing "file:" to filename (RHBZ#1580292).

All the current output modes use the default, It's just that I have a patch that uses this, so there might be someone in the future who wants to use this and if not, then at least you can tell me if this is wrong or not. Signed-off-by: Martin Kletzander <mkletzan@redhat.com> --- v2v/types.ml | 15 +++++++++++++++ v2v/types.mli | 8 +++++++- v2v/v2v.ml | 17 +++-------------- 3

On Tue, Sep 1, 2020 at 4:56 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > We previously implicitly supported writing to block devices instead of > local files, but there were several problems: > > * Block devices could be deleted, especially if virt-v2v failed during > a conversion. > > * Block devices could be overwritten by a file with the same name, >

We previously implicitly supported writing to block devices instead of local files, but there were several problems: * Block devices could be deleted, especially if virt-v2v failed during a conversion. * Block devices could be overwritten by a file with the same name, although I believe this is just an observed consequence of the previous point, or at least I was not able to reproduce this

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, Sep 01, 2020 at 07:37:42PM +0100, Richard W.M. Jones wrote: > On Tue, Sep 01, 2020 at 08:55:38PM +0300, Nir Soffer wrote: > ... > > > Note this commit intentionally does not prevent you from writing qcow2 > > > to a block device. RHV uses this so it is a thing that people do. > ... > > > +Note that you must create block devices of the correct size, and

On Tue, Sep 01, 2020 at 08:55:38PM +0300, Nir Soffer wrote: ... > > Note this commit intentionally does not prevent you from writing qcow2 > > to a block device. RHV uses this so it is a thing that people do. ... > > +Note that you must create block devices of the correct size, and you > > +need to use I<-of raw> since other output formats would not normally >

This changes the infrastructure to allow the target_file to be a QEMU URI. Rich.

Hai Mourik Jan, ? This is the script we use, this is the work my collega. ( see the developed by, thats his company?) This is a "as is"? share, so read the code, we added as much as possible info in there. ? Few extra pointers, - speed up the script by useing ramdisk, make sure your ramdisk has the space for the bigest pdf you want to create. ??? we did limit the max size in the

The main purpose of this change is two-fold: (1) Ensure that we run the same version of qemu-img that we are built against. (2) Allow the qemu-img path to be overridden at build time in case it's on a nonstandard path or (like RHV) has a nonstandard name. --- docs/guestfs-building.pod | 6 ++++++ lib/command.c | 4 ++-- lib/create.c | 4 ++-- lib/info.c

On Tue, Sep 1, 2020 at 9:42 PM Richard W.M. Jones <rjones@redhat.com> wrote: > > On Tue, Sep 01, 2020 at 07:37:42PM +0100, Richard W.M. Jones wrote: > > On Tue, Sep 01, 2020 at 08:55:38PM +0300, Nir Soffer wrote: > > ... > > > > Note this commit intentionally does not prevent you from writing qcow2 > > > > to a block device. RHV uses this so it is a

On Mon, Nov 25, 2019, 11:15 Richard W.M. Jones <rjones@redhat.com> wrote: > On Wed, Nov 20, 2019 at 03:06:55AM +0200, Nir Soffer wrote: > > diff --git a/v2v/v2v.ml b/v2v/v2v.ml > > index 03590c9e..58bb06c3 100644 > > --- a/v2v/v2v.ml > > +++ b/v2v/v2v.ml > > @@ -739,7 +739,9 @@ and copy_targets cmdline targets input output = > > | TargetURI

On Wed, Nov 20, 2019 at 03:06:55AM +0200, Nir Soffer wrote: > diff --git a/v2v/v2v.ml b/v2v/v2v.ml > index 03590c9e..58bb06c3 100644 > --- a/v2v/v2v.ml > +++ b/v2v/v2v.ml > @@ -739,7 +739,9 @@ and copy_targets cmdline targets input output = > | TargetURI uri -> uri in > [ "qemu-img"; "convert" ] @ > (if not (quiet ()) then

On Mon, Nov 25, 2019 at 04:27:11PM +0200, Nir Soffer wrote: > On Mon, Nov 25, 2019, 11:15 Richard W.M. Jones <rjones@redhat.com> wrote: > > > On Wed, Nov 20, 2019 at 03:06:55AM +0200, Nir Soffer wrote: > > > diff --git a/v2v/v2v.ml b/v2v/v2v.ml > > > index 03590c9e..58bb06c3 100644 > > > --- a/v2v/v2v.ml > > > +++ b/v2v/v2v.ml > > >

When using oVirt >= 4.3, we can enable the NBD based backend in imageio by specifying that we transfer raw data when creating a transfer. With the NBD backend, we can specify qcow2 disk format. I think we need a way to expose the capabilities of the output to the user. For example, can we use qcow2 format. Issues: - I hacked qemu-img convert command line to always use -O raw instead of

Commit 4699c7b6e126e07c95b67fb95df58aed87a680dd converted the null output to use the null-co qemu driver with a JSON URL syntax -- especially the latter is only available in newer versions of qemu. Even if this output mode is mostly for testing, check at runtime whether the null-co + JSON way is possible, falling back to the creation of thrown-away temporary files as before. ---

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

Add a simple helper to run a command from a sequence of arguments, without using a shell: this should help reducing the amount of quoting ineeded, since arguments are passed straight as such. Make use of it in the places currently using shell_command, and which don't assume they can run anything (so no shell redirections, `env`, etc). --- builder/builder.ml | 62

It mimics a bit in OCaml the logic used in commit a95214b1985e694946e3426120a6fdc13a3f081f (for the main library) and commit 588af1953e5f7ab74009b9175cc5d3efb8bb651a (in disk-create), so in OCaml tools direct calls to qemu/qemu-img with filenames provided by the user can properly handle filenames with e.g. ':'. --- mllib/common_utils.ml | 13 +++++++++++++ mllib/common_utils.mli | 8

With commit a594b7f90a682e2a9327b142138edb76ad8ba8ff the checks for input and output files with ':' were removed; while the input file is handled correctly by the disk_create API, an output filename with ':' could still be handled as specifying a transport, failing the last "qemu-img convert" call. Use the new qemu_input_filename helper to handle the output filename

Small function to create in OCaml-based code a directory and its parents, much like `mkdir -p`. --- mllib/common_utils.ml | 11 +++++++++++ mllib/common_utils.mli | 3 +++ 2 files changed, 14 insertions(+) diff --git a/mllib/common_utils.ml b/mllib/common_utils.ml index 898be17..76d8b79 100644 --- a/mllib/common_utils.ml +++ b/mllib/common_utils.ml @@ -673,3 +673,14 @@ let qemu_input_filename