vSphere Datastore Cluster Support Fails with "spec.host" Error When Using Multiple Compute Clusters
メンテナーはふだん 1 日以内に返信
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 42/100
- issue の種類
- バグ
- 明瞭さ
- 説明が足りない
- 活発さ
- 静か
- 技術スタック
- go
- 領域
- cloud, infrastructure
調査の方向性
ソースファイルやテストは指定されていません。まず、datastore cluster と複数の compute cluster を使用した VM プロビジョニングを再現し、次に machine-controller のリクエストを、spec.host エラーが発生する vCenter のストレージ配置推奨まで追跡します。datastore-cluster のプロビジョニングが、個別の datastore パスを必要とせずに成功すれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Issue
Customers attempting to provision VMs using vSphere datastore clusters encounter provisioning failures. When a MachineDeployment is configured to use a datastore cluster instead of a specific datastore path, machine-controller cannot successfully create virtual machines. The error message displayed is: failed to resolve datastore: error occurred while getting storage placement recommendation: ServerFaultCode: A specified parameter was not correct: spec.host. This occurs regardless of whether the vSphere compute cluster is correctly specified in the configuration. The issue manifests when customers try to leverage Storage DRS capabilities by using datastore clusters for automated storage placement, but machine-controller is unable to complete the storage placement request to vCenter. Even after ensuring all required fields like cluster are properly configured, VM provisioning continues to fail when datastore clusters are used, forcing customers to fall back to specifying individual datastore paths as a workaround.
Impact to the Customer
This bug blocks customers from using vSphere datastore clusters, which is a key feature for managing storage in production environments. Instead of letting vSphere automatically choose the best datastore from a cluster, customers have to manually specify exact datastore paths. This means they lose the benefits of automated storage management, like automatic load balancing and the ability to add or remove datastores without changing their configurations. The workaround of using specific datastore paths is tedious and defeats the whole purpose of having datastore clusters in the first place. For customers running multiple vSphere clusters, this becomes even more painful as they have to manually keep track of different datastore paths across all their clusters, making it hard to scale and maintain. It also makes disaster recovery and capacity planning more difficult since they can't rely on vSphere to automatically allocate storage based on what's available.
KKP version
v2.28
- 主要言語
- Go
- スター
- 325
- フォーク
- 140
- 平均マージ
- 4時間 3分
- マージ済み PR（30日）
- 13
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
kubermatic/machine-controller のほかの issue
-
Align kubebuilder markers with shipped CRDs対応中かも @KhizerRehan が 33 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
kubermatic/machine-controller#2091 ·
メンテナーはふだん 1 日以内に返信
-
customer-request kind/feature
難易度 5/5 1週間以上 初心者へのやさしさ 12/100
kubermatic/machine-controller#2104 ·
メンテナーはふだん 1 日以内に返信
-
customer-request
難易度 4/5 3〜5日 初心者へのやさしさ 25/100
kubermatic/machine-controller#2103 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
kubermatic/machine-controller#2080 ·
メンテナーはふだん 1 日以内に返信
-
Bump Azure SDKオープン
難易度 4/5 3〜5日 初心者へのやさしさ 52/100
kubermatic/machine-controller#2066 ·
メンテナーはふだん 1 日以内に返信
kubermatic/machine-controller の issue をすべて見る
似ている issue
-
VLAgent `spec.k8sCollector.includePodLabels: false` has no effect対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
VictoriaMetrics/operator#2772 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
Gaurav-Gosain/tuios#1316 ·
メンテナーはふだん 1 日以内に返信
-
needs: investigation
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
area:auth documentation priority:low
難易度 1/5 1〜3時間 初心者へのやさしさ 86/100
メンテナーはふだん 1 日以内に返信
-
Mend: dependency security vulnerability
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
kube-tarian/sigrun#203 ·