JP5468490B2 - Method and computer for accessing disk drive in computer with virtualized environment - Google Patents

Description

  The present invention relates to a technique for reducing overhead when accessing a disk drive from a virtual machine, and more particularly to a technique for reducing overhead while ensuring the safety of data recorded in a disk drive.

  For computers such as clients and servers, past operating systems (OS) and application programs (applications) can be operated on new incompatible hardware, and hardware resources can be used effectively. In some cases, virtualization technology is introduced for the purpose of operating a plurality of OSs simultaneously. The virtualization technology includes a host OS type in which a virtualization program operates on an OS, or a hypervisor type in which a virtualization program directly operates on hardware.

  In either case, a plurality of virtual machines can operate on the virtualization program. A virtual machine configured by software such as an application, a guest OS, and a device driver operates in a state separated from actual hardware by accessing virtual hardware provided by a virtualization program. The OS constituting the virtual machine is called a guest OS. In addition, in the hypervisor type, there are methods such as full virtualization that provides a complete hardware virtualization environment for the guest OS, and paravirtualization that modifies the guest OS and adapts it to the virtualization environment. .

  As described above, there are various virtual environment implementation models, but in any case, when the guest OS accesses the hardware, an extra overhead is generated by the intervention of the virtual program. Causes of overhead include processing to emulate hardware such as a central processing unit (CPU), main memory, disk drive, or network card with software, and switching operation between the guest OS and the virtualization program Context switching that occurs at the time. When an I / O request is made to a hard disk drive (HDD), overhead is generated to map the addresses of the virtual drive and the actual drive.

  Patent Document 1 discloses an emulation method that implements operation of an I / O device by emulation using a VMM (Virtual Machine Monitor), and direct access to an OS operating on a virtual machine by directly assigning an actual I / O device. A technique for switching between I / O systems is disclosed. In the direct I / O method, input / output to / from the I / O device can be performed directly from the OS, so that high-speed and highly reliable processing can be performed, but each OS occupies the I / O device. Therefore, it is described that even if a plurality of OSs can be executed on one host machine by the virtualization technology, an I / O device is required depending on the number of OSs, which is inefficient.

  Patent Document 2 discloses a technique for efficiently storing files by providing a cache area in a part of a hard disk in a storage device including a hard disk drive and a magnetic tape drive. Non-Patent Document 1 discloses a device that reduces the overhead of a virtual environment by realizing device separation for a specified guest OS and allowing only the specified guest OS to use the separated device. A technique called pass-through is disclosed. Device pass-through can be applied to devices that do not need to be shared between a plurality of guest OSes and virtualization programs, or to devices that cannot be shared.

JP 2009-223793 A JP 2003-150413 A

M. Tim Jones, “Linux (registered trademark) virtualization and PCI passthrough”, [online], [searched on July 13, 2010], Internet <URL: http://www.ibm.com/developerworks/ jp / linux / library / l-pci-passthrough /? ca = drs-jp>

  When a guest OS accesses an HDD or a flash SSD (Flash Solid State Drive) in a virtual environment, overhead occurs as described above. When a virtual environment is realized by a personal computer, it is common to share one piece of hardware between a virtualization program and a plurality of guest OSs. In the virtual environment, the guest OS operates like an application on the OS in the non-virtualized environment with respect to the virtual program. A privilege level can be set for the CPU by a ring protection mechanism.

  When a plurality of guest OSs operate on the virtualization program, the guest OSs are in an equal relationship, and thus the specific guest OS cannot freely occupy hardware. Further, when a specific guest OS can directly access the HDD, there is a safety problem because the guest OSs are not separated. Therefore, in the virtual environment, the maximum privilege level is basically given to the virtualization program to permit access to the hardware, and the guest OS accesses the hardware via the virtualization program. Therefore, the guest OS cannot be directly accessed by applying the direct I / O method of Patent Document 1 or the device pass-through of Non-Patent Document 1 to an HDD in which programs of a plurality of virtual machines are recorded.

  Accordingly, an object of the present invention is to provide a computer capable of reducing overhead when accessing a disk drive from a virtual environment. It is another object of the present invention to provide a computer that can access a disk drive storing a virtualization program and a guest OS while ensuring safety. A further object of the present invention is to provide a computer program for realizing such a computer and a method for accessing a disk drive.

  In the virtual environment, access to the disk drive is performed on the virtual disk drive provided to the virtual machine by the virtualization program. The virtualization program maps the virtual disk drive address to the actual disk drive address. Therefore, since access to the disk drive is accompanied by the operation of the virtual program, overhead of context switching and address mapping from the virtual machine to the virtualized program occurs.

  The computer according to the present invention allows a virtual machine to directly access a disk drive, eliminating the overhead inherent in accessing the disk drive under a virtualized environment. The disk drive may be connected to the computer via a network. Further, the format of the disk drive in the present invention is not particularly limited, and may be HDD or SSD in one example.

  In the present invention, a specific area that the virtual machine can access to the disk drive and a virtualization area that the virtual machine cannot access are set. The specific area is set for the purpose of removing overhead in the software layer, unlike a cache that absorbs the difference in operating speed of hardware such as a CPU and a main memory. The virtualization area is a storage area provided by the disk drive for the virtualization environment, and a virtual machine and a virtualization program are recorded therein. An application or guest OS process initiates an I / O request to the virtualized area. When the guest OS determines that the I / O request is a write access for writing data to the virtualization area, the guest OS writes the write data to the specific area.

  Therefore, it is possible to eliminate the overhead generated by the operation of the virtualization program at the time of write access to the disk drive. The computer transitions between the operation of the virtual machine and the operation of the virtualization program when the guest OS makes an I / O request to the disk drive. Set so that the virtual machine can access only a specific area while the virtual machine is running, and dynamically so that the specific area and the virtual area can be accessed while the virtualization program is running Can be set to

  The specific area can be set in the register of the disk controller by the virtualization program executing the ATA Set max address command. The parameter of the Set max address command can be changed dynamically at the timing of context switching. By setting the specific area in this way, the virtual machine can accept an I / O request to the disk drive, and the virtual machine can write data to the specific area permitted to be accessed. In addition, since the virtual machine cannot access the virtualization area, the security of the data recorded in the virtualization area is guaranteed.

  At this time, it is also possible for the virtualization program to generate a password and request the password to change the setting of the Set max address command. When a plurality of virtual machines operate in a time-sharing manner, the specific area can be divided into a plurality of logical blocks and dedicated to a plurality of virtual machines. When a virtual machine that uses a specific area is replaced or when the storage capacity of the specific area is insufficient, the virtual area is updated with the data recorded in the specific area asynchronously with write access, and the specific area is updated. Storage capacity can be secured. If the update is performed at idle time or shut-down timing, it is possible to make the user hardly feel the update overhead. If the virtualization program executes the update, the overhead due to context switching that occurs in the update process can be reduced.

  In the case of read access, when it is determined that the read data is already recorded in the specific area, the virtual machine can read the data from the specific area. Therefore, the overhead due to the operation of the virtualization program can be reduced even during read access. Further, when it is determined that the read data is not recorded in the specific area, the virtual machine can read from the virtual area by a normal procedure.

  An overhead occurs when reading from the virtualization area. In addition, the read data is likely to be read again in the near future. Since the read access to the data once read is performed again, the read data can be recorded in the specific area asynchronously with the read access. The number of disk drives is not limited to one, and the present invention can also be applied to a case where a single virtual disk drive is configured by a plurality of disk drives such as RAID. .

  According to the present invention, it is possible to provide a computer capable of reducing overhead in accessing a disk drive from a virtual environment. Further, according to the present invention, it is possible to provide a computer that can access a disk drive storing a virtualization program and a guest OS while ensuring safety. Further, according to the present invention, it is possible to provide a computer program for realizing such a computer and a method for accessing a disk drive.

