JP2008198210A - System and method for network booting of operating system of client computer using hibernation - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a system and a method for network booting of an operating system of a client computer. <P>SOLUTION: This invention provides a step and the method for the network booting of the operating system (O/S) of one or a plurality of client devices (2) such as a personal computer (PC) using a hibernation image. Remote booting of one or the plurality of client devices is attained by broadcasting or multi-casting data including hibernation (20), O/S (28) and an application file existing in a network server (4) required for the initial setting, by properly booting one or the plurality of client devices in a specific desirable embodiment by using virtual disk emulation. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

The present invention provides network booting of an operating system O / S on one or more client devices, such as a personal computer (PC) using a hibernation image.
Or, boot processing). More particularly, the present invention resides on the network server required to properly boot and initialize one or more client devices by utilizing virtual disk emulation and in certain embodiments. Facilitates remote booting of client devices by broadcasting or multicasting data including hibernation, O / S, and application fills.

Computer networks are used to interconnect personal computers (PCs) in office and other corporate environments. As the use of PCs expands, there is an increasing demand for sharing computer files and promoting management of each PC after installation. In a network consisting of a large number of PCs, it is very costly for an organization to have IT personnel to actually visit and service each PC. In order to reduce such costs, software and computer manufacturers maintain software products centrally on a network server and develop techniques for downloading desired software to each client PC via the network. .

Designers and manufacturers of embedded intelligent connected equipment reduce costs,
We are looking for ways to improve manageability and reliability, promote deployment, and protect intellectual property in devices. One way to achieve these is to introduce the ability for the client PC to be booted (or started) from the network. The purpose of the PC boot process is to load the necessary operating system elements, initialize the hardware device, and present the application to the user. This is a long process and under normal conditions it is necessary to take into account changes in hardware or software defaults and changes in authorized users. Network boot is more suitable for situations where the hardware associated with the PC (or directly connected to the PC) is fixed and the role of the client PC does not change frequently. Network boot enables the removal of the PC's hard disk and facilitates central management of software content. Current network bandwidth (10 / 100Mbs and 1Gb
Since s) does not reach the local hard disk speed of the client PC, remote “cold boot” of the client PC operating system (O / S) is not efficient and very time consuming. Furthermore, the effective bandwidth of the network and network server resources can be further exacerbated when attempting to boot a large number of client devices simultaneously ("boot storm"). The long time required for “cold boot” detracts from the perception and behavior of ordinary embedded devices. Therefore, there is a need for a scalable (or easy to expand and shrink) method that speeds up booting of multiple client devices from a loading server (or loading server) on the network.

Manufacturers of basic input / output systems (BIOS), PCs, and O / S are “hibernation”
Introduced a technology called. In hibernation, the memory and state of all PCs are saved to disk and then recovered after a certain time. Hibernation is mainly used in notebook computers to save battery power. For example, "
A laptop set to "hibernate mode" saves its state to its local hard disk when its lid is closed or after a certain period of inactivity, and is turned off, Recovers itself when the lid is opened. The original purpose of hibernation is to save battery power, but it allows the PC to return to the state of the PC prior to hibernation more quickly than when the PC performed a full “cold boot”. When power is reapplied to the notebook computer, the computer only needs to load the portion with very little O / S. The O / S checks whether the hibernation image is valid. If a hibernation image exists, the O / S copies the content (or contents) of the memory stored in the hibernation file back to the PC memory. If no hibernation image exists, a normal “cold boot” process is started. Here, “resumption (or recovery)” of hibernation using the hibernation image requires less data initialization so that the PC can return to the desired state more quickly than a “cold boot” is performed. It should be noted that it has a strong advantage.

Prior art systems present a technique for solving the long boot time associated with remotely booting a client device from a boot image on a network (see, for example, Patent Document 1). However, this patent teaches playing from a hibernation image stored in the local storage medium of each client PC and following a kind of reset. This approach requires that the client PC perform all reconfiguration of the desired state of the PC prior to hibernation, and the server has multiple corresponding client PCs on a network to which many client PCs are connected. Since each hibernation image is transferred individually, it may cause a network collision.

Some conventional systems use devices and methods that use disk emulation to boot a 32-bit PC operating system (O / S) on a client computer via a network connection to a server ( For example, see Patent Document 2). Specifically, this patent refers to Windows® 9xO / S 32, referred to as “thunking” until the client O / S is able to perform network processing on its own. He teaches how to switch (in each disk I / O call) between bit protection mode processing and the 16-bit real mode used by the BIOS. This method and apparatus is particularly suitable for booting an O / S such as Windows 95 from a server by downloading a complete image of the desired software application on the client PC including the O / S. However, this patent does not take into account the advantages of the hibernation function that is effective in recent O / S versions of Microsoft Corporation, namely Windows 2000 and Windows XP operating in protected mode. This patent also contemplates the use of multicasting of desired data to a plurality of client PCs on a network, including a hibernation file in one preferred embodiment, which is one of the features of the present invention. Absent.

US Pat. No. 6,101,601 US Pat. No. 5,974,547

The present invention provides a system and method for booting (or booting) O / S on one or more client PCs from a hibernation image stored on a network server using virtual disk emulation. To do.

