On Tue, Sep 1, 2020 at 9:42 PM Richard W.M. Jones <rjones(a)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 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
This works, we also do this with file and block devices in most cases.
I was confused by:
> > > + (* 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
I guess you don't create qcow2 image without qemu-img?
> 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
This does not work for qcow2, since -n disable creation of the image.
The actual command uses -O format so the format is set correctly in
this case.
If -n is specified, qemu-img assumes that the target is already in qcow2 format.
If not, it will fail with:
qemu-img: Could not open '/dev/loop0': Image is not in qcow2 format
But if you remove -n, convert will create the qcow2 header in the target.
There are some cases when using -n is bad, see here:
https://github.com/oVirt/vdsm/commit/2bbe66274524cc009f39d3a5e5577b84144f...
Rich.
> 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/
>
> _______________________________________________
> Libguestfs mailing list
> Libguestfs(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/libguestfs
--
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/