はじめに

こんにちは。
株式会社SHIFT ITソリューション部アプリケーションサービスグループの尾﨑です。SHIFTでマイグレーション関係のお仕事をしております。
今回、以下のような事件があり、この記事を書いてみました。
ご興味のある方が、最後まで読んで頂けると嬉しいです。

ことの発端

Broadcom社が2023年末にVMware社を買収しましたが、大きな影響が各方面に出ています。
特に、2024年2月12日（米国時間）に発表した 永久ライセンス廃止と、仮想化ソフトウエア「VMware vSphere Hypervisor(以降VMware ESXi)」の無償版廃止が大きいです。

参考：VMware by Broadcom : 製品ラインアップとライセンスモデルを大幅に簡素化

今後、VMware社の製品やサービスが、従来同様に提供され続けるか不透明ですので、仮想化ソフトウェアであるVMWare ESXiの無償版を使ってきた多くの個人や企業が、サブスクリプションプランを契約すべきか、別の仮想化ソフトウェアに変更するべきかで迷っています。

中でも、本番サービスを提供している本番環境を有償契約するのは当然としても、いままで無償で使えていた開発環境まで、有償契約を迫られているのことが、問題の本質です。

自分も困っているので、思い切って仮想化ソフトウエアであるProxmox VEにマイグレーションしてみました。

１．仮想化ソフトウエアの選択

仮想化ソフトウエアには、「ホスト型」,「ハイパーバイザー型」,「コンテナ型」がありますが、「VMware ESXi」は「ハイパーバイザー型」ですので、移行先も「ハイパーバイザー型(※)」にしました。

(※)ハイパーバイザー型仮想化ソフトウエアとは
直接サーバーに仮想化ソフトウェアをインストールし、その上で仮想マシンを実行する方式のことです。メリットは、ホストOSが不要で直接ハードウェアを制御できることです。また、仮想マシンの処理速度低下を最小限に抑えることが出来ます。

以下の条件で仮想化ソフトウエアを選びました。
①仮想マシンのパフォーマンスを考え、ハイパーバイザー型仮想化ソフトウエアであること。
②開発環境等のために、無償利用ができて、無償で仮想化ソフトウエアをバージョンアップできること。
③本番環境の提供サービスのために、有償版の仮想化ソフトウエアにバージョンアップができて、サポートも受けられること。

２．Proxmox VEとは

Proxmox VE (Proxmox Virtual Environment)は、Debianベースの仮想化プラットフォームです。Webインターフェースを持つ、仮想化に特化したLinuxディストリビューションです。
Proxmoxサーバソリューション社（ウィーン、AT）が開発しています。
無償利用でのバージョンアップのみ、またはサブスクリプションによるバージョンアップ・保守サポートが選べます。

■画面例

３．Proxmox VEの機能

Proxmox VEの機能は以下の通りです。VMware ESXiと比較して、無償版で出来ることが多様です。

４．ESXiの仮想マシンをマイグレーションする手順

注意事項
このブログは、ESXiの仮想マシンをProxmox VEにマイグレーションする記事なので、Proxmoxサーバの環境構築に関する説明を行いません。
環境構築に関する説明は、以下のドキュメントを参考にしてください。

リンク：Proxmox VEの英文ドキュメントURL

マイグレーションのイメージ図

VMware ESXiからProxmox VEへのマイグレーションはシンプルです。以下の２STEP実行後に設定変更するだけです。

■イメージ図

STEP 1：仮想マシンのエクスポート

１）VMware社の「ovftool」をダウンロードし、Proxmoxサーバの任意の場所に配置します。
　　リンク：ovftoolダウンロードURL
２）ESXi側 の仮想マシン（VM）を停止します。
３）ESXi側との通信により仮想マシン(vmdk)および設定(vmx)を、OVFファイルと共にエクスポートします。

書式： ovftool vi://{アカウント}@IPアドレス/{VM名}  {配置パス}
例　： ovftool vi://root@192.168.100.100/WinSvr .　

STEP 2：仮想マシンのインポート

