Re: [Qemu-devel] [PATCH] spapr: Reduce advertised max LUNs for spapr_vscsi

[Laurent Vivier <lvivier@redhat.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 10/09/2015 08:48, David Gibson wrote:
> On Thu, Sep 10, 2015 at 08:12:47AM +0200, Thomas Huth wrote:
>> On 10/09/15 03:24, David Gibson wrote:
>>> On Wed, Sep 09, 2015 at 09:29:18AM +0200, Thomas Huth wrote:
>>>> On 09/09/15 09:19, David Gibson wrote:
>>>>> On Wed, Sep 09, 2015 at 08:25:34AM +0200, Thomas Huth
>>>>> wrote:
>>>>>> On 09/09/15 03:22, David Gibson wrote:
>>>>>>> The implementation of the PAPR paravirtual SCSI adapter
>>>>>>> currently allows up to 32 LUNs (max_lun == 31).
>>>>>>> However the adapter isn't really designed to support
>>>>>>> lots of devices - the PowerVM implementation only ever
>>>>>>> puts one disk per vSCSI controller.
>>>>>> 
>>>>>> Do you know how many LUNs are advertised by PowerVM?
>>>>> 
>>>>> Well, what do you mean by "advertised".  AFAIK from the
>>>>> point of view of the guest, the number of LUNs is
>>>>> advertised per-target, not per controller.
>>>> 
>>>> I mean, what's the highest LUN number that can be seen by a
>>>> guest under PowerVM? Is it always using only one LUN per
>>>> controller, or is there a way to change the amount of LUNs?
>>>> (Sorry if I ask dumb questions ... I do not have much
>>>> experience with PowerVM yet)
>>> 
>>> Um.. I'm not sure, I have very little experience with PowerVM
>>> too.  I think with PowerVM it's usually real SCSI devices being
>>> passed through, rather than disk images, so presumably the SCSI
>>> target itself reports however many LUNs it has.  There may be a
>>> limitation in PowerVM, or in the AIX VIO server I think it
>>> typically backends onto, but I don't know what it is.
>>> 
>>> Since that limit has been in the guest side driver forever,
>>> presumbly no-one has hit LUNs > 8 in practice.
>>> 
>>>>>>> More specifically, the Linux guest side vscsi driver
>>>>>>> (the only one we really care about) is hardcoded to
>>>>>>> allow a maximum of 8 LUNs.
>>>>>> 
>>>>>> So what about changing the vscsi driver in Linux instead
>>>>>> to support more LUNs?
>>>>> 
>>>>> Doesn't help for existing guests.  Basically what I'm
>>>>> trying to achieve is for qemu to reject up-front
>>>>> configurations that are unlikely to actually work in the
>>>>> guest.
>>>> 
>>>> I just wonder whether it makes sense to change the guest
>>>> instead. In the future, if we ever have guests that support
>>>> more LUNs than 8 (maybe some non-Linux guests like FreeBSD?),
>>>> we've got to change QEMU back again... OTOH, since this is
>>>> just a one-line fix, it's likely ok to limit this to 8 now -
>>>> it's easy to revert if we ever need to, so I'm fine with
>>>> that change, I just wanted to discuss the other
>>>> possibilites.
>>> 
>>> Remember that the spapr-vscsi device exists pretty much
>>> entirely to make transition simpler for existing PowerVM
>>> guests.  New guests (Linux or otherwise) intended to run under
>>> KVM should be using virtio-blk or virtio-scsi.
>> 
>> FWIW, I had a quick look at FreeBSD sources here:
>> 
>> https://svnweb.freebsd.org/base/stable/10/sys/powerpc/pseries/phyp_vs
csi.c?revision=259204&view=markup
>>
>>
>> 
... and as far as I can see, they do not limit the LUNs to 8.
>> (I only spotted a "cpi->max_lun = ~(lun_id_t)(0);" in there). So
>> there indeed might also be older guests that support more than 8
>> LUNs.
> 
> Fair enough, you've convinced me.
> 
> I still think it makes sense downstream only, though.
> 

I agree with that. I've sent a patch series to the kernel ML to
display current limits and to allow to change max_lun.

Laurent
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlXxXB0ACgkQNKT2yavzbFPcNwCg8nyxLkZWx4MInpRTi2U98u3e
YgsAoNUsTQBAUXkdS5Cu1u5HINh8FEa8
=AaRF
-----END PGP SIGNATURE-----