Hi

I am new to this group.
Let me please provide a bit of background why I am making this post.
At my first IT job in 1999 there was an IBM 9221 running VM/ESA and on
top of that VSE/ESA. My involvement with that machine was
(unfortunately) very sporadic, I had to look after other tech.
I got very basic training on the machine, enabling me to do some simple
things ('v net, act' and stuff like that). Unfortunately I forgot most
of what I knew back then over the last 25 years due to not being
involved with mainframes professionally.
While I do play with mainframe tech in my spare time a bit, I cannot
claim any in-depth knowledge.
One thing that was explained to me back then was very impressive to me
and stuck in my mind.

You can install VM on top of VM

My knee-jerk question to my instructor back then was:

How deep can you go?

He didn't know.

Ever since, I have an idea in my head that comes back occasionally.
Can you install VM 'recursively'?
What I mean by that is the following:
Can you prepare an IPL-able VM tape that does the following:
* IPL (obviously)
* without user interaction:
* Some arithmetic to assess suitable values for the next step like
available memory (storage) and available DASD space
* create the necessary infrastructure to run a VM guest
(user account, minidisk, etc.) with the pre-computed values from the
last step
* IPL the same tape that was used originally for the 'bare-metal'
installation inside the just created VM
* Configure the guest system so that it can be reached from the
outside via a 3270 session or some such

This process is supposed to run as unattended as possible, continuing
until some inherent nesting limitation of VM is reached or a required
resource like storage or DASD space is exhausted.

I am lacking the experience with VM to assess whether this is possible
at all or if perhaps it is possible in principle but only with later
versions of VM than VM/370 or something like that.

Anyways, I would be interested in the opinion of people on this mailing
list regarding this topic.
Perhaps you'll tell me this is a stupid idea, but hey ho.

-Alex

On Tue, Mar 11, 2025 at 11:30:46AM -0400, Ross Patterson via groups.io wrote:

On Tue, Mar 11, 2025 at 10:50 Alexander Huemer via groups.io <aziD5eeth9fe=
[email protected]> wrote:

You can install VM on top of VM

My knee-jerk question to my instructor back then was:

How deep can you go?

He didn't know.

Technically, there is no limit. Diagnose code x'0000' will attempt to
return up to 5 levels of CP info. Practically, the "top level" system gets
slower and slower as you add more levels of CP underneath it. It was
common to run two levels for testing purposes, back in the 70s and 80s, but
not for production, due to poor performance. With today's real and
emulated mainframes, you could easily do more than that in production.

That sounds encouraging, thanks for laying that out.
I would think too that performance shouldn't be a problem.
This is very much an academic exercise anyways. The idea is just to
demonstrate that it is possible, not to solve any real-world problem.

Ever since, I have an idea in my head that comes back occasionally.
Can you install VM 'recursively'?
What I mean by that is the following:
...

Yes, but you'd have to write that installation process yourself. Nothing
in the normal VM installation makes that simple.

Right. The problem is, I know so little about VM and its ecosystem that
I don't even know where to start.

I am lacking the experience with VM to assess whether this is
possible at all or if perhaps it is possible in principle but only
with later versions of VM than VM/370 or something like that.

Successive later versions of VM have added more and more functions to
improve automation capabilites. Stuff like the Secondary Console Image
Facility.

Sounds great, but I can't say I really know what that is.

In case anybody on this list is interested to tinker on this, please let
me know, on of off list.

-Alex

开云体育

On Tue, Mar 11, 2025 at 11:30:46AM -0400, Ross Patterson via groups.io wrote:

On Tue, Mar 11, 2025 at 10:50 Alexander Huemer via groups.io <aziD5eeth9fe=
[email protected]> wrote:

You can install VM on top of VM

My knee-jerk question to my instructor back then was:

How deep can you go?

He didn't know.

Technically, there is no limit.  Diagnose code x'0000' will attempt to
return up to 5 levels of CP info.  Practically, the "top level" system gets
slower and slower as you add more levels of CP underneath it.  It was
common to run two levels for testing purposes, back in the 70s and 80s, but
not for production, due to poor performance.  With today's real and
emulated mainframes, you could easily do more than that in production.

