[flagged]
vDPA: Support for block devices in Linux and QEMU
11–20 of 23 posts
Re: vDPA: Support for block devices in Linux and QEMU
#12Good timing considering the esxi news https://kb.vmware.com/s/article/2107518?lang=en_US
Wow, I knew things were getting really bad with VMWare, but I didn’t know they had got that bad… I liked ESXi, the free hypervisor was a good stepping stone to get people into the ecosystem and probably sold a lot of vSphere and vCenter licences down the line. Very glad I decided to use Proxmox (as the Broadcom acquisition had been announced) for the small cluster we set up at our business a year ago, it’s been super…
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 me.
Re: vDPA: Support for block devices in Linux and QEMU
#13Good timing considering the esxi news https://kb.vmware.com/s/article/2107518?lang=en_US
I think they will give up mindshare.
I use proxmox, which is hard to use but open. It is powerful, but you sort of have to be a sysadmin to climb the learning curve with it.
But I have lots of friends who are busy at home, but use vmware there. To them it is the same sort of "free" as proxmox.
They create an abstract model of vmware in their heads.
And when they're at work, they think of virtualization kinds of problems in terms of vmware. So at work, that's the tool they frequently reach for.
Re: vDPA: Support for block devices in Linux and QEMU
#14Is vDPA a standardization of the storage interfaces used by AWS Nitro?
https://www.allthingsdistributed.com/2020/09/reinventing-vir...
> The Nitro System is comprised of three main parts: the Nitro Cards, the Nitro Security Chip, and the Nitro Hypervisor. The Nitro Cards are a family of cards that offloads and accelerates IO for functions ... The Nitro architecture also enabled us to make the hypervisor layer optional and offer bare metal instances. Bare metal instances provide applications with direct access to the processor and memory resources of the underlying server.
Re: vDPA: Support for block devices in Linux and QEMU
#15RH 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 solutions to vDPA.
[0] https://www.redhat.com/en/blog/introduction-virtio-networkin... [1] https://www.redhat.com/en/blog/how-vhost-user-came-being-vir... [2] https://www.redhat.com/en/blog/achieving-network-wirespeed-o...
Re: vDPA: Support for block devices in Linux and QEMU
#16ah, RH and docker and their race to poke out of emulation/virtualization for fringe performance gains.
we will soon get to a point qemu will just be a job manager for software that plugs directly into local syscalls, like, you know, regular software running on your system.
Re: vDPA: Support for block devices in Linux and QEMU
#17> 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…
I don't get it either, and I'm a maintainer of SPDK which provides multiple implementations of virtualized devices and is frequently used inside DPUs to present storage devices. If I'm implementing a hardware device anyway, why would I not just use NVMe as the interface? NVMe is superior to virtio-blk in every way that I can think of. Even for a software device in userspace, why not use a technology like vfio-user to…
Another top-level comment has covered this at least with regards to networking, hasn't discussed the storage side as much:
https://news.ycombinator.com/item?id=39355644
Re: vDPA: Support for block devices in Linux and QEMU
#18Earlier quoted context omitted.
I don't get it either, and I'm a maintainer of SPDK which provides multiple implementations of virtualized devices and is frequently used inside DPUs to present storage devices. If I'm implementing a hardware device anyway, why would I not just use NVMe as the interface? NVMe is superior to virtio-blk in every way that I can think of. Even for a software device in userspace, why not use a technology like vfio-user to…
Another top-level comment has covered this at least with regards to networking, hasn't discussed the storage side as much: https://news.ycombinator.com/item?id=39355644
Yes, I've seen some clearer cases made for networking.
In networking there is no standard for the hardware interface. Every vendor does their own thing. Except many can at least handle virtqueues carrying virtio-net messages for the data path, so some framework like vDPA may make sense (I'd prefer to see a full NIC interface standard emerge instead).
In storage, however, the industry has agreed on NVMe. This is a full standard for control and data plane. All storage products on the market, including DPUs and SmartNICs, just present NVMe devices. So there's no case to be made for vDPA at all. It just isn't necessary.
Re: vDPA: Support for block devices in Linux and QEMU
#19Earlier quoted context omitted.
Wow, I knew things were getting really bad with VMWare, but I didn’t know they had got that bad… I liked ESXi, the free hypervisor was a good stepping stone to get people into the ecosystem and probably sold a lot of vSphere and vCenter licences down the line. Very glad I decided to use Proxmox (as the Broadcom acquisition had been announced) for the small cluster we set up at our business a year ago, it’s been super…
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).
Re: vDPA: Support for block devices in Linux and QEMU
#20Earlier quoted context omitted.
Another top-level comment has covered this at least with regards to networking, hasn't discussed the storage side as much: https://news.ycombinator.com/item?id=39355644
Yes, I've seen some clearer cases made for networking. In networking there is no standard for the hardware interface. Every vendor does their own thing. Except many can at least handle virtqueues carrying virtio-net messages for the data path, so some framework like vDPA may make sense (I'd prefer to see a full NIC interface standard emerge instead). In storage, however, the industry has agreed on NVMe. This is a ful…
Yes, I see your point and agree that NVMe can be used for the same purpose.
But several HW vendors have implemented virtio-net devices in their SmartNic and may find it convenient to support virtio-blk to reuse most of the building blocks.
As for vhost-user, it's perfect for VM use cases, but with containers or applications in the host, it's not easy to use. Whereas, a vDPA device (HW or SW) can easily be attached to the host kernel (using the virtio-vdpa bus) and be managed with the standard virtio-blk driver.