AlmaLinux + KVM + Cockpit で始めるお手軽仮想化基盤 ～ 開発環境などでの利用を想定して ～

今回は、KVMとCockpitの概要やそれぞれの役割を紹介します 。 特に、無償版ESXiからの移行先を探している方 や、Debian/Ubuntu系(Proxmox VE等)の操作に慣れていない方 を対象に、開発環境などのミッションクリティカルではないスタンドアロン環境での使い方 を提案します。

セッションでは、ProxmoxやHyper-Vとの違い 、出来ること・出来ないこと 、環境構築のポイント 、普段使いの方法などに触れます。余裕があれば、ライブマイグレーションについても紹介予定です 。

説明者： 渡邊 真佐人氏（サイバートラスト株式会社）

＜このような方におすすめ＞
無償版単体ESXiを使っていたが、移行先を探している方
開発環境といったミッションクリティカルではないスタンドアロン環境での利用
Debian/Ubuntu系の操作に慣れておらず、Proxmox以外の選択肢を探している方

Transcript

1. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 AlmaLinux + KVM + Cockpit で始めるお手軽仮想化基盤 ～ 開発環境などでの利用を想定して ～ 2025.12.17 サイバートラスト株式会社 オープンプラットフォーム事業本部運用サービス部 渡邊　真佐人
2. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 渡邊　真佐人（自己紹介） サイバートラスト株式会社 オープンプラットフォーム事業本部運用サービス部 主に統合監視ソフト MIRACLE ZBX や HA クラスタリングソフト CLUSTERPRO X などのプリセールス、コンサルティングを担当。 前職にて監視オペレータや運用 SE なども経験したこともあり、監視環境や HA 環 境の設計構築の SI コンサルがメイン。逆に開発経験は皆無。 Proxmox VE をコンサル案件の検証などで社内自席 PC で使用していたことから、 Prossione Virtualization や KVM なども担当することに・・・ 旅先の地元居酒屋にて地酒（日本酒・焼酎）を飲み漁ります。。。 そのため海外旅行には全く興味がない国内専門の旅好き。
3. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 VMware から Broadcom への値上げ騒動（まだまだ収束しそうにないです） VMware vSphere Hypervisor (ESXi) は 8.0 U3e から再度無償化はされたが... • また有償化されるか不安、SPD にも無償版の記載はなく商用利用が不透明？ • 無償版ライセンスでは仮想マシンの vCPU 数に制限がある • そもそも商用サポートもないし、本番利用も当然非推奨 では、今回の騒動で日本でも一気に有名になった Proxmox VE を使ってみる？ • 必要機能も十分であり一元管理もできるし商用サポートもある • 普及してきたとはいえまだ日本での実績が少ない • Debian/Ubuntu 系コマンドに慣れてない KVM ということであれば AlmaLinux にも標準実装、どこまで使い物になる？ お話の背景
4. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 開発環境などに適しているその他の仮想化基盤 比較項目 Proxmox VE Hyper-V 提供 Proxmox Server Solutions GmbH 日本法人なし (日本はリセラーパートナーのみ) Microsoft コスト サポート 無償版でフル機能が使用可能 ※別途有償でのサポートもあり（ただしオーストリア時間） 限定版だが Windows10/11 Pro 等に組み込まれてい るため追加のコスト不要 ※フル機能の Windows Server 版でも標準で組み込まれているた め追加のライセンスコスト等は不要 ※ OS サポートがあれば Hyper-V もサポート範囲となる UI ブラウザベースの WebUI 日本語対応（一部英語だったり訳のブレなどあり） 専用 GUI ソフトウェア 日本語対応あり メリット ZFS, BTRFS など様々なファイルシステムに対応 Ceph による分散ストレージへの対応 SDN での仮想ネットワークへの対応 (一部試験扱い) LXC コンテナへの対応 Windows との親和性が高い PowerShell との併用による自動化などが可能 デメリット 複雑な構成も対応できるが高度な知識が必要になる マニュアル等が基本英語 普及してきたとはいえまだ日本での実績が少ない 機能が限定的 ※ HA 機能などはない ( Windows Server 版にはある ) 仮想スイッチなどのネットワーク系が心もとない ※ VLAN などを柔軟に構築できない場合もある
5. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 開発環境などに適しているその他の仮想化ソフトウェア 比較項目 Oracle VM VirtualBox VMware Workstation Pro 提供 Oracle OSS として公開 (GPLv3) Broadcom コスト 無償で使用可能 追加機能は商用利用不可（ライセンス購入必要） 2024 年 11 月に Pro を含め無償化 サポートなし UI 専用 GUI ソフトウェア 専用 GUI ソフトウェア メリット オープンソースでの提供 扱えるディスク形式が豊富 元々が商用版だったため高機能・安定性が高い 仮想マシンのパフォーマンスもよい 開発者向けツールが豊富 デメリット グラフィック機能が若干弱い 複雑なネットワーク構成が構築できないことも 開発ライフサイクルが不透明 無償版継続保証なし 「ホスト型」はサーバとして構築する必要がなくクライアント OS に気軽に導入できるメリットがあります。 VirtualBox については「今さら聞けない人のためのVirtualBox超入門」もぜひ参考にしてください。 https://almalinux.connpass.com/event/347462/
6. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 KVM: Kernel-based Virtual Machine Linux カーネルに統合された OSS の仮想化技術 広義: KVM, QEMU, libvirt など仮想化基盤の環境全体 狭義: Linux カーネルのモジュール (kvm.ko) のみ Cockpit: Web ベースの Linux 向け GUI サーバ管理ツール KVM 以外にもサーバ管理、Podman コンテナ管理なども可能 KVM と Cockpit
7. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 広義の KVM virt-manager: 仮想マシンを管理する GUI ツール (今回対象外) virsh: 仮想マシンを管理する CUI ツール libvirt: 仮想マシンなどを管理・操作するための API と ソフトウェア群 (KVM 以外に Xen なども対応) QEMU: 汎用的なマシンエミュレータ、また仮想化ツール 仮想マシンは qemu の 1 プロセスとして稼働 KVM/QEMU を組み合わせることで、高パ フォーマンスで GuestOS の稼働が可能に KVM の全体像 Hardware (CPU, Disk, NIC, etc...) Linux Kernel KVM (kvm.ko) QEMU libvirt virt-manager Cockpit virsh Other Linux Applications Guest OS Guest OS Guest OS Other Linux Applications 狭義の KVM
8. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 • 仮想マシンの作成、構成設定変更、起動停止 ◦ 一般的に必要となる部分は WebUI からの操作のみで対応可能 ◦ 詳細設定となると virsh などのコマンド等が必要になることも • スナップショット、クローン ◦ スナップショットは停止中、起動中（メモリスナップショット）双方対応 ◦ クローンは停止状態のみ • ライブマイグレーション ◦ 共有ストレージが存在しない環境でも可能 ◦ 停止状態での移動は不可 ( virsh では可能 ) ◦ スナップショットがある状態でのライブマイグレーションは不可 • WebUI 上でのコンソールアクセス Cockpit (WebUI) から出来ること、出来ないこと
9. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 • 複雑なネットワーク構成 ◦ Open vSwitch の利用が出来ない ▪ 標準リポジトリ外にパッケージは一部あるものの・・・・？ソースビルドすれば？ ▪ このあたりの機能を使うなら素直に Ubuntu/Debian 系を使ったほうが楽 ◦ VXLAN は利用可能なはず？ • 仮想マシンの自動バックアップ ◦ 標準機能のみでは対応できない ◦ 作りこめば追加製品なくとも可能だが・・・ AlmaLinux 版 KVM/QEMU が苦手なこと、出来ないこと
10. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 KVM/QEMU 環境の構築
11. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 今回の構成（必要スペック） 項目 要件など CPU Intel VT-x / AMD-V が有効な CPU OS + Cockpit として 4 core 程度 ほかに稼働させる仮想マシン分 メモリ OS + Cockpit として 4 ~ 8 GiB 程度 ほかに稼働させる仮想マシン分 ディスク OS + Cockpit として 60 GiB 程度 ほかに稼働させる仮想マシン分 ネットワーク 1 NIC 以上 冗長化や仮想マシンのセグメントを分割するなどの要件に応じて追加 OS AlmaLinux 10.1 インストール時に「仮想化ホスト」を選択 その他 NTP で時刻同期しておくことが望ましい
12. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 • OS インストール時のソフトウェアの選択は「仮想化ホスト」を選ぶ • その他の項目は、環境にあわせてで問題なし ◦ 今回は仮想マシンのディスク用領域は /datastore として別パーティション ◦ 仮想マシン向けのネットワーク設定は Cockpit から実施 ▪ インストーラで設定するより Cockpit のほうが楽です OS インストール
13. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 CPU 要件の確認（以下の３つのコマンドがポイント） • lsmod | grep kvm kvm_intel (Intel CPU) または kvm_amd (AMD CPU) が表示されることを確認します。 • lscpu Virtualization: に VT-x (Intel CPU) や AMD-V (AMD CPU) が表示されることを確認します。 • virt-host-validate 「成功」となって表示されることを確認します。以下の WARN は未使用であれば問題なし。 Checking for device assignment IOMMU support: WARN ☞ PCI パススルーが使用できません。 Checking for secure guest support: WARN ☞ Intel TDX や AMD SEV が認識されていない状況のためメモリ暗号化などが使用できません。 CPU の要件確認
14. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 • SELinux ◦ 基本的には Enforcing のままでも動作 ◦ Enforcing であれば仮想マシンが攻撃されるような場合も同一 KVM ホスト の別仮想マシンに攻撃が及ぶことを防げる場合も ◦ マイグレーションするときは disabled へ • Firewalld ◦ 標準の Public ゾーンのデフォルト設定でもまずは問題なし ▪ Cockpit, DHCPv6-client, SSH のみが許可 ◦ Public ゾーンの NIC を仮想マシンにブリッジで提供しても仮想マシンは ルールには関係なく通信可能 ▪ 仮想マシン側でファイアウォールを設定・制御する必要あり 追加設定
15. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 インストール時に仮想化ホストを選択しても cockpit-machines は入りません 以下のパッケージを追加します（必須以外はあると便利と思うものです） ➢ cockpit-files ◦ OS ファイル操作が可能になり ISO イメージのアップロードも Cockpit から可能 ➢ cockpit-machines ◦ 仮想マシンを Cockpit で管理するために必須のパッケージ ➢ virt-install ◦ コマンドで仮想マシンを作成するときにあると便利 ➢ virt-top ◦ 仮想マシンのリソース状況確認であると便利 ➢ virt-v2v ◦ 既存の ESXi などから仮想マシンを移行するときにあると便利 ➢ virt-v2v-bash-completion ◦ virt-v2v コマンドの bash 補完 追加パッケージ
16. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 Cockpit の使い方
17. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 ログイン 一般ユーザでログインした場合、 画面上部に制限がある旨が表示さるので解除します （ sudo と同じイメージです ) インストール時に作成した OS ユーザでログイン https://HOST_IP:9090/ 上記の URL でブラウザでアクセス ※ 自己証明の https 接続なので警告が出ます
18. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 KVM ホストのコンソールにも Cockpit からアクセス可能 ホストコンソール
19. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 仮想マシンに提供する Linux Bridge を作成 左側の「ネットワーキング」を選び「ブリッジの追加」を選択 ネットワーク設定 ① 作成する Linux Bridge 名と親となる NIC を選択 ( この NIC を仮想マシンに提供します )
20. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 複数の KVM ホストがあり、その間を物理ネットワークは共有するが通信は隔離し て接続したい場合など → VLAN を活用 ネットワーク設定 ② (必要があれば) 親となる物理 NIC と VLAN ID を指定 VLAN の NIC 名は任意で指定できますが、 親 NIC.<ID> が自動で入力されます ネットワーク設定①と同様に Linux Bridge を追加 作成した VLAN の NIC を選択します 作成した NIC は「IP 設定中」 物理から隔離セグメントへのアクセスが不要：IP 無効 KVMホストを踏み台にして隔離セグメントへ：IP 必要
21. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 複数 KVM ホストでの構成例 KVM ホスト #1 物理 NIC br0 br100 VLAN100 br200 VLAN100 VM#1 VM NIC VM NIC VM NIC KVM ホスト #2 物理 NIC br0 br100 VLAN100 br200 VLAN100 VM NIC VM NIC VM NIC VM#2 VM#3 VM#4 VM#5 VM#6 ←の構成場合： 異なる色の VM 間の通信不可 ただし、VLAN 上の VM には 物理セグメントからも不可 ↓ 例）br100 に IP 付与 KVM ホストを踏み台にして VM#2 と VM#5 にアクセス VLAN のお話になるので割愛 しますが、組み合わせること で複数のセグメントが異なる 開発環境をうまく同居させる ことも可能
22. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 左側で「ファイルブラウザ」を選択 (cockpit-files を入れている場合のみ) ※ホストコンソールから mkdir コマンドで作成しても OK です 仮想マシン用データディレクトリと ISO ディレクトリの作成 ① 左側下の「ファイルブラウザ」を選択 ② 上部のパスでデータ用のディレクトリを選択 今回の例では /datastore ③「︙」でプルダウンを開きディレクトリの作成 ④ 仮想マシン用ディレクトリ 今回の例では /datastore/machine ⑤ ISO 用ディレクトリ 今回の例では /datastore/iso
23. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 仮想マシン用と ISO 用のストレージプールを作成 ※ Cockpit で仮想マシンを作成すると自動作成されるので事前作成します ストレージプールの設定 仮想マシン用は名前「default」、ISO 用は名前「iso」 ※自動作成時にこの名前が使用されるので事前作成する タイプは「ファイルシステムのディレクトリー」を選択 ターゲットパスにはストレージ設定 ① で作成したパス 「ホスト起動時にプールを起動する」にチェック 「有効化」のボタンをクリックして「アクティブ」状態へ 「仮想マシン」→「x 個のストレージプール」 →「ストレージプールの作成」
24. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 仮想マシンの作成 「仮想マシン」→「仮想マシンの作成」 インストールタイプでは「ローカルインストールメディア」を選択 インストールソースで ISO ファイルを指定 → オペレーティングシステム選択は自動（選択されない時は手 動） ストレージは今回の構成例では qcow2 RAW 形式ではスナップショットが利用不可 ストレージのサイズとメモリサイズを指定 CPU コア数は後で指定 → 「作成して編集する」をクリック 「作成して実行」だと直後に起動してしまいます
25. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 「作成して編集」の編集する主な項目は？ • CPU ◦ vCPU 数、ソケット数、ソケットごとのコア数、コア 当たりのスレッド数、モードが設定可能 ◦ モードは最近の CPU であれば host-passthrough で • ファームウェア ◦ BIOS または UEFI ◦ Windows Server など TPM が必要な場合は UEFI 必須 ◦ あとから変更不可 • ブート順序 ◦ 複数のディスクや NIC からのブートなどの場合に • 自動起動 ◦ KVM ホスト起動時に自動起動するかどうか • ネットワークインターフェース ◦ 1 つの NIC が自動選択 ◦ 変更や追加があれば必要な Linux Bridge を指定 「作成して編集する」の実際の編集内容
26. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 「作成して編集する」を選んだあとの画面 ② NIC 構成を確認し、必要あれば編集 ① CPU やファームなど必要に応じて編集 ④ 編集が終わったら「インストール」 ③ 追加ディスクがあれば編集 指定した ISO はこの時点では非表示 ここにコンソールが表示されます
27. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 • virtio と scsi(virtio-scsi) の違い パフォーマンスは若干 virtio のほうが良いですが、PCI 直結のため PCI バス規格の制約を受けます - 最大 28 台 ( 実際には他の PCI デバイスもあるためもっと少ない ) - ホットスワップ非対応 - virtio-scsi で使える仮想 SCSI コントローラによる高度なストレージ機能が使えない • Cockpit で作成したストレージプールを指定しない ☞ UEFI 構成の仮想マシンの稼働中スナップショットが利用不可になってしまいます！！ 仮想マシンのディスクイメージの注意点 OK NG 【不可の理由】 UEFI 構成では NVRAM 領域として本体ディスクイメージ以 外に別のデータファイルが裏で自動作成されます。これが RAW 形式のため稼働中のスナップショットができません。 コマンドで NVRAM 領域を qcow2 にすることも可能です が、起動しない設定パターンもあるためお勧めしません。
28. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 仮想マシンの操作 「ボタン」と「︙」で仮想マシンを操作 主な操作できること • 実行 • 一時停止 • シャットダウン • シャットダウンの強制（電源ボタン） • 再起動 • 再起動の強制（リセットボタン） • 移行 ◦ ライブマイグレーション（稼働中のみ表示されます） • クローン ◦ 仮想マシンのクローン（停止中のみ表示されます） • 削除 ◦ クリック後の確認画面でディスクイメージも同時削除可能 ◦ ただし削除対象の選択には注意が必要
29. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 • Linux 系 OS の仮想マシン 細かい構成の制約を気にせず比較的自由に構成が可能 RHEL6.4 未満では VirtIO SCSI(sdX) が使用できないため virtio (vdX) を使用する必要あり 古い OS でも CPU モードは host-passthrough で動作可能 • Windows 系 OS の仮想マシン OS バージョンによって構成に制約があったり、追加手順などが必要になることも Windows Server 2016 / Windows 10 以降は UEFI + TPM が必須、VBS 利用には注意も必要 Windows Server 2003/R2 では host-passthrough が動かないことも ( qemu64 では動いた ) Windows 系インストーラは virtio/VirtIO SCSI を認識しない ( virtio のドライバ ISO が必要 ) または SATA/IDE としてディスクや CDROM を構成する必要あり NIC も rtl8139 や e1000 は標準で認識するが virtio は追加ドライバが必要 virt~~~~ は準仮想化のデバイス、完全仮想化のデバイスより高パフォーマンスを期待できるが... 仮想マシン作成時のポイント
30. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 仮想マシンのスナップショット
31. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 • 内部スナップショット 仮想マシンのスナップショットを 1 つの qcow2 ファイルで管理する方法 スナップショット取得中は仮想マシンが一時停止状態、また RHEL は非推奨扱い • 外部スナップショット（メモリ状態あり） 稼働中のメモリも含めたディスクデータを、仮想マシン本来の qcow2 ファイルとは別ファイル で管理する方法 Cockpit 上での稼働中の仮想マシンをスナップショットするときの手法 • 外部スナップショット（メモリ状態なし） 稼働中の仮想マシンであってもメモリを含まないディスクのみのデータを、仮想マシン本来の qcow2 ファイルとは別ファイルで管理する方法 Cockpit 上での停止中の仮想マシンをスナップショットするときの手法 スナップショットの種類
32. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 • CDROM 挿入中にスナップショットしない • スナップショットが存在する状態で CDROM を挿入・排出しない • スナップショットが存在する状態で仮想マシン構成を変更しない いずれも操作によっては仮想マシン構成が不整合となる場合があり、スナップショッ トの復元や削除といったことが出来なくなる場合もある ☞ コマンドにて復旧できる場合もあるが... Cockpit 操作だけではまず復旧できない ＜スナップショット運用におけるポイント（上記の問題回避のためには）＞ • スナップショットを多用する仮想マシンは CDROM ドライブは削除しておく • 可能な限り停止状態（メモリ状態を含まない）でスナップショットを実行 • 稼働中の仮想マシンのスナップショットは一時的なものとして扱う • 可能であればクローンも併用 • スナップショット関連の操作は Cockpit に限定、コマンドでは操作しない スナップショットの注意点
33. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 マイグレーション
34. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 • ライブマイグレーション 事前の環境準備や設定が必要 共有ストレージ有無に関係なく、ほぼ無停止で別の KVM ホストへ移動可能 Cockpit のみで一応完結（一応の理由は後述）、スナップショットがあると実行不可 • 停止マイグレーション？（単なる構成情報とディスクイメージの移動） 事前の環境準備や設定は不要 Cockpit からは実行できない（コマンド操作が必須）、スナップショットがあると実行不可 <マイグレーション運用のポイント（要件）> • KVM ホストでは、同一のパーティション構成、プール構成、NIC 構成が理想 • KVM ホストの CPU は近い世代であれば別メーカーでも可能だが同一が安全 • 仮想マシンのディスクイメージは qcow2 形式ファイルで構成しておく • 仮想マシンのスナップショットが存在しない状態で実施 KVM ホスト間の仮想マシン移動 (マイグレーション)
35. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 • 名前解決 ライブマイグレーション間の KVM ホストは名前解決が出来る必要あり 内部 DNS を用意してもいいですが、今回は /etc/hosts で代用 • データ転送で使用する SSH の準備 root での ssh 接続を使用するため、root で鍵を作成して ssh 鍵交換をしておく 鍵がない場合は root ユーザのパスワードを作成して～といったことが必要となる（割愛） ライブマイグレーションせずとも停止マイグレーションでも鍵交換をしておくと便利 • Firewalld のポート開放 以下のポート開放が必要 • 22/tcp データ転送の管理用として使用 • 16514/tcp 内部的な接続に使用 • 16509/tcp 内部的な接続に使用 • 49152-49215/tcp QEMU がメモリおよびディスクイメージデータの転送に使用 ライブマイグレーションの準備
36. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 今回は以下の構成 KVM ホスト #1 : kvm-host01 → 172.16.1.1 KVM ホスト #2 : kvm-host02 → 172.16.1.2 AlmaLinux 10.1 の /etc/hosts に追加するとこんな感じ 名前解決の準備 (/etc/hosts) # Loopback entries; do not change. # For historical reasons, localhost precedes localhost.localdomain: 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 # See hosts(5) for proper format and other examples: # 192.168.1.10 foo.example.org foo # 192.168.1.13 bar.example.org bar 172.16.1.1 kvm-host01 172.16.1.2 kvm-host02 kvm-host0* $ echo -e "172.16.1.1\tkvm-host01\n172.16.1.2\tkvm-host02" | sudo tee -a /etc/hosts
37. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 • 鍵作成 (kvm-host01 で作成) • 鍵転送 (kvm-host01 で作成した鍵を kvm-host02 へ) ※ 今の段階では root で ssh は出来ないので一度ログインしている一般ユーザ <username> に scp します • 鍵の再配置 (kvm-host02 で正しい場所へ再配置) マイグレーションのための SSH 準備 kvm-host01 $ sudo ssh-keygen -t ed25519 -N "" -f /root/.ssh/id_ed25519 -C kvm-host kvm-host01 $ sudo scp /root/.ssh/id_ed25519 <username>@kvm-host01:~ kvm-host01 $ sudo scp /root/.ssh/id_ed25519.pub <username>@kvm-host01:~ kvm-host02 $ sudo mv id_ed25519* /root/.ssh/ kvm-host02 $ sudo chown root:root /root/.ssh/id_ed25519 kvm-host02 $ sudo chown root:root /root/.ssh/id_ed25519.pub kvm-host02 $ sudo chmod go-rw /root/.ssh/id_ed25519
38. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 • authorized_keys に公開鍵を追加 • SSH ホストキーを登録 • SSH 鍵でのログイン確認 kvm-host01 と kvm-host02 のどちらでも kvm-host01 と表示されることを確認します kvm-host01 と kvm-host02 のどちらでも kvm-host02 と表示されることを確認します マイグレーションのための SSH 準備（続き） kvm-host0* $ sudo cat /root/.ssh/id_ed25519.pub | sudo tee -a /root/.ssh/authorized_keys kvm-host0* $ ssh-keyscan kvm-host01 | sudo tee -a /root/.ssh/known_hosts kvm-host0* $ ssh-keyscan kvm-host02 | sudo tee -a /root/.ssh/known_hosts kvm-host0* $ sudo ssh kvm-host01 hostname kvm-host0* $ sudo ssh kvm-host02 hostname
39. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 • firewall-cmd コマンドでポート開放とリロード 各コマンド実行にて success と表示されることを確認します • 最終的な結果 Firewalld のポート開放 kvm-host0* $ sudo firewall-cmd --permanent --add-port=16514/tcp --add-port=16509/tcp kvm-host0* $ sudo firewall-cmd --permanent --add-port=49152-49215/tcp kvm-host0* $ sudo firewall-cmd --reload kvm-host0* $ sudo firewall-cmd --list-all public (default, active) ~ 省略 ~ services: cockpit dhcpv6-client ssh ports: 16514/tcp 16509/tcp 49152-49215/tcp ~ 省略 ~
40. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 移行元の仮想マシンのディスクイメージは削除されません ライブマイグレーションの実行 仮想マシンのプルダウンメニューから「移行」を選択 宛先 URI: qemu+ssh://kvm-host02/system ストレージ:「ストレージのコピー」 共有ストレージの場合は「ストレージは 共有の場所にあります」を選択 ライブマイグレーションの開始
41. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 kvm-host02 上の kvm-test01 マシンを kvm-host01 へ移動する例 • ディスクイメージの移動 • 仮想マシン構成情報の移動 停止状態での仮想マシンの移動 kvm-host02 $ sudo scp /datastore/machine/kvm-test01.qcow2 kvm-host01:/datastore/machine/ kvm-host02 $ sudo rm /datastore/machine/kvm-test01.qcow2 kvm-host02 $ sudo virsh dumpxml kvm-test01 | sudo ssh kvm-host01 virsh define /dev/stdin ドメイン 'kvm-test01' が /dev/stdin から定義されました kvm-host02 $ sudo virsh undefine kvm-test01 --nvram --tpm ドメイン 'kvm-test01' の定義が削除されました
42. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 初期の qcow2 やライブマイグレーション後はシンプロビジョニングなし • ディスクイメージの最適化（シンプロビジョニング） • ディスクイメージの確認 7.47% allocated が実際に使用されている容量です No errors were found on the image や fragmented (断片化) も確認します 仮想マシンディスクイメージの最適化 kvm-host01 $ cd /datastore/machine kvm-host01 $ sudo mv kvm-test01.qcow2{,.bak} kvm-host01 $ sudo qemu-img convert -O qcow2 kvm-test01.qcow2.bak kvm-test01.qcow2 kvm-host01 $ sudo rm kvm-test01.qcow2.bak kvm-host01 $ sudo qemu-img check /datastore/machine/kvm-test01.qcow2 No errors were found on the image. 36707/491520 = 7.47% allocated, 0.00% fragmented, 0.00% compressed clusters Image end offset: 2406678528
43. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 おわりに
44. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 • インストールは「仮想化ホスト」の選択といくつかのパッケージ追加だけ • ネットワークなどの設定は Cockpit からが楽 • Cockpit には、いくつかイケてない制限もあるが、開発環境といったミッショ ンクリティカルでない日常使いであれば Cockpit のみでも利用可能レベル • マイグレーションによる仮想化ホスト側のメンテナンスにも対応可能 • 複数の仮想化ホストを用意する場合は、マイグレーションの予定がなくても同 一の構成で作っておく、かつ SSH 鍵交換だけはしておくと便利 libvirt 側と Cockpit 側の作り込みの足並みが揃っていない箇所が制約になってい ますが、スタンドアロンな仮想化基盤としては十分な機能が揃っています。 AlmaLinux + KVM + Cockpit まとめ
45. Copyright Cybertrust Japan Co., Ltd. All rights reserved. 公開 留意事項 本資料に記載されている会社名、製品名、サービス名は、当社または各社、各団体の商標もしくは登録商標です。 その他本資料に記載されているイラスト・ロゴ・写真・動画・ソフトウェア等は、当社または第三者が有する知的財産権やその他の権利により守られております。 お客様は、当社が著作権を有するコンテンツについて、特に定めた場合を除き、複製、改変、頒布などをすることはできません。 本資料に記載されている情報は予告なしに変更されることがあります。また、時間の経過などにより記載内容が不正確となる場合がありますが、当社は、当該情報 を更新する義務を負うものではありません。