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.
