US9910691B2 - Hypervisor to I/O stack conduit in virtual real memory - Google Patents

Hypervisor to I/O stack conduit in virtual real memory Download PDF

Info

Publication number
US9910691B2
US9910691B2 US14/955,242 US201514955242A US9910691B2 US 9910691 B2 US9910691 B2 US 9910691B2 US 201514955242 A US201514955242 A US 201514955242A US 9910691 B2 US9910691 B2 US 9910691B2
Authority
US
United States
Prior art keywords
request
formatted
service provider
hypervisor
specific
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US14/955,242
Other versions
US20160085581A1 (en
Inventor
Jorge R. Nogueras
Morgan J. Rosas
James Y. Wang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US12/135,999 priority Critical patent/US9208003B2/en
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US14/955,242 priority patent/US9910691B2/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WANG, JAMES Y., Nogueras, Jorge R., ROSAS, MORGAN J.
Publication of US20160085581A1 publication Critical patent/US20160085581A1/en
Application granted granted Critical
Publication of US9910691B2 publication Critical patent/US9910691B2/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061Partitioning or combining of resources
    • G06F9/5077Logical partitioning of resources; Management or configuration of virtualized resources
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/541Interprogram communication via adapters, e.g. between incompatible applications
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/545Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45579I/O management, e.g. providing access to device drivers or storage

Abstract

Provided is a virtual interface, a “Forwarder” and a Virtual Block Storage Device (VBSD). The virtual interlace is the interface between a Command/Response Queue (CRQ), which receives CRQ commands from a hypervisor, and a common interface of the Forwarder. The Forwarder receives I/O commands in a format associated with the common interface and converts the commands into a generic I/O format. The reformatted command is transmitted to the VBSD. The hypervisor sends a read or write (R/W) request to the virtual interface, which passes the request to the Forwarder. The Forwarder receives the request, converts the request into a form readable by the VBSD and transmits the converted request to the VBSD. The VBSD transmits the request to a block storage device and returns the response to the Forwarder. The Forwarder replies to the request from the virtual interface with the response from the ABSD. The virtual interface then responds to the hypervisor.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS

The present application is a continuation and claims the benefit of the filing date of an application entitled, “Hypervisor to I/O Stack Conduit in Virtual Real Memory” Ser. No. 12/135,999, filed Jun. 9, 2008, now U.S. Pat. No. 9,208,003, issued Dec. 8, 2015, assigned to the assignee of the present application, and herein incorporated by reference.

FIELD OF THE DISCLOSURE

The claimed subject matter relates to a method for simplify processing associated with Input/Output (I/O) associated with a hypervisor in a computing system.

BACKGROUND OF THE INVENTION

International Business Machines Corp. (IBM) of Armonk, N.Y. has been at the forefront of new paradigms in business computing. During the 1960's. IBM invented the concept of a hypervisor. A hypervisor is software running on a particular hardware platform that enables multiple operating systems (OSs) to run on the platform at the same time. Typically, this feature is accomplished by “virtualizing,” or hiding technical details, of a computer resource from users of that resource. Virtualization may create the appearance to end users or other resources that a single computer resource functions as multiple virtual resources or that multiple physical resources appear as a single virtual resource.

During the 1990's, IBM developed the concept of logical partitions, or “LPARs.” While the hypervisor is directed to the virtualization of operating systems, LPAR focuses on the partitioning of computer hardware resources. For example, a physical machine can be partitioned into multiple LPARs, each hosting a separate operating system. In data storage systems, LPARs enable multiple virtual instances of a storage array to exist within a single physical array. Further virtualization of computer memory has lead to virtual real memory (VRM). With the advent of VRM, data servers may create LPARs that are over-subscribed in terms of real memory usage. In other words, if a server has 32 GBs of real memory, LPARS may be created that use 40 GB of VRM. To perform this, a hypervisor running on the server executes page-in and page-out requests to disk on behalf of the LPARs, much like virtual memory managers (VMMs) currently do within an OS. Memory paged-out is written to physical disk storage handled by a virtual I/O server (VIOS), which is a special purpose LPAR that provides other client LPARs with virtualized I/O resources.

Input/Out (I/O) request are typically handled by one or more device drivers, or a “conduit,” that act in tandem to deliver a command for the hypervisor to an I/O stack. The conduit receives a request from the hypervisor to access a specific portion of memory for I/O, such as a block storage device. The conduit translates the request into a command that is understandable to the block storage device and transmits the request to the storage device. The block storage device processes the request and transmits a response to the conduit, which forwards the response to the hypervisor.

Currently available conduits handle specialized processing based upon the data types associated with either the hypervisor or the I/O block storage device. Adding functionality to the conduit related to data content rather than merely data transfer requires the creation of a new type of conduit.

SUMMARY

Provided is novel conduit configured such that the hypervisor does not need to include logic for communicating directly with an I/O storage device. The novel conduit includes three devices, a virtual interface, a “Forwarder” and a Virtual Block Storage Device (VBSD). The virtual interface is the interface between a Command/Response Queue (CRQ), which receives CRQ commands from the hypervisor, and a common interface of the Forwarder. The Forwarder receives I/O commands in a format associated with the common interface and converts the commands into a generic I/O format understood by the VBSD. The reformatted command is transmitted to the VBSD, which issues commands to the native I/O stack.

The hypervisor sends a read or write (R/W) request to the virtual interface, which passes the request to the Forwarder. The Forwarder receives the request, converts the request into a form readable by the VBSD and transmits the converted request to the VBSD. The VBSD transmits the request to the block storage device and returns the response to the Forwarder. The Forwarder then replies to the request from the virtual interface with the response from the ABSD. The virtual interface then responds to the hypervisor.

Also provided is an operation-specific module responsible for understanding and intelligent processing of data that is transmitted between the hypervisor and the I/O stack. The module understands a state diagram of a particular operation and configures any ancillary devices that may be necessary for successful completion of the operation. The module also initiates and processes state changes required for the operation, implement any processing algorithms necessary for the operation, converts data into a format readable by both the hypervisor and the I/O stack and performs any additional manipulations pertinent to the operation.

For example, if the operation is a memory paging operation, in which case the operation-specific module is referred to as a “Pager,” the module includes specialized algorithms for caching, read-ahead, I/O coalescing, as well as logic to dynamically configure block storage devices to be used as paging devices if necessary. A Pager would also include logic for processing state changes necessary for the paging of memory, e.g. to support redundant paging devices.

One advantage of the disclosed technology is that the hyper visor does not need to include logic to directly communicate with the I/O storage device. This allows for changes in both CRQ commands and the I/O stack interface to have minimal or no impact on the conduit. In addition, changes to CRQ commands have no impact on the I/O stack and changes to the I/O block storage device have no impact on the hypervisor.

This summary is not intended as a comprehensive description of the claimed subject matter but, rather, is intended to provide a brief overview of some of the functionality associated therewith. Other systems, methods, functionality, features and advantages of the claimed subject matter will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description.

BRIEF DESCRIPTION OF THE FIGURES

A better understanding of the claimed subject matter can be obtained when the following detailed description of the disclosed embodiments is considered in conjunction with the following figures, in which:

FIG. 1 is one example of a computing architecture the supports the claimed subject matter.

FIG. 2 is a block diagram illustrating the relationship among certain modules of FIG. 1.

FIG. 3 is a block diagram of the Forwarder of FIGS. 1 and 2 in more detail.

FIG. 4 is a flowchart of a Setup Forwarder process.

FIG. 5 is a flowchart of a Setup Stream process that implements a portion of the Setup Forwarder process of FIG. 4.

FIG. 6 is a flowchart of an Execute Central Process (CP) process.

DETAILED DESCRIPTION OF THE FIGURES

Although described with particular reference to data storage, the claimed subject matter can be implemented in any information technology (IT) system in which functional modularity is desirable. Those with skill in the computing arts will recognize that the disclosed embodiments have relevance to a wide variety of computing environments in addition to those described below. In addition, the methods of the disclosed technology can be implemented in software, hardware, or a combination of software and hardware. The hardware portion can be implemented using specialized logic; the software portion can be stored in a memory and executed by a suitable instruction execution system such as a microprocessor, personal computer (PC) or mainframe.

In the context of this document, a “memory” or “recording medium” can be any means that contains, stores, communicates, propagates, or transports the program and/or data for use by or in conjunction with an instruction execution system, apparatus or device. Memory and recording medium can be, but are not limited to, an electronic, magnetic, optical, electromagnetic or semiconductor system, apparatus or device. Memory and recording medium also includes, but is not limited to, for example the following: a portable computer diskette, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), and a portable compact disk read-only memory or another suitable medium upon which a program and/or data may be stored.

One embodiment, in accordance with the claimed subject, is directed to a programmed method for modularizing computer functionality. The term “programmed method”, as used herein, is defined to mean one or more process steps that are presently performed; or, alternatively, one or more process steps that are enabled to be performed at a future point in time. The term programmed method anticipates three alternative forms. First, a programmed method comprises presently performed process steps. Second, a programmed method comprises a computer-readable medium embodying computer instructions, which when executed by a computer performs one or more process steps. Finally, a programmed method comprises a computer system that has been programmed by software, hardware, firmware, or any combination thereof, to perform one or more process steps. It is to be understood that the term “programmed method” is not to be construed as simultaneously having, more than one alternative form, but rather is to be construed in the truest sense of an alternative form wherein, at any given point in time, only one of the plurality of alternative forms is present.

FIG. 1 is one example of a computing architecture 100 the supports the claimed subject matter. Architecture 100 includes two computing systems, a computing system 1 102 and a computing system 2 132. Systems 102 and 132 are communicatively coupled via a network 124. Systems 192 and 132 are also coupled to a storage area network (SAN) 126 that provides both systems 102 and 132 a connection to a shared data storage 128. Systems 102 and 132 could also be coupled through any number of communication mediums such as but not limited to, a wide area network (WAN) (not shown) and direct connections. Systems 102 and 132 may be the same of different types of computing systems and, in fact, the disclosed technology facilitates multiple types of systems to access common resources such as data storage 128. In the following example, the claimed subject matter is described with respect to an operation specific, or owner, module 118 that accesses data storage 122. Of course, it should be understood that the task of data storage and retrieval is only one example of resource utilization and that there are many possible computing system configurations, of which computing system architecture 100 is only one simple example, applicable to the claimed subject matter.