It is a figure which shows the structure of the software and hardware of a computer by which the virtual environment was implement | achieved. It is a figure explaining the principle which reduces the overhead at the time of accessing HDD. It is a figure explaining the method to protect a virtual area from access of a guest OS. FIG. 2 is a functional block diagram of software and hardware constituting a disk access control system for accessing an HDD by a file transfer method. It is a figure which shows the data structure of an address mapping table. It is a flowchart which shows the procedure when a virtual machine records a file on HDD by a file transfer system. It is a flowchart which shows the procedure when a virtual machine reads a file from HDD by a file transfer system. FIG. 2 is a functional block diagram of software and hardware constituting a disk access control system for accessing an HDD by a mirroring method. It is a figure which shows the address relationship of the specific area | region and virtual HDD in a mirroring system. It is a flowchart which shows the procedure when a virtual machine records a file on HDD by a mirroring system.

[Virtualized environment]
FIG. 1 is a diagram illustrating a software and hardware configuration of a computer 10 in which a predetermined program is executed to realize a virtual environment. In FIG. 1, a hypervisor type virtualization model referred to as a so-called type 1 is described as an example, but the present invention can also be applied to a host OS type virtualization model. The computer 10 typically includes, as hardware 19, a CPU 21, a main memory 23, an HDD 25, and an IDE controller 26 that serves as an interface between the system and the HDD 25. The hardware configuration in the present invention is well known. On the hardware 19, a virtualization program 17 called a hypervisor or VMM directly operates.

  On the layer of the virtualization program 17, a plurality of virtual machines 11, 13, and 15 can operate in a time division manner. Alternatively, only one selected virtual machine can operate. Each virtual machine 11, 13, 15 is configured by software such as applications 73, 75, 77, guest OSs 67, 69, 71, and virtual hardware 61, 63, 65. The virtualization program 17 emulates hardware such as the CPU 21, the main memory 23, the HDD 25, and the IDE controller 26, and the virtual hardware 61, 63, 63, 63, 63, 63, 63, 65 is provided.

  In this example, the virtual hardware 61, 63, 65 includes a virtual CPU, a virtual main memory, a virtual HDD, and a virtual IDE controller corresponding to the components of the hardware 19, respectively. The guest OSs 67, 69, 71 and the virtualization program 17 include modules for reducing overhead caused by the intervention of the virtualization program 17 when each virtual machine 11, 13, 15 accesses the HDD 25. Yes. The programs constituting the virtual machines 11, 13, and 15 and the virtualization program 17 are executed by the CPU 21, the main memory 23, and the like, and may be captured as hardware elements that cause the computer 10 to perform predetermined functions. it can.

[Basic principle of overhead reduction]
FIG. 2 is a diagram for explaining the principle of reducing overhead when the virtual machines 11, 13, and 15 access the HDD 25 according to this embodiment. The guest OSs 67, 69, 71 access the HDD 25 using the file path provided by the virtual HDDs 61, 63, 65 as a virtual interface. There are two types of hypervisor methods: full-virtualization and para-virtualization. In the complete virtualization method, since the virtualization program 17 constructs a complete virtualization environment, the guest OSs 67, 69, and 71 do not need to be modified to cope with the virtualization environment. The virtual program 17 operates at the maximum privilege level, and each guest OS operates at a privilege level lower than that.

  However, since each guest OS does not recognize that it is operating in a virtual environment, access to the HDD 25 that is allowed only by a program operating at the maximum privilege level is allowed for the virtual HDDs 61, 63, 65. To do. When the guest OS accesses the HDD 25, a privilege violation violation occurs in the CPU 21, and control is transferred to the virtualization program 17 that traps the exception, and the access to the HDD 25 is processed.

  In the para-virtualization method, when the guest OS 67, 69, 71 accesses the HDD 25, a hypervisor call is issued to call an internal function of the virtualization program 17, and the virtual machines 11, 13, 15 are changed or virtualized. Requesting the processing program 17 to perform processing. The para-virtualization method can perform high-speed processing as compared with the full virtualization method, but the guest OS needs to be modified. When the guest OS 67, 69, 71 accesses the HDD 25 in both the full virtualization method and the para-virtualization method, context switching when the control is transferred to the virtualization program 17, and the virtual HDDs 61, 63, Overhead is generated to map the addresses of 65 and HDD 25.

  In the present embodiment, the virtualization program 17 logically divides the storage area of the HDD 25 into a specific area 51 and a virtual area 53. The specific area 51 is a storage area that can be directly accessed by any of the guest OSs selected from the guest OSs 67, 69, and 71 (here, the guest OS 67) without going through the virtualization program 17. The virtualization area 53 is a storage area in which data such as the programs and files constituting the virtualization program 17 and the virtual machines 11, 13, and 15 are recorded and accessed by the guest OS 67 via the virtualization program 17. .

  Data corresponding to the virtual machines 11, 13, and 15 are recorded in the data areas 55, 57, and 59. In the data areas 55, 57, and 59, applications, OSs, device drivers, user data, and the like related to the respective virtual machines 11, 13, and 15 are recorded. When the virtualization program 17 emulates the HDD 25 as the virtual HDDs 61, 63, 65, the virtualization area 53 is logically divided into virtual HDDs 61, 63, 65 to secure the data areas 55, 57, 59. Alternatively, the entire virtual area 53 may be used to map the addresses of the virtual HDDs 61, 63, 65 and the address of the virtual area 53.

  The virtual machines 11, 13, and 15 do not need to recognize the address of the HDD 25 for the data to be accessed, and recognize only the addresses of the virtual HDDs 61, 63, and 65 and access the virtualization area 53 of the HDD 25. The guest OS 67 using the specific area 51 records a guest OS identifier indicating that the specific area 51 itself was used at a predetermined address. Then, the guest OS 67 writes all the write data to the specific area 51 at the time of write access for writing the file to the HDD 25. The virtualization area 53 plays a role as an original data storage location for the virtual machines 11, 13, and 15. In addition, the specific area 51 may be used by other guest OSs 69 and 71. The guest OS 67 instructs the virtualization program 17 to write the data recorded only in the specific area 51 to the virtualization area 53 asynchronously with the write access.

  When performing read access to read a file from the HDD 25, the guest OS 67 reads from the specific area 51 when read data is recorded in the specific area 51, and a virtual area 53 when read data is not recorded. Read from. In order to increase the chance of reading from the specific area 51, the guest OS 67 can write the file once read into the specific area 51 asynchronously with read access. In order for the guest OS 67 to access the HDD 25 thus virtualized, the data in the virtualized area 53 is protected while allowing the guest OS 67 to access the HDD 25 as follows.

  When the virtualization program 17 operates in the ring 0 and the guest OS 67 operates in the rings 1, 2, and 3, the access to the HDD 25 of the guest OS 67 becomes a privileged instruction violation and is trapped by the virtualization program 17 and the control of the CPU 21 is virtual. Shift to the computer program 17. In the virtualization support mechanism called Intel's VT (Virtualization Technology) and X86 virtualization, the guest OS 67 accesses the HDD 25 by controlling the access to the hardware for each I / O port by the object called I / O-bitmap. However, a technique for preventing the control from being transferred to the virtualization program 17 is provided.

  The virtualization program 17 describes parameters in the I / O-bitmap object, and controls I / O requests to the I / O port of the IDE controller 26 by the guest OS 67. The virtualization program 17 is described in the I / O-bitmap so that the access to the HDD 25 by the guest OS 67 is not trapped when the virtualization program 17 uses the specific area 51 and is trapped when the specific area 51 is not used. To do.

  In this way, the guest OS 67 can access the specific area 51. However, since control by the I / O-bitmap is in units of address of the I / O port, the guest OS 67 is released when the I / O port is released. Not only the specific area 51 but also the virtual area 53 can be accessed. Therefore, in the present embodiment, the guest OS 67 is prevented from accessing the virtualization area 53 as follows, while adopting a control method based on I / O-bitmap. Note that the virtualization support mechanism called Intel's VT or AMD's Pacifica employs a context-based privilege grant system, unlike the privilege level control by ring protection. In this case, it is not necessary to control the transition of the operation to the virtualization program 17 with the I / O-bitmap.

[Virtual Area Protection Method]
FIG. 3 is a diagram for explaining a method of protecting the virtual area 53 from access by the guest OS 67. According to the ATA (Advanced Technology Attachment) interface standard, it is possible to set an HPA (Host Protected Area) in which only a special program can access the storage area of the disk. In the present embodiment, the HPA setting is dynamically changed by linking the transition of the operation of the guest OS 67 and the operation of the virtualization program 17, and the guest OS 67 accesses the specific area 51 while the guest OS 67 is operating. Although it is possible, the virtual area 53 cannot be accessed.

In order to set the HPA in the HDD 25, the virtualization program 17 issues a Set max address command to set a valid address range of the HDD 25 in the register of the IDE controller 26. When the set value is smaller than the maximum storage capacity of the HDD 25, the storage capacity that can be used by the guest OS 67 or the virtualization program 17 is reduced. FIG. 3A shows a state in which the Set max address command is set to X (%) of the maximum storage capacity. In this case, 0% to X% of the storage capacity of the HDD 25 corresponds to the specific area 51, and more than 100% to 100% corresponds to the virtual area 53 in which access is restricted by setting HPA .

  Neither the guest OS 67 nor the virtualization program 17 can access the HPA. Therefore, if the HPA is set when the operation of the CPU 21 transitions to the execution of the guest OS 67, the guest OS 67 can access the specific area 51 but cannot access the virtualization area 53. FIG. 3B shows a state where the effective address range is set to 100% with the Set max address command. Since HPA is not set in this state, the guest OS 67 and the virtualization program 17 can access both the specific area 51 and the virtual area 53.

  Here, the virtualization program 17 issues a Set max address command with a parameter of 100% only when the operation of the CPU 21 transitions to the execution of the virtualization program 17, so that only the specific area 51 and the virtualization area 53 are themselves. To be able to access. As described above, even if the I / O port of the IDE controller 26 is opened to the guest OS 67 by the I / O-bitmap, the HPA is dynamically changed according to the transition of the CPU 21 between the guest OS 67 and the virtualization program 17. Is set, the access to the virtualization area 53 of the guest OS 67 can be restricted, and the access restriction on the virtualization program 17 can be released.

  If the guest OS 67 can change the HPA by issuing the Set max address command, the safety of the data recorded in the virtualization area 53 cannot be ensured. To ensure data security, you can require a password to issue the Set max address command. That is, the HPA once set by the virtualization program 17 can be prevented from being changed by the guest OS 67 unless a password is acquired. The password is not set by the user, and the virtualization program 17 can generate and generate a random number independently.

