Am 27.04.22 um 09:05 schrieb Thomas Lamprecht: > 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.
My first attempt using a widgetcolumn with a storage selector failed, as it would issue an API call for each disk...I'll try to come up with some way of sharing/fixing the store to make it work. In v3, I forgot to group the override settings in a fieldset, will do so in v4. > >> >> 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 I sent a v3 yesterday with something similar. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