In certain preferred embodiments of the present invention, hibernation images and some O
The data necessary to proceed with the boot process, such as the hibernation file including the / S file, will be described later (also, the applicant's other patent application, WO 0
3/090073 “System for and Method of Streaming Data to a Computer in a N”
streamed (or data transferred) synchronously (or simultaneously) from a network server (as described in etwork). (The contents of the above application are incorporated herein by reference in their entirety.)

  One or more PCs each run an O / S that supports hibernation, such as Microsoft Windows 2000 and XP. The ingenious software driver accepts (or receives) a plurality of sectors (data packets) that collectively (or jointly) constitute a hibernation file from a network server at least in part. To help restore (or resume) to a usable state. Requests (or requests) for disk access at an early stage of the boot process are initially redirected (or redirected) from each client to the network using the PXE service. The PXE code will establish an initial virtual connection between each client and server, allowing the server to be recognized as another drive for the client. The PXE code assists in downloading additional emulation code, which (ie, downloaded emulation code) then downloads O / S code that assists in downloading the hibernation file. During the early stages of the boot process, insufficient O / S elements are loaded and activated to provide supported network access to the client O / S. As a result, client hard disk access requests are handled via an Int 13h handler and downloaded emulation code. In about 25% of the O / S boot, the O / S takes control of communication with the server using an ingenious driver, effectively avoiding the need for a BIOS Int 13h service.

In another embodiment, data downloaded from the network server is recovered (or retrieved) in a predetermined manner from multiple sectors of the storage device associated with the network server (or directly connected to the server). Also good. In operation, one or more client PCs issue multiple requests (or requests) for multiple sector downloads. The request is temporarily transferred (or transmitted) to a server emulating the operation of each local disk of the client PC. In one embodiment, the network server broadcasts the desired data from the virtual hard disk associated with the server to each of the issuing clients. In another embodiment, the network server simultaneously multicasts the desired data from the virtual hard disk associated with the server (or directly connected to the server) to each requesting client. The server preferably accepts (or receives) the download request during a predetermined solicitation period (or invitation period) prior to multicasting.

In a particular embodiment, emulation is accomplished by executing emulation code that resides on each of the client PCs. Preferably, the emulation code is a pre-execution boot environment (PXE) code that resides on the network interface card (NIC) of each client PC. In an alternative embodiment, emulation is the result of an original boot code downloaded from a network server that, when executed, assumes disk access control by an interrupt handling procedure (Int 13h) and requests the desired data. .
In another embodiment, the emulation assumes control of part of the O / S (which is preferably Windows 2000, NT, or XP), and also the client's network interface, as desired. This is accomplished at each client PC by executing two original drivers downloaded from a network server that request the data. The data to be streamed (or data to be transferred) may be multicast or broadcast in burst mode from the network server to the client PC requesting download. Therefore, the data need not be transmitted redundantly to each client PC, but only once. As data sectors are received at each client, they are queued (or queued) in a data cache that has been previously allocated by an ingenious driver. This allows each client to concentrate on other operations, such as initializing O / S data structures, drivers, and / or applications.

The present invention requires less hardware because the client device does not have to be configured with a hard disk. The present invention also allows a client PC to boot the same hibernation image. This facilitates maintenance of each client device since each client does not need to execute the same O / S or application replication. For example, software upgrades need to be performed only on a single hibernation image regardless of the number of client PCs. Because the hibernation image is multicast to multiple clients, network traffic is greatly reduced during traffic peaks, such as when many clients attempt to boot simultaneously. Thus, the solution of the present invention is very scalable (or easy to expand and shrink) because fewer resources are required to boot an increasing number of client PCs.

In the following, certain preferred embodiments of the invention will be described with reference to the drawings.
In the present application, the term “hibernation” means that the power of the PC is turned off while the PC is “paused”. While the PC is turned off, power is removed from all or most of its components. When the PC is turned back on or “resumed (or recovered)”, the PC returns to normal operation in the same state as when it was turned off. The “hibernation function” described in US Patent No. 6,209,088 of Microsoft Corp etc. is called immediately before the PC is turned off, interrupts the execution of all programs, and the PC
Are saved as a “hibernation image” in a non-volatile storage device. The “resume function” is executed from volatile memory and is typically implemented by code executed from the same executable address space used by the O / S and / or application programs started by the O / S. . In the specific environment of the present invention described below, the “hibernation file” is an O / S file such as an O / S driver, and
Contains an initialization file that is read into the PC's volatile memory before the hibernation function is started.

The terms “MBR (Master Boot Record)”, “storage driver (or storage device driver)”, and “network filter driver” as used herein are bootstrappings developed by the applicant. Means a software module. In order to differentiate software modules developed by a person other than the applicant, a conventional conventional module name such as “O / S” is adopted. Further, the terms “virtual drive”, “boot drive”, and “server drive” are used interchangeably in the following description.

The network computer environment shown in FIG. 1 may be a corporate network or client / server configuration, where any of the PCs 2 may function as a file server or network server 4. The network server 4 may be a normal type system including a relatively small PC and a large mainframe. In the specific embodiment described below, the server 4 is a read-only memory with one or more central processing units (CPUs) 6, a hard disk 8 and its own BIOS 18 connected by one or more buses 16. (ROM) 1
0, an intermediate computer having a random access memory (RAM) 12 and a network adapter 14. As will be apparent to those skilled in the art, the BIOS 18 is a set of basic routines that assist in the communication of information between components within a network server. In the specific embodiment described below, the hard disk 8 of the network server has a hibernation file 20 composed of a hibernation image and a specific O / S file, a variety of microinstruction codes such as a sector sequence file 22 and an MBR 24, a streaming module 26, In addition, an O / S file such as the O / SMBR 28 including at least the network filter driver 30 and the storage driver (or storage device driver) 32 is stored.

Optionally, one or more additional servers 34 may be connected to the network and communicate with the first server 4 and the client PC 2. In the case of a multi-server network, a client module 36 (eg, HPPC) is present in the first server 4 and which additional server 34 includes client addressing information and download information in response to a request from the client device. May be specified.

One or more client apparatuses 2 are connected to the server 4 via a network router or network switch 38 on the network. Physical connection is cable,
It can be any of a variety of types including switched telephone lines, wireless devices operating in the radio and infrared spectrum, and other means. The client device and server transmit data to each other using a standard communication protocol. The O / S 40 that supports the Microsoft hibernation function, such as Microsoft Windows (registered trademark) 2000 and Windows (registered trademark) XP, has a physical configuration of each client device when an appropriate number of O / S modules and O / S drivers are activated. Manage critical functions or equipment. Each client device includes a CPU 42, such as an x86 family microprocessor manufactured by Intel Corporation. Each client also includes a local memory 44 including a ROM 46 and RAM 50 storing a BIOS 48, a local storage device (or local storage) 52, and a network adapter 54 connected to the CPU by a system bus 56.

FIG. 1 also illustrates a portion of the client's RAM 50 after the appropriate number of sectors have been downloaded and the code they contain has been executed. RAM as shown
50 may include downloaded O / S 40, O / S driver 76, O / S loader 78, network filter driver 30, storage driver (or storage device driver) 32, and O / S network stack 68. In some embodiments, RAM 50 also includes a copy of a kernel binary that provides system utility functions, such as hibernation file 20 and WIN32.SYS 72. Referring to FIG. 2, each client's network adapter 54 is preferably a network interface card (NIC) that provides a data link between the client's hardware and the network. Each NIC 54 includes a bus interface 58 for connection to a client system bus 56 and one or more network connectors 60 for connection to a network. Network connector 60 is L
It may correspond to AN or WAN. The NIC 54 also includes a random access memory (RAM) 62 for storing the NIC's unique destination address, and a selective ROM (OPROM) 6 for storing the PXE emulation code 66.
4 is provided. The destination address allows each client 2 to be individually addressed by other computers on the network.

Boot NIC Basic Architecture In one aspect of the present invention, an O / S supporting a hibernation function such as Windows (registered trademark) 2000 and (registered trademark) XP is booted (or started) on a network. And in another aspect, enables synchronous streaming (or data transmission) of O / S data that supports or does not support hibernation, herein referred to as boot NIC technology by the applicant Systems and methods are provided. Each booting client initially communicates with the server 4 using the PXE service. The PXE code 66 establishes a “virtual drive” that is first emulated between each client and server. The PXE (Pre-Runtime Boot Environment) service allows the MBR (Master Boot Record) code 33 to send a read request to the server, so that the hibernation file 20 residing on the server is transferred to the local client by each client CPU 42. It is possible to be recognized as a plurality of data sectors that can be stored in the hard disk 52. During the early stages of bootstrapping, the BIOS interrupt handler service operates only in real mode, so emulation is provided by execution of the MBR code 33 in real mode. In the second half of the processing, emulation is provided by the O / S kernel code and the storage driver 32 and the network filter driver 30 that are executed only in the protection mode (where no thunking occurs).

FIG. 3 is a block diagram illustrating a portion of the client's local memory 44 after the network filter driver 30 and storage driver (or storage device driver) 32 have been downloaded from the network server and executed. The only role of the network filter driver is to monitor all data packets sent from the network to the O / S network stack 68 via the client NIC 54 in order to identify the data packets that are specific to the boot NIC. Blocking the unique data packets from being sent to the network stack 68 and sending them to the storage driver 32 instead. Next, the storage driver 32 is mounted by a mount manager and a volume manager.
), And various managers 70 of Windows (registered trademark) having a storage role, such as a partition manager. If the network data packet is not specific to Boot NIC (BootNIC specific), the data packet is sent to the O / S network stack 68 without being affected. As will be apparent to those skilled in the art, there are three different types of data packets: (1) Broadcast packet, packet addressed to all computers on the network. (2) A multicast packet, a packet addressed by a computer that is two or more, but not necessarily all computers on the network. (3) Direct addressing packets, packets addressed only to specific client devices. The system according to the present invention may use any of these data packet transmission means.

