Re: [Xen-devel] [Patch 0/7] pvSCSI driver

[Steven Smith <steven.smith@xxxxxxxxxxxxx>]

> > What I don't understand is why you need this at all.  It seems like it
> > would make more sense to either:
> > 
> > a) Hang every LUN off of the same scsi host, or
> > b) Give each LUN its own scsi host.
> > 
> > Is there some reason why you might want to do something like this:
> > 
> > Host A  -------+----- LUN 1
> >                |
> >                +----- LUN 2
> > 
> > Host B  ------------- LUN 3
> > 
> > i.e. partition the virtual LUNs between multiple hosts in the guest,
> > but keeping some of them together?  Perhaps I'm just missing
> > something, but I can't think of any use cases which would benefit from
> > that, and trying to support it noticeably complicates the frontend.
> Can I explain a numbering logic of assigning LUNs to guests?
That was what I was hoping you'd do, yes. :)

> Basically, each guest looks same SCSI tree as host except for following
> two points. 
> 
> 1.) The "host" in 4-tuples "host:channel:id:lun" on guest may not be
>     same as that on host. 
> 2.) Tree on the guest may be sparse when some LUN doesn't assign to
>     the guest.
> 
> Therefore, "a1:b:c:d" on host becomes "a2:b:c:d" on guest. (a1 != a2
> generally)
Okay, why do you require that the device in the guest has the same
channel:id:lun as the device on the host?  That seems like a somewhat
gratuitous restriction to me.

> I think the numbering logic is same as b) you mentioned above. Is it
> right?
No, you've gone for option c:

c) The topology inside the guest reflects a subset of the host
   topology

which I hadn't previously considered.

Steven.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel