qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 0/6] SCSI series part 2, rewrite LUN parsing


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH 0/6] SCSI series part 2, rewrite LUN parsing
Date: Wed, 25 May 2011 17:08:25 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.10

On 05/25/2011 03:17 PM, Christoph Hellwig wrote:
On Fri, May 20, 2011 at 07:37:30PM +0200, Paolo Bonzini wrote:
On 05/20/2011 06:14 PM, Christoph Hellwig wrote:
I don't quite understand what you mean with path here.  It doesn't
seem to map to any SAM concept, nor does it seem to be related
to traditional multipathing.

It's what SAM calls a "bus identifier" in the description of LUN addressing
modes.

Ok, so it more or less translates to the concept of a "channel" in
the Linux SCSI subsystem.

Yes.

It would help if you could explain the concept
in a bit more detail in a comment.  Or in fact not bother with it at all,
which should be easy if we never present hierachial LUNs.

Unfortunately spapr_vscsi requires hierarchical LUNs. The OpenFirmware code starts by sending out INQUIRY messages to channel 0/1/2/3/4/5/6/7 target 0 LUN 0 (it doesn't recognize other targets or LUNs as far as I can see). So if you want to have a CD-ROM and a HD on your virtual machine, and you want your HD to keep its name both during the installation process and afterwards, you pretty much have to use channel 0 for the HD and another channel for the CD-ROM..

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]