JP2016110183A

JP2016110183A - 情報処理システム及び情報処理システムの制御方法

Info

Publication number: JP2016110183A
Application number: JP2014243835A
Authority: JP
Inventors: 岩松　昇; Noboru Iwamatsu; 昇岩松
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2014-12-02
Filing date: 2014-12-02
Publication date: 2016-06-20
Also published as: US20160154664A1

Abstract

【課題】高速で安全にマイグレーションを実行する。【解決手段】情報処理システムは、複数の情報処理装置と、複数の情報処理装置を管理する管理装置とを有し、複数の情報処理装置のうち第１の情報処理装置は、仮想マシンを起動する起動部と、仮想マシンの再起動を検出する再起動検出部と、再起動の検出に応答して仮想マシンを遮断する遮断部とを有し、複数の情報処理装置のうち第２の情報処理装置は、第１の情報処理装置の仮想マシンが遮断された後、遮断された仮想マシンを起動する旨の起動指示を受信した場合、遮断された仮想マシンを起動する起動部を有する。【選択図】図１

Description

本発明は、情報処理システム及び情報処理システムの制御方法に関する。

仮想化技術は、コンピュータまたは物理マシンである情報処理装置（以下、情報処理装置をコンピュータまたは物理マシン、または単にホストマシン、ホストとも称する。）上で動作するハイパーバイザが、物理マシンのハードウエアをエミュレートし、物理マシン上に複数の仮想マシン（またはVM: Virtual Machine）を起動して生成する。そして、仮想化技術は、複数の物理マシンに複数の仮想マシンを生成して、複数の利用者のサービスシステムを実現する。仮想マシンが起動・生成される物理マシンは、ホストマシンまたは単にホストとも称される。

このような仮想化技術において、仮想マシンを移行元ホストから移行先ホストに移行するライブマイグレーションは、物理マシンのメンテナンスや、仮想マシンを別の物理マシンに集約する場合に必要になる。ライブマイグレーションは、仮想マシンを稼働状態のまま別の物理マシンに移行させる技術である。ライブマイグレーションを利用することで、仮想マシンにより構築されているサービスシステムを停止することなく、仮想マシンを別の物理マシンに移行（マイグレート）することができる。

特開２０１１−２４８６１６号公報特開２０１１−１１８５５７号公報特開１０−２８３２１０号公報特開２００４−１３３８９２号公報

仮想マシンのライブマイグレーションは、（１）移行元ホストで稼働中の仮想マシンのメモリ内容を移行先ホストに転送し、（２）移行元ホストで仮想マシンを一時停止した状態で転送中に変更されたメモリ内容、CPUのレジスタ情報であるコンテキスト、I/O状態を含むハードウエアのエミュレーション状態などを移行先ホストに転送し、（３）移行先ホストで仮想マシンをリジュームする処理を有する。

そのため、メモリ内容の転送時間が長くなり、ホスト間のネットワークに負荷がかかる。特に、メモリの書き換え頻度が高い仮想マシンでは、メモリ内容の転送に要する時間が長くなり、変更データ（ダーティページ）の再転送の発生により、転送時間が予測しにくい。さらに、多数のホストマシンで多数の仮想マシンを起動する大規模なクラウドシステムでは、ホストマシンのメンテナンスのために仮想マシンをライブマイグレーションすることは、長時間を要し、ネットワークの多くの帯域を使用することになるという課題を有する。

また、ライブマイグレーションでは、移行元ホストと移行先ホストのハイパーバイザのバージョンが異なる場合、移行元ホストでのハードウエアのエミュレート状態を移行先ホストに引き継ぐことができないなどの理由で、マイグレーションが失敗することがある。

ライブマイグレーションの改善方法として、メモリ内容を圧縮してメモリ内容の転送時間を短縮することが提案されているが、メモリ内容の圧縮処理によりCPU使用率が上昇するので、改善効果はそれほど期待できない。また、移行先ホストに事前に仮想マシンのメモリを転送しておく場合は、移行先ホストのメモリリソースを浪費することになり好ましくない。

そこで、実施の形態の第１の側面の目的は、高速で確実に仮想マシンをマイグレーションできる情報処理システム及び情報処理システムの制御方法を提供することにある。

本実施の形態の第１の側面は、複数の情報処理装置と、
前記複数の情報処理装置を管理する管理装置とを有し、
前記複数の情報処理装置のうち第１の情報処理装置は、
仮想マシンを起動する起動部と、
前記仮想マシンの再起動を検出する再起動検出部と、
前記再起動の検出に応答して前記仮想マシンを遮断する遮断部とを有し、
前記複数の情報処理装置のうち第２の情報処理装置は、
前記第１の情報処理装置の仮想マシンが遮断された後、前記遮断された仮想マシンを起動する旨の起動指示を受信した場合、前記遮断された仮想マシンを起動する起動部を有する情報処理システムである。

第１の側面によれば、仮想マシン利用者の利便性を損なうことなく、高速で確実に仮想マシンをマイグレーションできる。

本実施の形態における情報処理システムの構成を示す図である。図１の各ホスト１、２、３と管理サーバ４とソフトウエアアップデートサービスサーバ５の概略構成を示す図である。図１に示した共有ストレージ２０の構成を示す図である。ハイパーバイザの一部のコマンドとその処理内容を示す図表である。ライブマイグレーションの処理を示すフローチャート図である。本実施の形態におけるリブートをトリガとするマイグレーションの処理を示すフローチャート図である。本実施の形態におけるリブートをトリガとするマイグレーションの処理を示すシーケンス図である。本実施の形態におけるリブートをトリガとするマイグレーションの処理を示すシーケンス図である。本実施の形態におけるリブートをトリガとするマイグレーションの処理の変形例を示すフローチャート図である。本実施の形態における仮想マシンのリブート動作と検出処理を示すフローチャート図である。本実施の形態におけるRDM管理モジュールRDM＿Mに設定されるリブート検出時の処理テーブル例を示す図である。第２の実施の形態におけるリブートをトリガにするマイグレーションの処理を示すフローチャート図である。第２の実施の形態におけるリブートをトリガにするマイグレーションの処理を示すフローチャート図である。第２の実施の形態におけるリブートをトリガにするマイグレーションの処理を示すフローチャート図である。第２の実施の形態における移行計画テーブルの一例を示す図である。第３の実施の形態におけるリブートをトリガにするマイグレーションの処理を示すフローチャート図である。第３の実施の形態におけるリブートをトリガにするマイグレーションの処理を示すフローチャート図である。第３の実施の形態におけるリブートをトリガにするマイグレーションの処理を示すフローチャート図である。第３の実施の形態における移行計画テーブルの例を示す図である。

