Abstract:
A computer-readable recording medium has stored therein a program for causing a computer to execute a usage mode data generation process. The process comprising (a) reading from a storage device association data associating each of a plurality of different expression formats of component data and a standardized expression format which can be converted to each of the plurality of different expression formats, and (b) based on the association data read at (a), generating according to the standardized expression format standardized usage mode data containing component data from first usage mode data that is usage mode data for a first virtual computer included in a plurality of virtual computers and that contains component data for the connector in a first relay device with the type of a first type expressed in a first expression format corresponding to the first relay device.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application is based upon and claims the benefit of priority of the Japanese Patent Application No. 2013-115982, filed on May 31, 2013, the entire contents of which are incorporated herein by reference. 
       FIELD 
       [0002]    The present invention relates to a computer-readable recording medium, usage mode data generation method, communication system, and usage mode data generation device. 
       BACKGROUND 
       [0003]    As illustrated in  FIG. 14 , virtual machines (VM) have hitherto been provided, for example to 4 respective servers  302 - 1  to  302 - 4  that are each connected to 4 ports  303 - 1  to  303 - 4  of a switch  300 .  FIG. 14  illustrates an example in which a virtual machine  304 - 1  is provided to the server  302 - 1 , and a virtual machine  304 - 4  is provided to the server  302 - 4 . Communication occurs between the virtual machine  304 - 1  and the virtual machine  304 - 4  through the switch  300 . When virtual machines are also provided to the server  302 - 2  and the server  302 - 3 , communication occurs between the virtual machines provided to the server  302 - 2  and the server  302 - 3  through the switch  300 . Consider a case in which the virtual machine  304 - 1  only communicates with the virtual machine  304 - 4 . Since the 4 servers  302 - 1  to  302 - 4  are connected to the single switch  300 , data from the virtual machine  304 - 1  might sometimes be transmitted to the virtual machine provided to the server  302 - 3  that is not the transmission destination. 
         [0004]    In order that data is not transmitted from one virtual machine to another virtual machine that is not the transmission destination, consideration may be given to building 2 networks by providing 2 switches and only connecting the servers with mutually communicating virtual machines to each of the switches. Namely, consideration may be given to building a first network including the server  302 - 1 , one of the switches, and the server  302 - 4 , and a second network including the server  302 - 2 , the other of the switches, and the server  302 - 3 . However, providing 2 switches increases the complexity of the overall configuration. 
         [0005]    Hitherto, 2 networks have been built virtually by using the switch  300  by employing virtual separation in the switch  300 . Virtually built networks are referred to as Virtual Local Area Networks (VLAN). 2 virtual local area networks are respectively identified by Virtual Local Area Network Identifiers (VLAN ID). 
         [0006]    In order to build two virtual local area networks, virtual local area network identifiers of identification data of the 4 respective ports  303 - 1  to  303 - 4  are stored in memory, not illustrated in the drawings, of the switch  300 . The memory of the switch  300  is moreover stored with Media Access Control Addresses (MAC Addresses) that are used in communication between the virtual machines associated with the virtual local area network identifiers. For example, the memory is stored with X as a virtual local area network identifier associated with the respective identification data of the ports  303 - 1 ,  303 - 4 , and stored with Y as the MAC address used in communication between the virtual machines  304 - 1 ,  304 - 4 . N is moreover stored as the virtual local area network identifier associated with the ports  303 - 2 ,  303 - 3 , and M is stored as the MAC address employed in communication by the virtual machines provided to the servers  302 - 2  and the  302 - 3 . 
         [0007]    Accordingly, for example when communication is performed between the virtual machines  304 - 1 ,  304 - 4 , the switch  300  identifies the communication between the virtual machines  304 - 1 ,  304 - 4  with the MAC address (Y). The switch  300  moreover identifies the ports  303 - 1 ,  303 - 4  performing communication between the virtual machines  304 - 1 ,  304 - 4  with the virtual local area network identifier (X). When communication is performed between the virtual machines  304 - 1 ,  304 - 4 , the switch  300  only relays data between the virtual machines  304 - 1 ,  304 - 4 . Namely, the switch  300  does not transmit data transmitted from the virtual machine  304 - 1  to the virtual machine associated with the port  303 - 3  that is appended with the other virtual local area network identifier (N). 
         [0008]    As described above, the memory of the switch  300  is stored with the virtual local area network identifiers associated with the identification data each of the ports  303 - 1  to  303 - 4 , and the MAC addresses used in communication between the virtual machines. The virtual local area network identifiers and MAC addresses associated with identification data of the respective ports  303 - 1  to  303 - 4  stored in the memory are referred to as port profiles. The switch  300  relays communication between the virtual machines using the port profiles stored in the memory, thereby building a virtual local area network. The virtual local area network identifiers are used in virtual local area network building. 
         [0009]    As illustrated in  FIG. 14 , the virtual machine  304 - 1  of the server  302 - 1  is sometimes migrated (relocated) to the separate server  302 - 2 . There is a need to prevent transmission of data from the virtual machine  304 - 1  to virtual machines other than the virtual machine  304 - 4 , that are not the transmission destination, after the virtual machine  304 - 1  has migrated to the server  302 - 2 . There is therefore a need to maintain the virtual local area network including the virtual machine  304 - 1  and the virtual machine  304 - 4 . The port profile associated with the identification data of the port  303 - 1  accordingly must be stored in the memory of the switch  300  in association with the identification data of the port  303 - 2 . Hitherto, when there is some degree of expectation of migration of the virtual machine  304 - 1  to the server  302 - 2 , the port profile associated with the identification data of the port  303 - 1  is stored in association with the identification data of the port  303 - 2  in the memory of the switch  300 . However, it is cumbersome to store the port profiles in advance. Accordingly, a function has been used in switches to automatically store port profiles associated with the identification data of the switches to be connected to the migration destination server of the virtual machine accompanying virtual machine migration (Automatic Port Profile Migration (AMPP)). Namely, the virtual machine  304 - 1  outputs a virtual local area network identifier ( 10 ) to the switch  300  during communication through the switch  300  of the virtual machine  304 - 1  that has migrated to the server  302 - 2  with the virtual machine  304 - 4 . The switch  300  automatically stores in the memory a port profile including the virtual local area network identifier ( 10 ) associated with the identification data of the port  303 - 2  to which the server  302 - 2  is connected. 
         [0010]    A larger network can be configured by connecting one switch to another switch. For example, as illustrated in  FIG. 15 , the switch  300  is connected to a switch  400 . When the switch  300  is connected to the switch  400 , the virtual machine  304 - 1  of the server  302 - 1  that is connected to the switch  300  can migrate to a server  402 - 1  that is connected to port  403 - 1  of the switch  400 . In order to maintain the virtual local area network, even after migration of the virtual machine  304 - 1  to the server  402 - 1 , the port profile is still stored associated with the port  403 - 1  in memory of the switch  400 . 
         [0011]    The switches  300 ,  400  may be connected together even when the switch  300  and the switch  400  are manufactured by different vendors (manufacturers). 
       RELATED PATENT DOCUMENTS 
       [0012]    Patent Document 1: Japanese Patent Application Laid-Open (JP-A) No. 2003-219029 
         [0013]    Patent Document 2: JP-A No. 2009-32204 
       SUMMARY 
       [0014]    According to an aspect of the embodiments, a computer-readable recording medium, having stored therein a program for causing a computer to execute a usage mode data generation process, the process comprising: 
         [0015]    (a) reading from a storage device association data associating each of a plurality of different expression formats of component data and a standardized expression format which can be converted to each of the plurality of different expression formats, each of the plurality of different expression formats corresponding to each type of a plurality of relay devices, the plurality of relay devices having a connector and relaying communication through the connectors between a plurality of virtual computers that each operate on a data processing device, the component data being included in a usage mode data which is referenced by the relay device, the usage mode data being data to set a usage mode of the connector when the communication through the connectors between a plurality of virtual computers; and 
         [0016]    (b) based on the association data read at (a), generating, according to the standardized expression format, standardized usage mode data containing component data from first usage mode data that is usage mode data for a first virtual computer included in the plurality of virtual computers and that contains component data for the connector in a first relay device with the type of a first type expressed in a first expression format corresponding to the first relay device. 
         [0017]    It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0018]      FIG. 1  is a block diagram illustrating an example of a communication system of an exemplary embodiment; 
           [0019]      FIG. 2  is a functional block diagram of a management device  10  of an exemplary embodiment; 
           [0020]      FIG. 3  is a diagram schematically illustrating an example of a management process of a management program stored in ROM  34  of the management device  10 . 
           [0021]      FIG. 4A  is a diagram illustrating a flow of processing during generation of port profiles in the formats of a vendor B and a vendor C, from a port profile in the format of a vendor A;  FIG. 4B  is a flow chart illustrating an example of a processing flow at step S 1 - 1  of  FIG. 4A . 
           [0022]      FIG. 5  is a diagram illustrating rules defined for generating a port profile from a master port profile and vice versa and associated with respective switch models and OSs. 
           [0023]      FIGS. 6A and 6B  are diagrams explaining rules for generating a port profile of a different format from a port profile of a particular format;  FIG. 6A  illustrates rules for generating port profiles of all other formats from the port profile of a particular format;  FIG. 6B  is a diagram illustrating rules for generating a master port profile from all port profiles of differing formats and vice versa. 
           [0024]      FIG. 7  is a flow chart illustrating an example of a processing flow for generating a port profile from a master port profile of the exemplary embodiment. 
           [0025]      FIG. 8  is a diagram illustrating VM migration. 
           [0026]      FIG. 9A  to  FIG. 9C  are diagrams illustrating port profile contents during generation of a port profile of the format of a vendor B from a port profile of the format of a vendor A;  FIG. 9A  illustrates a port profile PPA in the format of the vendor A;  FIG. 9B  illustrates a port profile PPB in the format of the vendor B;  FIG. 9C  illustrates a master port profile generated from the port profile PPA. 
           [0027]      FIG. 10  is a diagram illustrating an association table of port profiles against VMs stored in a switch. 
           [0028]      FIG. 11  is a diagram illustrating a priority ranking input by a priority ranking input section  70 ; 
           [0029]      FIG. 12  is a diagram explaining selection of QoS identification data that is closest to a QoS in a switch  22 - 1  from QoS identification data stored in a switch  22 - 2 , in accordance with the priority ranking of  FIG. 11 . 
           [0030]      FIG. 13  is a diagram illustrating a correspondence relationship between port profiles used by VMs migrated to a server  14  connected to a switch  22 - 2  from a server  12  connected to a switch  22 - 1 , and MAC addresses used in communication with the VMs; explaining a case in which a VM  17  is migrated ((A)); and explaining a case in which a VM  19  is migrated following the VM  17  migration ((B)). 
           [0031]      FIG. 14  is a diagram illustrating VM migration in related art. 
           [0032]      FIG. 15  is a diagram illustrating migration of a VM of a server connected to a particular switch to another server connected to a different switch in related art. 
       
    
    
     DESCRIPTION OF EMBODIMENTS 
       [0033]    Detailed description follows regarding an example of an exemplary embodiment of the present invention with reference to the drawings. Explanation follows regarding configuration of the exemplary embodiment. In the communication system illustrated in  FIG. 1 , a server  12  is connected to a port  20 - 1  of a switch  22 - 1 , and a server  14  is connected to a port  20 - 2  of a switch  22 - 2 . The servers  12 ,  14 , the switch  22 - 1 , and the switch  22 - 2  are connected to a management device  10 . 
         [0034]    A virtual machine (referred to as “VM” below)  17  is provided to the server  12 . Moreover, a hypervisor  15  operates on the server  12  and controls the VM  17 . As described below, the VM  17  is migrated (moved) to the server  14 . A hypervisor  16  operates on the server  14 , and the hypervisor  16  controls the VM  17  on the server  14  after the VM  17  has been migrated to the server  14 . 
         [0035]    The server  12  communicates with for example another server connected to a switch  22 - 1 , not illustrated in the drawings, and the server  14  that is connected to the switch  22 - 2 , through the VM provided to each server. 
         [0036]    In the management device  10 , a Central Processing Unit (CPU)  32 , Read Only Memory (ROM)  34 , Random Access Memory (RAM)  36 , an input device  38 , and a display device  40  are mutually connected to each other through a bus  48 . An external interface  42 , a communication interface  44  and a database  46  are connected to the bus  48 . 
         [0037]    The servers  12 ,  14  are configured similarly to the management device  10  and description of the configuration of the servers  12 ,  14  is therefore omitted. The switches  22 - 1 ,  22 - 2  are of similar configuration to the management device  10 ; however, the configurations of the switches  22 - 1 ,  22 - 2  differ from the configuration of the management device  10  in that the switches  21 ,  22 - 2  are not provided with the input device  38  and the display device  40  of the management device  10 . Moreover, the configurations of the switches  22 - 1 ,  22 - 2  differ from the configuration of the management device  10  in that the switches  22 - 1 ,  22 - 2  are respectively provided with memories  24 - 1 ,  24 - 2  in place of the database  46  of the management device  10 . 
         [0038]    Note that the management device  10  serves as an example of a usage mode data generation device of the present invention, and the servers  12 ,  14  serve as examples of a data processing device of the present invention. Moreover, the switches  22 - 1 ,  22 - 2  serve as examples of a relay device of the present invention, and the ports  20 - 1 ,  20 - 2  serve as examples of a connector of the present invention. The memories  24 - 1 ,  24 - 2  serve as examples of an association memory of the present invention. The VM  17  serves as an example of a virtual computer of the present invention. 
         [0039]      FIG. 2  illustrates a functional block diagram of the management device  10 . The management device  10  is provided with a network management section  50  and a VM management section  54 . Moreover, the management device  10  is provided with a PP (Port Profile), an operation Graphical User Interface (GUI)  74 , and the database  46 . 
         [0040]    The network management section  50  is provided with a PP management section  52 , a network configuration management section  66 , and a Media Access Control (MAC) address duplication detection section  68 . The PP management section  52  is provided with a PP acquisition section  56 , a PP detection section  58 , a PP setting section  60 , a master PP generation section  62 , and a child PP generation section  64 . 
         [0041]    The VM management section  54  is provided with a priority ranking input section  70  and a VM migration detection section  72 . The database  46  is provided with a VM-PP association table  76 , a rule definition section  78 , a PP database (referred to as a PPDB (Port Profile Data Base) below)  79 , a switch configuration data storage section  80 , and a ranking storage table  81 . 
         [0042]    The management device  10  performs VM management, network management, and port profile unified management. The network management section  50  performs setting and monitoring of the switch  22 - 1  and the switch  22 - 2 . The PP acquisition section  56  acquires a port profile stored in the switches  22 - 1 ,  22 - 2 . When for example the VM  17  has been migrated from the server  12  to the server  14 , the PP detection section  58  checks whether or not the port profile attempting to be newly created at the VM  17  migration destination side switch  22 - 2  is already present in the memory  24 - 2  of the switch  22 - 2 . The PP setting section  60  stores (sets) the port profile in the memory  24 - 2  of the switch  22 - 2 . When for example a port profile has been created, the master PP generation section  62  automatically creates a master port profile. The child PP generation section  64  creates a port profile for each of the ports  20 - 1 ,  20 - 2  of the respective switches  22 - 1 ,  22 - 2 . The network configuration management section  66  reads the hypervisor and switch data stored in the switch configuration data storage section  80  and detects the switches on the VM migration source side and the VM migration destination side. The MAC address duplication detection section  68  checks whether or not the MAC address communicated by the migrating VM is already in use at the switch at the migration destination side. 
         [0043]    The VM management section  54  performs VM creation, VM erasure, VM migration and the like through the hypervisors  15 ,  16 . The priority ranking input section  70  inputs a priority ranking in accordance with user instructions when one of identification data is chosen from plural Quality of Service (QoS) identification data, described below, of the migration destination switch. The input priority ranking is stored in the ranking storage table  81  (see also  FIG. 11 ). The VM migration detection section  72  detects VM migration. 
         [0044]    The PP operation GUI  74  inputs data for port profile creation in accordance with formats of the switches  22 - 1 ,  22 - 2 . 
         [0045]    The VM-PP association table  76  is used to manage the port profiles and VM data using each port profile. The rule definition section  78  stores rules, described in detail below, that are required for the creation of the port profiles and the master port profile. The PPDB  79  stores the port profiles managed in the database  46 . Note that each port profile corresponds to a switch and is stored associated with a VM as illustrated in  FIG. 10 . To be more specific, as illustrated in  FIG. 13  the port profile PPA is stored associated with the MAC addresses ( 100 ,  200 ) for communication using the VMs  17 ,  19 . The models of the switches  22 - 1 ,  22 - 2 , the OS used by the switches  22 - 1 ,  22 - 2  and data indicating the hypervisors  15 ,  16  associated with the switches  22 - 1 ,  22 - 2  are stored in the switch configuration data storage section  80 , associated with the switches  22 - 1 ,  22 - 2 . 
         [0046]    An example of a management process performed by a management program stored in the ROM  34  of the management device  10  is schematically illustrated in  FIG. 3 . The CPU  32  reads the management program from the ROM  34 , expands the management program into the RAM  36 , and executes processes of the management program. The management process is provided with a network management section process  82 , and a VM management process  86 . The network management section process  82  is provided with a PP management process  84 , a network configuration management process  98 , and a MAC address duplication detection process  100 . The PP management process  84  is provided with a PP acquisition process  88 , a PP detection process  90 , a PP setting process  92 , a master PP generation process  94 , and a child PP generation process  96 . The VM management process  86  is provided with a priority ranking input process  122  and a VM migration detection process  124 . 
         [0047]    Note that an example of a case where the management program is read from the ROM  34  is given above; however, there is no requirement for the management program to be stored in the ROM  34  from the outset. The management program may, for example, be initially stored on any “portable recording medium” such as a Solid State Drive (SSD), a DVD disc, an IC card, a magneto-optical disc, or a CD-ROM connected to and used by the management device  10 . Furthermore, the management device  10  may be configured to acquire and execute the management program from a portable recording medium. Moreover, the management program may be stored in a storage section such as another computer or a server device connected to the management device  10  through a communication line. The management device  10  may for example acquire and execute the management program from another computer or server device. 
         [0048]    Note that by executing each of the processes  82  ( 84  ( 88  to  96 ),  98 ,  100 ),  86  ( 122 ,  124 ), the CPU  32  operates as each of the sections  50  ( 52  ( 56  to  64 ),  66 ,  68 ),  54  ( 70 ,  72 ) that are illustrated in  FIG. 2 . 
         [0049]    Note that the rule definition section  78  serves as an example of a storage device of the present invention, the master PP generation section  62  serves as an example of a standardized usage mode data generation section of the present invention, and the child PP generation section  64  serves as an example of an individual usage mode data generation section of the present invention. 
         [0050]    Description of the operation of the exemplary embodiment follows. As illustrated in  FIG. 1 , a case is considered in which the VM  17  is provided to the server  12 , and the VM  17  is in communication other VMs. The user uses the PP operation GUI  74  and inputs data for creating a port profile associated with the VM  17 . The vendor of the switch  22 - 1  that is connected to the server  12  is a vendor A. The child PP generation section  64  creates the port profile PPA (see (A) in  FIG. 9 ) based on the input data using the formats of the vendor A. The PP setting section  60  stores the generated port profile PPA to the memory  24 - 1  of the switch  22 - 1  associated with the identification data of the port  20 - 1  connected to the server  12 . 
         [0051]    The switch  22 - 1  relays communication between the VM  17  of the server  12  and another VM, through the port  20 - 1  that is connected to the server  12 . The switch  22 - 1  relays communication in accordance with a port profile that sets the usage mode of the port  20 - 1 . A virtual local area network that includes the VM  17  and the other VM is accordingly built. An example of an element that defines the usage mode included in the port profile is data indicating the virtual local area network identifier (referred to below as the VLAN ID). The port profile further includes for example data specifically indicating contents of the network service, for example the QoS associated with data expressing the QoS, as another example of such an element. 
         [0052]    As described above, the vendors of the respective switches  22 - 1 ,  22 - 2  are different, and the port profile formats of the switches  22 - 1 ,  22 - 2  are therefore also different. Namely, the port profile PPA associated with the switch  22 - 1  vendor A is illustrated in (A) in  FIG. 9 . As illustrated in (A) in  FIG. 9 , the expression format of the data indicating the VLAN ID is “switchport trunk allowed vlan add” as indicated by reference numeral  120 NA. The expression format indicating the QoS is “qos cos” as shown by the reference numeral  120 MA. A port profile PPB that corresponds to a switch  22 - 2  vendor B is illustrated in (B) in  FIG. 9 . As illustrated in (B) in  FIG. 9 , the expression format of the data indicating the VLAN ID is “port-profile  10  vlan tag” as indicated by reference numeral  120 NB. The expression format of the data indicating the QoS is “port-profile  10  qos priority” as indicated by the reference numeral  120 MB. 
         [0053]    The expression formats expressing data that defines the usage mode elements of the port profile vary by vendor. Thus, when the VM  17  of the server  12  is migrated to the server  14  as illustrated in  FIG. 1  and  FIG. 8 , the switch  22 - 2  is unable to use the port profile PPA with the format left as it is. 
         [0054]    When the port profile PPA has been created (see Si of  FIG. 4A ), at step S 1 - 1  the master PP generation section  62  generates a master port profile MPPA from the port profile PPA that uses the vendor A formats. 
         [0055]    In the exemplary embodiment, rules for the generation of the master port profile MPPA from the port profile PPA that uses the vendor A format are pre-stored in the rule definition section  78 . Namely, since the expression formats that indicate data that defines each element of the usage modes of ports  20 - 1 ,  20 - 2  are different for the vendors A, B, the expression formats of each element in the management device  10  are therefore standardized; namely, compatible standardized expression formats are pre-defined. The rules indicate which expression formats correspond to which standardized expression formats. Note that the standardized expression formats serve as an example of a standardized expression format of the present invention. 
         [0056]    The operator associates together “switchport trunk allowed vlan add” ( 120 NA) and “port-profile  10  vlan tag” ( 120 NB), and defines “TaggedVLAN” ( 120 NM) as the standardized expression format corresponding thereto. The operator defines a first rule stating that “switchport trunk allowed vlan add” and “port-profile  10  vlan tag” correspond to “TaggedVLAN”. Moreover, the operator defines “QoSCoS” ( 120 MM) as the standardized expression format corresponding to “qos cos” ( 120 MA) and “port-profile  10  qos priority” ( 120 MB). The operator defines a second rule stating that “qos cos” and “port-profile  10  qos priority” correspond to “QoSCoS”. The first rule and the second rule defined above are stored in the rule definition section  78 . 
         [0057]    An example is described above wherein the expression formats of the port profiles differ between each vendor. However, the expression formats of the port profiles also differ for each switch model and Operating System (OS) used by each switch. Rules that differ between each switch model and each OS for generating the master port profile from the port profiles of each switch are stored in the rule definition section  78  for each switch model and each OS. As illustrated in  FIG. 5 , rules  110 - 1 ,  110 - 2  . . .  110 -N, used by the switch  22 - 1  for the purpose of generating a master port profile corresponding to switch  22 - 1 , are stored in the rule definition section  78 . The rules  110 - 1 ,  110 - 2  . . .  110 -N correspond to an OS  102  that is version v 1 , and to respective models  1  to N of the switch  22 - 1 . 
         [0058]    A method for generating a port profile using the format of another vendor from a port profile of a given vendor format is described below. Namely, as illustrated in  FIG. 6A , a case is considered wherein the operator defines rules for directly generating port profiles using other vendor formats from each port profile of plural switch vendors. However, there is a need for the operator to predefine rules for each different vendor combination. As illustrated in  FIG. 6A , when there are  4  vendor types for example, there is a need for the user to predefine  6  rules R 1  to R 6 . 
         [0059]    Therefore, in the exemplary embodiment, as illustrated in  FIG. 6B , the operator defines rules RA to RD for generating the port profiles  112  to  118  of each of the switches from the master port profile and vice versa. As illustrated in  FIG. 6B , for example when there are 4 vendor types, 4 rules RA to RD are sufficient. There are accordingly fewer predefined rules when using a master port profile than in the case described with reference to  FIG. 6A . 
         [0060]    Port profiles PPA, PPB serve as an example of usage mode data of the present invention, and the master port profile PPM serves as an example of standardized usage mode data of the present invention, and the rules are an example of association data of the present invention. 
         [0061]    A case is considered here where the VM  17  is migrated in sequence from the server  12  connected to the vendor A switch  22 - 1 , to the server  14  connected to the vendor B switch  22 - 2 , and to a server, not illustrated in the drawings, connected to a vendor C switch, not illustrated in the drawings. The port profile format needs to be modified at each of the migrations of the VM  17  to the server  12 , to the server  14 , and to the server not illustrated in the drawings.  FIG. 4A  illustrates processing to generate the port profiles of the vendor B and vendor C formats from a port profile that uses the vendor A format. At step S 1  the VM  17  is set on the server  12  as illustrated in  FIG. 1 . For the VM  17  to communicate with another VM, the user uses the PP operation GUI  74  and inputs data for port profile creation. The child PP generation section  64  generates the port profile PPA using the vendor A format (see (A) in  FIG. 9 ) based on the input data, and the PP setting section  60  sets the generated port profile PPA on the switch  22 - 1 . Namely, the port profile PPA is stored associated with the identification data of the port  20 - 1  in the memory  24 - 1  of the switch  22 - 1 . Note that the port profile is also stored in the PPDB  79 . 
         [0062]    When the port profile PPA has been created at step S 1 , at step S 1 - 1  the master PP generation section  62  generates the master port profile MPPA from the port profile PPA based on the rules described above. (B) in  FIG. 4  illustrates an example of the processing at step S 1 - 1 . At step  142  the master PP generation section  62  reads from the rule definition section  78  the rule for the generation of the master port profile from the vendor A format port profile of the switch  22 - 1 . At step  144  the master PP generation section  62  generates the master port profile MPPA using the rules described above and the contents of the port profile PPA. 
         [0063]    The contents of the processing at step  144  will be described in detail with reference to  FIG. 9 . From the above rules, the master PP generation section  62  is able to confirm that “switchport trunk allowed vlan add” in the port profile PPA corresponds to “TaggedVLAN” in the master port profile PPM. The “ 100 ” provided associated with “switchport trunk allowed vlan add” in the port profile PPA is associated with “TaggedVLAN” in the master port profile PPM. 
         [0064]    Moreover, from the above rules, the master PP generation section  62  is able to confirm that “qos cos” in the port profile PPA corresponds to “QoSCoS” in the master port profile PPM. The “ 5 ” provided associated with “qos cos” in the port profile PPA is associated with “QoSCoS” in the master port profile PPM. 
         [0065]    After the master port profile MPPA has been generated as described above, at step S 2  in  FIG. 4A , the user updates the port profile PPA through the child PP generation section  64  in accordance with, for example, changes in the usage method of a port for communication with the VM  17 . The port profile PPA is updated to a port profile PPA 1 . At step S 2 - 1  the master PP generation section  62  reflects the updated contents in the master port profile MPPA, based on the rules using similar processing to that illustrated in (B) in  FIG. 4 . The master port profile MPPA becomes the master port profile MPPA 1 . 
         [0066]    When the VM  17  is migrated to the server  14  that is connected to the switch  22 - 2  as described above, at step S 3 - 1  the master PP generation section  62  generates a port profile PPB for the switch  22 - 2  from the master port profile MPPA 1 . A more detailed description will be given later (see  FIG. 7 ). 
         [0067]    At step S 4 , when the user updates the port profile PPB as described above in accordance with, for example, a change in the usage method of the port, at step S 4 - 1  the master PP generation section  62  generates a master port profile MPPB 1  using similar processing to that illustrated in (B) in  FIG. 4 . 
         [0068]    The VM  17  that has been migrated to the server  14  of the switch  22 - 2  as described above is then migrated to the server, not illustrated in the drawings, connected to the vendor C switch, not illustrated in the drawings. When this occurs, at step S 5 - 1  the master PP generation section  62  generates a port profile PPC with the switch C format from the master port profile MPPB  1 . The port profile PPC is generated using similar processing to that used at step S 3 - 1 . Note that there are cases in which steps S 2  and S 4  of  FIG. 4A  are not executed. Steps S 2 - 1  and S 4 - 1  are therefore not executed, with the port profile PPB generated from the master port profile MPPA following the processing of step S 1 - 1  when the VM  17  has been migrated to the server  14 . 
         [0069]    Moreover, the master port profile MPPB is generated at step S 4 - 1  at the timing when the port profile PPB is updated. However, after the processing of step S 3 - 1 , the master port profile MPPB can be generated from the port profile PPB using similar processing to that used at step S 1 - 1 . In cases where the VM  17  is again migrated to another server, a port profile PPC can be generated from the master port profile MPPB using the processing of step S 5 - 1 . 
         [0070]      FIG. 7  illustrates an example of a flow of port profile generation processing (steps S 3 - 1  and S 5 - 1  in  FIG. 4A ) for generating a port profile with the switch format from the master port profile. Namely, explanation is given regarding an example of a case in which the VM  17  on the server  12  is migrated to the server  14  (step S 3 - 1  of  FIG. 4A ) as illustrated in  FIG. 1  and  FIG. 8 . At step  202 , the VM migration detection section  72  detects the migration of the VM. Namely, the user inputs instruction data to the management device  10  to instruct migration of the VM  17 , through the input device  38  of the management device  10 . When the instruction data is input to the management device  10 , the VM migration detection section  72  detects the input of the instruction data and detects the VM migration. 
         [0071]    At step  204  the network configuration management section  66  detects the hypervisors  15 ,  16  of the VM  17  migration source and migration destination servers  12 ,  14 . Firstly, the instruction data includes respective identification data identifying the migration source server  12  and the migration destination server  14  of the VM  17 . Moreover, data regarding the hypervisors  15 ,  16  and the switches  22 - 1 ,  22 - 2  are stored in the switch configuration data storage section  80 . The processing of step  204  is thereby executed based on the respective identification data identifying the servers  12 ,  14  included in the instruction data, and on data of the hypervisors  15 ,  16  and data of the switches  22 - 1 ,  22 - 2  stored in the switch configuration data storage section  80 . At step  206  the network configuration management section  66  detects the switches  22 - 1 ,  22 - 2  that are connected to the hypervisors  15 ,  16  on the migration source side and the migration destination side of the VM. Note that step  204  may be omitted, and the switches  22 - 1 ,  22 - 2  may be detected based on identification data that identifies the servers  12 ,  14  that is included in the instruction data. 
         [0072]    At step  208  the MAC address duplication detection section  68  detects whether or not a MAC address the same as the MAC address communicated by the migrated VM  17  is stored in the memory  24 - 2  of the migration destination side switch  22 - 2 . As illustrated in  FIG. 13 , the VMs  17 ,  19  are provided on the server  12 , with the VMs  17 ,  19  in communication with another VM. A single virtual local area network is built that includes the VMs  17 ,  19  and the other VM. Moreover, each of the MAC addresses ( 100 ,  200 ) used by VMs  17 ,  19  and the other VM are stored associated with port profile PPA in the memory  24 - 1  of the switch  22 - 1 . In cases in which the VMs  17 ,  19  are migrated to the server  14 , MAC addresses ( 100 ,  200 ) used in communication with each of the migrating VMs  17 ,  19  would not usually be present in the migration destination switch  22 - 2 . However, there are cases where the user stores the MAC addresses ( 100 ,  200 ) in the memory  24 - 2  of the switch  22 - 2  in error. In such cases, the MAC address duplication detection section  68  determines whether or not the MAC addresses ( 100 ,  200 ) used in communication with the migrating VMs  17 ,  19  are stored within the memory  24 - 2  of the migration destination switch  22 - 2 . 
         [0073]    When the determination result at step  208  is an affirmative determination, port profile generation processing terminates since there is a mistake by a user. However, the MAC addresses ( 100 ,  200 ) for communication with migrating VMs  17 ,  19  are usually not stored in the memory  24 - 2  of the migration destination switch  22 - 2 . In such cases the determination result at step  208  is therefore a negative determination, and port profile generation processing transitions to step  210 . 
         [0074]    At step  210  the PP acquisition section  56  and the PP detection section  58  perform processing to determine whether or not the port profile PPA for which setting is requested is already usable by the migration destination switch  22 - 2 . Namely, specifically, the PP acquisition section  56  first acquires the port profile PPA of the VM  17  migration source side switch  22 - 1 . The PP detection section  58  then determines whether or not a port profile with the same contents as the acquired port profile PPA is present in the migration destination side switch  22 - 2 . 
         [0075]    Note that the formats of the port profile PPA of the migration source side switch  22 - 1  and the port profile PPB of the migration destination side switch  22 - 2  differ from each other. The PP detection section  58  is therefore unable to make a direct comparison between the port profile PPA and the port profile PPB. However, at step S 1 - 1  (step S 2 - 1 ) of  FIG. 4A , the master port profile MPPA is generated from the port profile PPA of the migration source side switch  22 - 1 . The port profile PPB of the migration destination side switch  22 - 2  is thereby generated from the master port profile MPPA (MPPA 1 ) obtained from step S 1 - 1  (step S 2 - 1 ) in  FIG. 4A  based on the rules described above. Determination is then made as to whether or not a port profile with the same contents as the contents of the generated port profile PPB is stored in the memory  24 - 2  of the migration destination side switch  22 - 2 . In cases where a port profile with the same contents as the contents of the generated port profile PPB is stored in the memory  24 - 2  of the switch  22 - 2 , the determination result at step  210  is an affirmative determination. In such cases, port profile generation processing then transitions to step  226 . In cases where a port profile with the same contents as the contents of the generated port profile PPB is not present in the memory  24 - 2  of the switch  22 - 2 , the determination result at step  210  is a negative determination. In such cases, port profile generation processing then transitions to step  212 . 
         [0076]    At step  212  the child PP generation section  64  determines whether or not the model and the OS of the migration source side switch  22 - 1  and the migration destination side switch  22 - 2  of the VM  17  are the same as each other based on the data acquired at step  206 . In cases where both the model and the OS of the switch  22 - 1  and the switch  22 - 2  are the same as each other, the determination result at step  212  is an affirmative determination. The port profiles therefore need not be converted based on differences in model and OS, and so the processing at step  214  is skipped, and port profile generation processing transitions to step  216 . 
         [0077]    However, when the model or the OS or both the model and the OS of the switch  22 - 1  and the switch  22 - 2  differ from each other, the expression formats of the port profiles differ. There is accordingly a need to convert the port profile formats based on the differences in model and/or OS. Therefore, at step  214 , it is determined that the child PP generation section  64  should convert the port profile formats based on the differences in model and/or OS. 
         [0078]    At step  216  the child PP generation section  64  determines whether or not the network services of the VM  17  migration source and the VM  17  migration destination switches  22 - 1 ,  22 - 2  are the same as each other. When the determination result at step  216  is a negative determination, at step  218  the child PP generation section  64  selects the network service closest to the network service of the VM  17  migration source switch  22 - 1  from the network services of the switch  22 - 2 . Detailed explanation follows regarding contents of the processing of steps  216 ,  218 . 
         [0079]    The vendors of the switches  22 - 1 ,  22 - 2  are different vendors; however, there are cases in which the vendors of the switches  22 - 1 ,  22 - 2  are the same and the contents of network services identified by the same identification data differ. Explanation follows regarding the example of the network service QoS. Namely, firstly, when the ports  20 - 1 ,  20 - 2  of the switches  22 - 1 ,  22 - 2  forward data, the data is temporarily stored and the temporarily stored data is then forwarded. There are limitations to the amount of forwarding data that can be temporarily stored on the ports  20 - 1 ,  20 - 2 . Therefore, in cases in which for example communication is performed between plural VM pairs through the same port  20 - 1  at the same time, each VM would simultaneously attempt to forward data, at an amount that would exceed the maximum amount of data that can be temporarily stored on the port  20 - 1 . Therefore, any data that exceeds the maximum amount of data that can be temporarily stored by the port  20 - 1  would not be forwarded. 
         [0080]    The QoS therefore specifies a ratio of the data amounts that can be forwarded through the port  20 - 1  by each VM pair. For example, the QoS sets the respective VMs with first rank (G), second rank (S), and third rank (B) data forwarding amounts in the ratio 5:3:2. For example, in the example illustrated in  FIG. 12 , a “ 5 ” identifying that G:S:B=5:3:2 is included in the switch  22 - 1 . Moreover, for example when the VMs using the port  20 - 1  to forward data are a first VM, a second VM, and a third VM, then the amounts of data that can be temporarily forwarded are set with a ratio of 5:3:2 for the first VM, the second VM, and the third VM. 
         [0081]    As described above, even when the vendors of the switches  22 - 1 ,  22 - 2  are the same, the QoS identified by the “ 5 ” in the switch  22 - 2  may also be G:S:B=7:2:1. Accordingly, a second rank (S) is set for the VM  17 , and although data can be forwarded at a ratio of 3/10 until the VM  17  is migrated to the server  14 , the ratio becomes 2/10 due to the migration of the VM  17  to the server  14 . 
         [0082]    The child PP generation section  64  selects a QoS with the second rank (S) set to a ratio close to 3/10 out of the plural QoS of the switch  22 - 2 , so as to enable continuation of data forwarding at a ratio of 3/10 as far as possible. Namely, the child PP generation section  64  acquires the QoS data of the switch  22 - 2 . As the QoS of the VM  17  migration source side switch  22 - 1 , a “ 5 ” is acquired that identifies G:S:B=5:3:2 in the switch  22 - 1  as illustrated in  FIG. 12 . At step  216  the child PP generation section  64  determines whether or not G:S:B is 5:3:2 for the QoS acquired from the migration destination side switch  22 - 2 . In cases where at least one of G, S or B of the QoS differs between the migration source side switch  22 - 1  and the migration destination side switch  22 - 2 , the determination result of step  216  is a negative determination. Namely, as illustrated in  FIG. 12 , the QoS identified by  5  is G:S:B=5:3:2 for the switch  22 - 1 ; however, the QoS identified by “ 5 ” is G:S:B=7:2:1 for the switch  22 - 2 . Negative determination is therefore made at step  216 . Port profile generation processing then transitions to step  218 . 
         [0083]    At step  218  the child PP generation section  64  selects the identification data for the QoS closest to the QoS identified by  5  in the switch  22 - 1  from the QoS identification data of the switch  22 - 2 . The criteria for determining whether or not a QoS from amongst the plural QoS of the switch  22 - 2  is close to the switch  22 - 1  QoS, is a priority ranking pre-input by the priority ranking input section  70 . For example, a first case (VM=VM 1  (see  FIG. 11 )) is considered where the priority ranking input section  70  inputs prioritizing with G as the first priority ranking (Prio. 1). In the example illustrated in  FIG. 12 , G is  5  in the switch  22 - 1 , and the QoS identification data  7  in the switch  22 - 2 , corresponding to a G of  5 , is therefore selected. In a second case (VM=VM 2  (see  FIG. 11 )) where the priority ranking input section  70  inputs prioritizing with S as the first priority ranking, S is “ 3 ” in the switch  22 - 1 , and the QoS identification data  6  in the switch  22 - 2  is therefore selected. A third case (VM=VM 3  (see  FIG. 11 )) where the priority ranking input section  70  inputs prioritizing B is considered. B of the switch  22 - 1  is  2 , and B in switch  22 - 2  is  1  for QoS identification data  5 ,  6  and is  4  for QoS identification data “ 7 ”. Of  1  and  4 ,  1  is the closest to  2 . However, there are two QoS that designate B to  1 . As illustrated in  FIG. 11 , VM 3  is input prioritizing with S as the second priority ranking (Prio. 2) after the first priority ranking (Prio. 1) B. After B, the QoS identification data is selected preferentially on the basis of S. In the example illustrated in  FIG. 12 , S is  3  in the QoS of the switch  22 - 1 , and in the switch  22 - 2  the QoS for which S is  3  is the QoS identified by the identification data  6 . Thus, in the third case, the identification data  6  is selected. 
         [0084]    At step  220 , the child PP generation section  64  converts the expression formats of the port profile, and modifies the contents of the network service. 
         [0085]    First, explanation is given regarding conversion of the port profile expression formats. As described above, when the port profile of the vendor A is created, the master port profile (MPPA) is generated in advance from the port profile (PPA) in accordance with the rules as illustrated in  FIG. 4  (refer to step S 1 ). At step  220  the child PP generation section  64  reads the rule from the rule definition section  78  to generate the vendor B format port profile from the vendor A port profile. In accordance with the read rules, the child PP generation section  64  generates the port profile PPB that corresponds to vendor B from the master port profile (MPPA). 
         [0086]    Namely, the child PP generation section  64  is able to confirm from the above rules that “TaggedVLAN” in (C) in  FIG. 9  corresponds to “port-profile  10  vlan tag” in (B) in  FIG. 9 . The child PP generation section  64  then associates the “ 100 ” associated with “TaggedVLAN” of the master port profile PPM with “port-profile  10  vlan tag” of the port profile PPB. 
         [0087]    Moreover, the child PP generation section  64  is able to confirm from the above rules that “QoSCoS” in (C) in  FIG. 9  corresponds to the expression format “port-profile  10  qos priority” in (B) in  FIG. 9 . The child PP generation section  64  then initially associates the “ 5 ” associated with “QoSCoS” in the master port profile PPM with the “port-profile  10  qos priority” in the port profile PPB. As described above, when negative determination has been made at step  216 , and at step  218  the network service closest to the network service of the VM migration source network service is selected from the network services of the switch  22 - 2 , and “ 6 ” is applied associated with “port-profile  10  qos priority” in place of the initially associated “ 5 ” as illustrated in  FIG. 12 . 
         [0088]    At step  222  the PP setting section  60  applies (stores) the converted and content-modified port profile to the switch  22 - 2 . At the stage when only the port profile PPB is applied it is unclear which VMs are using the port profile PPB. At step  224  the PP setting section  60  associates the MAC address ( 100 ) used in communication with the VM  17  with the port profile PPB. The processing at step  224  is described with reference to  FIG. 13 . In the example illustrated in  FIG. 13 , the VM  17  that communicates using the MAC address  100 , and the VM  19  that communicates using the MAC address  200 , use the port profile PPA at the switch  22 - 1 . One possible network is built including the VM  17 , the VM  19 , and another VM that communicates with the VM  17  and the VM  19 . As illustrated in (A) in  FIG. 13 , when the VM  17  is migrated to the switch  22 - 2 , the generated port profile PPB on the switch  22 - 2  is applied at step  222 . At the point when the port profile PPB is applied, it is unclear which VMs are using the port profile PPB. However, at step  224  the MAC address and the port profile are associated with one another, and the MAC address  100  used in communication between the VM  17  and the other VM is therefore associated with the port profile PPB after execution of step  224 . 
         [0089]    Next, a case is considered in which after the VM  17 , the VM  19  is also migrated to the server  14  that corresponds to the switch  22 - 2 . At step  208  negative determination is made, and at step  210  it is determined whether or not the port profile for which setting is requested is usable by the migration destination switch  22 - 2 . The port profile PPA used by the VM  19  is already stored on the switch  22 - 2  as the port profile PPB as a result of the migration of the VM  17 . Affirmative determination is accordingly made at step  210 . 
         [0090]    When affirmative determination has been made at step  210 , port profile generation processing transitions to step  226 . At step  226  the child PP generation section  64  determines whether or not the MAC address ( 200 ) used in communication with the migrating VM  19  is applied in connection with the port profile PPA that is usable by the migration destination side switch  22 - 2 . As described above, affirmative determination is made at step  210  when the VM  19  is migrated. At the stage when affirmative determination is made at step  210 , the port profile PPB used by the VM  19  is not usually associated with the MAC address ( 200 ) used in communication with the VM  19 . Thus negative determination is made at step  226 , and at step  224  the PP setting section  60  associates the MAC address ( 200 ) used in communication with the VM  19  with the port profile PPB. Note that when affirmative determination is made at step  226 , port profile generation processing is terminated. 
         [0091]    Explanation follows regarding advantageous effects of the exemplary embodiment. 
         [0092]    According to the exemplary embodiment, when a VM on a given server is migrated to another server, there are cases in which the port profile format of the switch connected to the source server are different to the port profile format of the switch connected to the migration destination server. However, since the rules described above are predefined, the exemplary embodiment exhibits the advantageous effect of enabling the generation of a port profile with a different format (a master port profile) from the port profile. 
         [0093]    Moreover, there are two methods of converting the port profile formats. In a first case rules for generating the port profile format of another vendor from the port profile format of a particular vendor are defined for each vendor. In a second case rules are defined for the generation of a master port profile from a port profile with a different format. In the first case, it is necessary to have rules for the generation of port profiles of all different formats from a particular port profile. In contrast, in the second case, it is sufficient to define a rule for generating a master port profile for each differing port profile format. Thus, when the second case is adopted, the exemplary embodiment exhibits the advantageous effect of enabling a reduction in the number of user created rules. The exemplary embodiment exhibits an additional advantageous effect of enabling the generation of a port profile with the required format from a master port profile. Thus, the exemplary embodiment exhibits the advantageous effect of enabling communication to continue in the same manner as before migration, even when a VM is migrated to a server connected to a switch of a different vendor. 
         [0094]    According to the exemplary embodiment, in cases where the contents of the network service differ, the network service closest to the VM migration source network service is selected from the network services in the migration destination switch. Thus, the exemplary embodiment has an advantageous effect of enabling the port at the migration destination side to be used with a network service close to the network service of the VM migration source. 
         [0095]    Moreover, it is determined (step  210 ) whether or not the port profile for which setting is requested is usable by the migration destination side switch, and when determined that the port profile is usable by the migration destination side switch, the port profile is set on the migration destination side switch. Thus, the exemplary embodiment has an advantageous effect of enabling the prevention of duplicate port profiles being set. 
         [0096]    The MAC address of a migrating VM is not usually associated with the port profile of the migration destination side switch or stored in memory. However, a case where the MAC address of a migrating VM is associated with the port profile and stored in the memory of the migration destination side switch may arise as a result of a mistake by a user. According to the exemplary embodiment, it is determined (step  208 ) whether or not the MAC address used in communication with the migrating VM is stored in the memory of the migration destination side switch. In cases where the MAC address used in communication with the migrating VM is not stored in the memory of the migration destination side switch, the MAC address for use in communication with the migrating VM is stored in the memory of the migration destination side switch. Thus, the exemplary embodiment exhibits the advantageous effect of enabling the setting of duplicate MAC addresses to be avoided. 
         [0097]    Explanation follows regarding modified examples of the exemplary embodiment. 
         [0098]    According to the exemplary embodiment, in cases where the VM is migrated, and the migration destination side switch port profile has different formats from the VM migration source, an attempt is made to generate a port profile for the migration destination. However, the present invention is not limited to cases where a VM is migrated. Namely, as described above, the formats of the port profiles differ according to the switch model and OS. As an example of a modification, a master port profile is generated from the switch port profile in accordance with the switch model and OS based on the rules described above. Furthermore, in cases where the model or the OS or both are changed, a port profile is generated that corresponds to the format of the changed model and OS. 
         [0099]    In the exemplary embodiment, explanation has been given of QoS as an example of a network service; however, processing may be performed in a similar manner with another network service such as access control list (ACL). 
         [0100]    An exemplary embodiment exhibits the advantageous effect of enabling usage mode data of a particular format to be generated from usage mode data of a different format. 
         [0101]    All cited documents, patent applications and technical standards mentioned in the present specification are incorporated by reference in the present specification to the same extent as if the individual cited documents, patent applications and technical standards were specifically and individually incorporated by reference in the present specification. 
         [0102]    All examples and conditional language provided herein are intended for the pedagogical purposes of aiding the reader in understanding the invention and the concepts contributed by the inventor to further the art, and are not to be construed as limitations to such specifically recited examples and conditions, nor does the organization of such examples in the specification relate to a showing of the superiority and inferiority of the invention. Although one or more embodiments of the present invention have been described in detail, it should be understood that the various changes, substitutions, and alterations could be made hereto without departing from the spirit and scope of the invention.