お世話になります。
物理マシンを仮想化することをP2V(Physical to Virtual)といいますが、今回以下のような構成で行ってみます。
できるだけIT管理者が負担にならない方法を目指すこととします。
流れ
- Disk2VHDを使って物理ディスクを仮想ディスク(VHDX)に変換する
- Proxmox上に中継ファイルサーバーを作り、/var/vz/imagesにシンボリックリンクを作成する
- VHDXを変換してProxmoxのVMにアタッチする
まず物理SSDを仮想ディスク(.VHDXファイル)に変換します。マイクロソフト謹製のDISK2VHDというツールをダウンロードします。
exeを実行すると、保存先が指定できます。
トータルが120GBのSSDで、利用中なのは15GB程度でした。この15GBだけ可変ボリュームとして変換しますので、無駄な処理がなく、便利です。
通常、保存先として、
・外付けUSBディスク
・ネットワークドライブ(NAS)
を指定することが多いですが、大量ボリュームのためNASだとGbEの制約で低速となり、SSDが数百ギガに及ぶ場合、かなり時間が待たされます。
また、外付けUSBディスクの場合はNASより多少早いものの、「いったんコピー」という形になるので、仮想サーバーまでの再コピーで2倍時間がかかってしまいます。また企業PCとしてはセキュリティ的に難点があります。
そこで今回は「直接Proxmoxサーバにアップロードする」という方法ができるか検証します。物理マシンの画面はいったんおいておきます。
こちらのサイトを参考にし、ProxmoxへのSSH接続&SMB共有としての中継サーバーを作ります。
https://taiyakon.com/2018/08/windowswinsshfs-vmubuntusshfssmb.html
中継サーバーからシンボリックリンクを貼るというのは素晴らしい発想だと思いました。
WinSSHFSを直接ゲストWin10にマウントすると不安定という情報があったので、このような中継方法のほうが安定しそうですし、複数のクライアントに効率的に対応できそうです。
ディストリビューションは何でもよいのですがTurnkey File Serverを利用しました。
ProxmoxでTurnkeyをインストールします。
クライアント側へのSMB共有ができました。前回のWin10マシンが不調になったため別マシンに切り替えています。
続いて、中継ファイルサーバーにてsshfsをインストールします。
apt-install sshfs
空のフォルダを作成します。ここが中継点となります。Proxmoxへのシンボリックリンクを作るようなイメージだと思います。
SSHFSでマウントします。中にファイルがあるとエラーになってしまうので注意してください。
sshfs -o auto_cache -o reconnect -o allow_other -o idmap=user username@proxmoxserver:/var/lib/vz/images /srv/vhdx-transfer
SAMBAのWebminで改めてこのフォルダーを新規共有し、クライアントから見えるようになりました。
テキストファイルを置き、Proxmoxから見えることを確認します。
ここでDISK2VHDの操作に戻ります。ディスクイメージの出力先(コピー先)として先ほどのvhdx-transfer共有フォルダを指定します。
交換したマシンはクリーンインストール直後なので、9GBで済むようです。
ファイル名はシリアル番号など、会社で決めている管理名で分かりやすくしておきます。
移行が開始します。残り時間が表示されるのが便利です。古いHDDを積んだPCやサーバーだと数時間はかかります。
続いて、このディスクの受け皿となる仮想マシン(VMWareでいうところのコンピューティングリソース)をProxmox側で先に作っておきます。
以下のサイトを参考にさせていただきました。
https://www.youtube.com/watch?v=nriWlbCXKmU
既存の仮想マシンと区別するためマシンIDは201としました。
新規ディスクを作成しますが、これは一時的なダミーで、このダミーを物理マシンのvhdxファイルで上書きし、OSとして起動させるような流れになります。(今回のポイントとなります)
また通常Virtio-SCSIという準仮想化ドライバを使いますが、今回は初回起動時のドライバ読み込みのトラブルを避けるためにSATAのエミュレーションとします。
vm-201-disk-0というダミーディスク名をメモしておきます。
先ほどP2VしたVHDXを、QCOW2というKVMの推奨形式に変換し、同時にダミーディスクを上書きしますます。シェルから以下のコマンドを実行します。
qemu-img convert -O qcow2 /var/lib/vz/images/WIN-1TMGC5NI0K6.VHDX /var/lib/images/201/vm-201-disk-0.qcow2
ここでエラーになってしまいました。QCOW2への変換を想定していましたが、LVM-Thinによるブロック単位でのコントロール(シンプロビジョンやスナップショット機能)をしている場合、RAWイメージしか使えないようです。LVM-ThinはProxmoxの標準インストール方式です。
https://forum.proxmox.com/threads/qcow2-unavailable-grayed-out-4-2.27482/
本家のユーザーフォーラムによると、LVM-Thin運用の場合、vhdxをRAWとして直接インポートできるようです。
https://forum.proxmox.com/threads/converting-vhdx-to-raw.36354/
以下のコマンドを実行しました。
qm importdisk 201 /var/lib/vz/images/WIN-1TMGC5NI0K6.VHDX local-lvm
ハードウェアのオプションを見ると、しっかり認識されています。
このような状態になることを確認します。また、ブート順も変えておきます。
とくにドライバの再起動など求められることなくすんなりと起動しました。
変換元となったVHDXは削除するか、ユーザーアクセス権限のない場所にしばらく保存しておくなど想定されます。
中継サーバーを同じProxmox上に作っておくことで、SAMBA共有とSSHでの二重コピーとならず、迅速にP2Vができることが確認できました。
また、KVMへのP2VツールはCloneZillaが有名ですが、USBブートを各マシンで行う必要があります。今回はWindows上から実行し、かつ外付けディスクも不要なため、社内ネットワークにさえつながっていれば完全リモートでも可能と思われます。