以下の説明では、適宜、情報処理装置である物理マシンにインストールされたソフトウエアが、ソフトウエアの機能を実行する旨の説明を行う。このような動作は、正確に表現すると、物理マシンがソフトウエアを実行することで、ソフトウエアが有するある機能を実行することを意味する。しかし、以下の説明では、単に、ソフトウエアがその機能を実行する旨の表現で簡略的に説明する場合もある。

［本実施の形態における情報処理システム］
図１は、本実施の形態における情報処理システムの構成を示す図である。情報システムは、仮想マシンVMをハイパーバイザHV上で実行する複数の物理マシン（ホスト）１、２、３と、仮想マシンを管理する管理サーバ（MS）４と、共有ストレージ２０とを有する。

各ホスト１、２、３は、ハイパーバイザHVを実行して、一つのまたは複数の仮想マシンVMを起動し実行する。別の表現をすると、ハイパーバイザHVが仮想マシンVMを起動し実行する。共有ストレージ２０は、仮想マシンVMのゲストOS(Operating System)や、アプリケーションプログラムなどのイメージファイルを記憶する。仮想マシンVMは、共有ストレージ２０内に格納されたイメージファイルのゲストOSとアプリケーションプログラムを実行して、所望のサービスシステムを構築する。

管理サーバ４のVM管理ソフトウエア４＿１は、ハイパーバイザHVにコンフィグレーション情報に基づく仮想マシンを起動させ、必要に応じて仮想マシンを一時停止（ポーズ）及び再開（リジューム）させ、遮断（デストロイ）させる。また、管理サーバ４のVM管理ソフトウエア４＿１は、ハイパーバイザHVから仮想マシンの動作状態の情報を収集し、必要に応じて仮想マシンを稼働中の物理マシンから別の物理マシンに移行（マイグレーション）させる。さらに、管理サーバ４のVM管理ソフトウエア４＿１は、仮想マシンで構築されたサービスシステムの利用者端末６にポータルサイトを提供し、サービスシステムの利用者端末６からのサービスシステムの維持管理を可能にする。

各ホスト１、２、３と管理サーバ４と共有ストレージ２０とは、管理ネットワークM_NWを介して通信可能にされている。利用者端末６は、外部ネットワークEX_NWを介して管理サーバ４が提供するクラウドコンピューティングサービスのポータルサイト４＿３にアクセス可能である。さらに、情報処理システムの運用管理者端末７は、例えば管理ネットワークM_NWを介して管理サーバ４にアクセス可能である。また、各仮想マシンVMは、VMネットワークVM_NWを介して通信可能にされている。図１では、各仮想マシンVMに直接VMネットワークMV_NWが接続されるように記載されているが、実際には、仮想マシンVMは、ホスト１、２、３のネットワークインターフェースを介してVMネットワークMV_NWに接続される。

図１の情報処理システムは、ソフトウエアアップデートサービスサーバ５を有する。このソフトウエアアップデートサービスサーバ５は、情報処理システム内のホスト１、２、３のソフトウエアや、情報処理システム内の仮想マシンVMのソフトウエアのアップデートの適用を指示する。情報処理システムを管理する運用管理者端末７が、ソフトウエアアップデートサービスサーバ５に、ソフトエウアアップデートのスケジュールを設定することで、情報処理システムの管理者は、情報処理システム内のソフトウエアのアップデートの適用を計画的に実行する。

図２は、図１の各ホスト１、２、３と管理サーバ４とソフトウエアアップデートサービスサーバ５の概略構成を示す図である。例えば、ホスト１、２、３は、演算処理装置であるCPU１０と、RAM１２と、ROM１３と、ネットワークインターフェース（例えばNIC：Network Interface Card）１４と、入出力部１５と、ハードディスクなどの大容量記憶装置１６とを有し、それらはバス１８を介して接続される。

ホスト１、２、３の場合、大容量記憶装置１６は、例えばOSやハイパーバイザHVなどを格納する。管理サーバ４の場合、大容量記憶装置１６は、例えばOSとVM管理ソフトウエア４＿１などを記憶する。また、ソフトウエアアップデートサービスサーバ５の場合、大容量記憶装置１６は、例えばOSとソフトウエアアップデートサービスプログラムを記憶する。そして、大容量記憶装置１６に格納されているOSやソフトウエアはRAM内に展開され、CPUにより実行される。

図３は、図１に示した共有ストレージ２０の構成を示す図である。共有ストレージ２０は、VMホスト１、２、３に生成される仮想マシンVMのイメージファイルを記憶する。仮想マシンVMのイメージファイルは、例えばゲストOSとアプリケーションAPLと各種データDATAなどである。各種データDATAには、例えば前述のI/O状態を含むハードウエアのエミュレーション状態も含まれる。

VMホスト１、２、３のハイパーバイザHVは、管理サーバ４のVM管理ソフトウエア４＿１からの仮想マシンVMの作成コマンドに応答して、共有ストレージ２０内のイメージファイルに対応する仮想マシンを起動し、仮想マシンVMを実行する。

図４は、ハイパーバイザの一部のコマンドとその処理内容を示す図表である。VMホスト１、２、３のハイパーバイザHVは、管理サーバ４のVM管理ソフトウエア４＿１などからのコマンドに応答して、図４に示した処理を実行する。作成コマンド（または起動コマンド）（create）に対する処理は、仮想マシンVMのコンフィグレーション情報に従う仮想マシンVMを起動する処理である。VMホスト上で仮想マシンVMを起動することで仮想マシンVMが作成される。

仮想マシンVMのコンフィグレーション情報は、VM管理ソフトウエア４＿１が管理する仮想マシンのコンフィグレーションファイルに記述されている。仮想マシンのコンフィグレーションファイルには、例えば仮想マシンが使用するCPUまたはCPUコアの数もしくはCPU使用率、メモリ使用容量、ネットワーク帯域幅などが含まれる。管理サーバ４は、仮想マシンのコンフィグレーションファイルを添付して（またはそのパス情報を示して）作成コマンド（create）をVMホストのハイパーバイザHVに送信する。

一時停止コマンド（pause）に対する処理は、仮想マシンVMの動作を一時停止する処理である。この一時停止により、仮想マシンVMはメモリ領域などのリソースの使用を継続するが、ハイパーバイザHVによる仮想化の制御は停止し、仮想マシンVMによるアプリケーションの実行などは停止する。再開コマンド（resume）に対する処理は、一時停止している仮想マシンVMの動作を再開する処理である。そして、遮断コマンド（destroy）に対する処理は、仮想マシンVMの動作を遮断し、VMホスト上に生成していた仮想マシンVMを削除する処理である。この遮断コマンドにより、仮想マシンVMが使用していたメモリ内のデータやCPU内のコマンドの情報は、必要に応じて共有ストレージ２０内のイメージファイルに退避される。

