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).
vDPA: Support for block devices in Linux and QEMU
21–23 of 23 posts
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…
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
#23RH 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…