Patent Application
20090328038
This application is based upon and claims the benefit of priority from Japanese Patent Application No. 2008-169087, filed Jun. 27, 2008, the entire contents of which are incorporated herein by reference.
1. Field
One embodiment of the present invention relates to a computer system in which a virtual machine is migratable, and a device controlling method for the computer system.
2. Description of the Related Art
In recent years, much effort has been made to study virtual machine techniques. Migration is a virtual machine technique. The migration involves migrating a virtual machine running in a source host to a destination host, where the migrated virtual machine is then ran. The configuration of a device in the destination host is different from that in the source host. The source host may desire to utilize the device in the destination host.
Jpn. Pat. Appln. KOKAI Publication No. 2004-258840 discloses a technique of allowing a device driver of a guest OS in the virtual machine to communicate with a device driver present on a hypervisor in a particular server to utilize the device via a network.
However, the above-described technique needs to modify the device driver of the guest OS so that the device driver can communicate with the device driver on the hypervisor. However, the device driver used by the guest OS is provided by a vender and is difficult to modify.
A general architecture that implements the various feature of the invention will now be described with reference to the drawings. The drawings and the associated descriptions are provided to illustrate embodiments of the invention and not to limit the scope of the invention.
Various embodiments according to the invention will be described hereinafter with reference to the accompanying drawings. In general, according to one embodiment of the invention, a computer system configured such that a virtual machine including a guest operating system running on a source computer connected to a network migrates to a destination computer connected to the network, where the virtual machine then running on the destination computer wherein, the source computer comprises first hardware including a first processor, a first network interface, and a device, a first hypervisor configured to run on the first hardware, and to manage the virtual machine, and a first backend driver running in the first hypervisor and configured to directly control the device in association with communication performed via a first interface, the virtual machine comprises a frontend driver configured to run in the guest operating system, and to control the device, the destination computer comprises second hardware including a second processor, and a second network interface, a second hypervisor configured to run on the second hardware, and to manage the virtual machine, and a second backend driver configured to run in the second hypervisor and including a second interface which is the same as the first interface, wherein the frontend driver controls the device by performing communication, via the first interface, with the first backend driver, the communication relates to control of the device, when the virtual machine runs on the source computer, and the frontend driver controls the device by performing communication which being related to control of the device, via the second interface, with the second backend driver, and performing communication which being related to control of the device, the second backend driver and the first backend driver, when the virtual machine runs on the destination computer.
As shown in
A first backend driver 121 that is software controlling the first device 112 runs in the first hypervisor 120. The first backend driver 121 provides an abstracted interface for a frontend driver 311 of the guest OS 310. The first backend driver 121 can directly control devices.
The frontend driver 311, which controls the device, runs in the guest OS 310. The frontend driver 311 communicates with the first backend driver 121 to indirectly control the device via the first backend driver 121.
A communication interface between the frontend driver 311 and the first backend driver 121 is generally made up of a buffer (hereinafter referred to as a communication buffer) for data communication with an event notification buffer (hereinafter referred to as an event channel). The communication buffer, in spite of its name, may or may not actually communicate with an event notification interface because the frontend driver 311 and a destination backend driver communicate with each other on a local memory.
A second host 200 includes a second hardware 210 provided with CPU 211, a second device 212, and a second network interface card (NIC) 213. A second hypervisor 220 runs on the second hardware 210. As shown in
A second backend driver 221 that is software controlling the first device 112 runs in the second hypervisor 220. The second backend driver 221 provides the frontend driver 311 of the guest OS 310 with the same abstracted interface as that provided by the first backend driver 121.
If the virtual machine 300 migrates to the second host 200, the guest OS 310 is utilizing no device in the destined second host 200 but may desire to continuously utilize the first device 112 in the originating first host.
After the virtual machine 300 migrates to the second host 200, the management console 321 notifies the second backend driver 221 of a MAC address as a unique identifier inherent in a first network interface card. The second backend driver 221 detects a corresponding first host based on a MAC address. Then, the second backend driver 221 can communicate with the first backend driver 121 in the first host. Data exchanges for data outputs and inputs to and from the device are then performed through communication between the frontend driver 311 and the second backend driver 221 and communication between the second backend driver 221 and the first backend driver 121. The data exchanged between the frontend driver 311 and the second backend driver 221 is almost the same as that exchanged between the second backend driver 221 and the first backend driver 121. Thus, the format of the data transferred in the respective communications can be unified.
The backend drivers 121 and 221 need to add a tag indicating to which frontend driver 311 data being transmitted or received belongs, to the data. A common data communication technique may be used for the addition of the tags.
As shown in
The fourth backend driver 222 and the third backend driver 122 include the same interface. The fourth backend driver 222 directly controls the second device 212 in association with communication relating to control of the second device 212 performed between the fourth backend driver 222 and the third backend driver 122 or the second frontend driver.
As described above, if the virtual machine 300 migrates from the first host to the second host 200, then by continuing to use the same frontend driver 311 and connecting to the destination backend driver, the guest OS 310 can continuously utilize the device in the destination as is the case in which the configuration of the device remains unchanged.
When the frontend driver 311 uses a device in a remote host, the backend driver in the host in which the guest OS is operating communicates with a backend driver running in the remote host, in place of the frontend driver 311. Thus, the presence of the backend driver can be hidden from the implementation in the guest OS. Consequently, the level of abstraction of the equipment as viewed from the gust OS is increased to allow the equipment to be easily configured.
Furthermore, the hardware is actually operated by the backend driver, and the frontend driver need not be changed. Thus, even when the frontend driver, which cannot be easily changed, is used, the system can be easily made compatible with the latest hardware.
The various modules of the systems described herein can be implemented as software applications, hardware and/or software modules, or components on one or more computers, such as servers. While the various modules are illustrated separately, they may share some or all of the same underlying logic or code.
While certain embodiments of the inventions have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the inventions.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2008-169087 | Jun 2008 | JP | national |