［ライブマイグレーション］
図５は、ライブマイグレーションの処理を示すフローチャート図である。前提として、移行元ホスト上で仮想マシンVMが起動され動作中である。そこで、まず、管理サーバ４のVM管理ソフトウエア４＿１が、移行先ホストに仮想マシンVMを作成するためのリソース、CPU、メモリ容量、ネットワーク帯域幅などのハードウエアリソースを確保する（Ｓ１）。管理サーバ４のVM管理ソフトウエア４＿１は、ハイパーバイザHVから仮想マシンVMの動作情報を収集し、各ホストのハードウエアリソースを管理している。したがって、その管理しているハードウエアリソースに基づいて、VM管理ソフトウエア４＿１は移行される仮想マシンが使用する移行先のホストのリソースを予約しておく。

次に、VM管理ソフトウエア４＿１は、移行先ホストで移行対象の仮想マシンVMを起動し、その仮想マシンを一時停止状態にする（Ｓ２）。この処理は、管理サーバ４のVM管理ソフトウエア４＿１が移行先ホストのハイパーバイザHVに作成コマンドを実行させ、その後一時停止コマンドを実行させることで行われる。

そして、移行元ホストのハイパーバイザHVは、移行対象の仮想マシンVMが使用中のメモリ領域のスナップショットを取得し（Ｓ３）、取得したスナップショットを移行先ホストのメモリに転送する（Ｓ４）。このメモリのデータの転送は、転送に必要なメモリのデータ量が閾値以下になるまで継続される（Ｓ５）。閾値以下にならない場合、移行元ホストのハイパーバイザHVは、スナップショットの転送中に移行元ホストのメモリに書き込まれたダーティページを、スナップショットの転送終了後に移行先ホストのメモリに転送する。

転送が必要なメモリのデータ量が閾値以下になると（Ｓ５のＹＥＳ）、移行元ホストのハイパーバイザHVは、移行元ホストの仮想マシンVMを一時停止し、移行元ホストのCPUやメモリ内の仮想マシンの動作データを移行先ホストに転送する（Ｓ７）。これにより、移行先ホストの仮想マシンVMは、移行元ホストの仮想マシンと同じ動作状態になる。そして、移行先ホストのハイパーバイザHVが、一時停止状態の仮想マシンVMを再開させる（Ｓ８）。それと共に、移行元ホストのハイパーバイザHVが、移行対象の仮想マシンVMを遮断し、管理サーバ４のVM管理ソフトウエア４＿１に仮想マシンの移行が完了したことを通知する（Ｓ１０）。

以上の通り、ライブマイグレーションでは、移行元ホストの仮想マシンVMを遮断することなく移行先ホストに同じ仮想マシンVMを起動する。工程S6で移行元ホストの仮想マシンVMが一時停止されてから、工程S8で移行先ホストで仮想マシンVMが起動するまでのごく短い時間だけ、仮想マシンVMの動作が停止するだけである。したがって、仮想マシンVMは実質的に動作を停止しないで、移行元ホストから移行先ホストに移行（マイグレート）される。

上記のライブマイグレーションは、以下のような問題がある。第１に、移行元ホストのメモリ領域のスナップショットを移行先ホストのメモリに転送することで、ネットワークの帯域を利用することになる。さらに、転送すべきメモリのデータ容量が大きくなると転送時間が長くなり、特に、メモリのデータの書き換えを頻繁に行う仮想マシンVMの場合は、転送すべきメモリのデータ容量が閾値以下になるまでの時間を予測するのが困難になる。したがって、多数のホストで多数の仮想マシンを作成して実行させる大規模なクラウドシステムでは、ホストをメンテナンスするために長時間と多くのネットワーク帯域幅が必要になる。

第２に、移行元ホストのハイパーバイザHVと移行先ホストのハイパーバイザHV間でバージョンが異なる場合は、移行先ホストで仮想マシンVMが起動しても正常に動作することができず、ライブマイグレーションが失敗に終わる場合がある。失敗する一つの原因として、バージョンが異なることで動作状態を格納するメモリ領域が異なり、移行元ホストでの仮想マシンの動作状態を移行先ホストに引き継ぐことができない場合などがある。

［本実施の形態におけるマイグレーション］
図１に戻り、VMホスト１、２、３のハイパーバイザHVは、仮想マシンVMの作成や遮断などの一般的な機能に加えて、仮想マシンVMのソフトウエアリブート（以下単にソフトリブートと称する。）を検出するリブート検出モジュール（または再起動検出モジュール）RDM（Reboot Detection Module）を有する。仮想マシンVMへのソフトリブートの処理は、仮想マシンVMのゲストOSがBIOSコールにより再起動ルーチンを呼び出す処理を有する。そこで、ハイパーバイザHVのリブート検出モジュールRDMに、BIOSコールによる再起動ルーチンの呼び出しを検出する機能を設けることで、仮想マシンのソフトリブートを検出することができる。一般に、ハイパーバイザは、仮想マシンの起動コマンドや遮断コマンドを検出するが、仮想マシンのソフトリブートについては、仮想マシンが動作中の動作であるので、検出することはない。そこで、本実施の形態では、ハイパーバイザHVに仮想マシンのソフトリブートを検出する改良を加える。

さらに、ハイパーバイザHVは、リブート検出モジュールRDMによるソフトリブートの検出に応答して、リブート対象の仮想マシンVMを遮断し、管理サーバ４への仮想マシンの遮断通知などを行うRDM管理モジュールRDM_Mを有する。

そして、管理サーバ４のVM管理ソフトウエア４＿１は、通常のVM管理機能に加えて、VMリブート管理モジュール４＿２を有する。このVMリブート管理モジュール４＿２は、移行対象の仮想マシンVMのリブート検出モジュールRDMを有効化し、仮想マシンVMのリブート検出前後の処理を例えばハイパーバイザHVのRDM管理モジュールRDM_Mに設定し、それにより仮想マシンVMのソフトリブートをトリガにしてVMホストを変更することを可能にする。

また、ソフトウエアアップデートサービスサーバ５は、動作中の仮想マシンVMに対してOSのソフトウエアアップデーターの提供と適用を行う。例えば、管理サーバ４のVM管理ソフトウエア４＿１がソフトウエアアップデートサービスサーバ５に、図１の情報処理システム内の移行対象の仮想マシンVMに対するOSのソフトウエアアップデートのスケジュールを設定する。この設定されたスケジュールに基づいて、ソフトウエアアップデートサービスサーバ５は、移行対象の仮想マシンVMにOSのソフトウエアアップデートの適用を通知する。アップデートの適用の通知に応答して、仮想マシンVMの利用者端末６で仮想マシンVMの再起動（リブート）の操作が行われると、そのソフトリブートの操作に応答して仮想マシンVMがリブートされる。

本実施の形態では、この仮想マシンVMのリブートをハイパーバイザHVのリブート検出モジュールRDMが検出し、RDM管理モジュールRDM_Mに通知する。このリブートをトリガにして、RDM管理モジュールRDM_Mが移行元ホストで移行対象の仮想マシンVMを遮断し、例えばVM管理サーバ４のVMリブート管理モジュール４＿２に仮想マシンの遮断を通知する。VMリブート管理モジュール４＿２は、この通知に応答して、移行先ホストのハイパーバイザHVに遮断した仮想マシンVMの起動を指示して遮断した仮想マシンを起動させる。

VMリブート管理モジュール４＿２に代えて、ハイパーバイザHV内のRDM管理モジュールRDM_Mが、移行先ホストのハイパーバイザHVに直接、遮断した仮想マシンVMの起動を通知して遮断した仮想マシンを起動させても良い。

また、RDM管理モジュールRDM_Mには、移行対象の仮想マシンと移行対象でない仮想マシンを区別する設定が行われることが好ましい。かかる設定を参照することで、RDM管理モジュールRDM_Mは、仮想マシンのリブートが検出された場合、移行対象の仮想マシンなら同じホストでの起動をせず異なるホストでの起動につながる処理を行い、移行対象でない仮想マシンなら通常のリブートと同様に遮断と同じホストでの起動を実行する。

本実施の形態では、上記のとおり、ハイパーバイザHVが移行対象の仮想マシンVMのソフトリブートを検出したタイミングで、移行対象仮想マシンVMを移行元ホストで遮断させ、移動先ホストで移行対象仮想マシンVMを起動して、仮想マシンのマイグレーションを実行する。つまり、ライブマイグレーションとは異なり、本実施の形態では、仮想マシンのリブートのタイミングを検出してコールドマイグレーションを実行し、仮想マシンを別のホストに移行（マイグレーション）する。

仮想マシンのリブートを引き起こす手段として、上記のOSのソフトウエアアップデートに伴うソフトリブート以外に、情報処理システムの運用管理者端末７からの移行対象仮想マシンVMへの強制ソフトリブートや、仮想マシンの利用者端末６による任意のソフトリブートでも良い。運用管理者端末７からの移行対象仮想マシンへの強制ソフトリブートは、仮想マシンにCtrl-Alt-Deleteキーによるソフトリブートコマンドを送信することで実行される。また、仮想マシンの利用者による任意のソフトリブートは、情報処理システムの運用管理者端末７から仮想マシンの利用者に対するメールで仮想マシンのリブートを依頼し、利用者が任意のタイミングで行う利用者端末６でのリブート操作を待つことにより実現される。

図６は、本実施の形態におけるリブートをトリガとするマイグレーションの処理を示すフローチャート図である。本実施の形態のリブートをトリガとするマイグレーションをここではリブートマイグレーションと称する。

図７、図８は、本実施の形態におけるリブートをトリガとするマイグレーションの処理を示すシーケンス図である。このシーケンス図は、図６のフローチャートの処理を実行する主体を明示する図である。図７、図８も参照して図６のリブートマイグレーションの処理を以下説明する。

前提として、VM管理ソフトウエア４＿１が、ホスト１のハイパーバイザHVに仮想マシンVM_1を起動させている。そして、ホスト１のメンテナンスなどの目的で、ホスト１上の仮想マシンVM_1をホスト２に移行（マイグレーション）する場合を想定する。

まず、VM管理ソフトウエア４＿１が、移行先ホスト２に仮想マシンVM_2を作成するために必要なハードウエアリソース、CPU、メモリ容量、ネットワーク帯域幅などを確保する。VM管理ソフトウエア４＿１による仮想マシンのハードウエアリソースの確保の具体的な処理は、図５の工程S1で説明したのと同様である。

そして、VM管理ソフトウエア４＿１が、移行元ホスト１の移行対象仮想マシンVMのリブート検出モジュールRDMを有効化し、そのRDM管理モジュールRDM_Mにリブート検出時の処理を設定する（S12）。このリブート検出時の処理の設定は、例えば、全ての仮想マシンVMに対応して、リブート検出時にリブートマイグレーションを実行するか否かのフラグと、移行対象VMを遮断したことを通知する通知先IPアドレスと、移行先ホストの移行先仮想マシンのIPアドレスとポート番号などを含むテーブルの設定である。

そこで、ホスト１で起動中の仮想マシンVM_1でソフトリブートが操作されると、仮想マシンVM_1に対応するリブート検出モジュールRDMがそのソフトリブートを検出する（S13）。そして、リブート検出モジュールRDMがそのソフトリブートの検出を、RDM管理モジュールRDM_Mに通知し、RDM管理モジュールRDM＿Mにソフトリブート検出後の処理を実行させる。

リブート検出モジュールRDMに対応する仮想マシンVM_1が移行対象の場合、RDM管理モジュールRDM＿Mにソフトリブート検出後の処理が設定済みである。したがって、仮想マシンVM_1が移行対象でない場合、RDM管理モジュールRDM＿Mはリブート検出時の処理が指定されておらず（S14のNO）、何も実行せずに終了する。一方、仮想マシンが移行対象である場合、RDM管理モジュールRDM＿Mはリブート検出時の処理が指定されているので（S14のYES）、移行元ホスト１のリブートが検出された仮想マシンVM_1を遮断する（S15）。そして、RDM管理モジュールRDM＿Mは、仮想マシンVM_1を遮断した旨の通知を、VM管理ソフトウエア４＿１に行う（S16）。仮想マシンVM_1が遮断されると、仮想マシンVM_1の動作中のメモリ内のデータやCPUのレジスタ情報などで保存が必要なデータは共有ストレージ２０のイメージファイルに退避される。

そして、図７の例では、管理ソフトウエア４＿１のVMリブート管理モジュール４＿２が仮想マシンVM_1の遮断通知に応答して、移行先ホスト２のハイパーバイザHVに仮想マシンVM_2の起動を指示する（S17）。これに応答して、移行先ホスト２のハイパーバイザHVは、遮断した移行対象仮想マシンのコンフィグレーション情報に基づいて仮想マシンVM_2を起動する（S18）。コンフィグレーション情報と仮想マシンのイメージファイルのパス情報は、例えば起動コマンドに添付される。

一方、図８の例では、移行元ホスト１のハイパーバイザHVのRDM管理モジュールRDM＿Mが、移行先ホスト２のハイパーバイザHVに仮想マシンVM_2の起動を指示する（S17）。つまり、図７のようにVMリブート管理モジュール４＿２ではなく、図８では、移行元ホスト１のハイパーバイザHVが移行先ホスト２のハイパーバイザHVに直接仮想マシンVM_2の起動を指示する。これに応答して、移行先ホスト２のハイパーバイザHVは、移行対象仮想マシンのコンフィグレーション情報に基づいて仮想マシンVM_2を起動する（S18）。

