home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.os.vms      DEC's VAX* line of computers & VMS.      264,096 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 262,413 of 264,096   
   Dan Cross to arne@vajhoej.dk   
   Re: Ksplice equivalent for VMS ?   
   19 Feb 25 22:26:48   
   
   From: cross@spitfire.i.gajendra.net   
      
   In article ,   
   Arne Vajhøj   wrote:   
   >On 2/19/2025 2:50 PM, Robert A. Brooks wrote:   
   >> On 2/19/2025 14:10, Arne Vajhøj wrote:   
   >>> On 2/19/2025 10:05 AM, Robert A. Brooks wrote:   
   >>>> On 2/19/2025 08:25, Simon Clubley wrote:   
   >>>>> Oracle have a kernel patching tool called Ksplice that they acquired   
   >>>>> back in 2011. It allows their support contract Linux users to apply   
   >>>>> many Linux kernel patches without having to reboot the server:   
   >>>>>   
   >>>>> https://en.wikipedia.org/wiki/Ksplice   
   >>>>>   
   >>>>> Given the high-availability mindset for VMS users, I wonder if VSI ever   
   >>>>> considered creating something similar for VMS ?   
   >>>>   
   >>>> No.   
   >>>   
   >>> What about process migration?   
   >>   
   >> Like Galaxy on Alpha?   
   >   
   >I thought Galaxy was multiple logical systems on one physical system.   
   >DEC answer to IBM LPAR.   
   >   
   >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.  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.   
      
   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.   
      
   Ksplice updates code in the running system, basically thunking   
   out function calls to point to new code.  It has fairly   
   significant limitations, but doesn't require any sort of   
   migration.   
      
           - Dan C.   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca