This failed for me:

$ ./run virt-v2v -ic xen+ssh://root.224.33 xen-hvm-rhel7.8-x86_64 -o null
[   0.0] Opening the source -i libvirt -ic xen+ssh://root.224.33 xen-hvm-rhel7.8-x86_64
The authenticity of host '10.73.224.33 (10.73.224.33)' can't be established.
RSA key fingerprint is SHA256:EUNB9K3dP6Dzl4VGuy5EScDKm6XIMysvJVEWV56bYY0.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
root.224.33's password: 
[  20.5] Creating an overlay to protect the source from being modified
nbdkit: ssh[1]: error: all possible authentication methods failed
qemu-img: /home/rjones/d/virt-v2v/tmp/v2vovla8866e.qcow2: Requested export not available
Could not open backing image.

It's possible I had the wrong password?

Could you attach the full log file please?

Created attachment 1777119 [details]
xen-conversion.log

The following analysis is based on upstream v1.42 (the report is against
"virt-v2v-1.42.0-6.module+el8.4.0+8855+a9e237a9.x86_64"):

In the "create_overlays" function [v2v/v2v.ml] we invoke qemu-img like
this:

>   List.mapi (
>     fun i ({ s_qemu_uri = qemu_uri; s_format = format } as source) ->
> ...
>       let options =
>         "compat=1.1" ^
>           (match format with None -> ""
>                            | Some fmt -> ",backing_fmt=" ^ fmt) in
>       let cmd = [ "qemu-img"; "create"; "-q"; "-f"; "qcow2"; "-b"; qemu_uri;
>                   "-o"; options; overlay_file ] in
> ...
>   ) source_disks

meaning that the "backing_fmt" option is passed to qemu-img if and only
if the "s_format" field in the source disk is not None.

The log from comment 2 contains:

> qemu-img 'create' '-q' '-f' 'qcow2' '-b' 'nbd:unix:/tmp/v2vnbdkit.QA8zDc/nbdkit1.sock:exportname=/' '-o' 'compat=1.1' '/var/tmp/v2vovleb01ae.qcow2'

meaning that "s_format" is None in this particular case.

The source disks come from "v2v/input_libvirt_xen_ssh.ml":

>     let source, disks, _ = parse_libvirt_domain ?bandwidth self#conn guest in
> ...
>     (* Map the <source/> filename (which is relative to the remote
>      * Xen server) to an ssh URI pointing to nbdkit.
>      *)
>     let disks = List.map (
>       function
>       | { p_source_disk = disk; p_source = P_dont_rewrite } ->
>         disk
>       | { p_source_disk = disk; p_source = P_source_dev path }
>       | { p_source_disk = disk; p_source = P_source_file path } ->
>          let password =
>            match input_password with
>            | None -> Nbdkit_sources.NoPassword
>            | Some ip -> Nbdkit_sources.PasswordFile ip in
>          let nbdkit = Nbdkit_sources.create_ssh ?bandwidth ~password
>                                         ?port ~server ?user path in
>          let qemu_uri = Nbdkit_sources.run nbdkit in
>         { disk with s_qemu_uri = qemu_uri }
>     ) disks in
>
>     source, disks

wherein "s_format" is not modified, only propagated outwards from
"parse_libvirt_domain".

In "parse_libvirt_domain" [v2v/parse_libvirt_xml.ml], the format is
determined by:

>       let format =
>         match xpath_string "driver/@type" with
>         | Some "aio" -> Some "raw" (* Xen wierdness *)
>         | None -> None
>         | Some format -> Some format in

Now consider the source domain XML from comment 2 again:

>     <disk type='file' device='disk'>
>       <driver name='file'/>
>       <source file='/var/lib/xen/images/xen-hvm-rhel7.8-x86_64.img'/>
>       <target dev='hda' bus='ide'/>
>     </disk>

There is no "driver/@type" attribute. So that's the reason virt-v2v does
not pass a backing file format to qemu-img. Because libvirt does not
tell us the source format, we can only rely on qemu-img detecting the
format. There's nothing virt-v2v can do about this.

I'm going to agree and disagree on this one.

I don't think it's a current bug.  The code has completely changed in RHEL 9,
and in RHEL 8 as long as it's just a warning (not a hard fail) then I'm not
too bothered about fixing bugs there.

But there is something virt-v2v *could* do here, which is to autodetect
the format (using g#disk_format), which is basically the same as what qemu
is warning about doing.

Having said that, aren't Xen images always raw?  Does it ever use qcow2 or
another format?

Now regarding the current (modular) status:

- In commit 255722cbf39a ("v2v: Modular virt-v2v", 2021-09-07), the "s_format" field was eliminated altogether.

- Since the modularization, we don't use qemu-img for creating the protective overlay. Instead (for all conversions that are not "in-place"), we set the "read_only" input-option to true [v2v/v2v.ml], then

- in "input/input_xen_ssh.ml" (which enforces "read_only"), we create an nbdkit instance for each "LocalFile" input disk, through "Nbdkit_ssh.create_ssh",

- in "create_ssh" [input/nbdkit_ssh.ml], we implement the protective layer with the "cow" filter of nbdkit:

>   (* IMPORTANT! Add the COW filter.  It must be furthest away
>    * except for the rate filter.
>    *)
>   Nbdkit.add_filter cmd "cow";

So the reported problem is eliminated as a by-product of the modularization.

(In reply to Richard W.M. Jones from comment #6)
> I'm going to agree and disagree on this one.
> 
> I don't think it's a current bug.

I wrote up my analysis first for the *reported version* (as I stated at
the very top of comment 5), and then I started the analysis for the
*current version*. That's my comment 7. Your comment 6 caught me between
the two. :)

> The code has completely changed in RHEL 9, and in RHEL 8 as long as
> it's just a warning (not a hard fail) then I'm not too bothered about
> fixing bugs there.
> 
> But there is something virt-v2v *could* do here, which is to
> autodetect the format (using g#disk_format), which is basically the
> same as what qemu is warning about doing.

Ah, I didn't know that. So yes, regarding the "reported version", this
should be viable -- but it does not matter any longer.

> Having said that, aren't Xen images always raw?  Does it ever use
> qcow2 or another format?

I don't have the slightest idea -- but whatever the image format is,
libvirt should most probably report it.

Anyway, do you agree that we can close this as CURRENTRELEASE?
("Product" is RHEL9 on this ticket.) Thanks.

Yes, closing it is correct, thanks.