本実施の形態におけるリブートマイグレーションでは、移行対象仮想マシンのリブートをトリガとして移行元ホストで仮想マシンを遮断し、移行先ホストで仮想マシンを起動する。したがって、起動中の仮想マシンのメモリ内のデータを移行元ホストから移行先ホストに転送する必要がない。さらに、移行先ホストのハイパーバイザHVのバージョンが移行元ホストのハイパーバイザと異なっていても、移行元ホストでの仮想マシンの動作状態を移行先ホストが引き継がないので、移行先ホストでの仮想マシンの起動に失敗することは少ない。

［変形例］
図９は、本実施の形態におけるリブートをトリガとするマイグレーションの処理の変形例を示すフローチャート図である。図９に示した処理S11-S18は、図６の処理S11-S18と同じである。但し、図９のフローチャートでは、移行先ホストのハイパーバイザHVが仮想マシンVMを起動する処理S18の後、処理S19,S20,S21が実行される。

すなわち、仮想マシンVMを起動する処理S18の後、移行先ホスト２のハイパーバイザHVが、移行先ホスト２での仮想マシンVMの起動が成功したか否かをチェックし（S19）、何らかの理由で失敗した場合、移行先ホスト２のハイパーバイザHVが管理サーバ４のVM管理ソフトウエア４＿１に起動の失敗を通知する（S20）。この通知に応答して、VM管理ソフトウエア４＿１が、移行元ホスト１のハイパーバイザHVに遮断した仮想マシンVMの起動を指示し、ハイパーバイザHVに仮想マシンVMを起動させる（S21）。移行元ホストのハイパーバイザHVであるので、仮想マシンVMの起動に失敗することはほとんどない。但し、移行対象の仮想マシンVMの移行先ホストへのマイグレーションは完了していない。

図９に示した、移動先ホストのハイパーバイザHVによる仮想マシンVMの起動成功のチェック処理S19と、起動を失敗している場合の処理S20,S21は、図７、図８のシーケンス図にも記載されている。

［仮想マシンのリブート検出処理］
図１０は、本実施の形態における仮想マシンのリブート動作と検出処理を示すフローチャート図である。このリブート検出処理は、図６，９のリブート検出モジュールRDMによる仮想マシンのリブート検出処理S13に対応する。

まず、移行元ホストの仮想マシンVMに対してソフトリブート操作が行われると（S30のYES）、その仮想マシンVM上のゲストOSが仮想マシンVMの遮断処理（シャットダウン処理）を開始する（S31）。開始後、仮想マシンVM上のゲストOSがプログラムを全て停止する（S32）。さらに、仮想マシンVM上のゲストOSがBIOSコールにより再起動ルーチンを呼び出す（S33）。移行元ホストのハイパーバイザHVのリブート検出モジュールRDMが、仮想マシンVMの再起動ルーチンの呼び出しを検出し（S34）、RDM管理モジュールRDM＿Mに仮想マシンVMのリブート検出を通知する（S35）。

このように、本実施の形態によれば、ハイパーバイザHVに仮想マシンの再起動ルーチンの読み出しを検出するリブート検出モジュールRDMを新たに追加することで、仮想マシンVMのソフトリブートを検出する。

図１１は、本実施の形態におけるRDM管理モジュールRDM＿Mに設定されるリブート検出時の処理テーブル例を示す図である。リブート検出時の処理テーブルは、全ての仮想マシンVMのIDに対応して、ソフトリブートが検出された場合にリブートマイグレーションを実行するか否かを示すリブートマイグレーションフラグと、仮想マシンVMの遮断後にその遮断を通知する管理サーバ４のIPアドレスと、移行先ホストのIPアドレス及びポート番号とを有する。

図１１に示した処理テーブル例では、仮想マシンVM_01は、移行対象ではないためリブートマイグレーションフラグが「０」になっている。したがって、仮想マシンVM_01のソフトリブートが検出された場合、RDM管理モジュールRDM＿Mはその仮想マシンVM_01にリブートマイグレーションの処理を実行せず、ハイパーバイザHVが通常のリブート処理を実行する。

一方、仮想マシンVM_02、VM_03は、移行対象であるのでリブートマイグレーションフラグが「１」になっている。したがって、仮想マシンVM_02、VM_03のソフトリブートが検出された場合、RDM管理モジュールRDM＿Mはその仮想マシンVM_02、VM_03にリブートマイグレーションの処理を実行する。

仮想マシンVM_02に対しては、通知先管理サーバのIPアドレスが設定されているが、移行先ホストのIPアドレスとポート番号は設定されていない。したがって、RDM管理モジュールRDM＿Mは、仮想マシンVM_03のソフトリブートが検出された場合、その仮想マシンVM_02を遮断し、管理サーバ４のVM管理ソフトウエア４＿１に遮断の通知を行う。この通知に応答して、VM管理ソフトウエア４＿１は、移行先ホストのハイパーバイザHVに仮想マシンVM_02の起動を指示し起動させる。すなわち、図７に示したリブートマイグレーションの処理が実行される。

一方、仮想マシンVM_03に対しては、通知先管理サーバのIPアドレスと、移行先ホストのIPアドレスとポート番号とが設定されている。したがって、RDM管理モジュールRDM＿Mは、仮想マシンVM_03のソフトリブートが検出された場合、その仮想マシンVM_03を遮断し、管理サーバ４のVM管理ソフトウエア４＿１に遮断の通知を行う。さらに、RDM管理モジュールRDM＿Mは、移行先ホストのハイパーバイザHVに仮想マシンVM_03の起動を指示して起動させる。すなわち、図８に示したリブートマイグレーションの処理が実行される。

［第２の実施の形態におけるリブートをトリガにするマイグレーション］
図１２、図１３、図１４は、第２の実施の形態におけるリブートをトリガにするマイグレーションの処理を示すフローチャート図である。第２の実施の形態は、第１のホスト上の仮想マシンを全て第１のホスト以外のホストに移行し、第１のホストのメンテナンスを可能にする処理である。第２の実施の形態では、第１のホスト上の仮想マシンのソフトリブートを促す積極的な処理を行わず、仮想マシンでソフトリブート操作が行われるのを待って、ソフトリブートを検出した仮想マシンを他のホストに移行処理する。

図１２は、VM管理ソフトウエア４＿１によるメンテナンス開始設定の処理を示す。まず、運用管理端末７からの指示に応じて、VM管理ソフトウエア４＿１が、メンテナンス対象ホストを選択し、そのメンテナンス対象ホストで起動中の仮想マシンの移行計画テーブルを設定する（S40）。

