> Andreas Rogge <andreas.ro...@bareos.com> hat am 03.04.2025 18:08 CEST > geschrieben: > Am 03.04.25 um 09:24 schrieb Wolfgang Bumiller: > > I *believe* `qemu-nbd` should be able to bind all the storage types we > > want to restore to to /dev/nbdXY devices, which would give the provider > > a bunch of block devices to write to in whichever way they want to, so > > the provider would then only need to figure out how to receive the data > > and forward that to the devices. > > We'll need to try. > > That's pretty much what I had hoped for.
just because that recently came up in another context - there is also qemu-storage-daemon which can export anything qemu can read/write via different interfaces - NBD, but also a vhost-user-blk device via a socket, or a "fake raw file" provided via FUSE ;) given the annoying properties of NBD on the kernel side (Fiona can tell you more ;)), we might want to check out those as well. not sure how much performance overhead the FUSE variant has, it would probably be the easiest to implement considering both our and the backup provider end. of course, if you already have an NBD client implementation and just need the export data without it being "bound" on the PVE side, that would also be fairly simple ;) same applies to vhost-user-blk - in both cases, if you already know how to write to such a "block device", then PVE would just need to - allocate the image - export it via qemu-storage-daemon - tell you where the socket/NBD server is/make it accessible _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
