１．この記事の背景
ちらほら技術記事も書きたくて、ちょっと前に立ち向かった案件から事例を紹介したいと思います。
２．注意
環境によっていろいろ条件が異なります。
この手順でうまくいかない、新たな不具合が発生するケースもあり得ます。
ご自身の判断と責任で取り扱いをお願いいたします。
３．結論
・仮想マシンを稼働させたまま別のクラスタに移行する手段として、「System Center Virtual Machine Manager」が使える。
・でも基盤リプレースであれば、仮想マシン停止の方向性が幸せ。
４．環境
・Windows Server Failover Clustering 2019
・System Center Virtual Machine Manager2019 UR2
・仮想マシンのOS(Wndows Server2016/2019、Redhat7.x、CentOS7.x)
５．移行方法あれこれ
| 手段 | 具体的な方法 | 備考 |
|---|---|---|
| WSFCの機能 | [移動]をクリック | 同じクラスタ内のノードしか移動先に選べない |
| SCVMMの機能 | [バーチャルマシンの移動]をクリック | SCVMMに登録しているホストならどこへでも移動できる |
| ファイルコピー | 仮想マシンを停止し、VHD/VHDXを移動先にコピー。 新規に仮想マシンを作成しVHDXファイルを紐づける。 |
仮想マシンの停止が必要(静止点を確保するため) |
| バックアップデータからのリストア | フルバックアップを取得し、移動先ホストにリストア | 仮想マシンのIPバッティングに注意が必要 |
・WSFCの画面
・SCVMMの画面
６．★超重要★注意
基盤が変わるというのは外科手術的なものです。
うまく移動できたとしても、仮想マシンがうまく新しいホスト上で動けずリフレッシュのため、新しいホスト上で再起動が必要な場合があります。
(仮想マシンがホストへアクセスする際、読み取れない情報をキャッチして自動再起動など)
(移動当初数日は機嫌よくＶＭも動いてくれていたのに、突然OS再起動が発生したり・・※実話)
やはり基盤リプレースであれば、仮想マシン停止の方向で検討したほうが幸せな気がしました。