From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jun Kamada Subject: Re: [Patch 0/7] pvSCSI driver Date: Tue, 04 Mar 2008 16:57:43 +0900 Message-ID: <20080304161920.AAEC.EB2C8575@jp.fujitsu.com> References: <20080229133529.B718.EB2C8575@jp.fujitsu.com> <20080303113857.GA15396@weybridge.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20080303113857.GA15396@weybridge.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Steven Smith Cc: kama@jp.fujitsu.com, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Hi Steven-san, On Mon, 3 Mar 2008 11:38:57 +0000 Steven Smith 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? > 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. The reason why we took the option c is as follows. - Some storage management software running on guest may asume physical topology. (However, I'm not sure whether there is such a software or not.) - The "host" is Linux specific number and Scsi-Host structure for dummy consumes relatively large memory space. Therefore, we decided to compress the "host" number. (Not sparse. Contiguous.) Explicit declaration like below may be one solution. Of cource some default setting is needed. On Dom0 On Guest ------------------------ "1:2:3:4" ---> "5:6:7:8" Best regards, Jun Kamada