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

[Chris Scheers]

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.

In general, with modern hypervisors, you don't "move" CPUs around.

CPUs are not dedicated.  CPUs are shared.  They are scheduled to VMs as 
a resource.

Ideally, when an OS gets to its idle state, it releases the CPU(s) back 
to the hypervisor.

This is why the hypervisor may need to have some knowledge of and/or 
cooperation of the guest OS.*

For most x86 hypervisors, execution of the HALT instruction seems to be 
enough to return a CPU to the hypervisor.  When an interrupt 
subsequently occurs in the VM, a CPU is allocated and the VM is restarted.

So you can overcommit the number of CPUs when starting VMs.  This is 
where virtual machines shine in cost savings.  Instead of having a bunch 
of machines running at 10-20% utilization, you can have a few machines 
running at 75% utilization.


* The "knowledge" that the hypervisor needs can be very limited.  I 
think that for most x86 hypervisors, execution of the HALT instruction 
is sufficient to release a CPU.  This doesn't actually require knowledge 
of the OS.

Odd bit of trivia: In the Windows 2000 uniprocessor x86 HAL, a HALT is 
executed in the idle loop.  Windows 2000 uniprocessor works well as a 
VM.  In the stock Windows 2000 multiprocessor x86 HAL, no HALT is 
executed in the idle loop and all CPUs in the VM consume 100% of a host 
CPU.  This is not so friendly.

-- 
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360            Internet: chris at applied-synergy.com
   Fax: 817-237-3074