System 102 includes a monitor 104, a keyboard 106 and a mouse 108, which together facilitate human interaction with system 102. System 102 also includes data storage 122. Although snot illustrated, system 132 includes at least one each of a monitor, keyboard, mouse and data storage like 104, 106, 108 and 122. In addition, systems 102 and 132 also include, but not shown for the sake of simplicity, the components typically found in computing systems such as, but not limited to a power supply, data busses, one or more central processing units (CPUs), multiple data storage devices and so on.

In this example, computing system 1 102 includes owner module 118, a kernel 110, a virtual block storage device (VBSD) 112, a hypervisor 114 and a virtual asynchronous services interface (VASI) 116. Owner module 118 includes a novel component that implements the claimed subject matter, i.e. a forwarder module, or Forwarder, 120. Forwarder 120 is described in more detail below in conjunction with FIG. 3.

Throughout the Specification a specific example of an owner module, or a “Pager,” is employed to describe the claimed subject matter. A Pager is an owner-specific module that handles I/O requests. It should be understood that, although the claimed subject matter is described at time with respect to an owner-specific module and at time with respect to a “Pager,” there are many owner-specific operations and modules that would benefit from the disclosed technology. The coordination and execution of components 119, 112, 114, 116, 118 and 120 to implement the claimed subject matter are described in more detail below in conjunction with FIGS. 2-6.

FIG. 2 is a block diagram illustrating the relationship among certain modules of FIG. 1, specifically modules 110, 112, 114, 116, 118 and 120. Owner module 118 includes instantiations of Forwarder 120. As shown, Forwarder 120 handles communication between owner module 118 and both VBSD 112 and VASI 116. Owner module 118 includes any high level processing or functionality necessary for its own specifications, which may include any processing tasks executed by system 102. In other words, owner module represents a generic processing task and any such task may be configured to implement the disclosed technology. As explained above module 118 is sometimes referred to as Pager 118 because a module that handles communication between an owner module 118 and both VBSD 112 and VASI 116, or Pager, is one example of the type of functionality that may be implemented using the disclosed technology. Another example is a hibernator process, which is a computer process that, alter a period of inactivity, saves CPU memory (not shown) into non-volatile storage such as data storage 122 and powers down components of the computer to save power or battery life.

Owner module 118 drives the configuration and unconfiguration of Forwarder 120 (see FIG. 4) and there is a global table of each type of owner module 118 that include as forwarder. For example, if owner module 118 executes a particular type of task, such as a pager, and another owner module executes the same type of task, there would be one global table shared by both owner modules. However, if another owner module executes another task, such as a hibernator, there is a separate global table for that particular owner module and any other owner modules executing the task.

FIG. 3 is a block diagram of the Forwarder 120 of FIGS. 1 and 2 in more detail. Although each extension of kernel I/O that deals with VBSD 112 (FIGS. 1 and 2) and VASI 116 (FIGS. 1 and 2) appears to be its own separate kernel extension, the portion of the kernel extension which deals with interfacing with VBSD 112 and VASI 116 are common called the Forwarder 120. Forwarder 120 includes a Setup module 142, a Communication Module 144, a Conversion module 146 and a VASI table module 148, a VBSD table 150 and a Stream Table 150.

