Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
openSUSE Leap ドキュメンテーション › 仮想化ガイド › libvirt を利用した仮想マシンの管理 › Xen から KVM への移行ガイド
コンテンツコンテンツ
仮想化ガイド
  1. 前書き
  2. I 概要
    1. 1 仮想化技術
    2. 2 仮想化シナリオ
    3. 3 Xen 仮想化の紹介
    4. 4 KVM 仮想化の紹介
    5. 5 仮想化ツール
    6. 6 仮想化コンポーネントのインストール
  3. II libvirt を利用した仮想マシンの管理
    1. 7 libvirt デーモン
    2. 8 VM ホストサーバ の準備
    3. 9 ゲストのインストール
    4. 10 基本的な VM ゲスト の管理
    5. 11 接続と認可
    6. 12 高度なストレージ設定
    7. 13 仮想マシンマネージャ を利用した仮想マシンの設定
    8. 14 virsh を利用した仮想マシンの設定
    9. 15 AMD SEV-SNP による仮想マシンのセキュリティ強化
    10. 16 VM ゲスト の移行
    11. 17 Xen から KVM への移行ガイド
  4. III 全ハイパーバイザ共通の機能
    1. 18 ディスクのキャッシュモード
    2. 19 VM ゲスト の時刻設定
    3. 20 libguestfs
    4. 21 QEMU ゲストエージェント
    5. 22 ソフトウエア TPM エミュレータ
    6. 23 VM ゲスト に対するクラッシュダンプの作成
  5. IV Xen を利用した仮想マシンの管理
    1. 24 仮想マシンホストの設定
    2. 25 仮想ネットワーク
    3. 26 仮想環境の管理
    4. 27 Xen 内でのブロックデバイス
    5. 28 仮想化: オプション設定
    6. 29 管理作業
    7. 30 XenStore: ドメイン間で共有される設定データベース
    8. 31 Xen の高可用性仮想化ホストとしての使用
    9. 32 Xen: 準仮想化 (PV) ゲストから完全仮想化 (FV/HVM) ゲストへの変換
  6. V QEMU を利用した仮想マシンの管理
    1. 33 QEMU の概要
    2. 34 KVM VM ホストサーバ の構築
    3. 35 ゲストのインストール
    4. 36 qemu-system-ARCH を利用した仮想マシンの実行
    5. 37 QEMU モニタを利用した仮想マシンの管理
  7. VI トラブルシューティング
    1. 38 内蔵ヘルプとパッケージのドキュメンテーション
    2. 39 システム情報とログの収集
  8. 用語集
  9. A NVIDIA カードに対する GPU パススルー の設定
  10. B GNU ライセンス
ナビゲーション←→
openSUSE Leap ドキュメンテーション › 仮想化ガイド › libvirt を利用した仮想マシンの管理 › Xen から KVM への移行ガイド
トップへ
←→
適用先 openSUSE Leap 15.7

17 Xen から KVM への移行ガイド Edit source

17.1 virt-v2v を使用した KVM への移行
17.2 Xen から KVM への手動移行
17.3 さらなる情報

KVM の仮想化ソリューションはサーバ管理者の間でも非常に知られた存在となっており、既存の Xen ベースの環境を KVM に移行する要望も多くなっています。ですが、現時点では Xen の VM を KVM に自動変換してくれるような成熟したツールは提供されていません。その代わり、 Xen の仮想マシンを KVM に移行する作業を支援する技術ソリューションは用意されています。下記の章では、このような移行を行うための情報と手順を説明しています。

重要
重要: 移行手順はサポート対象外である件について

この文書内で説明している移行手順は、 SUSE では完全にはサポートしていません。ガイダンスとしてのみ提供しているものです。

17.1 virt-v2v を使用した KVM への移行 Edit source

本章では、 KVM 以外のハイパーバイザ (たとえば Xen) から libvirt が管理する KVM への仮想マシンの取り込み方法について説明しています。

ヒント
ヒント: Microsoft Windows のゲストについて