The present invention is the result of an effort to create a predictable and interoperable way for clients to interact with the network in a pre-boot environment (PXE) (with or without an operating system) Boot execution environment (PXE (pre-boot execution
Take advantage of widely used specifications known as environment)).
The current version of PXE was established as an Intel-led industry initiative of Wired for Management (WfM). PXE encompasses the following three technologies that establish a common and coherent set of pre-boot services with the boot firmware of Intel architecture-based systems: (I) A uniform protocol for the client 2 to request the allocation of the IP address of the network and consequently to request the download of the bootstrap program (MBR 24 and O / SMBR 28) from the network boot server 4. (Ii) A set of APIs available for pre-booting the client 2 firmware environment that constitutes a consistent set of services available by the BIOS 48 or bootstrap program. (Iii) A standard method of starting pre-boot firmware for executing the PXE protocol on the client PC.

The use of the PXE spec allows the client NIC 54 to act as a boot device. It also allows BIOS 48 to directly use the NIC code stored on OPROM 64 before or during POST processing. The present invention, in certain embodiments, selectively PXE boot server discovery.
Take advantage of features. By using this feature, the boot client 2 can discover (or discover) an appropriate boot server 4 or 34 from the list of available boot servers provided to the client 2 during the initial stage of remote boot. . The type of boot server, or the specific downloaded hibernation image, is the client's system architecture type or each client's unique ID
Information technology a based on information technology a
dministrator) can be assigned and maintained. PXE uses Dynamic Host Configuration Protocol (DHCP) and Trivial File Transfer Protocol (TFTP) to communicate with server 4. When PXE enables the client to boot, it obtains an IP address from the DHCP server 4. The client 2 may then discover a DHCP server 4 that gives the client a list of boot servers. In FIG.
An additional server 34 is shown that may operate as a boot server. However, to facilitate the description of the present invention, the process of the present invention resulting in booting and broadcasting or multicasting from the hibernation file will be described in the context of a network configuration consisting of a single server 4. .

Remote Booting from Hibernation Image As described above, the present invention boots an O / S from a server 4 storing a hibernation image 20 having an O / S file for a client PC to one or more clients 2. An improved system and method is provided. CP of each client
U42 only executes instructions (or instructions) from addressable memory, such as DRAM or other types of volatile electronic memory. A small amount of PXE code 66 is provided to OPROM 64 on NIC 54 to initialize this addressable memory. The PXE code 66 allows a request to be issued to the network server 4 emulating the client's local disk to read the MBR code 24. The downloaded MBR code 33 allows further disk emulation and the first part of the O / SMBR 28 is sent from the server to the client, where
Request to be loaded into DRAM. Next, the O / SMBR 28 downloads and initializes the remaining portions of the O / S, and those remaining portions download the hibernation file 20. Here, the following description includes only a single hibernation file 20 that is downloaded to multiple clients, but as will be apparent to those skilled in the art, a number of different client sets can be used using the method of the present invention. You can also stream hibernation files. Applicants have observed that the method of the present invention can reduce the time required for streaming to boot O / S 40 over the network by more than 50% over a traditional standard O / S local boot.

The hibernation transaction protocol consists of two parts. The first half is to create a hibernation image on the boot drive 8 and the second half is the actual resume (or recovery) from the hibernation file.

Prior to the start of the boot up of the present invention, the hibernation file 20 present on the server 4 is generated in a direct manner. After the client PC is set in a desired state, a hibernation function is used to generate a hibernation image in the hibernation file 20. The hibernation file 20 is then sent to the boot drive 8 of the server. Alternatively, the hibernation process may be performed such that the hibernation file is saved directly to the server boot drive. The hibernation function instructs all drivers to power down, but only the storage driver 32 caches WIN32.SYS 72 in the local memory 50, and the memory content is saved to the file HIBERFIL.SYS (when the O / S loader resumes). Is written down to a file to be checked for validity, and then powered down by an O / S request. Another step that is preferably performed before starting the boot process is to install MBR on the boot drive 8
24 emulation codes are stored.

  In the Windows® architecture, the Windows® architecture communicates with the server because the driver is required to exhibit a “type” and one driver cannot simultaneously be a storage driver and a network driver. Therefore, two drivers, a storage driver 32 and a network filter driver 30, are required instead of one driver. The execution of hibernation in Windows 2000 and XP assumes that only one O / S driver is required to communicate with the storage driver, and therefore the hibernation process is more than one O / S driver. Does not give a mechanism to allow to support. Since standard O / S drivers currently available are not written to resume from a file on the network, they will not work well. In a standard restart from a local drive, the O / S storage driver is required to know only (and indeed is) how to communicate with the local hard disk.

The storage driver 32 is a power handler of the NIC driver 74 (power handler).
) By replacing the dispatch address with the handler of the storage driver itself (dispatch routine disp).
atch routine). The storage driver 32 may then call the original NIC driver power handler routine.

The boot process consists of many processes, but generally involves one program starting a more advanced program with respect to the prior program. The main steps of the inventive method are BIOS initialization, PXE initialization, MBR loading and Int 13h redirection, hibernation image loading, and O / S resumption (or recovery). Here, these solutions are specific to Windows 2000, but the steps described below summarize the general framework for extending these solutions to other operating systems. It is a thing.

Referring to FIG. 5, immediately after power-up, initialization of the BIOS 48 of the client 2 is started together with execution of a power-on / self-test (POST) sequence (step 502). Each client broadcasts a DHCP discovery request to confirm its own IP address. Server O / S that supports this protocol (and other protocols) may or may not be network server 4 and these parameters along with the address of the server from which the client is booted (from there) return. The virtual boot drive 8 may comprise a non-volatile storage device associated with (or directly connected to) the network server 4 (or alternative boot server 34). Types of drivers include floppy (registered trademark) disks, hard disks, magnetic tapes, DVDs, CD-ROMs, and flash ROMs. In order to become a virtual boot drive 8, the device must keep a copy of the O / S file or the hibernation file containing the microinstruction code that is intended to be downloaded.

During POST, CPU 42 checks the address on bus 56 to determine if OPROM 64 is present on client 2. If OPROM is found, the CPU
All the hardware initialization routines on the ROM are processed to initialize the NIC 54 to a usable state (step 504). The OPROM code then initializes the PXE code (
Step 506). The OPROM code also “hooks” to the BIOS boot process via an interrupt 13h handler service that controls the reading and writing of the hard disk 52.
k) ". By using the PXE code to assume control of the NIC 54, the OP
The ROM 64 code communicates with the server 4 and allows the server hard disk 8 to transparently emulate the client 2 local hard disk 52 via disk read and write redirection to the server.

At the end of the POST sequence, BIOS 48 will begin booting the O / S. B
The IOS reads the first sector (cylinder 0, head 0, sector 1) of the virtual drive 8 of the server (step 510). The first sector stores an MBR (Master Boot Record) 24 containing additional emulation code for booting the O / S 40. The MBR 24 code is conventionally supplied by the O / S manufacturer, but additional emulation code needs to be developed to facilitate the hibernation resume process described below. The MBR code is executed after being loaded into the client's memory (step 512). The MBR code is PX to communicate with the network server
Continue to use E66, hook interrupt 13h to get all storage device access requests, and prevent writing to the server's virtual hard disk 8 during the early stages of the boot process (step 514).

The read request may be fulfilled by broadcasting the desired data from the virtual drive. However, in certain preferred embodiments, the read request is fulfilled by using a synchronous (or simultaneous) streaming method described below. Alternatively, read requests may be individually processed by the network server. The read request is not sent to the original Int 13h BIOS routine, but is instead used by the MBR for the PXE to receive data from the network server 4. The read request is fulfilled by the MBR code, and the request is returned to the request issuer along with the data downloaded from the network server. Disc lights are operated in different styles.
The MBR code does not perform writing, but returns a signal indicating normal writing to the disk write request issuer. The light is not sent to the original Int 13h BIOS routine.

  The MBR code then downloads an O / SMBR 28 developed by the O / S manufacturer, as shown in FIG. 1 as “Windows 2000 MBR”. The MBR code 33 of each client 2 gets all requests for local disk reads via its Int 13h vector hooking before OPROM 64 has the opportunity to examine the request. The downloaded MBR 88 then forwards the request to the network server using PXE 66 to download O / SMBR 28 (step 516).

