On March 10, 2020 7:25 am, Thomas Lamprecht wrote: > On 3/10/20 7:08 AM, Dietmar Maurer wrote: >>> I like the second option >>> >>> "mapping of source storage/bridge to target storage/bridge" >> ... >>> Also, it could be great to save mapping for reusing later >> >> Maybe in the new remote configuration (@fabian)? >> > > Yeah, IMO the second options gives you enough control without overkilling > on required mappings. > We also want to overwrite the default mapping from the remote config on a per > job basis, the storage map would be also nice to have for intra-cluster local > disk migration. >
I also thought about putting it into remote.cfg (as new entity/entities? or as part of a cluster or node definition?). overriding in the API or CLI can easily happen even as extension of the current parameter: targetstorage => 'foobar' (put every source storage on target storage 'foobar') targetstorage => '1' (put every source storage on an identically named target storage) targetstorage => 'foo:bar, bar:baz, foobar' (put foo on bar, bar on baz, and everything else on foobar) the (legacy) targetstorage parameter can then easily be mapped to the new storage_map parameter: targetstorage => '1' == targetstorage => '$id1:$id1, $id2,$id2, ..' for all storage IDs on source node storage_map could be given in the API or CLI to use a pre-defined storage map. do we need a stored mapping for intra-cluster migration as well? we could put the same entities into the node config as well, and the order of precedence would be: storage_map from remote.cfg/node config (if we store them as part of a remote entry, and not just as separate entities) storage_map given as parameter targetstorage given as parameter and the same thing for bridge_map / targetbridge? _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
