U.S. patent application number 13/175324 was filed with the patent office on 2012-02-02 for thin client system, management server, virtual machine creation management method and virtual machine creation management program.
Invention is credited to YUU SAKAMOTO.
Application Number | 20120030673 13/175324 |
Document ID | / |
Family ID | 44582296 |
Filed Date | 2012-02-02 |
United States Patent
Application |
20120030673 |
Kind Code |
A1 |
SAKAMOTO; YUU |
February 2, 2012 |
THIN CLIENT SYSTEM, MANAGEMENT SERVER, VIRTUAL MACHINE CREATION
MANAGEMENT METHOD AND VIRTUAL MACHINE CREATION MANAGEMENT
PROGRAM
Abstract
To prevent creation of a virtual machine in a hypervisor
unusable by a license for use in creating a virtual machine.
Provided are at least one tenant 400 including at least one tenant
terminal 410, a management data base 500 which stores resource
information of the tenant 400, at least one data center 300 on
which a virtual machine 331 to be used by the tenant 400 operates,
and a management server 200 including a virtual machine creation
management unit 204 which narrows down a hypervisor 330 in which
the virtual machine 331 can be created based on resource
information of the tenant 400 stored in the management data base
500 and a virtual machine creation request including predetermined
requirement information for creating the virtual machine 331 which
is received from the tenant terminal 410.
Inventors: |
SAKAMOTO; YUU; (Tokyo,
JP) |
Family ID: |
44582296 |
Appl. No.: |
13/175324 |
Filed: |
July 1, 2011 |
Current U.S.
Class: |
718/1 |
Current CPC
Class: |
G06F 9/452 20180201;
G06F 2009/45562 20130101; G06F 21/121 20130101; G06F 9/45558
20130101 |
Class at
Publication: |
718/1 |
International
Class: |
G06F 9/455 20060101
G06F009/455 |
Foreign Application Data
Date |
Code |
Application Number |
Jul 29, 2010 |
JP |
2010-170992 |
Claims
1. A thin client system, comprising: at least one tenant including
at least one tenant terminal; a management data base which stores
resource information of said tenant, at least one data center in
which a virtual machine to be used by said tenant operates; and a
management server including a virtual machine creation management
unit which narrows down a hypervisor in which said virtual machine
can be created based on resource information of said tenant stored
in said management data base and a virtual machine creation request
including predetermined requirement information for creating said
virtual machine which is received from said tenant terminal.
2. The thin client system according to claim 1, wherein said tenant
terminal comprises a virtual machine creation requesting unit which
makes said virtual machine creation request, and wherein said
virtual machine creation requesting unit includes, in said
requirement information of said virtual machine creation request, a
data center as a creation destination of said virtual machine, a
template for use in creating said virtual machine, a license for
use in creating said virtual machine and a domain of a tenant user
of said tenant, and said virtual machine creation management unit
of said management server extracts a data center which is a data
center included in said requirement information and usable by said
tenant from said management data base, extracts a connection broker
related to a manager related to said extracted data center and
usable by said tenant from said management data base, extracts said
hypervisor related to a manager related to said extracted
connection broker and usable by said tenant from said management
data base, and extracts said hypervisor included in said
requirement information and in which said virtual machine of said
tenant can be created from among said extracted hypervisors.
3. The thin client system according to claim 2, wherein said
virtual machine creation requesting unit of said tenant terminal
extracts said data center usable by said tenant from said
management data base, extracts a template for use in creating said
virtual machine based on said data center selected as a creation
destination of said virtual machine from among said extracted data
centers and said resource information of said tenant, extracts a
license for use in creating said virtual machine based on said
extracted template and said resource information of said tenant,
extracts a domain usable by said tenant based on said resource
information of said tenant, and includes said domain selected as a
domain to be used from among said extracted domains, said extracted
data center, said extracted template, and said extracted license in
said virtual machine creation request.
4. The thin client system according to claim 2, wherein a license
for use in creating said virtual machine includes multi-tenant
coexistence determination information indicating whether said
virtual machines of a plurality of said tenants are allowed to
coexist on the same hypervisor, and said virtual machine creation
management unit of said management server when said hypervisor is
referred to by other virtual machine, determines whether other said
virtual machine is a virtual machine to be used by said tenant,
when determination is made that said other virtual machine is a
virtual machine to be used by other tenant than said tenant,
verifies multi-tenant coexistence determination information of a
license for use in creating said virtual machine, and when said
multi-tenant coexistence determination information is "coexistence
not allowed", determines that said virtual machine cannot be
created in said hypervisor.
5. The thin client system according to claim 2, wherein information
of a license stored in said management data base includes an
effective number of licenses, and said virtual machine creation
requesting unit of said tenant terminal includes a license whose
number of references is less than said effective number of licenses
in said requirement information.
6. The thin client system according to claim 1, wherein said
management server comprises a data center control unit which
creates said virtual machine based on an instruction of said
virtual machine creation management unit, and wherein based on a
hypervisor narrowed down by said virtual machine creation
management unit and resource information of said tenant received
from said virtual machine creation management unit, said data
center control unit requests a manager related to said
narrowed-down hypervisor to create said virtual machine.
7. The thin client system according to claim 2, wherein information
of a license stored in said management data base includes a
hypervisor owner requirement, information of a hypervisor stored in
said management data base includes a hypervisor ownership, said
virtual machine creation requesting unit of said tenant terminal
includes, in said virtual machine creation request, said license
including said hypervisor owner requirement meeting said ownership
of a hypervisor usable by said tenant, and said virtual machine
creation management unit extracts said hypervisor satisfying said
hypervisor owner requirement of said requirement information.
8. A management server of a thin client system, comprising: a
virtual machine creation management unit which, based on resource
information of at least one tenant including at least one tenant
terminal stored in a management data base of said thin client
system and a virtual machine creation request including
predetermined requirement information for creating a virtual
machine to be used by said tenant on a data center of said thin
client system which is received from said tenant terminal, narrows
down a hypervisor in which said virtual machine can be created.
9. A virtual machine creation management method, comprising: at a
management server of a thin client system, a virtual machine
creation management step of, based on resource information of at
least one tenant including at least one tenant terminal stored in a
management data base of said thin client system and a virtual
machine creation request including predetermined requirement
information for creating a virtual machine to be used by said
tenant on a data center of said thin client system which is
received from said tenant terminal, narrowing down a hypervisor in
which said virtual machine can be created.
10. A computer readable medium storing a virtual machine creation
management program executed on a management server of a thin client
system, wherein said program causes said management server to
execute the functions of: a virtual machine creation management
processing of, based on resource information of at least one tenant
including at least one tenant terminal stored in a management data
base of said thin client system and a virtual machine creation
request including predetermined requirement information for
creating a virtual machine to be used by said tenant on a data
center of said thin client system which is received from said
tenant terminal, narrowing down a hypervisor in which said virtual
machine can be created.
Description
INCORPORATION BY REFERENCE
[0001] This application is based upon and claims the benefit of
priority from Japanese patent application No. 2010-170992, filed on
Jul. 29, 2010, the disclosure of which is incorporated herein in
its entirety by reference.
TECHNICAL FIELD
[0002] The present invention relates to a thin client system such
as a DaaS (Desktop as a Service) system in which a hypervisor is
shared by a plurality of tenants and, more particularly, a thin
client system, a management server, a virtual machine creation
management method and a virtual machine creation management program
which enable creation of a virtual machine to be prevented in a
hypervisor having no allowed license.
BACKGROUND ART
[0003] In recent years, a DaaS (Desktop as a Service) system in
which a hypervisor is shared by a plurality of tenants has been
attracting much attention among thin client systems. DaaS systems
have advantages such as mitigation of loads on a client side and
improvement of security because processing of a virtual desktop is
executed on a server side.
[0004] On the other hand, the system has a shortcoming that even
when a license for use in creating a virtual machine is not allowed
on a hypervisor on which a virtual machine of other tenant
operates, a virtual machine might be created by using the license
on the hypervisor on which the virtual machine of other tenant
operates.
[0005] Another problem is that even when a virtual machine is
created by using the above-described license on a hypervisor on
which no virtual machine of other tenant exists, a virtual machine
of other tenant might be created thereafter.
[0006] Under these circumstances, recited as related art in Patent
Literature 1, for example, is a technique having a mechanism of
approving a software license in a virtual machine environment. The
technique recited in Patent Literature 1 enables license check on a
virtual machine basis. [0007] Patent Literature 1: Japanese Patent
Laying-Open No. 2006-018815.
[0008] Although the technique recited in Patent Literature 1
enables license check on a virtual machine basis, since the license
check is executed for a virtual machine already created and not
executed at the time of creation of a virtual machine, application
of the technique recited in Patent Literature 1 fails to solve the
above-described problems.
OBJECT OF THE INVENTION
[0009] An object of the present invention is to solve the
above-described problems and provide a thin client system, a
management server, a virtual machine creation management method and
a virtual machine creation management program which enable creation
of a virtual machine to be prevented in a hypervisor that cannot be
used by a license for use in creation of a virtual machine.
SUMMARY
[0010] According to a first exemplary aspect of the invention, a
thin client system includes at least one tenant including at least
one tenant terminal, a management data base which stores resource
information of the tenant, at least one data center in which a
virtual machine to be used by the tenant operates, and a management
server including a virtual machine creation management unit which
narrows down a hypervisor in which the virtual machine can be
created based on resource information of the tenant stored in the
management data base and a virtual machine creation request
including predetermined requirement information for creating the
virtual machine which is received from the tenant terminal.
[0011] According to a second exemplary aspect of the invention, a
management server of a thin client system includes a virtual
machine creation management unit which, based on resource
information of at least one tenant including at least one tenant
terminal stored in a management data base of the thin client system
and a virtual machine creation request including predetermined
requirement information for creating a virtual machine to be used
by the tenant on a data center of the thin client system which is
received from the tenant terminal, narrows down a hypervisor in
which the virtual machine can be created.
[0012] According to a third exemplary aspect of the invention, a
virtual machine creation management method, includes at a
management server of a thin client system, a virtual machine
creation management step of, based on resource information of at
least one tenant including at least one tenant terminal stored in a
management data base of the thin client system and a virtual
machine creation request including predetermined requirement
information for creating a virtual machine to be used by the tenant
on a data center of the thin client system which is received from
the tenant terminal, narrowing down a hypervisor in which the
virtual machine can be created.
[0013] According to a fourth exemplary aspect of the invention, a
computer readable medium storing a virtual machine creation
management program executed on a management server of a thin client
system, wherein the program causes the management server to execute
the functions of a virtual machine creation management processing
of, based on resource information of at least one tenant including
at least one tenant terminal stored in a management data base of
the thin client system and a virtual machine creation request
including predetermined requirement information for creating a
virtual machine to be used by the tenant on a data center of the
thin client system which is received from the tenant terminal,
narrowing down a hypervisor in which the virtual machine can be
created.
[0014] The present invention enables creation of a virtual machine
in a hypervisor that cannot be used by a license for use in
creating a virtual machine.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] FIG. 1 is a block diagram showing a structure of a DaaS
system according to a first exemplary embodiment of the present
invention;
[0016] FIG. 2 is a block diagram showing a structure of a data
center according to the first exemplary embodiment;
[0017] FIG. 3 is a block diagram showing a structure of a data
center according to the first exemplary embodiment;
[0018] FIG. 4 is a diagram showing an example of a structure of a
table group according to the first exemplary embodiment;
[0019] FIG. 5 is a flow chart showing operation of registration of
system structure information of the data center according to the
first exemplary embodiment;
[0020] FIG. 6 is a diagram showing an example of a structure of a
data center information storage table according to the first
exemplary embodiment;
[0021] FIG. 7 is a diagram showing an example of a structure of a
manager information storage table according to the first exemplary
embodiment;
[0022] FIG. 8 is a diagram showing an example of a structure of a
connection broker information storage table according to the first
exemplary embodiment;
[0023] FIG. 9 is a flow chart showing operation of collecting and
registering system structure information of the data center
according to the first exemplary embodiment;
[0024] FIG. 10 is a diagram showing an example of a structure of a
hypervisor information storage table according to the first
exemplary embodiment;
[0025] FIG. 11 is a diagram showing an example of a structure of a
template information storage table according to the first exemplary
embodiment;
[0026] FIG. 12 is a diagram showing an example of a structure of a
directory information storage table according to the first
exemplary embodiment;
[0027] FIG. 13 is a flow chart showing operation of registering
resource information of a tenant according to the first exemplary
embodiment;
[0028] FIG. 14 is a flow chart showing operation of registering
resource information of a tenant according to the first exemplary
embodiment;
[0029] FIG. 15 is a flow chart showing operation of registering
resource information of a tenant according to the first exemplary
embodiment;
[0030] FIG. 16 is a diagram showing an example of a structure of a
to-be-used data center information storage table according to the
first exemplary embodiment;
[0031] FIG. 17 is a flow chart showing operation of registering
resource information of a tenant according to the first exemplary
embodiment;
[0032] FIG. 18 is a diagram showing an example of a structure of a
to-be-used connection broker information storage table according to
the first exemplary embodiment;
[0033] FIG. 19 is a flow chart showing operation of registering
resource information of a tenant according to the first exemplary
embodiment;
[0034] FIG. 20 is a diagram showing an example of a structure of a
to-be-used hypervisor information storage table according to the
first exemplary embodiment;
[0035] FIG. 21 is a flow chart showing operation of registering
resource information of a tenant according to the first exemplary
embodiment;
[0036] FIG. 22 is a diagram showing an example of a structure of a
to-be-used template information storage table according to the
first exemplary embodiment;
[0037] FIG. 23 is a diagram showing an example of a structure of a
license information storage table according to the first exemplary
embodiment;
[0038] FIG. 24 is a diagram showing an example of a structure of a
tenant route information storage table according to the first
exemplary embodiment;
[0039] FIG. 25 is a diagram showing an example of a structure of a
tenant information storage table according to the first exemplary
embodiment;
[0040] FIG. 26 is a flow chart showing operation of requesting
virtual machine creation according to the first exemplary
embodiment;
[0041] FIG. 27 is a flow chart showing operation of requesting
virtual machine creation according to the first exemplary
embodiment;
[0042] FIG. 28 is a flow chart showing operation of requesting
virtual machine creation according to the first exemplary
embodiment;
[0043] FIG. 29 is a flow chart showing operation of requesting
virtual machine creation according to the first exemplary
embodiment;
[0044] FIG. 30 is a flow chart showing operation of requesting
virtual machine creation execution according to the first exemplary
embodiment;
[0045] FIG. 31 is a flow chart showing operation of requesting
virtual machine creation execution according to the first exemplary
embodiment;
[0046] FIG. 32 is a flow chart showing operation of registering
resource information of a tenant according to a second exemplary
embodiment;
[0047] FIG. 33 is a diagram showing an example of a structure of a
to-be-used hypervisor information storage table according to the
second exemplary embodiment;
[0048] FIG. 34 is a flow chart showing operation of registering
resource information of a tenant according to the second exemplary
embodiment;
[0049] FIG. 35 is a diagram showing an example of a structure of a
license information storage table according to the second exemplary
embodiment;
[0050] FIG. 36 is a flow chart showing operation of requesting
virtual machine creation according to the second exemplary
embodiment;
[0051] FIG. 37 is a flow chart showing operation of requesting
virtual machine creation execution according to the second
exemplary embodiment; and
[0052] FIG. 38 is a block diagram showing an example of a hardware
structure of a management server according to the present
invention.
EXEMPLARY EMBODIMENT
[0053] Next, detailed description will be made of exemplary
embodiments of the present invention with reference to the
drawings. In all the drawings, the same reference numerals are
allotted to the same components to appropriately omit their
description.
First Exemplary Embodiment
[0054] First, a first exemplary embodiment of the present invention
will be detailed with reference to the drawings. In the following
drawings, no description will be made of a component not related to
the gist of the present invention and no illustration will be made
of the same either.
[0055] FIG. 1 is a block diagram showing a structure of a DaaS
system 100 according to the present exemplary embodiment. With
reference to FIG. 1, the DaaS system 100 according to the present
exemplary embodiment comprises a management server 200, a
management data base 500, data centers 300-1 and 300-2 and a tenant
400.
[0056] Although it is assumed here for description's sake that the
present exemplary embodiment is structured to have two data centers
300-1 and 300-2 as the data center 300 and one tenant 400, the
structure is not limited thereto.
[0057] Also assume that when generically calling the data centers
300-1 and 300-2, for example, they will be appropriately referred
to as the data center 300. This is also the case with the other
components.
[0058] With reference to FIG. 2 and FIG. 3 here, they are block
diagrams of the data center 300.
[0059] The data center 300 represents a data center where a data
center server is disposed which operates a manager 310, a
connection broker 320, a hypervisor 330 and a directory 340. The
data center 300 is managed by a data center information storage
table 510.
[0060] The manager 310 has a function of managing at least one
hypervisor 330.
[0061] The manager 310 executes creation, deletion and
activation/stop of a virtual machine 331 in the hypervisor 330
managed and provides information about the managed hypervisor
330.
[0062] Possibly used as the manager 310 are Sigma System Center,
Microsoft System Center, VMware vCenter Server, Citrix Provisioning
Server and the like, which are managed by a manager information
storage table 511.
[0063] With reference to FIG. 2 and FIG. 3, a manager A manages
hypervisors A and B, a manager B manages hypervisors C and D, a
manager C manages hypervisors E and F and a manager D manages
hypervisors G and H, respectively.
[0064] The connection broker 320, which is connected to the manager
310, has a function of controlling connection between the virtual
machine 331 on the hypervisor 330 managed by the manager 310 and a
virtual machine user. The connection broker 320 is managed by a
connection broker information storage table 512.
[0065] The connection broker 320 refers to the contents of the
directory 340 to control the connection. The connection broker 320
also provides the contents of the referred directory.
[0066] Possibly used as the connection broker 320 are Client
Management Option, VMware View, Xen Desktop and the like, which are
managed by the connection broker information storage table 512.
[0067] With reference to FIG. 2 and FIG. 3, connection brokers A
and B are connected to the manager A to refer to directories A and
B. Connection brokers C and D are connected to the manager B to
refer to the directories A and B. Connection brokers E and F are
connected to the manager C to refer to directories A' and B'.
Connection brokers G and H are connected to the manager D to refer
to the directories A' and B'.
[0068] The hypervisor 330 has a function of creating the virtual
machine 331 by using designated template 332 and license.
[0069] The hypervisor 330 also has a function of managing deletion,
activation and stop, etc. of the created virtual machine 331.
[0070] The hypervisor 330 also has a function of providing
information about its managed virtual machine 331 and the template
332.
[0071] Used as the hypervisor 330 are VMware ESX, Hyper-V, Xen
Server and the like, which are managed by a hypervisor information
storage table 513.
[0072] With reference to FIG. 2 and FIG. 3, the hypervisor A
manages virtual machines A, B and C and is allowed to use templates
A, B, C and D.
[0073] The hypervisor B manages virtual machines D, E and F and is
allowed to use templates E, F, G and H.
[0074] The hypervisor C has no virtual machine 331 existing and is
allowed to use the templates A, B, C and D.
[0075] The hypervisor D manages virtual machines J, K and L and is
allowed to use the templates A, B, G and H.
[0076] The hypervisor E manages virtual machines M and N and is
allowed to use the templates A, B, C and D.
[0077] The hypervisor F manages virtual machines O, P and Q and is
allowed to use the templates E, F, G and H.
[0078] The hypervisor G manages virtual machines R, S and T and is
allowed to use the templates A, B, C and D.
[0079] The hypervisor H manages virtual machines U, V and W and is
allowed to use the templates A, B, G and H.
[0080] The directory 340 has a function of providing directory
service for registering and providing domain information or the
like of a user allowed to use the virtual machine 331 by the tenant
400 (hereinafter referred to as a tenant user).
[0081] Possibly used as the directory 340 are Active Directory,
Open LDAP and the like and each element of information held by the
directory 340 is managed by a directory information storage table
514.
[0082] With reference to FIG. 2 and FIG. 3, the directories A and B
are referred to by the connection brokers A, B, C and D.
[0083] The directories A' and B' are referred to by the connection
brokers E, F, G and H.
[0084] The directories A' and B' are mirrors of the directories A
and B, respectively, and provide the same information as that of
the directories A and B.
[0085] The template 332 is used when creating the virtual machine
331 on the hypervisor 330. The template 332 includes, as contents,
structure information of the virtual machine 331 to be created,
information of an OS or an application to be installed into the
virtual machine 331, and the like. The template 332 is managed by a
template information storage table 515.
[0086] The management server 200 includes a data center
registration unit 201 which registers system structure information
of the data center 300 at the management data base 500, a data
center control unit 202 which collects system structure information
of the data center 300 and creates the virtual machine 331, a
tenant registration unit 203 which registers resource information
of the tenant 400 and a virtual machine creation management unit
204 which extracts the hypervisor 330 in which the virtual machine
331 is to be created.
[0087] The data center registration unit 201 has a function of
registering predetermined information necessary for controlling the
data center 300 at the management data base 500.
[0088] The data center registration unit 201 has a function of
requesting the data center control unit 202 to collect system
structure information of the data center 300 based on data center
information stored in the data center information storage table 510
which will be described later.
[0089] The data center control unit 202 has a function of
collecting system structure information from the data center 300
and registering the system structure information at the management
data base 500 based on a request from the data center registration
unit 201.
[0090] System structure information to be obtained by the data
center control unit 202 here includes information of the manager
310, the connection broker 320, the hypervisor 330, the template
332, the directory 340 and the like disposed in the data center
300.
[0091] The data center control unit 202 has a function of creating
the virtual machine 313 in a predetermined hypervisor 330 of the
data center 300 based on a virtual machine creation execution
request from the virtual machine creation management unit 204.
[0092] The tenant registration unit 203 has a function of
registering resource information of the tenant 400 (hereinafter
referred to as tenant information) at the management data base
500.
[0093] Here, tenant represents equivalency of so-called business
office, shop and the like. Tenant information includes at least a
tenant name.
[0094] The virtual machine creation management unit 204 has a
function of extracting the hypervisor 330 in which the virtual
machine 331 is to be created based on a virtual machine creation
request received from a virtual machine creation requesting unit
411 which will be described later and predetermined information
registered at the management data base 500. Details of the function
will be described in the description of operation of the present
exemplary embodiment.
[0095] The virtual machine creation management unit 204 has a
function of sending a request for creating the virtual machine 331
in the hypervisor 330 selected by a system manager from among
extracted hypervisors 330 to the data center control unit 202 as a
virtual machine creation execution request.
[0096] The tenant 400 comprises a tenant terminal 410 including the
virtual machine creation requesting unit 411 which requests
creation of the virtual machine 331. While the present exemplary
embodiment has a single tenant terminal 410 existing, it may have a
plurality of terminals existing.
[0097] The virtual machine creation requesting unit 411 has a
function of sending a virtual machine creation request for
requesting creation of the virtual machine 331 based on
predetermined information registered at the management data base
500 to the virtual machine creation management unit 204.
[0098] While the virtual machine creation requesting unit 411 is
provided in the tenant terminal 410 in the present exemplary
embodiment, it may be provided in the management server 200 to
execute each processing on the management server 200.
[0099] The management data base 500 comprises a table group 502
which stores information registered by the data center registration
unit 201, the data center control unit 202 and the tenant
registration unit 203, and a storage unit 501 which stores
registered information in a predetermined table of the table group
502. Information of a table of the table group 502 may be
arbitrarily registered by a system manager or the like.
[0100] Here, FIG. 4 is a diagram showing an example of a structure
of the table group 502.
[0101] With reference to FIG. 4, the table group 502 comprises the
data center information storage table 510, the manager information
storage table 511, the connection broker information storage table
512, the hypervisor information storage table 513, the directory
information storage table 514, the template information storage
table 515, a tenant information storage table 516, a to-be-used
data center information storage table 517, a to-be-used connection
broker information storage table 518, a tenant route information
storage table 519, a to-be-used hypervisor information storage
table 520, a to-be-used template information storage table 521, a
license information storage table 522 and a virtual machine
information storage table 523.
[0102] The data center information storage table 510 stores
information related to a data center (hereinafter referred to as
data center information).
[0103] The data center information includes at least a data center
name and location information of a data center (address, GPS
(Global Positioning System) coordinates, etc.).
[0104] The manager information storage table 511 stores information
related to the manager 310 (hereinafter referred to as manager
information).
[0105] The manager information includes at least a manager name, an
address of the manager and a data center name where the manager is
disposed. The data center name is stored as a reference to the data
center information storage table 510.
[0106] With reference to FIG. 4 here, a broken line arrow from the
manager information storage table 511 to the data center
information storage table 510 indicates a reference relation in
question. Similarly, broken line arrows all indicate reference
relationships in FIG. 4.
[0107] For the sake of description, while the manager information
storage table 511 is designed to have reference to a data center
name in the present exemplary embodiment, the data center name is
assumed to be information that enables unitary identification of
the data center 300. The manager name is also assumed to be
information that enables unitary identification of the manager 310
and this is also the case with all the other names which will be
described later. In addition, while in the present exemplary
embodiment, a name is assumed to be information to be referred to,
the information is not limited thereto but is any information that
enables unitary identification of the data center 300 and the
like.
[0108] The connection broker information storage table 512 stores
information related to the connection broker 320 (hereinafter
referred to as connection broker information).
[0109] The connection broker information includes at least a
connection broker name, an address of the connection broker and a
manager name to be connected. The manager name is stored as
reference to the manager information storage table 511.
[0110] The hypervisor information storage table 513 stores
information related to a hypervisor that the data center 300
comprises (hereinafter referred to as hypervisor information).
Hypervisor information is collected and registered by the data
center control unit 202.
[0111] The hypervisor information includes at least a hypervisor
name, a kind of hypervisor, a server specification and a manager
name of a management source. The manager name is stored as
reference to the manager information storage table 511.
[0112] The template information storage table 515 stores
information related to a template (hereinafter referred to as
template information).
[0113] The template information includes at least a template name,
contents of the template and a hypervisor name that is allowed to
use the template. The hypervisor name is stored as reference to the
hypervisor information storage table 513.
[0114] The directory information storage table 514 stores
information related to the directory 340 (hereinafter referred to
as directory information).
[0115] The directory information includes at least a directory path
which stores a domain of a tenant user or the like and a connection
broker name which is allowed to refer to the directory path. The
connection broker name is stored as reference to the connection
broker information storage table 512.
[0116] The virtual machine information storage table 523 stores
information related to a virtual machine (hereinafter referred to
as virtual machine information).
[0117] The virtual machine information includes at least a virtual
machine name, a tenant name that uses the virtual machine, a
hypervisor name where the virtual machine is to be created and a
license name used by the virtual machine.
[0118] The tenant name, the hypervisor name and the license name
are stored as reference to the tenant information storage table
516, the hypervisor information storage table 513 and the license
information storage table 522.
[0119] The tenant information storage table 516 stores information
related to the tenant 400 (hereinafter referred to as tenant
information). The tenant information includes at least a tenant
name.
[0120] The to-be-used data center information storage table 517
stores information of the data center 300 that can be used by the
tenant 400 (hereinafter referred to as to-be-used data center
information).
[0121] The to-be-used data center information includes at least a
tenant name and a data center name used by the tenant. The tenant
name and the data center name are stored as reference to the tenant
information storage table 516 and the data center information
storage table 510, respectively.
[0122] The to-be-used connection broker information storage table
518 stores information of the connection broker 320 that can be
used by the tenant 400 (hereinafter referred to as to-be-used
connection broker information).
[0123] The to-be-used connection broker information includes at
least a tenant name and a connection broker name used by the
tenant. The tenant name and the connection broker name are stored
as reference to the tenant information storage table 516 and the
connection broker information storage table 512, respectively.
[0124] The tenant route information storage table 519 stores domain
information of a tenant user that is allowed to use the virtual
machine 331 in the tenant 400 and information about a directory
path at which the domain information in question is registered
(hereinafter referred to as tenant route information).
[0125] The tenant route information includes at least a tenant
name, a directory path, a domain name and domain authentication
information. The tenant name and the directory path are stored as
reference to the tenant information storage table 516 and the
directory information storage table 514, respectively.
[0126] The to-be-used hypervisor information storage table 520
stores information of the hypervisor 330 that can be used by the
tenant 400 (hereinafter referred to as to-be-used hypervisor
information).
[0127] The to-be-used hypervisor information includes at least a
tenant name and a hypervisor name. The tenant name and the
hypervisor name are stored as reference to the tenant information
storage table 516 and the hypervisor information storage table 513,
respectively.
[0128] The to-be-used template information storage table 521 stores
information of the template 332 that can be used by the tenant 400
(hereinafter referred to as to-be-used template information).
[0129] The to-be-used template information includes at least a
tenant name and a template name. The tenant name and the template
name are stored as reference to the tenant information storage
table 516 and the template information storage table 515,
respectively.
[0130] The license information storage table 522 stores a license
and information of the template 332 that uses the license
(hereinafter referred to as license information).
[0131] The license information includes at least a template name
that uses the license, a license key, multi-tenant coexistence
determination information, expiration date and an effective number.
The template name is stored as reference to-be-used template
information storage table 521.
[0132] Here, the multi-tenant coexistence determination information
is information indicating whether virtual machines 331 of a
plurality of tenants 400 are allowed to exist on the same
hypervisor 330.
[0133] The multi-tenant coexistence determination information
indicating "coexistence allowed" represents that the virtual
machines 331 of a plurality of tenants 400 are allowed to exist on
the same hypervisor 330 and the multi-tenant coexistence
determination information indicating "coexistence not allowed"
represents that the virtual machines 331 of a plurality of tenants
400 are not allowed to exist on the same hypervisor 330.
(Description of Operation of the First Exemplary Embodiment)
[0134] Next, detailed description will be made of operation of the
DaaS system 100 according to the present exemplary embodiment with
reference to the drawings.
(Description of Operation of Registering System Structure
Information of Data Center 300)
[0135] Description will be made of operation of registering system
structure information of the data center 300 with reference to the
drawings.
[0136] FIG. 5 is a flow chart showing operation of registering
system structure information of the data center 300 according to
the present exemplary embodiment.
[0137] With reference to FIG. 5, first, when data center
information of data centers A and B to be used in the DaaS system
100 is input by a system manager (Step S501), the data center
registration unit 201 registers the data center information at the
management data base 500 (Step S502).
[0138] As to the data center information, assume here that
registered as data center information of the data center A are a
data center name "data center A" and location information "Tokyo"
and registered as data center information of the data center B are
a data center name "data center B" and location information
"Washington".
[0139] Next, the storage unit 501 stores the data center
information in the data center information storage table 510 (Step
S503).
[0140] Here, shown in FIG. 6 is an example of a structure of the
data center information storage table 510 as of after Step
S503.
[0141] Next, when the manager information of the managers A through
D disposed in the data centers A and B is input by the system
manager (Step S504), the data center registration unit 201
registers, at the management data base 500, new manager information
with the input manager information and a data center name where the
manager is disposed correlated with each other (Step S505).
[0142] Assume here that registered as manager information of the
manager A at Step S505 are the manager name "manager A", the
address "http://manager-a.nec.co.jp" and the data center name "data
center A".
[0143] Also assume that registered as manager information of the
manager B are the manager name "manager B", the address
"http://manager-b.nec.co.jp" and the data center name "data center
A".
[0144] Also assume that registered as manager information of the
manager C are the manager name "manager C", the address
"http://manager-c.nec.co.us" and the data center name "data center
B".
[0145] Also assume that registered as manager information of the
manager D are the manager name "manager D", the address
"http://manager-d.nec.co.us" and the data center name "data center
B".
[0146] Next, the storage unit 501 stores the registered manager
information in the manager information storage table 511 (Step
S506). At this time, the storage unit 501 stores the data center
name as reference to the data center information storage table
510.
[0147] Here, shown in FIG. 7 is an example of a structure of the
manager information storage table 511 as of after Step S506.
[0148] Next, when the connection broker information of the
connection brokers A through H connected to the registered managers
A through D is input by the system manager (Step S507), the data
center registration unit 201 registers, at the management data base
500, new connection broker information with the input connection
broker information and a connection destination manager name
correlated with each other (Step S508).
[0149] Assume here that registered as connection broker information
of the connection broker A at Step S508 are the connection broker
name "connection broker A", the address
"http://connectionbroker-a.nec.co.jp" and the manager name "manager
A".
[0150] Also assume that registered as connection broker information
of the connection broker B are the connection broker name
"connection broker B", the address
"http://connectionbroker-b.nec.co.jp" and the manager name "manager
A".
[0151] Also assume that registered as connection broker information
of the connection broker C are the connection broker name
"connection broker C", the address
"http://connectionbroker-c.nec.co.jp" and the manager name "manager
B".
[0152] Also assume that registered as connection broker information
of the connection broker D are the connection broker name
"connection broker D", the address
"http://connectionbroker-d.nec.co.jp" and the manager name "manager
B".
[0153] Also assume that registered as connection broker information
of the connection broker E are the connection broker name
"connection broker E", the address
"http://connectionbroker-e.nec.co.us" and the manager name "manager
C".
[0154] Also assume that registered as connection broker information
of the connection broker F are the connection broker name
"connection broker F", the address
"http://connectionbroker-f.nec.co.us" and the manager name "manager
C".
[0155] Also assume that registered as connection broker information
of the connection broker G are the connection broker name
"connection broker G", the address
"http://connectionbroker-g.nec.co.us" and the manager name "manager
D".
[0156] Also assume that registered as connection broker information
of the connection broker H are the connection broker name
"connection broker H", the address
"http://connectionbroker-h.nec.co.us" and the manager name "manager
D".
[0157] Next, the storage unit 501 stores the connection broker
information in the connection broker information storage table 512
(Step S509). At this time, the storage unit 501 stores a manager
name in the form of reference to the manager information storage
table 511.
[0158] Here, an example of a structure of the connection broker
information storage table 512 as of after Step S509 is shown in
FIG. 8.
[0159] Next, the data center registration unit 201 requests the
data center control unit 202 to collect system structure
information of the data centers A and B (Step S510).
[0160] In the processing executed so far, the system structure
information of the data centers A and B is recorded in the
management data base 500.
(Description of Operation of Collecting and Registering System
Structure Information of the Data Center 300)
[0161] While with respect to the above-described Step S501 through
Step S510, the description has been made of operation of
registering the system structure information of the data center 300
input by the system manager, more detailed description will be here
made of operation of collecting and registering the system
structure information of the data center 300.
[0162] FIG. 9 is a flow chart showing operation of collecting and
registering the system structure information of the data center 300
according to the present exemplary embodiment.
[0163] First, upon receiving a request for collecting the system
structure information of the data centers A and B from the data
center registration unit 201 made at Step S510 in FIG. 5 (Step
S901), the data center control unit 202 refers to the data center
information storage table 510, the manager information storage
table 511 and the connection broker information storage table 512
of the management data base 500 to obtain manager information of
the managers A through D and connection broker information of the
connection brokers A through H related to the data centers A and B
(Step S902).
[0164] Specific operation to be executed here is to obtain manager
information having a data center name of "data center A" or "data
center B". As a result, manager information of the managers A
through D is obtained.
[0165] Connection broker information to be obtained is connection
broker information which includes the above-obtained managers A
through D as a manager name. As a result, the connection brokers A
through H are obtained.
[0166] Next, the data center control unit 202 connects to the
managers A through D whose manager information is obtained (Step
S903) to obtain hypervisor information of the hypervisor 330
managed by the managers A through D and template information of the
template 332 usable by the hypervisor 330 in question as system
structure information (Step S904).
[0167] More specifically, the data center control unit 202 obtains
hypervisor information of the hypervisors A and B as hypervisor
information managed by the manager A, obtains hypervisor
information of the hypervisors C and D as hypervisor information
managed by the manager B, obtains hypervisor information of the
hypervisors E and F as hypervisor information managed by the
manager C and obtains hypervisor information of the hypervisors G
and H as hypervisor information managed by the manager D.
[0168] Assume here that the obtained hypervisor information of the
hypervisor A includes the hypervisor name "hypervisor A", a kind of
hypervisor "VMware ESX", the server specification "CPU: 3
GHz.times.16, memory: 16 GB" and the manager name "manager A". The
manager name represents a management source manager name. This is
also the case in the following.
[0169] Also assume that the obtained hypervisor information of the
hypervisor B includes the hypervisor name "hypervisor B", a kind of
hypervisor "VMware ESX", the server specification "CPU: 3
GHz.times.16, memory: 16 GB" and the manager name "manager A".
[0170] Also assume that the obtained hypervisor information of the
hypervisor C includes the hypervisor name "hypervisor C", a kind of
hypervisor "VMware ESX", the server specification "CPU: 3
GHz.times.16, memory: 16 GB" and the manager name "manager B".
[0171] Also assume that the obtained hypervisor information of the
hypervisor D includes the hypervisor name "hypervisor D", a kind of
hypervisor "VMware ESX", the server specification "CPU: 3
GHz.times.16, memory: 16 GB" and the manager name "manager B".
[0172] Also assume that the obtained hypervisor information of the
hypervisor E includes the hypervisor name "hypervisor E", a kind of
hypervisor "VMware ESX", the server specification "CPU: 3
GHz.times.16, memory: 16 GB" and the manager name "manager C".
[0173] Also assume that the obtained hypervisor information of the
hypervisor F includes the hypervisor name "hypervisor F", a kind of
hypervisor "VMware ESX", the server specification "CPU: 3
GHz.times.16, memory: 16 GB" and the manager name "manager C".
[0174] Also assume that the obtained hypervisor information of the
hypervisor G includes the hypervisor name "hypervisor G", a kind of
hypervisor "VMware ESX", the server specification "CPU: 3
GHz.times.16, memory: 16 GB" and the manager name "manager D".
[0175] Also assume that the obtained hypervisor information of the
hypervisor H includes the hypervisor name "hypervisor H", a kind of
hypervisor "VMware ESX", the server specification "CPU: 3
GHz.times.16, memory: 16 GB" and the manager name "manager D".
[0176] The data center control unit 202 obtains template
information of the templates A, B, C and D as template information
usable by the hypervisor A, obtains template information of the
templates E, F, G and H as template information usable by the
hypervisor B, obtains the template information of the templates A,
B, C and D as template information usable by the hypervisor C,
obtains the template information of the templates A, B, G and H as
template information usable by the hypervisor D, obtains the
template information of the templates A, B, C and D as template
information usable by the hypervisor E, obtains the template
information of the templates E, F, G and H as template information
usable by the hypervisor F, obtains the template information of the
templates A, B, C and D as template information usable by the
hypervisor G, and obtains the template information of the templates
A, B, G and H as template information usable by the hypervisor
H.
[0177] Assume here that the obtained template information of the
template A includes the template name "template A", the contents of
the template "Windows XP, memory: 1 GB", the hypervisor names
"hypervisor A", "hypervisor C", "hypervisor D", "hypervisor E",
"hypervisor G" and "hypervisor H". The hypervisor name represents a
hypervisor name of the hypervisor 330 which uses the template A.
This is also the case in the following.
[0178] Also assume that the obtained template information of the
template B includes the template name "template B", the contents of
the template "Ubuntu 9, memory: 1 GB", the hypervisor names
"hypervisor A", "hypervisor C", "hypervisor D", "hypervisor E",
"hypervisor G" and "hypervisor H".
[0179] Also assume that the obtained template information of the
template C includes the template name "template C", the contents of
the template "Windows 7, memory: 2 GB", the hypervisor names
"hypervisor A", "hypervisor C", "hypervisor E" and "hypervisor
G".
[0180] Also assume that the obtained template information of the
template D includes the template name "template D", the contents of
the template "Ubuntu 10, memory: 2 GB", the hypervisor names
"hypervisor A", "hypervisor C", "hypervisor E" and "hypervisor
G".
[0181] Also assume that the obtained template information of the
template E includes the template name "template E", the contents of
the template "Windows XP, memory: 2 GB", the hypervisor names
"hypervisor B" and "hypervisor F".
[0182] Also assume that the obtained template information of the
template F includes the template name "template F", the contents of
the template "Ubuntu 9, memory: 2 GB", the hypervisor names
"hypervisor B" and "hypervisor F".
[0183] Also assume that the obtained template information of the
template G includes the template name "template G", the contents of
the template "Windows Vista, memory: 2 GB", the hypervisor names
"hypervisor B", "hypervisor D", "hypervisor F" and "hypervisor
H".
[0184] Also assume that the obtained template information of the
template H includes the template name "template H", the contents of
the template "Fedora 11, memory: 2 GB", the hypervisor names
"hypervisor B", "hypervisor D", "hypervisor F" and "hypervisor
H".
[0185] Next, the data center control unit 202 connects to the
connection brokers A through H whose connection broker information
is obtained (Step S905) to obtain directory information of the
directory 340 to which the connection brokers A through H refer as
system structure information (Step S906).
[0186] More specifically, the data center control unit 202 obtains
directory information of the directories A and B as directory
information to which the connection brokers A through D refer and
obtains directory information of the directories A' and B' as
directory information to which the connection brokers E through H
refer.
[0187] Since the directories A' and B' are mirrors of the
directories A and B, the connection brokers E through H are
substantially allowed to refer to the same directory information as
that of the connection brokers A through D.
[0188] Assume here that the obtained directory information of the
directory A includes directory paths "o=tenant-a, c=jp", "ou=sales,
o=tenant-a, c=jp" and "cn=user-a, ou=sales, o=tenant-a, c=jp" and
connection broker names "connection broker A", "connection broker
B", "connection broker C" and "connection broker D". The connection
broker name represents a connection broker name of the connection
broker 320 which refers to the directory A. This is also the case
in the following.
[0189] Also assume that the obtained directory information of the
directory B includes directory paths "o=tenant-b, c=jp", "ou=sales,
o=tenant-b, c=jp" and "cn=user-b, ou=sales, o=tenant-b, c=jp" and
connection broker names "connection broker A", "connection broker
B", "connection broker C" and "connection broker D".
[0190] Also assume that the obtained directory information of the
directory A' includes directory paths "o=tenant-a, c=jp",
"ou=sales, o=tenant-a, c=jp" and "cn=user-a, ou=sales, o=tenant-a,
c=jp" and connection broker names "connection broker E",
"connection broker F", "connection broker G" and "connection broker
H".
[0191] Also assume that the obtained directory information of the
directory B' includes directory paths "o=tenant-b, c=jp",
"ou=sales, o=tenant-b, c=jp" and "cn=user-b, ou=sales, o=tenant-b,
c=jp" and connection broker names "connection broker E",
"connection broker F", "connection broker G" and "connection broker
H".
[0192] Next, the data center control unit 202 registers the
obtained hypervisor information, template information and directory
information at the management data base 500 (Step S907).
[0193] Next, the storage unit 501 stores the registered hypervisor
information in the hypervisor information storage table 513 (Step
S908). At this time, the storage unit 501 stores a manager name
existing in the hypervisor information in the form of reference to
the manager information management table 511.
[0194] The storage unit 501 in addition stores the registered
template information in the template information storage table 515
(Step S909). At this time, the storage unit 501 stores a hypervisor
name existing in the template information in the form of reference
to the hypervisor information storage table 513.
[0195] The storage unit 501 also stores the registered directory
information in the directory information storage table 514 (Step
S910). At this time, the storage unit 501 stores a connection
broker name existing in the directory information in the form of
reference to the connection broker information storage table
512.
[0196] Shown here in FIG. 10 through FIG. 12 are examples of
structures of the hypervisor information storage table 513, the
template information storage table 515 and the directory
information storage table 514 as of after Steps S908 and S909.
(Description of Operation of Registering Resource Information of
Tenant 400)
[0197] Next, description will be made of operation of registering
resource information of the tenant 400 using the DaaS system 100
according to the present exemplary embodiment with reference to the
flow chart of FIG. 13. FIG. 13 is a flow chart showing the
operation of registering resource information of the tenant.
[0198] With reference to FIG. 13, first, when the system manager
inputs tenant information of a tenant A which uses the DaaS system
100 (Step S1301), the tenant registration unit 203 presents the
data center 300 usable by the tenant A to the system manager (Step
S1302).
[0199] Here, more detailed operation of Steps S1301 and S1302 will
be described with reference to the flow chart of FIG. 14.
[0200] With reference to FIG. 14, when the system manager inputs
tenant information of the tenant A (Step S1401), the tenant
registration unit 203 registers the tenant information at the
management data base 500 (Step S1402).
[0201] Here, the registered tenant information is assumed to be the
tenant name "tenant A".
[0202] Next, the storage unit 501 stores the tenant name "tenant A"
in the tenant information storage table 516 (Step S1403).
[0203] Here, an example of a structure of the tenant information
storage table 516 as of after Step S1403 is shown in FIG. 25.
[0204] Next, the tenant registration unit 203 refers to the data
center information storage table 510, extracts the data center
names "data center A" and "data center B" (Step S1404) and provides
the same to the system manager (Step S1405).
[0205] As a method of the presentation here, the presentation can
be realized by representation by a display, for example. This is
also the case in the following. Not only a data center name but
also other information stored in the data center information
storage table 510 may be presented.
[0206] Subsequently, back to FIG. 13, when the system manager
selects the data center 300 to be used by the registered tenant A
(the tenant terminal 410 of the tenant A) from the presented data
center names "data center A" and "data center B" (Step S1303), the
tenant registration unit 203 presents the connection broker 320
usable by the tenant A to the system manager (Step S1304).
[0207] Here, detailed operation of Steps S1303 and S1304 will be
described with reference to the flow chart of FIG. 15.
[0208] With reference to FIG. 15, first, when the system manager
selects the data center 300 to be used by the registered tenant A
(the tenant terminal 410 of the tenant A) from the presented data
center names "data center A" and "data center B" (Step S1501), the
tenant registration unit 203 registers, at the management data base
500, the tenant name "tenant A" of the tenant A and the data center
name of the selected data center 300 so as to be correlated with
each other as to-be-used data center information (Step S1502).
[0209] Here, the data center 300 selected by the system manager is
assumed to be the data centers A and B. Accordingly, the registered
to-be-used data center information will be the tenant name "tenant
A" and the data center names "data center A" and "data center
B".
[0210] Next, the storage unit 501 stores the to-be-used data center
information in the to-be-used data center information storage table
517 (Step S1503).
[0211] At this time, the storage unit 501 stores the tenant name
and the data center name in the form of reference to the tenant
information storage table 516 and the data center information
storage table 510, respectively.
[0212] Here, an example of a structure of the to-be-used data
center information storage table 517 as of after Step S1503 is
shown in FIG. 16.
[0213] Next, the tenant registration unit 203 extracts a data
center name tied with the tenant name "tenant A" from the
to-be-used data center information storage table 517 (Step S1504).
As a result, the data center names "data center A" and "data center
B" are extracted.
[0214] Next, the tenant registration unit 203 refers to the manager
information storage table 511 to extract a manager name tied with a
data center name "data center A" or "data center B" (Step S1505).
As a result, the manager names "manager A", "manager B", "manager
C" and "manager D" are extracted.
[0215] Next, the tenant registration unit 203 refers to the
connection broker information storage table 512 to extract a
connection broker name tied with any of the manager names "manager
A", "manager B", "manager C" and "manager D" (Step S1506). As a
result, the connection broker names "connection broker A",
"connection broker B", "connection broker C", "connection broker
D", "connection broker E", "connection broker F", "connection
broker G" and "connection broker H" are extracted.
[0216] Next, the tenant registration unit 203 presents to the
system manager the extracted connection broker names "connection
broker A", "connection broker B", "connection broker C",
"connection broker D", "connection broker E", "connection broker
F", "connection broker G" and "connection broker H" (Step
S1507).
[0217] At Step S1506, information other than a connection broker
name may be extracted together and presented to the system
manager.
[0218] Subsequently, back to FIG. 13, when the connection broker
320 to be used by the registered tenant A is selected from the
presented connection broker information (Step S1305), the tenant
registration unit 203 presents the hypervisor 330 usable by the
tenant A to the system manager (Step S1306).
[0219] Here, detailed operation of Steps S1305 and S1306 will be
described with reference to the flow chart of FIG. 17.
[0220] With reference to FIG. 17, first, when the system manager
selects the connection broker 320 to be used by the registered
tenant A from the presented connection broker 320 (Step S1701), the
tenant registration unit 203 registers the tenant name of the
tenant A and the connection broker name of the selected connection
broker 320 so as to be correlated with each other as to-be-used
connection broker information at the management data base 500 (Step
S1702).
[0221] Assume here that the connection brokers 320 selected by the
system manager are the connection brokers A, B, C and E.
[0222] Accordingly, the registered to-be-used connection broker
information will be "tenant A" and "connection broker A", "tenant
A" and "connection broker B", "tenant A" and "connection broker C"
and "tenant A" and "connection broker E".
[0223] Next, the storage unit 501 stores the to-be-used connection
broker information in the to-be-used connection broker information
storage table 518 (Step S1703). At this time, the storage unit 501
stores the tenant name and the connection broker name in the form
of reference to the tenant information storage table 516 and the
connection broker information storage table 512, respectively.
[0224] Here, an example of a structure of the to-be-used connection
broker information storage table 518 as of after Step S1703 is
shown in FIG. 18.
[0225] Next, the tenant registration unit 203 refers to the
to-be-used connection broker information storage table 518 to
extract a connection broker name tied with the tenant name "tenant
A" (Step S1704).
[0226] As a result, connection broker names "connection broker A",
"connection broker B", "connection broker C" and "connection broker
E" are extracted.
[0227] Next, the tenant registration unit 203 refers to the
connection broker information storage table 512 to extract a
manager name tied with any of the connection broker names
"connection broker A", "connection broker B", "connection broker C"
and "connection broker E" (Step S1705). As a result, the manager
names "manager A", "manager B" and "manager C" are extracted.
[0228] Next, the tenant registration unit 203 refers to the
hypervisor information storage table 513 to extract a hypervisor
name tied with any of the manager names "manager A", "manager B"
and "manager C" (Step S1706).
[0229] As a result, the hypervisor names "hypervisor A",
"hypervisor B", "hypervisor C", "hypervisor D", "hypervisor E" and
"hypervisor F" are extracted.
[0230] Next, the tenant registration unit 203 presents to the
system manager the extracted hypervisor names "hypervisor A",
"hypervisor B", "hypervisor C", "hypervisor D", "hypervisor E" and
"hypervisor F" (Step S1707).
[0231] At Step S1706, information other than a hypervisor name may
be extracted together and presented to the system manager.
[0232] Here, back to FIG. 13, subsequently when the hypervisor 330
to be used by the tenant A is selected from the presented
hypervisor information (Step S1307), the tenant registration unit
203 presents the template 332 usable by the hypervisor to the
system manager (Step S1308).
[0233] Here, detailed operation of Steps S1307 and S1308 will be
described with reference to the flow chart of FIG. 19.
[0234] With reference to FIG. 19, when the system manager selects
the hypervisor 330 to be used by the tenant A from the presented
hypervisor information (Step S1901), the tenant registration unit
203 registers the tenant name of the tenant A and the hypervisor
name of the selected hypervisor 330 so as to be correlated with
each other as to-be-used hypervisor information at the management
data base 500 (Step S1902).
[0235] Assume here that the hypervisors 330 selected by the system
manager are the hypervisors A, C and E. Accordingly, the registered
to-be-used hypervisor information will be "tenant A" and
"hypervisor A", "tenant A" and "hypervisor C", and "tenant A" and
"hypervisor E".
[0236] Next, the storage unit 501 stores the to-be-used hypervisor
information in the to-be-used hypervisor information storage table
520 (Step S1903).
[0237] At this time, the storage unit 501 stores the tenant name
and the hypervisor name in the form of reference to the tenant
information storage table 516 and the hypervisor information
storage table 513, respectively.
[0238] Here, an example of a structure of the to-be-used hypervisor
information storage table 520 as of after Step S1903 is shown in
FIG. 20.
[0239] Next, the tenant registration unit 203 refers to the
hypervisor information storage table 510 to extract a hypervisor
name tied with the tenant name "tenant A" (Step S1904). As a
result, the hypervisor names "hypervisor A", "hypervisor C" and
"hypervisor E" are extracted.
[0240] Next, the tenant registration unit 203 refers to the tenant
information storage table 515 to extract a template name tied with
any of the hypervisor names "hypervisor A", "hypervisor C" and
"hypervisor E" (Step S1905). As a result, the template names
"template A", "template B", "template C" and "template D" are
extracted.
[0241] Next, the tenant registration unit 203 presents to the
system manager the extracted "template A", "template B", "template
C" and "template D" (Step S1906). At Step S1905, other information
than a template name may be extracted together and presented to the
system manager.
[0242] Here, back to FIG. 13, subsequently when the system manager
selects the template 332 to be used by the hypervisor 330 used by
the tenant A from the presented templates 332 (Step S1309), the
tenant registration unit 203 presents directory information of a
directory at which domain information of a tenant user of the
tenant 400 can be registered to the system manager (Step S1310).
Tenant user will be described later.
[0243] Here, detailed operation of Steps S1309 and S1310 will be
described with reference to the flow chart of FIG. 21.
[0244] With reference to FIG. 21, when the system manager selects
the template 332 to be used by the hypervisor 330 used by the
tenant A from the presented template information (Step S2101) and
further inputs a license to be used by the selected template 332
(Step S2102), the tenant registration unit 203 registers the tenant
name of the tenant A and the template name of the selected template
332 so as to be correlated with each other as to-be-used template
information at the management data base 500 (Step S2103), as well
as registering, at the management data base 500, the tenant name of
the tenant A and the template name of the selected template 332,
and the input license so as to be correlated with each other as
license information (Step S2104).
[0245] Here, the template 332 selected by the system manager is
assumed to include the templates A and B. Accordingly, the
registered to-be-used template information will be "tenant A" and
"template A", and "tenant A" and "template B".
[0246] Also assume that a license to be used by the template A
input by the system manager has "license key "AAAA-AAAA-AAAA-AAAA",
multi-tenant coexistence determination information "coexistence not
allowed", expiration date "no limit" and effective number "100""
and a license to be used by the template B has "license key
"BBBB-BBBB-BBBB-BBBB", multi-tenant coexistence determination
information "coexistence allowed", expiration date "no limit", and
effective number "no limit"".
[0247] Accordingly, the registered license information will include
"tenant A" and "template A", and license "license key
"AAAA-AAAA-AAAA-AAAA", multi-tenant coexistence determination
information "coexistence not allowed", expiration date "no limit"
and effective number "100"", and "tenant A" and "template B", and
"license key "BBBB-BBBB-BBBB-BBBB", multi-tenant coexistence
determination information "coexistence allowed", expiration date
"no limit" and effective number "no limit"".
[0248] Next, the storage unit stores the registered to-be-used
template information in the to-be-used template information storage
table 521 (Step S2105). At this time, the storage unit 501 stores
the tenant name and the template name in the form of reference to
the tenant information storage table 516 and the template
information storage table 515, respectively.
[0249] The storage unit also stores the registered license
information in the license information storage table 522 (Step
S2106). At this time, the storage unit 501 stores the tenant name
and the template name in the form of reference to the to-be-used
template information storage table 521.
[0250] Here, examples of structures of the to-be-used template
information storage table 521 and the license information storage
table 522 as of after Step S2106 are shown in FIG. 22 and FIG. 23,
respectively.
[0251] Next, the tenant registration unit 203 refers to the
to-be-used connection broker information storage table 518 to
extract a connection broker name tied with the tenant name "tenant
A" (Step S2107). As a result, the connection broker names
"connection broker A", "connection broker B", "connection broker C"
and "connection broker E" are extracted.
[0252] Next, the tenant registration unit 203 refers to the
directory information storage table 514 to extract a directory path
tied with any of the connection broker names "connection broker A",
"connection broker B", "connection broker C" and "connection broker
E" (Step S2108). As a result, directory information whose directory
path is any of "o=tenant-a, c=jp", "ou=sales, o=tenant-a, c=jp",
"cn=user-a, ou=sales, o=tenant-a, c=jp", "o=tenant-b, c=jp",
"ou=sales, o=tenant-b, c=jp", and "cn=user-b, ou=sales, o=tenant-b,
c=jp".
[0253] Next, the tenant registration unit 203 presents the
extracted directory path to the system manager (Step S2109). It is
also possible to extract information other than a directory path
and present the same to the system manager at Step S2108.
[0254] Here, back to FIG. 13, subsequently when a directory path
indicating a route of a directory tree at which domain information
of a user who is allowed to use the virtual machine 331 in the
tenant 400 is registered is selected by the user from the presented
directory paths (Step S1311) and the domain information is input by
the system manager (Step S1312), the tenant registration unit 203
registers a tenant name of the tenant A, the selected directory
path and the input domain information so as to be correlated with
each other as tenant route information at the management data base
500 (Step S1313).
[0255] Assume here that the directory path selected by the system
manager is "ou=sales, o=tenant-a, c=jp".
[0256] Also assume that the domain information input by the system
manager is "domain name "tenant-a-sales", and domain authentication
information is "UserName: Administrator, Password:
AdminPasswd"".
[0257] Accordingly, the registered tenant route information will be
""tenant A", "ou=sales, o=tenant-a, c=jp", "tenant-a-sales", and
"UserName: Administrator, Password: AdminPasswd"".
[0258] Next, the storage unit 501 stores the tenant route
information in the tenant route information storage table 519 (Step
S1314). At this time, the storage unit 501 stores the tenant name
and the directory path in the form of reference to the tenant
information storage table 516 and the directory information storage
table 514, respectively.
[0259] Shown here in FIG. 24 is an example of a structure of the
tenant route information storage table 519 as of after Step
S1314.
(Description of Operation of Requesting Virtual Machine
Creation)
[0260] Next, detailed description will be made of operation of
requesting virtual machine creation executed by the tenant terminal
410 of the tenant 400 with reference to the drawings.
[0261] Description will be made assuming that each table of the
table group 502 of the management data base 500 shows a state of
the structure examples shown in FIG. 6 through FIG. 8, FIG. 10
through FIG. 12, FIG. 16, FIG. 18, FIG. 20, and FIG. 22 through
FIG. 25.
[0262] FIG. 26 is a flow chart showing operation of requesting
virtual machine creation according to the present exemplary
embodiment.
[0263] When virtual machine creation requesting is started by
operation by a tenant user at the tenant terminal 410 of the tenant
400 (tenant A), first, the virtual machine creation requesting unit
411 refers to the to-be-used data center information storage table
517 to extract the data center 300 usable by the tenant A (data
center name tied with the tenant name "tenant A") (Step S2601). As
a result, the data center names "data center A" and "data center B"
are extracted.
[0264] While the present exemplary embodiment is premised on that
it is known which tenant 400 a tenant user uses, processing may be
added of separately managing an account of the tenant 400, an
account of the tenant terminal 410 or the like and determining a
tenant based on the account or the like.
[0265] Next, the virtual machine creation requesting unit 411
presents the extracted data center names "data center A" and "data
center B" to the tenant user (Step S2602). It is also possible to
extract information other than the data center name together and
present the same to the system manager at Step S2601.
[0266] As a method of the presentation, it can be realized by
presentation by a display, for example. This is also the case in
the following.
[0267] Next, when the data center 300 in which the virtual machine
331 of the tenant A is created is selected by the tenant user from
the presented data center names "data center A" and "data center B"
(Step S2603), the virtual machine creation requesting unit 411
presents the template 332 usable in creating the virtual machine
331 of the tenant A to the tenant user (Step S2604).
[0268] Here, detailed operation of Steps S2603 and S2604 will be
described with reference to the flow chart of FIG. 27.
[0269] With reference to FIG. 27, first, when the tenant user
selects the data center 300 in which the virtual machine 331 of the
tenant A is created from the presented data center names "data
center A" and "data center B" (Step S2701), the virtual machine
creation requesting unit 411 refers to the manager information
storage table 511 to extract a manager name tied with the data
center name of the selected data center 300 (Step S2702).
[0270] Assume here that the data center selected by the tenant user
is the "data center A". Accordingly, the manager names "manager A"
and "manager B" will be extracted.
[0271] Next, the virtual machine creation requesting unit 411
refers to the connection broker information storage table 512 to
extract the connection broker names tied with the manager names
"manager A" and "manager B" (Step S2703). As a result, the
connection broker names "connection broker A", "connection broker
B", "connection broker C" and "connection broker D" are
extracted.
[0272] Next, the virtual machine creation requesting unit 411
refers to the to-be-used connection broker information 218 to
extract a connection broker name of a connection broker useable by
the tenant A (connection broker name tied with the tenant name
"tenant A") (Step S2704). As a result, the connection broker names
"connection broker A", "connection broker B", "connection broker C"
and "connection broker E" are extracted.
[0273] Next, the virtual machine creation requesting unit 411
refers to the connection broker information storage table 512 to
extract a manager name tied with any of the connection broker names
"connection broker A", "connection broker B" and "connection broker
C" extracted at both of Steps S2703 and S2704 (Step S2705). As a
result, the manager names "manager A" and "manager B" are
extracted.
[0274] Next, the virtual machine creation requesting unit 411
refers to the hypervisor information storage table 513 to extract a
hypervisor name tied with any of the manager names "manager A" and
"manager B" (Step S2706). As a result, the hypervisor names
"hypervisor A", "hypervisor B" and "hypervisor C" are
extracted.
[0275] Next, the virtual machine creation requesting unit 411
refers to the to-be-used hypervisor information storage table 520
to extract a hypervisor name of a hypervisor usable by the tenant A
(hypervisor name tied with the tenant name "tenant A") (Step
S2707). As a result, the hypervisor names "hypervisor A",
"hypervisor C" and "hypervisor E" are extracted.
[0276] Next, the virtual machine creation requesting unit 411
refers to the template information storage table 515 to extract a
template name tied with any of the hypervisor names "hypervisor A"
and "hypervisor C" extracted at both of Steps S2706 and S2707 (Step
S2708). As a result, the template names "template A", "template B",
"template C" and "template D" are extracted.
[0277] Next, the virtual machine creation requesting unit 411
refers to the usable template information storage table 521 to
extract a template name of a template usable by the tenant A
(template name tied with the tenant name "tenant A") (Step S2709).
As a result, the template names "template A" and "template C" are
extracted.
[0278] Next, the virtual machine creation requesting unit 411
presents the template names "template A" and "template B" extracted
at both Steps S2708 and S2709 to the tenant user (Step S2710). At
this time, not only a template name but also other information may
be added and presented by referring to the template information
storage table 205.
[0279] Here, back to FIG. 26, subsequently when the template 332
for use in creating the virtual machine 331 is selected by the
tenant user from the presented template names "template A" and
"template B" (Step S2605), the virtual machine creation requesting
unit 411 presents a license usable in creating the virtual machine
331 of the tenant A to the tenant user (Step S2606).
[0280] Here, detailed operation of Steps S2605 and S2606 will be
described with reference to the flow chart of FIG. 28.
[0281] With reference to FIG. 28, first, when the tenant user
selects the template 332 for use in creating the virtual machine
331 from the presented template names "template A" and "template B"
(Step S2801), the virtual machine creation requesting unit 411
refers to the to-be-used template information storage table 521 to
extract a template name ("template name" tied with the tenant name
"tenant A") of the template 332 usable by the tenant A (to-be-used
template) (Step S2802). As a result, template names "template A"
and "template B" are extracted.
[0282] Next, the virtual machine creation requesting unit 411
refers to the license information storage table 522 to extract a
license tied with a to-be-used template of the tenant A (license
whose tenant name is "tenant A" and whose template name is
"template A" or "template B") (Step S2803). As a result, a license
with a license key "AAAA-AAAA-AAAA-AAAA", multi-tenant coexistence
determination information "coexistence not allowed", expiration
date "no limit" and effective number "100" is extracted.
[0283] Next, the virtual machine creation requesting unit 411
presents the extracted license to the tenant user (Step S2804). As
a result, the license is presented whose "license key is
"AAAA-AAAA-AAAA-AAAA", multi-tenant coexistence determination
information is "coexistence not allowed", expiration date is "no
limit", and effective number is "100"".
[0284] In the above-described license extraction processing, it is
also possible to exclude a license whose number of references from
the virtual machine 311 is not less than an effective number of the
license from extraction targets. This enables the effective number
of licenses to be checked.
[0285] Here, back to FIG. 26, subsequently when a license for use
in creating the virtual machine 331 is selected by the tenant user
from the presented licenses (Step S2607), the virtual machine
creation requesting unit 411 presents a domain usable by the tenant
A to the tenant user (Step S2608).
[0286] Here, detailed operation of Steps S2607 and S2608 will be
described with reference to the flow chart of FIG. 29.
[0287] With reference to FIG. 29, first, when the tenant user
selects a license for use in creating the virtual machine 331 from
the presented licenses (Step S2901), the virtual machine creation
requesting unit 411 refers to the tenant route information storage
table 519 to extract tenant route information (domain) of the
tenant A (Step S2902).
[0288] The license selected by the tenant user is here assumed to
have a license key "AAAA-AAAA-AAAA-AAAA", multi-tenant coexistence
determination information "coexistence not allowed", expiration
date "no limit", and effective number "100". The virtual machine
creation requesting unit 411 extracts a directory path, a domain
name and domain authentication information tied with the tenant
name "tenant A" as a domain.
[0289] As a result, extracted is "directory path "ou=sales,
o=tenant-a, c=jp", domain name "tenant-a-sales", and domain
authentication information "UserName: Administrator, Password:
AdminPasswd"".
[0290] Next, the virtual machine creation requesting unit 411
presents the domain to the tenant user (Step S2903).
[0291] Here, back to FIG. 26, subsequently when a domain in which
the virtual machine 331 of the tenant A is to participate is
selected by the tenant user (Step S2609), the virtual machine
creation requesting unit 411 creates a virtual machine creation
request including the data center 300, the template 332, the
license and the domain already selected by the tenant user as
requirement information (Step S2610).
[0292] Assume here that presented as a domain is ""ou=sales,
o=tenant-a, c=jp", "tenant-a-sales", and "UserName: Administrator,
Password: AdminPasswd"" and selected by the tenant user is
""ou=sales, o=tenant-a, c=jp", "tenant-a-sales", and "UserName:
Administrator, Password: AdminPasswd"".
[0293] In other words, the virtual machine creation request made at
Step S2610 includes, as requirement information, "data center A",
"template A", "license (license key) "AAAA-AAAA-AAAA-AAAA",
multi-tenant coexistence determination information "coexistence not
allowed", expiration date "no limit", effective number "100"" and
"domain (directory path "ou=sales, o=tenant-a, c=jp", domain name
"tenant-a-sales", domain authentication information "UserName:
Administrator, Password: AdminPasswd")".
[0294] Although in the present exemplary embodiment, a data center
name and a template name are used as requirement information of the
data center 300 and the template 332, any information, not limited
to them, can be used that enables unitary identification of the
data center 300 and the template 332.
[0295] Next, the virtual machine creation requesting unit 411 sends
the virtual machine creation request to the virtual machine
creation management unit 204 (Step S2611).
[0296] The virtual machine creation request may include not only
the above-described requirement information but also a machine name
of a virtual machine, an initial password or the like designated by
a tenant user, for example.
(Description of Operation of Creating Virtual Machine)
[0297] Next, detailed description will be made of operation of
creating a virtual machine with reference to the drawings.
[0298] Description will be made assuming that each table of the
table group 502 of the management data base 500 shows a state of
the structure examples illustrated in FIG. 6 through FIG. 8, FIG.
10 through FIG. 12, FIG. 16, FIG. 18, FIG. 20, and FIG. 22 through
FIG. 25.
[0299] Also assume that the virtual machine creation management
unit 204 has already received a virtual machine creation request
from the virtual machine creation requesting unit 411 of the tenant
A.
[0300] FIG. 30 is a flow chart showing operation of requesting
execution of virtual machine creation according to the present
exemplary embodiment.
[0301] First, when a request for execution of virtual machine
creation of the tenant A is made by the system manager, the virtual
machine creation management unit 204 refers to requirement
information of the data center 300 in the virtual machine creation
request (Step S3001). As a result, the data center name "data
center A" is referred to.
[0302] Here, while in the present exemplary embodiment, the
processing of the above-described Step S3001 is started with an
instruction from the system manager as trigger, the processing can
be started automatically. For example, it is possible to
automatically execute processing in the order of reception of a
virtual machine creation request from the virtual machine creation
requesting unit 411 or with "desired completion time and date"
designated by the tenant user added to requirement information of
the virtual machine creation request, automatically execute the
processing in order starting with the latest "desired completion
time and date".
[0303] Next, the virtual machine creation management unit 204
refers to the manager information storage table 511 to extract a
manager name tied with the data center name "data center A" (Step
S3002). As a result, the manager names "manager A" and "manager B"
are extracted.
[0304] Next, the virtual machine creation management unit 204
refers to the connection broker storage table 512 to extract a
connection broker name tied with the extracted manager names
"manager A" and "manager B" (Step S3003). As a result, the
connection broker names "connection broker A", "connection broker
B", "connection broker C" and "connection broker D" are
extracted.
[0305] Next, the virtual machine creation management unit 204
refers to the to-be-used connection broker information reference
table 518 to extract connection broker information tied with the
tenant name "tenant A" (Step S3004). As a result, the connection
broker names "connection broker A", "connection broker B",
"connection broker C" and "connection broker E" are extracted.
[0306] Next, the virtual machine creation management unit 204
extracts connection broker names extracted at both of Steps S3003
and S3004 (Step S3005). As a result, the connection broker names
"connection broker A", "connection broker B" and "connection broker
C" are extracted.
[0307] Next, the virtual machine creation management unit 204 again
refers to the connection broker storage table 512 to extract
manager names tied with the extracted connection broker names
"connection broker A", "connection broker B" and "connection broker
C" (Step S3006). As a result, the manager names "manager A" and
"manager B" are extracted.
[0308] Next, the virtual machine creation management unit 204
refers to the hypervisor information storage table 513 to extract
hypervisor names tied with the manager names "manager A" and
"manager B" (Step S3007). As a result, the hypervisor names
"hypervisor A", "hypervisor B", "hypervisor C" and "hypervisor D"
are extracted.
[0309] Next, the virtual machine creation management unit 204
refers to the to-be-used hypervisor information storage table 520
to extract hypervisor names tied with the tenant name "tenant A"
(Step S3008). As a result, the hypervisor names "hypervisor A",
"hypervisor C" and "hypervisor E" are extracted.
[0310] Next, the virtual machine creation management unit 204
extracts the hypervisor names extracted at both Steps S3007 and
S3008 (Step S3009). As a result, the hypervisor names "hypervisor
A" and "hypervisor C" are extracted.
[0311] Next, the virtual machine creation management unit 204
extracts the hypervisor 330 which is allowed to use the "template
A" included in requirement information among the hypervisor A and
the hypervisor C extracted at Step S3009 (Step S3010).
[0312] More specifically, the virtual machine creation management
unit 204 refers to the template information storage table 515 to
confirm that the hypervisor names "hypervisor A" and "hypervisor C"
are tied with the template name "template A".
[0313] As a result, since both of the hypervisor names "hypervisor
A" and "hypervisor C" are tied with the template name "template A",
both the hypervisor A and the hypervisor C are extracted as the
hypervisor 330 that is allowed to use the template A.
[0314] Next, the virtual machine creation management unit 204
extracts the hypervisor 330 in which the virtual machine 311 of the
tenant A can be created from the hypervisors 330 extracted at Step
S3010 (Step S3011).
[0315] Here, detailed processing of Step S3011 will be described
with reference to the flow chart of FIG. 31.
[0316] With reference to FIG. 31, first, the virtual machine
creation management unit 204 determines whether the extracted
hypervisor 330 is referred to by the virtual machine 311 (Step
S3101).
[0317] When the hypervisor 330 is not referred to by the virtual
machine 311 ("NO" at Step S3101), the virtual machine creation
management unit 204 determines that the virtual machine 311 can be
created in the hypervisor 330 (Step S3102).
[0318] When the hypervisor 330 is referred to by the virtual
machine 311 ("YES" at Step S3101), the virtual machine creation
management unit 204 determines whether the virtual machine 311
referring to the hypervisor 330 is a virtual machine used by the
tenant A (Step S3103).
[0319] When determining that the virtual machine 311 is the virtual
machine 331 used by the tenant A ("YES" at Step S3103), the virtual
machine creation management unit 204 determines that the virtual
machine 311 can be created in the hypervisor 330 (Step S3102).
[0320] When determining that the virtual machine 311 is not the
virtual machine used by the tenant A ("NO" at Step S3103), the
virtual machine creation management unit 204 then refers to the
multi-tenant coexistence determination information of a license as
requirement information to verify whether the virtual machine 331
to be created can coexist with the virtual machine 331 of other
tenant 400 on the same hypervisor 330 (Step S3104).
[0321] When the multi-tenant coexistence determination information
indicates "coexistence" ("YES" at Step S3104), the virtual machine
creation management unit 204 determines that the virtual machine
311 can be created in the hypervisor 330 (Step S3102).
[0322] When the multi-tenant coexistence determination information
indicates "coexistence not allowed" ("NO" at Step S3104), the
virtual machine creation management unit 204 determines that the
virtual machine 311 cannot be created in the hypervisor 330 (Step
S3105).
[0323] The virtual machine creation management unit 204 executes
the processing of Steps S3101 through S3105 with respect to all the
hypervisors 330 extracted at the above-described Step S3011 (Step
S3106).
[0324] After determining whether the virtual machine 311 can be
created with respect to all the hypervisors 330 extracted at Step
S3011 ("YES" at Step S3106), the virtual machine creation
management unit 204 subsequently extracts the hypervisor 330 in
which the virtual machine 311 can be created among the hypervisors
330 extracted at Step S3011 (Step S3107).
[0325] Assume here that all of the virtual machine A, the virtual
machine B and the virtual machine C are virtual machines of the
tenant 400 other than the tenant A.
[0326] As a result, since at Steps S3101 through S3107, the
hypervisor A is referred to by other virtual machines A, B and C,
and the virtual machines A, B and C are used by the tenant 400
other than the tenant A (the tenant terminal 410 of the tenant
400), it is not extracted. On the other hand, since the virtual
machine 311 to be referred to fails to exist in the hypervisor C,
the hypervisor C is resultantly extracted at Step S3107.
[0327] Here, back to FIG. 30, the virtual machine creation
management unit 204 subsequently presents the hypervisor C to the
system manager (Step S3012).
[0328] Next, when the hypervisor 330 in which the virtual machine
311 will be created is selected by the system manager from the
presented hypervisors 330 (Step S3013), the virtual machine
creation management unit 204 sends a request for execution of
creation of the virtual machine 331 in the selected hypervisor 330
to the data center control unit 202 (Step S3014).
[0329] Here, while the system manager selects the hypervisor 330 as
a creation destination at Step S3014, the selection can be realized
automatically.
[0330] Possible is, for example, automatically selecting the
hypervisor 330 whose number of already created virtual machines 331
is the smallest or automatically selecting the hypervisor 330 whose
server specification (CPU) distribution per one virtual machine 331
is the largest.
[0331] When the hypervisor C is here selected by the system
manager, the virtual machine creation management unit 204 sends a
hypervisor C virtual machine creation execution request to the data
center control unit 202.
[0332] The virtual machine creation execution request includes at
least a creation destination hypervisor, a tenant to be used, a
template to be used, a license to be used and a participating
domain as requirement information.
[0333] More specifically, the virtual machine creation execution
request sent at Step S3021 includes, as requirement information,
"creation destination hypervisor "hypervisor C"", "a tenant to be
used "tenant A"", "a template to be used "template A"", "a license
to be used "license key "AAAA-AAAA-AAAA-AAAA", multi-tenant
coexistence determination information "coexistence not allowed",
expiration date "no limit", effective number "100"", "participating
domain "path "ou=sales, o=tenant-a, c=jp", domain name
"tenant-a-sales", and domain authentication information "UserName:
Administrator, Password: AdminPasswd"".
[0334] Next, the data center control unit 204 having received the
virtual machine creation execution request refers to the hypervisor
included in the requirement information of the virtual machine
creation execution request (Step S3015) and then extracts a manager
name tied with the hypervisor name from the hypervisor information
storage table 513 (Step S3016).
[0335] More specifically, the data center control unit 202 extracts
the manager name "manager B" tied with the hypervisor name
"hypervisor C". In other words, the manager B which manages the
hypervisor C is extracted.
[0336] Next, the data center control unit 202 requests the manager
B to create the virtual machine 331 (Step S3017).
[0337] More specifically, the data center control unit 202 sends
the virtual machine creation execution request received from the
virtual machine creation management unit 204 to the manager B.
[0338] Next, when the virtual machine 331 is created, the data
center control unit 202 registers the virtual machine information
of the created virtual machine 331 at the management data base 500
(Step S3018).
[0339] The virtual machine information includes at least a tenant
name "tenant A", a hypervisor name "hypervisor C", a license key
""AAAA-AAAA-AAAA-AAAA", multi-tenant coexistence determination
information "coexistence not allowed", expiration date "no limit"
and effective number "100"".
[0340] Next, the storage unit 501 stores the registered virtual
machine information in the virtual machine information storage
table 523 (Step S3019).
[0341] At this time, the storage unit 501 stores the tenant name,
the hypervisor name, and the license key, the multi-tenant
coexistence determination information, the expiration date and the
effective number in the form of reference to the tenant information
storage table 516, the hypervisor information storage table 513 and
the license information storage table 522, respectively.
(Effects of the First Exemplary Embodiment)
[0342] Next, effects of the present exemplary embodiment will be
described.
[0343] Accordingly to the present exemplary embodiment, even when a
hypervisor is shared by a plurality of tenants, creation
destination hypervisors can be automatically narrowed down
according to a license for use in creating a virtual machine. This
prevents a virtual machine created by a license which fails to
allow coexistence with a virtual machine of other tenant from
existing on the same hypervisor as that of the virtual machine of
other tenant.
[0344] The present exemplary embodiment also enables, when a tenant
user requests virtual machine creation, requirement information to
be narrowed down and presented to the tenant user based on resource
information of a tenant already registered. This allows the tenant
user to request creation of a virtual machine without taking
physical location of other components than a data center into
consideration.
Second Exemplary Embodiment
[0345] Next, detailed description will be made of a second
exemplary embodiment of the present invention with reference to the
drawings. In the following drawings, no description will be made of
structures of components not related to the gist of the present
invention and no illustration will be made thereof either.
[0346] The present exemplary embodiment has the following features
in addition to the first exemplary embodiment.
[0347] In the present exemplary embodiment, the to-be-used
hypervisor information includes hypervisor ownership, which is
stored in the to-be-used hypervisor information storage table
520.
[0348] The hypervisor ownership has a value "borrow" or "own".
"Borrow" represents that the tenant 400 fails to own the hypervisor
330 and borrows the same. "Own" represents that the tenant 400 owns
the hypervisor 330.
[0349] Also in the present exemplary embodiment, the license
includes hypervisor owner requirements, which are stored in the
license information storage table 522.
[0350] The hypervisor owner requirements have values "borrow only",
"own only" and "both allowed". "Borrow only" represents that the
license can be used only when creating the virtual machine 331 in
the borrowed hypervisor 330. "Own only" represents that the license
can be used only when creating the virtual machine 331 in the owned
hypervisor 330. "Both allowed" represents that the license can be
used without being affected by hypervisor ownership.
[0351] Since other structures than those described above are the
same as those of the first exemplary embodiment, no details will be
described thereof.
(Description of Operation of the Second Exemplary Embodiment)
[0352] Next, operation of the DaaS system 100 according to the
present exemplary embodiment will be detailed with reference to the
drawings.
[0353] Description will be made of operation of registering
resource information of the tenant 400 which uses the DaaS system
100 according to the present exemplary embodiment with reference to
the drawings. Since operation of registering and operation of
collecting and registering system structure information of the data
center 300 are the same as those of the first exemplary embodiment,
no details will be made thereof.
(Description of Operation of Registering Resource Information of
the Tenant 400)
[0354] Operation of registering resource information of the tenant
400 which uses the DaaS system 100 according to the present
exemplary embodiment will be described with reference to the
drawings. In the following, no description will be made of a part
which executes the same operation as that of the first exemplary
embodiment.
[0355] FIG. 32 is a flow chart showing operation of the tenant
registration unit 203 according to the present exemplary embodiment
to present the hypervisor 330 which can be used by the tenant A to
the system manager. Shown in FIG. 32 is a result obtained by adding
the operation of the present exemplary embodiment to the operation
of the first exemplary embodiment shown in FIG. 19.
[0356] With reference to FIG. 32, in the present exemplary
embodiment, the system manager selects the hypervisor 330 to be
used by the tenant A based on the presented hypervisor information
(Step S1901) and the system manager further inputs hypervisor
ownership information set at the selected hypervisor 330 (Step
S1907), and the tenant registration unit 203 registers the tenant
name of the tenant A, the hypervisor name of the selected
hypervisor 330 and the input hypervisor ownership so as to be
correlated with each other as the to-be-used hypervisor information
at the management data base 500 (Step S1902').
[0357] Assume here that the hypervisors 330 selected by the system
manager are the hypervisors A, C and E.
[0358] Also assume that the hypervisor ownership information input
by the system manager is "own" for the hypervisors A and C and
"borrow" for the hypervisor E.
[0359] The registered to-be-used hypervisor information are
accordingly "tenant A", "hypervisor A" and "own", "tenant A",
"hypervisor C" and "own", and "tenant A", "hypervisor E" and
"borrow".
[0360] Next, the storage unit 501 stores the to-be-used hypervisor
information in the to-be-used hypervisor information storage table
520 (Step S1903). At this time, the storage unit 501 stores the
tenant name and the hypervisor name in the form of reference to the
tenant information storage table 516 and the hypervisor information
storage table 513, respectively.
[0361] Shown here in FIG. 33 is an example of a structure of the
to-be-used hypervisor information storage table 520 as of after
Step S1903.
[0362] Since the processing to follow is the same as that of FIG.
19, no detailed description will be made thereof.
[0363] Next, FIG. 34 is a flow chart showing operation of the
tenant registration unit 203 according to the present exemplary
embodiment to present the directory information of the directory in
which domain information of the tenant user of the tenant 400 can
be registered to the system manager. Shown in FIG. 34 is a result
obtained by adding the operation of the present exemplary
embodiment to the operation of the first exemplary embodiment shown
in FIG. 21.
[0364] In the present exemplary embodiment, when the system manager
selects the template 332 to be used by the hypervisor 330 used by
the tenant A based on the presented template information (Step
S2101) and the system manager further inputs a license including
hypervisor owner requirement which is used by the selected template
332 (Step S2102'), the tenant registration unit 203 registers the
tenant name of the tenant A and the template name of the selected
template 332 so as to be correlated with each other as the
to-be-used template information at the management data base 500
(Step S2103), as well as registering the tenant name of the tenant
A and the input license so as to be correlated with each other as
license information at the management data base 500 (Step
S2104').
[0365] Assume here that the templates 332 selected by the system
manager are the templates A and B. The registered to-be-used
template information will be accordingly "tenant A" and "template
A", and "tenant A" and "template B".
[0366] Also assume that a license used by the template A input by
the system manager is "license key "AAAA-AAAA-AAAA-AAAA",
multi-tenant coexistence determination information "coexistence not
allowed", expiration date "no limit", effective number "100" and
hypervisor owner requirement "own only"" and a license used by the
template B is "license key "BBBB-BBBB-BBBB-BBBB", multi-tenant
coexistence determination information "coexistence allowed",
expiration date "no limit", effective number "no limit" and
hypervisor owner requirement "both allowed"".
[0367] The registered license information will be "tenant A" and
"template A", and "license key "AAAA-AAAA-AAAA-AAAA", multi-tenant
coexistence determination information "coexistence not allowed",
expiration date "no limit", effective number "100" and hypervisor
owner requirement "own only"", and "tenant A" and "template B", and
"license key "BBBB-BBBB-BBBB-BBBB", multi-tenant coexistence
determination information "coexistence allowed", expiration date
"no limit", effective number "no limit" and hypervisor owner
requirement "both allowed"".
[0368] Shown here in FIG. 35 is an example of a structure of the
license information storage table 522 as of after Step S2106
according to the present exemplary embodiment.
[0369] Since the processing to follow is the same as that of FIG.
21, no detailed description will be made thereof.
(Description of Operation of Requesting Virtual Machine
Creation)
[0370] Next, operation of the tenant terminal 410 of the tenant 400
to request virtual machine creation according to the present
exemplary embodiment will be detailed with reference to the
drawings. In the following, no description will be made of a part
which executes the same operation as that of the first exemplary
embodiment.
[0371] FIG. 36 is a flow chart showing operation of the virtual
machine creation requesting unit 411 according to the present
exemplary embodiment to present a license usable in creating the
virtual machine 331 of the tenant A to the tenant user. Shown in
FIG. 36 is a result obtained by adding the operation of the present
exemplary embodiment to the operation of the first exemplary
embodiment shown in FIG. 28.
[0372] With reference to FIG. 36, in the present exemplary
embodiment, the virtual machine creation requesting unit 411 refers
to the license information storage table 522 to extract a license
(license key, multi-tenant coexistence determination information,
expiration date, effective number and hypervisor owner
requirements) tied with the extracted template names "template A"
and "template B" (Step S2803').
[0373] Next, the virtual machine creation requesting unit 411
refers to the to-be-used hypervisor information storage table 520
to extract ownership information of the hypervisors A, C and E
extracted at Step S2707 shown in FIG. 27.
[0374] As a result, extracted are ownership information "own" of
the hypervisor A, ownership information "own" of the hypervisor C
and ownership information "borrow" of the hypervisor E.
[0375] Next, the virtual machine creation requesting unit 411
compares the hypervisor ownerships of the hypervisors A, C and E
extracted at Step S2805 and the hypervisor owner requirements of
the license extracted at Step S2803', confirms that the ownership
information of each hypervisor satisfies hypervisor owner
requirements of the license and extracts a license including
hypervisor owner requirements meeting the extracted hypervisor
ownerships of the hypervisors A, C and E (Step S2806).
[0376] More specifically, since the hypervisor owner requirement of
the selected license is "own only", the hypervisors A and C whose
hypervisor ownership is "own" satisfy the requirements and are
extracted.
[0377] Next, the virtual machine creation requesting unit 411
presents the extracted license to the tenant user (Step S2804).
(Description of Operation of Creating Virtual Machine)
[0378] Next, operation of the virtual machine creation according to
the present exemplary embodiment will be detailed with reference to
the drawings. In the following, no description will be made of a
part which executes the same operation as that of the first
exemplary embodiment.
[0379] FIG. 37 is a flow chart showing operation of the virtual
machine creation according to the present exemplary embodiment.
Shown in FIG. 37 is a result obtained by adding the operation of
the present exemplary embodiment to the operation of the first
exemplary embodiment shown in FIG. 30.
[0380] In the present exemplary embodiment, after Step S3009, the
virtual machine creation management unit 204 determines whether
hypervisor ownership information of the hypervisors A and C
extracted at Step S3009 satisfies hypervisor owner requirements of
a license included in requirement information and extracts the
hypervisor 330 which-satisfies the hypervisor owner requirements
(Step S3020).
[0381] Since the hypervisor owner requirement of the license
included in the requirement information is "own only" and the
hypervisor information of the hypervisors A and C is "own", both
the hypervisors A and C satisfy the hypervisor owner requirements,
so that they are extracted.
[0382] Since the processing to follow is the same as that of FIG.
30, no detailed description will be made thereof.
(Effects of the Second Exemplary Embodiment)
[0383] The present exemplary embodiment enables further
narrowing-down of hypervisor information than by the first
exemplary embodiment.
[0384] The reason is that by adding ownership information of the
hypervisor 330 to be used and adding hypervisor owner requirements
to a license, it is possible to automatically exclude the
hypervisor 330 failing to satisfy the hypervisor owner requirements
of the license from extraction targets.
[0385] Next, an example of a hardware structure of the management
server 200 according to the present invention will be described
with reference to FIG. 38. FIG. 38 is a block diagram showing an
example of a hardware structure of the management server 200.
[0386] With reference to FIG. 38, the management server 200, which
has the same hardware structure as that of a common computer
device, comprises a CPU (Central Processing Unit) 801, a main
storage unit 802 formed of a memory such as a RAM (Random Access
Memory) for use as a data working region or a data temporary saving
region, a communication unit 803 which transmits and receives data
through a network, an input/output interface unit 804 connected to
an input device 805, an output device 806 and a storage device 807
to transmit and receive data, and a system bus 808 which connects
the above-described respective components with each other. The
storage device 807 is realized by, for example, a hard disk device
formed of a non-volatile memory such as a ROM (Read Only Memory), a
magnetic disk or a semiconductor memory.
[0387] The data center registration unit 201, the data center
control unit 202, the tenant registration unit 203 and the virtual
machine creation management unit 204 of the management server 200
according to the present invention have their operation realized
not only in hardware by mounting a circuit part which is a hardware
part such as an LSI (Large Scale Integration) with a program
incorporated but also in software by storing a program which
provides the functions in the storage device 807, loading the
program into the main storage unit 802 and executing the same by
the CPU 801.
[0388] The tenant terminal 410 also has such a hardware structure
as described above and each function that the tenant terminal 410
has can be realized in hardware or software.
[0389] Although the present invention has been described with
respect to the preferred exemplary embodiments in the foregoing,
the present invention is not necessarily limited to the
above-described exemplary embodiments and can be implemented in
various modifications within the scope of its technical idea.
[0390] An arbitrary combination of the foregoing components and
conversion of representation of the present invention among a
method, a device, a system, a recording medium, a computer program
and the like are also effective as a mode of the present
invention.
[0391] The respective components of the present invention need not
exist independently, and the plurality of the components may be
formed as one member, one component may be formed of a plurality of
members, a certain component may be a part of other component, a
part of a certain component and a part of other component may
overlap with each other or the like.
[0392] In addition, although the method and the computer program of
the present invention have a plurality of procedures recited in
order, the order of recitation does not limit the order of
execution of the plurality of procedures. Accordingly, when
executing the method and the computer program of the present
invention, the order of the plurality of procedures can be changed
within the range not hindering the contents.
[0393] Moreover, the plurality of procedures of the method and the
computer program of the present invention are not limited to
execution at different timing with each other. Therefore, during
execution of a certain procedure, other procedure might occur, a
part or all of execution timing of a certain procedure and
execution timing of other procedure might overlap with each other,
or the like.
[0394] The whole or part of the exemplary embodiments disclosed
above can be described as, but not limited to, the following
supplementary notes.
(Supplementary note 1) A thin client system, comprising:
[0395] at least one tenant including at least one tenant
terminal;
[0396] a management data base which stores resource information of
the tenant,
[0397] at least one data center in which a virtual machine to be
used by the tenant operates; and
[0398] a management server including a virtual machine creation
management unit which narrows down a hypervisor in which the
virtual machine can be created based on resource information of the
tenant stored in the management data base and a virtual machine
creation request including predetermined requirement information
for creating the virtual machine which is received from the tenant
terminal.
(Supplementary note 2) The thin client system according to
supplementary note 1, wherein
[0399] the tenant terminal comprises a virtual machine creation
requesting unit which makes the virtual machine creation request,
and wherein the virtual machine creation requesting unit includes,
in the requirement information of the virtual machine creation
request, a data center as a creation destination of the virtual
machine, a template for use in creating the virtual machine, a
license for use in creating the virtual machine and a domain of a
tenant user of the tenant, and
[0400] the virtual machine creation management unit of the
management server
[0401] extracts a data center which is a data center included in
the requirement information and usable by the tenant from the
management data base,
[0402] extracts a connection broker related to a manager related to
the extracted data center and usable by the tenant from the
management data base,
[0403] extracts the hypervisor related to a manager related to the
extracted connection broker and usable by the tenant from the
management data base, and
[0404] extracts the hypervisor included in the requirement
information and in which the virtual machine of the tenant can be
created from among the extracted hypervisors.
(Supplementary note 3) The thin client system according to
supplementary note 2, wherein the virtual machine creation
requesting unit of the tenant terminal
[0405] extracts the data center usable by the tenant from the
management data base,
[0406] extracts a template for use in creating the virtual machine
based on the data center selected as a creation destination of the
virtual machine from among the extracted data centers and the
resource information of the tenant,
[0407] extracts a license for use in creating the virtual machine
based on the extracted template and the resource information of the
tenant,
[0408] extracts a domain usable by the tenant based on the resource
information of the tenant, and
[0409] includes the domain selected as a domain to be used from
among the extracted domains, the extracted data center, the
extracted template, and the extracted license in the virtual
machine creation request.
(Supplementary note 4) The thin client system according to
supplementary note 2 or supplementary note 3, wherein
[0410] a license for use in creating the virtual machine includes
multi-tenant coexistence determination information indicating
whether the virtual machines of a plurality of the tenants are
allowed to coexist on the same hypervisor, and
[0411] the virtual machine creation management unit of the
management server
[0412] when the hypervisor is referred to by other virtual machine,
determines whether other the virtual machine is a virtual machine
to be used by the tenant,
[0413] when determination is made that the other virtual machine is
a virtual machine to be used by other tenant than the tenant,
verifies multi-tenant coexistence determination information of a
license for use in creating the virtual machine, and
[0414] when the multi-tenant coexistence determination information
is "coexistence not allowed", determines that the virtual machine
cannot be created in the hypervisor.
(Supplementary note 5) The thin client system according to any one
of supplementary note 2 through supplementary note 4, wherein
[0415] information of a license stored in the management data base
includes an effective number of licenses, and
[0416] the virtual machine creation requesting unit of the tenant
terminal includes a license whose number of references is less than
the effective number of licenses in the requirement
information.
(Supplementary note 6) The thin client system according to any of
supplementary note 1 through supplementary note 5, wherein the
management server comprises a data center control unit which
creates the virtual machine based on an instruction of the virtual
machine creation management unit, and wherein
[0417] based on a hypervisor narrowed down by the virtual machine
creation management unit and resource information of the tenant
received from the virtual machine creation management unit, the
data center control unit requests a manager related to the
narrowed-down hypervisor to create the virtual machine.
(Supplementary note 7) The thin client system according to
supplementary note 6, wherein
[0418] the management server includes a data center registration
unit which registers system structure information of the data
center, and
[0419] the data center control unit obtains manager information of
the data center, connection broker information, hypervisor
information, template information and directory information based
on a request from the data center registration unit.
(Supplementary note 8) The thin client system according to any of
supplementary note 2 through supplementary note 6, wherein
[0420] information of a license stored in the management data base
includes a hypervisor owner requirement,
[0421] information of a hypervisor stored in the management data
base includes a hypervisor ownership,
[0422] the virtual machine creation requesting unit of the tenant
terminal includes, in the virtual machine creation request, the
license including the hypervisor owner requirement meeting the
ownership of a hypervisor usable by the tenant, and
[0423] the virtual machine creation management unit extracts the
hypervisor satisfying the hypervisor owner requirement of the
requirement information.
(Supplementary note 9) A management server of a thin client system,
comprising:
[0424] a virtual machine creation Management unit which, based on
resource information of at least one tenant including at least one
tenant terminal stored in a management data base of the thin client
system and a virtual machine creation request including
predetermined requirement information for creating a virtual
machine to be used by the tenant on a data center of the thin
client system which is received from the tenant terminal, narrows
down a hypervisor in which the virtual machine can be created.
(Supplementary note 10) The management server according to
supplementary note 9, wherein the requirement information of the
virtual machine creation request from the tenant terminal includes
a data center as a creation destination of the virtual machine, a
template for use in creating the virtual machine, a license for use
in creating the virtual machine and a domain of a tenant user of
the tenant, and
[0425] the virtual machine creation management unit of the
management server
[0426] extracts a data center which is a data center included in
the requirement information and usable by the tenant from the
management data base,
[0427] extracts a connection broker related to a manager related to
the extracted data center and usable by the tenant from the
management data base,
[0428] extracts the hypervisor related to a manager related to the
extracted connection broker and usable by the tenant from the
management data base, and
[0429] extracts the hypervisor included in the requirement
information and in which the virtual machine of the tenant can be
created from among the extracted hypervisors.
(Supplementary note 11) The management server according to
supplementary note 10, wherein
[0430] a license for use in creating the virtual machine includes
multi-tenant coexistence determination information indicating
whether the virtual machines of a plurality of the tenants are
allowed to coexist on the same hypervisor, and
[0431] the virtual machine creation management unit of the
management server
[0432] when the hypervisor is referred to by other virtual machine,
determines whether other the virtual machine is a virtual machine
to be used by the tenant,
[0433] when determination is made that the other virtual machine is
a virtual machine to be used by other tenant than the tenant,
verifies multi-tenant coexistence determination information of a
license for use in creating the virtual machine, and
[0434] when the multi-tenant coexistence determination information
is "coexistence not allowed", determines that the virtual machine
cannot be created in the hypervisor.
(Supplementary note 12) The management server according to
supplementary note 10 or supplementary note 11, wherein
[0435] information of a license stored in the management data base
includes an effective number of licenses, and
[0436] the requirement information from the tenant terminal
includes a license whose number of references is less than the
effective number of licenses.
(Supplementary note 13) The management server according to any of
supplementary note 9 through supplementary note 12, further
comprises a data center control unit which creates the virtual
machine based on an instruction of the virtual machine creation
management unit, and wherein
[0437] based on a hypervisor narrowed down by the virtual machine
creation management unit and resource information of the tenant
received from the virtual machine creation management unit, the
data center control unit requests a manager related to the
narrowed-down hypervisor to create the virtual machine.
(Supplementary note 14) The management server according to
supplementary note 13, further comprises a data center registration
unit which registers system structure information of the data
center, and
[0438] the data center control unit obtains manager information of
the data center, connection broker information, hypervisor
information, template information and directory information based
on a request from the data center registration unit.
(Supplementary note 15) The management server according to any of
supplementary note 10 through supplementary note 14, wherein
[0439] information of a license stored in the management data base
includes a hypervisor owner requirement,
[0440] information of a hypervisor stored in the management data
base includes a hypervisor ownership,
[0441] the requirement information of the virtual machine creation
request includes the license including the hypervisor owner
requirement meeting the ownership of a hypervisor usable, by the
tenant, and
[0442] the virtual machine creation management unit extracts the
hypervisor satisfying the hypervisor owner requirement of the
requirement information.
(Supplementary note 16) A virtual machine creation management
method, comprising:
[0443] at a management server of a thin client system, a virtual
machine creation management step of, based on resource information
of at least one tenant including at least one tenant terminal
stored in a management data base of the thin client system and a
virtual machine creation request including predetermined
requirement information for creating a virtual machine to be used
by the tenant on a data center of the thin client system which is
received from the tenant terminal, narrowing down a hypervisor in
which the virtual machine can be created.
(Supplementary note 17) The virtual machine creation management
method according to supplementary note 16, wherein the requirement
information of the virtual machine creation request from the tenant
terminal includes a data center as a creation destination of the
virtual machine, a template for use in creating the virtual
machine, a license for use in creating the virtual machine and a
domain of a tenant user of the tenant, and
[0444] at the virtual machine creation management step,
[0445] extracts a data center which is a data center included in
the requirement information and usable by the tenant from the
management data base,
[0446] extracts a connection broker related to a manager related to
the extracted data center and usable by the tenant from the
management data base,
[0447] extracts the hypervisor related to a manager related to the
extracted connection broker and usable by the tenant from the
management data base, and
[0448] extracts the hypervisor included in the requirement
information and in which the virtual machine of the tenant can be
created from among the extracted hypervisors.
(Supplementary note 18) The virtual machine creation management
method according to supplementary note 17, wherein
[0449] a license for use in creating the virtual machine includes
multi-tenant coexistence determination information indicating
whether the virtual machines of a plurality of the tenants are
allowed to coexist on the same hypervisor, and
[0450] at the virtual machine creation management step,
[0451] when the hypervisor is referred to by other virtual machine,
determines whether other the virtual machine is a virtual machine
to be used by the tenant,
[0452] when determination is made that the other virtual machine is
a virtual machine to be used by other tenant than the tenant,
verifies multi-tenant coexistence determination information of a
license for use in creating the virtual machine, and
[0453] when the multi-tenant coexistence determination information
is "coexistence not allowed", determines that the virtual machine
cannot be created in the hypervisor.
(Supplementary note 19) The virtual machine creation management
method according to supplementary note 17 or supplementary note 18,
wherein
[0454] information of a license stored in the management data base
includes an effective number of licenses, and
[0455] the requirement information from the tenant terminal
includes a license whose number of references is less than the
effective number of licenses.
(Supplementary note 20) The virtual machine creation management
method according to any of supplementary note 16 through
supplementary note 19, further comprises a data center control step
of creating the virtual machine based on an instruction from the
virtual machine creation management step, and wherein
[0456] at the data center control step,
[0457] based on a hypervisor narrowed down by the virtual machine
creation management step and resource information of the tenant
received from the virtual machine creation management step,
requests a manager related to the narrowed-down hypervisor to
create the virtual machine.
(Supplementary note 21) The virtual machine creation management
method according to supplementary note 20, further comprises a data
center registration step of registering system structure
information of the data center, and
[0458] at the data center control step,
[0459] obtains manager information of the data center, connection
broker information, hypervisor information, template information
and directory information based on a request from the data center
registration step.
(Supplementary note 22) The virtual machine creation management
method according to any of supplementary note 17 through
supplementary note 21, wherein
[0460] information of a license stored in the management data base
includes a hypervisor owner requirement,
[0461] information of a hypervisor stored in the management data
base includes a hypervisor ownership,
[0462] the requirement information of the virtual machine creation
request includes the license including the hypervisor owner
requirement meeting the ownership of a hypervisor usable by the
tenant, and
[0463] at the virtual machine creation management step,
[0464] extracts the hypervisor satisfying the hypervisor owner
requirement of the requirement information.
(Supplementary note 23) A computer readable medium storing a
virtual machine creation management program executed on a
management server of a thin client system, wherein the program
causes the management server to execute the processing of:
[0465] a virtual machine creation management processing of, based
on resource information of at least one tenant including at least
one tenant terminal stored in a management data base of the thin
client system and a virtual machine creation request including
predetermined requirement information for creating a virtual
machine to be used by the tenant on a data center of the thin
client system which is received from the tenant terminal, narrowing
down a hypervisor in which the virtual machine can be created.
(Supplementary note 24) The computer readable medium according to
supplementary note 23, wherein the requirement information of the
virtual machine creation request from the tenant terminal includes
a data center as a creation destination of the virtual machine, a
template for use in creating the virtual machine, a license for use
in creating the virtual machine and a domain of a tenant user of
the tenant, and
[0466] at the virtual machine creation management processing,
[0467] extracts a data center which is a data center included in
the requirement information and usable by the tenant from the
management data base,
[0468] extracts a connection broker related to a manager related to
the extracted data center and usable by the tenant from the
management data base,
[0469] extracts the hypervisor related to a manager related to the
extracted connection broker and usable by the tenant from the
management data base, and
[0470] extracts the hypervisor included in the requirement
information and in which the virtual machine of the tenant can be
created from among the extracted hypervisors.
(Supplementary note 25) The computer readable medium according to
supplementary note 24, wherein
[0471] a license for use in creating the virtual machine includes
multi-tenant coexistence determination information indicating
whether the virtual machines of a plurality of the tenants are
allowed to coexist on the same hypervisor, and
[0472] at the virtual machine creation management processing,
[0473] when the hypervisor is referred to by other virtual machine,
determines whether other the virtual machine is a virtual machine
to be used by the tenant,
[0474] when determination is made that the other virtual machine is
a virtual machine to be used by other tenant than the tenant,
verifies multi-tenant coexistence determination information of a
license for use in creating the virtual machine, and
[0475] when the multi-tenant coexistence determination information
is "coexistence not allowed", determines that the virtual machine
cannot be created in the hypervisor.
(Supplementary note 26) The computer readable medium according to
supplementary note 24 or supplementary note 25, wherein
[0476] information of a license stored in the management data base
includes an effective number of licenses, and
[0477] the requirement information from the tenant terminal
includes a license whose number of references is less than the
effective number of licenses.
(Supplementary note 27) The computer readable medium according to
any of supplementary note 23 through supplementary note 26, further
comprises a data center control processing of creating the virtual
machine based on an instruction from the virtual machine creation
management processing, and wherein
[0478] at the data center control processing,
[0479] based on a hypervisor narrowed down by the virtual machine
creation Management processing and resource information of the
tenant received from the virtual machine creation management
processing, requests a manager related to the narrowed-down
hypervisor to create the virtual machine.
(Supplementary note 28) The computer readable medium according to
supplementary note 27, further comprises a data center registration
processing of registering system structure information of the data
center, and
[0480] at the data center control processing,
[0481] obtains manager information of the data center, connection
broker information, hypervisor information, template, information
and directory information based on a request from the data center
registration processing.
(Supplementary note 29) The computer readable medium according to
any of supplementary note 24 through supplementary note 28,
wherein
[0482] information of a license stored in the management data base
includes a hypervisor owner requirement,
[0483] information of a hypervisor stored in the management data
base includes a hypervisor ownership,
[0484] the requirement information of the virtual machine creation
request includesthe license including the hypervisor owner
requirement meeting the ownership of a hypervisor usable by the
tenant, and
[0485] at the virtual machine creation management processing,
[0486] extracts the hypervisor satisfying the hypervisor owner
requirement of the requirement information.
* * * * *
References