[File transfer method]
FIG. 4 is a functional block diagram of software and hardware constituting the disk access control system 100 that accesses the HDD 25 by the file transfer method. The disk access control system 100 is mounted on the computer 10. The virtual machine 11 includes an application 73, a guest OS 67, a virtual HDD 61, and an address mapping table (AMP) 93 as elements related to the present embodiment. The guest OS 67 is described using Windows (registered trademark) as an example, but other OS can be applied to the present invention. The application 73 operates in the user mode. The application 73 is a program that can call API functions via a subsystem DLL (Dynamic Link Library) and write / read data to / from the virtual HDD 61.

  The application 73 may be an installer that installs a program in the virtual HDD 61. A system service dispatcher (SSD) 83 is responsible for switching between the user mode and the kernel mode. The SSD 83 confirms the call number of the interrupt generated during the system call service called from the application 73 operating in the user mode, and switches the API function to the internal support function operating in the kernel mode.

  The I / O manager 85 creates an IRP (I / O Request Packet) and dispatches it to a predetermined device driver in order to perform communication between device driver hierarchies related to the input / output of the stack structure. The IRP is used for communication between each device driver and the I / O manager 85. A device driver related to access to the HDD 25 includes a file system driver 87, an access control driver 89, and a disk driver 91. The file system driver 87 forms a file system such as FAT (File Allocation Table) or NTFS (NT File System) to manage I / O requests such as recording, reading, deleting, or moving files related to the virtual HDD 61. To do.

  The file system driver 87 provides a file path for the virtual HDD 61 to the application 73. The file system driver 87 converts the file path specified in the API function received from the I / O manager 85 into an LBA (logical block address) of the virtual HDD 61 and sends it to the access control driver 89. The access control driver 89 is a program that processes an I / O request to the virtual HDD 61 using the specific area 51 of the HDD 25. The access control driver 89 can refer to and update the AMP 93. The access control driver 89 further determines the timing for updating the specific area 51 or the virtualization area 53.

  The disk driver 91 has a hierarchical structure, and converts an I / O request received from the access control driver 89 for reading or writing a predetermined LBA of the virtual HDD 61 into a protocol for controlling the HDD 25. To the virtual HDD 61. The virtual HDD 61 is provided by the virtualization program 17 and provides a virtualized interface to the virtual machine 11 by abstracting the virtualization area 53 of the HDD 25. The virtual HDD 61 simply provides a file path interface to the I / O request from the disk driver 91 and does not respond directly.

  The virtualization program 17 includes an access manager 101, an HPA manager 102, a file system driver 103, and a disk driver 105 as elements related to the present embodiment. The access manager 101 is a program for updating the virtualization area 53 with the data of the specific area 51 when a request to update the virtualization area 53 is received from the access control driver 89.

