Am 23.04.22 um 11:38 schrieb Thomas Lamprecht: > On 21.04.22 13:26, Fabian Ebner wrote: >> Namely, if there is a storage in the backup configuration that's not >> available on the current node. > > Better than the status quo, but in the long run all the "force all volumes to > a single storage" > on restore and also migrate isn't ideal for the case where one or more > storages do not exist on > the target node. An per-volume override would be nicer, but may require some > gui adaptions to > present that in a sensible way with good UX. >
In the UI, it could simply be part of the disk grid (proposed in patch manager 3/3), only showing up for drives selected from the backup? In the back-end for migration, we have a storage-storage map, but here we'd need a drive-storage map. It'd be possible to extend the 'storage' parameter for the create/restore API call to be such a map, but I wonder if going for a 'restore-drives' parameter being such a map (and replacing the proposed 'preserve-drives' parameter) would be better? The downside is, we'd have to choose between A) preserve disk and config B) preserve disk as unused for the drives that are not present in the backup. A) would be more convenient in the partial restore context, but B) is the current default. Thus we need to keep B) if 'restore-drives' is not specified at all for backwards-compatibility, but can choose A) if 'restore-drives' is specified. But doing so seems a little inconsistent regarding user expectation. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