That sounds encouraging, thanks for laying that out.
I would think too that performance shouldn't be a problem.
This is very much an academic exercise anyways. The idea is just to 
demonstrate that it is possible, not to solve any real-world problem.
 

Ever since, I have an idea in my head that comes back occasionally.
Can you install VM 'recursively'?
What I mean by that is the following:
...

Yes, but you'd have to write that installation process yourself.  Nothing
in the normal VM installation makes that simple.

Right. The problem is, I know so little about VM and its ecosystem that 
I don't even know where to start.

I am lacking the experience with VM to assess whether this is 
possible at all or if perhaps it is possible in principle but only 
with later versions of VM than VM/370 or something like that.

Its possible with every version of VM and there are as far as I know no hard coded limits limits. Performance suffers the deeper you go because many instructions need to be interpreted at each level.
At some point you will run out of real memory because in order to do certain things pages need to be locked in memory.
? ?

Successive later versions of VM have added more and more functions to
improve automation capabilites.  Stuff like the Secondary Console Image
Facility.

Sounds great, but I can't say I really know what that is.

In case anybody on this list is interested to tinker on this, please let 
me know, on of off list.

I would say even with the later facilities you can't automate something that generates an arbitrary depth of VMs.
Lets take things at a simple level. Each VM needs its own system disk that you IPL from. These need to be known in some way, by the top level VM before you start.
So if they are physical disks the top level VM needs to have a separate IO address in DMKRIO.
Yes you can use minidisks but that doesn?t help much. The number of cylinders is defined at startup...

-Alex

Dave

As mentioned, technically there's no limit. But in practice there is. It all has to do with the overhead you get when running in virtual environments and especially when CPU instructions need to be emulated. I do work with modern z-environments, in a current z/VM virtualization overhead is about 7%, emulation is effectively about 100% overhead, more or less the same is true for any VM/ESA or VM/XA system.

You have to consider SIE processing. () Because of SIE your guest can get access to the processor directly, but when SIE is not available all CPU load needs to be emulated by the host levels. SIE can run three levels. In the past you were running a mainframe in basic mode. You could run three levels with SIE: first level (or native), second level and third level. SIE was available in the 370 XA architecture, so VM/370 doesn't include SIE, you would need VM/XA or newer for that.

Then we got LPAR mode mainframes. Starting zArchitecture LPAR mode is the only mode available. PR/SM is basically the first level of virtualization. So now you can run two SIE levels in an LPAR, the VM Host (now refered to as native or first level) and a guest under VM (now refered to as second level). Any guest running under the second level guest (a third level guest) cannot benefit from SIE processing. Remember, in LPAR mode this third level guest is actually a fourth level guest. So in practice, when running a VM LPAR with a VM guest and a VM or VSE guest under the second level VM, the host now needs to emulate all CPU instructions.

Some 15 years ago we wanted to run a customer in a second level environment. Indeed we could run their VM?(z/VM -> customer z/VM guest -> z/VSE guests) as second level guest, but their VSE systems couldn't use SIE. As a result the load was emulated and CPU usage doubled and also introduced a lot of other timing related issues. That wasn't an option for that customer, but we did run another customer as second level environment for a couple of years and they accepted the increased CPU load for their environment.

Apart from running on the real hardware, we obviously focus on Hercules. So in this case all CPU needs to be emulated, going from x86 hardware to an emulated S360-S370-S390 CPU. Next we run VM in hercules. As stated, SIE is only found in VM/XA and later so SIE is not available in VM/370 and a guest CPU needs to be emulated in any level of virtualization. But for argument sake, Hercules implements the ESA/390 architecture, including SIE, so if you run a newer VM within this system SIE is available. But only for three levels, and the S390 CPU is emulated to begin with.

But technically, you can run Hercules -> VM -> Linux -> Hercules -> Linux etc (or whatever configuration you like). The only thing is, your guest may be very slowwww as the overhead will double with every new level, especially when SIE is not available in any of the levels (VM/370 or any level beyond third level virtualization).

At least you're not the first to try this. I have seen a virtualization up to 7 levels running various configurations of hercules, VM and Linux.

Regards, Berry.

Op 11-03-2025 om 15:48 schreef Alexander Huemer via groups.io: