CN104598297B - virtual machine management method and device - Google Patents
virtual machine management method and device Download PDFInfo
- Publication number
- CN104598297B CN104598297B CN201510050036.5A CN201510050036A CN104598297B CN 104598297 B CN104598297 B CN 104598297B CN 201510050036 A CN201510050036 A CN 201510050036A CN 104598297 B CN104598297 B CN 104598297B
- Authority
- CN
- China
- Prior art keywords
- guest
- module
- hypervistor
- shutdown
- aaa
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Computer And Data Communications (AREA)
Abstract
The application proposes virtual machine management method and device.Method includes：The AAA accounting request messages for the first user for the 2nd Guest OS of access that the AAA client module that AAA server module on first guest operating system Guest OS receives on the 2nd Guest OS is periodically sent；AAA server module on first Guest OS carries out charging to the first user, charging finishes, judge the first user whether arrearage, if arrearage, then judge whether that also other users access the AAA client module on the 2nd Guest OS, if the webmaster module on the 3rd Guest OS no, is notified to close the 2nd Guest OS.The application is effectively utilized the host resource on Hypervistor.
Description
Technical field
This application involves technical field of virtualization, more particularly to virtual machine management method and device.
Background technology
The rapid development of computer industry so that the computing hardware resource such as storage, memory it is integrated stronger and stronger.Unit
The computing capability that size devices provide is more and more stronger.And in practical applications, some service applications are actually in the most of the time
Computing capability that need not be so powerful is supported.Therefore, to efficiently use hardware device performance, hardware resource wave is prevented
Take, many small virtual machine systems are run in a powerful service and are come into vogue in recent years.Here it is virtualization technology.
Parallel Clustering by virtualization technology and therewith, can be by any server resource pond, should for upper strata
With the flexible scheduling of resource of offer.Meanwhile the appearance of virtual machine objectively also requires IT management frameworks to innovate, to tackle virtual machine
This new IT management object.So as to various Hypervistor (Virtual Machine Manager application platform) occur.In the market
Compare the series of the ESX including VMware, the Hyper-V of open source projects Xen, KVM and Microsoft of mainstream.Due to these projects mostly
Increase income or partly increase income, so each application vendor can be packaged into one's own void by the secondary development to these projects
Plan machine management platform system.
The content of the invention
The application provides virtual machine management method and device.
What the technical solution of the application was realized in：
A kind of virtual machine management method, this method include：
AAA server module on first Guest OS receives the AAA client module periodicity on the 2nd Guest OS
The AAA accounting request messages of the first user for the 2nd Guest OS of access sent；
AAA server module on first Guest OS carries out charging to the first user, and charging finishes, and judges the first user
Whether arrearage, if arrearage, judge whether the AAA client module that also other users are accessed on the 2nd Guest OS, if not having
Have, then notify the webmaster module on the 3rd Guest OS to close the 2nd Guest OS.
A kind of virtual machine management method, this method include：
Webmaster module on 3rd Guest OS receives the shutdown that the AAA server module on the first Guest OS is sent and disappears
Breath, the message carry the address of the 2nd Guest OS with AAA client module；
Webmaster module on 3rd Guest OS passes through the shutdown on the Hypervistor where calling the 2nd Guest OS
Control module closes the 2nd Guest OS.
A kind of virtual machine management device, on the first Guest OS with AAA server module, which includes：
Accounting module：Receive that AAA client module on the 2nd Guest OS periodically sends for access second
The AAA accounting request messages of the first user of Guest OS, charging is carried out to the first user；
Shut down judgment module：When accounting module finishes first user's charging, judge the first user whether arrearage, if owe
Take, then judge whether that also other users access the AAA client module on the 2nd Guest OS, if not having, notify the 3rd
Webmaster module on Guest OS closes the 2nd Guest OS.
A kind of virtual machine management device, on the 3rd Guest OS with webmaster module, which includes：
Shutdown message receiving module：Receive what the authentication and authorization charging AAA server module on the first Guest OS was sent
Shutdown message, the message carry the address of the 2nd Guest OS with AAA client module；
Shutdown module：By calling the shutdown control module on the Hypervistor where the 2nd Guest OS to close the
Two Guest OS.
As it can be seen that in the application, when no user's access on a Guest OS, can be passed through by the Guest OS as webmaster
The shutdown control module on Hypervistor is called to close the Guest OS, so as to be effectively utilized on Hypervistor
Host resource.
Brief description of the drawings
Fig. 1 is the virtual machine management method flow chart that one embodiment of the application provides；
Fig. 2 is the virtual machine management method flow chart that another embodiment of the application provides；
Fig. 3 is the virtual machine management method flow chart that the another embodiment of the application provides；
Fig. 4 is the networking exemplary plot one that the application provides；
Fig. 5 is the virtual machine management method flow chart that the another embodiment of the application provides；
Fig. 6 is the networking exemplary plot two that the application provides；
Fig. 7 is the composition schematic diagram for the virtual machine management device that one embodiment of the application provides；
Fig. 8 is the composition schematic diagram for the virtual machine management device that another embodiment of the application provides.
Embodiment
For convenience of understanding, provide first as described below：
Guest OS：Guest operating system, the i.e. VME operating system applied to host operating system.
Applicant carries out analysis to existing virtual machine management platform system and finds：
Hypervistor layers of design original intention is to provide management of process, memory management, I/ to the Guest OS on upper strata
O management, system call etc. function, prevent from clashing between Guest OS and driving, Guest OS and Guest OS cause be
System collapse.Therefore, Hypervistor pays more attention to resource transfer basic function, and is not relevant for Guest OS management works
Itself.But Hypervistor remains able to provide the control interface for Guest OS, to facilitate upper application software pair
Guest OS are managed operation.
In order to ensure the stabilization of Hypervistor, current mainstay thinking is to try to design ground by Hypervistor
As small as possible, as far as possible simply, this also determines that Virtual Machine Manager can not possibly finally be realized in itself by Hypervistor, therefore
Need the function being transferred in the Guest OS on some upper strata.
Fig. 1 is the virtual machine management method flow chart that one embodiment of the application provides, it is comprised the following steps that：
Step 101：AAA (Authentication, Authorization and on first Guest OS
Accounting, authentication and authorization charging) server module receive the 2nd Guest OS on AAA client module periodically send
For access the 2nd Guest OS the first user AAA accounting request messages.
AAA accounting requests message carries the first user identifier of the 2nd Guest OS of access.
Step 102：AAA server module on first Guest OS carries out charging to the first user, and charging finishes, and judges
First user whether arrearage, if arrearage, judge whether the AAA client mould that also other users are accessed on the 2nd Guest OS
Block, if not having, notifies the webmaster module on the 3rd Guest OS to close the 2nd Guest OS.
Wherein, the Virtual Machine Manager application platform where the first Guest OS, the 2nd Guest OS and the 3rd Guest OS
Hypervistor is identical, or not exactly the same.
Preferably, when the Hypervistor where the first Guest OS, the 2nd Guest OS and the 3rd Guest OS is identical
When, in step 102, further comprise when the AAA server module on the first Guest OS judges the first subscriber arrearage：First
Guest OS send charging response message to the 2nd Guest OS, which carries the instruction of the first user offline, and reason is arrearage,
So that：2nd Guest OS disconnect the connection with the first user；And
When the AAA server module on the first Guest OS judges that no other users are accessed on the 2nd Guest OS
During AAA client module, the first Guest OS notify the webmaster module on the 3rd Guest OS to close the 2nd Guest OS and include：
First Guest OS send shutdown message to the webmaster module on the 3rd Guest OS, which carries the ground of the 2nd Guest OS
Location, so that：3rd Guest OS call the shutdown control module on the Hypervistor to close the 2nd Guest OS.
Preferably, when the Hypervistor where the first Guest OS, the 2nd Guest OS and the 3rd Guest OS is endless
When exactly the same, the Hypervistor where the first Guest OS, the 2nd Guest OS and the 3rd Guest OS forms one
Hypervistor clusters, and the Hypervistor where the 3rd Guest OS is Hypervistor managers；And
In step 102, further wrapped when the AAA server module on the first Guest OS judges the first subscriber arrearage
Include：AAA server module on first Guest OS sends charging response report to the AAA client module on the 2nd Guest OS
Text, the message carry the instruction of the first user offline, and reason is arrearage, so that：2nd Guest OS are disconnected with the first user's
Connection；And
When the AAA server module on the first Guest OS judges that no other users are accessed on the 2nd Guest OS
During AAA client module, the first Guest OS notify the webmaster module on the 3rd Guest OS to close the 2nd Guest OS and include：
First Guest OS send shutdown message to the webmaster module on the 3rd Guest OS, which carries the ground of the 2nd Guest OS
Location, so that：3rd Guest OS are called by the Hypervistor managers where itself where the 2nd Guest OS
Shutdown control module on Hypervistor closes the 2nd Guest OS, wherein, saved on the 3rd Guest OS and operate in institute
State the Hypervistor information where all Guest OS with AAA client module on Hypervistor clusters.
Preferably, it is when the first Guest OS and the 3rd Guest OS are same Guest OS, i.e., same on the first Guest OS
When there is AAA server module and webmaster module, in step 102, the first Guest OS notify the net on the 3rd Guest OS
Pipe, which closes the 2nd Guest OS, to be included：2nd Guest OS are closed by the webmaster module of the first Guest OS oneself.
Fig. 2 is the virtual machine management method flow chart that another embodiment of the application provides, it is comprised the following steps that：
Step 201：The AAA server module that webmaster module on 3rd Guest OS is received on the first Guest OS is sent
Shutdown message, the message carry with AAA client module the 2nd Guest OS address.
Step 202：Webmaster module on 3rd Guest OS passes through the Hypervistor where calling the 2nd Guest OS
On shutdown control module close the 2nd Guest OS.
Preferably, in step 201, the webmaster module on the 3rd Guest OS receives first with AAA server module
Controlled after the shutdown message that Guest OS are sent, by the shutdown on the Hypervistor where the 2nd Guest OS of calling
Module further comprises before closing the 2nd Guest OS：3rd Guest OS send shutdown notice to the 2nd Guest OS and disappear
Breath, so that：2nd Guest OS complete shutdown preparation.
Fig. 3 is the virtual machine management method flow chart that the another embodiment of the application provides, it is comprised the following steps that：
Step 300：For operating in each Guest OS under same Hypervistor, set on the first Guest OS
AAA server module, sets webmaster module, in other Guest in addition to the first, the 3rd Guest OS on the 3rd Guest OS
AAA client module is set on OS；Configuration has AAA server module on other Guest OS in addition to the first Guest OS
The first Guest OS address, on the first Guest OS configuration with webmaster module the 3rd Guest OS address, its
In, each AAA client module is in rental state, can be leased to paying customer's use.
As shown in figure 4, all operated on same Hypervistor in Guest OS1~4, wherein, set on Guest OS1
AAA server module has been put, webmaster module is provided with Guest OS3, AAA visitors are provided with Guest OS2, Guest OS4
Family end module.
Step 301：AAA server module on first Guest OS receives the AAA client module on each Guest OS
The AAA accounting request messages of the user for the corresponding Guest OS of access periodically sent.
AAA accounting requests message carries the user name of the user of the corresponding Guest OS of access.
For the AAA client module on any Guest OS, which, which can be directed to, accesses each use of itself
Family periodically sends AAA accounting request messages to the AAA server module on the first Guest OS, to ask to relative users
Carry out periodically fee calculating.
Step 302：For any Guest OS (such as：2nd Guest OS) on any for sending of AAA client module
AAA accounting request messages, the user that the AAA server module on the first Guest OS is directed to the message carry out charging.
Specifically, the AAA accounting request messages that the AAA client module on Guest OS is sent, first reach
Hypervistor, Hypervistor forward the packet to IP network again, and IP network is according to the destination address of message to the report
Text carries out three layers of forward process, which is forwarded back to Hypervistor, and Hypervistor, will according to the destination address of message
Message is transmitted to the first Guest OS.
Step 303：Charging finishes, the AAA server module on the first Guest OS judge the user whether arrearage, if
It is to perform step 305；Otherwise, step 304 is performed.
Step 304：AAA server module on first Guest OS is to sending the second of the AAA accounting request messages
AAA client module on Guest OS returns to AAA charging response messages, and charging indication, this flow terminate for message carrying.
Step 305：AAA server module on first Guest OS judges whether that also other user's accesses send this
AAA client module on 2nd Guest OS of AAA accounting request messages, if so, performing step 306；Otherwise, step is performed
307。
Step 306：AAA server module on first Guest OS is to the AAA client module on the 2nd Guest OS
AAA charging response messages are sent, which indicates that the user is offline, and reason is arrearage；AAA client on 2nd Guest OS
Module receives the AAA charging response messages, prompts its arrearage to the user, disconnects the connection with the user, this flow terminates.
Step 307：AAA server module on first Guest OS is to the AAA client module on the 2nd Guest OS
AAA charging response messages are sent, which indicates that the user is offline, and reason is arrearage, the AAA client on the 2nd Guest OS
Module receives the AAA charging response messages, prompts its arrearage to the user, disconnects the connection with the user；Meanwhile first
Guest OS send shutdown message to the 3rd Guest OS, which carries the address of the 2nd Guest OS, the 3rd Guest OS
On webmaster module receive the shutdown message, call the shutdown control module on Hypervistor to close the 2nd Guest OS.
Shutdown control module is configured with Hypervistor, the module be used for close run on this Hypervistor it is each
Guest OS, only the webmaster module on the 3rd Guest OS possess the authority for calling the shutdown control module.
Since as long as Guset OS are in operating status, it will take host OS (i.e. Hypervistor) memory,
The host resources such as CPU, therefore, when the AAA server module on the first Guest OS finds the AAA client on any Guest OS
When end module is accessed without any user, the webmaster module on the 3rd Guest OS is notified to close the Guest OS, with
Discharge the host resource of Guest OS occupancy.
It should be noted that in practical applications, AAA server module and webmaster module can be arranged on a Guest at the same time
On OS.
Fig. 5 is the virtual machine management method flow chart that the another embodiment of the application provides, it is comprised the following steps that：
Step 500：More hypervistor form a cluster by Clustering, select wherein one
Hypervistor is as hypervistor managers；Set on the first Guset OS on the first hypervistor is operated in
Put AAA server module, on the 3rd Guest OS on hypervistor managers are operated in set webmaster module, except
AAA client module is set on other Guest OS of first and second Guest OS；In the Guest OS in addition to the first Guest OS
The address of upper first Guest OS of the configuration with AAA server module, being configured on the first Guest OS has webmaster module
The 3rd Guest OS address；Configured on the 3rd Guest OS with webmaster module the mark of each Hypervistor with
And the incidence relation between the address of each Guest OS run on the Hypervistor, wherein, at each AAA client module
In the state of rental, paying customer's use can be leased to.
It should be noted that in practical applications, AAA server module and webmaster module can be arranged on a Guest at the same time
On OS, at this time, which operates on Hypervistor managers.
Step 501：AAA server module on first Guest OS receives the AAA client module on each Guest OS
The AAA accounting request messages of the user for the corresponding Guest OS of access periodically sent.
AAA accounting requests message carries the user name of the user of the corresponding Guest OS of access.
Step 502：For any Guest OS (such as：2nd Guest OS) on any for sending of AAA client module
AAA accounting request messages, the user that the AAA server module on the first Guest OS is directed to the message carry out charging.
Specifically, the AAA accounting request messages that the AAA client module on Guest OS is sent, first reach the Guest
Hypervistor where OS, the Hypervistor forward the packet to IP network again, and IP network is according to the purpose of message
Address carries out three layers of forward process, the Hypervistor being forwarded to where the first Guest OS, the first Guest OS to the message
The Hypervistor at place forwards the message to the first Guest OS according to the destination address of message.
Step 503：Charging finishes, the AAA server module on the first Guest OS judge the user whether arrearage, if
It is to perform step 505；Otherwise, step 504 is performed.
Step 504：AAA server module on first Guest OS is to sending the second of the AAA accounting request messages
AAA client module on Guest OS returns to AAA charging response messages, and charging indication, this flow terminate for message carrying.
Step 505：AAA server module on first Guest OS judges whether that also other user's accesses send this
AAA client module on 2nd Guest OS of AAA accounting request messages, if so, performing step 506；Otherwise, step is performed
507。
Step 506：AAA server module on first Guest OS is to the AAA client module on the 2nd Guest OS
AAA charging response messages are sent, which indicates that the user is offline, and reason is arrearage；AAA client on 2nd Guest OS
Module receives the AAA charging response messages, prompts its arrearage to the user, disconnects the connection with the user, this flow terminates.
Step 507：AAA server module on first Guest OS is to the AAA client module on the 2nd Guest OS
AAA charging response messages are sent, which indicates that the user is offline, and reason is arrearage, the AAA client on the 2nd Guest OS
Module receives the AAA charging response messages, prompts its arrearage to the user, disconnects the connection with the user；Meanwhile first
Guest OS send shutdown message to the webmaster module on the 3rd Guest OS, which carries the address of the 2nd Guest OS,
Webmaster module on 3rd Guest OS receives the shutdown message, the address of the 2nd Guest OS in the message, determines
Hypervistor where 2nd Guest OS, by where the 2nd Guest OS of Hypervistor managers calling
Shutdown control module on Hypervistor closes the 2nd Guest OS.
Shutdown control module is configured with each Hypervistor, which is used to close on this Hypervistor to transport
Capable each Guest OS, only the webmaster module on the 3rd Guest OS possess the shutdown control called on each Hypervistor
The authority of module.
If AAA server module and webmaster module are all disposed within the first Guest OS, in this step 507, first
Guest OS need not send shutdown message, directly according to the address for the 2nd Guest OS for sending AAA accounting request messages, determine
Hypervistor where 2nd Guest OS, then by where the 2nd Guest OS of Hypervistor managers calling
Shutdown control module on Hypervistor closes the 2nd Guest OS.
The application example of the application is given below：
As shown in fig. 6, hypervistor1, hypervistor2, hypervistor3 form a cluster, wherein,
Hypervistor3 is as manager.
Guest OS1, Guest OS2 are operated on Hypervistor1, and Guest OS3, Guest OS4 are operated in
On Hypervistor2, Guest OS5 are operated on Hypervistor3.
AAA server module is set on Guest OS1, webmaster module, Guest OS2, Guest are set on Guest OS5
AAA client module is set on OS3, Guest OS4.
Guest OS2, Guest OS3, Guest OS4, be configured with AAA server module on Guest OS5
The address of Guest OS1, the address of the Guest OS5 with webmaster module is configured with Guest OS1；Match somebody with somebody on Guest OS5
Put the mark and the incidence relation of the address of Guest OS2 of Hypervistor1, and the mark of Hypervistor2 with
Guest OS3, Guest OS4 address incidence relation.
User 1, user 2 access Guest OS2, and user 3, user 4 access Guest OS3, and user 5 accesses Guest OS4.
One) when initial, user's charging list that Guest OS1 are safeguarded is as shown in table 1：
| User name | Place Guest OS | Connection state | Remaining cost |
| User 1 | Guest OS 2 | Online | A members |
| User 2 | Guest OS 2 | Online | B members |
| User 3 | Guest OS 3 | Online | C members |
| User 4 | Guest OS 3 | Online | D members |
| User 5 | Guest OS 4 | Online | E members |
Table 1
Two) Guest OS2 are periodically sent out for user 1, the AAA accounting request messages of user 2；
Guest OS3 are periodically sent out for user 3, the AAA accounting request messages of user 4；
Guest OS4 are periodically sent out the AAA accounting request messages for user 5.
For received any AAA accounting requests message, Guest OS1 carry out charging to relative users, and update the institute of table 1
The remaining cost of the user in the user's charging list shown.
Three) a certain moment, Guest OS1 receive the AAA accounting request messages for user 1 that Guest OS2 are sent, meter
Expense finishes, and finds 1 arrearage of user, then returns to AAA charging response messages to Guest OS2, and the message instruction user 1 is offline, former
Because arrearage, while the remaining cost of user 1 in user's charging list is updated, and the connection state of user 1 is updated to offline；
Guest OS2 receive the AAA charging response messages, prompt arrearage to user 1, are then turned off the connection with user 1.
Four) another moment, Guest OS1 receive the AAA accounting request messages for user 2 that Guest OS2 are sent, meter
Expense finishes, and finds 2 arrearage of user, then returns to AAA charging response messages to Guest OS2, and the message instruction user 2 is offline, former
Because arrearage, while update the remaining cost of user 2 in user's charging list, and the connection state of user 2 is updated to it is offline,
Guest OS1 have found that all users on Guest OS2 are offline, then send shutdown message to Guest OS5, which takes
Address with Guest OS2；
At this time, user's charging list that Guest OS1 are safeguarded is as shown in table 2：
| User name | Place system | Connection state | Remaining cost |
| User 1 | Guest OS 2 | Offline | 0 yuan |
| User 2 | Guest OS 2 | Offline | 0 yuan |
| User 3 | Guest OS 3 | Online | C2 members |
| User 4 | Guest OS 3 | Online | D2 members |
| User 5 | Guest OS 4 | Online | E2 members |
Table 2
Guest OS2 receive the AAA charging response messages, prompt arrearage to user 2, are then turned off the connection with user 2；
Guest OS5 receive the shutdown message, and the address of the Guest OS2 in message, determines that Guest OS2 exist
On Hypervistor1, shutdown notification message is sent to Hypervistor1, Hypervistor1 receives the shutdown notification message,
Into shutdown ready state, all operation data are saved in local or sharing storage module, Guest OS5 wait certain time length
Afterwards or receive Hypervistor1 return shutdown push-notification-answer message after, called by Hypervistor3
Shutdown control module on Hypervistor1 closes Guest OS2.
In the embodiment of the present application, the message of interaction, message can use HTTP (Hyper-Text between Guest OS
Transfer Protocol, hypertext transfer protocol) mode encapsulates.
The advantageous effects of the embodiment of the present application are as follows：
When no user's access on a Guest OS, calling is passed through by the Guest OS with webmaster module
Shutdown control module on Hypervistor closes the Guest OS, so as to recycle the host of Guest OS occupancy in time
Resource, improves the utilization rate of the host resource on Hypervistor.
Fig. 7 is the composition schematic diagram for the virtual machine management device that one embodiment of the application provides, which, which is located at, has AAA
On first Guest OS of server module, which mainly includes：Accounting module and shutdown judgment module, wherein：
Accounting module：Receive that AAA client module on the 2nd Guest OS periodically sends for access second
The AAA accounting request messages of the first user of Guest OS, charging is carried out to the first user.
Shut down judgment module：When accounting module finishes first user's charging, judge the first user whether arrearage, if owe
Take, then judge whether that also other users access the 2nd Guest OS, if not having, notify the webmaster mould on the 3rd Guest OS
Block closes the 2nd Guest OS.
Wherein, the Virtual Machine Manager application platform where the first Guest OS, the 2nd Guest OS and the 3rd Guest OS
Hypervistor is identical, or not exactly the same.
Preferably, when the Hypervistor where the first Guest OS, the 2nd Guest OS and the 3rd Guest OS is identical
When, shutdown judgment module judges to be further used for during the first subscriber arrearage, and charging response message is sent to the 2nd Guest OS, should
Message carries the instruction of the first user offline, and reason is arrearage, so that：2nd Guest OS disconnect the connection with the first user；
And when shutdown judgment module notifies the webmaster module on the 3rd Guest OS to close the 2nd Guest OS and include：To
Webmaster module on three Guest OS sends shutdown message, which carries the address of the 2nd Guest OS, so that：3rd
Webmaster module on Guest OS calls the shutdown control module on the Hypervistor to close the 2nd Guest OS.
Preferably, when the Hypervistor where the first Guest OS, the 2nd Guest OS and the 3rd Guest OS is endless
When exactly the same, the Hypervistor where the first Guest OS, the 2nd Guest OS and the 3rd Guest OS forms one
Hypervistor clusters, and the Hypervistor where the 3rd Guest OS is Hypervistor managers；
Shutdown judgment module judges to be further used for during the first subscriber arrearage, and charging response report is sent to the 2nd Guest OS
Text, the message carry the instruction of the first user offline, and reason is arrearage, so that：2nd Guest OS are disconnected with the first user's
Connection；
And shutdown judgment module is notified on the 3rd Guest OS when judging that no other users access the 2nd Guest OS
Webmaster module, which closes the 2nd Guest OS, to be included：Shutdown message is sent to the webmaster module on the 3rd Guest OS, which takes
Address with the 2nd Guest OS, so that：Webmaster module on 3rd Guest OS passes through the Hypervistor where itself
The shutdown control module on Hypervistor where the 2nd Guest OS of manager's calling closes the 2nd Guest OS,
Wherein, saved on the 3rd Guest OS operate on the Hypervistor clusters as AAA client
Hypervistor information where all Guest OS.
Preferably, when there is AAA server module and webmaster module at the same time on the first Guest OS, i.e. the first Guest
When OS and the 3rd Guest OS is same Guest OS, shutdown judgment module notifies the webmaster module on the 3rd Guest OS to close
2nd Guest OS include：2nd Guest OS are closed by the webmaster module of the first Guset OS oneself.
Fig. 8 is the composition schematic diagram for the virtual machine management device that another embodiment of the application provides, which, which is located at, has
On 3rd Guest OS of webmaster module, which mainly includes：Shutdown message receiving module and shutdown module, wherein：
Shutdown message receiving module：The shutdown message that the AAA server module on the first Guest OS is sent is received, this disappears
Breath carries the address of the 2nd Guest OS with AAA client module, and the address of the 2nd Guest OS is sent to shutdown mould
Block.
Shutdown module：By calling the shutdown control module on the Hypervistor where the 2nd Guest OS to close the
Two Guest OS.
Preferably, module of shutting down passes through the shutdown control module on the Hypervistor where calling the 2nd Guest OS
It is further used for before closing the 2nd Guest OS, shutdown notification message is sent to the 2nd Guest OS, so that：Second
Guest OS complete shutdown preparation.
The foregoing is merely the preferred embodiment of the application, not limiting the application, all essences in the application
God and any modification, equivalent substitution, improvement and etc. within principle, done, should be included within the scope of the application protection.
Claims (12)
1. a kind of virtual machine management method, it is characterised in that this method includes：
Authentication and authorization charging AAA server module on first guest operating system Guest OS is received on the 2nd Guest OS
The AAA accounting request messages for the first user for the 2nd Guest OS of access that AAA client module is periodically sent；
AAA server module on first Guest OS carries out charging to the first user, and charging finishes, and whether judges the first user
Arrearage, if arrearage, judges whether that also other users access the AAA client module on the 2nd Guest OS, if not having,
The webmaster module on the 3rd Guest OS is notified to close the 2nd Guest OS.
2. according to the method described in claim 1, it is characterized in that, as the first Guest OS, the 2nd Guest OS and the 3rd
When Hypervistor where Guest OS is identical,
When the AAA server module on the first Guest OS judges the first subscriber arrearage, the method is further included：
AAA server module on first Guest OS sends charging response to the AAA client module on the 2nd Guest OS
Message, the message carry the instruction of the first user offline, and reason is arrearage, so that：2nd Guest OS are disconnected and the first user
Connection；
AAA server module on the first Guest OS notifies the webmaster module on the 3rd Guest OS to close second
Guest OS include：
AAA server module on first Guest OS sends shutdown message to the webmaster module on the 3rd Guest OS, this disappears
Breath carries the address of the 2nd Guest OS, so that：Webmaster module on 3rd Guest OS is called on the Hypervistor
Shutdown control module close the 2nd Guest OS.
3. according to the method described in claim 1, it is characterized in that, as the first Guest OS, the 2nd Guest OS and the 3rd
When Hypervistor where Guest OS is not exactly the same, the first Guest OS, the 2nd Guest OS and the 3rd Guest OS
The Hypervistor at place forms a Hypervistor cluster, and the Hypervistor where the 3rd Guest OS is
Hypervistor managers；
When the AAA server module on the first Guest OS judges the first subscriber arrearage, the method is further included：
AAA server module on first Guest OS sends charging response to the AAA client module on the 2nd Guest OS
Message, the message carry the instruction of the first user offline, and reason is arrearage, so that：2nd Guest OS are disconnected and the first user
Connection；
AAA server module on the first Guest OS notifies the webmaster module on the 3rd Guest OS to close second
Guest OS include：
AAA server module on first Guest OS sends shutdown message to the webmaster module on the 3rd Guest OS, this disappears
Breath carries the address of the 2nd Guest OS, so that：Webmaster module on 3rd Guest OS passes through where itself
The shutdown control module on Hypervistor where the 2nd Guest OS of Hypervistor managers calling closes second
Guest OS,
Wherein, the owning as AAA client operated on the Hypervistor clusters is saved on the 3rd Guest OS
Hypervistor information where Guest OS.
4. method according to any one of claims 1 to 3, it is characterised in that as the first Guest OS and the 3rd Guest OS
For same Guest OS when,
AAA server module on the first Guest OS notifies the webmaster module on the 3rd Guest OS to close second
Guest OS include：
The webmaster module of first Guest OS oneself closes the 2nd Guest OS.
5. a kind of virtual machine management method, it is characterised in that this method includes：
Webmaster module on 3rd guest operating system Guest OS receives the authentication and authorization charging AAA clothes on the first Guest OS
The shutdown message that business device module is sent, the message carry the address of the 2nd Guest OS with AAA client module；
Webmaster module on 3rd Guest OS is controlled by the shutdown on the Hypervistor where calling the 2nd Guest OS
Module closes the 2nd Guest OS.
6. according to the method described in claim 5, it is characterized in that, the webmaster module on the 3rd Guest OS receives first
After the shutdown message that AAA server module on Guest OS is sent, by where the 2nd Guest OS of calling
Shutdown control module on Hypervistor further comprises before closing the 2nd Guest OS：
Webmaster module on 3rd Guest OS sends shutdown notification message to the 2nd Guest OS, so that：2nd Guest
OS completes shutdown preparation.
A kind of 7. virtual machine management device, positioned at the first guest operating system with authentication and authorization charging AAA server module
On Guest OS, it is characterised in that the device includes：
Accounting module：Receive that AAA client module on the 2nd Guest OS periodically sends for the 2nd Guest of access
The AAA accounting request messages of the first user of OS, charging is carried out to the first user；
Shut down judgment module：When accounting module finishes first user's charging, judge the first user whether arrearage, if arrearage,
Then judge whether that also other users access the AAA client module on the 2nd Guest OS, if not having, notify the 3rd
Webmaster module on Guest OS closes the 2nd Guest OS.
8. device according to claim 7, it is characterised in that as the first Guest OS, the 2nd Guest OS and the 3rd
When Hypervistor where Guest OS is identical,
The shutdown judgment module judges to be further used for during the first subscriber arrearage, the AAA client on the 2nd Guest OS
Module sends charging response message, which carries the instruction of the first user offline, and reason is arrearage, so that：2nd Guest
OS disconnects the connection with the first user；
And the shutdown judgment module notifies the webmaster module on the 3rd Guest OS to close the 2nd Guest OS and include：To the 3rd
Webmaster module on Guest OS sends shutdown message, which carries the address of the 2nd Guest OS, so that：3rd
Webmaster module on Guest OS calls the shutdown control module on the Hypervistor to close the 2nd Guest OS.
9. device according to claim 7, it is characterised in that as the first Guest OS, the 2nd Guest OS and the 3rd
When Hypervistor where Guest OS is not exactly the same, the first Guest OS, the 2nd Guest OS and the 3rd Guest OS
The Hypervistor at place forms a Hypervistor cluster, and the Hypervistor where the 3rd Guest OS is
Hypervistor managers；
The shutdown judgment module judges to be further used for during the first subscriber arrearage, the AAA client on the 2nd Guest OS
Module sends charging response message, which carries the instruction of the first user offline, and reason is arrearage, so that：2nd Guest
OS disconnects the connection with the first user；
And the shutdown judgment module notifies the webmaster module on the 3rd Guest OS to close the 2nd Guest OS and include：To the 3rd
Webmaster module on Guest OS sends shutdown message, which carries the address of the 2nd Guest OS, so that：3rd
Webmaster module on Guest OS passes through where the 2nd Guest OS of Hypervistor managers calling where itself
Shutdown control module on Hypervistor closes the 2nd Guest OS,
Wherein, the owning as AAA client operated on the Hypervistor clusters is saved on the 3rd Guest OS
Hypervistor information where Guest OS.
10. according to any device of claim 7 to 9, it is characterised in that the first Guest OS have webmaster at the same time
Module,
The shutdown judgment module notifies the webmaster module on the 3rd Guest OS to close the 2nd Guest OS and include：By first
The webmaster module of Guest OS oneself closes the 2nd Guest OS.
11. a kind of virtual machine management device, on the 3rd guest operating system Guest OS with webmaster module, its feature
It is, which includes：
Shutdown message receiving module：Receive the shutdown that the authentication and authorization charging AAA server module on the first Guest OS is sent
Message, the message carry the address of the 2nd Guest OS with AAA client module；
Shutdown module：Second is closed by the shutdown control module on the Hypervistor where the 2nd Guest OS of calling
Guest OS。
12. according to the devices described in claim 11, it is characterised in that the shutdown module is by calling the 2nd Guest OS institutes
Hypervistor on shutdown control module close the 2nd Guest OS before be further used for, to the 2nd Guest OS
Shutdown notification message is sent, so that：2nd Guest OS complete shutdown preparation.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510050036.5A CN104598297B (en) | 2015-01-30 | 2015-01-30 | virtual machine management method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201510050036.5A CN104598297B (en) | 2015-01-30 | 2015-01-30 | virtual machine management method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN104598297A CN104598297A (en) | 2015-05-06 |
| CN104598297B true CN104598297B (en) | 2018-05-11 |
Family
ID=53124115
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201510050036.5A Active CN104598297B (en) | 2015-01-30 | 2015-01-30 | virtual machine management method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN104598297B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10193984B2 (en) * | 2015-12-01 | 2019-01-29 | Telefonaktiebolaget Lm Ericsson (Publ) | Architecture for enabling fine granular service chaining |
| CN114449025B (en) * | 2020-10-16 | 2024-03-08 | 上海汽车集团股份有限公司 | Communication method and system |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101916207A (en) * | 2010-08-28 | 2010-12-15 | 华为技术有限公司 | Energy saving method, device and system under desktop virtual environment |
| CN102214117A (en) * | 2010-04-07 | 2011-10-12 | 中兴通讯股份有限公司 | Virtual machine management method, system and server |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9336034B2 (en) * | 2011-06-28 | 2016-05-10 | Hewlett-Packard Development Company, L.P. | Display of host operating system user interface elements within a guest operating system of a virtual machine |
-
2015
- 2015-01-30 CN CN201510050036.5A patent/CN104598297B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102214117A (en) * | 2010-04-07 | 2011-10-12 | 中兴通讯股份有限公司 | Virtual machine management method, system and server |
| CN101916207A (en) * | 2010-08-28 | 2010-12-15 | 华为技术有限公司 | Energy saving method, device and system under desktop virtual environment |
Non-Patent Citations (1)
| Title |
|---|
| 基于多系统联动的安全接入认证计费系统的研究与实现;王兴梁;《中国优秀博硕士学位论文全文数据库（硕士） 信息科技辑》;20061115(第11期);第52-66页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN104598297A (en) | 2015-05-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2021017279A1 (en) | Cluster security management method and apparatus based on kubernetes and network domain, and storage medium | |
| CN102262557B (en) | Method for constructing virtual machine monitor by bus architecture and performance service framework | |
| CN104767649B (en) | Dispose the method and device of bare metal server | |
| JP5275407B2 (en) | Method for network interface shared by multiple virtual machines | |
| Tu et al. | Revisiting the open vswitch dataplane ten years later | |
| CN103747107B (en) | A kind of compatible cloud operating platform and its implementation | |
| CN108062248A (en) | Method for managing resource, system, equipment and the storage medium of isomery virtual platform | |
| CN108228316A (en) | A kind of method and apparatus of encryption device virtualization | |
| Nakao et al. | CoreLab: An emerging network testbed employing hosted virtual machine monitor | |
| CN110661842B (en) | Resource scheduling management method, electronic equipment and storage medium | |
| CN102707985A (en) | Access control method and system for virtual machine system | |
| JP2006107500A (en) | Updating software during its execution | |
| CN105306225B (en) | A kind of physical machine remote power-off method based on Openstack | |
| CN106685679A (en) | Network service deployment method and device | |
| CN103473117A (en) | Cloud-mode virtualization method | |
| CN104216741A (en) | Android plug-in implementation method and device based on APK (Android Package) dynamic loading and interaction method | |
| TWI734379B (en) | Computer implement method, computer system and computer program product starting a secure guest using an initial program load mechanism | |
| Wu et al. | Android unikernel: Gearing mobile code offloading towards edge computing | |
| CN101488173A (en) | Method for measuring completeness of credible virtual field start-up files supporting non-delaying machine | |
| JP2012243298A (en) | Server i/o migration management method and device | |
| CN108037978A (en) | A kind of managing computing resources method based on virtualization technology | |
| CN102289620A (en) | Credible equipment virtualization system and method based on Xen safety computer | |
| CN105303102A (en) | Secure access method for virtual machine and virtual machine system | |
| CN106293847A (en) | Method for supporting service of virtualization platform | |
| CN109347716A (en) | The instantiation method and device of consumer VNF |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information |
Address after: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Applicant after: Xinhua three Technology Co., Ltd. Address before: 310052 Binjiang District Changhe Road, Zhejiang, China, No. 466, No. Applicant before: Huasan Communication Technology Co., Ltd. |
|
| CB02 | Change of applicant information | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |