[Info-vax] OpenVMS on x86 and Virtual Machines -- An Observation

[gezelter at rlgsc.com]

On Wednesday, January 30, 2019 at 5:07:16 PM UTC-5, Dave Froble wrote:
> On 1/30/2019 2:50 PM, Stephen Hoffman wrote:
> > On 2019-01-30 18:57:52 +0000, Phillip Helbig (undress to reply said:
> >
> >> Since VMS will soon run natively on x86, what is the motivation to run
> >> it on some sort of emulator?
> >
> > Emulation involves differing instruction sets and differing
> > architectures and run-time instruction translation.  The underlying
> > hardware is typically of a different architecture with a different
> > instruction set.
> >
> > Apps and operating systems running under virtualization use the native
> > instruction set and architecture of the hardware with no translations,
> > and with a few specific operations either invoking the hypervisor or
> > reserved to the hypervisor.  Outside of those operations, instructions
> > and apps run at full speed, untranslated, directly on the underlying
> > hardware.
> >
> > For you?  Maybe you'll be running parts of your environment under
> > virtualization eventually, as it'll let you build and test different
> > environments—multiple instances of OpenVMS, and mixes of OpenVMS and
> > other operating systems—on the same hardware.  That might well involve a
> > OpenVMS cluster operating within a single box for instance, while you're
> > migrating your plethora of old Alpha hardware to fewer or potentially to
> > one x86-64 box.  You may well find that a single small x86-64 box runs
> > your entire existing Alpha load, after all.  Or you might eventually be
> > testing a newer product release or a newer installation of OpenVMS,
> > without disrupting the main installation. Getting your entire
> > environment upgraded to the VSI releases for Alpha, and then clustering
> > with the x86-64 boxes and getting your apps ported.
> >
> > For other folks, virtualization means that their OpenVMS apps can be
> > hosted on a shared server, and that folks can boot up multiple OpenVMS
> > instances for unexpected loads.  This is consolidating hardware to fewer
> > boxes, and this can also involve temporarily renting hardware and
> > software rather than the expense of purchase what may well be excessive
> > hardware and software capacity.  If you're running a back-end for a
> > gaming environment, you can either purchase enough hardware for your
> > maximum load and hope that some extremely-popular game doesn't exceed
> > that capacity, and also hope that the aggregate load can support the
> > costs of what can often be excess capacity.  It also means that folks
> > don't necessarily have to staff as many data centers, and can boot up
> > hosts that are geographically local to the clients.   Or geographically
> > appropriately-distant, in the case of disaster preparedness.  Etc.
> >
> > Rolling in a system image—a fully-configured environment—and booting it
> > as needed is pretty handy for deployment, testing, and for recovery,
> > too.  With virtualization, it's possible to effectively pause the whole
> > running environment out to disk, transfer it to another host, reload the
> > guest onto another hypervisor on another box, and restart the paused
> > processing.
> >
> > Some organizations outsource the hosting for their servers, and other
> > folks prefer to have their own shared data centers and shared hosting.
> >
> > Can you do this with hardware?  Sure.  But you're going to be purchasing
> > a whole lot of capacity you won't be using, if you don't want to
> > saturate.  And moving copies of guests is easier than moving backups
> > around.
> >
> > I routinely have guests running on the local desktop box, as that allows
> > me to use apps and tools that require specific Linux or BSD
> > distributions.  I don't need to reboot, or switch to other hosts, or to
> > even need or use additional hardware to do this.
> >
> > For some of the parallels here with virtualized hosts, ponder what
> > virtualized memory and virtualized storage and virtualized networking
> > have each provided.
> >
> >
> 
> Many good reasons to have the VM capability.  However, don't lay it on 
> too thick.  When talking about capacity, TANSTAAFL, spinning up another 
> guest on HW that is already running at max isn't going to give you any 
> more capacity.  Probably less.
> 
> I really should start getting some experience with VMs.  Any suggestions 
> for good ones for a beginner to learn?  Is using WEENDOZE to run the VM 
> Ok?  Or do I need to learn to run some Linux?  Which one?
> 
> -- 
> David Froble                       Tel: 724-529-0450
> Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA  15486

David,

VirtualBox runs quite nicely on an appropriate notebook. I have often used it for when I need a Linux system for one thing or another. As an additional benefit, it is completely portable, no network link needed to gain access. 

One of the nice things about VM provisioning is the ease of creating expendable test systems. Cloning a system to do a potentially dangerous test? Less than a minute on my laptop. Need to run a piece of dicey software. Bring up a VM with cloned mass storage.

Many have observed that creating a virtual instance is the work of seconds. Procuring and installing hardware takes hours if not days or longer. The cost of creating/destroying virtual instances is pennies compared to tens of thousands US$. Check out what Amazon charges for a non-dedicated instance. Pocket change. I have seen university faculty tell students to create Amazon instances for courses rather than go through the university.

- Bob Gezelter, http://www.rlgsc.com