The access manager 101 passes the I / O request received from the disk driver 91 to the file system driver 103 without performing any processing. The HPA manager 102 releases the HPA when an I / O request of the guest OS 61 is issued and the control shifts from the guest OS 67 to the virtualization program 17, and when the control shifts from the virtualization program 17 to the guest OS 67. This is a program that sets a parameter to set an HPA and issues a Set max address command.

  The access manager 101 passes the read data from the virtualization area 53 received from the file system driver 103 to the disk driver 91 without performing any processing. The file system driver 103 manages the file path of the virtualization area 53. The file system driver 103 converts the virtual LBA of the virtual HDD 61 in which a predetermined file is recorded into the LBA of the virtual area 53 that is actually recorded. The disk driver 105 converts the I / O request received to the HDD 25 into a predetermined protocol and executes it.

  FIG. 5 shows the data structure of AMP93. The AMP 93 shown in FIG. 5A associates the LBA provided by the virtual HDD 61 to the guest OS 67 and the LBA in the specific area 51 where data is actually recorded for specific three files. Here, in order to simplify the description, one file is associated in units of LBA.

  In the HDD 25, it is assumed that addresses from LBA001 to LBAnnn are sequentially assigned to all sectors of the disk from the specific area 51 to the virtualization area 53. LBA001 to LBA100 correspond to the specific area 51, and LBA101 to LBAnnn correspond to the virtual area 53. It is assumed that addresses from LBA001 to LBAmmm are assigned to the virtual HDD 61 by the virtualization program 17.

  The update flag is information indicating that the virtualization area 53 needs to be updated with the data of the specific area 51. The access control driver 89 resets (0) the update flag when the data recorded in the corresponding LBAs of the virtual HDD 61 and the specific area 53 do not match, and sets (1) when they match. When the update flag is set, data can be deleted from the specific area 51 without updating the virtualization area 53. A method for setting the update flag will be described later. The registration date and time is information for determining the order in which the virtual area 53 is updated and then deleted when the storage capacity of the specific area 51 decreases. The access control driver 89 writes the date and time when the entry is registered in the AMP 93 in the registration date and time column.

  Next, the operation of the disk access control system 100 will be described with reference to the flowcharts of FIGS. FIG. 6 is a flowchart showing a procedure when the virtual machine 11 records a file in the HDD 25. The virtual machines 13 and 15 may perform time-sharing operation in the computer 10 together with the virtual machine 11, but are excluded from the description because the virtual machines 13 and 15 do not use the specific area 51 in the procedure here.

  In block 201, a virtual environment in which the computer 10 operates and the virtualization program 17 and the virtual machine 11 of FIG. 1 operate is realized. In the startup routine of the computer 10 or when the virtual machine 11 is loaded after the virtual program 17 operates, the access control driver 89 reads the guest OS identifier from a predetermined address in the specific area 51. Then, it is determined whether or not the specific area 51 has been used by itself.

  If it is determined that the specific area 51 has been used by itself, the access control driver 89 continues to use the data recorded in the specific area 51 and the entry of the AMP 93. When it is determined that the specific area 51 is being used by another virtual machine 13 or 15, the access control driver 89 initializes the specific area 51 and the AMP 93. The virtualization program 17 describes parameters in the I / O-bitmap so that the operation of the CPU 21 does not shift to the virtualization program 17 even when the guest OS 67 accesses the HDD 25.

  When the virtual machine 11 operates, the HPA manager 102 issues a Set max address command with the parameter X (%), sets the virtualization area 53 to HPA as shown in FIG. When is operated, a Set max address command with a parameter of 100% is issued to cancel the HPA as shown in FIG. The virtualization program 17 has sufficient storage in the specific area 51 to install a new application by the virtual machine 11, record a file by the application 73, or record a file read from the virtualization area 53. It is desirable to secure capacity. However, even in the case where it is not possible to secure a storage capacity for recording these data at a time in the specific area 51, in the present embodiment, the data of the specific area 51 can be replaced.

  In block 203, the application 73 requests to create a process for recording a new file in the guest OS 67 by calling an API function or a process for updating the file read from the virtualization area 51. The process does not recognize the LBA of the virtual HDD 61 as the file storage location, and sets the file path in the virtual HDD 61 provided by the file system driver 87 in the API function as a parameter related to the file recording location. The SSD 83 converts the API function into an internal support function and sends it to the I / O manager 85.

  The I / O manager 85 communicates with each device driver by describing a request for an internal support function in the IRP. Each device driver also communicates with other device drivers by writing in the IRP received from the I / O manager 85 and returning it to the I / O manager 85. The file system driver 87 converts the file path specified by the API function into the LBA of the virtual HDD 61 and sends it to the access control driver 89.

  Here, it is assumed that the file system driver 87 assigns the LBA007 of the virtual HDD 61 to the file name and file path specified by the application 73. In block 205, the access control driver 89 determines whether the I / O request is a write access or a read access. In the case of read access, the process moves to block 209. The read access process will be described with reference to FIG. Some I / O requests are related to file deletion and file movement. However, if the write access process and read access process according to the present embodiment are described, those processing methods will be understood by those skilled in the art. The explanation will be omitted.

  In the processing so far, the write data to the HDD 25 is written in the virtual area 53 with the virtual HDD 61 as an interface. In the present embodiment, all the write data is once written in the specific area 51. Therefore, in block 207, the access control driver 89 refers to the AMP 93 to search for an empty LBA in the specific area 51, and for the LBA 007 assigned by the file system driver 87, the LBA001 in the specific area 51. Assign.

  In block 211, the access control driver 89 requests the disk driver 91 to write a file to the LBA 001 in the specific area 51. The disk driver 91 requests the HDD 25 to record the file in the LBA001 in the specific area 51. Since the virtualization program 17 sets a parameter in the I / O-bitmap so as not to trap the access to the HDD 25 of the guest OS 67, the disk driver 91 directly specifies it through the IDE controller 26 without calling the virtualization program 17. A file can be written in the area 51. Therefore, in this embodiment, it is possible to remove the overhead generated by the processing of the virtualization program 17 for all write data at the time of write access.

  The disk driver 91 that has received the write completion notification from the HDD 25 notifies the access control driver 89 to that effect in block 213. The access control driver 89 that has received the notification updates the AMP 93 at block 215. That is, since a new file is recorded in the specific area 51, the access control driver 89 registers the LBA007 of the corresponding virtual HDD 61 and the LBA001 of the specific area 51 in the AMP 93 and further writes the registration date and time. At this time, since the file of LBA007 in the specific area 51 is not recorded in the virtualization area 53, the update flag is reset.

  The specific area 51 is an area for recording all the write data at the time of a write request in place of the virtual area 53. When the storage capacity is small, the application and user data related to the guest OS 67 cannot be written. Things happen. However, unlike the cache such as the CPU or the main memory, the specific area 51 does not disappear even if the power is lost. Therefore, as long as data is additionally recorded, the remaining storage capacity is Less.

  Therefore, when the storage capacity of the specific area 51 is smaller than the storage capacity set in the virtual HDD 61, there is a possibility that data cannot be written. In block 217, the access control driver 89 refers to the AMP 93 to determine whether or not the remaining storage capacity of the specific area 51 is equal to or less than a predetermined value. If the remaining storage capacity is equal to or less than the predetermined value, it is determined that the virtualization area 53 needs to be updated, and the process proceeds to block 219. If the remaining storage capacity exceeds the predetermined value, there is no need to update, so the process proceeds to block 223.

  In block 219, the access control driver 89 refers to the AMP 93 to acquire the pair of the virtual HDD 61 whose update flag is reset and the LBA of the specific area 51. In the example of FIG. 5A, data recorded in LBA001 and 002 in the specific area where the update flag is reset is targeted. Further, the access control driver 89 issues a system call for transferring the operation to the virtualization program 17, and the virtualization area 53 corresponding to the LBA 007 and 009 of the virtual HDD 61 with the data of the LBA 001 and 002 in the specific area 51. Is requested to update the access manager 101.

  The operation of the CPU 21 shifts to the virtualization program 17 when the virtualization program 17 traps the system call. Since the HPA manager 102 does not set the HPA when it operates, the disk driver 105 can access the entire HDD 25. Upon receiving the update request, the access manager 101 requests the disk driver 105 to read data from the LBAs 001 and 002 in the specific area 51.

  Further, the access manager 101 requests the file system driver 103 to write the read data to the LBA007 and 009 of the virtual HDD 61. The file system driver 103 maps the received LBAs 007 and 009 of the virtual HDD 61 to predetermined LBAs such as LBAs 101 and 102 in the virtualization area 53 and issues a write request to the disk driver 105.

  LBAs 101 and 102 are part of the data area 55 in FIG. Since the virtualization area 53 is updated only by the virtualization program 17, no overhead associated with context switching occurs even if a plurality of LBAs are updated. Unless the data recorded in the specific area 51 is deleted when another virtual machine uses it, when the application 73 performs read access to the LBA007 and 009 of the virtual HDD 61 later, the read data is virtualized. The data can be read from the LBAs 101 and 102 in the conversion area 53.

  In block 221, the access manager 101 that has received the update completion notification from the disk driver 105 notifies the access control driver 89 of the updated LBA007, 009 of the virtual HDD or the LBA001, 002 of the specific area 51. . The access control driver 89 that has received the notification sets an update flag corresponding to the LBA that has been updated in the AMP 93.

  Thereafter, when the storage capacity of the specific area 51 is insufficient when writing new data to the specific area 51, the LBA updated most recently among the LBAs of the specific area 51 in which the update flag is set. The specific area 51 can be used by overwriting. In the above procedure, at block 217, it is determined whether or not the virtualization area 53 needs to be updated based on the remaining storage capacity of the specific area 51. Since it is safe, there is no problem even if the state where the update flag is reset continues for a long time. Therefore, as long as the remaining storage capacity of the specific area 51 is not insufficient, the procedure of block 217 is performed as follows: a shutdown event of the computer 10 issued by the guest OS 67, an idle event of the CPU 21, or a periodic timer of the guest OS 67. You may perform based on an event.

  However, it is not preferable to update the virtualization area 53 at the timing of newly writing data to the specific area 51 or updating the data in the specific area 51 because the overhead in the virtualization program 17 increases. The virtualization area 53 is preferably updated asynchronously with the write access after a certain amount of data is recorded in the specific area 51. By updating the data collectively, overhead associated with context switching between the virtual machine 11 and the virtualization program 17 can be reduced.

  FIG. 7 is a flowchart illustrating a procedure when the virtual machine 11 reads a file from the HDD 25. Assume that three entries as shown in FIG. 5A are registered in the AMP 93. In block 301, following block 209 in FIG. 6, the file system driver 87 converts the file path specified by the process into the LBA of the virtual HDD 61 and sends it to the access control driver 89. The access control driver 89 determines whether or not the LBA of the virtual HDD 61 designated in the read access is registered in the AMP 93.

  If the LBA of the virtual HDD 61 related to the read request is, for example, LBA009 and is registered in the AMP 93, the process proceeds to block 303. In block 303, the access control driver 89 acquires from the AMP 93 the LBA 002 in the specific area corresponding to the LBA 009 of the virtual HDD 61 received from the file system driver 87. In block 305, the access control driver 89 requests the disk driver 91 to read the file from the LBA 002 in the specific area 51. Since the guest OS 67 directly accesses the specific area 51 to read the file and the control does not transfer to the virtualization program 17, the overhead can be removed.

  If the LBA of the virtual HDD 61 related to the read request is not registered in the AMP 93 with the LBA 011 in block 301, for example, the process proceeds to block 307. In block 307, the access control driver 89 sends the LBA 011 included in the I / O request received from the file system driver 87 to the disk driver 91 without change, and shifts to the virtualization program 17. When the system call is issued, the operation of the CPU 21 shifts to the virtualization program 17.

  It is assumed that the LBA 011 included in the read request is mapped to, for example, the LBA 105 in the virtualization area 53 by the file system driver 103. The file system driver 103 converts the received read request LBA 011 into the LBA 105 and sends it to the disk driver 105. The disk driver 105 sends the file read from the LBA 105 in the virtualization area 53 to the access control driver 89 via the access manager 101 and the disk driver 91.

  The access control driver 89 that has received the file related to the read request registers the LBA 011 of the virtual HDD 61 in the AMP 93 as shown in FIG. However, at this time, since the file of the LBA 105 of the virtual area 53 is not recorded in the specific area 51, the LBA entry of the specific area 51 corresponding to the LBA 011 of the virtual HDD 61 is blank. After registering only the entry of the read virtual HDD 61 in the AMP 93, the access control driver 89 passes the received file to the application 73.

  According to the procedure up to block 309, there is data that has been read from the virtualization area 53 and not written to the specific area 51. The data accessed most recently is likely to be accessed again soon. Therefore, in the present embodiment, data once read from the virtualization area 53 is recorded in the specific area 51, and reading from the specific area 51 is enabled for the next and subsequent read accesses. However, if the specific area 51 is updated each time reading is performed, the overhead becomes large. Therefore, the reading process from the virtualization area 53 and the writing process to the specific area 51 are performed asynchronously or at different timings.

  In block 311, the access control driver 89 determines whether or not the data in the specific area 51 needs to be updated. The determination can be made based on an event issued by the guest OS 67 indicating that a certain time interval has passed, an event indicating shutdown, an event indicating the idle state of the CPU 21, or the like. In block 313, the access control driver 89 that has received an event indicating the necessity of updating the specific area 51 from a predetermined module of the guest OS 67 refers to the AMP 93 to search for an entry in which the specific area 51 is empty. The LBA 011 of the HDD 61 is acquired.

  The access control driver 89 assigns LBA004, which is a free address in the specific area 51, to the LBA011 of the virtual HDD 61. The access control driver 89 calls an internal support function for accessing the HDD 25, reads a file from the LBA 105 in the virtualization area via the LBA 011 of the virtual HDD 61, and further reads the read file to the LBA 004 in the specific area 51. Requests the disk driver 91 to record. The disk driver 91 reads a file from the virtualization area 53 via the virtualization program 17 and writes it directly to the specific area 51. As a result, the data of the LBA 105 read from the virtualization area 53 between the previous update of the specific area 51 and the current update is written to the LBA 004 of the specific area 51.

  In block 315, the disk driver 91 notifies the access control driver 89 that the writing to the specific area 51 has been completed. The access control driver 89 that has received the notification registers the LBA 004 of the specific area 51 in association with the LBA 011 of the virtual HDD 61 in the AMP 93 as shown in FIG. 5C, and sets an update flag. The access control driver 89 simultaneously writes the registration date / time in the AMP 93.

