3.3.1 Using IM Configuration Management to manage a virtualization configuration

(a) Conditions for a manageable virtualization configuration

When you manage a KVM, you can manage the virtualization system configuration without virtualization environment management software. To manage virtualization software other than KVM, one of the following virtualization environment managers must be installed on the virtualization system management host.

• vCenter

• JP1/SC/CM

• SCVMM

• HCSM

The following table describes the requirements for using the above virtualization environment managers. The table after that gives the requirements for KVM.

Table 3‒1: Requirements for virtualization environment management software

Virtualization environment management software	Requirements for the manager	Requirements for the virtualization system management host	Requirements for the VMM host on which the guest OS is running	Requirements for the guest OS
vCenter	The user ID and the password of the account for accessing the vCenter host to which the manager connects are registered in IM Configuration Management.	The manager can communicate with the host on which vCenter is running.	VMware ESX has been installed.	VMware Tools are installed on the guest OSs running on VMware ESX hosts, and IP addresses and host names are assigned to the guest OSs.
JP1/SC/CM	None.	The manager can communicate with JP1/Base on the host on which JP1/SC/CM is running.	Hitachi Compute Blade logical partitioning feature has been installed.	IP addresses and host names are assigned to the guest OSs managed by Hitachi Compute Blade logical partitioning feature.
SCVMM	The domain name of the SCVMM host to which the manager connects, the names of users with administrator privileges in the domain, and the passwords of such users are registered in IM Configuration Management. The SCVMM management console is installed on the manager.#1, #2 The version of the SCVMM management console matches the version of the SCVMM on the collection-target virtualization system management host.	The OS on the host on which SCVMM is running is Windows Server 2012 or Windows Server 2008 R2. The SCVMM management console that is installed on the manager can communicate with the SCVMM that is installed on the virtualization system management host. The version of SCVMM matches the virtualization system management hosts that are specified as collection targets by a specific manager.	Hyper-V or vCenter has been installed.	Hyper-V Integrated Services is installed on the guest OSs running on Hyper-V hosts, and IP addresses and host names are assigned to the guest OSs.
HCSM	The user name, the password, and the port number of the HCSM host to which the manager connects are registered in IM Configuration Management. HTTP communication can be used with the above user name, password, and port number on the HCSM host to which the manager connects.	None.	HCSM manages the chassis and blade on which Hitachi Compute Blade logical partitioning feature is running. HCSM manages the host whose virtualization system configuration is to be collected.	IP addresses and host names are assigned to the guest OSs managed by Hitachi Compute Blade logical partitioning feature.

#1: Do not install different versions of SCVMM management console on the same manager.

#2: Check prerequisite OSs for installing the SCVMM management console beforehand.

Table 3‒2: Requirements for KVM

Requirements for the manager	Requirements for the VMM host on the virtual host	Requirements for the guest OS
The OS user ID, the password of the private key, and port number of the KVM host to which the manager connects are registered in IM Configuration Management. The manager can connect to the KVM host to which the manager wants to connect with SSH based on the information registered in IM Configuration Management. The OS user registered in IM Configuration Management has root privileges.	The public key required for SSH connection with the manager has been distributed.	IP addresses and host names are assigned to the guest OSs managed by KVM. The guest OSs managed by KVM can resolve the IP address and host name of the local host. The host names of the guest OSs managed by KVM are the same as the host identification names defined by KVM.# If the host names of the guest OSs are changed, the host identification names defined by KVM are also redefined as the same names.

#: When you collect the virtualization configuration information of KVM, collect the host identification name (called a domain name in KVM) displayed in Id Name when the virsh list command is executed, defined by KVM as the host name of a virtual host.

For details, see 7.3 Virtualization configuration management in the JP1/Integrated Management 2 - Manager Overview and System Design Guide.

(b) Conditions of JP1/Base for managing a virtualization configuration

Make sure that the following settings of JP1/Base satisfy the prerequisites for managing a virtualization configuration.

