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