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) >>> 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. Thomas
signature.asc
Description: OpenPGP digital signature
