[pve-devel] [PATCH qemu-server 4/4] implement PoC migration to remote cluster/node

[Fabian Grünbichler]

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?