さぁ移行！いざ変換の沼へ！VMCへLegacy OSを移行してみよう～ 仁義なきConverter編～

こんばんわ。

つい先日、ようやく体重が80Kg台を切りました。

ここ数年の健康診断では、肥満でもなく標準でもない、軽肥満とかいう中途半端なカテゴライズに放り込まれていました。

一念発起して、週末の運動と食事制限を開始したところ、84.3kgあった体重が、現在79.3kgまでに落ちました！

いやー、資格試験合格した時より嬉しかったですね！

お仕事は苦しいことばかりですが、腐らず技術力向上も、自分磨きも続けていきたいですね。

さて、今回は、VMware Cloud on AWS(VMC)への仮想マシン移行手段として「vCenter Converter Standaloneを使ったLegacy OS移行」をご紹介したいと思います。

これ、俺、超得意。とか思っていた時期もありました。

VMware製品に携わり続けてそろそろ8年ほど経ちますが、作成した仮想化基盤に対して、物理マシンを仮想マシンとして移行したい！というお客様はたくさんおられました。

物理から仮想へ移行することをP2V(Physical to Virtual)と呼びますが、これには色々なやり方があります。

・Acronis True Imageを使って物理マシンのOSをイメージ化する

・Plate Spinなど変換機能を持ったソフトを使う

・ベアメタルバックアップ→リストア 機能を使う

私がパッと思いつくのはこれぐらいです。

もっとあるだろーが、このヘッポコSEが！と思った貴方。

仕方ないんです…私の技術力はvSphereに特化しすぎたせいで、技術の幅が狭いのです…。

閑話休題。

さて、そんなP2Vですが、VMwareが無料で公開しているツールとして、

vCenter Converter Standalone(以降Converter) というツールがあります。

これ、無料ツールなのですが、ポイントを押さえておけば、凄い優秀なツールです。

① 移行元仮想マシンのログイン情報を入力

② 移行先の仮想化基盤の情報を入力

③ 移行して出来上がる仮想マシンのスペックなんかを入力

④ ( ^)o(^ )

の4ステップで、物理マシンを仮想マシンへ変換できてしまいます。

ちなみに、私は過去数十件移行案件をやりましたが、Conveterを使った移行案件だけは、失敗したことがありません。つまり、超得意です。

私の唯一の特技です。えっへん。

戯言はともかくとして、移行やってみよう。

さて、そんな私が超得意なConverterですが、先日ついに逆襲(?)されてしまいました。

要は、移行失敗です。

ご紹介します。

物理のWindows Server 2003 R2 SP2を、VMCへP2Vするという作業なのですが、この作業でConverterを使いました。

上記に書いたように、色々移行のやり方はあるのですが、ソフトを使うと基本的に有料です。

今回はお金をかけずに、ということでしたので、Converterを使いました。

ご存じの通り、2003 R2 SP2は、Microsoftもとっくの昔にサポートを打ち切っているレガシーOSです。

ただ、業務システムの関係でレガシーOSを使い続けている企業さんはたくさんあります。今回は、延命のためVMC環境へP2Vをやることになりました。

なお、Converterは、2017にリリースされた6.2.0.1以降、新しいバージョンはリリースされていません。

よって、2021年現在使える最も新しいバージョンは、6.2.0.1です。

しかし、この6.2.0.1、リリースノートをよく見ると…

はい。

サポートOSに2003 R2とかないですね！

つまるところ、Not Supportです。

しかも、Interoperabilityを見ると…

VMCのvCenterバージョンである7.0もNot Support！

なんということでしょう。

この世には、神も仏もいないのか。

ボク「こ、Converterきさまー！どれだけの互換性をそのバージョンにたどり着くために、切り捨てた！？」

Converter「お前は今までに食ったパンの枚数をおぼえているのか？」

ということで、このブログを見ている良い子のみんなも、悪い子のみんなもvCenter Convereter Standaloneを使ったVMCへの移行自体そもそもNot Support構成である旨、念頭に置いてくださいね☆彡

VMCへ移行する前に

Converterに使用されるポートは、以下の通りです。

特に

443と902を多用します。

これらは事前に、VMCのManagement GatewayのFirewallルールで穴あけしておいてください。

さぁ移行！

ConverterをWindowsの作業端末にインストールし、Converterの画面を開きます。

最初にでてくるのは、Source System。つまり、「移行元」の情報です。

この段階で、移行元マシンへAgentをプッシュインストールします。

事件は、ここで起きた。

というわけで、問題の画面がこちら！

ﾌｧｰｰｰｰｰｗｗｗｗ

え？ Agentのインストールダメなの？マジで？

Firewallもウィルス対策も入ってない、ガバガバOSなのに？

この1603、対象にagentを入れようとしたとき、対象側でサービス起動に失敗するとよくでます。

なので、対象側のレジストリエディタから、「ServicesPipeTimeout」の値を長い時間に設定して、サービス起動のタイムアウト時間を稼ぎます。

ところが、ここをどんんんんんんんんだけ長くしようが、1603のエラーがでます。

つまり、サービスタイムアウトが問題じゃないっぽい。

なお、Converterをインストールしたマシンのインストールフォルダ内には、Agentのexeファイルがあります。

こちらを対象マシン側にダイレクトに送り込んで、インストールすることもできます。

ところがぎっちょん！！！

やはり、Starting servicesでエラーがでますねー。

 

まぁ結論から言うとね、

その後も、あれやこれやと試してみましたが、結論だけ言うとConverterのバージョンを、6.2.0.1→6.0にダウングレードしたことで、移行は成功しました。

6.0は、2003 R2が対応している最後のバージョンです。

↑ 一番上！Completedになってるでしょ？

蓋を開けてみれば簡単なことなのですが、現在VMwareが提供しているのは、「6.2.0.1」のみ…6.0が手に入らないことが最大のネックじゃね？と思います。

(私は、家の検証環境にたまたま残ってました)

どうせ最新版の6.2.0.1でもVMCはNot Supportなので、それが6.0になったところで、「で？」って感じでなので、試したところ、うまくいきました。

ちなみに6.0で試したとき、ちょっとだけ妙なエラーがでました。

なんやのこれ(´・ω・`)？

このエラーはCommunityとかで情報を漁ってると、Agent再インストール+OS再起動でうまくいくぜ！って書いてあったので、その通りにしたところ、解消しました。

6.2.0.1で検証していた時にAgentを入れようとして失敗しまくってたので、何かしらゴミが残っていたのかもしれません。

2003以降、Agentをアンインストールしても再起動は要求されなかったはずですが、念のため再起動しておくことをオススメします。

最後に。

というわけで、今回は得意とか嘯いておきながら、見事にConverterに逆襲されてしまったヘッポコSEのお話しでした。

この当時、SDDCはversion 1.12を使っていましたが、最新だとどうなるかはわかりません。

口酸っぱく言いますが、Not Support構成でございますので、このブログを読んでいる良い子も悪い子も、やるときは自己責任でお願いしますね☆彡

とりあえず、今回のわかったことは、

・Legacy OSに対するConverterの動作と互換性は結構シビアだよ！

・でもホストに対するConverterの動作と互換性はシビアじゃないよ！

ってことでした。

なので、どうしてもConverter使う場合は、「ゲストOSの互換性」を主体でConverterのバージョンを決めた方がよさそうです。

ではでは～