本章では Linux ゲストに主眼を置いて説明しています。 virt-v2v を利用して Microsoft Windows のゲストを移行する手順は Linux ゲストの場合とほとんど同じですが、仮想マシンドライバパック (VMDP) の部分のみ違いがあります。 VMDP を利用した Windows ゲストの変換方法について、詳しくは Virtual Machine Driver Pack documentation をご覧ください。

17.1.1 virt-v2v の紹介 Edit source

virt-v2v は KVM 以外のハイパーバイザで動作する VM ゲスト を、 libvirt が管理する KVM 上で実行できるようにするコマンドラインツールです。可能であれば、変換後の仮想マシンで準仮想化型の virtio ドライバを使用するように設定することもできます。サポート対象となるオペレーティングシステムと、ハイパーバイザの一覧は下記のとおりです:

サポート対象のゲスト側オペレーティングシステム

  • SUSE Linux Enterprise Server

  • openSUSE

  • Red Hat Enterprise Linux

  • Fedora

  • Microsoft Windows Server 2003 または 2008

サポート対象の移行元ハイパーバイザ

  • Xen

サポート対象の移行先ハイパーバイザ

  • KVM (libvirt での管理となります)

17.1.2 virt-v2v のインストール Edit source

virt-v2v のインストールは簡単です:

> sudo zypper install virt-v2v

なお、 virt-v2v コマンドを実行するには root の権限が必要となります。 root で実行するか、もしくは sudo を介して実行してください。

17.1.3 libvirt 管理下の KVM 仮想マシンへの変換 Edit source

virt-v2v は、 Xen ハイパーバイザで動作している仮想マシンを libvirt 管理下の KVM に変換することができるツールです。 libvirt や virsh コマンドに関する詳細については、 パートII「libvirt を利用した仮想マシンの管理」 をお読みください。そのほか、 virt-v2v のコマンドラインオプションについては、 virt-v2v のマニュアルページ ( man 1 virt-v2v ) をお読みください。

仮想マシンを変換する前に、まずは下記の手順を実行しておきます:

手順 17.1: 移行のための環境準備

  1. 新しいローカルストレージプールを作成します。

    virt-v2v は、移行元の仮想マシンのストレージを libvirt の管理下にあるローカルのストレージプールにコピーします (移行元のディスクイメージはそのまま保持されます) 。プールを作成するには 仮想マシンマネージャ を使用するか、もしくは virsh を使用してください。詳しくは 8.2.2項 「仮想マシンマネージャ を利用したストレージの管理」 および 8.2.1項 「virsh を利用したストレージの管理」 をお読みください。

  2. ローカルのネットワークインターフェイスを準備します。

    変換後の仮想マシンが VM ホストサーバ のローカルネットワークインターフェイスを使用できるかどうかを確認します。通常はネットワークブリッジを使用しますが、ネットワークブリッジを作成していない場合は、 YaST › システム › ネットワークの設定 › 追加 › ブリッジ で作成してください。

    注記
    注記: ネットワークデバイスのマッピングについて

    移行元で Xen ホスト内のネットワークデバイスを使用している場合は、変換処理内で移行先の KVM ホスト内のネットワークデバイスを使用するようにすることができます。たとえば Xen のネットワークブリッジが br0 であれば、そのまま KVM でも使用することができます。 /etc/virt-v2v.conf ファイル内では、そのような変換ルールを設定することができます。この変換機能を有効化するには、 <!-- と --> でコメントアウトされた箇所のコメントを外してください。たとえば下記のようになります:

     <network type='bridge' name='br0'>
   <network type='network' name='default'/>
 </network>
    ヒント
    ヒント: ネットワークブリッジが無い場合について

    ネットワークブリッジが無い場合、必要であれば 仮想マシンマネージャ で作成することもできます。

virt-v2v は下記のような書式で実行することができます:

virt-v2v -i 入力方式 -os ストレージプール 移行元_VM
入力方式

入力方式を指定します。 libvirt または libvirtxml のいずれかを指定してください。詳しくは 移行元_VM の説明をお読みください。

ストレージプール

移行先の仮想マシン向けに用意したストレージプールを指定します。

移行元_VM

移行元の仮想マシンを指定します。ここで指定すべき値は 入力方式 の指定によって異なります。 libvirt を指定した場合は移行元のドメイン名を、 libvirtxml を指定した場合は移行元のドメインの XML 設定ファイルのパスを指定します。

注記
注記: 変換にかかる時間について

仮想マシンの変換には、主にディスクイメージ全体をコピーする処理として、多くのシステム資源が必要となります。 1 台の仮想マシンあたり最大でも 10 分程度が必要になりますが、ディスクイメージが大きい場合はより多く時間がかかる場合もあります。

17.1.3.1 libvirt の XML 設定ファイルをベースにした変換 Edit source

本章では、 libvirt の XML 設定ファイルを利用してローカルの Xen 仮想マシンを変換する方法について説明しています。この方式は、既に KVM ハイパーバイザが動作している環境に適切な仕組みです。なお、移行元の libvirt の XML ファイルと libvirt のストレージプールが、それぞれローカルホスト内に存在していることを確認しておいてください。

  1. まずは移行元の仮想マシンに対する libvirt の XML 設定ファイルを取得します。

    ヒント
    ヒント: XML ファイルの取得について

    移行元の仮想マシンの libvirt XML ファイルを取得するには、まず Xen カーネルを利用してホスト側の OS を動作させなければなりません。既に KVM が有効化された環境を起動している場合は、まず Xen カーネルに戻してから libvirt の XML ファイルを取得し、その後再度 KVM 環境にしてください。

    まずは移行元の仮想マシンを virsh で識別します:

    # virsh list
 Id    名前                           状態
----------------------------------------------------
[...]
  2     sles12_xen                     実行中
[...]

    変換元の仮想マシンが sles12_xen である場合は、これを XML 形式のファイル sles12_xen.xml に保存するには、下記のようなコマンドを実行します:

    # virsh dumpxml sles12_xen > sles12_xen.xml

  2. 出力された XML ファイルの内容を表示させて、 KVM ホストの観点からもアクセス可能なパスであることを確認してください。 1 台のマシン内でローカル移行するだけであれば問題はありませんが、他のホストに移行させるような場合は、パスを変更する必要があるかもしれません。

    <source file='/var/lib/libvirt/images/XenPool/SLES.qcow2'/>
    ヒント
    ヒント: イメージのコピーについて

    イメージを何度もコピーしてしまわないようにするため、ディスクイメージを libvirt のストレージプールに直接コピーしておくことをお勧めします。この場合は、 XML ファイル内の source file の内容を合わせて変更する必要があります。なお、 virt-v2v を使用すると、既存のディスクを検出してその場で変換を行うようになります。

  3. virt-v2v コマンドを実行して KVM 仮想マシンに変換します:

    # virt-v2v sles12_xen.xml1 \
-i XML_ファイル2 \
-os 移行先のホスト:/エクスポートされたディレクトリ3 \
--bridge br04 \
-on sles12_kvm5

    1

    移行元の Xen ベースの仮想マシンの XML ファイルを指定します。

    2

    virt-v2v は移行元の仮想マシンに関する情報を、 libvirt の XML ファイルから読み込みます。

    3

    移行先の仮想マシンのディスクイメージを配置するストレージプールを指定します。この例では、 移行先のホスト 内にある /エクスポートされたディレクトリ 内にイメージを配置することになります。

    4

    移行先の KVM ベースの仮想マシンで使用するネットワークブリッジを指定します。ここではホスト内の br0 を使用する意味になります。

    5

    移行先の仮想マシンを sles12_kvm という名前に変更して、名前が重複しないように指定しています。

17.1.3.2 libvirt のドメイン名をベースにした変換 Edit source

この方式は既に libvirt で Xen を使用していて、移行後に同じマシンを KVM ハイパーバイザに移行するような場合に有用です。

  1. まずは移行対象の仮想マシンの libvirt ドメイン名を確認します。

    # virsh list
 Id    名前                           状態
----------------------------------------------------
[...]
  2     sles12_xen                     実行中