[Mirroring method]
FIG. 8 is a functional block diagram of software and hardware constituting the disk access control system 300 that accesses the HDD 25 by the mirroring method. The disk access control system 300 is different from the disk access control system 100 of FIG. 4 in the functions of the access control driver 301 and the access manager 305, the data structure of the AMP 303, and the capacity of the specific area 307. Hereinafter, this difference will be mainly described.

  FIG. 9A is a diagram showing the address relationship between the specific area 307 and the virtual HDD 61 by the mirroring method. In the mirroring method, the disk image of the virtual HDD 61 is copied to the specific area 307. Therefore, the virtualization program 17 sets the parameters so that the storage capacity of the specific area 307 is equal to or larger than the storage capacity of the data area 55 allocated to the virtual machine 11 in the virtualization area 309 and issues a Set max address command. To do. Here, it is assumed that the specific area 307 is set to LBA000 to LBAxxx of the HDD 25.

  Then, the virtualization program 17 provides the file system driver 87 through the virtual HDD 61 with an interface of LBA000 to LBAxxx having the same address range as the specific area 307. As shown in FIG. 9B, since the LBA of the virtual HDD 61 and the LBA of the specific area 307 are mapped with the same address in the AMP 303, only the common LBA is registered. The functions of the access control driver 301 and the access manager 305 will be described based on the procedures in FIGS. The registration date and time is recorded by the access control driver 301 at the timing when the entry is registered in the AMP 303.

  FIG. 10 is a flowchart showing a procedure when the application 73 records a file in the HDD 25. Blocks 401 to 405 and 409 are the same as the procedures of blocks 201 to 205 and block 209 in FIG. In the mirroring method, the LBA of the virtual HDD 61 provided by the file system driver 87 as a predetermined file recording location matches the LBA of the specific area 307. In block 407, the access control driver 301 requests the disk driver 91 to record the LBA 007 in the specific area 307 without changing the LBA 007 received from the file system driver 87. At this time, the access control driver 301 does not issue a system call for making a transition to the virtualization driver 17.

  Since the LBA of the specific area 307 in which the file is recorded and the LBA of the virtual HDD 61 match, the access control driver 301 needs to search for an empty LBA in the specific area 307 by referring to the AMP 93 as in the file transfer method. There is no. Receiving the request, the disk driver 91 requests the HDD 25 to write a file to the LBA 007 in the specific area 307. While the virtual machine 11 is operating, the HPA manager 102 sets only the virtualization area 309 to HPA, so that the disk driver 91 can write a file in the specific area 307.

  In block 407, the access control driver 301 receives a write completion notification from the disk driver 61, and registers LBA007 in the AMP 303 in block 411. Further, since no file is recorded in the virtual area 61 corresponding to the LBA007 in the virtual HDD 61, the access control driver 301 does not set the update flag of the LBA007 or resets it if it is set.

  In block 413, the access control driver 301 determines whether or not the virtualization area 309 needs to be updated. Since the specific area 307 is set with a storage capacity capable of storing all the data of the virtualization area 309 assigned to the virtual machine 11, the virtual area 11 is not limited as long as the virtual machine 11 occupies the specific area 307. There is no need to update. However, since the specific area 307 may also use other virtual machines 13 and 15, the access control driver 301 receives a shutdown notification or a notification of stopping the virtual machine 11 from the guest OS 67 module. It is determined that the update is necessary.

  If an update is necessary, the process proceeds to block 415, and the access control driver 301 obtains the LBA whose update flag is reset from the AMP 303 and requests to update the virtualization area 309 with the data in the specific area 307. To the access manager 305. The access manager 305 updates the virtualization area 309 in the same procedure as the block 219 in FIG.

  In block 417, the access manager 305 that has received the update completion notification from the disk driver 105 notifies the access control driver 89 of the updated LBA. The access control driver 89 that has received the notification sets the update flag of the LBA corresponding to the data that has been updated. The read access processing procedure in block 409 can be performed in accordance with the read access processing procedure in the file transfer method shown in FIG.

