Bug 1238610 - 'dir' type pool couldn't autostart while disable the autostart flag
Summary: 'dir' type pool couldn't autostart while disable the autostart flag
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.2
Hardware: x86_64
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: Erik Skultety
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-02 09:35 UTC by zhenfeng wang
Modified: 2015-11-19 06:48 UTC (History)
6 users (show)

Fixed In Version: libvirt-1.2.17-2.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 06:48:01 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2202 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2015-11-19 08:17:58 UTC

Description zhenfeng wang 2015-07-02 09:35:08 UTC
Description of problem:
'dir' type pool couldn't autostart while disable the autostart flag

Version-Release number of selected component (if applicable):
libvirt-1.2.17-1.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1.# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              inactive   no      

2.Restart libvirtd service
#systemctl restart libvirtd

3.Check the pool status, found the pool was still in inactive status
# virsh pool-list --all
 Name                 State      Autostart 
-------------------------------------------
 default              inactive   no    

4.The dir type pool could autostart successfully even we disable the autostart flag before libvirt-1.2.15-1.el7.x86_64

Actual results:
'dir' type pool couldn't autostart while disable the autostart flag

Expected results:
Should autostart while restart libvirtd service

Additional info:
When libvirtd starts up it probes all storage pools to identify if they are already active on the host. If the filesystem that the directory is located on is mounted, then the directory based pool is trivially active. These words from the following bug
https://bugzilla.redhat.com/show_bug.cgi?id=1036603#c2

Comment 2 Erik Skultety 2015-07-08 13:35:50 UTC
Fixed upstream:

commit f92f31213a718e194323718cb3c667129ef1d4e8
Author: Erik Skultety <eskultet@redhat.com>
Date:   Thu Jul 2 14:41:37 2015 +0200

    storage: Fix regression in storagePoolUpdateAllState
    
    Commit 2a31c5f0 introduced support for storage pool state XMLs, however
    it also introduced a regression:
    
    if (!virstoragePoolObjIsActive(pool)) {
        virStoragePoolObjUnlock(pool);
        continue;
    }
    
    The idea behind this was that since we've got state XMLs and the pool
    wasn't marked as active by autostart routine (if the autostart flag had been
    set earlier), the pool is inactive and we can leave it be and continue with
    other pools. However, filesystem type pools like fs,dir, possibly netfs are
    supposed to be active if the filesystem is mounted on the host. And this is
    exactly where the regression occurs, e.g. pool type 'dir' which has been
    previously destroyed and marked as !autostart gets filtered out
    by the condition above.
    The resolution should be simply to remove the condition completely,
    all pools will get their 'active' flag updated by check callback and if
    they do not support such callback, the logic doesn't change and such
    pools will be inactive by default (e.g. RBD, even if a state XML exists).

v1.2.17-37-gf92f312

Comment 5 yisun 2015-07-14 07:43:39 UTC
Verified on:
libvirt-1.2.17-2.el7.x86_64
qemu-kvm-rhev-2.3.0-9.el7.x86_64
kernel-3.10.0-292.el7.x86_64

PASS

1. Prepare two pools (one dir pool and one iscsi pool)
# virsh pool-dumpxml default
<pool type='dir'>
  <name>default</name>
  <uuid>3fb748f5-8b63-4aad-bd76-908b5434e4af</uuid>
  <capacity unit='bytes'>214643507200</capacity>
  <allocation unit='bytes'>32164483072</allocation>
  <available unit='bytes'>182479024128</available>
  <source>
  </source>
  <target>
    <path>/home/pool</path>
    <permissions>
      <mode>0755</mode>
      <owner>0</owner>
      <group>0</group>
      <label>unconfined_u:object_r:home_root_t:s0</label>
    </permissions>
  </target>
</pool>

# virsh pool-dumpxml iscsi
<pool type='iscsi'>
  <name>iscsi</name>
  <uuid>bc121ba8-cab4-450b-b482-c67defc440fc</uuid>
  <capacity unit='bytes'>4347396096</capacity>
  <allocation unit='bytes'>4347396096</allocation>
  <available unit='bytes'>0</available>
  <source>
    <host name='x.x.x.x' port='3260'/>
    <device path='xxxxxx'/>
  </source>
  <target>
    <path>/dev/disk/by-path</path>
    <permissions>
      <mode>0755</mode>
    </permissions>
  </target>
</pool>

2. check the pools' status
# virsh pool-list --all
 Name                 State      Autostart
-------------------------------------------
 default              active     no        
 iscsi                active     no    

3. explicitly disable the "autostart"
# virsh pool-autostart --disable default
Pool default unmarked as autostarted

# virsh pool-autostart --disable iscsi
Pool iscsi unmarked as autostarted

4. destroy the pools
# virsh pool-destroy default
Pool default destroyed

# virsh pool-destroy iscsi
Pool iscsi destroyed

# virsh pool-list --all
 Name                 State      Autostart
-------------------------------------------
 default              inactive   no        
  iscsi                inactive   no        


5. restart libvirtd process
# service libvirtd restart
Redirecting to /bin/systemctl restart  libvirtd.service

6. check the pools' status
# virsh pool-list --all
 Name                 State      Autostart
-------------------------------------------
 default              active     no        <==== dir pool autostarted as expected.
 iscsi                inactive   no       <==== iscsi pool not autostarted as expected.

Comment 7 errata-xmlrpc 2015-11-19 06:48:01 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://rhn.redhat.com/errata/RHBA-2015-2202.html


Note You need to log in before you can comment on or make changes to this bug.