[Info-vax] Reloading device drivers on x86-64 VMS

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of JF
> Mezei
> Sent: 08-Mar-15 5:06 PM
> To: info-vax at info-vax.com
> Subject: Re: [New Info-vax] Reloading device drivers on x86-64 VMS
> 
> If we're going to be asking for me the moon, might as well ask for the
> moon:
> 
> VMS should be able to reload itself, dynamically updating all running
> images with pointers to updated shareable images, drivers etc.
> 
> In essence, you should be able to do a rolling upgrade of VMS without
> quitting any processes.
> 
> 
> Seriously though, there needs to be a paradigm consideration. In the
> past, rolling upgrades meant using clustering capabilities with dual
> boot nodes and enough nodes to maintain service as you progressively
> reboot all nodes into the upgraded system disk from one of 2 boot nodes
> and eventually upgrade the other boot node and do load balancing by
> rebooting a few nodes.
> 
> The ability to reboot a node, shut it off for hardware maintenance etc
> is something that is necessary in a large data centre with hundreds of
> nodes.
> 
> But for VMS's remaining niche market, is that still the case ?  Or are
> we looking at much smaller systems with single nodes etc ? With single
> nodes or non clustered nodes (because clustering is so expensive), then
> in-situ upgrades without reboot become interesting. But if most
> customers are on clusters and have the ability to reboot individual
> nodes easily, then in-situ upgrades are less important.

Proactively shutting down OVMS systems in a cluster with zero service 
availability impact can be done today with proper App, batch and DNS 
planning. Simply set logins =0 on the node to be shut down and the VMS 
DNS will interpret this as "current connections and users continue, but
no new connections will be sent to that OS instance." When all users &
connections have dropped from that system, then that server can be
shutdown (even in prime time) rebooted with zero service availability 
impact. There might be a few seconds of transition, but users usually 
attribute these to network delays - certainly no worse that when 
VMware transitions apps from one OS instance to another.

I agree it would be great for a future capability to have this on a single
node without clustering. This would make it easier for mission critical
environments like manufacturing and other 24x7x365 shops to have
this capability without adding additional complexity and costs.

Re: high cluster pricing. I agree but the fix is to either make cluster pricing 
Part of the OS or at least much, much less expensive. When clustering 
Is one of the strengths of an OS and many do not use it because of the 
cost, then that is an issue.

Imho, the pricing model at some V9.next point in the future should not 
be based on complicated sockets/cores which confuses everyone, but 
rather a combination of an annual support subscription based host/OS 
instance model in combination with a tier level e.g. workstation, dept, 
enterprise .. perhaps a Dev tier as well?

Regards,

Kerry Main
Back to the Future IT Inc.
 .. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com