On 25.04.22 09:28, Fabian Ebner wrote: > 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?
exactly what I thought too. > > 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? hmm, possibly > > 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. would a more general src:dest map help, for example (just to give the very rough direction meaning here): not present or `scsi1:backup` <- would be restored as in the backup (config) `scsi1:store=foo` <- as in config put on another storage `scsi1:preserve` <- preserve from existing installation being overwritten The actual left/right hand sides would need to get fleshed out to fit our use cases best, but _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
