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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list