JP5690676B2 - Virtual machine layer management device - Google Patents

Description

  The present invention relates to a layer management technique for virtual machines.

  When operating a virtual machine on a physical machine, various software has a hierarchical structure, such as an OS (operation system) on the virtual machine, middleware on the OS, and job application on the middleware. It is common to be managed and operated. Hereinafter, in this specification, each of a physical machine, a virtual machine, and each software is expressed as a hierarchy or a layer.

  Currently, there is a service such as a cloud service that allows an administrator who manages a virtual machine to rent a job application that runs on the virtual machine to a user. In such a service form, a user uses a job application, but an administrator manages each layer of the job application, the OS, and the like.

  Here, in order to manage a virtual machine, it is necessary to specify access authority or management authority. With respect to such management authority, Patent Document 1 discloses that management authority for a virtual machine resource is set by determining information on the presence or absence of management authority for each virtual resource ID. Thereby, the user can manage the resources of the virtual machine.

  A technique for setting access authority to a folder having a hierarchical structure is disclosed in Patent Document 2. In this patent document 2, access is made for each folder in the folder access right management table in order to set the access right that is the same as or weaker than that of the upper folder of the folder having a hierarchical structure when a lower folder is created. It is disclosed that the authority is set.

JP 2005-208999 A JP 2004-62780 A

  As described above, the management of each level is currently performed by the administrator. However, in the future, in this form of service, the user's own desire to directly manage each level is expected to increase. . Specifically, for example, when the user wants to manage the job application layer used directly, or when he wants to manage from the job application layer to the middleware layer running below, or even below that If you want to manage up to the OS layer, it is expected that demand will vary depending on the range of hierarchies you want to manage.

  This point cannot be handled by the technique disclosed in Patent Document 1. Japanese Patent Application Laid-Open No. 2004-133620 discloses that a user is given authority to manage virtual machine resources. This resource refers to one category such as a CPU and a memory, and does not have a hierarchical structure. As described above, there is a method of management authority that does not consider the hierarchical structure on the virtual machine, but there is no disclosed mechanism for setting management authority in consideration of the hierarchical structure in the virtual machine, and what is realized Is not yet.

  Further, when the management authority (access authority) of each layer in the virtual system is managed using the technique disclosed in Patent Document 2, the following problems occur.

  In Patent Document 2, when the setting of the upper folder is changed, the lower folder is determined based on the folder hierarchy information, and the access authority is set for each folder. However, in this case, since information for specifying the access authority is set for each folder one by one, it takes time to change the access authority for each layer below the folder. Therefore, even if this is applied to a virtual machine, when it is desired to change the range of the management authority of the user, there is a problem that it takes time and effort to rewrite the management authority information for each hierarchy.

  The service management table that stores the management range that is the index information of the range of the hierarchy that is managed for each piece of information that identifies the user such as the user ID, the management range, and the information about the presence or absence of the management authority for each layer The management range management table to be managed is stored, and the hierarchy in which each user has the management authority is specified by comparing the information in these two tables.

  When managing the management authority of the hierarchy for each user, the convenience is improved.

It is a figure which shows the service management table in one Embodiment of this invention. It is a figure which shows the virtual node management table in one Embodiment of this invention. It is a figure which shows the user management table in one Embodiment of this invention. It is a figure which shows the physical node management table in one Embodiment of this invention. It is a figure which shows the management range management table in one Embodiment of this invention. It is a figure which shows the user registration flow in one Embodiment of this invention. It is a figure which shows the system registration flow in one Embodiment of this invention. It is a reference flow figure of a system configuration by a user in one embodiment of the present invention. Operation lock flow (center side operation) of specific system in one embodiment of the present invention It is a flowchart which shows the operation lock release process (center side operation) of the specific system in one Embodiment of this invention. It is a flowchart which shows the specific system operation lock process (batch job opportunity) in one Embodiment of this invention. It is a flowchart which shows the operation lock release process (batch job opportunity) of the specific system in one Embodiment of this invention. It is a figure which shows the whole system structure in one Embodiment of this invention. It is a figure which shows the system name management table in one Embodiment of this invention. It is a figure which shows the hierarchy range management table in one Embodiment of this invention.

  An embodiment of the present invention will be described below with reference to the drawings.

  As shown in the overall view of the system in FIG. 13, a virtual machine layer management apparatus 004 (hereinafter referred to as this apparatus) has a physical machine group connected to the lowest layer, a virtual machine above it, an OS above it, On top of that, a middleware structure is formed, and a job application (an application layer that is actually used directly by the user, which is referred to as a job in FIG. 13) has a hierarchical structure. The virtual machine layer device 001 includes a user administrator terminal 001 that is a user's virtual machine system administrator terminal, a center administrator terminal 002 that is a virtual machine system administrator side, and an Internet terminal that is an end user terminal. 003 etc. are connected to each other.

  The case where the management authority of the virtual machine hierarchy is specified includes, for example, the following cases.

