[Libguestfs] [PATCH v2v] v2v: Allow output to block devices (RHBZ#1868690).

Richard W.M. Jones rjones at redhat.com
Tue Sep 1 18:37:42 UTC 2020


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
> > +make sense on a block device.
> 
> qcow2 on block device is useful normally, for example for supporting
> incremental backup of the disk. Also using qcow2 avoids the horrible issue
> of lvm on the host activating logical volumes inside the block device while
> the guest is using the devices.
> 
> So the statement "would not normally make sense" is too extreme.
>
> Maybe something like:
> 
>     Typically l<of raw> is used for block devices but other formats such as
>     qcow2 can be useful in some cases.

Sure, I will adjust this.  I knew that RHV was using it.

> > @@ -713,27 +716,33 @@ and copy_targets cmdline targets input output =
> >
> >        (match t.target_file with
> >         | TargetFile filename ->
> > -          (* It turns out that libguestfs's disk creation code is
> > -           * considerably more flexible and easier to use than
> > -           * qemu-img, so create the disk explicitly using libguestfs
> > -           * then pass the 'qemu-img convert -n' option so qemu reuses
> > -           * the disk.
> > -           *
> > -           * Also we allow the output mode to actually create the disk
> > -           * image.  This lets the output mode set ownership and
> > -           * permissions correctly if required.
> > +          (* As a special case, allow output to a block device or
> > +           * symlink to a block device.  In this case we don't
> > +           * create/overwrite the block device.  (RHBZ#1868690).
> >             *)
> > -          (* What output preallocation mode should we use? *)
> > -          let preallocation =
> > -            match t.target_format, cmdline.output_alloc with
> > -            | ("raw"|"qcow2"), Sparse -> Some "sparse"
> > -            | ("raw"|"qcow2"), Preallocated -> Some "full"
> > -            | _ -> None (* ignore -oa flag for other formats *) in
> > -          let compat =
> > -            match t.target_format with "qcow2" -> Some "1.1" | _ -> None in
> > -          output#disk_create filename t.target_format
> > -                             t.target_overlay.ov_virtual_size
> > -                             ?preallocation ?compat
> > +          if not (is_block_device filename) then (
> > +            (* It turns out that libguestfs's disk creation code is
> > +             * considerably more flexible and easier to use than
> > +             * qemu-img, so create the disk explicitly using libguestfs
> > +             * then pass the 'qemu-img convert -n' option so qemu reuses
> > +             * the disk.
> 
> How would -n work if you want to create qcow2 format?

I'm completely sure what the question means, but virt-v2v currently
does this:

  qemu-img create -f FORMAT filename
  qemu-img convert -n overlay filename

The new code doesn't change that for files, but the proposal does
change it for devices to only this command:

  qemu-img convert -n overlay device

I don't think that the format makes any difference AFAIK.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/




More information about the Libguestfs mailing list