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