which vols added to storage pool during refresh?

[Gareth S Bestor <bestor@xxxxxxxxxx>]

(opps, actually meant to post this to
libvirt-users instead of libvirt-cim...)


We're looking at a problem when we have a libvirt pool defined, below

[root@xnl2192 ~]# virsh pool-dumpxml ScsiPool-host2
<pool type='scsi'> 
  <name>ScsiPool-host2</name> 
  <uuid>f2ea1882-881f-9f49-838d-39e070f68002</uuid>
  <capacity>136583315456</capacity>
  <allocation>136583315456</allocation>
  <available>0</available> 
  <source> 
    <adapter name='host2'/> 
  </source> 
  <target> 
    <path>/dev/disk/by-id</path>
    <permissions> 
      <mode>0700</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions> 
  </target> 
</pool> 

As you can see, this pool maps to /dev/disk/by-id. There may be a large
number of actual volume entries in /dev/disk/by-id, however it appears
only a distinct subset of them are actually added into the libvirt pool
when you do a pool-refresh. What does libvirt check when determining which,
and whether or not, to add one of these volume into the vol-list?

In particular, we have a case when one specific volume in /dev/disk/by-id
is *not* added into the pool, and no amount of pool-refresh makes a difference.
We did notice that if you remove all the sym links in /dev/disk/by-id and
do a pool-refresh, that libvirt re-scans the bus, recreates the links in
/dev/disk/by-id, and adds (some of) the volumes back into the vol-list.
But not this one problematic vol, so clearly there is something about this
vol that libvirt doesnt like and why it is (deliberately?) not added to
the pool. 

What checks, etc does libvirt make against vols when determining whether
to add them to a pool? 

- G 

Dr. Gareth S. Bestor
IBM Senior Software Engineer
Systems & Technology Group - Systems Management Standards
971-285-6375 (mobile)
bestor@xxxxxxxxxx_______________________________________________
Libvirt-cim mailing list
Libvirt-cim@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-cim