[...]

    上記の出力から、 sles12_xen が移行対象であるものとします。

  2. virt-v2v コマンドを実行して KVM 仮想マシンに変換します:

    # virt-v2v sles12_xen1 \
-i libvirt2 \
-os ストレージプール3 \
--network eth04 \
-of qcow25 \
-oa sparse6 \
-on sles12_kvm

    1

    Xen ベースの仮想マシンのドメイン名を指定します。

    2

    virt-v2v は libvirt との接続を介して仮想マシンの情報を直接取得します。

    3

    移行先のディスクイメージをローカルの libvirt ストレージプールに配置します。

    4

    全てのゲストブリッジ (もしくはネットワーク) は、ローカルで管理するネットワークに接続します。

    5

    移行先の仮想マシンで使用するディスクイメージの形式を指定します。 raw もしくは qcow2 のいずれかがサポートされています。

    6

    変換後のディスク領域の割り当て方法を指定します。 sparse (スパースファイルとして割り当てる) もしくは preallocated (事前に容量を割り当てる) のいずれかを指定します。

17.1.3.3 リモートの Xen 仮想マシンの変換 Edit source

この方式は、移行元となる Xen の仮想マシンがリモートに存在するような場合に有用です。 virt-v2v ではリモートのホストとの間を ssh 経由で接続しますので、移行元のホストで SSH サービスが動作していることを確認しておいてください。

注記
注記: パスワード無しの SSH アクセスについて

virt-v2v を動作させるにはパスワード無しの SSH 接続が必要となります。これはつまり、 ssh-agent を利用して SSH 鍵を追加しておく必要があることを意味します。詳しくは man ssh-keygen および man ssh-add でそれぞれ表示されるマニュアルページをお読みください。 第22章 「OpenSSH によるネットワーク操作の機密保持」 にも詳しい説明があります。

リモートのホストとの間で libvirt 接続を行うには、まずリモート側のホストを表す URI を組み立てる必要があります。下記の例は、接続先のホスト名が remote_host.example.com で、接続に使用するユーザ名が root である場合の例です:

xen+ssh://root@remote_host.example.com/

libvirt の接続 URI に関する詳細は、 https://libvirt.org/uri.html をお読みください。

  1. 出力された内容から、移行対象の仮想マシンの libvirt ドメイン名を探します。

    # virsh -c xen+ssh://root@remote_host.example.com/ list
 Id    名前                           状態
----------------------------------------------------
  1     sles12_xen                     実行中
[...]

    上記の出力から、 sles12_xen が移行対象であるものとします。

  2. リモート接続で virt-v2v コマンドを使用する場合、下記のようなコマンドラインになります:

    # virt-v2v sles12_xen \
-i libvirt \
-ic xen+ssh://root@remote_host.example.com/ \
-os ローカルストレージプール \
--bridge br0

17.1.4 変換した仮想マシンの起動 Edit source

virt-v2v が完了すると、 -on オプションで指定した名前で libvirt 内に新しいドメインが作成されます。 -on を指定しない場合、移行元と同じ名前の仮想マシンになります。新しいゲストは標準的な libvirt ツール、たとえば virsh や 仮想マシンマネージャ などで管理することができます。

ヒント
ヒント: マシンの再起動について

17.1.3.2項 「libvirt のドメイン名をベースにした変換」 の手順で Xen の仮想マシンを変換したあとは、ホストマシンを再起動して非 Xen カーネルを起動することができます。

17.2 Xen から KVM への手動移行 Edit source

17.2.1 概要 Edit source