• JP1 permission levels

  Use either of the following JP1 permission levels when using IM Configuration Management to manage a virtualization configuration.

  • JP1_CF_Admin

  • JP1_CF_Manager

  When you use IM Configuration Management - View to apply a virtualization system configuration to Central Scope, the JP1 user who logs on to IM Configuration Management - View must have the following permissions:

  • JP1 resource group: JP1_Console

  • JP1 permission level: JP1_Console_Admin

• Requirements for registering hosts

  • When you register host names you obtain from the virtualization configuration information in IM Configuration Management without change, check whether the name of the event server of JP1/Base running on the hosts to be registered satisfies the following requirements:

    - When you register short host names in IM Configuration Management, the name of the event server of JP1/Base running on the hosts to be registered is a short name.

    - When you register FQDN host names in IM Configuration Management, the name of the event server of JP1/Base running on the hosts to be registered is an FQDN.

  • If the host names obtained from the virtualization configuration information differ from the host names you want to register in IM Configuration Management, use the Register Host window to register the hosts with the host names you want registered in IM Configuration Management.

(a) Using the Register Host window to register virtual hosts

Invoke the Register Host window from the IM Configuration Management window to register new virtual hosts.

1. In the IM Configuration Management window, click the Host List tab to display the Host List page.

2. Use either of the following methods to display the Register Host window:

   • In the tree area, select Host List. From the menu bar, choose Edit, and then Register Host.

   • In the tree area, right-click Host List to display a pop-up menu and then choose Register Host.

3. In the Register Host window, enter information in the blank boxes to register a new host.

   In the Host type section, select Physical host or Virtual host from the drop-down list.

   When you select Physical host in the Host type section

   In the Virtual Manager Settings window, in the Virtual Manager Type section, from the top drop-down list, select the name of virtualization management software installed on the host.

   When you select Virtual host in the Host type section

   In the VMM host box, specify the name of the host on which virtualization software is installed.

   In the Virtual Manager Type box, specify the name of the virtualization management software that manages the host.

(b) Collecting virtualization configuration information on the virtualization system management host

Collect virtualization configuration information on the virtualization system management host and set the virtualization configuration information of the managed host in IM Configuration Management.

For details about how to collect virtualization configuration information on the virtualization system management host, see 3.3.2 Collecting virtualization system configuration information.

(a) Obtaining certificates

The two ways to obtain an SSL certificate from VMware ESX are by using Internet Explorer and by obtaining the certificate files directly. To obtain an SSL certificate from vCenter, use Internet Explorer. This subsection describes both methods.

(b) Installing certificates in IM Configuration Management

Install the obtained certificate in IM Configuration Management using the procedure described below.

(c) Deleting certificates from IM Configuration Management

This subsection explains how to delete certificates from IM Configuration Management.

(a) Configuring an SSH server

To configure an SSH server:

1. Log on to the host on which KVM has been installed as a user with root privileges.

2. Open /etc/ssh/sshd_config.

3. Set yes for PubkeyAuthentication^#1.

