Re: [Qemu-devel] virtio-scsi limits

[Paolo Bonzini <pbonzini@redhat.com>]

On 18/04/2017 17:24, Richard W.M. Jones wrote:
> In libvirt, <address ... bus="0"> refers to the virtio-scsi "channel".
> The current virtio-scsi driver in qemu has a hard limit of 1 channel,
> so you can only use bus="0" (or channel=0).
> 
> Open question: Will this limit ever be increased?

No, it's only there because spapr_vscsi supports channel>0.

> In libvirt, <address ... target="0"> refers to the virtio-scsi
> "scsi-id" (internally in the driver called just ".id").  You can use
> any target from 0 to 255 inclusive.
> 
> In libvirt, <address ... unit="0"> refers to the virtio-scsi "unit" ie
> the SCSI LUN.  You can use any LUN from 0 to 16383 inclusive.
> 
> Open question: What does the bus=scsi0.0 parameter mean?

The first bus in scsi0, where the 0 in scsi0 is the controller index.

> Not tested yet: Does hotplugging work on individual LUNs?

Yes.

> Currently libguestfs puts each disk on a separate target (target=i
> unit=0), and therefore has an effective limit of 255 disks (256 - 1
> because the appliance uses a disk).
> 
> When I changed libguestfs to use LUNs instead of targets (target=0
> unit=i), I got a peculiar bug.  It looks like there is some kind of
> race when enumerating the device, where /sys is populated before the
> device is actually available.

That's not _too_ surprising because devtmpfs processes creation/deletion
requests asynchronously.

Paolo

> See the below boot log, and compare it
> to the init code:
> 
> https://github.com/libguestfs/supermin/blob/master/init/init.c#L176
> 
> * fp = fopen ("/sys/block/sdab/dev", "r") succeeds at line 181
> 
> * we read major:minor from fp at line 230
> 
> * we mknod ("/dev/root",...) at line 245
> 
> * we mount ("/dev/root", "/root", "ext2"...) at line 262, which fails with
>   EINVAL
> 
> * shortly after that, kernel messages indicate that sdab has been
>   attached.