1 ポイント 投稿者 GN⁺ 2025-10-21 | 1件のコメント | WhatsAppで共有
  • 多くの企業が VMwareの高額なライセンス費用 と最近の変化を受けて、代替策を模索している
  • 複数の中小規模のITチームは、Proxmox VEoVirt のような オープンソース仮想化ソリューション への移行を検討している
  • KVM、Xen、Hyper-V など ほかのハイパーバイザー への マイグレーション を考える事例が多い
  • 実際の移行では、データ移行の方法既存ワークフローとの互換性 の問題に悩んでいる
  • コミュニティでは、大規模インフラ移行時のコスト/性能分析実行戦略 に関する議論が活発に行われている

VMware代替を模索する背景

  • 多くの企業が最近の VMwareのライセンス方針変更 と増大するコスト負担に直面している
  • これに伴い、既存のVMwareインフラを置き換えられるソリューションを検討する動きが加速している

主な代替仮想化プラットフォーム

  • Proxmox VE: Webベースの管理のしやすさと活発なコミュニティ支援により、多くの小規模・中堅組織で検討されているオープンソースの仮想化ソリューション
  • oVirt: Red Hatベースのエンタープライズ仮想化ソリューションで、KVMを基盤とし、拡張性と自動化機能を備えている
  • Xen: 長年にわたり安定性と性能が実証されてきたオープンソースのハイパーバイザーで、主要な商用サポート企業も存在する
  • Hyper-V: Microsoftのソリューションであり、Microsoftインフラとの親和性が高く、Windows環境に適している

マイグレーションの課題と議論

  • 実際の移行プロセスでは、既存VMデータの移行ネットワークおよびストレージの互換性自動化スクリプトの書き直し など、現実的な課題に直面している
  • ベンチマーク、テスト移行、小規模なパイロットプロジェクトなどによって検証手順を踏むケースがほとんどである

コミュニティと専門家の意見

  • 多くのユーザーは、段階的に 一部のサービスから移行するアプローチを好んでいる
  • 性能、安定性、拡張性の観点から、各ソリューションの特徴的な長所と短所に関する多様な経験と助言が共有されている

結論と戦略的アプローチ

  • VMware依存を減らすための さまざまな代替ソリューション が実際に活用されている
  • 組織のインフラ規模や複雑さ、予算、IT能力に応じた、カスタマイズされた移行戦略の必要性が強調されている

