From: cross@spitfire.i.gajendra.net   
      
   In article ,   
   Waldek Hebisch  wrote:   
   >Lawrence D'Oliveiro  wrote:   
   >> On Wed, 19 Feb 2025 15:05:35 -0500, Arne Vajhøj wrote:   
   >>   
   >>> * 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)   
   >>   
   >> Linux virtualization migrates entire VMs that way, rather than individual   
   >> processes.   
   >   
   >Migrating whole VM will also migrate _current_ kernel.  The whole   
   >point of orignal question is updating kernel.   
      
   Indeed.  But if the goal is to update the host, and not the   
   guest, it's an acceptable method, provided you can meet the   
   requirements vis resources et al, and can handle the limitations   
   with respect to direct access to devices.  And if the workloads   
   in question can tolerate the drag on performance during the   
   migration (no matter how you shake it, there's a mandatory   
   blackout period where the guest is not running on either the   
   host or target systems).   
      
   I designed the live migration protocol used for Bhyve in the   
   Oxide architecture.  Minimizing that period was an explicit   
   design goal, but at some point you simply have to bottle up the   
   last bits of state from the source and move them to the   
   destination.   
      
           - Dan C.   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)