STEP1でエクスポートしたovfファイルに書かれた情報を使って、Proxmoxに仮想マシンをインポートします。
vmidは任意の番号を設定可能です。
ターゲットストレージは既存のLVMを指定します。作成するVMのディスクが入るか残容量を確認して下さい。

書式：qm importovf {vmid} {VM名}.ovf  {ターゲットストレージ} --format qcow2
例　：qm importovf 100 WinSvr.ovf  pve --format qcow2

５．仮想マシンインポート後の設定変更

仮想マシンをインポートしたら、以下の設定変更を行います。

１）Linuxの場合

■画面設定例

２）Windowsの場合

リンク：virtio-win-gt-x64.msiおよびvirtio-win-guest-tools.exeのダウンロードURL

■画面設定例

６．障害対策とバックアップ・リストア方法

以下の障害対策を検討し、実施しました。

１）ディスク障害

対策：
ディスク内の情報をNASにバックアップし、ディスク交換後にリストアで回復させる事にしました。

必須条件：
バックアップ先NASのディスクをNFSマウントしておきます。OS用のディスクと仮想マシン用ディスクを、物理的に別ストレージ(LVM)にします。

２）H/W筐体故障対策（マザーボード故障及び電源故障）

故障したH/W部品の交換にて対応します。部品単位での交換が難しい場合は、同型の筐体に交換します。
新しい部品を付けたH/Wに元々のディスク（OS用および仮想マシン用）を装着して起動する事で復旧します。

３）停電対策

電源喪失時には、 UPSにより仮想化サーバを自動シャットダウンしてディスクを保護します。
UPS各社のUPS装置および専用ソフトウエアにて実現します。我が家はOMRON社製UPSを使っています。

７．サポート体制の確認

以下にProxmox VEのサポート体制を記載しました。
開発環境を提供しているProxmoxサーバは、コミュニティサポートを無償で受けれられますが、本番サービスを提供しているProxmoxサーバは対象外となりますので、ご注意下さい。

リンク：コミュニティフォーラムURL
リンク：ベンダサポートURL
リンク：トレーニングプログラムURL

８．パッチ適用方法の確認

１）Proxmox VEのパッチ適用

本番運用しているサーバの場合は、 Proxmox社のサブスクリプション契約を行い「Proxmox Enterprise Repository」からパッチを取得する必要があります。また、開発用のサーバの場合は、Proxmox社が提供する「 No-Subscription 」を設定することで無償パッチ適用が可能になります。

定期的に手動でパッチ適用をしましょう。以下の手順で適用が可能です。
「データセンター」→「ノード」→「アップデート」から、「再表示」押下→「アップグレード」押下
※パッチ適用にはインターネット接続が必須です。
Proxy環境の場合は、当該サーバから「proxmox.com」および「debian.org」へのインターネット接続を許可する必要があります。

２）仮想マシンへのパッチ適用

仮想マシン側OSも、定期的にパッチ適用をしましょう。
Windowsなら[Windows Update]で更新します。
Linux の場合は、yumまたはdnf(Redhat系)、apt(Debian系)などで更新します。

３）仮想マシンのバックアップ取得タイミング

仮想マシンのアップデートを実施したタイミングで、OS停止状態のVMをバックアップしましょう。
またアプリで使用するデータを、全てNASやクラウドストレージに保管できれば、バックアップをリストアしても、障害時点までの差分を少なくすることができます。

９．ユーザーエクスペリエンスの向上

以下に、実際にマイグレーションをした際のエクスペリエンスを記載します。皆さんの参考になれば幸いです。

１）移行時のトラブル

Linuxの移行（マイグレーション）はスムーズに完了しましたが、Windowsではトラブルが発生しました。
原因はWindowsが「VirtIO SCSI」を標準サポートしていない事です。ディスクにIDEやSATAを指定ないとWindowsが起動しないのですが、IDEドライバやSATAドライバは、ディスクアクセススピードが遅いのです。
仮想マシンの格納先がHDDだった事もあり、起動途中でWindowsが停止してしまいました。

