On 2011年11月29日 05:48, Dave Allan wrote:
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.
I'd agree with danpb more, i.e. it shouldn't mix the storage pool
operation in domain's life. Both the storage and domain have public
APIs for use, if we auto-create/start the storage pool as a side
effect of domain starting, it probalbly means we need to call the
storage's public API internally inside domain's public API, another
way is to create some specific inernal storage functions for purpose,
but it doesn't make things any better IMHO. It just could bring
unexpected pain which we might suffer from in future, as the domain
and storage are standalone modules with the original design, though
I could't give an concrete proof now. Could anyone imagine it and
give a proof? :-)
Regards,
Osier
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list