Setup module 142 is responsible for the creation and initialization of Forwarder 120, including the creation of flight table 150. Communication module 144 handles input and output (I/O) transmitted and received from other components of computing system 102 (FIG. 1). In the example of an owner module such as owner module 118 that is configured as a Pager, Forwarder 120 transmits and receives communications from both VASI 116 (FIGS. 1 and 2) and VBSD 112 (FIGS. 1 and 2). Conversion module 146 is responsible for formatting communication from a first format corresponding to one particular component into a second format corresponding to a second component and vice versa. Of course that may be more than two types of components and corresponding formats that employ Forwarder 120 so it should be understood that any necessary format conversion are handles by Forwarder 120.

VASI table 148 stores information necessary for communication between Forwarder 120 and VASI 116. VBSD table 150 stores information necessary for communication between Forwarder 120 and VBSD 112. Stream table 152 stored information on pending requests. Information stored in Stream table 152 in conjunction with a Pager include, but is not limited to, pointers to the corresponding request, a parsed buffer and a pointer to a scatter gather list. The uses of modules 142, 144, 146, 148, 150 and 152 are described in more detail below in conjunction with FIGS. 4-6.

FIG. 4 is as flowchart of as Setup Forwarder process 200. In this example, process 200 is executed by owner module 118 (FIGS. 1 and 2) of computing system 102 and executed to create and initialize Forwarder 120 (FIGS. 1-3). In other words, process 200 is executed to create Forwarder 120 for owner-specific module 118, which in this example is an I/O paging module or “Pager.” It should be understood, that owner module 118 drives the creation, configuration and unconfiguration of Forwarder 120 and there is a global table of each type of owner module 118 that include a forwarder. For example, if owner module 118 executes a particular type of task, such as a pager, and another owner module executes the same type of task, there would be one global table shared by both owner modules. However, if another owner module executes another task, such as a hibernator, there is a separate global table for that particular owner module and any other owner modules executing the task.

Process 200 starts in a “Begin Setup Forwarder (FOR)” block 202 and proceeds immediately to a “Create Global Table (GT)” block 204. During block 204, process 200 creates a global forwarder table. As explained above in conjunction with FIG. 3, there is one global table for each type of owner module, e.g. multiple modules that handle memory paging tasks share a single global table. Once a global table is established for a particular type of task, the global table does not need to be created again. During block 204 the fields of the global table are also initialized with all pertinent data fields such as, but not limited to, the number of forwarder instances, a list of streams and any function pointers needed for communication. The first time through process 200 many of these variables are set to a value of ‘0’ and are updated later.

During a “Symbol Exchange” block 206, process 200 communicates with VBSD 112 to retrieve function pointers necessary to initiate communication. These symbols are exchanged and stored in the global table. Symbol exchange and storage occurs the first time process 200 is initiated with respect to a particular type of owner module 118 and the stored symbols remain valid for the life of Forwarder 112. During a “Create Destroy Process (DP)” block 208, a destroy process (not shown) is started, initialized and put to sleep. The destroy process is created to monitor and drive deletion of both streams and process 200 itself. The destroy process is initialized with variables such as, but not limited to, global event anchors. Once put to sleep, the destroy process is awakened on two occasions: 1) a stream is unconfigured; and 2) process 200 is being unconfigured. When a stream is unconfigured, the destroy process drives the deletion process, including clean up of any relevant tables and other memory and notification of other processes. When process 200 is unconfigured, the destroy process closes open streams, deallocates memory for streams and sessions, notifies other processes and then terminates itself.

During a “Create Stream” block 210, process 200 establishes the communication paths necessary for communication with VASI 116 and VBSD 112. The creation of a stream is described in more detail below in conjunction with FIG. 5. During a “Create Session” block 210, process 200 queries VASI 116 (FIG. 1) to determine required parameters to drive traffic between VASI 116 and Forwarder 120. Forwarder 120 then requests a session with VBSD 112 using the parameters received from VASI 116. During an “Update Global Table” block 212, the global table created during block 204 is updated to reflect the addition of the new session.

FIG. 5 is a flowchart of a “Setup Stream” process 250 (see process block 210, FIG. 4). Process 250 starts in a “Begin Setup Stream” block 252 and proceeds immediately to an “Allocate Memory” block 254. During block 254, process 250 allocates memory necessary for the stream. During an “Establish VASI” block 256, process 250 drives the exchange of information necessary for the setup and initialization of VASI 116 (FIGS. 1 and 2). After successful initiation or VASI 116 communication, control proceeds to a “Create Block Device (BD)” block 258. During block 258, Forwarder 120 requests from VBSD 112 (FIGS. 1 and 2) the creation of a block memory device. Based upon the parameters exchanged during block 256.

