6:14 a.m.
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(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8
10:32 a.m.
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(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8
5:54 a.m.
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.
11:23 a.m.
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(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8
2:54 a.m.
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(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8
11:02 a.m.
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(a)assyoma.it - info(a)assyoma.it
GPG public key ID: FF5F32A8
2302
days inactive
2306
days old
5 comments
2 participants
participants (2)
-
Gionatan Danti -
Peter Krempa