[Other features]
So far, the specific areas 51 and 307 have been described on the assumption that only one of the virtual machines is occupied. In this case, when the virtual machines 11, 13, and 15 operate on the virtualization program 17 in a time-sharing manner, only one of the virtual machines that occupy the specific areas 51 and 307 can access the HDD 25 at high speed. it can. In the present invention, the specific areas 51 and 307 are divided into a plurality of logical blocks, and each is assigned to each virtual machine, so that a plurality of virtual machines operating in time division can use the specific area 51. Further, by assigning the divided specific areas 51 and 307 to the virtual machines 11, 13, and 15, it is not necessary to initialize the specific areas 51 and 307, and the data hit rate for read access can be increased. .

  In the present invention, even when the HDD 25 stores a virtualization program and a program constituting a plurality of virtual machines, the data in the virtualization areas 53 and 309 can be secured by setting the HPA. Such a feature is not limited to the case where data is stored in the virtualization areas 53 and 309 provided in one HDD. For example, a system called RAID (Redundant Arrays of Independent Disks) is employed for file servers, work stations, and the like.

  In RAID, a plurality of HDDs are virtualized to construct one logical disk, and the virtualization program can recognize and access them as one HDD. As a method for realizing RAID, there are a hardware method and a software method. When adopting the method by hardware, the present invention can be applied by changing the virtualization program so as to send a command for setting the HPA to each HDD. Also, when adopting the software method, redundant recording may not be possible for a specific area, but high-speed access can be achieved by transferring data asynchronously from a specific area to a virtual area where redundant recording is performed. It is advantageous for applications in which priority is given.

  Although the present invention has been described with the specific embodiments shown in the drawings, the present invention is not limited to the embodiments shown in the drawings, and is known so far as long as the effects of the present invention are achieved. It goes without saying that any configuration can be adopted.

DESCRIPTION OF SYMBOLS 10 ... Computer 11, 13, 15 ... Virtual machine 17 ... Virtualization program 19 ... Hardware 51, 307 ... Specific area 53, 309 ... Virtualization area 61, 63, 65 ... Virtual HDD
67, 69, 71 ... Guest OS
93, 303 ... Address mapping table (AMP)
100, 300 ... disk access control system

Claims (19)

