[libvirt] [PATCH 4/4] storage_conf: Resolve libvirtd crash matching scsi_host

[John Ferlan]

On 10/06/2014 08:44 AM, Ján Tomko wrote:
> On 10/06/2014 01:23 PM, John Ferlan wrote:

<...snip...>

>>
>> If you mean we don't check that the name starts with 'scsi' or
>> 'scsi_host', then sure I agree, but that would be a different bug or
>> issue.  I can certainly add a check if that's desired to ensure prefix
>> is correct.  Of course, the docs :
>>
>> http://libvirt.org/formatstorage.html
>>
>> do provide the rules for the name property (and less so for the parent).
>>
> 
> I mean we don't check if a scsi controller is present on the specified PCI
> address when the pool is defined (so the definiton does not depend on host
> hardware). After this patch, I can successfully define a pool with:
> 
>     <adapter type='scsi_host'>
>       <parentaddr unique_id='1'>
>         <address domain='0x0000' bus='0x00' slot='0x1f' function='0x0'/>
>       </parentaddr>
>     </adapter>
> 
> (where 00:1f.0 is some ISA bridge on my system)
> 
> But defining another pool with <adapter type='scsi_host'> and name specified
> now depends on the host hardware, i.e. it always fails:
>     <adapter type='scsi_host' name='host1'/>
> 
> error: Failed to define pool from pool.xml
> error: operation failed: Storage source conflict with pool: 'scsi-pool'
> 
> 
> Depending on the host hardware for duplicate detection during definition seems
> weird to me, considering we don't do that for the first definition on the pool
> either.
> 
>

The parentaddr/unique_id are way to make sure the definition of the
target of the pool lives beyond a host reboot or some other "event" that
causes a reorder/renumber of the 'scsi_host#' values.

Validating whether the address provided is actually a valid target for a
scsi_host is a different can-o-worms.

The patches to be posted shortly will at least make sure the various
ways a scsi_host can be named (name=host#, name=scsi_host#, parentaddr &
unique_id) will at least result in non duplicated pools.

John