Bug 2192112
| Summary: | seclabel DAC relabel no VS yes & 'backup-begin' | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | lejeczek <peljasz> | ||||
| Component: | libvirt | Assignee: | Virtualization Maintenance <virt-maint> | ||||
| libvirt sub component: | Storage | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
| Status: | CLOSED NOTABUG | Docs Contact: | |||||
| Severity: | high | ||||||
| Priority: | unspecified | CC: | bstinson, jsuchane, jwboyer, pkrempa, vgoyal, virt-maint | ||||
| Version: | CentOS Stream | Flags: | pm-rhel:
mirror+
|
||||
| Target Milestone: | rc | ||||||
| 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: | 2023-05-02 10:09:41 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: |
|
||||||
That is not it, but instead it's utterly misleading & confusing 'no available space' - VMs images where different sizes and when failed/succeded I could only attribute that to 'relabel' for dom XML apart from 'relabel' where identical. I remember I failed a report some time ago - precisely about the way 'backup' messages a failure out with such a "test-case" as no-space-left. I was hoping devel would improve this. ... so, not a bug, nothing to do with 'relabel' thanks, L. (In reply to lejeczek from comment #1) > That is not it, but instead it's utterly misleading & confusing 'no > available space' - VMs images where different sizes and when failed/succeded > I could only attribute that to 'relabel' for dom XML apart from 'relabel' > where identical. > I remember I failed a report some time ago - precisely about the way > 'backup' messages a failure out with such a "test-case" as no-space-left. I > was hoping devel would improve this. > > ... so, not a bug, nothing to do with 'relabel' > thanks, L. So you ran out of space and hence you faced this failure? Sounds like this bug can be closed as NOTABUG? Next time please don't foget to also attach the full VM xml and the full backup XML ( or the full virsh commadnline) used to start the backup if you are going to report a bug. From your report it's impossible to see whats happening. Since Comment 1 mentions that it's not a bug I'll close this. If you end up reopening it for any reason please make sure to attach as much information as possible. Hello again - actually there is a problem with relabel - now after a bigger clean up storages is done, re-testing is done and definetely:
<seclabel type='dynamic' model='dac' relabel='yes'> -- good backup!
<seclabel type='static' model='dac' relabel='no'> -- ! no backup!
logs below and a domdef in attachment.
...
internal error: unable to execute QEMU command 'blockdev-add': Could not open '/devs/X-VMs-BKPs/vda.qcow2': Permission denied
Path '/devs/X-VMs-BKPs/vda.qcow2' is not accessible: No such file or directory
Unable to tear down cgroup access on /devs/X-VMs-BKPs/vda.qcow2
cannot resolve symlink /devs/X-VMs-BKPs/vda.qcow2: No such file or directory
Unable to restore security label on /devs/X-VMs-BKPs/vda.qcow2
<domainbackup mode='push'>
<disks>
<disk name='vda' type='file'>
<driver type='qcow2'/>
<target file='/devs/X-VMs-BKPs/vda.qcow2'>
<encryption format='luks'>
<secret type='passphrase' uuid='xxxxxxxxxxxxxxxx'/>
</encryption>
</target>
</disk>
</disks>
</domainbackup>
Created attachment 1962165 [details]
dom definition
Just to mention, I think I got some packages updates since I filed this report. qemu-img-8.0.0-1.el9.x86_64 qemu-kvm-common-8.0.0-1.el9.x86_64 qemu-kvm-core-8.0.0-1.el9.x86_64 selinux-policy-38.1.12-1.el9.noarch |
Description of problem: Hi, with xml definition as here: ... <seclabel type='static' model='dac' relabel='no'> <label>+107:+107</label> <imagelabel>+107:+107</imagelabel> </seclabel> 'backup-begin' fails with: ... internal error: unable to execute QEMU command 'blockdev-add': Could not open '/devs/X-VMs-BKPs/vda.qcow2': Permission denied Path '/devs/X-VMs-BKPs/vda.qcow2' is not accessible: No such file or directory Unable to tear down cgroup access on /devs/X-VMs-BKPs/vda.qcow2 cannot resolve symlink /devs/X-VMs-BKPs/vda.qcow2: No such file or directory Unable to restore security label on /devs/X-VMs-BKPs/vda.qcow2 ... even tough 'qemu' user has write permission to the target path. Suffices to set relabel='yes' and backup works. Does not make much sense having a fully up&running VM not being able to backup. What I also see is that with 'no' running dom definition is: ... <seclabel type='static' model='dac' relabel='no'> <label>+107:+107</label> </seclabel> so this is absent: <imagelabel>+107:+107</imagelabel> which is present with 'yes' Version-Release number of selected component (if applicable): libvirt-libs-9.0.0-7.el9.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: