Bug 1904946
Summary: | virt-v2v from xen doesn't set backing format: qemu-img: warning: Deprecated use of backing file without explicit backing format (detected format of raw) | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 9 | Reporter: | liuzi <zili> | ||||
Component: | virt-v2v | Assignee: | Virtualization Maintenance <virt-maint> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | unspecified | CC: | juzhou, lersek, mxie, ptoscano, rjones, tyan, tzheng, xiaodwan | ||||
Target Milestone: | beta | Keywords: | Triaged | ||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | V2V | ||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2022-05-26 11:58:32 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
liuzi
2020-12-07 07:25:44 UTC
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. |