proper code for virt-aa-helper to allow blockcommit rw as needed
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libvirt (Ubuntu) |
Confirmed
|
Low
|
Unassigned |
Bug Description
From the ML:
virsh blockcommit is invoked this leads to:
1.) qemuDomainBlock
2.) qemuDomainDiskC
3.) qemuSecuritySet
4.) AppArmorSetSecu
5.) virt-aa-helper does the profile reload ->
6.) failure since the image has an explicit deny rule
The path in question tries to fix this at 5.) by not adding a deny write
rule at all but the place to fix this is 4.) since
AppArmorSetSecu
element into account to create a virDomainDefPtr based on def that marks
the image in question as 'rw' but "only" reloads the profile.
Full discussion:
https:/
For now we will keep the delta as-is, but mid term a proper extension to virt-aa-helper would be the right way
Changed in libvirt (Ubuntu): | |
status: | New → Confirmed |
tags: | added: virt-aa-helper |
tags: | added: libvirt-apparmor-dev |
Changed in libvirt (Ubuntu): | |
importance: | Undecided → Low |
Some docs on the gereral use case: wiki.libvirt. org/page/ Live-disk- backup- with-active- blockcommit wiki.libvirt. org/page/ Live-merge- an-entire- disk-image- chain-including -current- active- disk
- http://
- http://
Steps to reproduce: ms-libvirt --verbose sync --source http:// cloud-images. ubuntu. com/daily arch=amd64 label=daily release=xenial testblockcommit release=xenial arch=amd64 label=daily
# create basic guest
$ apt install uvtool-libvirt
$ uvt-simplestrea
$ uvt-kvm create --password=ubuntu xenial-
# By default there is (intentionally) not much a qemu process can read/write to uvtool/ libvirt/ images/ xenial- testblockcommit .qcow testblockcommit ------- ------- ------- ------- ------- ------ uvtool/ libvirt/ images/ xenial- testblockcommit .qcow
# To make external snapshots you have to either:
# - define some dir for the guest to snapshot to and add it to its apparmor rules
# - create the snapshot upfront qemu-img -c which will generate the rules for the backing chain
# But fortunately uvtool already sets things up just the way we need it.
# By default the root disk is a snapshot to the base cloud-image
# You can check the chain:
$ qemu-img info --backing-chain /var/lib/
# The guest lists the snapshot as it's disk
$ virsh domblklist xenial-
Target Source
-------
vda /var/lib/
# in /etc/apparmor. d/libvirt/ libvirt- <uuid>. files we can see the related rules uvtool/ libvirt/ images/ xenial- testblockcommit .qcow" rwk uvtool/ libvirt/ images/ x-uvt-b64- Y29tLnVidW50dS5 jbG91ZC5kYWlseT pzZXJ2ZXI6MTYuM DQ6YW1kNjQgMjAx NzA5MTk= " rk, testblockcommit vda --active --pivot --verbose testblockcommit ------- ------- ------- ------- ------- ------ uvtool/ libvirt/ images/ x-uvt-b64- Y29tLnVidW50dS5 jbG91ZC5kYWlseT pzZXJ2ZXI6MTYuM DQ6YW1kNjQgMjAx NzA5MTk=
# r/w to the current snapshot
"/var/lib/
# but only r to the base image
"/var/lib/
$ virsh blockcommit xenial-
Block commit: [100 %]
Successfully pivoted
root@artful-test:~# virsh domblklist xenial-
Target Source
-------
vda /var/lib/
The action added another rule: uvtool/ libvirt/ images/ x-uvt-b64- Y29tLnVidW50dS5 jbG91ZC5kYWlseT pzZXJ2ZXI6MTYuM DQ6YW1kNjQgMjAx NzA5MTk= " rw,
"/var/lib/
Since today we have [1] applied this needs to be unapplied to check if this is still an issue to be fixed or if the actual addition of the second rule is new and fixes the issue completely.
Unfortunately something made libvirt an FTBFS that I have to fix first.