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

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.