WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

Steven-san,

On Thu, 28 Feb 2008 11:13:31 +0000
Steven Smith <steven.smith@xxxxxxxxxxxxx> wrote:
> 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?

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)

I think the numbering logic is same as b) you mentioned above. Is it
right?

Thanks,

-----
Jun Kamada



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

<Prev in Thread] Current Thread [Next in Thread>