4. Set no for UseDNS^{#1, #2}.

5. Set yes for PermitRootLogin^#1.

6. Execute the following command to restart the sshd service.

   /etc/rc.d/init.d/sshd restart

   Note that these commands might differ depending on the version of the OS. For details, see the documentation of the applicable OS.

#1

For details about the items to be set and how to set them in sshd_config, see the documentation for your SSH server.

#2

If you do not set these items, make sure that the host on which KVM has been installed can perform name resolution as follows.

• The host can resolve the IP address of the manager host to the manager host name.

• The IP address resolved from the host name of the manager host matches the IP address of the manager host.

If you are using a DNS server for name resolution and the host on which KVM has been installed cannot connect to the DNS server, the collection of virtualization configuration information from KVM might be delayed. If a delay occurs, startup or collection might time out and fail. To prevent this problem, we recommend that you set no for UseDNS and LookupClientHostnames.

(b) Initially creating keys

Log on to the host on which KVM has been installed as a user who collects virtualization configuration information from KVM and execute the ssh-keygen command to create keys. You only need to do this the first time that you create keys.

You can choose the type of keys (RSA or DSA).

Before you start the procedure, make sure that only the owner of the keys has write permission for the directory above the .ssh directory. If anyone other than the owner has write permission for the higher-level directory, SSH connections will fail.

1. Log on to the host on which KVM has been installed as a user who can collect virtualization configuration information from KVM.

2. Execute the ssh-keygen command.

   Enter the command as follows:

   • When creating RSA keys: ssh-keygen -t rsa

   • When creating DSA keys: ssh-keygen -t dsa

3. Determine the name of the file in which the private key will be stored and the directory that will hold the file.

   The path and the file name must not contain multibyte characters. The default setting is ~/.ssh/id_rsa.

4. Press the Return key twice.

   When you are prompted to enter the passphrase for the private key, enter nothing and press the Return key. When you are prompted again, enter nothing and press the Return key again.

   The following is an example of executing the ssh-keygen -t rsa command.

   [root@HOST]$ ssh-keygen -t rsa

   Generating public/private rsa key pair.

   Enter file in which to save the key (/home/ssh-user/.ssh/id_rsa):

   Enter passphrase (empty for no passphrase):

   Enter same passphrase again:

   Your identification has been saved in /home/ssh-user/.ssh/id_rsa.

   Your public key has been saved in /home/ssh-user/.ssh/id_rsa.pub.

   The key fingerprint is:

   ax:xx:xx:xx:xx:bx:xx:xc:xx:xx:xx:xd:xd:xa:ed:xx root@HOST

5. Execute the cat command to add the public key file to the authentication key file.

6. Execute the chmod command to change the attribute of the authentication key file to 600.

   The following is an example of executing the cat and chmod commands.

   [ClientUser@TargetHost .ssh]$ cat id_rsa.pub >> authorized_keys

   [ClientUser@TargetHost .ssh]$ chmod 600 authorized_keys

7. Configure AuthorizedKeysFile in /etc/ssh/sshd_config.

   By default, ~/.ssh/authorized_keys or .ssh/authorized_keys is set. If you change the path for the authentication key file created in step 6, check and, if necessary, revise the value of AuthorizedKeysFile. If you change any settings in sshd_config, restart the sshd service as a superuser.

Cautionary notes

• Manage private keys with the utmost care.

• The creation of keys (public key and a private key pair) does not depend on any environment or tool. You can create keys in any environment using any tool. However, after you create keys, you must place the private keys and public keys in the appropriate locations.

(c) Placing the private key on the JP1/IM - Manager host (when keys are initially created)

When the OS of the JP1/IM - Manager host is Windows, place the private key created as described in 3.3.1(8)(b) Initially creating keys on the JP1/IM - Manager host running Windows. The path for the location of the private key must not contain multibyte characters. This only needs to be done the first time that keys are created.

(d) Placing the public key on the host on which KVM has been installed (when keys have already been created)

Place the public key created in 3.3.1(8)(b) Initially creating keys on the host on which KVM has been installed. To do so, follow the procedure below. Note that this only needs to be done when keys were created on another host.

Before you start the procedure, make sure that only the owner of the keys has write permission for the directory above the .ssh directory. If anyone other than the owner has write permission for the higher-level directory, SSH connections will fail.

1. Log on to the host on which KVM has been installed as a user who can collect virtualization configuration information from KVM.

2. Navigate to the .ssh directory.

   If the home directory of the user who collects virtualization configuration information from KVM does not contain the .ssh directory, create one. Set 700 as the attribute of the directory.

3. Execute the scp command to copy the public key file to the host on which KVM has been installed.

   Copy the public key file created as described in 3.3.1(8)(b) Initially creating keys to the monitored host. Copy the file to the .ssh directory in the home directory of the user who will collect virtualization configuration information from KVM.

4. Execute the cat command to add the contents of the public key file to the authentication key file.

5. Delete the copied public key file.

6. Execute the chmod command to change the attribute of the authentication key file to 600.

7. Configure AuthorizedKeysFile in /etc/ssh/sshd_config.

   By default, ~/.ssh/authorized_keys or .ssh/authorized_keys is set. If you change the path for the authentication key file created in step 6, check and, if necessary, revise the value of AuthorizedKeysFile. If you change any settings in sshd_config, restart the sshd service as a superuser.

An example of executing the scp, cat, and chmod commands is shown below. In this example, the host name of the host where keys are created as described in 3.3.1(8)(b) Initially creating keys is IMHost.

• Example of executing the commands:

  [ClientUser@TargetHost ]$ cd .ssh

  [ClientUser@TargetHost .ssh]$ scp

  root@IMHost:/home/ssh-user/.ssh/id_rsa.pub ./

  root@IMHost's password: Enter a password here.

  id_rsa 100% 233 0.2KB/s 00:00

  [ClientUser@TargetHost .ssh]$ cat id_rsa.pub >> authorized_keys

  [ClientUser@TargetHost .ssh]$ rm id_rsa.pub

  [ClientUser@TargetHost .ssh]$ chmod 600 authorized_keys

(e) Checking connections

When SSH client software is installed on the JP1/IM - Manager host in a Windows environment, use the private key placed on the host as described in 3.3.1(8)(c) Placing the private key on the JP1/IM - Manager host (when keys are initially created) and check whether you can establish an SSH connection with the host on which KVM has been installed. In addition, when you establish an SSH connection, make sure that a password and passphrase do not need to be entered.

If an error occurs or you are prompted to enter a password and a passphrase, check whether the settings are specified correctly as described. Also check the settings of the OS to make sure that the OS will allow SSH connections.

Note that when virtualization configuration information from KVM is collected, the following commands must be executable on the hosts on which KVM has been installed. Make sure that the users that collect virtualization configuration information from KVM can execute these commands. If these commands cannot be executed, make sure that KVM has been installed correctly and that the command path has been set correctly.

• virsh version

• virsh list --all

(a) Configuring an SSH server

To configure an SSH server:

1. Log on to the host on which KVM has been installed as a user with root privileges.

2. Open /etc/ssh/sshd_config.

3. Set yes for PubkeyAuthentication^#1.

4. Set no for UseDNS^{#1, #2}.

5. Set yes for PermitRootLogin^#1.

6. Execute the following command to restart the sshd service.

   /etc/rc.d/init.d/sshd restart

   Note that these commands might differ depending on the version of the OS. For details, see the documentation of the applicable OS.

#1

For details about the items to be set and how to set them in sshd_config, see the documentation for your SSH server.

#2

If you do not set these items, make sure that the host on which KVM has been installed can perform name resolution as follows.

• The host can resolve the IP address of the manager host to the manager host name.

• The IP address resolved from the host name of the manager host matches the IP address of the manager host.

If you are using a DNS server for name resolution and the host on which KVM has been installed cannot connect to the DNS server, the collection of virtualization configuration information from KVM might be delayed. If a delay occurs, startup or collection might time out and fail. To prevent this problem, we recommend that you set no for UseDNS and LookupClientHostnames.

(b) Initially creating keys

Log on to the JP1/IM - Manager host in a UNIX environment a user with root privileges and execute the ssh-keygen command to create keys. You only need to do this the first time that you create keys.

You can choose the type of keys (RSA or DSA).

1. Log on to the JP1/IM - Manager host as a user with root privileges.

2. Execute the ssh-keygen command.

   Enter the command as follows:

   • When creating RSA keys: ssh-keygen -t rsa

   • When creating DSA keys: ssh-keygen -t dsa

3. Determine the names of the file in which the private key will be stored and the directory that will hold the file.

   The path and the file name must not contain multibyte characters. The default setting is ~/.ssh/id_rsa.

4. Press the Return key twice.

   When you are prompted to enter the passphrase for the private key, enter nothing and press the Return key. When you are prompted again, enter nothing and press the Return key again.

   The following is an example of executing the ssh-keygen -t rsa command.

   [root@HOST]$ ssh-keygen -t rsa

   Generating public/private rsa key pair.

   Enter file in which to save the key (/home/ssh-user/.ssh/id_rsa):

   Enter passphrase (empty for no passphrase):

   Enter same passphrase again:

   Your identification has been saved in /home/ssh-user/.ssh/id_rsa.

   Your public key has been saved in /home/ssh-user/.ssh/id_rsa.pub.

   The key fingerprint is:

   ax:xx:xx:xx:xx:bx:xx:xc:xx:xx:xx:xd:xd:xa:ed:xx root@HOST

Cautionary notes

• Manage private keys with the utmost care.

• The creation of keys (public key and a private key pair) does not depend on any environment or tool. You can create keys in any environment using any tool. However, after you create keys, you must place the private keys and public keys in the appropriate locations.

(c) Placing the public key on the host on which KVM has been installed

Place the public key created in 3.3.1(9)(b) Initially creating keys on the host on which KVM has been installed. To do so, follow the procedure below.

Before you start the procedure, make sure that only the owner of the keys has write permission for the directory above the .ssh directory. If anyone other than the owner has write permission for the higher-level directory, SSH connections will fail.

1. Log on to the host on which KVM has been installed as a user who can collect virtualization configuration information from KVM.

2. Navigate to the .ssh directory.

   If the home directory of the user who collects virtualization configuration information from KVM does not contain the .ssh directory, create one. Set 700 as the attribute of the directory.

3. Execute the scp command to copy the public key file to the host on which KVM has been installed.

   Copy the public key file created as described in 3.3.1(9)(b) Initially creating keys to the host on which KVM has been installed. Copy the file to the .ssh directory in the home directory of the user who will collect virtualization configuration information from KVM.

4. Execute the cat command to add the contents of the public key file to the authentication key file.

5. Delete the copied public key file.

6. Execute the chmod command to change the attribute of the authentication key file to 600.

7. Configure AuthorizedKeysFile in /etc/ssh/sshd_config.

   By default, ~/.ssh/authorized_keys or .ssh/authorized_keys is set. If you change the path for the authentication key file created in step 6, check and, if necessary, revise the value of AuthorizedKeysFile. If you change any settings in sshd_config, restart the sshd service as a superuser.

An example of executing the scp, cat, and chmod commands is shown below. In this example, the host name of the JP1/IM - Manager host where keys are created as described in 3.3.1(9)(b) Initially creating keys is IMHost.

• Example of executing the commands:

  [ClientUser@TargetHost ]$ cd .ssh

  [ClientUser@TargetHost .ssh]$ scp root@IMHost:/home/ssh-user/.ssh/id_rsa.pub ./

  root@IMHost's password: Enter a password here.

  id_rsa.pub 100% 233 0.2KB/s 00:00

  [ClientUser@TargetHost .ssh]$ cat id_rsa.pub >> authorized_keys

  [ClientUser@TargetHost .ssh]$ rm id_rsa.pub

  [ClientUser@TargetHost .ssh]$ chmod 600 authorized_keys

(d) Checking connections

To check whether the JP1/IM - Manager host can connect to the host on which KVM has been installed:

1. Log on to the JP1/IM - Manager host as a user with root privileges.

2. Use the created private key to execute the ssh command on the host on which KVM has been installed.

If the connection succeeds without any entry, the SSH setting has been completed.

If an error occurs or you are prompted to enter a password and a passphrase, check whether the settings are specified correctly as described. Also check the settings of the OS to make sure that the OS will allow SSH connections.

The following example executes the ssh command to check connections:

In this example, the host name of the JP1/IM - Manager host is IMHost, the host name of the monitored host is TargetHost, and the user name that will collect virtualization configuration information from KVM is ssh-user.

• Example of executing the commands:

  [root@IMHost]$ /usr/bin/ssh -i /home/ssh-user/.ssh/id_rsa -p 22 ssh-user@TargetHost

  The authenticity of host 'TargetHost (xxx.xxx.xxx.xxx)' can't be established.

  RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.

  Are you sure you want to continue connecting (yes/no)? yes

  Warning: Permanently added 'TargetHost,xxx.xxx.xxx.xxx' (RSA) to the list of known hosts.

  Last login: Mon Mar 23 17:17:52 2011 from xxx.xxx.xxx.xxx

  [ssh-user@TargetHost ~]$ exit

  logout

  Connection to TargetHost closed.

  [root@IMHost]$

Note that when virtualization configuration information from KVM is collected, the following commands must be executable on the hosts on which KVM has been installed. Make sure that the users that collect virtualization configuration information from KVM can execute these commands. If these commands cannot be executed, make sure that KVM has been installed correctly and that the command path has been set correctly.

• virsh version

• virsh list --all