[Info-vax] IBM nearing deal to acquire Red Hat

[etmsreec at gmail.com]

On Saturday, 4 May 2019 22:57:42 UTC+1, Dave Froble  wrote:
> On 5/4/2019 2:22 PM, Bill Gunshannon wrote:
> > On 5/4/19 12:53 PM, Dave Froble wrote:
> >>
> >> Probably because of concepts.  A reboot is not normally a part of
> >> running VMS.  That might not be so in other environments.
> >>
> >
> > Another myth that should be put to rest.  When the University was
> > still running on VMS it was managed by someone most people here
> > would recognize as an authority  on VMS management.  They used
> > to reboot the systems regularly and never left them running for
> > more than a month with out a reboot.  Just because some people
> > let them go longer and even see some value in the bragging
> > rights doesn't necessarily mean it's a good idea.
> >
> > bill
> >
> >
> 
> If the purpose was to recover some CPUs, I doubt a month is appropriate.
> 
> Galaxy was a great idea.  If it wasn't, would we have VMs today?  Not 
> the same thing, but, in the same direction.
> 
> I was not trying to re-start the old arguments about uptime and 
> re-boots.  I was just stating that "re-boot" is not a common occurrence 
> with some VMS people.  I got no problems with re-boots.
> 
> The topic was Galaxy, and it appears from other posts that the ability 
> to move CPUs around is still a unique capability.  Or perhaps not.
> 

Never thought I'd be posting this - shoot me now.

Solaris, with its Guest LDoms, has the capability to add and/or remove CPUs and memory from running guests without reboots.  Caveats obviously apply, in that they need to be running a specific minimum OS version etc., and they need to have at least one CPU and some memory to be running.

So far as I can ascertain, they can do some jobs via scripting on the physical box, but still not as adaptable and functional as Galaxy.

Things get really odd with SPARC, though.  A core on the physical processor runs multiple threads, and the threads are seen as CPUs by the guest.