[Top][All Lists]

[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?


> 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.


> 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
> * shortly after that, kernel messages indicate that sdab has been
>   attached.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]