We had a discussion about further backports in [1], but I think the
answer is no unless we have a stronger reasoning. Let us mark the tags
accordingly.
[1]:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1892306/comments/7
** Changed in: libvirt (Ubuntu)
Assignee: Christian Ehrhardt
This bug was fixed in the package libvirt - 6.0.0-0ubuntu1
---
libvirt (6.0.0-0ubuntu1) focal; urgency=medium
* Merged with Debian 5.6.0-4 from experimental and v6.0.0 from upstream
Among many other new features and fixes this includes fixes for:
- LP: #1859253 - rbd driver
Just adding a comment to refresh our "60 days timeout" timer, as this
bug was not dropped and is being worked on.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1845506
Title:
Libvirt snapshot doesn'
FYI - pushed in upstream git now and will be in the next release.
** Tags added: libvirt-20.04
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1845506
Title:
Libvirt snapshot doesn't update apparmor
Ok the extra issue I had was only due to my stacked container setup, something
broke on the apparmor nesting.
On a bare metal system with the patches applied snapshotting multiple disks at
once worked fine now.
The good part of that is that I can now submit my patch series.
Done here:
https://w
By single stepping the code I see that the Denies clearly come in after
the second reload_profile added the rule - so it just should not happen?
Maybe the rules aren't reloaded yet?
But I see the reload activities in dmesg:
... apparmor="STATUS" operation="profile_replace" ...
A manual reload wh
I have created the patches that I had in mind and a test PPA [1] (only a subset
of the patches created are in there) to verify them.
I have run test builds on Eoan and on upstream/master code levels, upstream
code also ran the sysntax/style check scripts of the project.
For me the test PPA [1] w
Example if you run snapshot and hot-add concurrently it might loose one
rule and break.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1845506
Title:
Libvirt snapshot doesn't update apparmor profile
ok, attach-device and attach-disk only support one device on each
invocation and thereby are safe even if they would call the critical
code.
But these (more common) paths still pass AppArmorSetSecurityImageLabel which
means if there were rules added that are not yet reflected in the XML
represen
Launchpad has imported 2 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=1746684.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://hel
TODO from here:
- Test attaching multiple disks in one XML (hot add) just to be sure
- reword the bad help text in virt-aa-helper
- split operation modes / general options / file passing
- add some more words to differ between -f and -F
- In AppArmorSetSecurityImageLabel for the load_profile ca
All false are reloads to restore former content (that is ok):
src/security/security_apparmor.c:706:return reload_profile(mgr, def, NULL,
false);
src/security/security_apparmor.c:750:return reload_profile(mgr, def, NULL,
false);
src/security/security_apparmor.c:795:return reload_profil
virt-aa-helper has (TBH misunderstandable) call modes for appending:
-f | --add-file add file to profile
-F | --append-file append file to profile
-f does render the XML into apparmor rules and then adds the passed file (this
is used atm by the labelling call).
-F keep
In comparison in a hotplug case the extra disk becomes part of the ephemeral
active XML.
And on the next action would be added by parsing that.
But here it renders the XML to append one, and then does the same to append the
second.
But then one can hotplug multiple disks in one XML, that does wor
XML is taken via virDomainDefFormat from the contexts `virDomainDefPtr def`
That is passed to virt-aa-helper as stdin.
These calls are from the same stack.
In my example having the same object for the VM.
vm=0x7f92240444b0 which carries def=0x7f92380e9190 nto both calls and
therby the same XML co
logs:
2 disks:
Oct 15 13:14:07 e libvirtd[612]: internal error: unable to execute QEMU command
'transaction': Could not create file: Permission denied
Oct 15 13:14:08 e libvirtd[612]: Path
'/var/lib/libvirt/images/eoan-disk1.snapshot1.qcow' is not accessible: No such
file or directory
Oct 15 13
I think I see what happens.
virt-aa-helper works on some intermediate content, and the labelling calls only
"append" something.
This works if you e.g. hot attach one and later another device.
But on this interaction with snapshots of multiple devices they seem to work on
"the same" intermediate c
Interesting is that for:
$ virsh snapshot-create-as --domain eoan --disk-only --atomic --diskspec
vda,snapshot=no --diskspec vdb,snapshot=no --diskspec
vdc,file=/var/lib/libvirt/images/eoan-
disk1.snapshot2.qcow,snapshot=external --diskspec
vdd,file=/var/lib/libvirt/images/eoan-
disk2.snapshot1.qc
>From the description of Dominque this seemed a common case, so I tried
with just qcow files and got it confirmed.
# Create basic guest (already has two disks)
uvt-simplestreams-libvirt --verbose sync --source
http://cloud-images.ubuntu.com/daily arch=amd64 label=daily release=eoan
uvt-kvm create
FYI: Also the dumpxml of the other reported case was at:
https://bugzilla.redhat.com/attachment.cgi?id=1609257
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1845506
Title:
Libvirt snapshot doesn't u
Please find xml attached.
** Attachment added: "CmsrvLAP2.xml"
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1845506/+attachment/5291697/+files/CmsrvLAP2.xml
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.la
Then please attach a guest XML of your case as there are too many ways
to configure/attach disks to try all of them. I'll give it a retry
myself then when I'm back to chime in with a +1 on the case then (if
confirmed).
--
You received this bug notification because you are a member of Ubuntu
Bugs,
@paelzer,
I don't think my bug is a duplicate of 1525310...
With me, everything works fine from the start. Creating snapshots works
fine also. Only with guest that has multiple disks, the snapshot fails.
Nonetheless, I tested the snapshot with the
/etc/apparmor.d/usr.lib.libvirt.virt-aa-helper l
Hi Dominique,
isn't that the same as I outlined on [1] ?
In case you think it is related could you for a check open
/etc/apparmor.d/usr.lib.libvirt.virt-aa-helper and remove the deny lines
from /dev/sd to /dev/mapper; then reload via `sudo apparmor_parser -r
/etc/apparmor.d/usr.lib.libvirt.virt-aa
24 matches
Mail list logo
