Iterating over the usual disks into the pools.
(gdb) p *disk->src->srcpool
$9 = {pool = 0x565040c0a590 "internal", volume = 0x565040c09ad0 "foo", voltype
= 0, pooltype = 0, actualtype = 0, mode = 0}
(gdb) p *disk->src->srcpool
$11 = {pool = 0x565040c093d0 "testvg", volume = 0x565040c09650 "guest1",
voltype = 0, pooltype = 0, actualtype = 0, mode = 0}
And then e.g. in my case the default connection fails.
31231 virDomainDiskTranslateSourcePool(virDomainDiskDefPtr def)
...
31246 if (!(conn = virGetConnectStorage()))
Due to that it returns -1 and we can't get any extra info from the disk
Inside virGetConnectGeneric I see that it can't get a existing cached
connection via
145 conn = virThreadLocalGet(threadPtr);
(gdb) p conn
$2 = (virConnectPtr) 0x0
That was expected, then it probes via geteuid and since virt-aa-helper runs
like libvirtd as root decides to use
(gdb) p uri
$7 = 0x55a1b10bcce0 "storage:///system"
Then it tries to open this, the backtrace up to here looks like
#0 virConnectOpenInternal (name=0x55a1b10bcce0 "storage:///system", auth=0x0,
flags=0) at ../../../src/libvirt.c:820
#1 0x00007f014f83fbb4 in virConnectOpen (name=name@entry=0x55a1b10bcce0
"storage:///system") at ../../../src/libvirt.c:1076
#2 0x00007f014f83b3dd in virGetConnectGeneric (threadPtr=<optimized out>,
name=0x7f014f9081a2 "storage") at ../../../src/driver.c:156
#3 0x00007f014f7069c5 in virDomainDiskTranslateSourcePool (def=0x55a1b1074cc0)
at ../../../src/conf/domain_conf.c:31246
#4 0x000055a1b0d1552a in get_files (ctl=0x7ffe043579e0) at
../../../src/security/virt-aa-helper.c:951
#5 vahParseArgv (argv=<optimized out>, argc=<optimized out>,
ctl=0x7ffe043579e0) at ../../../src/security/virt-aa-helper.c:1442
#6 main (argc=<optimized out>, argv=<optimized out>) at
../../../src/security/virt-aa-helper.c:1492
With these arguments:
Breakpoint 4, virConnectOpenInternal (name=0x55a1b10bcce0 "storage:///system",
auth=0x0, flags=0) at ../../../src/libvirt.c:820
(here is the libvirt.conf load BTW)
It tries via storage driver then:
(gdb) p virConnectDriverTab[0]->hypervisorDriver->name
$20 = 0x7f014b8438e4 "storage"
(gdb) p *(virConnectDriverTab[0]->uriSchemes)
$22 = 0x7f014b8438e4 "storage"
Init goes well and it calls into
(gdb) p virConnectDriverTab[0]->hypervisorDriver->connectOpen
$31 = (virDrvConnectOpen) 0x7f014b830490 <storageConnectOpen>
But that returns -2
(gdb) bt
#0 storageConnectOpen (conn=0x55a1b109f920, auth=0x0, conf=0x55a1b10bcce0,
flags=0) at ../../../src/storage/storage_driver.c:397
#1 0x00007f014f83e822 in virConnectOpenInternal (name=<optimized out>,
auth=0x0, flags=0) at ../../../src/libvirt.c:1000
#2 0x00007f014f83fbb4 in virConnectOpen (name=name@entry=0x55a1b10af4b0
"storage:///system") at ../../../src/libvirt.c:1076
#3 0x00007f014f83b3dd in virGetConnectGeneric (threadPtr=<optimized out>,
name=0x7f014f9081a2 "storage") at ../../../src/driver.c:156
#4 0x00007f014f7069c5 in virDomainDiskTranslateSourcePool (def=0x55a1b1075050)
at ../../../src/conf/domain_conf.c:31246
#5 0x000055a1b0d1552a in get_files (ctl=0x7ffe043579e0) at
../../../src/security/virt-aa-helper.c:951
#6 vahParseArgv (argv=<optimized out>, argc=<optimized out>,
ctl=0x7ffe043579e0) at ../../../src/security/virt-aa-helper.c:1442
#7 main (argc=<optimized out>, argv=<optimized out>) at
../../../src/security/virt-aa-helper.c:1492
And here the problem is that in the context of virt-aa-helper in
src/storage/storage_driver.c the driver isn't present.
(gdb) p driver
$32 = (virStorageDriverStatePtr) 0x0
We could be blunt and call storageStateInitialize, but I think that
would try to re-setup all the pools. Without further analysis I'm not
sure this is safe to call in the virt-aa-helper context.
@Garry - was the removal of the virDriverLoadModule related to this - to
keep some original driver context?
In the past it just didn't have storage loaded without this and things
failed. Sine this isn't the libvirt daemon which has storage loaded (and
a driver we could use) but "just" virt-aa-helper I doubt skipping this
load will help, but happy to be convinced otherwise.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1677398
Title:
Apparmor prevents using storage pools and hostdev networks
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1677398/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
