BroadcomがVDDKダウンロードを停止、VMware離脱がさらに困難に

私はHyper-VからVMwareへの移行プロジェクトをリードできたから今の仕事を得た。そしてちょうど今年、VMwareからHyper-Vへの移行プロジェクトをリードした。VMwareは本当に素晴らしい製品だった（管理していたVCF環境では少し扱いにくかったが）。Broadcomの傘下に入ってしまったのは本当に残念だ。それに比べてHyper-Vは典型的なMicrosoft製品のように感じる。異なるチームによって作られた、後付けでくっつけたような感じのさまざまなツールがタスクを実行するためにある。FCMを実行してノードを管理しなければならない？でもロールを管理するにはHVMを実行する？でもVMware vSphereやProxmoxがネイティブに提供するような全体的なリソース管理はない？

私は、避けられないWindowsホストの問題に備えて、セミプロダクションのワークロード用にProxmoxクラスターをこっそり環境に構築している。

TFAから

> VMwareからProxmoxへの移行は影響を受けない...

面白いことに（そして、エンタープライズに比べてホームラボの規模が小さく、自動化の要件も控えめであることを認めつつ）、私が1、2年前にProxmoxへの移行を始めたとき、ESXiサーバーからProxmoxへVMを移動するプロセスは驚くほど簡単だった。実質的にESXiをストレージシステムとしてマウントし、'ここにコピー'するだけだ。

覚えている限り、唯一の小さな課題は、ターゲットVMのCPUタイプの保守的な選択（Proxmoxはデフォルトの'host' CPUを嫌うようだ）と、ネットワーク/SCSIコントローラのデフォルトだった。堅牢性をパフォーマンスより優先するように設計されているのだと思う。

すべて自動化可能だと思う。

つまり、Linuxのqemu-imgツールは、VMディスクイメージを.vmdkから他のすべてのハイパーバイザーと互換性のある形式に変換できる。VMwareからのVM移行プロセスには、このツールを使うこと（そして新しいハイパーバイザーで適切な仮想ハードウェアプロファイルを手動で作成すること）以外に何かあるのだろうか？

明らかに、サポートされる仮想ハードウェアの種類はハイパーバイザーの種類によって異なるが、それは通常別途対処できるものだ。

私はこれらの顧客にはほとんど同情しない。もしかしたら、単に知識がなく専門知識もない中小企業は別かもしれないが、私がいたすべての会社やクライアントで、中核インフラをプロプライエタリなコンポーネントで不必要に構築しないように上司を説得しようとする人が少なくとも1、2人はいた。しかし、ほとんどの場合、彼らは無視されていたし、今も無視されている。

確かに、他の環境で動作しないことが証明されているレガシーなWindows専用ソフトウェアがあるなら、運が悪いし、手が縛られているかもしれない。しかし、私がこの遅くて醜くて自動化しにくい混乱から解放したすべてのVMwareショップは、そのために高い代償を払わなければならなかった。

これらの人々は、あと何回 rug pull されればいいのだろう？ああ、そうだ、彼らはおそらくAzure移行の途中だろう。

痛みを通して学ぶ必要がある人もいる。

Avago（Broadcom）が廃業した後に配布できるように、誰かVMwareのソースコードを外部に持ち出せないだろうか？

私の友人が言うには、VMwareはその周りに構築されたエコシステムのおかげで、今でも最高のVMプラットフォームだそうだ。だから、後の復活のために保存できればいいのに。

時間は速く進むことは分かっているが、完全に失うのは残念だ。

これが犯罪を助長することだと分かっているが、これが犯罪と見なされるなら社会は何かおかしい。

免責事項：しないで（ヒーローにならないで）

VMwareを離れるのが難しくなった？何だって？違う！まだそこに留まっているなら、あなたが失敗したことがより明らかになっただけだ。（元VMware社員 #10/11 -- 数え切れない。初代PMディレクター）

私は大規模なAzure Local移行の最中で、VDDKが利用できなくなっていることに気づいた... ちょっと面白いのは、ちょうど同僚に、彼らがそれを提供していることに驚いていると話していたところだったからだ。ありがたいことに自分のコピーは保存してあるが、Microsoftが今後Azure Migrateでこれをどう処理するつもりなのか全く分からない。SUSEも同じ問題を抱えていると思う。