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

[Daniel P. Berrange]

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.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|