1. Field of the Invention
The present invention relates generally to the field of computer environments having virtual machines and storage systems.
2. Description of the Related Art
Virtual Machines. A virtual machine operating system running on a single host processor has the ability to create a plurality of virtual machines, each of which is an illusion of a real machine from a user""s standpoint. Each vita machine is a simulation of a real computer system environment, where ""several different operating systems can be running in virtual machines concurrently. Each operating system running in a virtual machine may be referred to as a guest operating system or as a xe2x80x9cguestxe2x80x9d.
One of the most widely used virtual operating systems is Virtual Machine Facility/Enterprise Systems Architecture (VM/ESA) provided by International Business Machines, Inc. VM manages an IBM System 390 computer and creates the illusion that each of several users operating from terminals with a complete System 390 computer. Several different guest operating systems are available for VM, including conversational systems (e.g., a Conversational Monitor System or CMS), multiple-access systems (e.g., VM/ESA), and batch or single users interactive systems (e.g., DOS/VSE).
A control program (CP) of VM running in the host processor manages the xe2x80x9crealxe2x80x9d resources (such as storage, processor, and input/output (I/O) resources) so that many independent and fully functional virtual machines appear to be doing their own processing using their own storage, processor, and I/O resources.
VM provides three types of virtual machines which are defined by their storage configurations: (1) a Virtual Real machine (V=R machine); (2) a Virtual=Fixed machine (V=F machine); and (3) a Virtual=Virtual machine (V=V machine). A V=R machine has a fixed, contiguous area of host real storage starting at xe2x80x9cpagexe2x80x9d zero. CP does not page this storage, so guest real storage maps to host real storage. A V=F machine also has a fixed, contiguous area of host real storage, but the area does not start at real page zero. CP does not page this storage, and thus guest real storage maps to host real storage. Because V=R and V=F machines receive preference in terms of storage and performance, these virtual machines are called xe2x80x9cpreferredxe2x80x9d virtual machines. A V=V machine has guest real storage that does not permanently map to host real storage. Rather CP pages the guest real storage of a V=V machine into and out of host real storage. Many V=R and V=F machines can be defined, but VM typically ensures some limitationsxe2x80x94e.g. that you do not have more than one V=R machine and five V=F machines (or zero V=R machines and six V=F machines) logged on at the same time.
A host processor may operate in either supervisor state or in problem state. CP runs on the real machine in supervisor state, where it has access to all privileged instructions. When CP dispatches a particular virtual machine, that virtual machine runs on the real machine but in problem state. The virtual machine may be in either virtual supervisor state or virtual problem state. For each virtual machine, CP keeps a control block containing virtual registers and a virtual state word. The virtual state word indicates the current state of the virtual machine and the virtual instruction counter.
When CP dispatches a virtual machine, the virtual machine executes real instructions on the real machine. Many interrupts occur because a virtual machine attempts to execute a privileged instruction normally acceptable only by VM. Since virtual machines are constrained to run in the real machine""s problem state, an interrupt results each time a virtual machine attempts a privileged instruction. Thus, program interruptions are the key to the interfacing between an executing virtual machine and CP.
When a virtual machine generates a program exception interrupt, CP gains control and determines the cause of the interrupt. If the virtual machine is executing in the virtual problem state, then CP passes the real program interruption directly to the virtual machine, which then processes the interrupt through its conventional interrupt-handling procedures. If, however, the virtual machine is operating in virtual supervisor state, then CP simulates the execution of the privileged instruction. To perform simulation, CP must determine what the virtual machine is attempting to accomplish. If I/O is being attempted, then CP performs any necessary mapping between virtual and real devices. If disk I/O is involved, then CP maps virtual track addresses to real track addresses. CP then schedules the real I/O operation corresponding to the a virtual I/O request, and returns control to the virtual machine""s operating system, which then continues operation as if it itself had initiated the I/O. This CP interruption causes a loss of I/O performance for virtual machines.
A Virtual Machine Assist feature, which has both hardware and software components, is a performance improvement option available to VM installations. Virtual storage operating systems, such as Multiple Virtual Storage (MVS) systems, execute in problem state while under control of VM/ESA. Such operating systems use a large number of privileged instructions that generate interrupts requiring CP""s attention and servicing. With the Virtual Machine Assist feature, however, the associated hardware intercepts and services many of these interrupts, resulting in significant performance benefits. With I/O Assist, also referred to as I/O Passthru or Start Interpretive Execution (SIE) Assist, significant I/O performance benefits are available.
In contrast with a basic mode associated with virtual partitioning, a host processor may alternatively operate in a logically partitioned (LPAR) mode. The LPAR mode provides partitioning of the processor across multiple physical or logical partitions. Each LPAR contains some portion of the processor and storage resources, some number of channel paths, and, if available, some portion of expanded storage. Since LPAR environments do not require CP translation or use, there are no I/O performance issues similar to those of VM. However, the flexibility of VM is lost with the use of LPARs.
Storage Systems. Many computer environments employ direct access storage device (DASD) subsystems for fast, efficient, and economical storage of data in a device which records and retrieves data in response to a reference of the data""s location. The principle device which supports direct access storage is a disk.
Like other input/output (I/O) and storage devices, DASDs are often connected to a host processor through one or more channel paths. A channel retrieves channel commands from a channel subsystem in main storage of the host processor. A channel command word (CCW) sent from the host processor specifies the particular I/O command to be executed, the storage area associated with the operation, the action to be taken whenever transfer to or from the area is completed, and other options. One type of channel architecture is the Enterprise Systems Connection (ESCON) architecture, which is built around fiber optic transmission technology.
A channel forwards each command to a storage controller which governs operations of the DASDs. The storage controller provides a path for data transfer (as well as for command and status information transfer) between the host processors and the DASDs. It also converts the data from a form acceptable to the host processor to a form acceptable to the DASDs. The storage controller may be referred to as a control unit, a storage subsystem, a head of string, an integrated file adapter, an integrated storage control, a storage director, etc.
More particularly, a storage controller interprets and executes channel commands forwarded from. the host processor. For example, SEEK commands position a DASD access mechanism. SEARCH commands cause comparisons between data from main storage and data on specified areas of DASDs. WRITE commands cause data to be transferred from main storage to specified areas of DASDs. READ commands cause data to be transferred from DASDs to main storage and checked for validity. Thus, it is the channel commands that control the operations of the involved storage devices. Another function of the storage controller is to furnish status information to the host processor as the channel commands are executed. For example, the storage controller indicates when the transfer of a particular unit of data has been completed. In a READ operation, for example, the storage controller indicates when the end of the data file has been detected.
In some cases, the storage controller of a DASD is housed in the same physical unit as the DASD. In others, it is separate. In still others, the functions of the DASD are effected by two complementary units. In some cases, storage controller functions are performed by equipment that is housed within the same physical unit as the host processor. xe2x80x9cShared DASDxe2x80x9d is typically used to describe the capability of accessing a DASD from two or more host processors. The accessing of a particular device is not concurrent or simultaneous by the host processors sharing it; rather, it is sequential. The sequence is determined by both hardware and software. A user installation may elect to allow data to be shared among host processors for any of several reasons. For example, scheduling of jobs is simplified and operator intervention is minimized. Instead of having to be moved from one system to another, a volume on a shared DASD can remain mounted and available to each system able to access it by means of the channel and/or string switch involved. As another example, the time and resources required to update data are minimized. When data must be added, deleted, or changed, only one update to a shared data set is needed. In contrast, multiple updates would be needed if each of several host processors had its own copy of the data set. In a multiple computer installation, backup and switch over to another computer when a hardware failure occurs is facilitated if the needed data is accessible to the other computer without having to move it. Finally, direct access storage space is saved. Only one copy of the shared data is required for current processing.
Sharing of a DASD between different host processors can be accomplished in any of several known ways. As examples, a two-channel switch may attach the storage controller to two channels on different processors; a four-channel switch may attach the storage controller to channels on different processors; and so on. When shared DASD capability is available, an 110 operation may be started to a shared device from any of the processors able to access the device. The processor must gain access to the device by means of a programmable switch. Each sharing processor vies for the switch to gain access into the pool of devices governed by the switch. The first requesting host processor gets the switch set to its interface. Then it can perform I/O operations to the device it addressed. When the switch returns to a neutral position, any other (or the same) can select another (or the same) device and have the switch set to its interface.
None of the sharing processors is generally aware of what other processors are doing with respect to data on the shared devices; data integrity is the responsibility of the using programs. To help insure data integrity, a RESERVE CCW can be issued to retain exclusive use of one or more of the shared devices while a data update is being performed. On the other hand, a RELEASE CCW can be issued to terminate the exclusive reservation. If a shared device has been. reserved for exclusive use, the channels through which the RESERVE CCW was issued will have access while the storage controller xe2x80x9clocks outxe2x80x9d any other channels attempting access.
To help provide the lockout mechanism for a RESERVE, each host processor generates a unique Path Group ID (PGID) and sends it to the storage controller through its group of channel paths upon initialization. The PGID allows the storage controller to distinguish which channel paths go to which host processors, and to associate the paths together into a logical grouping. When the RESERVE CCW is received, the storage controller uses the PGID to determine the scope of the RESERVE so that access to the storage device is blocked for all other hosts while the initiating host retains access through of all its channel paths.
Virtual Machines and Storage. A single DASD may be divided by CP into many minidisks, each of which may be allocated to a different virtual machine. Minidisks are subsets of full disks, and each consist of a range of cylinders. Each is treated by a virtual machine operating system as a complete physical disk device but one of smaller capacity than a full disk. CP handles the mapping of minidisks to real disks, but the space within each minidisk is managed by the operating system running on the virtual machine to which the minidisk is assigned.
In contrast to the sharing of minidisks, a single DASD may be shared between virtual guests where CP simulates the RESERVE and RELEASE for each guest requesting access. The storage controller still provides the lockout mechanism between different host processors using PGIDs, but CP distinguishes between its own virtual guests to provide the lockout mechanism therebetween. In order for CP to see and simulate the RESERVES, the I/O must be passed through CP""s CCW translation routines. These translation routines account for a relatively large percentage of I/O processing time, and therefore virtual guests operate with reduced I/O performance when sharing a DASD in this manner. CP does not presently provide simulation of ASSIGN and UNASSIGN for tape devices, which prevents more than one guest from sharing a tape device in this manner.
Alternatively, a DASD which is xe2x80x9cdedicatedxe2x80x9d is owned by a single virtual machine and not shared with other guests. The host processor may support a SIE instruction which allows for one or more preferred virtual guests to operate advantageously using I/O Assist. The SIE instruction puts a preferred virtual guest in complete control of hardware to which it has access, without undue processing by CP and thus better I/O performance. However, since the PGID is established by CP and is the same for all virtual guests of the same host processor, the storage controller cannot distinguish between different guests accessing storage using I/O Assist. Thus, sharing of a DASD is not presently available nor possible between preferred virtual guests of the same host processor under I/O Assist without compromising data integrity.
Accordingly, there is a need for an alternative to conventional virtual machine environments that do not accommodate the sharing of dedicated devices between virtual machine guests of the same host processor.
In a virtual machine environment, a virtual machine ID associated with a virtual machine is sent to a storage controller along with a request to access a storage device. The virtual machine ID is used by the storage controller along with a path group ID to determine the scope of the access request. Thus, virtual machines of a single host processor may share the storage device while both preserving data integrity and performing optimally.
USPTO Backgrounds
USPTO Backgrounds