In step 518, the network server 4 starts from the virtual drive 8 of the server,
Data packets that collectively (or jointly) configure O / SMBR 28 are O / SMB
Multicast or synchronously stream (or data transfer) to each client 2 requesting R download. Synchronization may be achieved by using a synchronized streaming process 400 described below. In this embodiment, the streaming module 26 registers for downloading to all the clients 2 that issued O / SMBR download requests during the solicitation period. The solicitation period has a predetermined time interval that gives all clients the opportunity to register. The streaming module 26 then designates the first client as the read request source. That is, only that client is allowed to generate a read request for the streaming module 26 for the content of the next data sector to be multicast to all registered clients.

The streaming module 26 then accesses all of the registered clients 2 and multicasts the content of the first sector of the group of sectors of the virtual drive 8 that collectively stores the identification of the read request source and the O / SMBR 28. . The streaming module then determines whether all sectors of the group of O / SMBR sectors have been multicast. If additional sectors need to be multicast, and
If there are two or more registered clients, the streaming module specifies a new read request source. The streaming module then accesses the next sector and multicasts its content to all registered clients along with the identification of the new read requester. The step of designating a new read request source is preferred and is performed in order. That is, after each multicast round, one registered client assumes the role of generating virtual drive read requests in turn, and the other unspecified clients simply wait for data multicast. Streaming process 40
0 is repeated until the entire O / SMBR 28 is multicast and loaded to each client, at which point the downloaded O / SMBR assumes control of the network interface 54 and request generation processing.

Note that each read request is the same regardless of which registered client issued it. Therefore, read requests performed by the MBR code proceed in a lock-step manner. Since each client requests a read from the same virtual drive and is already executing the same MBR 28 downloaded from the virtual drive, each read request will be the same.

Referring to FIG. 5, in step 520, each registered client receives and stores a broadcast or multicast O / SMBR sector. The received data sector is stored in the RAM 50 in a part of the memory reserved for the expanded BIOS data area. Each broadcast sector or multicast sector may be transmitted with a sequence number. Each client may then determine whether the client has successfully received all of the transmitted sectors (step 522). If the client misses a data packet, the client may request the missed data sector from the network server asynchronously. However, the data is returned to that client alone and not broadcast or multicast to all registered clients.

  In step 524, O / SMBR 28 (eg, Windows 2000 MBR) is loaded into each client's memory 50 and executed. Next, the O / SMBR downloads the O / S loader 74 (eg, NTLDR) described by the O / S manufacturer from the virtual drive (step 526). The downloaded O / S loader 78 may check whether a valid hibernation image exists in the virtual drive 8 (step 528). The virtual drive is set to include a valid hibernation image 20 in advance. The O / S loader 78 then starts loading the hibernation image via a series of Int 13h read requests that the MBR 33 acquires and redirects to the network server 4 (step 530). Here, the streaming process 400 may be utilized again to access and broadcast or multicast the content of multiple sectors on the virtual drive 8 that collectively store the hibernation file 20 (step 532).

After the hibernation image is copied to the local memory 44 of each client, the O / S loader 78 recovers (or replays) the O / S recovered from the hibernation image.
In S40, that is, execution is passed to Windows XP or 2000 (step 534). Note that after this point, read requests are not performed in a synchronous fashion. That is, they are sent to the network server on a stand-alone basis and answered by the network server.

At this point, the O / S 40 needs to wake up a driver 76, such as the storage driver 32, and perform some initialization to return the system to a usable state. To configure each client 2 to load storage (or enclosure) and network filter drivers in the proper order, some standard driver registries for existing drivers are listed in the following table: As before, it needs to be changed in advance (eg by using the regedit32 registry editor).

One difficult problem that arises here is that the storage driver 32 must prevent all reads and writes until the NIC driver 74 and network filter driver 30 are initialized. However, the network filter driver does not include the file WIN32.SYS72 and kernel binary that provide system utility functions such as low-level routines for the O / S 40 to display and print.
) Will not be initialized until leading. The problem is that WIN32.SYS caches the client memory 50 early before generating the hibernation image, so that the file is now part of the hibernation image itself that is read into the local memory 50. It is solved by doing. This makes the file WIN32K.SYS
Can read from local memory without having to access the virtual drive 8. With one exception, the storage driver 32 queues all O / S disk write and read requests into the pre-allocated cache during the generation of the hibernation image, ie, at this point in the client system memory 50. . The storage driver 32 simply stores the request until permission to process the request is secure, that is, until the NIC driver 74 and the network filter driver 30 are initialized (step 536). The file WIN32K.SYS is read from the local client memory, and the data is returned to the O / S (step 538).

The O / S 40 then wakes up the NIC driver and network filter driver 30. In step 542, the network filter driver 30 informs the storage driver 32 that the NIC 54 has been initialized and the network filter driver 30 is ready to accept pending read and write requests. Alternatively, the storage driver 32 (Now generating the hibernation image)
“Hook” the dispatch function of the IC driver 74 and monitor the data for its “IRP_MJ_POWER”. This alerts the storage driver 32 when a network driver wakes up. After the O / S 40 sends IRP_MJ_POWER to the NIC driver 74,
The request is always in the full power on state (ie, the NIC is fully usable). The storage driver 32 waits until the NIC driver finishes the processing of IRP_MJ_POWER, that is, until the network driver completely occurs.