仮想マシンを管理する際の推奨される方式は libvirt です (詳しくは https://libvirt.org/ をお読みください) 。 libvirt は仮想マシンを手作業で作成して動作させるよりも手間のかからない方式で、クロスプラットフォームに対応するほか、多数のハイパーバイザにも対応しています。そのほか、リモート接続に際しても機密を保持することができるほか、仮想ネットワークにも対応し、仮想マシンを管理する際の抽象化レイヤとしても使用することができます。そのため、この記事での説明は libvirt の方式をベースにしています。

一般的に、 Xen から KVM への移行は下記の手順で行います:

  1. 移行元の Xen VM ゲスト に対するバックアップコピーを作成する。

  2. (任意) 準仮想化ゲストに固有の変更を適用する。

  3. 移行元の Xen VM ゲスト に関する情報を取得し、 KVM 環境で等価な設定を作成する。

  4. Xen ホスト内の移行元ゲストをシャットダウンし、 KVM ハイパーバイザ内で移行先のゲストを起動する。

警告
警告: ライブマイグレーションに対応しない件について

Xen から KVM への移行はライブマイグレーションに対応していません。そのため、 VM ゲスト を動作させたままでは移行を行うことができません。移行先の KVM の VM ゲスト を動作させる前に、移行元の Xen の VM ゲスト をシャットダウンしてください。

17.2.2 Xen VM ゲスト のバックアップ Edit source

お使いの Xen VM ゲスト をバックアップするには、下記の手順を実施します:

  1. まずは移行元の Xen ゲストを識別します。下記のようにして ID と名前 (Name) を記憶しておきます。

    > sudo virsh list --all
Id 名前                 状態
----------------------------------
 0 Domain-0             実行中
 1 SLES15SP3            実行中
[...]

  2. ゲストをシャットダウンします。シャットダウンはゲスト OS 内から実行することが できるほか、下記のようにして virsh を利用しても実行できます:

    > sudo virsh shutdown SLES11SP3

  3. まずは設定を XML ファイルにバックアップします。

    > sudo virsh dumpxml SLES11SP3 > sles11sp3.xml

  4. 次にディスクイメージファイルをバックアップします。 cp や rsync などのコマンドを利用してバックアップコピーを作成してください。このとき、 md5sum コマンドでコピーのチェックサムを作成しておくとよいでしょう。

  5. ディスクイメージファイルをバックアップしたら、再度ゲストを起動します:

    > sudo virsh start SLES11SP3

17.2.3 準仮想化ゲストに固有の変更 Edit source

準仮想化 Xen ゲストから移行する場合は、下記のような変更を適用します。下記の変更はゲストを動作させて適用してもかまいませんし、 guestfs-tools を使用すれば停止済みのゲストでも適用することができます。

重要
重要

本章で示した変更を適用してしまうと、移行元の VM ゲスト は Xen 内で動作しなくなってしまいますのでご注意ください。

17.2.3.1 既定のカーネルのインストール Edit source

警告
警告: 起動してはならない件について

既定のカーネルをインストールした後は Xen からゲストを起動しようとしないでください。起動しようとしても動作しないためです。

Xen ゲストのディスクイメージを KVM ハイパーバイザ内で使用するためにコピーする場合、 Xen ハイパーバイザを 使用せずに 起動できるものであることを確認してください。準仮想化 Xen ゲストの場合、通常は Xen 向けの特殊なカーネルが動作しているほか、 GRUB 2 などのブートローダもインストールされていないためです。

  1. SLES 11 の場合は /etc/sysconfig/kernel ファイルを更新します。 INITRD_MODULES パラメータ内にある全ての Xen ドライバを削除し、 virtio ドライバに置き換えます。たとえば下記前者のような設定になっている場合:

    INITRD_MODULES="xenblk xennet"

    上記を下記のように変更します:

    INITRD_MODULES="virtio_blk virtio_pci virtio_net virtio_balloon"

    SLES 12, 15 もしくは openSUSE の場合、 /etc/dracut.conf.d/*.conf ファイル内を検索し、 xenblk xennet を virtio_blk virtio_pci virtio_net virtio_balloon に置き換えます。

  2. 準仮想化 Xen ゲストの場合、固有の Xen カーネルを動作させています。 KVM で動作できるようにするには、既定のカーネルをインストールする必要があります。

    注記
    注記: 既に標準のカーネルがインストールされている場合がある件について

    完全仮想化ゲストの場合は既に標準のカーネルがインストールされていますので、ここで敢えてインストールし直す必要はありません。

    rpm -q kernel-default コマンドを Xen ゲスト内で実行すると、既定のカーネルがインストールされているかどうかを確認することができます。インストールされていない場合は zypper in kernel-default コマンドでインストールしてください。

    なお、 KVM でゲストを動作させるには、 virtio (準仮想化) ドライバをインストールしておかなければなりません。下記のようなコマンドを実行して確認してください。なお、 6.4.0-150600.9 の箇所をお使いのカーネルバージョンに置き換えて実行してください:

    > sudo sudo find /lib/modules/6.4.0-150600.9-default/kernel/drivers/ -name virtio*
/lib/modules/6.4.0-150600.9-default/kernel/drivers/block/virtio_blk.ko.zst
/lib/modules/6.4.0-150600.9-default/kernel/drivers/bluetooth/virtio_bt.ko.zst
/lib/modules/6.4.0-150600.9-default/kernel/drivers/char/hw_random/virtio-rng.ko.zst
/lib/modules/6.4.0-150600.9-default/kernel/drivers/crypto/virtio
/lib/modules/6.4.0-150600.9/kernel/drivers/block/virtio_blk.ko
...

  3. 次に /etc/fstab ファイルを更新します。xvda デバイスを vda デバイスに変更します。

  4. さらにブートローダの設定を更新します。まずは Xen ゲスト内で rpm -q grub2 を実行して、 GRUB 2 がインストールされているかどうかを確認します。インストールされていない場合は zypper in grub2 を実行してインストールしてください。

    OS の起動時に新しくインストールした既定のカーネルを使用するように設定します。なお、 Xen 固有のデバイスを使用している場合は、対応するカーネルのコマンドラインオプションを削除もしくは更新してください。この作業は YaST ( システム › ブートローダ ) のほか、手作業でも行うことができます:

    • まずはメニュー内の Linux の起動項目のうち、変更したい箇所を識別します:

      > cat /boot/grub2/grub.cfg | grep 'menuentry '

      新しくインストールしたものがどれなのかを番号で覚えておきます (上から順に 0 から数えてください) 。

    • 新しくインストールしたカーネルを既定の起動項目に設定します:

      > sudo grub2-set-default N

      ここで、 N の箇所には新しくインストールしたカーネルの順序番号を指定します。

    • /etc/default/grub ファイルをエディタなどで開き、 GRUB_CMDLINE_LINUX_DEFAULT および GRUB_CMDLINE_LINUX_RECOVERY のオプションを探します。それらの値のうち、 Xen 固有のデバイス指定があれば、それらを削除もしくは更新してください。たとえば下記前者のような指定があった場合:

      root=/dev/xvda1 disk=/dev/xvda console=xvc

      上記を下記のように変更します:

      root=/dev/vda1 disk=/dev/vda

      なお、 xvc のようなコンソール指定があった場合は、それら全て (xvc0 など) を削除する必要があります。

  5. /boot/grub2 もしくは /boot/grub2-efi ディレクトリ内にある device.map ファイルを更新します。ここでは xvda のストレージデバイスを vda に変更してください。

  6. 新しい既定値を取り込むため、下記のように実行します:

    grub2-mkconfig -o /boot/grub2/grub.cfg

17.2.3.2 KVM で起動できるようにするためのゲストの更新 Edit source

  1. さらにシステムを更新して、既定のシリアルコンソールを使用するようにします。まずは設定済みのコンソールを一覧表示して、 xvc? へのシンボリックリンクを削除してください。

    > sudo ls -l /etc/systemd/system/getty.target.wants/
getty@tty1.service -> /usr/lib/systemd/system/getty@.service
getty@xvc0.service -> /usr/lib/systemd/system/getty@xvc0.service
getty@xvc1.service -> /usr/lib/systemd/system/getty@xvc1.service

# rm /etc/systemd/system/getty.target.wants/getty@xvc?.service

  2. さらに /etc/securetty ファイルを更新します。 xvc0 を ttyS0 に置き換えてください。

17.2.4 Xen VM ゲスト 設定の更新 Edit source

本章では移行元の Xen VM ゲスト の設定をエクスポートする方法、および libvirt の管理下の KVM ゲストとして取り込む際の変更すべき項目について説明しています。

17.2.4.1 Xen VM ゲスト 設定のエクスポート Edit source

まずはゲストの設定をエクスポートしてファイルに保存します。保存された内容は、たとえば下記のようになります:

> sudo virsh dumpxml SLES11SP3
<domain type='xen'>
  <name>SLES11SP3</name>
  <uuid>fa9ea4d7-8f95-30c0-bce9-9e58ffcabeb2</uuid>
  <memory>524288</memory>
  <currentMemory>524288</currentMemory>
  <vcpu>1</vcpu>
  <bootloader>/usr/bin/pygrub</bootloader>
  <os>
    <type>linux</type>
  </os>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/lib/xen/bin/qemu-dm</emulator>
    <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/var/lib/libvirt/images/SLES_11_SP2_JeOS.x86_64-0.0.2_para.raw'/>
      <target dev='xvda' bus='xen'/>
    </disk>
    <interface type='bridge'>
      <mac address='00:16:3e:2d:91:c3'/>
      <source bridge='br0'/>
      <script path='vif-bridge'/>
    </interface>
    <console type='pty'>
      <target type='xen' port='0'/>
    </console>
    <input type='mouse' bus='xen'/>
    <graphics type='vnc' port='-1' autoport='yes' keymap='en-us'/>
  </devices>
</domain>

libvirt での VM ゲスト の XML 書式に関する詳細は、 https://libvirt.org/formatdomain.html で説明されています。

17.2.4.2 ゲストの設定に対する一般的な変更 Edit source

出力した Xen ゲストの XML 設定ファイルは、 KVM ハイパーバイザで動作させる際にいくつか修正する必要があります。下記の手順は完全仮想化と準仮想化の両方に対応しています。ただし、下記の XML 要素全てが存在するとは限りません。存在しているもののみを修正してください。

ヒント
ヒント: 使用する用語について

XML 設定ファイル内での項目位置を示すため、本文書では XPath 文法を使用しています。たとえば下記のような XML ファイル内で、 <domain> タグ内の <name> を表す場合:

<domain>
  <name>sles11sp3</name>
</domain>

XPath では /domain/name と表記します。

  1. まずは /domain 要素内の type 属性を、 xen から kvm に変更します。

  2. /domain/bootloader 要素を削除します。

  3. /domain/bootloader_args 要素を削除します。

  4. /domain/os/type 要素の値を、 linux から hvm に変更します。

  5. /domain/os 要素内に <boot dev="hd"/> を追加します。

  6. /domain/os/type 要素内に arch 属性を追加します。設定可能な値は arch=”x86_64” もしくは arch=”i686” のいずれかです。

  7. /domain/devices/emulator 要素内の値を、 /usr/lib/xen/bin/qemu-dm' から /usr/bin/qemu-kvm に変更します。

  8. 準仮想化 (PV) ゲストに関連づけられたディスクに対して、下記の設定変更を行います:

    • /domain/devices/disk/driver 要素内にある name 属性を file から qemu に変更し、 type 属性を追加します。 type 属性には raw もしくは qcow2 のいずれかの値を指定します。

    • /domain/devices/disk/target 要素内の dev 属性を、 xvda から vda に変更します。

    • /domain/devices/disk/target 要素内の bus 属性を、 xen から virtio に変更します。

  9. それぞれのネットワークカードに対して、下記の変更を行います:

    • /domain/devices/interface 内に model 要素が存在している場合は、その type 属性を virtio に変更します:

      <model type=”virtio”>

    • /domain/devices/interface/script 要素があれば、それらの要素全てを削除します。

    • /domain/devices/interface/target 要素内に dev 属性が存在していて、その値が vif, vnet, veth のいずれかで始まるものであった場合は、それらの要素全てを削除します。独自のネットワークを使用している場合は、 dev の値を変更します。

  10. /domain/devices/console 要素があれば、それらの要素全てを削除します。

  11. /domain/devices/serial 要素があれば、それらの要素全てを削除します。

  12. /domain/devices/input 要素内の bus 属性を、 xen から ps2 に変更します。

  13. メモリバルーン機能を使用する場合は、 /domain/devices 要素内に下記の要素を追加します。

    <memballoon model="virtio"/>
ヒント
ヒント: デバイス名について

<target dev='hda' bus='ide'/> 要素はゲスト OS 側に対してどのようにディスクを提示するのかを制御する項目です。 dev 属性では 「論理」 デバイス名を指定しますが、この値とゲスト OS 内でのデバイス名は、必ずしも一致しているとは限りません。そのため、ブートローダのコマンドラインで、ディスクのマッピングを変更する必要があるかもしれません。たとえばブートローダ側の設定では hda2 にルートディスクが存在しているように記述されているものの、 KVM では sda2 に現れるような場合、下記のようにブートローダのコマンドラインを変更する必要があります:

[...] root=/dev/hda2 resume=/dev/hda1 [...]

上記を下記のように変更します:

[...] root=/dev/sda2 resume=/dev/sda1 [...]

準仮想化型の xvda デバイスを使用している場合は、下記のようにします:

[...] root=/dev/vda2 resume=/dev/vda1 [...]

上記の変更を行わないと、 VM ゲスト を KVM 環境で起動することができなくなります。

17.2.4.3 移行先での KVM ゲスト設定 Edit source

上述の変更点を全て適用すると、 KVM ゲストの設定は下記の例のようになります:

<domain type='kvm'>
  <name>SLES11SP3</name>
  <uuid>fa9ea4d7-8f95-30c0-bce9-9e58ffcabeb2</uuid>
  <memory>524288</memory>
  <currentMemory>524288</currentMemory>
  <vcpu cpuset='0-3'>1</vcpu>
  <os>
    <type arch=”x86_64”>hvm</type>
    <boot dev="hd"/>
  </os>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type="raw"/>
      <source file='/var/lib/libvirt/images/SLES_11_SP2_JeOS.x86_64-0.0.2_para.raw'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    <interface type='bridge'>
      <mac address='00:16:3e:2d:91:c3'/>
      <source bridge='br0'/>
    </interface>
    <input type='mouse' bus='usb'/>
    <graphics type='vnc' port='5900' autoport='yes' keymap='en-us'/>
    <memballoon model="virtio"/>
  </devices>
</domain>

変更後の設定は、ホームディレクトリ内に SLES11SP3.xml のようなファイル名で保存してください。取り込みを行うと、設定は /etc/libvirt/qemu ディレクトリ内にコピーされます。

17.2.5 VM ゲスト の移行 Edit source

VM ゲスト の設定とゲスト OS 内での設定を変更したら、移行元の Xen ゲストをシャットダウンして、 KVM ハイパーバイザで移行先を起動してください。

  1. Xen ホスト内で動作するゲストをシャットダウンするには、コンソールから root で shutdown -h now を実行します。

  2. 必要であれば、 VM ゲスト に結びつけられているディスクファイルをコピーします。既定の設定では、 Xen のディスクイメージは /var/lib/xen/images にありますので、これを /var/lib/kvm/images にコピーしてください。なお、 KVM 側にゲストがまだ存在していない場合、 /var/lib/kvm/images ディレクトリは存在しませんので、 (root で) 作成してからコピーしてください。

  3. 新しいドメインを作成して libvirt に登録します:

    > sudo virsh define SLES11SP3.xml
 ドメイン SLES11SP3 が SLES11SP3.xml から定義されました

  4. 作成したドメインが KVM の設定内に存在していることを確認します:

    > virsh list –all

  5. ドメインを作成したら、あとは起動するだけです:

    > sudo virsh start SLES11SP3
 ドメイン SLES11SP3 が起動されました

17.3 さらなる情報 Edit source

libvirt に関する詳細は、 https://libvirt.org をお読みください。

libvirt の XML 書式に関する詳細については、 https://libvirt.org/formatdomain.html をお読みください。

→パート III 全ハイパーバイザ共通の機能←第16章 VM ゲスト の移行
このページを印刷

© 2024 SUSE