On a computer that has a disk drive and a virtualization environment formed by a virtualization program and a virtual machine,
When a specific area that can be accessed by the virtual machine and a virtual area that cannot be accessed by the virtual machine are transferred to the disk drive, and the operation of the computer transits between the virtual machine and the virtualization program. In addition, the virtual machine is set to be accessible only to the specific area while the virtual machine is operating, and the specific area and the virtualization area are set while the virtualization program is operating. Steps to allow access ,
Initiating an I / O request for the virtualized area;
Determining whether the I / O request is a write access for writing data to the virtualization area or a read access for reading data from the virtualization area;
A computer program for executing a process including a step of writing write data in the specific area when it is determined that the access is the write access. The computer program product of claim 1 , wherein the setting step includes the step of the virtualization program executing an ATA Set max address command. On a computer that has a disk drive and a virtualization environment formed by a virtualization program and a virtual machine,
A specific area that includes a plurality of logical blocks allocated exclusively to a plurality of virtual machines and that can be accessed by the virtual machine, and a virtual area that cannot be accessed by the virtual machine are set in the disk drive. Steps,
Initiating an I / O request for the virtualized area;
Determining whether the I / O request is a write access for writing data to the virtualization area or a read access for reading data from the virtualization area;
A computer program for executing a process including a step of writing write data in the specific area when it is determined that the access is the write access. On a computer that has a disk drive and a virtualization environment formed by a virtualization program and a virtual machine,
Setting a specific area that the virtual machine can access and a virtual area that the virtual machine cannot access to the disk drive;
Initiating an I / O request for the virtualized area;
Determining whether the I / O request is a write access for writing data to the virtualization area or a read access for reading data from the virtualization area;
Writing write data to the specific area when it is determined that the write access; and
A computer program that executes a process including: updating the virtual area with data recorded in the specific area asynchronously with the write access . The computer program according to claim 4 , wherein the virtualization program executes the updating step. On a computer that has a disk drive and a virtualization environment formed by a virtualization program and a virtual machine,
Setting a specific area that the virtual machine can access and a virtual area that the virtual machine cannot access to the disk drive;
Initiating an I / O request for the virtualized area;
Determining whether the I / O request is a write access for writing data to the virtualization area or a read access for reading data from the virtualization area;
Writing write data to the specific area when it is determined that the write access; and
Determining whether read data is recorded in the specific area when it is determined to be the read access;
A computer program that executes a process including a step of reading data from the specific area when the virtual machine is determined to be recorded in the specific area . The computer program according to claim 6 , further comprising: reading data from the virtualized area when the virtual machine determines that the data is not recorded in the specific area. 8. The computer program according to claim 6 , further comprising a step of recording data read from the virtual area in the specific area asynchronously with the read access. A computer capable of realizing a virtual environment in which a virtual machine operates on a virtualization layer,
A specific area that the virtual machine can access and a disk drive in which a virtual area that the virtual machine cannot access is set;
A disk controller which constitutes an interface to the disk drives,
A request unit for issuing an I / O request to the disk controller;
Determining whether the I / O request is a write access or a read access, and when determining that the I / O request is the write access, an access control unit that writes write data to the specific area;
The disk controller is controlled so that only the specific area can be accessed while the virtual machine is operating, and the access restriction on the disk controller is released while the virtualization program is operating. And a storage area control unit for controlling the computer. A computer capable of realizing a virtual environment in which a virtual machine operates on a virtualization layer,
A specific area that the virtual machine can access and a disk drive in which a virtual area that the virtual machine cannot access is set;
A disk controller which constitutes an interface to the disk drives,
A request unit for issuing an I / O request to the disk controller;
Determining whether the I / O request is a write access or a read access, and when determining that the I / O request is the write access, an access control unit that writes write data to the specific area;
A computer having an update processing unit that updates the virtualized area with data written in the specific area at a timing different from the timing of the write access . A computer capable of realizing a virtual environment in which a virtual machine operates on a virtualization layer,
A specific area that the virtual machine can access and a disk drive in which a virtual area that the virtual machine cannot access is set;
A disk controller which constitutes an interface to the disk drives,
A request unit for issuing an I / O request to the disk controller;
It is determined whether the I / O request is a write access or a read access. When it is determined that the I / O request is the write access, write data is written in the specific area, and when it is determined that the I / O request is the read access, A computer having an access control unit that determines whether or not data to be read exists in a specific area and reads data from the specific area when it is determined that data exists . The computer according to claim 11 , wherein the access control unit reads data from the virtualization area when it is determined that no data exists in the specific area. The computer according to claim 11 or 12 , wherein the access control unit writes data read from the virtualized area to the specific area at a timing different from the timing of the read access. A computer capable of realizing a virtual environment in which a virtual machine operates on a virtualization layer,
A specific area that includes a plurality of logical blocks dedicated to each of the plurality of virtual machines and that can be accessed by the virtual machine, and a disk drive in which a virtual area that the virtual machine cannot access is set ,
A disk controller which constitutes an interface to the disk drives,
A request unit for issuing an I / O request to the disk controller;
A computer comprising: an access control unit that determines whether the I / O request is a write access or a read access, and writes write data to the specific area when the I / O request is determined to be the write access. A method of accessing a disk drive in a computer in which a virtualized environment is realized, comprising:
While the guest OS operates the virtualization program in the computer, a specific area where the guest OS can access the disk drive and a virtualization area where the guest OS cannot access the disk drive Realizing a function of restricting access to a part of the storage area of the disk drive and setting the access restriction to be released while the virtualization program is operating ;
An application program causing the computer to realize a function of starting access to the virtualization area;
The guest OS causing the computer to realize a function of determining whether the access is a write access for writing data to the virtualization area or a read access for reading data from the virtualization area;
A method in which a virtualization program realizes a function of writing write data to the specific area in the computer when it is determined that the write access is made. The method according to claim 15 , wherein the step of realizing the writing function causes the writing to the specific area at the same address as the address of the virtual disk drive determined by the guest OS. A method of accessing a disk drive in a computer in which a virtualized environment is realized, comprising:
A step of realizing a function of setting a specific area in which the guest OS can access the disk drive and a virtual area in which the guest OS cannot access the disk drive by the virtualization program;
An application program causing the computer to realize a function of starting access to the virtualization area;
The guest OS causing the computer to realize a function of determining whether the access is a write access for writing data to the virtualization area or a read access for reading data from the virtualization area;
Realizing the function of the virtualization program writing the write data to the specific area in the computer when it is determined that the write access;
The guest OS causing the computer to realize a function of writing data written in the specific area to the virtual area at a timing different from the timing of the write access . A method of accessing a disk drive in a computer in which a virtualized environment is realized, comprising:
  A specific area in which a virtualization program includes a plurality of logical blocks dedicated to each of the plurality of virtual machines and the guest OS can access the disk drive, and the guest OS is stored in the disk drive. Realizing a function of setting a virtual area that cannot be accessed;
  An application program causing the computer to realize a function of starting access to the virtualization area;
  The guest OS causing the computer to realize a function of determining whether the access is a write access for writing data to the virtualization area or a read access for reading data from the virtualization area;
  Realizing a function of causing the computer to write write data to the specific area when the virtualization program determines that it is the write access;
Having a method. A method of accessing a disk drive in a computer in which a virtualized environment is realized, comprising:
  A step of realizing a function of setting a specific area in which the guest OS can access the disk drive and a virtual area in which the guest OS cannot access the disk drive by the virtualization program;
  An application program causing the computer to realize a function of starting access to the virtualization area;
  The guest OS causing the computer to realize a function of determining whether the access is a write access for writing data to the virtualization area or a read access for reading data from the virtualization area;
  Realizing the function of the virtualization program writing the write data to the specific area in the computer when it is determined that the write access;
  Realizing the function of determining whether the virtualized program is recorded in the specific area or not when the virtualization program determines that the read access is performed;
  The virtual program causing the computer to realize a function of reading data from the specific area when it is determined that the virtual program is recorded in the specific area;
Having a method.

Images