図１５は、第２の実施の形態における移行計画テーブルの一例を示す図である。この例は、メンテナンス対象ホスト上で起動中の２０台の仮想マシンVMを約６０分で他のホストにマイグレーションする移行計画テーブルである。移行計画テーブルには、仮想マシンの移行処理開始からの経過時間と、それぞれの経過時間での移行済み仮想マシンの目標台数とが設定される。図１５の例では、経過時間３０分での移行済み仮想マシンが１５台、経過時間６０分での移行済み仮想マシンが２０台に設定されている。

図１２に戻り、VM管理ソフトウエア４＿１は、移行元ホストの全仮想マシンVMの移行先ホストを決定する（S41）。VM管理ソフトウエア４＿１は、収集している全ホストの仮想マシンの情報に基づいて、どのホストが仮想マシンVMの移行先に適切かを検出する。そして、VM管理ソフトウエア４＿１は、それぞれの移行先ホストに移行対象の仮想マシンVMを作成するハードウエアリソースを確保する（S42）。仮想マシン作成のためのハードウエアリソースの確保については既に説明したとおりである。

さらに、VM管理ソフトウエア４＿１は、移行元ホストの全仮想マシンVMについてソフトリブート検出後の処理を、移行元ホストのハイパーバイザHVのRDM管理モジュールRDM＿Mに設定する（S43）。

図１３は、仮想マシンVMのリブート検出後の仮想マシンVMの移行処理を示す。まず、移行元ホストのハイパーバイザHVのリブート検出モジュールRDMが仮想マシンのリブートを検出すると（S44のYES）、リブート検出を通知されたRDM管理モジュールRDM＿Mが、リブート検出時の処理テーブル（図１１）を参照し、リブートマイグレーションフラグが「１」であれば、移行元ホストのリブートが検出された仮想マシンVMを遮断し（S45）、VM管理ソフトウエア４＿１に仮想マシンの遮断を通知する（S46）。そして、その遮断通知に応答して、VM管理ソフトウエア４＿１が移行先ホストのハイパーバイザHVに仮想マシンVMの起動を指示する（S47）。この起動指示に応答して、移行先ホストのハイパーバイザHVは移行元ホストで遮断した仮想マシンVMを起動させる（S48）。処理S46では、VM管理ソフトウエア４＿１に代えて、移行元ホストのハイパーバイザHVのRDM管理モジュールRDM＿Mが直接移行先ホストのハイパーバイザHVに仮想マシンVMの起動を指示しても良い。図１３の処理S44-S48は、メンテナンス対象の移行元ホスト上の仮想マシン全てについて繰り返される。

図１４は、VM管理ソフトウエア４＿１によるVM移行を確認する処理である。VM管理ソフトウエア４＿１は、図１３の処理S44-S48が繰り返されている間、移行計画テーブルを参照して、経過時間と移行済み仮想マシン数を確認する（S49）。VM管理ソフトウエア４＿１は、経過時間が３０分に達した時に移行済み仮想マシン数が中間目標台数未満か否かを判定する（S50）。図１５の移行計画テーブル例では、３０分経過時の中間目標台数は１５台である。もし移行済み仮想マシン数が中間目標台数未満であれば、経過時間の６０分を経過した時点で全２０台の仮想マシンVMの他のホストへの移行完了を達成できない蓋然性が高い。そこで、VM管理ソフトウエア４＿１は、未移行の仮想マシンを移行先ホストにライブマイグレーションする処理を開始する（S51）。つまり、VM管理ソフトウエア４＿１は、各仮想マシンのソフトリブートの発生を待つことなく、自発的に、未移行の仮想マシンをライブマイグレーションにより他のホストにマイグレートする。

［第３の実施の形態におけるリブートをトリガにするマイグレーション］
図１６、図１７、図１８は、第３の実施の形態におけるリブートをトリガにするマイグレーションの処理を示すフローチャート図である。第３の実施の形態も、第１のホスト上の仮想マシンを全て第１のホスト以外のホストに移行し、第１のホストのメンテナンスを可能にする処理である。但し、第３の実施の形態では、第１のホスト上の仮想マシンのソフトリブートを促す積極的な処理を行い、第１のホスト上の仮想マシンの移行処理を計画通りに完了するようにする。仮想マシンのソフトリブートを促す積極的な処理として、ソフトウエアアップデートサービスサーバ５に移行対象の仮想マシンに対しソフトウエアアップデートの適用を通知するよう設定する。

図１６は、VM管理ソフトウエア４＿１によるメンテナンス開始設定の処理を示す。まず、運用管理端末７からの指示に応じて、VM管理ソフトウエア４＿１が、メンテナンス対象ホストを選択する（S60）。VM管理ソフトウエア４＿１は、移行元ホストの全仮想マシンVMの移行先ホストを決定する（S61）。VM管理ソフトウエア４＿１は、収集している全ホストの仮想マシンの情報に基づいて、どのホストが仮想マシンVMの移行先に適切かを検出する。そして、VM管理ソフトウエア４＿１は、それぞれの移行先ホストに移行対象の仮想マシンVMを作成するハードウエアリソースを確保する（S62）。

さらに、VM管理ソフトウエア４＿１は、移行元ホストの全仮想マシンVMについてソフトリブート検出後の処理を、移行元ホストのハイパーバイザHVのRDM管理モジュールRDM＿Mに設定する（S63）。

次に、VM管理ソフトウエア４＿１は、ソフトウエアアップデートサービスサーバ５に移行対象の仮想マシンVMにソフトウエアのアップデートを適用するよう指示する（S64）。そして、VM管理ソフトウエア４＿１は、ソフトウエアアップデートサービスサーバ５のアップデート目安時間に基づき移行計画テーブルを設定する（S65）。

図１９は、第３の実施の形態における移行計画テーブルの例を示す図である。この移行計画テーブルは、２０台の仮想マシンVMを移行するものである。そして、移行計画テーブルでは、ソフトウエアアップデートサービスサーバ５によるアップデートに要する目安時間を約１５分と想定し、経過時間２０分で移行済み仮想マシンの台数が１８台、経過時間２５分で同２０台と策定されている。

ソフトウエアアップデートサービスサーバ５が各仮想マシンにアップデートの適用を通知するが、その通知に応じて実行されるアップデートの目安時間は約１５分であり、通知から１５分後にソフトリブートの操作が行われ、経過時間１８分で大部分の仮想マシンがマイグレーションを完了すると想定される。

しかし、仮想マシンの使用状況によってはアップデートが実行されずアップデート後のソフトリブート操作が行われない場合がある。そこで、VM管理ソフトウエア４＿１が、途中経過時間で移行済み仮想マシンの台数を確認し、VM管理ソフトウエア４＿１が、アップデートの適用が行われなかった仮想マシンについてハイパーバイザHVにライブマイグレーションを実行させるのが望ましい。