During an “Execute Central Process (CP)” block 260, Forwarder 120 initiates a Central Process 300 (see FIG. 6) that spawns all threads necessary for operation of the stream. Process 300 executes throughout the lifetime of the stream. Finally, process 250 proceeds to an “End Setup Stream” block 269 in which process 250 is complete.

FIG. 6 is a flowchart of a “Setup Central Process (CP)” process 300. In this example, process 300 is stored on data storage 122 (FIG. 1) and executes on a processor (not shown) associated with computing system 1 102 (FIG. 1).

Process 300 starts in as “Begin Execute Central Process (CP)” block 302 and proceeds immediately to a “Receive Request” block 304. During block 304, hypervisor 114 (FIGS. 1 and 2) drives an I/O request that is received by VASI 116 (FIGS. 1 and 2). During a “Create Structure” block 306, VASI 116 formats the request in the form of a parsed buffer, formatted in a structure specific to VASI 116, and a scatter gather list. The parsed buffer information includes data such as, but not necessarily limited to, the size of the I/O request, a correlator parameter for tracking the request, and a pointer to the parsed list of scatter gather entries. Each entry in the scatter gather list provides information for a single I/O operation and includes, but is not limited to, a base address, an offset from the base address, a number of bytes of the entry and whether the corresponding request is a read or write operation.

During a “Transmit Structure” block 308, process 300 transmits the buffer created during block 306 to Forwarder 120. During a “Store Request” block 310, Forwarder 120 stored the request in a list of outstanding requests, used to verify incoming responses (see process block 314). Information stored in conjunction with an incoming request includes, but is not limited to, times the request was received and responded to and a parsed buffer and a pointer to a scatter gather list. During a “Forward Request” block 312, process 300 forwards the request to VBSD 112 (FIGS. 1 and 2).

Once a request has been forwarded to VBSD 112 during block 312, process 300 waits for a reply from VBSD 112 during, a “Receive Response” block 314. A response received during block 314 from VBSD 112 includes a pointer to the parsed buffer created during block 310 that correspond to the original request. Once a response is received, process 300 proceeds to an “Update Records” block 316, during which Forwarder 120 removes the corresponding entry from the list of outstanding requests stored during block 310. During a “Forward Response” block 318, the response received during block 314 is forwarded to VASI 116. Control then returns to Receive Request block 304 in which Forwarder 120 waits for the next communication request and processing proceeds as explained above.

Finally, process 300 is halted by means of an interrupt 320, which passes control to an “End Execute CP” block 319 in which process 300 is complete. Interrupt 318 is typically generated when system 102 or owner module 118 of which process 300 is a part is itself halted. During nominal operation, process 300 continuously loops through blocks 304, 306, 308, 310, 312, 314, 316 and 318, processing I/O request generated by hypervisor 114.

While the claimed subject matter has been shown and described with reference to particular embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and detail may be made therein without departing from the spirit and scope of the claimed subject matter, including but not limited to additional, less or modified elements and/or additional, less or modified blocks performed in the same or a different order.

Claims (23)

