[pve-devel] [PATCH storage v4 09/27] plugin: introduce new_backup_provider() method

Fabian Grünbichler f.gruenbichler at proxmox.com
Fri Apr 4 09:15:29 CEST 2025


> Andreas Rogge <andreas.rogge at 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




More information about the pve-devel mailing list