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

[Dave Allan]

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.

Dave