Hi,
I was asked about a very similar case and needed to debug it.
So I thought I give the issue reported here a try how it looks like today.

virt install creates a guest with a command like:
  -drive file=/dev/LVMpool/test-snapshot-virtinst,format=raw,if=none,id=drive-virtio-disk0,cache=none,aio=native

## Solved - confusion of pre-existing other apparmor rules as pools are unsupported by libvirt/apparmor ##

In this case virt-inst pre-creates a VG of a given size and passes the guest just that.
This is the different to using the actual pool feature.
With that I'm "ok" that it doesn't need a special apparmor rule already.
From the guest/apparmor point of view when the guest starts the path is known and added to the guests profile.
(With a pool ref in the guest that would not have worked)

## experiments - setup ##
Lets define a guest which has a qcow and a lvm disk that we can snapshot for experiments.
We will use the disk created in the test above, but in a uvtool guest to get rid of all virt-install special quirks.
The other disk is just a qcow file.

  $ sudo qemu-img create -f qcow2 /var/lib/uvtool/libvirt/images/eoan-snapshot-test.qcow 1G
Formatting '/var/lib/uvtool/libvirt/images/eoan-snapshot-test.qcow', fmt=qcow2 size=1073741824 cluster_size=65536 lazy_refcounts=off refcount_bits=16

The config for those looks like:
qcow:
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/uvtool/libvirt/images/eoan-snapshot-test.qcow'/>
      <target dev='vdc' bus='virtio'/>
    </disk>

CMD: -drive file=/var/lib/uvtool/libvirt/images/eoan-snapshot-test.qcow,format=qcow2,if=none,id=drive-virtio-disk2
apparmor:   "/var/lib/uvtool/libvirt/images/eoan-snapshot-test.qcow" rwk,


disk:
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/LVMpool/test-snapshot-virtinst'/>
      <target dev='vdd' bus='virtio'/>
    </disk>

CMD: -drive file=/dev/LVMpool/test-snapshot-virtinst,format=raw,if=none,id=drive-virtio-disk3
apparmor:   "/dev/dm-11" rwk,
which is a match as
$ ll /dev/LVMpool/test-snapshot-virtinst
lrwxrwxrwx 1 root root 8 Sep 11 05:14 /dev/LVMpool/test-snapshot-virtinst -> ../dm-11


## experiments - snapshotting ##

Details of the spec see: https://libvirt.org/formatdomain.html

Snapshot of just the qcow file:
$ virsh snapshot-create-as --print-xml --domain eoan-snapshot --disk-only --atomic --diskspec vda,snapshot=no  --diskspec vdb,snapshot=no --diskspec vdc,file=/var/lib/libvirt/images/eoan-snapshot-test.thesnapshot.qcow,snapshot=external --diskspec vdd,snapshot=no

$ virsh snapshot-list eoan-snapshot
 Name                 Creation Time             State
------------------------------------------------------------
 1568196836           2019-09-11 06:13:56 -0400 disk-snapshot

The snapshot got added to the apparmor profile:
  "/var/lib/libvirt/images/eoan-snapshot-test.thesnapshot.qcow" rwk,

The position shows that this was done with the "append" feature of virt-aa-helper.
So it did not re-parse the guest but just add one more entry (as it would do on hotplug).

I'm not trying to LVM-snapshot as that seems not what was asked for.
And further LVM would have own capabilties to do so.


## check status after snapshot ##

The guest now has the new snapshot as main file and the old one as backing file (COW-chain)
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/eoan-snapshot-test.thesnapshot.qcow'/>
      <backingStore type='file' index='1'>
        <format type='qcow2'/>
        <source file='/var/lib/uvtool/libvirt/images/eoan-snapshot-test.qcow'/>
        <backingStore/>
      </backingStore>
      <target dev='vdc' bus='virtio'/>
      <alias name='virtio-disk2'/>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0004'/>
    </disk>

Please do mind that this is the "runtime view", once shut down you'll only see the new snapshot.
    
This is confirmed by the metadata in the qcow file.
$ sudo qemu-img info /var/lib/libvirt/images/eoan-snapshot-test.thesnapshot.qcow
image: /var/lib/libvirt/images/eoan-snapshot-test.thesnapshot.qcow
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 196K
cluster_size: 65536
backing file: /var/lib/uvtool/libvirt/images/eoan-snapshot-test.qcow
backing file format: qcow2
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false


## restart guest ##

XML of inactive guest as expected:

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/eoan-snapshot-test.thesnapshot.qcow'/>
      <target dev='vdc' bus='virtio'/>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0004'/>
    </disk>

