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

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.