[libvirt] [PATCH v3 4/7] qemu: Translate the iscsi pool/volume disk source

[Paolo Bonzini]

Il 24/07/2013 12:46, Daniel P. Berrange ha scritto:
> On Wed, Jul 24, 2013 at 12:41:49PM +0200, Paolo Bonzini wrote:
>> Il 24/07/2013 12:39, Daniel P. Berrange ha scritto:
>>> On Wed, Jul 24, 2013 at 12:37:10PM +0200, Paolo Bonzini wrote:
>>>> Il 24/07/2013 12:31, Daniel P. Berrange ha scritto:
>>>>> breaking the default config for QEMU's without iSCSI support.
>>>>
>>>> Understood, that's why I suggested not having a default config at all
>>>> for type='lun' devices.
>>>
>>> As I said before, that causes apps to have to do special handling
>>> for iSCSI pools, which is not something we want.
>>
>> This is not about iSCSI pools, it is about type='lun' devices.
>>
>> And as I said before, knowing the kind of pool is something you have to
>> do anyway for type='lun' devices, because they won't work if the
>> underlying pool is filesystem- or LVM-based.
> 
> Regardless of whether all pools types can use type=lun, I don't want
> to see special case handling of this attribute. If it is optional in
> the XML schema, it should be unconditionally optional for any usage.

The XML schema can mark it as optional for type!=lun and mandatory for
type=lun, but I agree it may be unnecessarily complicated.

>>>> Also, can libvirt at least detect using a volume on a pool that wasn't
>>>> started, and fail unless mode='direct'?
>>>
>>> It should always fail to start the guest if the pool is not started,
>>> regardless of the mode used.
>>
>> Another point of mode='direct' is that the pool need not be started.
> 
> That is not something we can allow in the long term. When we expand our
> fine grained access control further, we're likely going to need to do
> ACL checks for the virStorageVolPtr object referenced by the XML config
> here. We can't do that unless the pool is running. So we cannot set a
> precedent of allowing use without the pool being active IMHO.

Can you make the pool active, but at the same time not expose it as
devices on the host?  LUNs can be discovered by talking directly to the
target (similar to the iscsi-ls command included with libiscsi).

In other words, perhaps mode='host' vs. mode='direct' could be a
property of the pool rather than the disk?  That would certainly work
fine for me.

Paolo