Live data from Hacker News

vDPA: Support for block devices in Linux and QEMU

stefano-garzarella.github.io

21–23 of 23 posts

Re: vDPA: Support for block devices in Linux and QEMU

#21
post #19
post #12

Earlier quoted context omitted.

I'm really worried who is going to handle network and raid going forward. LSI was the standard for hardware raid, 3com and others big network names. Now they are Broadcom, which basically means: * do as little as possible * axe most support * screw the little guy * milk milk milk * no real heavy R&D This means, to me, that lots of hardware and software is being handled far less diligently than Boeing. And that scares…

Hardware RAID is much less of a necessity nowadays than it was before. There are multiple options for highly performant/redundant storage, be it localised to a single box or across multiple boxes (such as ZFS or Ceph).

Yes exactly, between ZFS and Ceph I'm not too worried - and at the bleeding edge, NVMe is just changing the game completely because the drives are becoming so fast that they need their own dedicated PCIe lanes, so you don't want to bottleneck it through an HBA in any case, and the HBA just increases access latency.

Re: vDPA: Support for block devices in Linux and QEMU

#22

> One of the significant benefits of vDPA is its strong abstraction, enabling the implementation of virtio devices in both hardware and software—whether in the kernel or user space. This unification under a single framework, where devices appear identical for QEMU facilitates the seamless integration of hardware and software components. I honestly don’t know what this means. Is it faster? Is it more secure? Why would…

Ceph Block Device 3rd Party Integrations: https://docs.ceph.com/en/latest/rbd/rbd-integrations/ : Kernel Modules, QEMU, libvirt, Kubernetes, Nomad, OpenStack, CloudStack, LIO iSCSI Gateway, Windows, qemu: https://docs.ceph.com/en/latest/rbd/qemu-rbd/#qemu-and-block... `cephadm bootstrap` requires docker or podman and ssh: https://docs.ceph.com/en/latest/cephadm/install/#bootstrap-a... Ceph Object Gateway: radosgw: ht…

S3 or radosgw are not very relevant to a discussion about block storage devices.

Ceph's RBD is "special" in the sense that the client understands the clustering, and talks to multiple servers. If you wanted that in the mix, you'd have to run a local Ceph client -- like the Ceph software stack exposing block devices from kernel does. The only way I can see vDPA being relevant to that is to avoid middlemen layers, VM -> host kernel block device abstraction -> Ceph kernelspace RBD client. But the block device abstraction is pretty thin.

The real use case for vDPA, when talking about storage, seems to be standardizing an interface the hardware can provide. And then we're back to "why not NVMe?".

(Disclaimer: ex-Ceph-employee)

Re: vDPA: Support for block devices in Linux and QEMU

#23
post #15

RH has a blog series which motivates and introduces vDPA. For a start, read their post on virtio-networking and vhost-net [0], continue with virtio-networking and DPDK [1] and finally read "Achieving network wirespeed in an open standard manner: introducing vDPA" [2]. In particular the last link has a lot of diagrams, recaps a lot of the virtio-networking topics and finally has a table which compares the other soluti…

That seems to talk about networking only, while the blog post talks about storage. For networking I get it, there's no vendor-independent data path standard for easy virtualization there. But for storage, NVMe is supposed to be that.
Post reply on HN