DE112008003910T5 - Diskless client using a hypervisor - Google Patents

Abstract

System comprising:
an operating system;
a remote access storage unit that is in general communication with the operating system; and
a hypervisor that captures communications actions from the operating system and redirects the communications actions to that remote access storage device.

Description

The present invention relates to diskless clients and their effective and cost-effective management.

The paradigm of desktop computers connected to a shared server has long suffered from problems related to cost and manageability. Most important concerns concern the security that is constantly occurring and that each desktop computer has a hard disk so that unauthorized copying or downloading of data is facilitated and greatly increases the risk of system crash with respect to the difficulties of the manager What could happen in any desktop computer.

Accordingly, there is a continuing trend among smaller and larger businesses to provide a diskless client that eliminates the many types of desktop computers. All data, which can be found on a central server, and the entire file management can be controlled from one central location. The system backup is very simplified, since a large number of desktop computers do not have to be activated at the time a back-up or backup is performed and any "correction management" required can be performed on the server side.

However, a major impediment to making the changes just described is that most operating systems (OS's) are not capable of the type of remote access booting normally required in a diskless system. By and large, each operating system tends to be configured for a specific type of boot, which often requires some sort of local storage, and thus has a lack of versatility in booting that could be used. For example, during booting, the operating system needs to know whether booting is from a remote access memory or local memory, wirelessly, or from a local area network (LAN). Costly constraints generally need to be implemented to allow for a tangible degree of diversity.

Consequently, a compelling need has been identified in addressing these versatility issues and their associated problems.

In accordance with at least one presently preferred embodiment of the present invention, it is generally intended to provide an arrangement for facilitating remote access booting in diskless client systems as just described. For this purpose, the use of a hypervisor in general is envisaged which can be freely accommodated in a variety of boot arrangements for a given operating system. This then ensures that little or no, especially costly, modifications are made to the operating system to ensure greater versatility.

In summary, one aspect of the invention is to provide a system comprising: an operating system; a remote access storage unit having general communication with the operating system; and a hypervisor that receives communication activities from the operating system and redirects the communication activities to the remote access storage unit.

Another aspect of the invention provides a method comprising: loading an operating system; Loading a hypervisor and deploying the hypervisor to intercept communications actions from the operating system and to redirect the communications actions to a remote access storage device.

Furthermore, an additional aspect of the invention is to provide a machine readable program storage unit that understandably executes a program of instructions to be performed by the machine and perform method steps including: loading an operating system; Loading a hypervisor; and deploying the hypervisor to intercept communications actions from the operating system and to redirect the communications actions to a remote access storage device.

For a better understanding of the present invention, together with other and further features and advantages thereof, reference is made to the following description, taken in conjunction with the accompanying drawings, and the scope of the invention will be pointed out in the appended claims.

1 schematically illustrates a first type of hypervisor.

2 schematically illustrates a system employing a hypervisor according to at least one embodiment of the present invention.

As discussed above, it is generally contemplated herein, in accordance with at least one presently preferred embodiment of the present invention, to make more efficient the deployment of a hypervisor in a diskless client system and the boot capabilities of a Highly expand operating system. In particular, the hypervisor preferably "captures" (in a manner to be described below) all floppy and LAN accesses from the operating system.

Stated another way, to the extent that many operating systems are normally configured to describe a hard disk during boot up, and to the extent that one desires to integrate such an operating system into a diskless system, a hypervisor according to the The present invention obviates the need to reconfigure the operating system for a seamless environment by significantly different booting. Any and all translations to the remote access memory as performed by the hypervisor thus become essentially "blind" to the operating system.

Conventionally, a hypervisor is executed in a base set as code running under an operating system to allow an operating system to run in a virtual environment and can create the virtual environment for a "guest operating system" (such as Microsoft XP). It thus allows the operating system to run with the current hardware.

Essentially, there are two major types of hypervisors; a "Type 1" runs directly on a hardware and a "Type 2" runs under an existing operating system. 1 shows a Type 1 hypervisor environment ( 10 ). An operating system 1 ( 20 ; can be a user operating system (UOS) like that of Microsoft XP. An operating system 2 ( 30 ) is a service operating system (SOS) that is used for manageability of a client such as Linux or Microsoft Windows PE. These two operating systems and the hypervisor ( 40 ) even run on the same hardware ( 50 ).

In general, according to a preferred embodiment of the present invention, a hypervisor ( 140 ) loaded first ( 160 ) under an operating system ( 120 ) to run. In particular, the hypervisor ( 140 ) preferably loaded first ( 160 ) and then the operating system ( 120 ), so that the hypervisor ( 140 ) under the operating system ( 120 ) running. Once loaded, the hypervisor ( 140 ) preferably a connection to the central server ( 170 ) loads user data, "hooks into" data access modules, and continues with a normal boot path. By "latching" into disk access modules, the hypervisor itself essentially has disk access modules so that it is able to intercept hardware memory for a read / write function, which will now be described.

Consequently at any time when the operating system ( 120 ) tries ( 175 ), to a file on a local hardware store ( 180 ), the hypervisor ( 140 ) preferably this access ( 175 ) And thus prevent what else in a different way with a hardware memory ( 180 ) communicates ( 185 ), and then essentially the device data of the server ( 170 ) read ( 190 ). In other words, if the operating system ( 120 ) something that is assumed to be a hardware memory read or write, takes, captures, or interrupts the hypervisor ( 140 ) reading or writing ( 175 ), and directs the reading or writing to a remote access memory on the network, and thus the operating system "thinks" ( 120 It reads or writes to local storage when it is currently going across the network to the remote access storage. Local traffic (LAN traffic) is also preferably intercepted, so there is no access conflict. (In other words, normal LAN data is preferably treated differently.) Preferably, priority may be given to reading / writing data of a data remote access memory up to the selection time, e.g., up to 80% or more of the bandwidth over normal network traffic .).

In other words, the operating system is 120 ) essentially "shrink-wrapped" and isolated from components or points that it would normally communicate with (eg, a hardware memory [ 180 ]) and the hypervisor ( 140 ) acts as a buffer or interface through which a predetermined type of communication is now performed. Or a hypervisor ( 140 ), according to at least one present preferred embodiment of the present invention, a client operating system ( 120 ) By "thinking" that it is from a hardware driver ( 180 ) boots (or does with a way of reading or writing to it) when instead calling, for example, a disk read sector ( 175 ) and then to the server ( 170 ) Posted ( 190 ) becomes. Accordingly, a hypervisor ( 140 ) is preferably configured to allow normal boot communication ( 175 ) from an operating system ( 120 ), which itself is normally configured to read and write with respect to a very specific medium (such as a hardware memory [ 180 ]), and then such communication will be transferred to another location (eg a server [ 170 ]), which can accommodate a variety of boat commands more freely and skillfully. Thus, the operating system ( 120 ) do not go through a costly reconfiguration to ensure versatility; the hypervisor ( 140 ) acts as a buffer or intermediate to prevent this need. The remote access point to which the communication Of course, this is not necessarily a server, as discussed above. It may also be essentially any form of remote access storage device, such as a storage area network (SAN) or network attached storage (NAS).

It should be noted that while the use of a hypervisor to "intercept" the reading and writing of a hardware memory has just been discussed, a hypervisor can of course also be more versatile than it is used for. For example, if an operating system is configured to read from or write to something other than a hardware store, a hypervisor may still "intercept" such reading and writing. Essentially, in accordance with at least one present preferred embodiment of the present invention, any read / write from an operating system through a hypervisor may be redirected to a remote access memory.

A variety of known processes are required for safe loading ( 160 ) of a hypervisor ( 140 ) conceivable. For example, loading ( 160 ) can be reached via flash, via UEFI memory, or via a secure PXE (Preboot Execution Environment) boot (this may use a Boot Integrity Services [BIS] or it may use some secure loading method). The presently preferred loading mechanism is the use of a device that uses the iSCSI (Internet Small Computer Systems Interface) protocol. Additional information about PXE booting is available in the Preboot Execution Environment (PXE) specification ( http colon dot slash slash www dot pix dot net slash software slash pxeboot slash archive slash pxespec dot pdf ). Additional information about the iSCSI protocol is in the RFC 3720 available. ( http colon slash slash www dot faqs dot org slash rfcs slash rfc3720 dot html ). Although essentially any suitable hypervisor may be used in accordance with the presently preferred embodiments of the present invention, the "Xen" hypervisor is currently used as the preferred hypervisor. The Xen hypervisor is an open source software development. For additional information about the Xen hypervisor, see http colon slash www xensource dot com being found.

It is conceivable to run more than one operating system based on a common hypervisor according to embodiments of the present invention. For example, Windows XP and Linux can run simultaneously in the neutral frame of a single hypervisor, and the hypervisor can translate read / write from both operating systems from a local and a remote access memory. One fact is that there is no conceivable limit to the number of operating systems that can run on the basis of a common hypervisor.

The present invention is to be understood to include, in accordance with at least one present preferred embodiment, elements that may be implemented on an at least general purpose computer running on appropriate software programs. This can also be implemented on at least one integrated circuit or part of at least one integrated circuit. Thus, it is to be understood that the invention may be implemented in hardware, software, or a combination of both.

Unless otherwise specified, it is assumed that all patents, patent applications, patent publications and other publications (including web-based publications) mentioned and cited herein are fully incorporated by reference as if incorporated with their full text.

Although the illustrated embodiments of the present invention have been described with reference to the accompanying drawings, it is to be understood that the invention is not limited only to these precise embodiments and that various other changes and modifications therein may be influenced by one skilled in the art without departing from deviate from the scope and idea of the invention.

Summary

Diskless client using a hypervisor

An arrangement for facilitating remote access booting in diskless client systems as just described. In this regard, the use of a hypervisor that can accommodate a variety of boot arrangements for a given operating system is generally contemplated. This then ensures that few to no modifications, especially costly, must be used to ensure greater versatility for an operating system.

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited non-patent literature

• http colon dot dot slash slash www dot pix dot net slash software slash pxeboot slash archive slash pxespec dot pdf [0021]
• RFC 3720 [0021]
• http colon slash slash www dot faqs dot org slash rfcs slash rfc3720 dot html [0021]
• http colon slash www xensource dot com [0021]

Claims (20)

System comprising: an operating system; a remote access storage unit that is in general communication with the operating system; and a hypervisor that captures communications actions from the operating system and redirects the communications actions to that remote access storage device. The system of claim 1, wherein the hypervisor intercepts reads and writes from the operating system with respect to a given receiver and redirects the read and write actions to a remote access storage unit. The system of claim 2, wherein the hypervisor intercepts read and write actions from the operating system with respect to the local storage device and redirects the read and write actions to a remote access storage device. The system of claim 3, wherein the hypervisor captures read and write actions from the operating system with respect to a local hard disk and redirects the read and write actions to a remote access storage unit. The system of claim 1, wherein the hypervisor acts to communicate with the remote access storage device during booting of the operating system. The system of claim 1, wherein the remote access storage unit comprises a central server. The system of claim 1, wherein: the operating system comprises a first operating system; the system further comprises a second operating system; the hypervisor acts to capture communication actions of both the first and the second, and redirects the communications actions to the remote access storage unit. The system of claim 7, further comprising a charging device that loads the hyperlink. The system of claim 8, wherein the load device acts to apply an iSCSI protocol. The system of claim 8, wherein the loader acts to load the hypervisor before the operating system is loaded. Method, comprising: Loading an operating system; Loading a hypervisor; and Use the hypervisor to capture communication actions from the operating system and redirect the communication actions to a remote access storage unit. The method of claim 11, wherein includes capturing read and write actions of the operating system with respect to a given receiver; and the m remote access memory unit comprises. The method of claim 12, wherein the capturing of read and write actions comprises capturing read and write actions from the operating system with respect to a local storage device. The method of claim 13, wherein capturing read and write actions from the operating system relative to a local storage device comprises capturing read and write actions of the operating system relative to a local hard drive. The method of claim 11, wherein redirecting the read and write actions comprises redirecting the read and write actions to a central server. The method of claim 11, wherein the step of loading an operating system includes loading a first operating system; the method further comprises loading a second operating system; applying the hypervisor comprises applying the hypervisor to capture communication actions of both the first and second operating systems, and redirecting the communication zones to a remote access storage unit. The method of claim 11, wherein loading a hypervisor comprises using an iSCSI protocol. The method of claim 11, wherein loading a hypervisor to load an operating system is performed. The method of claim 11, further comprising: Booting an operating system; and Performing communications between the hypervisor of a remote access storage device during booting. Machine-readable program storage unit materially executable by a program of instructions by the machine to perform method steps comprising: loading an operating system; Loading a hypervisor; and applying the hypervisor to: capture communications actions from the operating system and redirect communications actions to a remote access storage device.

Images