Bug 1685151

Summary: Guest will be destroyed if autostarted pool is destroyed and libvirtd restarted
Product: Red Hat Enterprise Linux 8 Reporter: Michal Privoznik <mprivozn>
Component: libvirtAssignee: Michal Privoznik <mprivozn>
Status: CLOSED ERRATA QA Contact: gaojianan <jgao>
Severity: low Docs Contact:
Priority: low    
Version: 8.2CC: dyuan, hhan, jdenemar, kanderso, lmen, meili, mprivozn, mtessun, rbalakri, xuzhang, yalzhang, yisun
Target Milestone: rcKeywords: Upstream
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-4.5.0-29.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1658504 Environment:
Last Closed: 2019-11-05 20:48:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1658504    
Bug Blocks:    

Description Michal Privoznik 2019-03-04 13:53:39 UTC
+++ This bug was initially created as a clone of Bug #1658504 +++

While working on a fix for this bug ^^^ I've came across another one:

1) start a storage libvirt pool (e.g. type of iscsi)
2) start a domain with a disk from that storage pool, e.g.:

    <disk type='volume' device='disk'>
      <driver name='qemu' type='raw'/>
      <source pool='iscsi-secret-pool' volume='unit:0:0:1'/>
      <target dev='vdc' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>

3) make sure the pool is autostarted (virsh pool-autostart)
4) destroy the pool
5) restart libvirtd
6) observe domain being killed

This is introduced by:
cefb97fb81 virStateDriver - Separate AutoStart from Initialize
e4a969092b Separate out StateAutoStart from StateInitialize

Comment 1 Michal Privoznik 2019-03-04 13:58:01 UTC
Alternatively, when bug 1658504 is fixed then all that is needed to reproduce this bug is to use a volume from iscsi-direct pool since iscsi-direct pools don't keep their state through libvirtd restarts. Then no pool-destroy is ineeded.

Comment 2 Michal Privoznik 2019-03-04 14:02:43 UTC
Patches posted upstream:

https://www.redhat.com/archives/libvir-list/2019-March/msg00088.html

Comment 3 Michal Privoznik 2019-03-06 09:22:47 UTC
I've just pushed patches upstream:

07a9c8bae8 Revert "Separate out StateAutoStart from StateInitialize"
fc380c2e01 Revert "virStateDriver - Separate AutoStart from Initialize"
31c3c35c94 bhyve: Move autostarting of domains into bhyveStateInitialize
c6266ddb02 daemon: Register secret driver before storage driver

v5.1.0-80-g07a9c8bae8

Comment 7 gaojianan 2019-07-03 09:15:15 UTC
Verified in version:
libvirt-5.4.0-1.module+el8.1.0+3304+7eb41d5f.x86_64
qemu-kvm-4.0.0-4.module+el8.1.0+3356+cda7f1ee.x86_64
kernel-4.18.0-107.el8.x86_64

Step:
1) start a storage libvirt pool 
<pool type='iscsi'>
<name>iscsi</name>
<source>
<host name="10.66.4.119"/>
<device path="iqn.2016-03.com.virttest:logical-pool.target4"/>
</source>
<target>
<path>/dev/disk/by-path</path>
</target>
</pool>

2) start a domain with a disk from that storage pool, e.g.:

    <disk type='volume' device='disk'>
      <driver name='qemu' type='raw'/>
      <source pool='iscsi' volume='unit:0:0:0'/>
      <target dev='vdc' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>

3) virsh pool-autostart iscsi
4) virsh pool-destroy iscsi
5) systemctl restart libvirtd
6) # virsh list 
 Id   Name   State
----------------------
 14   ovmf   running
 19   jgao   running

Guest jgao works well

Comment 8 gaojianan 2019-07-03 10:17:33 UTC
Additional verify:
Also test iscsi-direct pool for the clone Bug #1658504 

    <disk type='volume' device='disk'>
      <driver name='qemu' type='raw'/>
      <source pool='iscsi-direct' volume='unit:0:0:0'/>
      <target dev='vdb' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
    </disk>
and do the same work as comment7 ,all works well.

Comment 10 errata-xmlrpc 2019-11-05 20:48:05 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3345