VMwareからKVMへの移行を検討する際、「移行後の運用をどう設計すればいいのか」という不安を持つ担当者は少なくありません。VMware vCenterのような統合管理ツールに慣れている環境では特に、KVMへの移行後の運用体制が見えにくく、移行の踏み出しを妨げる要因になりがちです。
本記事では、KVM環境の運用設計における4つの主要テーマ——監視・バックアップ・HA（高可用性）構成・運用自動化——について、VMwareからの移行者が押さえておくべきポイントを解説します。
この記事で分かること
- KVM環境の監視設計：OLVMを含む監視ツールの選択・監視対象の3層設計・VMwareからの移行で変わるポイント
- バックアップ設計：スナップショット・ファイルベースの2方式とRPO/RTOの考え方
- HA（高可用性）構成：Pacemaker/Corosync（KVM HA）・Oracle RAC/SEHA・Dbvisit StandbyMPによるDR、およびCPUピン留め時のライブマイグレーション制限
- 運用自動化：Ansible/Terraformによる構成管理と日常運用タスクの効率化
1. KVM環境の監視設計
監視対象の整理
KVM環境の監視は、大きく「ホスト（物理サーバー）」「VM（仮想マシン）」「リソース使用率」の3層で設計します。VMwareでいえばvCenter・ESXiの監視に相当しますが、KVMでは監視の仕組みを自前で整備する必要があります。
ホスト監視
- CPU・メモリ・ストレージ・ネットワークの使用率
- KVMプロセス（libvirtd）の稼働状態
- ハードウェア障害（ディスク故障・メモリエラー等）
VM監視
- 各VMのCPU・メモリ・ディスクI/O・ネットワーク使用率
- VMの稼働状態（running / paused / shutoff等）
- ゲストOS内のアプリケーション監視（OS内エージェントが必要）
リソース使用率監視
ホスト・VM単体の監視に加え、クラスタ全体のリソース使用率を俯瞰する視点も重要です。特に以下の指標を継続的にトラッキングすることで、リソース不足の予兆検知や適切なVM配置計画に役立てられます。
- ホスト全体のCPUオーバーコミット率（物理コアに対して割り当てた仮想CPUの比率）
- メモリオーバーコミット率（物理メモリに対して割り当てた仮想メモリの比率）
- ストレージプールの使用率・空き容量
- ネットワーク帯域の使用率・パケットロス率
監視ツールの選択肢
KVM環境の監視には、オープンソースツールを組み合わせて使うのが一般的です。主な選択肢は以下の通りです。
| ツール | 特徴 | 向いているケース |
| OLVM（Oracle Linux Virtualization Manager） | Oracle社提供のKVM統合管理コンソール。VMwareのvCenterに相当。日本語GUIあり。Hard Partitioning設定にも必要 | 複数のKVMホストを統合管理する場合・Hard Partitioningを利用する場合 |
| Prometheus + Grafana | メトリクス収集・可視化の定番OSS。node_exporterやlibvirt_exporterと組み合わせて使う | リアルタイム監視・グラフ可視化を重視する場合 |
| Zabbix | エージェント型の総合監視ツール。豊富なテンプレートがあり設定しやすい | 既存のZabbix環境がある場合・幅広い監視項目を設定したい場合 |
| Nagios / Icinga | 老舗の監視ツール。プラグインが豊富 | シンプルな死活監視・既存Nagios環境との統合 |
| Virt-Manager | KVM標準のGUI管理ツール。VMの状態確認・基本的なリソース監視が可能 | 小規模環境・シンプルな管理を優先する場合 |
VMwareからの移行で変わるポイント
VMware環境ではvCenterが監視・管理を統合していましたが、KVMではOLVMや個別のOSSツールを組み合わせて代替する必要があります。移行時に特に注意が必要なのは以下の点です。
- vCenter Alarmに相当するアラートの再設定（Prometheus Alertmanager・Zabbixのトリガー等で代替）
- VMwareのパフォーマンスグラフに相当するダッシュボードの構築（GrafanaでESXi相当のビューを作成）
- ライブマイグレーションの監視（CPUピン留め使用時は利用不可。使用しない構成では手動またはスクリプトで実施のため、移行ログの監視を別途設計）
2. バックアップ設計
KVMでのバックアップ方式
KVM環境のバックアップは、主に「スナップショット」と「ファイルベースバックアップ」の2方式で設計します。
① スナップショット（内部スナップショット・外部スナップショット）
virshコマンドやlibvirtを使って、VMの状態を特定時点でキャプチャする方式です。内部スナップショットはqcow2形式のディスクイメージ内に保存され、取得・復元が容易です。外部スナップショットはディスクイメージを別ファイルに分岐させる方式で、本番環境に影響を与えずにバックアップできます。
主なツール：virsh snapshot-create（libvirt標準）、virt-backup（スナップショット管理の自動化）
② ファイルベースバックアップ
VMのディスクイメージファイル（.qcow2 / .raw等）を直接コピーする方式です。VMを停止した状態でのコールドバックアップが最もシンプルですが、稼働中のVMに対してはrsync等を使ったライブコピーも可能です。バックアップ先として、NFSやiSCSIのネットワークストレージ、またはオブジェクトストレージ（S3互換）を利用するケースが一般的です。
主なツール：rsync（差分コピー）、Bareos / Amanda（スケジュール管理・世代管理・リモート転送を統合管理するOSSバックアップツール）
RPO / RTOの考え方
バックアップ設計の前提として、RPO（目標復旧時点）とRTO（目標復旧時間）を業務部門と合意しておくことが重要です。
| 指標 | 定義 | KVMでの対応例 |
| RPO（目標復旧時点） | 障害発生時に「どの時点まで」のデータを復元できればよいか | スナップショットの取得頻度で制御（例：1時間ごと取得 → RPO 1時間） |
| RTO（目標復旧時間） | 障害発生から「何時間以内に」業務を再開できればよいか | スナップショットからの復元時間・バックアップ転送時間を事前に計測 |
VMwareのvSphere Data ProtectionやvSphereレプリケーションと比べると、KVMでは同等の機能をOSSで構成することになります。初期設定の工数はかかりますが、ライセンスコストなしで柔軟な構成が実現できます。
3. HA（高可用性）構成
Pacemaker / Corosyncによるクラスタ構成
KVM環境でHAクラスタを構成する場合、Pacemaker（クラスタリソースマネージャー）とCorosync（クラスタ通信基盤）を組み合わせるのが標準的なアプローチです。VMレベルのHA（KVMホスト障害時にVMを別ホストで自動起動）を実現します。
なお、Oracleデータベース自体のHA（DBレベルの冗長化）については、以下の構成も利用可能です。
- Oracle RAC（Real Application Clusters）：Oracle Database EE向けの複数ノードによるアクティブ-アクティブ構成。KVM上のVMで構成可能
- Oracle SEHA（Standard Edition High Availability）：Oracle Database SE2向けのHA構成。RACより低コストで冗長性を確保できる
KVMレベルのHA（Pacemaker/Corosync）とOracleレベルのHA（RAC/SEHA）は目的が異なるため、要件に応じて組み合わせを選択します。
Pacemaker / Corosyncの基本的な構成手順
- CorosyncによるKVMホスト間のクラスタ通信設定
- PacemakerによるVMリソース（仮想マシン）の定義
- フェンシングデバイス（STONITH）の設定：スプリットブレイン発生時の安全な障害ノード切り離し
- 共有ストレージの設定（iSCSI / NFS / GlusterFS等）：フェイルオーバー先でVMディスクにアクセスできるよう構成
VMware HAとの比較
| 機能 | VMware HA | KVM（Pacemaker/Corosync） |
| 障害検知・自動再起動 | ◎（vCenter管理下で自動） | ○（Pacemakerで設定） |
| 設定の容易さ | ◎（GUIで完結） | △（構成によってはCLI・個別設計が必要） |
| フェンシング設定 | ◎（vCenter管理下で自動） | △（STONITH設定が必要） |
| ライセンスコスト | ×（VMware有償） | ◎（OSS・無償） |
ライブマイグレーション
KVMはライブマイグレーション（稼働中VMの別ホストへの無停止移動）をサポートしており、計画的なメンテナンス時のダウンタイムを最小化できます。
【重要】CPUピン留め使用時はライブマイグレーション不可
ただし、OracleライセンスのHard Partitioning（ライセンス最適化）を目的としてCPUピン留めを設定している場合、仮想マシンが特定の物理コアに固定されるため、ライブマイグレーション機能は利用できません。
CPUピン留めを使用しない構成（Oracleライセンス最適化が不要な非Oracle VMなど）では、ライブマイグレーションを利用可能です。環境設計時にOracleライセンス最適化とライブマイグレーションはトレードオフとなるため、要件に応じて構成を検討する必要があります。
ライブマイグレーションを利用するには、移行元・移行先のホスト間で共有ストレージが必要です。また、CPU世代が大きく異なるホスト間では互換性の問題が発生することがあるため、ホストのハードウェア選定時に注意が必要です。
VMware vMotionとの比較
| 機能 | VMware vMotion | KVM ライブマイグレーション |
| 稼働中VMの無停止移動 | ◎（vCenter管理下で自動） | ○（virsh migrate コマンドで実行）※1 |
| 操作方法 | ◎（GUIで完結） | △（構成によってはCLI・個別設計が必要） |
| 共有ストレージ | ◎（vSAN含む多様な選択肢） | ○（iSCSI / NFS / GlusterFS等） |
| CPU互換性 | △（EVC設定で緩和可能） | △（CPU世代差が大きいと要注意） |
| ライセンスコスト | ×（VMware有償） | ◎（OSS・無償） |
※1 CPUピン留め（Hard Partitioning）を使用してOracleライセンスを最適化している場合、VMが特定の物理コアに固定されるためライブマイグレーションは利用不可。CPUピン留めを使用しない非Oracle VM等では利用可能。
DbvisitによるOracle HA / DR構成
KVM環境でOracleデータベースを運用している場合、Oracle自体の高可用性・災害対策（DR）として「Dbvisit」の活用が有効です。
Dbvisit StandbyMP
Oracle Database Standard Edition向けのログ転送型スタンバイ構成ツールです。プライマリDBのアーカイブREDOログをスタンバイサーバーに転送・適用することで、Oracle Data Guardと同等のDR構成をより低コストで実現できます。KVM環境のVMとして構成する場合も対応可能です。
- 対象：Oracle Database Standard Edition 2（Oracle RAC非対応環境）
- RPO：数分〜十数分（ログ転送間隔に依存）
- フェイルオーバー：手動または半自動での切り替え
- Pacemaker/Corosyncとの組み合わせ：KVMホストレベルのHAとOracle DBレベルのDRを階層的に構成可能
VMwareからKVMに移行したタイミングで、Oracleのライセンス最適化（Hard Partitioning）とDbvisitによるDR構成を合わせて整備することで、コスト削減と可用性確保を同時に実現できます。
▼ Dbvisit StandbyMPの詳細
https://www.insight-tec.com/products/dbvisit
4. 運用自動化
KVM環境の日常運用をスケールさせるために、構成管理ツールによる自動化が有効です。VMware環境のvRealize Automationに相当する役割を、OSSツールで実現できます。
Ansibleによる構成管理
AnsibleはKVM/libvirtに対応したモジュールを標準提供しており、VMの作成・起動・停止・スナップショット取得・ネットワーク設定などをコードで管理できます。
- VMプロビジョニングの自動化（テンプレートからのVM作成）
- KVMホストの設定管理（libvirt設定・ネットワーク設定）
- 定期的なスナップショット取得・バックアップ処理のスケジューリング
- 複数ホストへの設定変更の一括適用
Terraformによるインフラ管理
TerraformのlibvirtプロバイダーをKVM環境に対して利用することで、インフラ構成をコードで定義・管理できます。特に複数のVM環境を統一的に管理したい場合や、クラウドとオンプレミスのハイブリッド環境を扱う場合に効果的です。
日常運用タスクの自動化例
Ansible・Terraformで対応できる主な日常運用タスクを整理します。
| 運用タスク | 自動化方法・ツール |
| VMプロビジョニング（テンプレートからの作成） | Ansible（community.libvirt モジュール） |
| KVMホスト・ネットワーク設定の構成管理 | Ansible Playbook / Terraform（libvirt provider） |
| インフラ構成のコード管理・バージョン管理 | Terraform（libvirt provider） |
| 定期スナップショット取得 | Ansible Playbook + cronジョブ |
| VM起動・停止スケジュール | virshコマンド + systemdタイマー |
| 複数ホストへの設定変更の一括適用 | Ansible Playbook |
| ホストへのパッチ適用（ローリングアップデート） | Ansibleによる計画的なローリングアップデート |
まとめ
VMwareからKVMに移行した後の運用設計について、4つのテーマで解説しました。
- 監視：OLVMで複数KVMホストを統合管理しつつ、Prometheus/Grafana・Zabbix等のOSSツールを組み合わせてホスト・VM・リソースの3層監視を設計する。vCenterに相当するアラート・ダッシュボードを別途構築する必要がある
- バックアップ：スナップショット（virsh / virt-backup）とファイルベースバックアップ（rsync / Bareos / Amanda）を組み合わせ、業務要件に合ったRPO/RTOを設計する
- HA構成：Pacemaker/CorosyncでVMレベルのHA（KVM HA）を実現。Oracle DBレベルのHAはRAC・SEHAを組み合わせて対応。Dbvisit StandbyMPでOracle SE2向けのDR構成も構築可能。なお、CPUピン留め（Hard Partitioning）使用時はライブマイグレーションが利用不可となる点に注意
- 運用自動化：Ansible/TerraformによってVMプロビジョニング・構成管理・日常運用タスクを自動化し、運用負荷を削減できる
VMware代替製品の比較については「VMware代替を徹底比較｜KVM vs Hyper-V vs Nutanix vs Proxmox」もご覧ください。
インサイトテクノロジーでは、VMwareからOracle Linux KVMへの移行を支援するとともに、移行後の運用設計・構築もワンストップでサポートしています。
▼ 導入事例集をダウンロード
VMwareからの移行を検討する企業の導入事例をまとめた資料をご用意しています。
https://www.insight-tec.com/download/document_0070
▼ Oracle Linux KVM移行ソリューションの詳細
https://www.insight-tec.com/products/consulting/kvm_solution
▼ 移行に関するご相談
自社環境に最適な移行先の選定、コスト試算など、お気軽にご相談ください。
https://www.insight-tec.com/products/consulting/kvm_solution/#f