図１７は、仮想マシンVMのリブート検出後の仮想マシンVMの移行処理を示す。まず、移行元ホストのハイパーバイザHVのリブート検出モジュールRDMが仮想マシンのリブートを検出すると（S66のYES）、リブート検出を通知されたRDM管理モジュールRDM＿Mが、リブート検出時の処理テーブル（図１１）を参照し、リブートマイグレーションフラグが「１」であれば、移行元ホストのリブート検出された仮想マシンVMを遮断し（S67）、VM管理ソフトウエア４＿１に仮想マシンの遮断を通知する（S68）。そして、その遮断通知に応答して、VM管理ソフトウエア４＿１が移行先ホストのハイパーバイザHVに仮想マシンVMの起動を指示する（S69）。この起動指示に応答して、移行先ホストのハイパーバイザHVは移行対象の仮想マシンVMを起動させる（S70）。処理S69では、VM管理ソフトウエア４＿１に代えて、移行元ホストのハイパーバイザHVのRDM管理モジュールRDM＿Mが直接移行先ホストのハイパーバイザHVに仮想マシンVMの起動を指示しても良い。処理S66-S70は、メンテナンス対象の移行元ホスト上の仮想マシン全てについて繰り返される。

第３の実施の形態では、ソフトウエアアップデートサービスサーバ５がメンテナンス対象のホスト上の仮想マシンに対しソフトウエアアップデートの適用を計画的に通知するので、各仮想マシンでは、特段の事情がなければ、アップデート処理が適用され仮想マシンのソフトリブート操作が行われることが予想される。したがって、移行対象の仮想マシンは計画的にリブートされ、それをトリガにして移行元ホストで遮断され、他のホストで起動されることが予想される。

図１８は、VM管理ソフトウエア４＿１によるVM移行を確認する処理である。VM管理ソフトウエア４＿１は、図１７の処理S66-S70が繰り返されている間、移行計画テーブルを参照して、経過時間と移行済み仮想マシン数を確認する（S70）。VM管理ソフトウエア４＿１は、経過時間が１８分に達した時に移行済み仮想マシン数が中間目標台数未満か否かを判定する（S72）。図１９の移行計画テーブル例では、１８分経過時の中間目標台数は１８台である。もし移行済み仮想マシン数が中間目標台数未満であれば、不足台数の仮想マシンは、ソフトウエアアップデートの適用中か、またはソフトウエアアップデートの適用を行っていないまたは失敗していることが想定される。

そこで、VM管理ソフトウエア４＿１は、ソフトウエアアップデートサービスサーバ５に未移行の仮想マシンのアップデート適用状態を問い合わせる（S73）。そして、未移行の仮想マシンVMでアップデート適用を未実行または適用の失敗が発生している場合は（S74のYES）、VM管理ソフトウエア４＿１は、その仮想マシンについてライブマイグレーションを開始するようハイパーバイザHVに通知してライブマイグレーションを開始させる（S75）。アップデート適用を未実行または適用を失敗した理由は、例えば、対象の仮想マシンをソフトリブートできない事情がある場合などが考えられる。一方、未移行の仮想マシンがアップデート適用中であれば、その仮想マシンについてはアップデートの適用が完了するのを待つ。

本実施の形態では、仮想マシンの利用者によるソフトリブートをトリガにしてマイグレーションを実行しているが、仮想マシンの利用者端末からの仮想マシンへのソフトリブート以外でも、例えば、データセンタの情報処理システムの運用管理者端末からの仮想マシンに対する強制リブートや、VM管理ソフトウエア４＿１による仮想マシンの利用者端末宛てのソフトリブート依頼メールに応じた利用者からのソフトリブートでも良い。

以上のとおり、本実施の形態のリブートをトリガとするマイグレーションによれば、ライブマイグレーションの場合の移行元ホストのメモリ内のデータを移行先ホストに転送する必要がないので、マイグレーションに長い時間を要することはなく、ネットワーク帯域を使用することがない。さらに、移行元ホストと移行先ホストのハイパーバイザHV間でバージョンが異なる場合でも、移行先ホストで仮想マシンの起動に失敗することは少ない。

また、本実施の形態のリブートをトリガとするマイグレーションによれば、ソフトウエアベンダによるアップデートサービスを利用して、仮想マシンの移行時期をある程度制御することができ、計画的なホストのメンテナンスや、ホストのサイジングを容易にすることができる。

以上の実施の形態をまとめると、次の付記のとおりである。

（付記１）
複数の情報処理装置と、
前記複数の情報処理装置を管理する管理装置とを有し、
前記複数の情報処理装置のうち第１の情報処理装置は、
仮想マシンを起動する起動部と、
前記仮想マシンの再起動を検出する再起動検出部と、
前記再起動の検出に応答して前記仮想マシンを遮断する遮断部とを有し、
前記複数の情報処理装置のうち第２の情報処理装置は、
前記第１の情報処理装置の仮想マシンが遮断された後、前記遮断された仮想マシンを起動する旨の起動指示を受信した場合、前記遮断された仮想マシンを起動する起動部を有する情報処理システム。

（付記２）
前記第１の情報処理装置は、さらに、前記仮想マシンを遮断した旨の遮断通知を前記管理装置に送信する遮断通知部を有し、
前記管理装置は、前記第１の情報処理装置から前記遮断通知を受信した場合、前記起動指示を前記第２の情報処理装置に送信する指示部を有する、付記１に記載の情報処理システム。

（付記３）
前記第１の情報処理装置は、さらに、前記起動指示を前記第２の情報処理装置に送信する指示部を有する、付記１に記載の情報処理システム。

（付記４）
前記第２の情報処理装置は、
前記起動部が前記遮断された仮想マシンの起動に失敗した場合、前記遮断された仮想マシンの起動に失敗した旨の失敗通知を前記管理装置に送信する失敗通知部を有し、
前記管理装置は、前記失敗通知を受信した場合、前記起動指示を前記第１の情報処理装置に送信する指示部を有する、付記１に記載の情報処理システム。

（付記５）
前記管理装置は、前記第１の情報処理装置に、前記仮想マシンの再起動を検出した場合に前記仮想マシンを遮断するか否かを含む再起動時処理の設定を行う設定部を有する、付記１に記載の情報処理システム。

（付記６）
前記再起動時処理には、前記仮想マシンの再起動を検出した場合に前記仮想マシンを遮断するか否かに加えて、前記遮断した仮想マシンを起動する旨の起動指示を前記第２の情報処理装置に送信するか否かを有する、付記５に記載の情報処理システム。

