[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] virtio-scsi limits
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] virtio-scsi limits |
Date: |
Tue, 18 Apr 2017 17:30:52 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
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.