Kubernetes は、ステートレスなアプリケーションだけでなく、データベースをはじめとするステートフルなアプリケーションの実行基盤としても広く採用されています。一方で、全てのアプリケーションをコンテナ・アプリケーションに変換できるわけではありません。仮想マシン（VM）での継続運用が必要な場合には、Kubernetes 環境と VM 環境の両方を管理しなければならないという課題が生じます。
この課題を解決するのが、KubeVirt です。KubeVirt は Kubernetes 上で VM を稼働させる技術で、商用サービスでは Red Hat OpenShift Virtualization や SUSE Virtualization などがあります。
しかし、KubeVirt が従来の VM インフラと同等の機能を備えているとは限らず、結局、既存の VM インフラを併用し続けている企業があるのではないでしょうか。
このような課題の解決策として、Portworx Enterprise と KubeVirt を組み合わせる方法があります。この方法により、従来の VM インフラと同等の機能を実現できます。本記事では、コンテナと VM を 1 つの環境で安全かつ効率的に運用するための具体的なポイントを解説します。
なお、Portworx Enterprise の機能に関しては、「コンテナ時代のデータ基盤を支える Portworx 入門」をご参照ください。
2026.05.08 投稿者：戸田 貴夫
Portworx は、Kubernetes 向けのデータ基盤です。コンテナや KubeVirt などのモダンな仮想化向けに、ストレージ、データ保護、DR、バックアップを統合的に提供し、コンテナ時代に最適なデータ管理を実現します。
ストレージ + CSI と Portworx の違い
「PX-Store (2/3)：FlashArray または FlashBlade との連携と優位性」でもご紹介したとおり、通常では、CSI ドライバ経由でストレージをプロビジョニングすると、ボリュームが物理ストレージ上に作成されます。そのボリュームが PV と紐づき、さらに PV と PVC が紐づいて Pod で利用されます。
この場合、物理ストレージ上には VM ごとに個別のボリュームが作成され、それぞれのボリュームにはランダムな名前が付与されます。ストレージ管理者にとっては「どのボリュームがどの VM に対応しているのか」が判別しづらいという状況が生じます。
一方、Portworx Enterprise のソフトウェア定義のストレージ（SDS）の機能を利用することで、従来の VM インフラのようにストレージをプールする環境を構築できます。ボリュームは、物理ストレージではなく Portworx Enterprise 上で管理されるため、物理ストレージ上にランダムな名前のボリュームが複数作成されることはありません。
PX-Store (2/3)：FlashArray または FlashBlade との連携と優位性
2026.06.23 投稿者：鈴木 宏征
Portworx Enterprise の機能である PX-Store と FlashArray、FlashBlade との連携や、「従来型ストレージ ＋ CSI」構成との違いに焦点を当て、PX-Store の優位性について詳しくご紹介します。
仮想マシンのサービス継続性
ライブ・マイグレーション
従来の VM インフラでは、電源 ON の VM をハイパーバイザーのノード間で移動させるライブ・マイグレーション機能があり、ノードのリソース状況にあわせて VM を移動させるのが一般的な方法でした。KubeVirt 環境にもライブ・マイグレーション機能は存在します。しかし、それを実行するにはストレージ側が RWX（ReadWriteMany）に対応している必要があります。
Portworx Enterprise では、SDS 機能で作成されるブロック・ボリュームや、CSI ドライバ経由で FlashArray 上に作成されたブロック・ボリュームが RWX に対応しています。
ノード障害に対する仮想マシンの可用性
KubeVirt 環境においてノード障害が発生した場合に、VM は他のノードで再起動します。
しかし、VM が使用するストレージが CSI ドライバ経由で物理ストレージ上に作成されたボリュームの場合は、異なるノードに対してボリュームの再接続が発生し、その後、virt-launcher Pod に公開され、Pod 内の QEMU が VM の仮想ディスクとして利用します。ノードへの再接続から Pod への公開となるため、VM の再起動まで多くの時間を要します。
それに対して Portworx Enterprise では、PVC ごとに物理ストレージのボリュームを作成するのではなく、事前にノードに対して物理ストレージのボリュームを接続し、ストレージ・プールを構成します。PVC の要求に対して作成されるボリュームは、物理ストレージ上ではなく、Portworx Enterprise のストレージ・プールに作成されます。そのため、ノード障害が発生しても、他のノードは既に物理ストレージのボリュームと接続状態を維持しています。また、Portworx Enterprise で作成するボリュームは、レプリカ機能で保護することができます。レプリカ・ボリュームは、元のボリュームとは異なるノードに配置されます。レプリカ・ボリュームを virt-launcher Pod に再公開することにより、ボリューム利用までの時間が短縮され、VM の迅速な復旧が可能になります。
サイト障害に対する仮想マシンの保護
「Portworx のデータ保護機能：Kubernetes 環境のデータを止めずに守る」では、ネームスペース単位で DR（ディザスタ・リカバリ）が設定できることをご紹介しました。
Portworx のデータ保護機能：Kubernetes 環境のデータを止めずに守る
2026.08.04 投稿者：安部 諒
Portworx Enterprise のデータ保護機能であるスナップショットと同期／非同期レプリケーションによるディザスタ・リカバリをご紹介します。Kubernetes 環境におけるデータ損失のリスクを低減し、障害時の迅速な復旧を実現する方法を解説します。
KubeVirt 環境では、ネームスペース単位だけでなく、VM 単位で DR を設定し、サイト障害から復旧することができます。
PX-Backup による仮想マシンのバックアップ
「Portworx Backup：Kubernetes のバックアップ／リストアを一元化」でご紹介した PX-Backup を用いて VM のバックアップをスケジュール化することで、障害発生後に他の Kubernetes クラスタにリストアするよう設定できます。
Portworx Backup：Kubernetes のバックアップ／リストアを一元化
2026.08.18 投稿者：安部 諒
Portworx Backup は、ストレージ内のデータと Kubernetes リソースをまとめてバックアップ／リストアし、コンテナや VM が混在する Kubernetes 環境の運用をシンプルにします。
通常のコンテナ・アプリケーションでは、ネームスペース単位でのバックアップ／リストアに対応しています。一方、KubeVirt 環境では、ネームスペース単位に加えて、 VM 単位でのバックアップ／リストアにも対応しています。
ストレージ・リソースの最適化
VM 環境では、OS 領域などの同タイプのデータがストレージ上に複数保存されます。このような環境では、オンプレミスの FlashArray やパブリック・クラウドの Everpure Cloud Dedicated と連携することで、重複排除と圧縮機能により保存データが削減され、ストレージ・コストが大幅に低減します。
仮想マシン環境に最適化された SDS 機能
Portworx Enterprise では、VM 環境に最適化された SDS 機能として Kube Datastore をリリースしました。その第 1 弾の機能が、Dynamic Pool です。
Dynamic Pool の前に、まずはこれまでの Portworx における Pool について説明します。
Kubernetes クラスタに Portworx Enterprise をインストールすると、Storage Cluster が構成されます。Storage Cluster は、Portworx Enterprise のデータ領域を構成するクラスタです。
Storage Cluster が構成されると、各ノードに接続されている同じ種類、同じ容量のドライブやブロック・ボリュームをまとめた Local Pool が構成されます。Portworx Enterprise のボリュームは、Local Pool に作成され、このボリュームが PV と紐づきます。
レプリカ・ボリュームは、異なるノードの Local Pool に作成され、可用性を担保します。先述のとおり、ノード障害時には、このレプリカ・ボリュームが使用されます。
レプリカ・ボリュームで可用性を担保するため、VM からの書き込みは必ずレプリカ・ボリュームまで書き込んでから応答（ACK）が返されます。そのため、必ずしも I/O に最適化された構成とはいえませんでした。
これに対し、Dynamic Pool では、バックエンド・ストレージに FlashArray を用いて可用性をオフロードすることで、レプリカ・ボリュームを作成しない構成でも可用性を担保できるようになりました。
ノード障害時はレプリカ・ボリュームを使用するのではなく、Local Pool を異なるノードに移動させ、VM にボリュームを公開して復旧します。
なお、Dynamic Pool は 2026 年 9 月現在、OpenShift Virtualization と FlashArray の組み合わせにおいて利用可能な機能です。
まとめ
従来の KubeVirt 環境では機能的な課題があり、他のハイパーバイザーと併用せざるを得ないケースが多かったのではないでしょうか。Portworx Enterprise を組み合わせることで、コンテナ環境と VM 環境を分離することなく、1 つの環境での運用が可能になります。さらに、Kube Datastore の今後の進化により、既存の VM 環境と変わらない運用の実現が期待されます。
Everpure、Everpure のロゴ、「P」のロゴ、Pure Storage および、Everpure の商標リストに記載されているマークは、米国およびその他の国における Everpure, Inc. またはその子会社の商標または登録商標です。その他記載の全ての名称は、それぞれの権利者に帰属します。