We claim:
1. A method for handling a request from a hypervisor in a computing system, comprising:
receiving, at a virtual interface from a hypervisor, a request directed to a service provider device;
converting the request to a format common to a plurality of two or more different types of operation-specific modules to produce a formatted request;
transmitting the formatted request to an operation-specific module of the plurality of operation-specific modules;
converting, by the operation-specific module, the formatted request to a command format corresponding to the service provider device;
transmitting, by the operation-specific module, the service provider device formatted request to the service provider device;
receiving a response from the service provider device at the operation-specific module;
converting, by the operation-specific module, the response from the service provider device to the format common to the plurality of two or more different types of operation-specific modules to produce a formatted response;
transmitting, by the operation-specific module, the formatted response to the virtual interface;
converting the formatted response to a format corresponding to the hypervisor; and
transmitting the hypervisor formatted response to the hypervisor.
2. The method of claim 1, wherein the operation-specific device is a paging device and the service provider device is a virtual block storage device (VBSD).
3. The method of claim 1, wherein the operation-specific device is a hibernation module.
4. The method of claim 1, wherein the request is a Read/Write (R/W) operation.
5. The method of claim 1, wherein the request directed to the service provider device is converted to a command data-link interface (CDLI) format.
6. The method of claim 5, further comprising processing the CDLI formatted request received at the operation-specific module based upon a content type of the CDLI formatted request.
7. The method of claim 6, wherein the content type is a paging Input/Output (I/O) request.
8. The method of claim 7, the processing comprising:
a caching process;
a read-ahead process; and
an I/O coalescing process.
9. An apparatus for handling a request from a hypervisor in a computing system, comprising:
a processor;
a computer-readable storage medium;
a hypervisor;
a virtual interface;
an operation-specific module; and
instructions, stored on the computer-readable storage medium and executed on the processor, for performing a method, the method comprising:
receiving, at the virtual interface from the hypervisor, a request directed to a service provider device;
converting the request to a format common to a plurality of two or more different types of operation-specific modules to produce a formatted request;
transmitting the formatted request to an operation-specific module of the plurality of operation-specific modules;
converting, by the operation-specific module, the formatted request to a command format corresponding to the service provider device;
transmitting, by the operation-specific module, the service provider device formatted request to the service provider device;
receiving a response from the service provider device at the operation-specific module;
converting, by the operation-specific module, the response from the service provider device to the format common to the plurality of two or more different types of operation-specific modules to produce a formatted response;
transmitting, by the operation-specific module, the formatted response to the virtual interface;
converting the formatted response to a format corresponding to the hypervisor; and
transmitting the hypervisor formatted response to the hypervisor.
10. The apparatus of claim 9, wherein the operation-specific device is a paging device and the service provider device is a virtual block storage device (VBSD).
11. The apparatus of claim 9, wherein the operation-specific device is a hibernation module.
12. The apparatus of claim 9, wherein the request is a Read/Write (R/W) operation.
13. The apparatus of claim 9, wherein the request directed to the service provider device is converted to a command data-link interface (CDLI) format.
14. The apparatus of claim 13, further comprising logic, executed on the processor, for processing the CDLI formatted request received at the operation-specific module based upon a content type of the CDLI formatted request.
15. The apparatus of claim 14, wherein the content type is a paging Input/Output (I/O) request.
16. The system of claim 15, the logic for processing comprising:
a caching process;
a read-ahead process; and
an I/O coalescing process.
17. A computer programming product for handling a request from a hypervisor in a computing system, comprising:
a physical memory;
instructions, stored on the physical memory and executed on a processor, for performing a method, the method comprising:
receiving, at a virtual interface from a hypervisor, a request directed to a service provider device;
converting the request to a format common to a plurality of two or more different types of operation-specific modules to produce a formatted request;
transmitting the formatted request to an operation-specific module of the plurality of operation-specific modules;
converting, by the operation-specific module, the formatted request to a command format corresponding to the service provider device;
transmitting, by the operation-specific module, the service provider device formatted request to the service provider device;
receiving a response from the service provider device at the operation-specific module;
converting, by the operation-specific module, the response from the service provider device to the format common to the plurality of two or more different types of operation-specific modules to produce a formatted response;
transmitting, by the operation-specific module, the formatted response to the virtual interface;
converting the formatted response to a format corresponding to the hypervisor; and
transmitting the hypervisor formatted response to the hypervisor.
18. The computer programming product of claim 17, wherein the operation-specific device is a paging device and the service provider device is a virtual block storage device (VBSD).
19. The computer programming product of claim 17, wherein the request is a Read/Write (R/W) operation.
20. The computer programming product of claim 17, wherein the request directed to the service provider device is converted to a command data-link interface (CDLI) format.
21. The computer programming product of claim 20, further comprising logic for processing the CDLI formatted request received at the operation-specific module based upon a content type of the CDLI formatted request.
22. The computer programming product of claim 21, wherein the content type is a paging Input/Output (I/O) request.
23. The computer programming product of claim 22, the logic for processing comprising:
a caching process;
a read-ahead process; and
an I/O coalescing process.
US14/955,242 2008-06-09 2015-12-01 Hypervisor to I/O stack conduit in virtual real memory Active 2028-12-16 US9910691B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/135,999 US9208003B2 (en) 2008-06-09 2008-06-09 Hypervisor to I/O stack conduit in virtual real memory
US14/955,242 US9910691B2 (en) 2008-06-09 2015-12-01 Hypervisor to I/O stack conduit in virtual real memory

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/955,242 US9910691B2 (en) 2008-06-09 2015-12-01 Hypervisor to I/O stack conduit in virtual real memory
US15/842,924 US10360060B2 (en) 2008-06-09 2017-12-15 Virtual machine monitor to I/O stack conduit in virtual real memory
US16/416,422 US10628209B2 (en) 2008-06-09 2019-05-20 Virtual machine monitor to I/O stack conduit in virtual real memory

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US12/135,999 Continuation US9208003B2 (en) 2008-06-09 2008-06-09 Hypervisor to I/O stack conduit in virtual real memory

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/842,924 Continuation US10360060B2 (en) 2008-06-09 2017-12-15 Virtual machine monitor to I/O stack conduit in virtual real memory

Publications (2)

