[Qemu-devel] qemu and own disk driver writing questions

[Qemu-devel] qemu and own disk driver writing questions

[Vasiliy Tolstov]

Hi! If i want to develop some sort of qemu network block driver to own
storage. I can write qemu driver or tcmu / scst userspace driver and
attach to qemu block device (i'm use linux)
So in theory what path have minimal overhead in case of memory copy
and performance?
Where i can find some info how qemu works with data that needs to be
written or readed from block device passed to vm?
Thanks.

-- 
Vasiliy Tolstov,
e-mail: v.tolstov@selfip.ru

Re: [Qemu-devel] qemu and own disk driver writing questions

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

On Thu, Apr 13, 2017 at 01:57:17PM +0300, Vasiliy Tolstov wrote:
> Hi! If i want to develop some sort of qemu network block driver to own
> storage. I can write qemu driver or tcmu / scst userspace driver and
> attach to qemu block device (i'm use linux)
> So in theory what path have minimal overhead in case of memory copy
> and performance?
> Where i can find some info how qemu works with data that needs to be
> written or readed from block device passed to vm?

The best approach depends on your requirements.  If you want the code to
be merged into qemu.git it's important to discuss the requirements first
so that everyone is on board with adding another block driver.

Three options:

1. Implement iSCSI, NBD, or NFS on your storage server.  Doesn't require
   new QEMU code and users don't need to upgrade QEMU.

2. Implement a block driver in block/.  See iSCSI and other network
   protocol drivers for examples.  Useful if your storage system offers
   snapshot features.

3. Implement vhost-user-scsi in your storage server.  You need to write
   a virtio-scsi backend that runs in a separate userspace process on
   the host.  You are limited to supporting the virtio-scsi device - no
   IDE, SATA, virtio-blk, etc.  vhost-user-scsi is still under active
   development and you may need to contribute to it if you hit
   limitations/bugs.  Requires low-level knowledge of virtio.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [Qemu-devel] qemu and own disk driver writing questions

[Kevin Wolf]

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

Am 18.04.2017 um 19:14 hat Stefan Hajnoczi geschrieben:
> On Thu, Apr 13, 2017 at 01:57:17PM +0300, Vasiliy Tolstov wrote:
> > Hi! If i want to develop some sort of qemu network block driver to own
> > storage. I can write qemu driver or tcmu / scst userspace driver and
> > attach to qemu block device (i'm use linux)
> > So in theory what path have minimal overhead in case of memory copy
> > and performance?
> > Where i can find some info how qemu works with data that needs to be
> > written or readed from block device passed to vm?
> 
> The best approach depends on your requirements.  If you want the code to
> be merged into qemu.git it's important to discuss the requirements first
> so that everyone is on board with adding another block driver.
> 
> Three options:
> 
> 1. Implement iSCSI, NBD, or NFS on your storage server.  Doesn't require
>    new QEMU code and users don't need to upgrade QEMU.
> 
> 2. Implement a block driver in block/.  See iSCSI and other network
>    protocol drivers for examples.  Useful if your storage system offers
>    snapshot features.
> 
> 3. Implement vhost-user-scsi in your storage server.  You need to write
>    a virtio-scsi backend that runs in a separate userspace process on
>    the host.  You are limited to supporting the virtio-scsi device - no
>    IDE, SATA, virtio-blk, etc.  vhost-user-scsi is still under active
>    development and you may need to contribute to it if you hit
>    limitations/bugs.  Requires low-level knowledge of virtio.

Maybe also worth noting that 3. bypasses the block layer in QEMU, so you
can't use any features that it provides, like block jobs, backing files,
non-raw image formats, etc.

Kevin

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]