Comment 34 for bug 1677398
Revision history for this message
| Garry Lawrence (invalidinterrupt) wrote | #34 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
a60fb26
(Get the code!)
Thanks for subscribing me; I'm a launchpad newbie and didn't realize that wasn't automatic when I posted here. I'll try to answer your questions to the best of my recollection.
#1
I can't remember exactly why I needed to drop the storage driver load; I think the local storage driver it started didn't have all the configuration I needed to resolve the disk paths (probably needed the pool config). If I remember correctly, after reading around the source code it looked like I could get it to connect to a remote storage driver automatically by eliminating the local one.
#2
I agree that we can't always know where libvirt.conf is, but here I allowed the default that was in use by my system to move forward. Other locations could be allowed, and a more general approach would be a good idea.
#3
I had inspected those structs using gdb when I was working on that patch, but don't have an example on-hand right now
My memory of why I was doing this is hazy at this point. I think I was trying to grant each VM access to only its own disk layers (so adding to the profile template does not accomplish this), and I needed virt-aa-helper to traverse a qcow image's backing chain to grant read access to the parents (which didn't work without resolving it's path).
I'll try to find time soon to look into the cause of the failure you mention. My patch did work for me and I've been starting VMs with the generated profiles, but it's very possible I broke something else. I don't have a ton of experience with libvirt yet.
Sorry if this is obvious, but it's been a while since I was working on this: what do you mean by "setting up a new storage context" in your last comment?
This is somewhat off topic, but why does the AppArmor security driver use a helper binary (virt-aa-helper)? If it's mostly historical reasons, would there be motivation to move the logic from the helper in-process similarly to the SELinux driver in the future? It seems like that might simplify accessing information of the sort we're talking about here (e.g. pool configs, hostdev network info).