[libvirt] Associate a LUN as disk with WWNN/WWPN

[Osier Yang]

On 2011年11月29日 05:48, Dave Allan wrote:
> On Mon, Nov 28, 2011 at 09:41:12PM +0000, Daniel P. Berrange wrote:
>> On Mon, Nov 28, 2011 at 09:01:45AM -0500, Dave Allan wrote:
>>> On Fri, Nov 25, 2011 at 10:49:29AM +0000, Daniel P. Berrange wrote:
>>>> On Fri, Nov 25, 2011 at 06:42:42PM +0800, Osier Yang wrote:
>>>>> On 2011年11月25日 18:28, Daniel P. Berrange wrote:
>>>>>> On Fri, Nov 25, 2011 at 04:55:02PM +0800, Osier Yang wrote:
>>>>>>
>>>>>>>
>>>>>>> <quote>
>>>>>>> AFAIU libvirt needs a way to:
>>>>>>>
>>>>>>> - Associate a virtual adapter WWN with a VM (in the VM xml)
>>>>>>> - Learn to start a virtual adapter when the VM is started, and destroy the
>>>>>>>    adapter when the VM is stopped.
>>>>>>> - Possibly a way to associate a WWN with a scsi pool, to start / stop a
>>>>>>>    virtual adapter with the pool.
>>>>>>> </quote>
>>>>>>>
>>>>>>> But afer thinking more, I'd think it might be not good idea:
>>>>>>>
>>>>>>> As far as I could understand, the requirement of the BZ wants
>>>>>>> a way to create/migrate a guest with NPIV. I'm goint to talk
>>>>>>> create first,and migration then.
>>>>>>
>>>>>> The desire to assocaite WWNN/WWPN with a VM is just one part of a more
>>>>>> general need to expand libvirt's SCSI support. Paulo started a design
>>>>>> thread on the subject a month or so back which sort of converged into
>>>>>> agreement:
>>>>>>
>>>>>> https://www.redhat.com/archives/libvir-list/2011-October/msg01253.html
>>>>>>
>>>>>
>>>>> Yes, I read this thread before, but it looks to me Paolo was talking
>>>>> about LUN, scsi host, and vHBA passthrough. It's a bit different
>>>>> with what I'm trying to resolve (There is no passthrough here, but
>>>>> about how to design a good workflow between virt-manager / Boxes
>>>>> and libvirt for using (creating and migration ) a FC LUN as a normal
>>>>> disk). The useful thing in the discussion of the thread may be
>>>>> define the (v)HBA as a controller though.
>>>>>
>>>>> Or I misunderstood something?
>>>>
>>>> I've found that when people generally talk about associating iSCSI LUNs
>>>> with a guest, they have always been expecting SCSI LUN passthrough, or
>>>> passthrough of the entire iSCSI vHBA.
>>>
>>> Agreed, and IMO we should implement that also, but I think that work
>>> is divisible from the non-passthrough case, which is what we're
>>> considering.
>>>
>>>> If we're considering a non-passthrough use case, then IMHO the problem
>>>> should be generalized to
>>>>
>>>>    How do we associated a storage volume with a VM ?
>>>>
>>>> ie not something that is specific to (i)SCSI.
>>>
>>> I like the idea of associating a storage volume with a particular
>>> block device on a VM.
>>>
>>> So, what's your vision for how a VM would use storage that's visible
>>> to a virtual WWN?  It sounds like you're saying that we should extend
>>> SCSI pools to take WWNN, WWPN and fabric name, and then instantiate
>>> the vHBA when the pool is started.  We'd then extend the domain disk
>>> XML to take a pool/volume definition.  When the VM is started, we'd
>>> check to see if the pool was active, if not, try to start it, and use
>>> the resulting volume as described in the domain XML.  We'd have to
>>> manage the wait for the volumes to show up, but we have to contend
>>> with that regardless.  That's kind of a nice option in this use case
>>> as it would allow administrators to bring the pool up ahead of domain
>>> start if desired.
>>>
>>> Is that right?
>>
>> That's not really what I had in mind for storage pools. I expect that
>> the storage pool is configured by the mgmt app prior to creating the
>> guest. When creating the guest they just refer to a volume within the
>> pool. We shouldn't be auto-creating storage pools as a side effect of
>> starting guests IMHO.
>
> I think we're saying the same thing--I was thinking the user/mgmt app
> would create the pool, and starting the guest would start the pool if
> it wasn't already started, if a volume in it was associated with the
> VM.
>

I'd agree with danpb more, i.e. it shouldn't mix the storage pool
operation in domain's life. Both the storage and domain have public
APIs for use, if we auto-create/start the storage pool as a side
effect of domain starting, it probalbly means we need to call the
storage's public API internally inside domain's public API, another
way is to create some specific inernal storage functions for purpose,
but it doesn't make things any better IMHO. It just could bring
unexpected pain which we might suffer from in future, as the domain
and storage are standalone modules with the original design, though
I could't give an concrete proof now. Could anyone imagine it and
give a proof? :-)

Regards,
Osier