Hello, On 26/08/2025 16:42, vita...@yourcmc.ru wrote: > You've added a block device driver whitelist in Proxmox 9.0. It's more intended for specific driver options, but as it die's if a QEMU block device driver is not in the list it indeed also acts as allow list for those. > Could you please add Vitastor there? > > I mean this place: > https://git.proxmox.com/?p=pve-storage.git;a=blob;f=src/PVE/Storage.pm;h=1dde2b751a766a28af8d40df7149936691cca772;hb=HEAD#l145 > > $allowed_qemu_blockdev_options in PVE/Storage.pm. > > For Vitastor to work correctly, it needs to contain: > > vitastor => { image => 1, 'config-path' => 1, 'etcd-host' => 1, 'etcd-prefix' > => 1 }
Hmm, we could add that, but would prefer only doing so if the plugin is directly in QEMU already. That said, this is rather internal, so maintenance cost would be low, so could be still fine... I would like some other opinion on it though (CC @Fiona). > Vitastor is a high-performance alternative to Ceph with a similar > architecture (written totally from scratch) if you never heard of it. :-) I'm > the author. > > Current installation instructions are here: > > https://vitastor.io/en/docs/installation/packages.html > > https://vitastor.io/en/docs/installation/proxmox.html > > It'd be also cool if you could upstream my block driver plugin, currently I'm > releasing it as a QEMU patch + block/vitastor.c. It's not a problem for me to > continue doing that just as before, but I'd of course appreciate if you added > it to your QEMU packages. :-) To avoid any false expectations upfront: As of now we won't take your patches into our downstream build of QEMU. For us the main reason for why we never evaluated Vitastore more closely (yes, we heard of it) is that it seems there is a bus factor of 1, as basically all contributions seen to be "just" from you, and while that may even have some benefits w.r.t. a consistent and clean design it also means that if anything should happen (let's really hope not!) that won't allow (or want) you to continue working on Vitastore from one day to another, we would need to provide quite a bit of developer power to be able to understand the whole code base and maintain it further once we adopted this. As while we're prepared for some bug fix (investigations) and what not, like we are for every project we integrate, it's still a big difference w.r.t. risk management when there are not at least 3 somewhat active devs upstream, at least for projects at this scale. And while yes, reducing the complexity of Ceph while getting the same (or even more) performance is certainly a great goal (kudos for working on that and getting this far!), but for us Ceph is still manageable for now and it's wide adoption is a major benefit that makes much of it's pain tolerable. A smaller reason is C++, while I certainly do not want to blame C++ for all problems of Ceph, IMO lots of pain and complexity stems from that in Ceph, and while I cannot make any judgement for Vitastore, as I did not check out the source in any relevant manner, I'm worried that C++ needs a lot of attention and tooling to avoid such growth of complexity and making maintenance harder, especially once more developers are working on a project. While we got some expertise, most of our Devs have no deep C++ experience besides for some drive-by fix of a specific bug. But that all said, why not upstream to QEMU directly? IMO that would help much more people, improve willingness for adoption for users and reduce overall maintenance cost for you and naturally also for us, if we would (hypothetically) take this in. AFAICT it would not be _that_ much change for QEMU. Anyhow, I wish you the best of luck and I hope Vitastore can overcome the initial "chicken and egg" inertia that such projects face. Maybe some of our devs (or experienced users) get to do a closer evaluation of your project in the context of Proxmox VE on a calmer day. best regards Thomas _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
