[PVE-User] Automatic migration before reboot / shutdown? Migration to host in same group?

[Uwe Sauter]

Thomas,

>>> An idea is to allow the configuration of the behavior and add two additional behaviors,
>>> i.e. migrate away and relocate away.
>> What's the difference between migration and relocation? Temporary vs. permanent?
> 
> Migration does an online migration if possible (=on VMs) and the services is already running.
> Relocation *always* stops the service if it runs  and only then migrates it.
> If it then gets started on the other side again depends on the request state.
> 
> The latter one may be useful on really big VMs where short down time can be accepted
> and online migration would need far to long or cause congestion on the network.

Ah, ok. So relocation is migration without "online" checked (UI) or "qm migrate" without "--online"?

>>>> (Please don't comment on whether this setup is ideal – I'm aware of the risks a single chassis brings…)
>>> As long as nodes share continents your never save anyway :-P
>> True, but impossible to implement for approx. 99.999999% of all PVE users. And latencies will be a nightmare then, esp. with
>> Ceph :D
> 
> Haha, yeah, would be quite a nightmare, if you haven't your own sea cable connection :D

Even then the latency adds up by approx. 1 millisecond per 100km…


>>> Quasi, a maintenance mode? I'm not opposed to it, but if such a thing would be done
>>> it would be only a light wrapper around already existing functionality.
>> Absolutely. Just another action that would evacuate the current host as optimal as possible. All VMs that are constrained to a
>> specific node group should be migrated within that group, all other VMs should be migrated to any node available (possible doing
>> some load balancing inside the cluster).
> 
> I'll look again in this, if I get an idea how to incorporate this without breaking edge cases I can give it a shot,
> no promise yet, though, sorry :)

>> If there are valid concerns against this reasoning, I'm open to suggestions for improvement.
> 
> Sounds OK, I have to think about it if I can propose a better fitting solution regarding our HA stack.
> An idea was to add simple dependencies, i.e. this group/service should
> not run on the same node as the other group/services. Not sure if this is quite specialism or more people would profit from it...

I'd like to hear you suggestions if you find the time…

>> Interesting idea. Didn't have a look at priorities yet.
>>
>> Request for improvement: In "datacenter -> HA -> groups" show the configured priority, e.g. in a format
>> "nodename(priority)[,nodename(priority)]"
> 
> Hmm, this should already be the case, except if the default priority is set.
> I added this when I reworked the HA group editor sometimes in 4.3.

Well, I didn't play with priorities yet so it might be that it just didn't show up in my case.


Thank you,

	Uwe