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

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

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