[libvirt-users] Immutable backing files

Hi list, suppose I have an immutable (ie: due to a read-only snapshot) backing file. After creating an overlay file with "qemu-img create -f qcow2 -o backing_file=/path/to/immutable/file.img current.qcow2", libvirt refuse to start the virtual machine and exits with an error stating "Could not open backing file /path/to/immutable/file.img: Permission denied". From my understanding, libvirtd is trying to change the owner/permissions/selinux context of the backing file but, being it immutable, fails to start the VM. Is that the expected behavior? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8

Il 03-09-2018 13:14 Gionatan Danti ha scritto:
Hi list, suppose I have an immutable (ie: due to a read-only snapshot) backing file.
After creating an overlay file with "qemu-img create -f qcow2 -o backing_file=/path/to/immutable/file.img current.qcow2", libvirt refuse to start the virtual machine and exits with an error stating "Could not open backing file /path/to/immutable/file.img: Permission denied".
From my understanding, libvirtd is trying to change the owner/permissions/selinux context of the backing file but, being it immutable, fails to start the VM. Is that the expected behavior?
Thanks.
Hi all, any suggestion on the matter? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8

On Tue, Sep 04, 2018 at 17:32:49 +0200, Gionatan Danti wrote:
Il 03-09-2018 13:14 Gionatan Danti ha scritto:
Hi list, suppose I have an immutable (ie: due to a read-only snapshot) backing file.
After creating an overlay file with "qemu-img create -f qcow2 -o backing_file=/path/to/immutable/file.img current.qcow2", libvirt refuse to start the virtual machine and exits with an error stating "Could not open backing file /path/to/immutable/file.img: Permission denied".
From my understanding, libvirtd is trying to change the owner/permissions/selinux context of the backing file but, being it immutable, fails to start the VM. Is that the expected behavior?
Thanks.
Hi all, any suggestion on the matter?
You forgot to specify the format of the backing file into the overlay file (qemu-img option -F). Libvirt treats any unspecified format as raw since it's not secure to do probing of the format.

Il 06-09-2018 12:54 Peter Krempa ha scritto:
You forgot to specify the format of the backing file into the overlay file (qemu-img option -F). Libvirt treats any unspecified format as raw since it's not secure to do probing of the format.
Hi, the immutable base file *was* a raw image. Then a qcow2 overlay was added, but the vm (which accesses the overlay file) only boot if the base file is writable. It would surprise me if a read-only raw image + qcow2 overlay is an unsupported configuration, so I feel I am missing something... Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8

On Thu, Sep 06, 2018 at 18:23:46 +0200, Gionatan Danti wrote:
Il 06-09-2018 12:54 Peter Krempa ha scritto:
You forgot to specify the format of the backing file into the overlay file (qemu-img option -F). Libvirt treats any unspecified format as raw since it's not secure to do probing of the format.
Hi, the immutable base file *was* a raw image. Then a qcow2 overlay was added, but the vm (which accesses the overlay file) only boot if the base file is writable.
I suspect this is a permission problem. The backing file still needs to be accessed by the VM so libvirt should correctly relabel it (if possible) if the dynamic_ownership feature is enabled. Since you are seeing problems it's possible that libvirt's treatment was not enough. Libvirt's labelling e.g. does not ensure that the directory user/group/label are correct, we only deal with the image. As the messages you've shared have obfuscated paths I can't tell you if that might be a problem. If you are sure that the paths are accessible by the qemu process and it still does not work, please attach debug logs and the XML file to a bug report.
It would surprise me if a read-only raw image + qcow2 overlay is an unsupported configuration, so I feel I am missing something...
No, that is a supported configuration and even the security should not create a problem here as we assume the backing image is raw in this case. That is only a problem if you have a qcow2 image as the base image.
Thanks.
-- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8

On 07/09/2018 09:54, Peter Krempa wrote:
No, that is a supported configuration and even the security should not create a problem here as we assume the backing image is raw in this case. That is only a problem if you have a qcow2 image as the base image.
Thanks for confirmation. I'll continue my testing and report back. Regards. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@assyoma.it - info@assyoma.it GPG public key ID: FF5F32A8
participants (2)
-
Gionatan Danti
-
Peter Krempa