Publication Number Publication Date
US20160085581A1 US20160085581A1 (en) 2016-03-24
US9910691B2 true US9910691B2 (en) 2018-03-06

Family

ID=41401334

Family Applications (4)

Application Number Title Priority Date Filing Date
US12/135,999 Active 2031-12-17 US9208003B2 (en) 2008-06-09 2008-06-09 Hypervisor to I/O stack conduit in virtual real memory
US14/955,242 Active 2028-12-16 US9910691B2 (en) 2008-06-09 2015-12-01 Hypervisor to I/O stack conduit in virtual real memory
US15/842,924 Active US10360060B2 (en) 2008-06-09 2017-12-15 Virtual machine monitor to I/O stack conduit in virtual real memory
US16/416,422 Active US10628209B2 (en) 2008-06-09 2019-05-20 Virtual machine monitor to I/O stack conduit in virtual real memory

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US12/135,999 Active 2031-12-17 US9208003B2 (en) 2008-06-09 2008-06-09 Hypervisor to I/O stack conduit in virtual real memory

Family Applications After (2)

Application Number Title Priority Date Filing Date
US15/842,924 Active US10360060B2 (en) 2008-06-09 2017-12-15 Virtual machine monitor to I/O stack conduit in virtual real memory
US16/416,422 Active US10628209B2 (en) 2008-06-09 2019-05-20 Virtual machine monitor to I/O stack conduit in virtual real memory

Country Status (1)

Country Link
US (4) US9208003B2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10628209B2 (en) 2008-06-09 2020-04-21 International Business Machines Corporation Virtual machine monitor to I/O stack conduit in virtual real memory

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9389892B2 (en) 2010-03-17 2016-07-12 Zerto Ltd. Multiple points in time disk images for disaster recovery
US10649799B2 (en) 2010-03-17 2020-05-12 Zerto Ltd. Hypervisor virtual server system, and method for providing data services within a hypervisor virtual server system
US9710294B2 (en) * 2010-03-17 2017-07-18 Zerto Ltd. Methods and apparatus for providing hypervisor level data services for server virtualization
US9442748B2 (en) 2010-03-17 2016-09-13 Zerto, Ltd. Multi-RPO data protection
US20110265085A1 (en) 2010-03-17 2011-10-27 Zerto Ltd. Methods and apparatus for providing hypervisor level data services for server virtualization
US8959323B2 (en) 2010-10-27 2015-02-17 International Business Machines Corporation Remote restarting client logical partition on a target virtual input/output server using hibernation data in a cluster aware data processing system
US8458413B2 (en) 2010-10-27 2013-06-04 International Business Machines Corporation Supporting virtual input/output (I/O) server (VIOS) active memory sharing in a cluster environment
US9311209B2 (en) * 2012-11-27 2016-04-12 International Business Machines Corporation Associating energy consumption with a virtual machine
US9400792B1 (en) * 2013-06-27 2016-07-26 Emc Corporation File system inline fine grained tiering
CN106155764A (en) 2015-04-23 2016-11-23 阿里巴巴集团控股有限公司 The method and device of scheduling virtual machine input and output resource
WO2016171876A1 (en) * 2015-04-23 2016-10-27 Alibaba Group Holding Limited Method and system for scheduling input/output resources of a virtual machine
CN106201839B (en) 2015-04-30 2020-02-14 阿里巴巴集团控股有限公司 Information loading method and device for business object
CN106487708B (en) 2015-08-25 2020-03-13 阿里巴巴集团控股有限公司 Network access request control method and device
CN106802805B (en) * 2017-01-18 2020-03-10 郑州云海信息技术有限公司 Application service management method and device suitable for server management
US10616076B2 (en) * 2017-05-30 2020-04-07 International Business Machines Corporation Network asset management

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6732104B1 (en) 2001-06-06 2004-05-04 Lsi Logic Corporatioin Uniform routing of storage access requests through redundant array controllers
US20050240932A1 (en) 2004-04-22 2005-10-27 International Business Machines Corporation Facilitating access to input/output resources via an I/O partition shared by multiple consumer partitions
US20050256859A1 (en) 2004-05-13 2005-11-17 Internation Business Machines Corporation System, application and method of providing application programs continued access to frozen file systems
US20070011272A1 (en) 2005-06-22 2007-01-11 Mark Bakke Offload stack for network, block and file input and output
US20070106992A1 (en) 2005-11-09 2007-05-10 Hitachi, Ltd. Computerized system and method for resource allocation
US20070233775A1 (en) 2006-03-31 2007-10-04 Jeff Jackson Exposing device features in partitioned environment
US20080104591A1 (en) 2006-11-01 2008-05-01 Mccrory Dave Dennis Adaptive, Scalable I/O Request Handling Architecture in Virtualized Computer Systems and Networks
US20090089464A1 (en) 2007-09-27 2009-04-02 Sun Microsystems, Inc. Modular i/o virtualization for blade servers
US20090276785A1 (en) 2008-05-05 2009-11-05 Dell Products L.P. System and Method for Managing a Storage Array

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9208003B2 (en) 2008-06-09 2015-12-08 International Business Machines Corporation Hypervisor to I/O stack conduit in virtual real memory

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6732104B1 (en) 2001-06-06 2004-05-04 Lsi Logic Corporatioin Uniform routing of storage access requests through redundant array controllers
US20050240932A1 (en) 2004-04-22 2005-10-27 International Business Machines Corporation Facilitating access to input/output resources via an I/O partition shared by multiple consumer partitions
US20050256859A1 (en) 2004-05-13 2005-11-17 Internation Business Machines Corporation System, application and method of providing application programs continued access to frozen file systems
US20070011272A1 (en) 2005-06-22 2007-01-11 Mark Bakke Offload stack for network, block and file input and output
US20070106992A1 (en) 2005-11-09 2007-05-10 Hitachi, Ltd. Computerized system and method for resource allocation
US20070233775A1 (en) 2006-03-31 2007-10-04 Jeff Jackson Exposing device features in partitioned environment
US20080104591A1 (en) 2006-11-01 2008-05-01 Mccrory Dave Dennis Adaptive, Scalable I/O Request Handling Architecture in Virtualized Computer Systems and Networks
US20090089464A1 (en) 2007-09-27 2009-04-02 Sun Microsystems, Inc. Modular i/o virtualization for blade servers
US20090276785A1 (en) 2008-05-05 2009-11-05 Dell Products L.P. System and Method for Managing a Storage Array

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10628209B2 (en) 2008-06-09 2020-04-21 International Business Machines Corporation Virtual machine monitor to I/O stack conduit in virtual real memory

