Description of problem: Guest will be destroyed if iscsi pool is destroyed and libvirtd restart Version-Release number of selected component (if applicable): libvirt-7.0.0-8.module+el8.4.0+10233+8b7fd9eb.x86_64 qemu-kvm-5.2.0-10.module+el8.4.0+10217+cbdd2152.x86_64 How reproducible: 100% Steps to Reproduce: 1. Start a storage Regres pool with iscsi backend storage. # cat iscsi-pool.xml <pool type='iscsi'> <name>iscsi</name> <uuid>37219096-5307-4e8f-af91-c22c45420563</uuid> <capacity unit='bytes'>21474836480</capacity> <allocation unit='bytes'>21474836480</allocation> <available unit='bytes'>0</available> <source> <host name='**IP**' port='3260'/> <device path='iqn.2021-01.com.redhat:test'/> </source> <target> <path>/dev/disk/by-path</path> <permissions> <mode>0755</mode> <owner>-1</owner> <group>-1</group> </permissions> </target> </pool> # virsh pool-define iscsi-pool.xml Pool iscsi defined from iscsi-pool.xml # virsh pool-start iscsi Pool iscsi started # virsh pool-list --all Name State Autostart --------------------------------- default active yes iscsi active no 2. Start a domain with a disk from that storage pool # virsh dumpxml lmn | grep /disk -B10 ... <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source pool='iscsi' volume='unit:0:0:0' mode='host' index='1'/> <backingStore/> <target dev='vdc' bus='virtio'/> <alias name='virtio-disk2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> # virsh list --all Id Name State --------------------------------- 1 lmn running 3. Set the pool as autostart # virsh pool-autostart iscsi Pool iscsi marked as autostarted 4. Destroy the pool and restart libvirtd # virsh pool-destroy iscsi Pool iscsi destroyed # systemctl restart libvirtd 5. Check the guest status. # virsh list --all Id Name State --------------------------------- - lmn shut off Actual results: Guest will be destroyed Expected results: Guest is still in running Additional info: 1. Same with iscsi-direct pool. 2. libvirtd.log: 2021-03-09 09:45:33.230+0000: 324447: debug : virGetConnectGeneric:156 : Opened new storage connection 0x7f3c58015190 2021-03-09 09:45:33.230+0000: 324447: debug : virStoragePoolLookupByName:367 : conn=0x7f3c58015190, name=iscsi 2021-03-09 09:45:33.230+0000: 324447: debug : virAccessManagerCheckStoragePool:359 : manager=0x559816feedf0(name=stack) driver=storage pool=0x7f3c5810e8d0 perm=0 2021-03-09 09:45:33.230+0000: 324447: debug : virAccessManagerCheckStoragePool:359 : manager=0x559816feee50(name=none) driver=storage pool=0x7f3c5810e8d0 perm=0 2021-03-09 09:45:33.230+0000: 324447: debug : virStoragePoolIsActive:2187 : pool=0x7f3c580205f0 2021-03-09 09:45:33.230+0000: 324447: debug : virAccessManagerCheckStoragePool:359 : manager=0x559816feedf0(name=stack) driver=storage pool=0x7f3c5810e8d0 perm=1 2021-03-09 09:45:33.230+0000: 324447: debug : virAccessManagerCheckStoragePool:359 : manager=0x559816feee50(name=none) driver=storage pool=0x7f3c5810e8d0 perm=1 2021-03-09 09:45:33.230+0000: 324447: error : virDomainStorageSourceTranslateSourcePool:31401 : unsupported configuration: storage pool 'iscsi' containing volume 'unit:0:0:0' is not active 2021-03-09 09:45:33.230+0000: 324447: debug : virStoragePoolDispose:601 : release pool 0x7f3c580205f0 iscsi 37219096-5307-4e8f-af91-c22c45420563 2021-03-09 09:45:33.230+0000: 324447: debug : qemuProcessStop:7590 : Shutting down vm=0x5598170216a0 name=lmn id=2 pid=324291, reason=daemon, asyncJob=none, flags=0x0 2021-03-09 09:45:33.230+0000: 324447: debug : qemuDomainLogAppendMessage:6605 : Append log message (vm='lmn' message='2021-03-09 09:45:33.230+0000: shutting down, reason=daemon ) stdioLogD=1 2021-03-09 09:45:33.230+0000: 324447: debug : virNetSocketNewConnectUNIX:683 : path=/run/libvirt/virtlogd-sock spawnDaemon=0 binary=<null> 2021-03-09 09:45:33.230+0000: 324447: debug : virNetSocketNewConnectUNIX:739 : connect() succeeded 2021-03-09 09:45:33.230+0000: 324447: debug : virNetSocketNew:245 : localAddr=0x7f3c43ffe540 remoteAddr=0x7f3c43ffe5d0 fd=34 errfd=-1 pid=0 2021-03-09 09:45:33.230+0000: 324447: info : virNetSocketNew:301 : RPC_SOCKET_NEW: sock=0x5598170848b0 fd=34 errfd=-1 pid=0 localAddr=127.0.0.1;0, remoteAddr=127.0.0.1;0
I'm not entirely persuaded that this is a regression. The code that does the pool+vol translation is in place for a rather long time. Anyways, we should not attempt to do the translation when reconnecting. The storage pool may even be redefined to a new source. We should store the original config of the source in private data.
There's a same bug before and has already been fixed. Bug 1685151 - Guest will be destroyed if autostarted pool is destroyed and libvirtd restarted
(In reply to Meina Li from comment #2) > There's a same bug before and has already been fixed. > Bug 1685151 - Guest will be destroyed if autostarted pool is destroyed and > libvirtd restarted So this should be a regression bug.
Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.
It can still be reproduced with libvirt-8.5.0-5.el9.x86_64 and qemu-kvm-7.0.0-10.el9.x86_64. So according to the comment 1, I change the "Stale date" to avoid the 30-day auto-close.
It can still be reproduced with libvirt-9.0.0-9.el9_2.x86_64 and qemu-kvm-7.2.0-14.el9_2.x86_64.