仮想マシン
仮想マシンパネルでは、ゲストオペレーティングシステムのライフサイクルの制御、構成ファイルの管理、およびリソースのクローン作成を行うことができます。
A. 基本的な状態操作
- メインのVMリストから、現在の実行状態(All States、Running、Stopped、Paused、 または Suspended)でフィルタリングできます。
- アクションのショートカットを使用して、管理者はクイック電源状態コマンド(Start、Stop (Graceful)、Force Stop、Restart、 または Force Restart)を実行できます。
B. ゲストコンソールへのアクセス
- 実行中の仮想マシンを選択すると、Webブラウザ内でインタラクティブな VNC Console を直接起動できます。
- これにより、初期セットアップ、ネットワークの修復、またはホスト名の確認に最適な、低レベルのグラフィカルまたはコマンドラインのオペレーティングシステムログイン制御(
tty1)が提供されます。
C. 仮想ハードウェア構成の変更(編集とXML編集)
仮想マシンのリソース調整が必要な場合は、Edit アクションパネルに移動します:
- Compute Options (Basic & Advanced): Maximum Memory、Max vCPUs、CPU Pinning Configurations、Sockets、Cores、および Threads の設定を調整します。また、CPUモード(例:
host-passthrough)を定義し、高度なフラグ(例:UEFI、Secure Boot、またはTPM機能の有効化)を指定することもできます。 - Direct XML Editing: 標準の切り替えメニュー以外の精密な調整を行うには、Edit XML を選択します。これにより、ゲストの libvirt XML ドメイン定義マッピングブロック(
<domain type='kvm'>、<vcpu>、<memory>、またはバッキングファイル定義の直接変更など)にテキストベースで直接アクセスできます。
D. テンプレート、クローン、およびスナップショット
- Cloning VMs: Clone アクションを開始して、複製を作成します。新しいクローンの一意の名前を入力し、ターゲットの移行先ストレージプールを選択して、Guest identity を選びます(セクション E を参照)。クローンは常にソース VM のすべてのディスクイメージの完全かつ独立したコピーです。作成後はソースに依存せず、ディスクが大きいほどクローンに時間がかかります。リンククローン(コピーオンライト)は利用できず、ソースのスナップショットはクローンにコピーされません。ソースに直接接続したホストのブロックデバイス、読み取り専用ディスク、ISO イメージはコピーされず、クローンはソースと同じデバイスまたはファイルを使用します。書き込み可能なデバイスを共有している間は、両方の VM を同時に実行しないでください。
- Snapshots: Create Snapshot を選択して、特定の時点のリカバリイメージを取得します。一意のスナップショット名(例:
snap-01)とオプションの説明を入力します。スナップショットの状態にアクティブなランタイムメモリを含めるかどうかを選択できます。 - Templates: Convert to Template 機能を使用して、既存の構造化された仮想マシンデプロイメントを静的なベースラインテンプレート構成に変換するか、以前にキャプチャしたテンプレートから新しいマシンをデプロイします。テンプレートからのデプロイでも、クローンと同じ Guest identity の選択肢が表示されます。スナップショットとテンプレート を参照してください。
E. クローンのゲストアイデンティティ (Guest Identity)
ディスクを単純にコピーすると、ゲスト OS が自分を他のマシンと区別するために使う情報もすべてコピーされます。ソースとその完全なコピーを同時に実行すると、通常次のような症状が現れます:
- 両方の VM が DHCP から同じ IP アドレスを受け取る。
- クラウドイメージから構築した VM のクローンが、ネットワークがまったくない状態で起動する。
- 両方の VM が同じホスト名を表示し、SSH クライアントがホストキーで両者を区別できない。
Clone ダイアログの Guest identity 設定で、結果を選択します:
| オプション | 結果 |
|---|---|
| Reset guest identity (recommended) | 独自のアイデンティティを持つクローン。Vapor は、クローンを初めて起動する前にコピーしたディスクを編集します。ソース VM が変更されることはありません。 |
| Keep an exact copy | ソースのディスクをバイト単位でそのままコピーします。リストアテスト、調査用に保管するコピー、またはライセンスが machine ID に紐づいたアプライアンスに使用します。 |
ホストがアイデンティティをリセットできる場合、Reset guest identity がデフォルトで選択されます。リセットできない場合は Keep an exact copy が選択され、ダイアログにその理由が表示されます(ホストの要件 を参照)。
Reset guest identity で変更される内容
- Machine ID:
/etc/machine-id(および、別ファイルの場合は/var/lib/dbus/machine-id)に新しいランダムな ID が設定されます。この ID でクライアントを識別する DHCP サーバーは、クローンに別のアドレスを割り当てます。 machine ID がuninitialized(初回起動用に準備されたテンプレート)の場合は、そのまま残されます。 - SSH ホストキー: すべてのホストキーが、同じ種類とサイズの新しいキーに置き換えられます。ソースに接続したことのあるクライアントには、クローンのホストキーが異なって見えます。VM に新しい種類のキーもある場合、古い DSA キーは削除されます。 4096 ビットを超える RSA キーは 4096 ビットのキーに置き換えられ、その旨が結果に注記されます。
- ネットワークの MAC バインディング: クローンのネットワークインターフェースには新しい MAC アドレスが割り当てられます。ソースの MAC アドレスを指定しているネットワーク設定(netplan、NetworkManager、
ifcfgファイル、systemd-networkd、udev ルール、/etc/network/interfaces)はクローンのアドレスに更新され、インターフェースが起動するようになります。 - DHCP リース: ソースが保存したリースは削除され、クローンは自身のリースを要求します。
- ランダムシード: 保存されているランダムシードは新しいランダムデータに置き換えられます。
- ホスト名: クローン名から設定されます。小文字に変換し、ASCII の英字・数字・ハイフン以外の文字はすべてハイフンに置き換え、連続するハイフンは 1 つにまとめ、先頭と末尾のハイフンを削除して、最大 63 文字に切り詰めます。ソースのホスト名のドメインは、有効な DNS ドメインであればそのまま残ります。たとえば
web01.example.comをweb02としてクローンするとweb02.example.comになります。/etc/hostsのループバック行にある一致する名前も更新されます。クローン名から使用できる部分が残らない場合、またはゲストに/etc/hostnameがない場合、ホスト名は変更されません。
それ以外はソースのまま残ります:ユーザーアカウントとパスワード、ユーザーの SSH authorized keys、インストール済みのソフトウェアとドライバー、アプリケーションデータ、および静的 IP アドレス。
静的 IP アドレス
静的 IP アドレスは維持されるため、クローンはソースと同じアドレスを持ちます。クローンは警告付きで完了し、autostart がオフの状態で作成されます。両方の VM を同じネットワークで実行する前にアドレスを変更してください。例:ソースを停止したままクローンを起動し、VNC コンソールからアドレスを変更してから、ソースを再度起動します。
完了したクローンで確認すべきその他の事項
クローンは作成されますが、次の場合は結果に警告または注記が表示されます:
- ソースが Active Directory または Kerberos ドメインに参加している: クローンはソースのマシンアカウントを使い続けるため、ソースがドメインからロックアウトされる可能性があります。ネットワークに接続する前に、クローンをドメインから外し、新しい名前で再参加させてください。
- cloud-init がホスト名を管理している: cloud-init が起動のたびにソースのホスト名を再設定することがあります。クローンにソースの名前が表示され続ける場合は、クローンの cloud-init 設定でホスト名を変更してください。
- 登録・管理エージェントが設定されている(Red Hat Subscription Manager、Ubuntu Pro、Puppet、Salt、Chef): クローンはソースの登録情報をそのまま持っています。クローンを登録し直してください。
アイデンティティをリセットできない場合
Reset guest identity を選択していてアイデンティティをリセットできない場合、クローンは理由を示して失敗し、VM は作成されません。Vapor はコピー前にソース VM を確認するため、ほとんどのケースはすぐに報告されます。それ以外のケースは、コピーを変更する前にコピー上で検出され、コピーは削除されます。代わりに Keep an exact copy を選択し、両方の VM を実行する前にゲスト内でアイデンティティを変更してください:
| 状況 | 対処 |
|---|---|
| Windows またはその他の Linux 以外のゲスト | 完全なコピーを作成し、ゲストを汎用化します(Windows では Sysprep を使用)。 |
| 暗号化されたディスク(LUKS や BitLocker など) | 完全なコピーを作成し、ゲスト内でアイデンティティを変更します。 |
| ディスク上に OS が見つからない、または複数ある | 完全なコピーを作成します。 |
| ホストが変更できないファイルシステム(例:古いカーネルのホスト上の RHEL 9 およびその再ビルド版(Rocky Linux、AlmaLinux)の XFS ファイルシステム) | 完全なコピーを作成し、ゲスト内でアイデンティティを変更します。 |
/var などゲストのシステムの一部が、クローンと一緒にコピーされないディスク(直接接続したホストのブロックデバイスや読み取り専用ディスク)上にある | ソース VM でシステムのその部分をディスクイメージに移してから、再度クローンします。完全なコピーでも、そのデバイスはソースと共有されたままです。 |
| VM に複数のネットワークインターフェースがあり、ネットワーク設定が、ソースのどのネットワークインターフェースにもない MAC アドレスを指定している | ソース VM の古いエントリを削除または修正してから、再度クローンします。guest_identity が auto の場合は警告になるだけで、リセットは完了します。 |
| SSH ホストキーが DSA キーのみ | ソース VM に新しい種類のキーを追加(sudo ssh-keygen -A)してから、再度クローンします。 |
Linux クローンのアイデンティティを自分で変更するには、クローン内で次を実行します:
sudo rm -f /etc/machine-id /var/lib/dbus/machine-id
sudo systemd-machine-id-setup
sudo hostnamectl set-hostname <new-name>
sudo rm -f /etc/ssh/ssh_host_*
sudo ssh-keygen -A
sudo systemctl restart ssh # RHEL 系ゲストではサービス名は sshdVapor がコピーしたディスクを編集している間に問題が発生した場合、クローン全体が失敗します。コピーは削除され、VM は作成されません。ソース VM には影響しません。
ゲストエージェント
クローンはソースの QEMU ゲストエージェント接続を保持するため、エージェントに依存する機能(スナップショットやバックアップのためのファイルシステムの静止化、ゲスト IP の報告)はソースと同様にクローンでも動作します。
ホストの要件
アイデンティティのリセットには、Vapor ホストに guestfish(libguestfs の一部)が必要です。root としてインストールします:
# Debian 12 以降、Ubuntu 22.04 以降
sudo apt-get install guestfish libguestfs-xfs
# Debian 11、Ubuntu 20.04
sudo apt-get install libguestfs-tools libguestfs-xfs
# RHEL 9 とそのリビルド(Rocky Linux、AlmaLinux)
sudo dnf install libguestfs libguestfs-xfs
# RHEL 8 とそのリビルド
sudo dnf install libguestfs-tools-c libguestfs-xfsVapor を再起動する必要はありません。Vapor は Clone ダイアログを開くたびにツールを再確認し、バックグラウンドで短いセルフテストを実行します。Reset guest identity があらかじめ選択されていない場合、または無効になっている場合は、ダイアログを閉じて 1 分ほど後に開き直してください。それでも利用できない場合は、ダイアログの理由欄に、ホストに不足しているものやセルフテストの結果が表示されます。
カーネルが 5.15 より古いホスト
Vapor は、ホスト自身のカーネルで起動する小さな補助 VM (libguestfs アプライアンス) の中でアイデンティティをリセットします。実行中の VM のクローンはクラッシュ整合性のコピーであり、Debian 13 などの新しいゲストのファイルシステムは、5.15 より古いカーネルでは書き込み可能としてマウントできない状態になります。そのようなホストでは、このクローンのアイデンティティをリセットできません (理由 unmountable)。選択に応じて、クローンは失敗するか、警告付きの完全なコピーとして作成されます。完全なコピーは通常、ネットワークなしで起動します。停止中の VM のクローンは影響を受けません。
これは Ubuntu 20.04 (カーネル 5.4) と Debian 11 (カーネル 5.10) が対象です。Vapor 3.3.2 以降、Ubuntu 20.04 への新規インストールではアプライアンスに 5.15 カーネルが用意されます。インストーラーは 5.15 HWE カーネルをダウンロードし、インストールせずに /opt/vapor-guestfs-kernel/<release> に展開するため、ホスト自身のカーネルとブートは変わりません。インプレースでアップグレードしたホストには適用されません。root で同じ手順を手動で実行してください。
REL=$(apt-cache depends linux-image-generic-hwe-20.04 | grep -o 'linux-image-5\.15[^ ]*' | sed 's/linux-image-//')
D=/opt/vapor-guestfs-kernel/$REL; T=$(mktemp -d)
(cd $T && sudo apt-get download linux-image-$REL linux-modules-$REL)
for f in $T/*.deb; do sudo dpkg-deb -x $f $D; done; sudo depmod -b $D $REL
sudo mkdir -p /etc/systemd/system/vapor.service.d
printf '[Service]\nEnvironment=SUPERMIN_KERNEL=%s\nEnvironment=SUPERMIN_MODULES=%s\n' \
"$D/boot/vmlinuz-$REL" "$D/lib/modules/$REL" | sudo tee /etc/systemd/system/vapor.service.d/guestfs-kernel.conf
# The appliance is cached; clear it so it is rebuilt with the new kernel.
sudo rm -rf /var/lib/vapor/guestfs-cache/.guestfs-0
sudo systemctl daemon-reload && sudo systemctl restart vapor元に戻すには、/etc/systemd/system/vapor.service.d/guestfs-kernel.conf を削除して Vapor を再起動します。Debian 11 では新しいカーネルを bullseye-backports から入手でき、そのカーネルのパッケージで同じ手順を適用できます。これらを行わない場合は、そのような VM を停止してからクローンしてください。
API クライアント向け
クローンのリクエスト(POST /api/v1/virtualization/computes/{id}/clone および POST /api/v1/virtualization/computes/clone)とテンプレートからのデプロイ(POST /api/v1/virtualization/computes/from-template)は、guest_identity フィールドを受け付けます:
| 値 | 動作 |
|---|---|
reset | アイデンティティをリセットします。できない場合はリクエストが失敗します:409 と IDENTITY_RESET_UNAVAILABLE(ホストがアイデンティティをリセットできない)または IDENTITY_RESET_UNSUPPORTED_GUEST(ゲストをリセットできない。詳細に reason_code が含まれる)、あるいはコピー開始後であれば、進捗イベントに同じ error_code を持つ失敗したクローン。 |
auto | 可能な場合はアイデンティティをリセットします。コピーを変更する前にリセットできないと判明した場合、クローンは完全なコピーになり、結果にその理由が警告として報告されます。 |
keep | 完全なコピーを作成します。 |
リセットツール自体が失敗またはタイムアウトした場合、クローンは IDENTITY_RESET_FAILED(reason_code は tool_error または timeout)で失敗します。テンプレートからのデプロイでは 500 が返され、クローンではこのコードが進捗イベントの error_code として報告されます。
フィールドを省略すると、ホストのデフォルトが適用されます:vapor.conf の clone_guest_identity_default(または環境変数 VAPOR_CLONE_GUEST_IDENTITY_DEFAULT)で、auto(デフォルト)または keep です。クローンの最終イベント(テンプレートからのデプロイではレスポンス)には、status(done、kept、failed)、reason_code、reason、新しい hostname、および上記の warnings を含む identity_reset オブジェクトが含まれます。GET /api/v1/virtualization/computes/clone/capabilities は、ホストがアイデンティティをリセットできるかどうかと、できない場合はその理由を返します。