Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support

[Ketan Nilangekar]

We need to confirm the perf numbers but it really depends on the way we do 
failover outside qemu.

We are looking at a vip based failover implementation which may need some 
handling code in qnio but that overhead should be minimal (atleast no more than 
the current impl in qemu driver)

IMO, the real benefit of qemu + qnio perf comes from:
1. the epoll based io multiplexer
2. 8 epoll threads
3. Zero buffer copies in userland code
4. Minimal locking

We are also looking at replacing the existing qnio socket code with memory 
readv/writev calls available with the latest kernel for even better performance.

But again this is something that will come in the near future. For now the 
existing qnio implementation can give us adequate performance even if we need 
to modify it to handle vip based failover.

Ketan

> On Oct 25, 2016, at 1:01 PM, Paolo Bonzini <address@hidden> wrote:
> 
> 
> 
>> On 25/10/2016 07:07, Ketan Nilangekar wrote:
>> We are able to derive significant performance from the qemu block
>> driver as compared to nbd/iscsi/nfs. We have prototyped nfs and nbd
>> based io tap in the past and the performance of qemu block driver is
>> significantly better. Hence we would like to go with the vxhs driver
>> for now.
> 
> Is this still true with failover implemented outside QEMU (which
> requires I/O to be proxied, if I'm not mistaken)?  What does the benefit
> come from if so, is it the threaded backend and performing multiple
> connections to the same server?
> 
> Paolo
> 
>> Ketan
>> 
>> 
>>> On Oct 24, 2016, at 4:24 PM, Paolo Bonzini <address@hidden>
>>> wrote:
>>> 
>>> 
>>> 
>>>> On 20/10/2016 03:31, Ketan Nilangekar wrote: This way the
>>>> failover logic will be completely out of qemu address space. We
>>>> are considering use of some of our proprietary 
>>>> clustering/monitoring services to implement service failover.
>>> 
>>> Are you implementing a different protocol just for the sake of
>>> QEMU, in other words, and forwarding from that protocol to your
>>> proprietary code?
>>> 
>>> If that is what you are doing, you don't need at all a vxhs driver
>>> in QEMU.  Just implement NBD or iSCSI on your side, QEMU already
>>> has drivers for that.
>>> 
>>> Paolo