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=, 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=, argc=, ctl=0x7ffe043579e0) at ../../../src/security/virt-aa-helper.c:1442 #6 main (argc=, argv=) 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 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=, 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=, 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=, argc=, ctl=0x7ffe043579e0) at ../../../src/security/virt-aa-helper.c:1442 #7 main (argc=, argv=) 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.