In step 544, the storage driver restores the O / S 40 to a usable state, after which the user can use the client PC in the normal manner.
Dequeue all cached read and write requests. It should be noted here that in this embodiment, the storage driver manipulates reads and writes in slightly different ways. That is, the storage driver writes all writes to the virtual drive in order to prevent destroying its data when different clients write to the same virtual image at the same time. Cache locally. Conversely, reads are made by actual reads from the virtual drive, unless a copy of the required sector is cached on the client. In the latter case, the sector is cached from the client's memory and no network transaction takes place.

Synchronous Streaming of Desired Data to Multiple Clients The data necessary to proceed with the boot process in a particular preferred embodiment is described in Applicant's other patent application WO 03/090073. As is shown, it is streamed synchronously from the server 4 to one or more clients 2. The inventive system according to this embodiment is in response to a read request issued by one or more clients 2 and is present in a transparent local disk emulation and in the “virtual” drive 8 of the server. Data sector set content (or
Content) broadcasting or burst mode multicasting.

The flowchart of FIG. 4 illustrates a process 400 for synchronous (or simultaneous) data streaming. Here, in order to complete the network boot of the O / S on the client using the hibernation file, the synchronous streaming process 400 is basically performed twice (with some meaningful differences), ie, the O / S. Used once before and after the driver is initialized. This is because the O / S boot process uses an interrupt handler procedure (or interrupt handler process) during the early stages of the boot process to download files from the virtual drive 8, whereas they are then initialized Storage driver 32 and network filter driver 30
Is to use. This means that two solutions are required to perform substantially equivalent tasks.

Each client desiring to download specific data issues an initial request. The desired data may include a boot program, hibernation file, O / S file, or application file residing on the server virtual drive 8. As these requests are issued to the server 4, the server boots via execution of the PXE code 66 and the downloaded MBR33 code, or through execution of the O / SMBR28 code along with the network filter and storage driver. up(
Emulate the client's local disk 52 during various stages of boot up). (Step 402)

In step 404, the server's streaming module 26 registers each client issuing an initial request during a predetermined solicitation period. Each registered client waits for a data packet from the streaming module 26.

In step 406, the streaming module looks for the sector sequence file 22 on the server 4. The sector sequence file 22 determines the access to the data sector containing the desired data and the broadcast or multicast order of the data sector. If the sector sequence file 22 is not found, the program flow proceeds to a learning process (or learning process) 450 for recording the sector sequence file described later.

In step 408, if the sector sequence file 22 is found, the streaming module 26 broadcasts or multicasts the desired data to registered clients. Data packets are broadcast or multicast at a fixed rate as preferred.

At each registered client 2, the received data packet is stored in a fixed length queue to compensate for the difference between the broadcast or multicast rate and the client boot processing speed (step 410). Network and storage drivers handle streaming in a manner different from the initial MBR / Int 13h hooking process. The driver loads the data into a large temporary section in memory ("data cache") that is pre-allocated in each client.
Each registered client keeps track of (or records the location of) data packets that it has successfully received. Optionally, each registered client sends a server to the most recent N
An acknowledgment (or received signal) is transmitted indicating that attempts have been made to successfully receive the packets (step 412). The purpose of the client acknowledgment is to ensure that the local client buffer is not overrun.

In step 414, the streaming module 26 confirms that all desired data has been accessed and that their content (or content) has been transmitted. If these processes are not complete, step 408 and step 410 are repeated until completion. If all the desired data is broadcast or multicast, the streaming module sends a message indicating that the transmission is complete (step 416).
). However, at this point, not all clients may have received all blocks of information without problems. That is, some packets may be missing for some reason. Also, some clients may miss the start of transmission.
In step 418, each of the clients 2 may respond to the streaming module 26 with a message indicating a successful transmission or a message indicating the need for retransmission of missed packets. The streaming module 26 compiles and effectively orders the list of packet retransmissions (step 420). Alternatively, the list of packet retransmissions (prior to step 414) may be iteratively edited for each determined number of bytes during the transmission of the data packet. Retransmissions may be performed individually between the streaming module and the client (step 422). At this point, most clients are processing received data packets, so the network bandwidth is high, so individual retransmissions have a discernable effect on boot time or network traffic. Would not give.

In step 424, after the downloaded data has been successfully processed, the memory allocated in advance for the cache is deallocated.

As noted above, the advantages of streaming 400 are that each client needs data while the client's O / S is devoted to initializing the O / S data structure, driver, or application. This means that the O / S data that will be required in the future will already be prepared by preloading the data packet into the memory. The streaming module 26 broadcasts and / or multicasts the packet to the client before the client is ready to use the packet, and shifts the boot-up time dependency from the packet transmission time to the client boot processing time. In certain embodiments, the streaming module 26 utilizes the sector sequence file 22 to determine the order of the virtual drive sector content to be transmitted. The sector sequence file 22 is expected to be stored on the server 4 before embarking on a synchronous streaming process, but if this is not done,
The sector sequence file 22 may be generated during the learning process (or learning process) described below.

If the streaming module 26 cannot find the sector sequence file 22, a learning process 450 is performed. The sector sequence file consists of a list of sectors that the O / S must read to complete the boot process. In step 426, the streaming module 26 selects one registered client. The selected client is allowed to boot conventionally using the original MBR 24 and drivers (30 and 32) and the streaming module is in the new sector sequence file and the selected client is booting All the sector access requests generated are recorded (step 428). In step 430, the booting client informs the streaming module that it has completed booting. At this point, the new sector sequence file is stored in the virtual drive 8,
In step 408, the streaming process is resumed. From the above features and implementation of the invention, other embodiments of the invention will be apparent to persons skilled in the art. For example, in some embodiments, the synchronous streaming process 400 is used only for downloading data requested by an interrupt handler procedure (or interrupt handler process),
It may be used only for protected mode access of the server. Alternatively, the synchronous streaming process 400 may be used for preloading applications to clients. Similarly, in another embodiment, an MB for synchronizing request and reception of data packets.
Booting from a network copy of the hibernation image without using an R code is also within the scope of the present invention. Therefore, the foregoing description and examples are illustrative only and the true scope and spirit of the invention is defined by the appended claims.

