Top
PRIMECLUSTER  Installation and Administration Guide 4.4
FUJITSU Software

G.2.2 Using the Host OS failover function

Perform the following procedure on guest OSes in which the Migration is performed and all host OSes.

You need to perform this procedure only once and not for each Migration.

  1. Creation of kvmguests.conf file (host OS)

    Perform the following procedure on all host OSes to create the kvmguest.conf file. The file named kvmguests.conf must be the same on all host OSes. For PRIMEQUEST, if the file is already created when the host OS failover function was set, it is not required to perform the procedure again.

    1. Check the setting information.

      When performing migration, log in to the guest OS (cluster node) via SSH to change the settings of the shutdown facility.

      Prior to the settings, confirm the following information that are required for the settings.

      • IP address of the guest OS

      • Domain name of the guest OS

      • Cluster name of the guest OS

      • CF node name of the guest OS

    2. Create the user (when logging in to the guest OS not as a root user).

      Create the user (when logging in to the guest OS not as a root user).

      Take the following steps on the guest OS to be migrated.

      1. Create the login user.

        Set the user password with seven-bit ASCII characters except the following characters.

        >  <  "  /  \  =  !  ?  ;  ,  &
      2. Set the sudo command so that the created user can execute the command as a root user.

        Execute the visudo command by using the sudo command. Describe the following setting in the displayed setting file.

        <User created in step (1)>    ALL=(root) NOPASSWD: ALL
    3. Encrypt the password.

      Execute the sfcipher command to encrypt the user password (for the user created as a root user or the user created in step 2) to log in to the guest OS via SSH.

      For information on how to use the sfcipher command, see the "sfcipher" manual page.

      # sfcipher -c
      Enter User's Password:
      Re-enter User's Password:
      D0860AB04E1B8FA3
    4. Create /etc/opt/FJSVcluster/etc/kvmguests.conf.

      Create /etc/opt/FJSVcluster/etc/kvmguests.conf with the following contents.

      Create the kvmguests.conf file as a root user. Set the permission as 600.

      guest-name host-cfname guest-clustername guest-cfname guest_IP guest_user guest_passwd
        :
      • Enter the information of one node in one line.

      • Delimit each item with a single space.

      • The kvmguests.conf file must be the same on all cluster nodes.

        guest-name         :Specify the domain name of the guest OS to be migrated.
        host-cfname        :Specify the CF node name of the host OS in which "guest-name"
                            is running.
                            If you execute "cftool -l" on the host OS in which "guest-name"
                            is running, you can confirm the CF node name of the node.
        guest-clustername  :Specify the cluster name of the guest OS.
                            If you execute "cftool -c" on the guest OS, you can confirm
                            the cluster name of the node.
        guest-cfname       :Specify the CF node name of the guest OS.
                            If you execute "cftool -l" on the guest OS, you can confirm
                            the CF node name of the node.
        guest_IP           :Specify the IP address of the guest OS.
                            Available IP address formats are IPv4 and IPv6 addresses.
                            IPv6 link local addresses are not available.
        guest_user         :Specify the user name for logging in to the guest OS.
                            Specify the user created as a root user or the created in step 2.
        guest_passwd       :Specify the user password for logging in to the guest OS.
                            Specify the password encrypted in step 3.

      Example: In a two-node configuration between guest OSes, two cluster systems are configured

      guest11 cfhost1 cluster1 cfguest11  10.20.30.50 user1 D0860AB04E1B8FA3
      guest12 cfhost2 cluster1 cfguest12  10.20.30.51 user2 D0860AB04E1B8FA3
      guest21 cfhost1 cluster2 cfguest21  10.20.30.60 user3 D0860AB04E1B8FA3
      guest22 cfhost2 cluster2 cfguest12  10.20.30.61 user4 D0860AB04E1B8FA3
    5. Confirm the log in to the guest OS.

      The shutdown facility accesses the target node with SSH during migration. Therefore, you need to authenticate yourself (create the RSA key) in advance, which is required when using SSH for the first time.

      Check that you can connect to all the guest OSes (nodes) which are defined to /etc/opt/FJSVcluster/etc/kvmguests.conf via SSH as a root user. Execute the command as a root user.

      # ssh -l user XXX.XXX.XXX.XXX
      The authenticity of host 'XXX.XXX.XXX.XXX (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  <- Enter "yes."
    6. Check the setting in /etc/opt/FJSVcluster/etc/kvmguests.conf.

      Execute the sfkvmtool command on all the host OSes to make sure that the settings in /etc/opt/FJSVcluster/etc/kvmguests.conf are correct. If the settings are correct, the following message is output.

      # /opt/SMAW/SMAWsf/bin/sfkvmtool -c
      NOTICE: The check of configuration file succeeded.

      If a message other than above is output, review the setting in /etc/opt/FJSVcluster/etc/kvmguests.conf.

    7. Start the shutdown facility.

      Check that the shutdown facility has already been started on all the nodes.

      # sdtool -s

      If the shutdown facility has already been started, execute the following on all the nodes to restart it.

      # sdtool -e
      # sdtool -b

      If the shutdown facility has not been started, execute the following on all the nodes to start it.

      # sdtool -b
  2. Registration of host OS information (host OS)

    Execute the following command on the all host OSes to register the host OS information.

    # /opt/SMAW/SMAWsf/bin/sfkvmmigratesetup -c -i hostip [-w off]
    hostip

    Specify the IP address of the host OS on which this command was executed.

    Available IP address formats are IPv4 and IPv6.

    IPv6 link local addresses are not available.

    -w off

    Specify this option if the weights of the guest OS shutdown facility and that of the host OS shutdown facility should not be linked when migrating the guest OS.
    Without this option, linkage of the weights of the guest OS shutdown facility and the host OS shutdown facility is enabled when migrating the guest OS.
    This option must be the same on all host OSes.

  3. Setting up guest OSes (host OS/guest OS)

    Perform following procedure on all guest OSes.
    It is alternative to perform following procedure on all guest OSes at a time or one by one.

    1. Stopping of guest OS

      Execute the following command on the guest OS to stop the guest OS.

      # /sbin/shutdown -P now
    2. Settings to look up host OS information

      On the host OS where the guest OS is stopped, execute the following command to enable the guest OS to look up the host OS information file.

      # /opt/SMAW/SMAWsf/bin/sfkvmmigratesetup -s domain
      domain

      Specify the domain name of the guest OS.

    3. Startup of guest OS

      Start the guest OS.

  4. Creating the user ID in the destination host OS (host OS)

    Create the user ID in the destination host OS.

    For the detailed procedure, see "3.2.3.1.4 Host OS setup (after installing the operating system on guest OS)."

  5. Login to the destination host OS (guest OS)

    Log in to the destination host OS from all guest OSes and authenticate yourself (create the RSA key) in advance, which is required when using SSH for the first time.

    Log in to the destination host from all guest OSes with the host OS account specified in libvirt shutdown agent.

    # ssh -l user XXX.XXX.XXX.XXX
    The authenticity of host 'XXX.XXX.XXX.XXX (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 <- Input yes