From: arne@vajhoej.dk   
      
   On 2/19/2025 5:26 PM, Dan Cross wrote:   
   > In article ,   
   > Arne Vajhøj   wrote:   
   >> I am thinking about a scenario like:   
   >> * cluster with node A and B   
   >> * critical process P that for whatever reason does not work   
   >>    running concurrent on multiple nodes runs on A   
   >> * node A needs to be taken down for some reason   
   >> * so VMS on node A and B does some magic and migrate P from A to B   
   >>    transparent to users (obviously require a cluster IP address or   
   >>    load balancer)   
   >   
   > While this may be an acceptable method to "hotpatch" a host with   
   > minimal disruption to whatever workload it's running, it is   
   > completely unlike what ksplice does.  For one, it requires that   
   > sufficient resources exist in wherever you'd migrate the process   
   > to for the duration of the update.   
      
   That is a requirement.   
      
   :-)   
      
   >                                    Moreover, it requires that   
   > all aspects of state that are required to resume execution of   
   > the process are accessable and replicable on other, similar   
   > hardware.   
      
   Yes. Which becomes a little easier when restricted to a   
   cluster instead of any systems.   
      
   > Many hyperscalar cloud providers do something similar for   
   > updates, but there are serious limitations and downsides; for   
   > example, direct passthru to hardware devices (storage, compute   
   > accelerators, etc) can make it impossible to move a VM.   
      
   Moving VM's is common. Robert started by mentioning vMotion.   
      
   Arne   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)