1件のコメント

 
GN⁺ 2025-10-21
Hacker Newsの意見
  • 私の所属機関では VMware の5年 ELA が150万ドルから1,200万ドルへと急騰した。私は高等教育分野で働いている。
    数か月前に Hyper-V 環境を構築済みで、Microsoft ELA にすでに含まれていたため、より高水準のサポートに予算を回せた。
    genAI stuff だけを担当する別チームがある。
    約3週間前に VM の移行を始め、3,500台のうち約500台を移した。
    研究支援事業向けの HPC 環境はベアメタルへ移行中で、VM の移行は一時的な HPC と一般インフラ向けである。
    SAP Hana など一部の大規模アプリケーションサーバーは、SAP が Hyper-V をサポートしないなら VMware に残るかもしれない。
    この夏は本当に大変だったが、最終的にはうまくやり遂げた。

    • Broadcom の VMware 戦略を要約する引用として、これがあると思う。
      「Global 2000 企業なら VMware はあなたのビジネスを欲しがる。そうでなければ特に関心はない」
      関連記事
  • 私の周囲の SME の友人たちの間では、この話題がかなり熱い。
    スウェーデンのローカル事情で見ると、主要ベンダーは HPE と Nutanix だ。
    HPE が複数のハイパーバイザーバックエンドをサポートしつつ独自フロントエンドを載せたのは、天才的な判断だと思う。これが今後進むべき唯一の道だ。
    今の職場では Proxmox を使っており、非常に満足している。
    VMware の経験がある立場からすると、大半の企業は Proxmox に容易に置き換えられると思う。
    Proxmox はエンタープライズ SLA がないため導入が遅れている。コストがいくらであれ、エンタープライズ契約さえあればよい。
    個人的には KubeVirt や Openshift+KubeVirt がもっと広がってほしい。すでに広く使われている kubernetes API にハイパーバイザーランタイムを組み合わせるのは、実に見事だと感じる。

    • Proxmox がこの好機を逃しそうで心配している。
      VMware を置き換える絶好のポジションにいたのに、会社の規模が小さく保守的で、世界的に広がる野心があるようには見えない。

    • Proxmox のプレミアム契約内容:
      エンタープライズリポジトリへのアクセス、全機能セット、カスタマーポータル経由のサポート、無制限サポートチケット、2時間以内の応答、リモート SSH サポート、オフラインでのサブスクリプションキー有効化が提供される。

    • SAN と ISCSI をサポートしていないのが本当に残念だ。
      こういう方式の構成が好きなので、使い続けたかった。

    • ベアメタルの Openshift への移行を提案したが、機能不足の問題で反発があった。
      結局 hpe に行くことになった。

    • Openshift+KubeVirt は参入するには本当に良い位置にいると思う。
      私が働いてきた複数の分野では Openshift の利用が多いので、自然な拡張だ。
      MSFT の Hyper-V バンドル力を見落としていたが、このスレッドでは頻繁に言及されている。

  • Broadcom が値上げしすぎたので proxmox へ移行中だ。
    IT チームの何人かが自宅で proxmox を使った経験があり、Broadcom の VMWare 維持コストが移行中断リスクをはるかに上回った時点で、ためらいなく切り替えを決めた。
    ファームの一部を移して A/B テストし、結果も良好だったので、次の Broadcom への支払い前に全面移行を完了できそうだ。
    Broadcom のおかげで決断を早めることができた。
    個人的に Broadcom と Oracle は「絶対に自発的には取引しない企業」のツートップだ。Oracle と同格に並んだ Broadcom はある意味すごい。

    • 私は Broadcom を Oracle より一段悪いと見ている。
      Oracle は少なくとも金を払う顧客は欲しがるが、Broadcom は顧客そのものに関心がないように見える。
  • MSP として働いており、主に中小企業のクライアントを担当している。
    Broadcom の VMware 買収後、ライセンス費用は非常に大きく上がり、今年はコア数の最低要件のせいで年2万ドルに達した。今後さらに上がるかもしれない。
    既存の永続ライセンスなら、管理 VLAN をインターネットから分離して使えば数年は持ちこたえられるが、パッチが当てられないため、いずれ内部監査で問題になる。
    更新型ライセンスは期限切れになると VM の電源すら入れられず、再起動すると停止したままになる。
    全体の半分は Hyper-V に移しており、多くはすでに Windows サーバーを使っている。
    違いはいくつかあるが、Hyper-V は必要な機能をすべて提供し、ライセンスもすでに含まれている。
    Veeam が VM 間の移行を簡単にしてくれるので、顧客はバックアップ用途で多く使っている。
    かなりの数が Azure や他のホスティング環境へ移行しており、本社のファイルサーバーのような主要 LOB がなければ簡単に移せる。
    一部は nutanix へ切り替え、または拡張している。

    • 私たちの組織でも18か月ほど前に IDC の4分の1を nutanix に移したが、今は nutanix から離れつつある。
      サーバー/開発者の立場では、奇妙な VM の挙動や期待以下の性能など、さまざまな不安定さに悩まされ、他のシステムオーナーも同様の問題を抱えていた。
      短期間のうちに何か決定的な変化があり、その結果移行することになった。
  • upstream Linux がサポートしているのは libvirtd ベースのスタックなので、こちらも確認する価値がある。
    認証要件のために proxmox を UI としてだけ使っているところもあり、私の顧客では cockpit dashboard や kubernetes に移った例も多い。
    規模やプロビジョニング要件によって変わる。
    cockpit は設定が簡単なので一番のお気に入りだが、クラスター規模には向かず、Web UI と複数の cockpit server デーモンを別途セットアップする面倒さがある。
    Proxmox は古く Perl ベースだが、十分実用的だ。ストレージクラスタリングは ceph のようなファイルシステム層が必要で、そこは少し苦労する。
    Openshift もあるが、IBM/RedHat への依存を懸念して中小規模企業は敬遠している。
    cockpit, proxmox, cockpit machines の説明

    • cockpit の SSH/マルチマシン機能がまもなくサポート終了予定なのが残念だ。
  • ブロックストレージベンダーとして働いており、VMware から移行するさまざまな KVM ベースのクラウド管理プラットフォームを目にしている。
    顧客は OpenNebula、CloudStack、Proxmox、OpenStack、HP VME、Oracle Virtualization、さらには自前構築のソリューションへと移っている。
    主な共通点は、特定のハイパーバイザーに縛られず、予測可能な高性能を提供できるストレージバックエンドに注力していることだ。
    KVM エコシステムの利点は、作業に最適なツールを自由に選べ、その自由がストレージ層まで広がることにある。
    優れたソフトウェア定義ブロックストレージソリューションであれば、データ移行や災害復旧などの機能によって VMware からの移行を円滑に進められる。

    • 2020年代に Openstack が再び注目されるとは思わなかった。
      KVM ソリューションは確実に勢いを得ている。
  • 最も得をしているのは Microsoft のように見える。
    企業はクローズドソースのソフトウェアで痛い目を見たのに、同じ道を繰り返していて悲しい。
    Nutanix も需要が急増している。
    Proxmox や Xcp-ng のような代替策も記録的な導入ペースを見せていて、その点は救いだ。
    私は Apache CloudStack プロジェクトの一員だが、このサービスも前例のない需要増を経験している。
    KVM ハイパーバイザーが事実上の標準になっており、virt-v2v ツールのおかげで vmware ゲストの移行も容易になった。

    • 現在はクラウド VM の方が Broadcom のライセンス費用より安いことすらあり、VMware から Azure や AWS への大量移行を見ている。
  • 以前いた PriorCo で、2023/2024 年のこの時点に選択肢をスライドに整理して提示した。
    VMware 残留、Apache Cloudstack への移行、Nutanix への移行という3つの道を提案したが、最終的には残りのインフラを AWS へ移すリフトアンドシフトに決まった。
    私が責任者なら Cloudstack の方が適していたと思う。私たちにはその能力があり、ベンダーロックインから抜け出せたはずだ。
    Nutanix は技術ポートフォリオだけを見て候補に入れたが、収益性や財務構造、SaaS への集中などから、結局 VMware と同じ問題に陥る懸念があった。
    KVM/QEMU や OpenStack ベースのさまざまな選択肢があり、Virtuozzo も印象的だったが、統合パッケージとしては物足りなかった。
    Oxide はシンプルさと統合性が魅力だったが、新興スタートアップ製品への社内需要が不足していた。
    Microsoft と Oracle はコストとライセンス負担が重すぎて除外し、IBM/Openshift はプライベートクラウドの100%が VM で、製品全体の約20%しかコンテナ化できないため除外した。
    最も重要な助言は、現在のワークロードの特性を正確に理解し、それに合った選択肢を選ぶことだ。
    誰もが K8s とコンテナを強調するが、大半が VM の環境では、そうした選択肢はあまり意味がない。

    • なぜ Proxmox を検討しなかったのか気になる。
  • <i>"VMware's in court again. Customer relationships rarely go this wrong"</i>(190コメント、2025年)
    関連リンク
    <i>"Proxmox VE: Import Wizard for Migrating VMware ESXi VMs"</i>(100コメント、2024年)
    関連リンク

  • 主に企業の IT チームに対して、代替ツールやワークフローを認めるよう強く求めている。
    実際、これが最大の障害だ。
    私たちのチームには十分な DevOps の能力があり、コンテナ化や開発環境のパッケージ化も可能だが、企業のセキュリティチームは議論の要請に対して「ポリシー違反」と繰り返すだけだ。
    この経験は一社だけでなく、高度なエンジニアリング/ソフトウェア企業をいくつも経験しても同じだった。

    • 私もまったく同じ状況で、本当にうんざりしている。
      サイバーセキュリティチームがすべてを握っているのに、DevOps やプロセス管理への関心も専門性もほとんどない。
      結局、話し合おうとしても人間のファイアウォールに阻まれ、返ってくるのはいつも「だめだ」だけだ。
      なぜ組織として改善できないのか、皆が不思議に思っている。

    • サードパーティの信頼性の問題は冗談ではない。
      誰が自分の仕事を止めて、新しい中核ベンダーを監査しようとするだろうか。

    • 私たちのチームも DevOps スキルによって、コンテナ化や開発環境のパッケージ化まで実現できる。
      私の職場では Kubernetes なしでコンテナに全面的に振り切ったが、結果は非常に良かった。
      こうしたアプローチへの抵抗は本当に残念で、最終的にうまく進むことを願っている。