(1) When the user has a management authority at a level higher than that of the virtual machine In other words, a virtual machine is assigned to each user, and the user operates middleware and job applications on the virtual machine. Thereby, each user has an advantage that a system with a high degree of freedom can be constructed. On the other hand, there is a demerit that the service usage fee becomes high because the price includes the job, middle, and OS in the entire virtual machine.

(2) When the user has a management authority higher than the job application layer In other words, the same virtual machine and middleware are given to each user, and the user operates the job application layer. As a result, since the user shares the virtual machine, there is a merit that the service usage fee per job application is low (system integration). That is, for the user, the service provision cost varies depending on the hierarchy having the management authority, and therefore, the hierarchy for which the management authority is desired is designated in view of cost effectiveness.

  In addition, specific examples of management authority in each hierarchy are shown below. Having the virtual machine layer management authority means, for example, allowing changes to the virtual machine memory size, number of CPU cores, storage capacity, and the like. The physical machine layer includes logical network settings. A network path can be logically assembled inside a physical machine. For example, in a situation where a path is physically connected to A-B, A-C, and A to two points, “A-B path Can be logically set. Furthermore, for example, it is assumed that the firmware is set. For example, in the case of a server, there is a server firmware called BIOS, and when the BIOS setting is changed, a device that is read when the server is started (CD drive or other Can be changed). The authority up to the middleware layer can set OS and server software setting information (such as the number of requests received simultaneously from the end user of the system and the number of applications simultaneously executed). Thus, convenience is provided to the user by having management authority not only to the job application layer but also to a deeper layer.

  FIG. 1 is an example of a service management table 101 that identifies what service is applied to each user. In this service management table 101, a user code 1012 for identifying a user, a system ID 1013 for uniquely identifying a system used by the user, which is assigned to a system (such as an attendance input, a travel expense adjustment system) constructed on a virtual machine ( It is necessary to set a unique value on the virtual machine layer management apparatus.), A subsystem ID 1014 that uniquely identifies a subsystem used by the user, and a management range that is index information of a management range that can be managed by the user (Specific values may be a value that means a part or all of a layer (layer) such as “more than virtual machine”, “virtual machine”, “middleware”, “VM”, etc. You can just assign numbers and IDs.) Support level 1016 and virtual node ID 1017 to identify the virtual node Put in storage.

  Here, the support level 1016 indicates a level (time zone) at which management is performed on the center side (specifically, the center manager terminal side). Usually, in the case of a software product, an inquiry is made to the support window when a failure occurs. Specifically, when the support level 1016 is set to “9: 00-17: 00”, the management on the center side is not performed except during this time period. Therefore, even if a failure occurs outside of the above time, the problem must be solved only on the user side. In other words, if the support level 1016 is set to “24h365d” (24 hours 365 days), this means that the center side can be supported. If cloud computing is assumed, the usage charges can be ranked by dividing the level.

  Here, the difference between the system and the subsystem will be described. The system refers to the entire business system of user A, for example. (A means general work system, including time input, travel expense settlement, business diary, customer management system, etc. built by user A.) Subsystem is a system that includes user A's business system (time input , Travel expense settlement system, etc.). For example, the business system of user A is represented as system ID: A, and the attendance system of user A is represented as subsystem ID: A-1.

  By combining the management range 1015 and the support level 1016, a more detailed range managed by the user can be expressed. As an example, if the user management range is "more than virtual machines" and the support level is "automatic failover at the center", the user can make detailed settings for virtual machines, but the response in case of failure is No need to consider.

  FIG. 2 is an example of the virtual node management table 102 for managing virtual nodes. In this virtual node management table 102, a virtual node ID 1022 that identifies a virtual node, an operation lock flag 1023 that indicates the lock state of the virtual node operation, and an operable time zone 1024 that determines the operable time zone of the virtual node, The physical node ID 1025 that identifies the physical node on which the actual virtual node operates, the allocation CPU 1026 that is allocated to the virtual node, the allocation memory 1027 that is allocated, the allocation disk 1028 that is allocated, and the flag that indicates whether the virtual node is used are stored The virtual node used flag 1029 information to be stored is associated with each other and stored.

  FIG. 3 is an example of the user management table 103 that stores user information. In this user management table 103, for each user code 1031 which is a code for identifying a user, a user name 1033, an affiliation 1034 indicating the affiliation of the user, and a management system ID 1035 indicating the system managed by the user (the management system ID is , A registered system ID is entered, and one user can manage a plurality of systems.

  FIG. 4 is an example of a physical node management table 201 that stores physical node information. In this physical node management table 201, the physical node ID 2012 that identifies the physical node, and the CPU 2013, the memory 2014, the disk capacity 2015, and whether a virtual node has been created in the physical node for each physical node ID. The information indicating whether or not a virtual node is created 2016 is stored in association with each other. In this embodiment, the CPU is the number of cores, the memory is the capacity (GB), and the disk is the capacity (GB). However, the present invention is not limited to this.

  FIG. 5 is an example of a management range management table for specifying a management range for each user. In the management range management table, in correspondence with the management range 2022 for managing the range of layers that can be managed, that is, the virtual machine layer (VM), the OS layer (OS), the middleware layer (middle), the job layer (job), etc. Virtual machine (CPU) operation authority 2023 for specifying CPU management authority for the virtual machine, virtual machine (memory) operation authority 2024 for specifying memory management authority for the virtual machine, OS operation authority 2025 for specifying OS management authority, Management authority for each layer such as middle operation authority 2026 for specifying middleware management authority and job operation authority 2027 for specifying job application management authority is stored in association with each other.

  FIG. 14 is an example of a system name management table 104 that identifies a system name. In the system name management table 104, a system ID 1042 for specifying a system, a subsystem ID 1043 for specifying its subsystem, and each system name are stored in association with each other.

  FIG. 15 is an example of a hierarchy management range table for specifying a management range by hierarchy. In the hierarchy management range table 204, a management range 2042 for specifying a management range, and an operation authority range definition 2043 for storing a type of hierarchy with management authority are stored in association with each other for each management range 2042.

  The flow of processing will be described below in accordance with the flow of FIG. 6, FIG. 7, and FIG. 8, divided into FIG. 6 user registration, FIG.

<User registration>
First, user registration will be described with reference to the flowchart of FIG. First, the information of the user who uses this apparatus is registered into this apparatus. Specifically, when the process is started in step S301, the user administrator terminal first receives registration information input by the user. The registration information received from the user administrator terminal 001 is transmitted to the virtual machine layer management apparatus 004. The received information is registered in the user management table 103 of the virtual machine layer management apparatus 004 in step S302. Specifically, the user code 1032, the user name 1033, the affiliation 1034, and the management system ID 1035 are registered. This completes user registration. The user code may be automatically assigned an ID for identifying each user by the system. The management system ID 1035 refers to an ID of a system used by a user, and is information for specifying a system including a system ID and a subsystem ID.

<System registration>
Next, the system registration flow will be described with reference to FIG. System registration refers to registering information related to the system in order for the virtual machine layer management apparatus 004 to identify the system constructed on the virtual machine. Also included is a procedure for adding a new virtual machine for system registration. Prepare a virtual machine with the required specifications, install it on the virtual infrastructure, and build a system on the installed virtual machine. In this case, information necessary for preparing the virtual machine and information for identifying the constructed system are stored in the virtual machine layer management apparatus.

  First, system registration processing is started in step S401. In step S402, the center manager terminal 002 receives information on the number of virtual nodes and virtual node specifications that the user wants to use. Then, the information received from the center manager terminal 002 is transmitted to the virtual machine layer management apparatus 004. As a result, the virtual machine layer apparatus accepts the transmitted information. At this time, management range and support level information may also be received. Specifically, the virtual node specification CPU 4 core, the memory 2048 MB, the HDD 40 GB virtual node 4 nodes, the support level is the daytime service, the management range is information such as OS or more. The information to be received is not limited to this, and may be information having no support level, for example.

  In step S403, the virtual node management table 102 is referenced to determine whether the accepted virtual node exists. Specifically, it is determined whether there is a virtual node having the same specifications as the virtual node received from the information of each virtual node such as the allocation CPU 1026, the allocation memory 1027, and the allocation disk 1028 of each node managed by the virtual node management table 102. . If virtual nodes with the same specifications exist, then the virtual node used flag 1029 is checked to determine whether the virtual node has been used. If the virtual node is unused, the process proceeds to step S406 in order to permit the user to use the virtual node. If the virtual node has been used, the process proceeds to step S404 to create a new virtual node.

  The process of step S404 for determining whether or not a new virtual node can be created will be described in detail. This device identifies information on virtual node creation presence / absence 2016 in the physical node management table 201, selects a physical node for which a virtual node has not been created, identifies a physical node ID 2012, and assigns a virtual node to the identified physical node. Whether or not can be created. Whether or not a virtual node has been created means that when a new virtual node cannot be set on a 2016 physical node, information indicating existence is stored and other virtual nodes have already been created, but there is still room for additional specifications to be created. In some cases, information indicating nothing is stored. A virtual node does not use all the resources of a physical node. Specifically, if the physical node has 32 GB of memory, the virtual node may use only 4 GB of the virtual node. Therefore, when creating a virtual node, if there is a surplus resource in a certain physical node, the virtual node can be created in that physical node. A virtual node is created based on the information received from the user in the physical node specified by the physical node ID.

  Subsequently, in step S405, the apparatus adds the information received from the user to the virtual node management table 102 and stores it. In the specific example, a new virtual node ID 1022 is allocated, the physical ID identified in step 404 is the physical node ID 1025, the allocation CPU 1026 stores 4 cores, the allocation memory 1027 stores 2 GB, and the allocation disk stores 40 GB of information. In this case, the operation lock flag 1023 is released (because it is used), the operation possible time zone 1024 is given a value according to the contract according to the contract, and the virtual node used flag 1029 is used, so information indicating use, for example, Yes is remembered. The information “Yes” is not limited to this as long as it is information indicating use.

  Next, information received from the user in the columns 1012 to 1017 of the service management table 101 in step S406, specifically, system ID, subsystem ID, user code, management range, support level, and virtual node ID information Add

<User system configuration reference flow>
Next, a case where the user refers to the registered system will be described. Each user can refer to the system only within the authority registered in the system registration described above. A mechanism for realizing this will be described along the system configuration reference flow by the user in FIG.

  First, processing is started in step S501. In step S502, when the user logs in, the apparatus specifies the management system ID 1035 of the user management table 103 that matches the input user information such as the user code, the user name, and the affiliation, and displays a list of systems managed by the user. indicate.

  In this case, the apparatus outputs a system name 1044 corresponding to the system ID 1042 and the subsystem ID 1043 of the system name management table 104 based on the information of the management system ID 1035. Specifically, the column 1043 subsystem ID of the system name management table 104 is specified, and the system name that matches the value corresponding to the column 1035 management system ID of the user management table 103 is output.

  In step S503, the apparatus accepts a list of systems to be managed designated by the user from the system list output by the apparatus. Based on the management system ID 1035 of the specified system, this apparatus extracts the management range indicating the range that can be managed for each user in the service management table 101 and information on the management target virtual node. Specifically, as information to be extracted, column 1015 management range information and column 1017 virtual node ID of the service management table 101 are extracted.

In step S504, the apparatus identifies the column 1023 operation lock flag in the virtual node management table 102 based on the value of the column 1017 virtual node ID in the service management table 101. Based on the specified lock flag, it is determined whether the operation is locked or released. (Details of this locked state will be described later.)
If it is locked, the process returns to step S502 to display the system list screen again. If the lock is released, the process proceeds to step S505. The apparatus specifies the column 1024 operable time zone of the virtual node management table 102 based on the value of the column 1017 virtual node ID of the service management table 101. The specified value indicates the operable time zone of the virtual node used by the system specified by the user.

In step S506, the apparatus compares the identified operable time zone 1024 with the current time. As a result of the comparison, it is determined whether the current time corresponds to the operable time zone 1024. (For example, if the current time is 14:00 and the operable time zone is from 9:00 to 17:00, 14:00 corresponds to the operable time zone, so operation is possible.)
If the current time is outside the operable time zone, the process returns to step S502 and the system list screen is displayed again.

  If the current time is within the operable time zone, the process moves to step S507, and the apparatus searches the virtual node ID of the service management table 101 from the system ID specified by the user and displays a list of associated virtual nodes. Output. The user receives the selected virtual node ID as a state in which the user can select a management target to be referred to / changed from the list of virtual nodes output by the apparatus.

  In step S508, the apparatus specifies a range that can be managed by the user for the management target (virtual node) selected by the user. Specifically, first, the management range of the column 1015 of the service management table 101 is specified.

  Next, this apparatus searches for information in the management range 1015 in the service management table 101 and information in the management range 2022 in the management range management table 202, and identifies a record that matches the column 1015 management range. To do. The range that can be displayed to the user is specified from the operation authority of each column of the corresponding record. For example, when the management range 1015 of the service management table 101 is a VM, the VM (CPU) operation authority 2023 “Yes” and the VM (memory) operation authority 2024 corresponding to the VM in the management range 2022 of the management range management table 202 are displayed. The information of “Yes”, OS operation right 2025 “Yes”, middle operation right 2026 “Yes”, and job operation right 2027 “Yes” is specified. In this case, the items that can be referred to and operated by the user are those having a value of “Yes” in each column of the management range management table 202. Therefore, the apparatus displays an item corresponding to “Yes” to the user in each column of the management range management table 202. Subsequently, in step S509, the apparatus displays a range that can be operated by the user on the management target (virtual node) selected by the user.

  Here, it has been described that the management range is specified by the management range management table 202, but a method of specifying the management range by the hierarchical range management table 204 will also be described next.

  In the example of the management range management table 202, the management range management table is queried in step S508. In this case, the hierarchical range management table may be queried. Specifically, the management range 2042 of the hierarchical range management table 204 is specified, the operation authority range definition 2043 specified for each management range is read, and the user can operate based on the information stored in the operation authority range definition 2043 Specific scope.

Specifically, when the management range 1015 is a VM, the operation authority range is obtained from the VM, OS, middle, and job information of the operation authority range definition 2043 corresponding to the VM of the management range 2042 of the hierarchical range management table 204. The definition 2043 stores information of a hierarchy to which management authority is permitted, and specifies that the VM, OS, middle, and job have management authority “present”. Management authority is not given to a hierarchy that is not stored in the operation authority range definition 2043.
<Operation lock of specific system>
Next, in order to deal with cases where the system is affected by the user managing the system freely in daily operations, or when the user wants to temporarily freeze the system management by the center, A method for locking a specific system will be described. The following pattern can be considered as a locking method.
(1) Locking of system reference by time designation In a contract between a user and a cloud service providing vendor, a time zone during which the user manages the system is designated. Thereby, the user can manage the system during his / her business hours, and the ease of system management can be improved. In the system registration flow, the user designates the time zone for managing the system. When the virtual node is assigned, the management time zone for the virtual node is designated. In a specific example, information specifying a time such as 0800-1700 (08:00 to 17:00 in this case) is stored in the operable time zone 1024 of the virtual node management table 102.
(2) Locking / Release of System Reference by Center Side A case will be described in which an operation to the system is locked so that the user is not referred to or changed for maintenance of the center that manages the virtual infrastructure. Locking is performed as shown in the flow of FIG. When the user refers to the system after locking, the locked state is detected in the flow of FIG. 8 to prevent the user from referring to the system. The lock is released according to the flow of FIG.

  Here, the lock setting of the specific system (2) will be described in detail according to the flow of FIG. First, processing is started in step S601. In step S602, the center manager terminal 002 accepts input of information specifying the system to be locked that is selected from the center operator. Then, the center manager terminal 002 transmits the input information to this apparatus. The apparatus receives input information.

  In step S603, the apparatus identifies the column 1014 subsystem ID of the service management table 101, causes the center operator to select a system to be locked, and accepts the input. Further, the apparatus specifies the column 1017 virtual node ID for the virtual node associated with the system ID selected by the center operator.

  In step S604, the apparatus determines the current operation lock flag for the virtual node to be locked with the received system ID. Specifically, in each selected virtual node, the column 1023 operation lock flag of the virtual node management table 102 is specified, and it is determined whether it is in a locked state. If the operation lock flag is “lock”, the process returns to the system list in step S601.

In step S605, the apparatus changes the column 1023 operation lock flag of the virtual node management table 102 to “lock” indicating lock information.
<Release operation lock of specific system>
Next, unlocking will be described in detail along the flow of FIG.

  Processing starts in step S701. In step S702, the apparatus causes the center operator to select a system to be unlocked, and receives an input of the ID of the system from the center manager terminal 002.

  In step S703, the apparatus identifies the column 1014 subsystem ID of the service management table 101 based on the received system ID, and identifies the system that the center operator wants to unlock. Furthermore, this apparatus specifies the column 1017 virtual node ID for the virtual node associated with the system selected by the center operator.

  In step S704, the apparatus specifies the current operation lock flag 1023 that is to be locked, that is, corresponds to the specified virtual node. If the specified operation lock flag 1023 is not “lock”, the process returns to step S702. If the specified operation lock flag 1023 is “lock”, the process proceeds to step S705.

In step S705, the apparatus changes the column 1023 operation lock flag 1023 of the virtual node management table 102 to “release”. The information stored in the operation lock flag 1023 is not limited to “release”, and may be any information as long as it indicates that the operation is not locked.
<Operation lock of a specific system (batch job trigger)>
Next, system reference locking / releasing by a batch job trigger will be described. Locking the system reference due to a batch job trigger means that the system will be affected if the system is changed during the process, such as before the batch process is executed. The system locks operations such as system configuration changes.

  As an example of means for locking the operation, when performing a batch job for a long time, a job for locking the operation is prepared before the batch job. The reference to the system is locked by the job that locks the operation, and then batch processing is performed. By preparing a job for releasing the operation lock as a job after the processing is completed, the lock is released after the processing.

  By providing a mechanism for locking / releasing system operations by such jobs, the system is prevented from being changed during batch processing.

  First, the process of locking the operation of the specific system will be described along the flow of FIG. The following processing is performed by this apparatus. In step S801, processing is started. In step S802, the batch job selects and locks a system to be locked. Specifically, information (subsystem ID) for specifying the lock target system is given from the batch job, the lock target virtual node ID 1022 of the virtual node management table 102 is specified based on the information, and the operation lock flag 1023 is set. Change to information representing a lock. That is, in step S803, the apparatus accesses the service management table 101 and identifies the virtual node ID of the operation lock target system.

In step S804, if the operation lock flag 1023 is in the released state from the virtual node ID specified in the virtual node management table 102, the apparatus sets the operation lock flag 1023 of the virtual node in the virtual node management table 102 in step S805. Change to represent lock.
<Release operation lock of specific system (batch job trigger)>
Next, the process of releasing the lock will be described according to the flow of FIG. First, processing is started in step S901. The following processing is executed by this apparatus. In step S902, a lock target system is selected and unlocked according to a command included in the batch job. Specifically, information (subsystem ID) for specifying the lock target system is given from the batch job, the lock target virtual node ID 1022 of the virtual node management table 102 is specified based on the information, and the operation lock flag 1023 is specified. Is changed to information indicating release. That is, in step S903, the device accesses the service management table 101 and identifies the virtual node ID 1022 of the target system for which the operation lock is to be released.

  If the “operation lock flag” (1023) of the virtual node identified in the virtual node management table 102 is in the locked state in step S904, the device checks the operation lock flag of the virtual node in the virtual node management table 102 in step S905. Change 1023 to information indicating release.

101 Service Management Table 102 Virtual Node Management Table 103 User Management Table 104 System Name Management Table 201 Physical Node Management Table 202 Management Range Management Table 204 Hierarchy Range Management Table

Claims (2)

When a virtual machine operates on a physical machine and a single or a plurality of software operates on the virtual machine in a hierarchy, the physical machine, the virtual machine, and the software are used as a hierarchy, A virtual machine layer management device that identifies management authority,
A service management storage unit that stores a management range that is index information that represents a range of the hierarchy in association with information for identifying a user;
A management authority management storage unit that associates and stores the management range and information for specifying the management authority for each hierarchy indicated by the management range;
Means for receiving information identifying the user;
Means for identifying a management range corresponding to information for identifying the user from the service management storage unit;
A virtual machine layer management device comprising: means for identifying from the management authority management storage unit whether or not each layer has management authority corresponding to the specified management range. The virtual machine layer management apparatus according to claim 1,
The said management authority management memory | storage part is a virtual machine layer management apparatus which memorize | stores the information which shows the presence or absence of the management authority about each of the said several hierarchy in each management range.

Images