Internal organization of z86VM
z/VM
While not part of z86VM, IBM’s z/VM product provides the base virtual machine manager for hosting the x86 guests. Each x86 operating image operates as a separate z/VM guest and they share I/O processing and management servers as other z/VM guests.
Binary Translator
This component reads the x86 object code, determines what instruction needs to be executed and branches to a routine to handle that particular instruction. Some instructions have a natural affinity to the z architecture and become a quick translation. Other instructions that have to manage context across instruction operations, such as for i/o or process management will be calling other routines for in depth processing.
Dispatch
Dispatch component is necessary to manage threads and processes for the guest x86 virtual machines. It will maintain context for all users and manage their internal dispatch priorities.
I/O device drivers
With the x86 guests running on IBM Z, a collection of devices must be available to those images as well. Hard Disk drivers will map x86 guest file system to locally attached mainframe disk drives. Screen device drivers, tape subsystems and network attached file systems are examples of other devices drivers that are provided with z86VM.
Interrupt handler
A large advantage of the IBM Z architecture is its in interrupt handling. It effectively manages work across multiple processes and can run at 100% processor utilization without fear of failure. The z86VM interrupt handler takes advantages of these same capabilities, but applies them to the x86 workloads. As a result, the processor utilization of x86 virtual machines can run far higher than a native x86 environment. These interrupts may be a result of paging, i/o or thread dispatch of workloads.
Time Management
The original 8088 processor of the x86 architecture had a “pit timer” that would add to a counter and through this recurrent “tick” it was copied into future x86 chips to provide the timer function. This was one of the most difficult pieces of the architecture to recreate. But each x86 operating system running as a virtual machine must depend on an accurate clock and timer processing to maintain the integrity of files, databases and transaction processing. More modern operating systems can handle a Network Time Protocol or external timer. For either of these class of operating systems, this timer function is a critical dependency.
Memory Mapping
x86 operating systems use memory pages to host the real and virtual storage associated with their systems. These pages are mapped to the IBM Z paging infrastructure. Detailed algorithms and exploitation of IBM Z architecture have been undertaken to share as many pages (system kernel and shared files) as possible across x86 virtual guests to reduce the amount of real memory that is consumed by the overall z/VM environment.
I/O Scheduler
Another benefit of the IBM Z architecture is its asynchronous I/O processing. Again, z86VM takes advantage of that architecture by scheduling independent read and write operations to the storage and network system while dispatching other units of work. Once complete, an interrupt will be scheduled and work on that virtual guest will resume.
Virtual Memory Manager/TC Scheduler
Virtual machine manager ( Main Loop ), translated code (fragment) scheduler. As part of the z86VM environment, if code segments are repeatedly used, for example, the kernel operating system or a specific application, those code fragments will be cached for reuse to speed up run time performance. The principal is very similar to the JAVA Just in Time compiler. Rather than re-interpret every code string, if it recognizes the code string after several uses, it will compile it to speed up performance. In the case of z86VM, the code isn’t compiled, but rather, an IBM Z architecture binary is created from it’s translated x86 binary so that the code can be quickly executed. z86VM will also recognize common code segments across multiple guest virtual machines. Those code segments will be cached in a common memory to each virtual guest for rapid deployment.
Primary z/VM Virtual Machines
Z86MNT
This is the primary virtual machine for managing all other virtual machines within the z86VM functionality. The Z86 EXEC is the primary mechanism for operating the environment, including Installation, customization, start, stop and debug commands. Each of these commands is documented in a later section.
Z86MNT is the default name for this guest virtual machine, but it could be tailored based on other z86VM environments running within the same z/VM operating environment.
Z86IO
This is the virtual machine that is tasked with translation and operation of the x86 i/o system and it’s mapping to the z architecture i/o system. Imagine that z86VM operates a SAN environment shared across all the x86 guest virtual machines. z86IO would act as the SAN controller and manage access for all the individual guest virtual machines.
z86user
Each x86 guest virtual machine will have it’s own owning user id. This can be defined as part of the installation or using several of the Z86 EXEC command options. Each user owns their own files for security purposes. These id’s can be cloned copies of each other or different resources, such as virtual memory and locally attached file system, can be defined for the various needs of different virtual machines.
The functional tasks of z86VM
There are certain major areas that must be defined for the functional operation of the z86VM environment. These areas are managed via the Z86 EXEC and the commands associated with that exec. Each section, below, will highlight the commands necessary and in a later section, the commands will be described in more detail.
z86VM Boot Drive
Each x86 user in the z86VM environment must have its own virtual machine defined and that must be a bootable x86 operating system. Multiple users may share the same operating system image, which will reduce systems administration time and patch management. However, some users may prefer Linux, some may prefer Windows and then there may be release variations for those operating systems.
The goal of a business deploying z86VM should be to reduce the number of variations of operating system images to reduce change, policy and security administration controls necessary for the many OS variants.
I/O Boot Drive
The ZIO Module must have its own boot drive. This is a shared virtual machine to process the I/O of all z86 virtual guest images. It will translate the requests of the PC based fixed block architecture virtual devices to the real hardware running IBM Z format devices.
X86hd Drives
x86hd Drives are one or more 3390 volumes which are formatted (FINIT) as x86 hard drive space. Each z86 guest is allocated a portion of disk space directed by the ‘ hdmemory’ profile parameter.
User Definitions
Each z86VM user must be properly defined to z/VM as a guest virtual machine. Then, each user must have its boot operating system drive associated with it. They also need to have their x86 drives associated with it.
These users may also be automatically started and stopped via admin commands. This is especially helpful when the guests are acting as Daemons or server machines.
Two operations are required for z86 User definitions. First, the z/VM directory must be updated to include the user as a valid virtual machine guest. That will be described in a later section.
Second, those z86 users must be defined to z86VM.
Admin Defined Components of z86VM
The following diagrams are intended to provide a visual overview of the z86VM environment. In this example, we’ll use the MGT server, the IO server and two z86 users. We’ll also have two x86 defined disks to meet their combined storage needs.
