Re: [libvirt] [PATCH v3 4/7] qemu: Translate the iscsi pool/volume disk source
On Wed, Jul 24, 2013 at 12:59:27PM +0200, Paolo Bonzini wrote:
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).
I've never considered that actually. From the API POV, what we need to
know is the list of LUNS and their sizes. We don't require that they
have files visible in the host - for example the VMWare storage pool
impls don't expose files on the host.
So adding a mode for the pool which let you enumerate LUNs, but not
expose them in the FS would be an option.
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.
It doesn't neccessarily need to be exclusive. If the pool used
mode='host' we could still allow mode=host|direct in the guest. Only
if the pool used mode=direct, would have to restrict it to mode=direct
in the guest. We could make the guest config setting for "mode"
default to match the pool's config.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|