Also Published As

Publication number Publication date
US20180121228A1 (en) 2018-05-03
US10628209B2 (en) 2020-04-21
US20160085581A1 (en) 2016-03-24
US20090307396A1 (en) 2009-12-10
US10360060B2 (en) 2019-07-23
US20190272191A1 (en) 2019-09-05
US9208003B2 (en) 2015-12-08

Similar Documents

Publication Publication Date Title
US10552208B2 (en) Migrating a virtual machine that owns a resource such as a hardware device
US9448728B2 (en) Consistent unmapping of application data in presence of concurrent, unquiesced writers and readers
US10579305B2 (en) Method and apparatus for processing read/write request in physical machine
US9286087B2 (en) Storage optimization selection within a virtualization environment
US9423983B2 (en) Intelligent storage controller
US10691363B2 (en) Virtual machine trigger
US9158362B2 (en) System and method for power reduction by sequestering at least one device or partition in a platform from operating system access
US20180322039A1 (en) Apparatuses and methods for adaptive control of memory
CN102193824B (en) Virtual machine homogenizes to realize the migration across heterogeneous computers
US8176211B2 (en) Computer system, control apparatus, storage system and computer device
JP5689526B2 (en) Resource affinity through dynamic reconfiguration of multiqueue network adapters
KR100914077B1 (en) Method and apparatus for providing virtual server blades
US9239765B2 (en) Application triggered state migration via hypervisor
US6301605B1 (en) File array storage architecture having file system distributed across a data processing platform
JP5026509B2 (en) Converting a machine to a virtual machine
US8505006B1 (en) Resource management in virtual machines using dynamic table for performing resource queries
US20160077740A1 (en) Systems and methods for enabling local caching for remote storage devices over a network via nvme controller
US8200771B2 (en) Workload migration using on demand remote paging
US8291425B2 (en) Computer, control method for virtual device, and program thereof
US8732285B2 (en) Upgradeable persistent virtual storage
US7530071B2 (en) Facilitating access to input/output resources via an I/O partition shared by multiple consumer partitions
US9645764B2 (en) Techniques for migrating active I/O connections with migrating servers and clients
TWI278755B (en) An apparatus and method for high performance volatile disk drive memory access using an integrated DMA engine
US7363629B2 (en) Method, system, and program for remote resource management
US6760787B2 (en) Recoverable methods and systems for processing input/output requests including virtual memory addresses

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:NOGUERAS, JORGE R.;ROSAS, MORGAN J.;WANG, JAMES Y.;SIGNING DATES FROM 20151119 TO 20151130;REEL/FRAME:037176/0412

STCF Information on status: patent grant

Free format text: PATENTED CASE