The guest starts just fine (with still all 4 disk entries):
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/uvtool/libvirt/images/eoan-snapshot.qcow'/>
      <backingStore type='file' index='1'>
        <format type='qcow2'/>
        <source file='/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MTkuMTA6czM5MHggMjAxOTA5MDY='/>
        <backingStore/>
      </backingStore>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0000'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/uvtool/libvirt/images/eoan-snapshot-ds.qcow'/>
      <backingStore/>
      <target dev='vdb' bus='virtio'/>
      <alias name='virtio-disk1'/>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0001'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/eoan-snapshot-test.thesnapshot.qcow'/>
      <backingStore type='file' index='1'>
        <format type='qcow2'/>
        <source file='/var/lib/uvtool/libvirt/images/eoan-snapshot-test.qcow'/>
        <backingStore/>
      </backingStore>
      <target dev='vdc' bus='virtio'/>
      <alias name='virtio-disk2'/>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0004'/>
    </disk>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/LVMpool/test-snapshot-virtinst'/>
      <backingStore/>
      <target dev='vdd' bus='virtio'/>
      <alias name='virtio-disk3'/>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0005'/>
    </disk
    
The apparmor includes the backing chains:
  "/var/lib/uvtool/libvirt/images/eoan-snapshot.qcow" rwk,
  "/var/lib/uvtool/libvirt/images/x-uvt-b64-Y29tLnVidW50dS5jbG91ZC5kYWlseTpzZXJ2ZXI6MTkuMTA6czM5MHggMjAxOTA5MDY=" rk,
  "/var/lib/uvtool/libvirt/images/eoan-snapshot-ds.qcow" rwk,
  "/var/lib/libvirt/images/eoan-snapshot-test.thesnapshot.qcow" rwk,
  "/var/lib/uvtool/libvirt/images/eoan-snapshot-test.qcow" rk,
  "/dev/dm-11" rwk,

All works just fine even through restart nowadays.

## LVM snapshots ##

While at it lets double check LVM snapshots as that is often used as well and I was asked about them.

I use this as vdd still:
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/LVMpool/test-snapshot-virtinst'/>
      <backingStore/>
      <target dev='vdd' bus='virtio'/>
      <alias name='virtio-disk3'/>
      <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0005'/>
    </disk
    
Running an LVM snapshot is like:
$ sudo lvcreate -L1G -s -n /dev/LVMpool/test-snapshot-virtinst-snap /dev/LVMpool/test-snapshot-virtinst
  Using default stripesize 64.00 KiB.
  Logical volume "test-snapshot-virtinst-snap" created.

Which gives me:
$ sudo lvdisplay /dev/LVMpool
  --- Logical volume ---
  LV Path                /dev/LVMpool/test-snapshot-virtinst
  LV Name                test-snapshot-virtinst
  VG Name                LVMpool
  LV UUID                H0FfqR-619v-KAeJ-GhXU-p9K5-dns8-fP8NGX
  LV Write Access        read/write
  LV Creation host, time s1lp05, 2019-09-11 05:14:52 -0400
  LV snapshot status     source of
                         test-snapshot-virtinst-snap [active]
  LV Status              available
  # open                 2
  LV Size                1.00 GiB
  Current LE             256
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:11
   
  --- Logical volume ---
  LV Path                /dev/LVMpool/test-snapshot-virtinst-snap
  LV Name                test-snapshot-virtinst-snap
  VG Name                LVMpool
  LV UUID                hTPlXa-o3vj-yjrE-Igse-H7K7-NimG-ipTdoH
  LV Write Access        read/write
  LV Creation host, time s1lp05, 2019-09-11 06:44:05 -0400
  LV snapshot status     active destination for test-snapshot-virtinst
  LV Status              available
  # open                 0
  LV Size                1.00 GiB
  Current LE             256
  COW-table size         1.00 GiB
  COW-table LE           256
  Allocated to snapshot  0.00%
  Snapshot chunk size    4.00 KiB
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:14
  
Writing into that from the guest makes it change.

sudo lvs
  LV                          VG      Attr       LSize  Pool Origin                 Data%  Meta%  Move Log Cpy%Sync Convert
  test-snapshot-virtinst      LVMpool owi-aos---  1.00g                                                                    
  test-snapshot-virtinst-snap LVMpool swi-a-s---  1.00g      test-snapshot-virtinst 9.80
  

Since LVM keeps the old name the one that is continued to be written the same:
$ ll /dev/LVMpool/
lrwxrwxrwx  1 root root    8 Sep 11 06:44 test-snapshot-virtinst -> ../dm-11
lrwxrwxrwx  1 root root    8 Sep 11 06:44 test-snapshot-virtinst-snap -> ../dm-14

Still dm-11 that matches apparmor
  "/dev/dm-11" rwk,

Checking if it is an issue to restart the guest with the LVM snapshot attached.
No, shutdown and start work fine still.

With that said I think we can close this old bug nowadays.

P.S. There is a case a friend of mine reported with qcow snapshots on LVM which sounds odd and is broken.
This I'll track down in another place as it has nothing to do with the issue that was reported here.