1 is a block diagram illustrating a client / server network environment in which the present invention is implemented. FIG. FIG. 2 is a block diagram illustrating a network adapter according to one embodiment of the present invention. FIG. 4 is a block diagram illustrating an example of a portion of a client's local memory after an ingenious driver has been downloaded from a network server and executed. Figure 6 is a flowchart illustrating one embodiment of a synchronous streaming process provided by the present invention. 6 is a flowchart illustrating one embodiment of a remote network boot process utilizing a hibernation image file.

Explanation of symbols

2 Client 4 1st server 6 CPU
8 Hard disk (virtual drive)
10 ROM
12 RAM
14 Communication interface (network adapter)
16 bus 18 BIOS
20 Hibernation file 22 Sector sequence file 24 MBR
26 Streaming module 28 O / SMBR
30 Network filter driver 32 Storage driver 33 MBR
34 Second server 36 Client module 38 Network router / switch 40 O / S
42 CPU
44 memory 46 ROM
48 BIOS
50 memory (RAM)
52 Hard disk 54 Network adapter (NIC)
56 System bus 58 Bus interface 60 Network connector 62 RAM
64 OPROM
66 PXE
68 OS network stack 70 Various managers of Windows (registered trademark) 72 Initialization file 74 NIC driver 76 OS driver 78 OS loader

Claims (42)

