Re: [libvirt] [PATCH v2 6/7] storage: Support "chap" authentication for iscsi pool
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(a)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