[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PULL 40/41] vhost-user-scsi: Introduce vhost-user-scsi
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PULL 40/41] vhost-user-scsi: Introduce vhost-user-scsi host device |
Date: |
Sun, 23 Jul 2017 16:47:40 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
On 18/07/2017 18:32, Marc-André Lureau wrote:
>
>
> On Thu, Jun 15, 2017 at 1:20 PM Paolo Bonzini <address@hidden
> <mailto:address@hidden>> wrote:
>
> From: Felipe Franciosi <address@hidden <mailto:address@hidden>>
>
> This commit introduces a vhost-user device for SCSI. This is based
> on the existing vhost-scsi implementation, but done over vhost-user
> instead. It also uses a chardev to connect to the backend. Unlike
> vhost-scsi (today), VMs using vhost-user-scsi can be live migrated.
>
> To use it, start Qemu with a command line equivalent to:
>
> qemu-system-x86_64 \
> -chardev socket,id=vus0,path=/tmp/vus.sock \
> -device vhost-user-scsi-pci,chardev=vus0,bus=pci.0,addr=...
>
> A separate commit presents a sample application linked with libiscsi to
> provide a backend for vhost-user-scsi.
>
> Signed-off-by: Felipe Franciosi <address@hidden
> <mailto:address@hidden>>
> Message-Id: <address@hidden
> <mailto:address@hidden>>
> Signed-off-by: Paolo Bonzini <address@hidden
> <mailto:address@hidden>>
> ---
>
>
> I just realized the patch was missing qemu-options.hx update. Oh wait,
> virtio-scsi-pci isn't documented either?
>
> Would it have been possible to add a vhost-user-chr=chr argument on
> virtio-scsi-pci instead of introducing a new device? Would that make
> sense (to share code, argument etc)?
No, it wouldn't make sense.
The reason is that vhost-scsi devices are configured entirely outside
QEMU, and for this reason vhost-scsi/vhost-user-scsi do not expose a
SCSI bus at the QEMU level. They do share code (through the
virtio-scsi-common superclass), but they are fundamentally different.
The vhost-blk device probably would also be a separate class, for the
same reason. There is no way to define a -drive option with a chardev
backend.
Even vhost-user-net is somewhat hackish in its use of -netdev in my
opinion, because it cannot implement ->receive (except for the RARP
hack) and it bypasses things such as filters and hubs.
Paolo