A method of streaming an operating system from a server on a network to one or more client devices comprising:
The method
Identifying a first server having a virtual boot drive address residing on the network by a pre-runtime boot environment service running on the one or more client devices;
Detecting the virtual boot drive having a hibernation file having operating system data by the pre-runtime boot environment service;
Establishing a virtual drive connection between the one or more client devices and the virtual boot drive using pre-runtime boot code;
Receiving a requested master boot record from the virtual boot drive;
Executing the master boot record on the one or more client devices, the master boot record issuing a request for an operating system loader to the virtual boot drive;
Receiving the operating system loader from the virtual boot drive;
In response to the request issued by a master boot record code, loading the hibernation file downloaded from the virtual boot drive by the operating system loader;
Recovering an operating system on the one or more client devices via the loaded hibernation file;
Using the operating system to launch a driver capable of running the operating system.   The method of claim 1, further comprising locating a boot server on the network, the boot server being associated with the virtual boot drive.   The method of claim 1, further comprising receiving a requested data sector, wherein each data sector is transmitted to the one or more client devices by the virtual boot drive.   The method of claim 1, wherein activating the driver further comprises activating each of a storage device driver and a network filter driver. Relaying a portion of the requested data sector to a storage device driver by the network filter driver;
The method of claim 4, further comprising: initializing the network filter driver by reading a portion of the requested data sector by the operating system. Storing a read request and a write request issued by the operating system in a cache memory;
Initializing a network interface card driver by the operating system;
Retrieving each of the stored read and write requests from the cache memory by the storage device driver, wherein retrieving the read and write requests restores the operating system; 5. The method of claim 4, comprising. A system for streaming an operating system from a server on a network to one or more client devices,
The system
Means for identifying a first server having an address of a virtual boot drive resident on the network by a pre-runtime boot environment service running on the one or more client devices;
Means for detecting the virtual boot drive having a hibernation file having operating system data by the pre-runtime boot environment service;
Means for establishing a virtual drive connection between the one or more client devices and the virtual boot drive using pre-runtime boot code;
Means for receiving a requested master boot record from the virtual boot drive;
Means for executing the master boot record on the one or more client devices, the master boot record issuing a request for an operating system loader to the virtual boot drive;
Means for receiving the operating system loader from the virtual boot drive;
Means for loading the hibernation file downloaded from the virtual boot drive by the operating system loader in response to the request issued by a master boot record code;
Means for recovering an operating system on the one or more client devices via the loaded hibernation file;
Using the operating system to launch a driver capable of running the operating system.   The system of claim 7, further comprising means for locating a boot server on the network, the boot server being associated with the virtual boot drive.   The system of claim 7, further comprising means for receiving a requested data sector, wherein each data sector is transmitted to the one or more client devices by the virtual boot drive.   The system of claim 7, wherein the means for activating the driver further comprises means for activating each of a storage device driver and a network filter driver. Means for relaying a portion of the requested data sector to a storage device driver by the network filter driver;
11. The system of claim 10, further comprising: means for initializing the network filter driver by reading a portion of the requested data sector by the operating system. Means for storing in the cache memory read requests and write requests issued by the operating system;
Means for initializing a network interface card driver by the operating system;
Means for retrieving from the cache memory each read request and write request stored by the storage device driver, wherein retrieving the read request and write request further restores the operating system; The system of claim 10, comprising: A method of booting a client computer to a predetermined state via a network,
The method
Issuing a request for a first set of sectors of a virtual hard disk associated with a server computing device by a client-executable emulation code and a client disk access interrupt procedure, wherein the first set of sectors is a first Including a boot file of
Receiving a first boot file from the server computing device via the network;
Executing the content of the first boot file, comprising:
Installing a second client disk access interrupt handler procedure, the second client disk access interrupt handler procedure intercepts a read request and a write request to the hard disk, and sends the read request to the server computing device; Transferring and caching the write request to prevent the write request from being executed on the virtual hard disk so as to maintain the state of the virtual hard disk;
Issuing a second request for a second set of sectors including a second boot file; and
Receiving the second boot file from the server computing device, wherein the second boot file includes an O / S boot file;
Executing the second boot file, comprising:
Issuing a third request for a third set of sectors containing a hibernation image;
Receiving the hibernation image, wherein the hibernation image includes local memory content, memory management information, and other state information required to restore the client computer to the predetermined state. Including,
Loading the hibernation image into client memory;
Recovering the client computer to the predetermined state by initializing drivers, data structures and applications associated with the O / S.   The method of claim 13, wherein a second client disk access interrupt handler caches the write request locally at the client computer.   The method of claim 13, wherein the second client disk access interrupt handler caches the write request at a location on the network.   The method of claim 13, wherein the emulation code comprises PXE code resident on the client computer.   The method of claim 13, wherein initializing the driver comprises initializing a network filter driver and a storage device driver to enable server emulation.   The method of claim 13, wherein receiving the hibernation image comprises receiving the hibernation image via the server.   The method of claim 13, wherein receiving the second boot file comprises receiving the second boot file on a sector basis.   20. The method of claim 19, further comprising requesting a retransmission of one of the sectors of the second boot file by the client computer.   The method of claim 13, wherein receiving the hibernation image comprises receiving the hibernation image on a sector basis.   The method of claim 21, further comprising requesting retransmission by one of the sectors of the hibernation image by the client computer. A computer readable medium having instructions that, when executed, causes the client computer to boot to a predetermined state over a network;
The computer readable medium is:
Instructions for issuing a request for a first set of sectors of a virtual hard disk associated with a server computing device by a client executable emulation code and a client disk access interrupt procedure, the first set of sectors comprising: Instructions including a first boot file;
Instructions for receiving the first boot file from the server computing device via the network;
Instructions for executing the content of the first boot file comprising:
Instructions for installing a second client disk access interrupt handler procedure, the second client disk access interrupt handler procedure intercepting a read request and a write request to the hard disk, and processing the read request to the server operation An instruction that prevents the write request from being executed in the virtual hard disk so as to keep the state of the virtual hard disk by transferring to the device and caching the write request;
An instruction for issuing a second request for a second set of sectors including a second boot file, and an instruction for receiving the second boot file from the server computing device. The second boot file includes an instruction including an O / S boot file;
An instruction for executing the second boot file,
An instruction including an instruction to issue a third request for a third set of sectors including a hibernation image;
Instructions for receiving the hibernation image, the hibernation image comprising local memory content, memory management information, and other status information required to restore the client computer to the predetermined state Including instructions, and
Instructions for loading the hibernation image into the client memory;
A computer readable medium comprising: instructions for recovering the client computer to the predetermined state by initializing drivers, data structures and applications associated with the O / S.   24. The computer readable medium of claim 23, wherein a second client disk access interrupt handler caches the write request locally at the client computer.   24. The computer-readable medium of claim 23, wherein the second client disk access interrupt handler caches the write request at a location on the network.   24. The computer readable medium of claim 23, wherein the emulation code comprises PXE code resident on the client computer.   The computer-readable medium of claim 23, wherein the instructions for initializing the driver include instructions for initializing a network filter driver and a storage device driver to allow server emulation.   24. The computer-readable medium of claim 23, wherein the instructions for receiving the hibernation image include instructions for receiving the hibernation image via the server.   24. The computer readable medium of claim 23, wherein the instructions for receiving the second boot file include instructions for receiving the second boot file on a sector basis.   30. The computer readable medium of claim 29, further comprising instructions for requesting retransmission by the client computer of one of the sectors of the second boot file.   The computer readable medium of claim 23, wherein the instructions for receiving the hibernation image include instructions for receiving the hibernation image on a sector basis.   32. The computer-readable medium of claim 31, further comprising instructions for requesting a retransmission by one of the sectors of the hibernation image by the client computer. A system for booting a client computer to a predetermined state via a network,
The system
Means for issuing a request for a first set of sectors of a virtual hard disk associated with a server computing device by means of a client-executable emulation code and a client disk access interrupt procedure, the first set of sectors comprising: Including a boot file of, and
Means for receiving a first boot file from the server computing device via the network;
Means for executing the content of the first boot file, comprising:
Means for installing a second client disk access interrupt handler procedure, wherein the second client disk access interrupt handler procedure intercepts a read request and a write request to a hard disk and sends the read request to the server computing device; Means for preventing the write request from being executed in the virtual hard disk so as to maintain the state of the virtual hard disk by transferring and caching the write request;
Means for issuing a second request for a second set of sectors containing a second boot file, and means for receiving the second boot file from the server computing unit, The boot file of 2 includes an O / S boot file;
Means for executing the second boot file, comprising:
Means for issuing a third request for a third set of sectors including a hibernation image; and
Means for receiving the hibernation image, the hibernation image comprising local memory content, memory management information, and other state information required to restore the client computer to the predetermined state; Including, means,
Means for loading the hibernation image into the client memory;
Recovering the client computer to the predetermined state by initializing drivers, data structures and applications associated with the O / S.   34. The system of claim 33, wherein a second client disk access interrupt handler caches the write request locally at the client computer.   34. The system of claim 33, wherein the second client disk access interrupt handler caches the write request at a location on the network.   34. The system of claim 33, wherein the emulation code includes PXE code resident on the client computer.   34. The system of claim 33, wherein the means for initializing the driver includes means for initializing a network filter driver and a storage device driver to enable server emulation.   34. The system of claim 33, wherein the means for receiving the hibernation image includes means for receiving the hibernation image via the server.   34. The system of claim 33, wherein the means for receiving the second boot file includes means for receiving the second boot file on a sector basis.   40. The system of claim 39, further comprising means for requesting a retransmission of one of the sectors of the second boot file by the client computer.   34. The system of claim 33, wherein the means for receiving the hibernation image includes means for receiving the hibernation image on a sector basis.   42. The system of claim 41, further comprising means for requesting a retransmission by one of the sectors of the hibernation image by the client computer.

Images