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

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&gt; > <...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