| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 28 |
| Nodes: | 6 (1 / 5) |
| Uptime: | 44:38:11 |
| Calls: | 422 |
| Calls today: | 1 |
| Files: | 1,024 |
| Messages: | 90,244 |
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.
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 ?
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.
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?
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?
There is vMotion for virtual machines on ESXi, but that's not exactly
the same.
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)
* 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)
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.
In article <vp5dig$2dnk8$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> 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.
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.
vMotion which does that for ESXi was mentioned in what you chose not to quote.
In article <67b66f14$0$712$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 2/19/2025 5:26 PM, Dan Cross wrote:
In article <vp5dig$2dnk8$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> 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.
I don't know what you mean when you say, "restricted to a
cluster instead of any systems."
If you mean that this somehow
makes managing state during process migration easier, then no,
not really; all of the same caveats apply. For instance,
if a program is using (say) a GPU for computation, part of
migrating it will be extracting whatever state it has in the
GPU out of the GPU, and replicating it on the destination
system.
At one point, the internal numbering of cores in the GPU was
visible to code running on the GPU, creating an $n \choose k$
fingerprinting problem for migration.
Besides, clusters can contain heterogenous systems.
On 2/19/2025 9:26 PM, Dan Cross wrote:
In article <67b66f14$0$712$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
[snip]
Yes. Which becomes a little easier when restricted to a
cluster instead of any systems.
I don't know what you mean when you say, "restricted to a
cluster instead of any systems."
A and B being in a cluster instead of being two
standalone nodes.
If you mean that this somehow
makes managing state during process migration easier, then no,
not really; all of the same caveats apply. For instance,
if a program is using (say) a GPU for computation, part of
migrating it will be extracting whatever state it has in the
GPU out of the GPU, and replicating it on the destination
system.
At one point, the internal numbering of cores in the GPU was
visible to code running on the GPU, creating an $n \choose k$
fingerprinting problem for migration.
A VMS server process will not be using GPU.
I guess as part of the migration the process would need to
be non-CUR and release CPU (and GPU if VMS adds support for
CUDA or similar in the future).
Main memory will need to be migrated. And cluster will
not help with that.
But cluster with shared storage will help with disk files.
And cluster with shared SYSUAF will help with identity.
And cluster with shared queue database will help with jobs.
Besides, clusters can contain heterogenous systems.
Yes.
The nodes would need to be compatible.
Mixed architecture cluster is definitely out
of the question.
:-)
On 2/19/2025 5:26 PM, Dan Cross wrote:
In article <vp5dig$2dnk8$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> 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.
In article <vp65ns$2gh03$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
On 2/19/2025 9:26 PM, Dan Cross wrote:
In article <67b66f14$0$712$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
[snip]
Yes. Which becomes a little easier when restricted to a
cluster instead of any systems.
I don't know what you mean when you say, "restricted to a
cluster instead of any systems."
A and B being in a cluster instead of being two
standalone nodes.
Oh I see, you're using cluster here as a shorthand to
mean that they're in the same administrative domain.
If you mean that this somehow
makes managing state during process migration easier, then no,
not really; all of the same caveats apply. For instance,
if a program is using (say) a GPU for computation, part of
migrating it will be extracting whatever state it has in the
GPU out of the GPU, and replicating it on the destination
system.
At one point, the internal numbering of cores in the GPU was
visible to code running on the GPU, creating an $n \choose k$
fingerprinting problem for migration.
A VMS server process will not be using GPU.
Sure. GPUs, as compute accelerators, are just one example.
It could be some other resource. The point is, process-level
migration is not a panacea; ksplice has its place, even with
its limitations.
Lawrence D'Oliveiro <ldo@nz.invalid> 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.
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.
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?
There is vMotion for virtual machines on ESXi, but that's not exactly the same.
Migrating whole VM will also migrate _current_ kernel. The whole point
of orignal question is updating kernel.