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.
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. anslateSourcePo ol(virDomainDis kDefPtr def) orage() ))
31231 virDomainDiskTr
...
31246 if (!(conn = virGetConnectSt
Due to that it returns -1 and we can't get any extra info from the disk
Inside virGetConnectGe neric I see that it can't get a existing cached connection via et(threadPtr) ;
145 conn = virThreadLocalG
(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 nternal (name=0x55a1b10 bcce0 "storage: ///system" , auth=0x0, flags=0) at ../../. ./src/libvirt. c:820 entry=0x55a1b10 bcce0 "storage: ///system" ) at ../../. ./src/libvirt. c:1076 neric (threadPtr= <optimized out>, name=0x7f014f9081a2 "storage") at ../../. ./src/driver. c:156 anslateSourcePo ol (def=0x55a1b107 4cc0) at ../../. ./src/conf/ domain_ conf.c: 31246 79e0) at ../../. ./src/security/ virt-aa- helper. c:951 ./src/security/ virt-aa- helper. c:1442 ./src/security/ virt-aa- helper. c:1492
#0 virConnectOpenI
#1 0x00007f014f83fbb4 in virConnectOpen (name=name@
#2 0x00007f014f83b3dd in virGetConnectGe
#3 0x00007f014f7069c5 in virDomainDiskTr
#4 0x000055a1b0d1552a in get_files (ctl=0x7ffe0435
#5 vahParseArgv (argv=<optimized out>, argc=<optimized out>, ctl=0x7ffe043579e0) at ../../.
#6 main (argc=<optimized out>, argv=<optimized out>) at ../../.
With these arguments: nternal (name=0x55a1b10 bcce0 "storage: ///system" , auth=0x0, flags=0) at ../../. ./src/libvirt. c:820
Breakpoint 4, virConnectOpenI
(here is the libvirt.conf load BTW)
It tries via storage driver then:
(gdb) p virConnectDrive rTab[0] ->hypervisorDri ver->name verTab[ 0]->uriSchemes)
$20 = 0x7f014b8438e4 "storage"
(gdb) p *(virConnectDri
$22 = 0x7f014b8438e4 "storage"
Init goes well and it calls into rTab[0] ->hypervisorDri ver->connectOpe n Open>
(gdb) p virConnectDrive
$31 = (virDrvConnectOpen) 0x7f014b830490 <storageConnect
But that returns -2
(gdb) bt 9f920, auth=0x0, conf=0x55a1b10b cce0, flags=0) at ../../. ./src/storage/ storage_ driver. c:397 nternal (name=<optimized out>, auth=0x0, flags=0) at ../../. ./src/libvirt. c:1000 entry=0x55a1b10 af4b0 "storage: ///system" ) at ../../. ./src/libvirt. c:1076 neric (threadPtr= <optimized out>, name=0x7f014f9081a2 "storage") at ../../. ./src/driver. c:156 anslateSourcePo ol (def=0x55a1b107 5050) at ../../. ./src/conf/ domain_ conf.c: 31246 79e0) at ../../. ./src/security/ virt-aa- helper. c:951 ./src/security/ virt-aa- helper. c:1442 ./src/security/ virt-aa- helper. c:1492
#0 storageConnectOpen (conn=0x55a1b10
#1 0x00007f014f83e822 in virConnectOpenI
#2 0x00007f014f83fbb4 in virConnectOpen (name=name@
#3 0x00007f014f83b3dd in virGetConnectGe
#4 0x00007f014f7069c5 in virDomainDiskTr
#5 0x000055a1b0d1552a in get_files (ctl=0x7ffe0435
#6 vahParseArgv (argv=<optimized out>, argc=<optimized out>, ctl=0x7ffe043579e0) at ../../.
#7 main (argc=<optimized out>, argv=<optimized out>) at ../../.
And here the problem is that in the context of virt-aa-helper in storage_ driver. c the driver isn't present.
src/storage/
(gdb) p driver erStatePtr) 0x0
$32 = (virStorageDriv
We could be blunt and call storageStateIni tialize, 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.