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

[John Ferlan]

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?

I guess I have to assume qemu because of the docs which have:

    <disk type='volume' device='disk'>
      <driver name='qemu' type='raw'/>
      <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