HDDを廃止し、代わりにより高速なNVMe上に仮想マシンを格納するようにしたところ、Windowsが起動し、「VirtIO SCSI」ドライバ導入が出来ました。また、仮想マシン側のディスク設定を「VirtIO SCSI」にして問題なく使えるようになりました。

２）機能面で良かったこと・困ったこと

VMWareは、仮想マシンファイル(vmdk)と設定ファイル(vmx)が同一のディレクトリにあるので、VMの再登録も簡単ですが、Proxmox VEは別々の場所にあるため、OSディスク障害からの復旧方法の確認時に、設定ファイルの場所が分からずに困りました。

上記以外には、VMWare ESXiに劣る機能差はありませんでした。
むしろProxmox VEの方が高機能で、VMware ESXiの方が少ないです。

３） H/W障害時のAD認証問題

Proxmox VEが入ったH/W筐体が故障した場合、中に入っているWindows Serverが停止してしまうので、AD認証が使えなくなります。※そもそのADが１台という運用が問題ですが、今は触れません。

そのため、時間が経てば経つほどWindows端末にログインできなくなったり、NASがAD認証エラーを発生させる可能性があります。

そこで、PC上のVMware Workstation Proに、Proxmoxサーバから転送した仮想マシン(Windows Server)のをコピーし、稼働できるようにしました。 具体的には、ADが入った仮想マシン(Windows Server)のバックアップファイルを、コマンドでvmdk形式の仮想マシンに変換し、作成したvmdkファイルをPCへ転送したのです。

これにより、AD認証ができるため、故障修理完了までの時間が問題ではなくなりました。

なお、上記で作成した仮想マシンは、バックアップファイルから作っているため、時間差の影響でWindowsに差分が発生していますが、一時的にAD認証をするだけならば十分です。

４）バックアップソフトの標準化

VMware ESXiには、標準ではバックアップソフトが存在しません。そのため、ghettoVCBというフリーソフトのシェルスクリプトを使っていました。しかし、シェルスクリプトであるため、バックアップ/リストアはコマンド操作です。それなりの手間がかかっていました。

一方で、Proxmox VEは、バックアップ機能が標準で装備されており、Web画面にてバックアップ/リストアが可能です。
かなり、楽になりました。

５）アップデート方法の違い

VMware ESXi の場合、インターネットからアップデートISOを入手し、DVD-ROM化する手間がありました。また、DVDでPCを起動しアップデートを適用する必要があるため、サーバの置き場所へ行き、手作業を行う必要がありました。

一方、 Proxmox VEの場合は、aptコマンドにより、更新パッケージの入手と適用まで行え、遠隔実行ができます。
こちらも、大きく改善しました。

６）Performance Hybrid Architecture問題

VMware ESXiは、Intel 12th 以降の一般ユーザー向けPCに搭載されるCPU「Pシリーズ」が搭載するPerformance Hybrid Architecture(P-Core と E-Core)をサポートしていません。
ただし、カーネル オプション「cpuUniformityHardCheckPanic=FALSE」を付与して起動するといった、回避策がありますが、サポート対象外の方法です。今までは、これで起動していました。

一方で、 Proxmox VEは、（正確にはDebian/Linuxのカーネル）はPerformance Hybrid Architectureをサポートしていますので、今まで使っていたハードうウエアで問題なく動作しております。

７）コスト削減効果

VMware ESXiは、H/Wの制限（CPUおよびNIC）が多く、対応機種の多くはPCサーバ機です。そのため、設備投資費用が高くなりがちです。

一方でProxmox VEは、Debian/LinuxがベースOSのため、ほぼ全てのPC用CPUとNICがサポートされています。よって、いま使っているハードウエア（PC)が故障したとしても、整備投資費用を低くすることが可能です。
#Intel VTまたはAMD-Vを備えたEMT64またはAMD64というCPU制限がありますが、これを備えた製品が多数あります。

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/

PHOTO：UnsplashのChristopher Burns