[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

> 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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]