Bug 1588373
Summary: | assuming backing store type to raw if not specified can lead to failures | ||
---|---|---|---|
Product: | [Community] Virtualization Tools | Reporter: | Xensemann <xensemann> |
Component: | libvirt | Assignee: | Peter Krempa <pkrempa> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | ben, ildar.mulyukov, libvirt-maint, pkrempa |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-12-18 08:40:11 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: |
Description
Xensemann
2018-06-07 07:52:29 UTC
When I'm wrapping all the images together with rebase '', then it is working. It does not matter if all the overlays are empty or full of usefull informationes. It still does not work. You've created the images without specifying backing format (using the -F switch for qemu-img). That way libvirt refuses to look for the backing image of Roof.ovl as it treats the backing image as 'raw' due to security implications. This means that libvirt then does not use the correct security label for anything below Roof.ovl. Specifying the backing file format using -F should fix your problem. it did it! thx so much! qemu-img create -f qcow2 Base.img 50G qemu-img create -f qcow2 -F qcow2 -b Base.img FirstFloor.ovl qemu-img create -f qcow2 -F qcow2 -b FirstFloor.ovl SecondFloor.ovl qemu-img create -f qcow2 -F qcow2 -b SecondFloor.ovl Roof.ovl => Working! --- But can you tell me how I could figure it out by running a general test? Backingchain is showing noting suspicious. Would it be an idea to make the error message around this topic a bit more user friendly? image: Roof.ovl file format: qcow2 virtual size: 50G (53687091200 bytes) disk size: 196K cluster_size: 65536 backing file: SecondFloor.ovl Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false image: SecondFloor.ovl file format: qcow2 virtual size: 50G (53687091200 bytes) disk size: 196K cluster_size: 65536 backing file: FirstFloor.ovl Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false image: FirstFloor.ovl file format: qcow2 virtual size: 50G (53687091200 bytes) disk size: 196K cluster_size: 65536 backing file: Base.img Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false image: Base.img file format: qcow2 virtual size: 50G (53687091200 bytes) disk size: 196K cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false Well, that's kind of hard to do. The error you've seen is reported by qemu. Due to historical reasons we do not consider this a failure if a backing file does not have the format specified. On the other hand. It probably will become a failure scenario when using -blockdev as if we force the type to 'raw' in the backing chain, qemu will complain loudly. I'll keep this open with a new summary and assign it to myself since I'm working on the -blockdev integration Thank you for your support! --- for everybody else finding this post. To resolve already existing issues with existing images you can do this: qemu-img rebase -f qcow2 -b Base.img -F qcow2 FirstFloor.ovl qemu-img rebase -f qcow2 -b FirstFloor.ovl -F qcow2 SecondFloor.ovl qemu-img rebase -f qcow2 -b SecondFloor.ovl -F qcow2 Roof.ovl Upstream fixes that by reporting an error if the format is not recorded in the image. Additionally a document is added on how to fix the images. commit 5949ac0f59b791a7677645360586c7c2a7be6cec Author: Peter Krempa <pkrempa> Date: Tue Dec 17 18:50:18 2019 +0100 kbase: Add document outlining backing chain XML config and troubleshooting Signed-off-by: Peter Krempa <pkrempa> Reviewed-by: Michal Privoznik <mprivozn> commit 3615e8b39badf2a526996a69dc91a92b04cf262e Author: Peter Krempa <pkrempa> Date: Tue Dec 17 17:04:04 2019 +0100 util: storage: Don't treat files with missing backing store format as 'raw' Assuming that the backing image format is raw is wrong when doing image detection: 1) In -drive mode qemu will still probe the image format of the backing image. This means it will try to open a backing file of the image which will fail if a more advanced security model is in use. 2) In blockdev mode the image will be opened as raw actually which is wrong since it might be qcow. Not opening the backing images will also end up in the guest seeing corrupted data. Rather than attempt to solve various corner cases when us assuming the storage file being raw and actually being right forbid startup when the guest image doesn't have the format specified in the metadata. v5.10.0-334-g5949ac0f59 *** Bug 1790101 has been marked as a duplicate of this bug. *** *** Bug 1792911 has been marked as a duplicate of this bug. *** |