| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [Patch 0/7] pvSCSI driver
> > > > 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.
...
> > > 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.)
There are three obvious ways for them to make that kind of assumption:
1) There's some SCSI command which applies to a collection of devices,
and that collection depends on the topology. Bus resets are the
obvious one here. All of these commands will need special handling
anyway, to prevent VMs from interfering with each other (and I
don't think you currently support any of them, anyway).
2) There are some magic LUNs/targets/whatevers which the application
tries to access at a particular address. sam4r10 requires that
either LUN 0 or the REPORT LUNS well-known LUN be present, so
that's pretty plausible. I think your current implementation may
already have problems here if a user decides to only connect a
subset of a device's LUNs, yes?
3) There's some SCSI command which returns LUNs in its results.
REPORT LUNs is the obvious one here. The frontend will currently
report incorrect results for these commands if the user has only
connected a subset of the LUNs.
This kind of suggests that we should be plumbing things through to the
guest with a granularity of whole targets, rather than individual
logical units. The alternative is a much more complicated scsi
emulation which can fix up the LUN-sensitive commands.
> - 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.)
Are you implying that frontend host numbers won't always match up with
backend host numbers?
If hosts are expensive to construct then that's a good reason to avoid
model (b) (one host per LUN/target) (although my desktop has a scsi
host for each SATA port, so they can't be *that* expensive). It
doesn't rule out model (a) (one host shared by all LUNs).
> 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"
Allowing this kind of mapping sounds reasonable to me. It would also
make it possible (hopefully) to add support for some of the weirder
SCSI logical unit addressing modes without changing the frontends
(e.g. hierarchical addressing with 64 bit LUNs). That might involve a
certain amount of munging of REPORT LUNS commands in the backend,
though.
Steven.
signature.asc
Description: Digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home