[libvirt] [PATCH v2 6/7] storage: Support "chap" authentication for iscsi pool

[Osier Yang]

On 16/07/13 00:07, John Ferlan wrote:
> On 07/15/2013 11:11 AM, Osier Yang wrote:
>> On 15/07/13 23:01, John Ferlan wrote:
>>> On 07/15/2013 10:16 AM, Osier Yang wrote:
>>>> On 10/07/13 03:10, John Ferlan wrote:
>>>>> From: Osier Yang <jyang at redhat.com>
>>> <...snip...>
>>>
>>>> i think the chap auth iscsi pool won't  be able to start with this
>>>> change,
>>>> findPoolSources is an api for discovering the pool sources. however,
>>>> we want the chap auth are set up before connecting to the iscsi target
>>>> when starting the pool, otherwise the pool starting will fail on
>>>> authentication.
>>>> note that startPool and findPoolSources are independant apis, they don't
>>>> invoke each other.
>>>>
>>>> with this change, if one wants to start the pool successfully, he has to
>>>> invoke the findPoolSources first, this dependancy is incorrect. as an
>>>> example, in virsh layer, one has to execute find-storage-pool-sources
>>>> or find-storage-pool-sources-as before pool-start.
>>>>
>>>> as an alternative way to have the non-null 'conn' for startPool, we can
>>>> create a connection in storageDriverAutostart (like qemu driver does),
>>>> which is the only place pass an null 'conn' to startPool,
>>> While there is a v3 posted - this code hasn't differed there, so I'll
>>> just use this opportunity to ask you questions...
>>>
>>> A 'conn' to what? Should we assume qemu like nwfilter_driver.c does?
>>>
>>>       if (!driverState->privileged)
>>>           return 0;
>> i think we don't need to restrict it to be a priviledged connection for
>> storage. otherwise there will be regression.
>>
>>>      conn = virConnectOpen("qemu:///system");
>>>
>>> Do we further restrict the StartPool code to ensure there is a
>>> privileged qemu connection?
>> yeah, we will want to get a connection object, but as said above, it
>> should work both priviledged or unpriviledged connection, and no
>> need to restrict startPool to ensure there is a connection, since
>> other storage backends may still work without a connection object
>>
>> osier
> Right and that's what I wasn't quite sure how to resolve in the
> startPool path.  Furthermore a connection to what?

hm, it's a good question. see below
>
> I guess I have to assume qemu because of the docs which have:
>      <disk type='volume' device='disk'>
>        <driver name='qemu' type='raw'/>

we only use "qemu" here because of 'volume' type disk only works
for qemu driver, and it's just a document example.  it doesn't relate
with how to set up the connection uri in storage driver. storage driver
should be independant with each hypervisor drivers (e.g lxc/xen/qemu),
but the question is how could the storage driver know which uri it
should use to get a connection? lxc:///, qemu:///[session|system],
or others? directly using qemu uri doesn't work, for instance, libvirtd
is running without qemu driver loaded.

but i don't have idea either. and also don't see any shortcut to
get the connection object.

Daniel, any thoughts?

>        <source pool='blk-pool0' volume='blk-pool0-vol0'/>
>        <target dev='hda' bus='ide'/>
>
> (BTW: 'volume' is not listed as a valid 'disk type=<value>'...)
>
> And it seems I'd need to a privileged field to _virStorageDriverState
> since storageStateReload() doesn't have the privileged value like
> storageStateInitialize() has.
>
> In storageDriverAutostart() there'd need to be a virConnectOpen to
> either qemu:///system or qemu:///session.  That 'conn' would be passed
> to the startPool (but could also be passed along to checkPool and
> refreshPool conceivably.
>
> This is (more or less) like what qemuAutostartDomains() does with
> respect to 'conn' (except it's using cfg->uri).  The comment in that
> code is rather dubious too...
>
> I'll redo v3 7/7 and repost those changes.
>
> John