（付記７）
前記第１の情報処理装置の前記再起動検出部は、前記仮想マシンのオペレーションシステムがＢＩＯＳコールにより再起動ルーチンを呼び出した場合に前記仮想マシンの再起動を検出する、付記１に記載の情報処理システム。

（付記８）
さらに、所定のタイミングで前記第１の情報処理装置の仮想マシンにソフトウエアアップデートの適用を指示するシフトウエアアップデートサービス装置を有し、
前記第１の情報処理装置の仮想マシンは、前記ソフトウエアアップデートに伴って行われる再起動操作に応答して前記再起動を開始する、付記１に記載の情報処理システム。

（付記９）
前記第１の情報処理装置は、さらに、前記仮想マシンを遮断した旨の遮断通知を前記管理装置に送信する遮断通知部を有し、
前記管理装置は、前記第１の情報処理装置で起動されている複数の仮想マシンのうち所定の数の仮想マシンが第１の期間中に遮断されていない場合、前記第１の情報処理装置の遮断されていない残りの仮想マシンを前記第２の情報処理装置にライブマイグレーションする旨のライブマイグレーション指示を前記第１の情報処理装置に送信する指示部を有する、付記１に記載の情報処理システム。

（付記１０）
複数の情報処理装置と、前記複数の情報処理装置を管理する管理装置とを有する情報システムの制御方法であって、
前記複数の情報処理装置のうち第１の情報処理装置が、仮想マシンを起動する起動工程と、
前記第１の情報処理装置が、前記仮想マシンの再起動を検出する再起動検出工程と、
前記第１の情報処理装置が、前記再起動の検出に応答して前記仮想マシンを遮断する遮断工程と、
前記複数の情報処理装置のうち第２の情報処理装置が、前記第１の情報処理装置の仮想マシンが遮断された後、前記遮断された仮想マシンを起動する旨の起動指示を受信した場合、前記遮断された仮想マシンを起動する起動工程とを有する情報処理システムの制御方法。

（付記１１）
さらに、前記第１の情報処理装置が、前記仮想マシンを遮断した旨の遮断通知を前記管理装置に送信する遮断通知工程と、
前記管理装置が、前記第１の情報処理装置から前記遮断通知を受信した場合、前記起動指示を前記第２の情報処理装置に送信する指示工程とを有する、付記１０に記載の情報処理システムの制御方法。

（付記１２）
さらに、前記第１の情報処理装置が、前記仮想マシンを遮断した後、前記起動指示を前記第２の情報処理装置に送信する指示工程を有する、付記１０に記載の情報処理システムの制御方法。

１、２、３：VMホスト、ホスト、物理マシン、ホストコンピュータ
HV：ハイパーバイザ
RDM：リブート検出モジュール
RDM_M：RDM管理モジュール
４：管理サーバ、MS
４＿１：VM管理ソフトウエア
４＿２：VMリブート管理モジュール
５：ソフトウエアアップデートサービスサーバ
６：利用者端末
７：運用管理者端末
２０：共有ストレージ
OS：オペレーティングシステム
APL：アプリケーション
DATA：データ
M_NW：管理ネットワーク
VM_NW：仮想マシンネットワーク

Claims

複数の情報処理装置と、
前記複数の情報処理装置を管理する管理装置とを有し、
前記複数の情報処理装置のうち第１の情報処理装置は、
仮想マシンを起動する起動部と、
前記仮想マシンの再起動を検出する再起動検出部と、
前記再起動の検出に応答して前記仮想マシンを遮断する遮断部とを有し、
前記複数の情報処理装置のうち第２の情報処理装置は、
前記第１の情報処理装置の仮想マシンが遮断された後、前記遮断された仮想マシンを起動する旨の起動指示を受信した場合、前記遮断された仮想マシンを起動する起動部を有する情報処理システム。
前記第１の情報処理装置は、さらに、前記仮想マシンを遮断した旨の遮断通知を前記管理装置に送信する遮断通知部を有し、
前記管理装置は、前記第１の情報処理装置から前記遮断通知を受信した場合、前記起動指示を前記第２の情報処理装置に送信する指示部を有する、請求項１に記載の情報処理システム。
前記第１の情報処理装置は、さらに、前記起動指示を前記第２の情報処理装置に送信する指示部を有する、請求項１に記載の情報処理システム。
前記第２の情報処理装置は、
前記起動部が前記遮断された仮想マシンの起動に失敗した場合、前記遮断された仮想マシンの起動に失敗した旨の失敗通知を前記管理装置に送信する失敗通知部を有し、
前記管理装置は、前記失敗通知を受信した場合、前記起動指示を前記第１の情報処理装置に送信する指示部を有する、請求項１に記載の情報処理システム。
前記管理装置は、前記第１の情報処理装置に、前記仮想マシンの再起動を検出した場合に前記仮想マシンを遮断するか否かを含む再起動時処理の設定を行う設定部を有する、請求項１に記載の情報処理システム。
前記第１の情報処理装置の前記再起動検出部は、前記仮想マシンのオペレーションシステムがＢＩＯＳコールにより再起動ルーチンを呼び出した場合に前記仮想マシンの再起動を検出する、請求項１に記載の情報処理システム。
さらに、所定のタイミングで前記第１の情報処理装置の仮想マシンにソフトウエアアップデートの適用を指示するシフトウエアアップデートサービス装置を有し、
前記第１の情報処理装置の仮想マシンは、前記ソフトウエアアップデートに伴って行われる再起動操作に応答して前記再起動を開始する、請求項１に記載の情報処理システム。
前記第１の情報処理装置は、さらに、前記仮想マシンを遮断した旨の遮断通知を前記管理装置に送信する遮断通知部を有し、
前記管理装置は、前記第１の情報処理装置で起動されている複数の仮想マシンのうち所定の数の仮想マシンが第１の期間中に遮断されていない場合、前記第１の情報処理装置の遮断されていない残りの仮想マシンを前記第２の情報処理装置にライブマイグレーションする旨のライブマイグレーション指示を前記第１の情報処理装置に送信する指示部を有する、請求項１に記載の情報処理システム。
複数の情報処理装置と、前記複数の情報処理装置を管理する管理装置とを有する情報システムの制御方法であって、
前記複数の情報処理装置のうち第１の情報処理装置が、仮想マシンを起動する起動工程と、
前記第１の情報処理装置が、前記仮想マシンの再起動を検出する再起動検出工程と、
前記第１の情報処理装置が、前記再起動の検出に応答して前記仮想マシンを遮断する遮断工程と、
前記複数の情報処理装置のうち第２の情報処理装置が、前記第１の情報処理装置の仮想マシンが遮断された後、前記遮断された仮想マシンを起動する旨の起動指示を受信した場合、前記遮断された仮想マシンを起動する起動工程とを有する情報処理システムの制御方法。