Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

vSphere クラスタをドメインに追加する

このドキュメントでは、Compute Engine ベアメタルインスタンスを使用して、 Google Cloud の VMware ソリューションの既存の VMware Cloud Foundation（VCF）9.1 ドメインに vSphere クラスタを追加する方法について説明します。単一のクラスタを超えてコンピューティングと vSAN ストレージ容量をスケーリングする必要がある場合、ワークロードを分離する必要がある場合、既存のドメイン内で個別の vSphere Lifecycle Manager（vLCM）イメージまたは vSAN ストレージポリシーを適用する必要がある場合は、クラスタを追加します。クラスタは、同じプロジェクト、Virtual Private Cloud（VPC）ネットワーク、ゾーン内の次のいずれかのドメインに追加できます。

管理ドメイン: 管理 vCenter Server と NSX Manager によって管理されるクラスタを追加します。
VI ワークロードドメイン: ワークロードドメイン vCenter Server とその NSX Manager インスタンスによって管理されるクラスタを追加します。

アーキテクチャの概要

既存の VCF ドメインに vSphere クラスタを追加すると、デプロイでは次のアーキテクチャが使用されます。

ベアメタル ESXi ホスト: 新しい ESXi ホストは、VPC ネットワークの既存のレイヤ 2 サブネット（ESXi 管理、vMotion、vSAN、NSX トンネルエンドポイント（TEP））に接続された z3-highmem-192-highlssd-metal ベアメタルインスタンスです。各ホストは、プライマリネットワークインターフェース（nic0）と VLAN のタグ付け付き Dynamic Network Interface を介して接続します。
追加の管理アプライアンスなし: ターゲットドメインをすでに管理している vCenter Server と NSX Manager にクラスタを追加するため、新しい管理アプライアンスをデプロイする必要はありません。また、新しいアプライアンスの Cloud DNS レコード、バックエンドサービス、高可用性（HA）ポリシー、転送ルールも作成しません。代わりに、新しいホストを既存のゾーンネットワークエンドポイントグループ（NEG）に追加します。
IP アドレスの割り当てと調整: VCF はネットワークプールから vMotion と vSAN の IP アドレスを割り当て、NSX は NSX IP アドレスプールから TEP（vmk10）IP アドレスを割り当てます。どちらのプールも VCF 9.1 でホストごとの静的割り当てをサポートしていないため、デプロイ中に Compute Engine Dynamic NIC を VCF で割り当てられた IP アドレスに合わせ、すべての VCF 検証を有効のままにします。

始める前に

クラスタを作成する前に、次のセクションの要件を確認し、環境変数を構成します。

環境要件を確認する

環境が次の要件を満たしていることを確認します。

権限: ターゲットプロジェクトに必要な Identity and Access Management（IAM）ロール（Compute 管理者（roles/compute.admin）、DNS 管理者（roles/dns.admin）、Secret Manager のシークレットアクセサー（roles/secretmanager.secretAccessor）など）が付与されている。
Secret Manager の認証情報: 初期デプロイ後に VCF で ESXi root、SDDC Manager、vCenter Server、NSX Manager のパスワードを変更またはローテーションした場合、Secret Manager は自動的に更新されません。このドキュメントのコマンドを実行する前に、Secret Manager で対応するシークレットを更新するか、更新されたパスワードを直接指定して、有効な VCF 認証情報と一致するようにします。
ドメインの健全性: ターゲットドメインが正常（vCenter Server、vSAN、NSX Manager、SDDC Manager、VCF Operations）で、失敗したタスクがない。
vSphere Lifecycle Manager（vLCM）イメージ: vLCM イメージが VCF イメージライブラリで使用可能であるか、ホストからイメージを抽出する予定がある。すべてのホストが整合性を保つように、既存のクラスタで使用されているものと同じイメージを使用します。
ストレージデバイス: 各新しいホストには、vSAN に必要な、既存のパーティションのない NVMe ローカル SSD デバイスがあります。
最小ノード数: クラスタには少なくとも 3 つのベアメタルノードが必要です。これは、1 つの障害を許容する vSAN に必要な最小数です（FTT=1）。
マシンタイプ: クラスタ内のすべてのノードで同じマシンタイプ（vSAN Express Storage Architecture（ESA）の場合は z3-highmem-192-highlssd-metal）が使用されます。
ゾーン: 新しいクラスタは、既存の管理および NSX TEP ゾーン NEG と同じゾーンにあります。
ジャンプボックス VM: gcloud CLI、curl、jq がインストールされ、VPC ネットワーク（bm-gcp-demo サブネットなど）へのネットワーク接続があるジャンプボックス VM にアクセスできます。
信頼できるイメージのポリシーと VPC Service Controls: 組織で constraints/compute.trustedImageProjects 組織ポリシーが適用されている場合、または VPC Service Controls サービス境界を使用している場合は、プロジェクトで smve-prod-public-images プロジェクト（projects/999037279871）へのイメージアクセスが許可されていることを確認します。詳細については、ノード容量を管理するをご覧ください。
VLAN ベースのネットワーキング: VMware ソリューションでは、VLAN ベースのネットワーキングをサポートするために、VPC ネットワークのサブネットの [サブネットマスクの解決] プロパティを [学習を伴うブロードキャストプライマリ範囲のみ] に設定する必要があります。Google Cloud コンソールのサポートセンターで、次の情報を含むサポートチケットを開きます。
- プロダクト: Google Cloud VMware Engine
- 優先度: P2
- カテゴリ: ネットワーク接続
- ビジネスへの影響: 技術に関する一般的な質問
- 詳細情報を提供する: Allowlist L2 network connectivity for my project、プロジェクト ID、プロジェクト番号、デプロイのターゲットリージョンとゾーン
VLAN ベースのネットワーキングのサポートの詳細については、レイヤ 2 エミュレーション: ARP ブロードキャストとカスタム MAC ラーニングをご覧ください。

環境パラメータの例を確認する

このドキュメントのコマンドでは、次のサンプルパラメータを使用します。

入力パラメータ	値の例	説明
プロジェクト ID	`PROJECT_ID`	ターゲットドメインと同じ Google Cloud プロジェクト
リージョンとゾーン	`us-east4`/`us-east4-b`	既存のゾーン NEG と同じゾーン
お客様 ID	`demo`	既存のリソース名で使用されている識別子
ターゲットドメイン	`mgmt-domain`（または `wld01`）	既存の管理ドメインまたは VI ワークロードドメイン
クラスタ名	`cl02`	新しい vSphere クラスタの名前
マシンタイプ	`z3-highmem-192-highlssd-metal`	クラスタ内のすべてのノードに同じマシンタイプを使用する
ノード数	`3`	vSAN の最小ノード数 `FTT=1`
VPC ネットワーク	`bm-demo`	既存の VPC ネットワーク
サブネット（VLAN ID）	`bm-mgmt-demo`（タグなし）、`bm-vmotion-demo`（`2`）、`bm-vsan-demo`（`3`）、`bm-nsx-demo`（`4`）	既存のレイヤ 2 サブネット
ゾーン NEG	`bm-mgmt-demo`、`bm-nsx-tep-demo`	既存の管理 NEG と NSX TEP NEG
ESXi イメージ	ファミリー `astra-vcf-9-1-x`、プロジェクト `smve-prod-offline-depot`	既存のクラスタと同じ ESXi イメージビルド
DNS ドメインとゾーン	`vmware.gve` / `dns-zone-demo`、`rev-dns-zone-demo`	既存の Cloud DNS 正引きおよび逆引きマネージドゾーン
SDDC Manager	`sddcm.vmware.gve`（`192.168.0.3`）	既存の SDDC Manager アプライアンス
ESXi `root` パスワード	`esxi-root-password`	ESXi `root` パスワードを保持する既存の Secret Manager のシークレット

IP アドレスとホスト名を計画する

次の表に、3 つの新しい ESXi ホストの IP アドレス計画の例を示します。

ESXi ホスト	管理 IP（`nic0`）	vMotion（VLAN 2）	vSAN（VLAN 3）	NSX TEP（VLAN 4）
`esxi-h7`	`192.168.0.161`	`192.168.2.21`	`192.168.3.21`	`192.168.4.21`
`esxi-h8`	`192.168.0.162`	`192.168.2.22`	`192.168.3.22`	`192.168.4.22`
`esxi-h9`	`192.168.0.163`	`192.168.2.23`	`192.168.3.23`	`192.168.4.23`

ターゲットドメインを選択する

選択したターゲットドメインによって、新しいクラスタを管理する vCenter Server、NSX Manager、オーバーレイトランスポートゾーンが決まります。

パラメータまたはリソース	管理ドメイン内のクラスタ	VI ワークロードドメイン内のクラスタ
`TARGET_DOMAIN` 変数	`mgmt-domain`	`wld01`
vCenter Server の管理	`vc01.vmware.gve`	`vc02.vmware.gve`
`NSX_MANAGER` 変数	`nsx01.vmware.gve`（管理 NSX）	`nsx05.vmware.gve`（専用 NSX）または `nsx01.vmware.gve`（共有管理 NSX）
`TRANSPORT_ZONE` 変数	`overlay-tz-mgmt-nsxt`	ワークロードドメイン NSX インスタンスのオーバーレイトランスポートゾーン

リージョンの割り当てを確認する

ベアメタルノードをプロビジョニングする、またはクラスタを作成する前に、プロジェクトに十分なリージョンとグローバルの Compute Engine 割り当てがあることを確認します。リージョン内の既存のすべてのクラスタのリソースを次の増分値に追加してから、プロジェクトの割り当てと比較します。

割り当て指標	ベアメタルノードごとに必要なリソース	3 ノードクラスタに必要なリソース
`compute.googleapis.com/cpus_per_vm_family`（`Z3`）	192 vCPU	3 × 192 = 576 vCPU
`compute.googleapis.com/local_ssd_total_storage_per_vm_family`（`Z3`）	72 TB	3 × 72 TB = 216 TB
`compute.googleapis.com/hyperdisk_balanced_total_storage`	128 GB	3 × 128 GB = 384 GB
`compute.googleapis.com/resource_policies`	既存のクラスタにノードを追加する場合は 0	クラスタごとに 1 つのスプレッドプレースメントポリシー
`compute.googleapis.com/regional_backend_services_protocol_forwarding_fast_ha`	新しいアプライアンスなしでノードまたはクラスタを追加する場合は 0	新しい VCF 管理アプライアンス VIP または NSX Edge エンドポイントごとに 1 つ

必要な割り当ての完全なリストと、割り当ての増加を表示またはリクエストする方法については、割り当てと上限をご覧ください。

環境変数を設定する

このガイドのコマンドで使用する次の環境変数をジャンプボックスシェルに設定します。

export PROJECT_ID="PROJECT_ID"
export REGION="us-east4"
export ZONE="us-east4-b"
export CUSTOMER_ID="demo"
export VPC_NETWORK="bm-${CUSTOMER_ID}"
export DOMAIN="vmware.gve"
export DNS_ZONE="dns-zone-${CUSTOMER_ID}"
export REV_DNS_ZONE="rev-dns-zone-${CUSTOMER_ID}"
export MGMT_SUBNET="bm-mgmt-${CUSTOMER_ID}"
export VMOTION_SUBNET="bm-vmotion-${CUSTOMER_ID}"
export VSAN_SUBNET="bm-vsan-${CUSTOMER_ID}"
export TEP_SUBNET="bm-nsx-${CUSTOMER_ID}"
export MGMT_NEG="bm-mgmt-${CUSTOMER_ID}"
export TEP_NEG="bm-nsx-tep-${CUSTOMER_ID}"
export CLUSTER_NAME="cl02"
export PLACEMENT_POLICY="bm-${CLUSTER_NAME}"
export NETWORK_POOL_NAME="${CLUSTER_NAME}-np01"
export TEP_POOL_NAME="${CLUSTER_NAME}-tep-pool"
export VDS_NAME="${CLUSTER_NAME}-vds-01"
export MACHINE_TYPE="z3-highmem-192-highlssd-metal"
export ESXI_IMAGE_FAMILY="astra-vcf-9-1-x"
export ESXI_IMAGE_PROJECT="smve-prod-offline-depot"
export SDDC_MANAGER="sddcm.vmware.gve"            # 192.168.0.3
export VCF_USER="admin@local"
export VCF_PASSWORD="VCF_ADMIN_PASSWORD"
export ESXI_PASSWORD_SECRET="esxi-root-password"  # Secret Manager secret holding the ESXi root password
export MTU=8896                                   # VPC MTU

# Target domain parameters
export TARGET_DOMAIN="mgmt-domain"                # Or wld01
export NSX_MANAGER="nsx01.vmware.gve"             # Or nsx05.vmware.gve for wld01 with a dedicated NSX instance
export TRANSPORT_ZONE="overlay-tz-mgmt-nsxt"      # Overlay transport zone of the target NSX instance

# Ordered host list: name mgmt_ip vmotion_ip vsan_ip tep_ip
CLUSTER_HOSTS=(
  "esxi-h7 192.168.0.161 192.168.2.21 192.168.3.21 192.168.4.21"
  "esxi-h8 192.168.0.162 192.168.2.22 192.168.3.22 192.168.4.22"
  "esxi-h9 192.168.0.163 192.168.2.23 192.168.3.23 192.168.4.23"
)

# TEP pool range matching the new hosts' Compute Engine TEP NIC IPs
export TEP_CIDR="192.168.4.0/24"
export TEP_GATEWAY="192.168.4.1"
export TEP_START="192.168.4.21"
export TEP_END="192.168.4.23"

コマンドを実行する前に、次のように置き換えます。

PROJECT_ID: ターゲット Google Cloudプロジェクトの ID。
VCF_ADMIN_PASSWORD: SDDC Manager 管理者のパスワード。

計画した IP アドレスが、既存の転送ルールまたはインスタンスで使用されていないことを確認します。

gcloud compute forwarding-rules list --project="${PROJECT_ID}" --regions="${REGION}" \
    --format="table(name,IPAddress,subnetwork.basename())"
gcloud compute instances list --project="${PROJECT_ID}" --zones="${ZONE}" \
    --format="table(name,networkInterfaces[].networkIP.list())"

DNS レコードを作成する

管理ドメインをデプロイしたときに、レイヤ 2 サブネット、Cloud DNS 受信転送ポリシー、前方参照と逆引き参照のマネージドゾーンを作成しました。クラスタを追加しても新しいアプライアンスはデプロイされないため、新しい ESXi ホストのフォワード（A）レコードとリバース（PTR）レコードのみを作成する必要があります。

add_dns() {
  local name=$1 ip=$2
  gcloud dns record-sets create "${name}.${DOMAIN}." \
      --rrdatas="${ip}" --type=A --ttl=300 \
      --zone="${DNS_ZONE}" --project="${PROJECT_ID}"
  local rev
  rev=$(echo "${ip}" | awk -F. '{print $4"."$3"."$2"."$1".in-addr.arpa."}')
  gcloud dns record-sets create "${rev}" \
      --rrdatas="${name}.${DOMAIN}." --type=PTR --ttl=300 \
      --zone="${REV_DNS_ZONE}" --project="${PROJECT_ID}"
}

for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST MGMT_IP _ <<< "${entry}"
  add_dns "${HOST}" "${MGMT_IP}"
done

# Verify DNS records
gcloud dns record-sets list --zone="${DNS_ZONE}" --project="${PROJECT_ID}" \
    --filter="name~'esxi-h[7-9]'"

ベアメタルインスタンスを作成する

新しいクラスタ専用のプレースメントポリシーを作成します。次に、プライマリ管理インターフェース（nic0）と、vMotion（VLAN 2）、vSAN（VLAN 3）、NSX TEP（VLAN 4）用の VLAN タグ付き Dynamic NIC を使用して、各ベアメタル ESXi ホストを作成します。

プレースメントポリシーの作成

グループプレースメントポリシーを作成します。

gcloud compute resource-policies create group-placement "${PLACEMENT_POLICY}" \
    --region="${REGION}" \
    --availability-domain-count=6 \
    --collocation=COLLOCATED \
    --project="${PROJECT_ID}"

ブートディスクとベアメタル ESXi インスタンスを作成する

クラスタ内の各ホストに Google Cloud Hyperdisk Balanced ブートディスクとベアメタル ESXi インスタンスを作成します。

i=0
for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST MGMT_IP VMOTION_IP VSAN_IP TEP_IP <<< "${entry}"
  AD=$(( (i % 6) + 1 )); i=$((i + 1))

  # Create boot disk
  gcloud compute disks create "${HOST}" \
      --image-project="${ESXI_IMAGE_PROJECT}" \
      --image-family="${ESXI_IMAGE_FAMILY}" \
      --type=hyperdisk-balanced --interface=NVME --size=128GB \
      --guest-os-features=IDPF \
      --zone="${ZONE}" --project="${PROJECT_ID}"

  # Create bare-metal ESXi host
  gcloud compute instances create "${HOST}" \
      --zone="${ZONE}" \
      --machine-type="${MACHINE_TYPE}" \
      --can-ip-forward \
      --resource-policies="${PLACEMENT_POLICY}" \
      --availability-domain="${AD}" \
      --hostname="${HOST}.${DOMAIN}" \
      --disk="name=${HOST},boot=yes,auto-delete=yes" \
      --labels=gcve-node=true \
      --tags=mm-gcve-node \
      --deletion-protection \
      --maintenance-policy=TERMINATE \
      --restart-on-failure \
      --network-performance-configs=total-egress-bandwidth-tier=TIER_1 \
      --project="${PROJECT_ID}" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${MGMT_SUBNET},no-address,private-network-ip=${MGMT_IP}" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${VMOTION_SUBNET},no-address,private-network-ip=${VMOTION_IP},vlan=2" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${VSAN_SUBNET},no-address,private-network-ip=${VSAN_IP},vlan=3" \
      --network-interface="network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${TEP_SUBNET},no-address,private-network-ip=${TEP_IP},vlan=4"
done

# Verify instance creation and network interfaces
gcloud compute instances list --project="${PROJECT_ID}" --zones="${ZONE}" \
    --filter="name~'esxi-h[7-9]'" \
    --format="table(name,status,networkInterfaces[].vlan.list(),networkInterfaces[].networkIP.list())"

NEG メンバーシップを更新する

VCF ネットワークアプライアンスがクラスタノード間でトラフィックをルーティングできるように、ゾーン内のすべてのノードがサブネットの同じゾーン NEG に属している必要があります。新しいホストを既存の管理 NEG と NSX TEP NEG に追加します。

# List the NEGs in the zone (management and NSX TEP)
gcloud compute network-endpoint-groups list --zones="${ZONE}" --project="${PROJECT_ID}" \
    --format="table(name,subnetwork.basename(),networkEndpointType,size)"

ALL_NEGS=("${MGMT_NEG}" "${TEP_NEG}")
for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  for NEG in "${ALL_NEGS[@]}"; do
    gcloud compute network-endpoint-groups update "${NEG}" \
        --zone="${ZONE}" \
        --add-endpoint="instance=${HOST}" \
        --project="${PROJECT_ID}"
  done
done

# Verify NEG endpoints
for NEG in "${ALL_NEGS[@]}"; do
  gcloud compute network-endpoint-groups list-network-endpoints "${NEG}" \
      --zone="${ZONE}" --project="${PROJECT_ID}" \
      --format="table(networkEndpoint.instance,networkEndpoint.ipAddress)"
done

ESXi root パスワードをリセットする

セキュリティとホストのコミッショニングのために、各新しいホストの root パスワードを、Secret Manager に保存されている ESXi root パスワードにリセットします。後のステップで、同じシークレットを使用してホストをコミッショニングします。パスワードが VCF の複雑さの要件（大文字、小文字、数字、特殊文字を含む 15 文字以上）を満たしていることを確認します。初期デプロイ後に ESXi root または VCF のパスワードを変更またはローテーションした場合は、これらのコマンドを実行する前に、Secret Manager で対応するシークレットを更新します。

各新しいホストで root パスワードをリセットするには、ジャンプボックス VM から次のコマンドを実行し、プロンプトが表示されたら初期 ESXi root パスワードを入力します。

# 1. Read the ESXi root password from Secret Manager
ESXI_ROOT_PASSWORD=$(gcloud secrets versions access latest \
    --secret="${ESXI_PASSWORD_SECRET}" --project="${PROJECT_ID}")

# 2. Reset the root password on each new host
for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  ssh -o StrictHostKeyChecking=no "root@${HOST}.${DOMAIN}" \
      "esxcli system account set -i root -p '${ESXI_ROOT_PASSWORD}' -c '${ESXI_ROOT_PASSWORD}'"
done

# 3. Optional: Verify that the FQDN is set and vmk0 is configured as STATIC
ssh "root@esxi-h7.${DOMAIN}" \
    'esxcli system hostname get; esxcli network ip interface ipv4 get -i vmk0'

専用ネットワークプールを作成する

VCF は、ホストのコミッショニング時に選択したネットワークプールから vMotion と vSAN の IP アドレスを割り当てます。既存のクラスタのネットワークプールには独自のホスト IP アドレスのみが含まれているため、新しいホストの Compute Engine Dynamic NIC に事前に割り当てた vMotion と vSAN の IP アドレスを正確に含む IP 範囲を持つ専用のネットワークプールを作成します。専用のネットワークプールを使用すると、VCF IP の割り当てが事前に割り当てられた Compute Engine IP アドレスのセット内に維持されるため、不一致が発生した場合にのみ、後でホストと IP の順序を調整する必要があります。

ネットワークプールは、VCF Operations または SDDC Manager API を使用して作成できます。

VCF Operations

[VCF Operations] で、[ネットワークプール管理] に移動し、[ネットワークプールを作成] をクリックして、vMotion（VLAN 2、192.168.2.21～192.168.2.23）と vSAN（VLAN 3、192.168.3.21～192.168.3.23）のネットワーク設定と 8896 バイトの MTU を使用して cl02-np01 ネットワークプールを作成します。

SDDC Manager API

次のコマンドを実行して、ネットワークプールを作成し、その ID を取得します。

TOKEN=$(curl -s -X POST "https://${SDDC_MANAGER}/v1/tokens" \
    -H "Content-Type: application/json" \
    -d "{\"username\":\"${VCF_USER}\",\"password\":\"${VCF_PASSWORD}\"}" | jq -r '.accessToken')

curl -s -X POST "https://${SDDC_MANAGER}/v1/network-pools" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "{
      \"name\": \"${NETWORK_POOL_NAME}\",
      \"networks\": [
        { \"type\": \"VMOTION\", \"vlanId\": 2, \"mtu\": ${MTU},
          \"subnet\": \"192.168.2.0\", \"mask\": \"255.255.255.0\", \"gateway\": \"192.168.2.1\",
          \"ipPools\": [ { \"start\": \"192.168.2.21\", \"end\": \"192.168.2.23\" } ] },
        { \"type\": \"VSAN\", \"vlanId\": 3, \"mtu\": ${MTU},
          \"subnet\": \"192.168.3.0\", \"mask\": \"255.255.255.0\", \"gateway\": \"192.168.3.1\",
          \"ipPools\": [ { \"start\": \"192.168.3.21\", \"end\": \"192.168.3.23\" } ] }
      ]
    }"

# Retrieve the network pool ID for host commissioning
POOL_ID=$(curl -s "https://${SDDC_MANAGER}/v1/network-pools" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r --arg n "${NETWORK_POOL_NAME}" '.elements[] | select(.name==$n) | .id')
echo "${POOL_ID}"

ホストをコミッショニングする

VCF Operations または SDDC Manager API を使用して、新しい ESXi ホストを SDDC Manager インベントリにコミッションします。

VCF Operations

VCF Operations で、[Inventory] > [Hosts] > [Commission Hosts] に移動します。
cl02-np01 ネットワークプールを選択し、vSAN ESA ストレージタイプを選択します。
ホストの FQDN（esxi-h7.vmware.gve、esxi-h8.vmware.gve、esxi-h9.vmware.gve）と root の認証情報を入力します。
SSL サムプリントを承認し、ホストを検証して、[Commission] をクリックします。

SDDC Manager API

次のコマンドを実行して、ホストを検証してコミッショニングし、Successful が返されるまでタスク ID をポーリングします。

ESXI_PASSWORD=$(gcloud secrets versions access latest \
    --secret="${ESXI_PASSWORD_SECRET}" --project="${PROJECT_ID}")

HOST_FQDNS=$(for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"; echo "${HOST}.${DOMAIN}"
done | jq -R . | jq -s .)

HOSTS_JSON=$(jq -n --argjson f "${HOST_FQDNS}" --arg p "${ESXI_PASSWORD}" \
    --arg np "${POOL_ID}" --arg npn "${NETWORK_POOL_NAME}" \
    '$f | map({fqdn: ., username: "root", password: $p, storageType: "VSAN_ESA",
               networkPoolId: $np, networkPoolName: $npn})')

# 1. Validate hosts
curl -s -X POST "https://${SDDC_MANAGER}/v1/hosts/validations" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" -d "${HOSTS_JSON}"

# 2. Commission hosts
TASK_ID=$(curl -s -X POST "https://${SDDC_MANAGER}/v1/hosts" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${HOSTS_JSON}" | jq -r '.id')

# 3. Poll task status until Successful
curl -s "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" -H "Authorization: Bearer ${TOKEN}" | jq -r '.status'

ホストの SSL サムプリントに内部（FQDN 以外）の証明書名が表示されている場合、DNS 検索ドメインがホストに構成されていません。影響を受ける ESXi ホストで、esxcli network ip dns search add -d vmware.gve コマンドを実行し、/var/lib/vmware/osdata/init.sh スクリプトを再実行します。次に、/sbin/generate-certificates コマンドを実行して、rhttpproxy サービスと hostd サービス（/etc/init.d/rhttpproxy restart && /etc/init.d/hostd restart）を再起動します。

デプロイ前の IP アライメントを確認する

SDDC Manager で、すべての vSAN、vMotion、ネットワーク接続の検証を有効にしておきます。これらの検証チェックは、VCF が各ホストに割り当てる vmk1（vMotion）と vmk2（vSAN）の IP アドレスが、そのホストの Compute Engine Dynamic NIC IP アドレスと一致する場合にのみ合格します。SDDC Manager が異なるホスト順序でプール IP アドレスを割り当てたために不一致が発生すると、クラスタ作成タスクは接続チェックで一時停止します。その後、次のステップで Dynamic NIC を調整してから、タスクを再試行します。

ネットワークプールの範囲が Compute Engine vMotion と vSAN NIC の IP アドレスと一致していることを確認する: ネットワークプールに、新しいホストの Dynamic NIC に事前に割り当てた IP アドレス（この例では 192.168.2.21～192.168.2.23 と 192.168.3.21～192.168.3.23）のみが含まれていることを確認します。

# Inspect network pool definition
curl -s "https://${SDDC_MANAGER}/v1/network-pools/${POOL_ID}" \
    -H "Authorization: Bearer ${TOKEN}" | jq '.networks[] | {type, vlanId, mtu, ipPools}'

# Inspect Compute Engine dynamic NIC IPs per new host (VLAN 2 = vMotion, 3 = vSAN, 4 = TEP)
for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  echo "== ${HOST}"
  gcloud compute instances describe "${HOST}" --zone="${ZONE}" --project="${PROJECT_ID}" \
      --format="table(networkInterfaces[].name,networkInterfaces[].vlan,networkInterfaces[].networkIP)"
done

ホスト名の昇順で IP アドレスを割り当てる: ホスト名の昇順（esxi-h7 → .21、esxi-h8 → .22、esxi-h9 → .23）で Compute Engine IP アドレスを事前に割り当て、IP アドレスのセットが両側で同じになるようにします。
SDDC Manager が検証をバイパスしないことを確認する: SDDC Manager アプライアンス（root）で、application.properties ファイルに validation.disable.* プロパティが含まれていないことを確認します。
```
# Must return no output. If any validation.disable.* line is present, remove it
# and run: systemctl restart domainmanager
grep -n 'validation.disable' /etc/vmware/vcf/domainmanager/application.properties
```
SDDC Manager API を使用してクラスタを追加する場合は、リクエスト本文に "skipValidations": true プロパティを設定しないでください。
Compute Engine TEP NIC IP アドレスに合わせて NSX TEP プールのサイズを設定する: クラスタに新しい静的 NSX TEP IP アドレスプールを構成します。範囲は 192.168.4.21～192.168.4.23（TEP_START 変数から TEP_END 変数まで）で、新しいホストの VLAN 4 Dynamic NIC の IP アドレスと一致させ、ゲートウェイを 192.168.4.1 に設定します。

クラスタを追加する

VCF Operations または SDDC Manager API を使用して、クラスタをターゲットドメインに追加できます。

VCF Operations

VCF Operations にログインし、[Inventory] に移動して [VCF Instances] を開き、ターゲットドメイン（mgmt-domain または wld01）を選択して、[Add cluster] をクリックします（または、SDDC Manager UI で、[Workload Domains] > [ターゲットドメイン] > [Actions] > [Add Cluster] に移動します）。次の設定を使用してウィザードを完了します。

ウィザードページ	フィールド	値
ストレージ	種類	vSAN、vSAN ESA を有効にする、vSAN HCI、転送中のデータの暗号化をオフ
クラスタ	クラスタ名	`cl02`
画像	vLCM イメージ	既存のクラスタで使用されているイメージを選択するか、[この VCF インスタンスのホストからイメージを抽出する] を選択します（`esxi-h7` を使用）。
ホスト	ホスト	`esxi-h7`、`esxi-h8`、`esxi-h9`（`cl02-np01` ネットワークプールを使用して vSAN ESA としてコミッショニング）
vSphere Distributed Switch	プロフィール	デフォルト（単一 VDS）またはカスタム: 1 アップリンク（`uplink1` → `vmnic0`）、MTU `8896`、トラフィックタイプ ESX 管理、VM 管理、vMotion、vSAN、NSX
NSX スイッチモード	仮想スイッチの運用モード	[Apply the default virtual switch mode configured in NSX Manager] をオフにし、[Operational Mode] を [Standard] に設定します。VMware ソリューションホストは、デフォルトモード（拡張データパス標準）をサポートしていません。
NSX ホストオーバーレイ	TEP VLAN と IP の割り当て	VLAN `4`（既存の NSX 構成と一致）、静的 IP プール（DHCP は使用しない）: 新しいプール `cl02-tep-pool`、CIDR `192.168.4.0/24`、範囲 `192.168.4.21`～`192.168.4.23`、ゲートウェイ `192.168.4.1`
確認	送信	[Finish] をクリックします。[フリート管理] > [タスク] に移動してタスクをモニタリングし、タスク ID（`TASK_ID`）を記録します。

SDDC Manager API

ターゲットドメイン ID、vLCM イメージパーソナリティ ID、コミッショニングされたホスト ID を取得し、クラスタを作成するための仕様を検証して送信します。

# 1. Retrieve target domain ID, vLCM image personality ID, and host specs
DOMAIN_ID=$(curl -s "https://${SDDC_MANAGER}/v1/domains" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r --arg d "${TARGET_DOMAIN}" '.elements[] | select(.name==$d) | .id')

curl -s "https://${SDDC_MANAGER}/v1/personalities" -H "Authorization: Bearer ${TOKEN}" \
    | jq -r '.elements[] | [.personalityId, .personalityName] | @tsv'
IMAGE_ID="PERSONALITY_ID"   # Select the personalityId of the existing clusters' image

HOST_SPECS=$(curl -s "https://${SDDC_MANAGER}/v1/hosts" -H "Authorization: Bearer ${TOKEN}" \
    | jq --argjson f "${HOST_FQDNS}" --arg vds "${VDS_NAME}" '
        [.elements[] | select(.fqdn as $x | $f | index($x))
         | {id, hostNetworkSpec: {vmNics: [{id: "vmnic0", uplink: "uplink1", vdsName: $vds}]}}]')
echo "${HOST_SPECS}" | jq 'length'   # Must equal 3

# 2. Construct the cluster specification (without skipValidations)
CLUSTER_SPEC=$(jq -n \
    --arg domain "${DOMAIN_ID}" --arg name "${CLUSTER_NAME}" --arg img "${IMAGE_ID}" \
    --argjson hosts "${HOST_SPECS}" --arg vds "${VDS_NAME}" --argjson mtu "${MTU}" \
    --arg tz "${TRANSPORT_ZONE}" --arg pool "${TEP_POOL_NAME}" \
    --arg cidr "${TEP_CIDR}" --arg gw "${TEP_GATEWAY}" --arg s "${TEP_START}" --arg e "${TEP_END}" '
{
  domainId: $domain,
  computeSpec: { clusterSpecs: [{
    name: $name,
    clusterImageId: $img,
    hostSpecs: $hosts,
    datastoreSpec: { vsanDatastoreSpec: { datastoreName: ($name + "-vsan"), esaConfig: { enabled: true } } },
    networkSpec: {
      vdsSpecs: [{
        name: $vds, mtu: $mtu,
        portGroupSpecs: [
          { name: ($vds + "-pg-mgmt"),    transportType: "MANAGEMENT", activeUplinks: ["uplink1"], teamingPolicy: "loadbalance_loadbased" },
          { name: ($vds + "-pg-vmotion"), transportType: "VMOTION",    activeUplinks: ["uplink1"], teamingPolicy: "loadbalance_loadbased" },
          { name: ($vds + "-pg-vsan"),    transportType: "VSAN",       activeUplinks: ["uplink1"], teamingPolicy: "loadbalance_loadbased" }
        ],
        nsxtSwitchConfig: {
          transportZones: [ { name: $tz, transportType: "OVERLAY" } ],
          hostSwitchOperationalMode: "STANDARD"
        }
      }],
      nsxClusterSpec: { nsxTClusterSpec: {
        uplinkProfiles: [{ name: ($name + "-uplink-profile"),
          teamings: [ { policy: "LOADBALANCE_SRCID", activeUplinks: ["uplink-1"] } ],
          transportVlan: 4 }],
        ipAddressPoolsSpec: [{ name: $pool,
          subnets: [{ cidr: $cidr, gateway: $gw, ipAddressPoolRanges: [ { start: $s, end: $e } ] }] }]
      }},
      networkProfiles: [{
        name: ($name + "-network-profile"), isDefault: true,
        nsxtHostSwitchConfigs: [{
          vdsName: $vds, uplinkProfileName: ($name + "-uplink-profile"), ipAddressPoolName: $pool,
          vdsUplinkToNsxUplink: [ { vdsUplinkName: "uplink1", nsxUplinkName: "uplink-1" } ]
        }]
      }]
    }
  }]}
}')

# 3. Validate the cluster specification
curl -s -X POST "https://${SDDC_MANAGER}/v1/clusters/validations" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${CLUSTER_SPEC}" | jq '{executionStatus, resultStatus}'

# 4. Create the cluster and poll the task
TASK_ID=$(curl -s -X POST "https://${SDDC_MANAGER}/v1/clusters" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d "${CLUSTER_SPEC}" | jq -r '.id')
curl -s "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" -H "Authorization: Bearer ${TOKEN}" | jq -r '.status'

コマンドを実行する前に、PERSONALITY_ID をクラスタ vLCM イメージの personalityId 値に置き換えます。

VCF がホストに Compute Engine Dynamic NIC と異なる vMotion または vSAN IP アドレスを割り当てると、タスクは vSAN と vMotion の接続の検証ステップで停止します。タスクを失敗した状態のままにして、vMotion と vSAN の Dynamic NIC を調整するの手順を完了してから、タスクを再試行します。タスクをキャンセルしたり、検証チェックを無効にしたりしないでください。

vMotion と vSAN の Dynamic NIC を調整する

クラスタ作成タスクが vSAN と vMotion の接続の検証ステップで停止した場合は、このセクションの手順を適用します。タスクがそのステップを通過した場合は、ステップ 1 と 2 のみを実行して IP の整合性を確認し、NSX TEP Dynamic NIC を整合するに進みます。

VCF で割り当てられた IP アドレスを読み取る: SDDC Manager の /v1/hosts エンドポイント（または SDDC Manager の platform データベース）にクエリを実行して、VCF が各ホストに割り当てた vMotion（vmk1）と vSAN（vmk2）の IP アドレスを確認します。

curl -s "https://${SDDC_MANAGER}/v1/hosts" -H "Authorization: Bearer ${TOKEN}" | jq -r '
  ["FQDN","STATUS","CLUSTER","MGMT_IP","VMOTION_IP","VSAN_IP"],
  (.elements | sort_by(.fqdn)[] | [
     .fqdn, (.status // "-"), (.cluster.name // .cluster.id // "-"),
     (([.ipAddresses[]? | select(.type=="MANAGEMENT") | .ipAddress] | first) // "-"),
     (([.ipAddresses[]? | select(.type=="VMOTION")    | .ipAddress] | first) // "-"),
     (([.ipAddresses[]? | select(.type=="VSAN")       | .ipAddress] | first) // "-")
  ]) | @tsv' | column -t

# Alternative (run on the SDDC Manager appliance shell):
# psql -h localhost -U postgres -d platform \
#   -c "select hostname, vmotion_ip_address, vsan_ip_address from host;"

Compute Engine Dynamic NIC と比較する: 各新しいホストの現在の Dynamic NIC IP アドレスを一覧表示します。

for entry in "${CLUSTER_HOSTS[@]}"; do
  read -r HOST _ <<< "${entry}"
  echo "== ${HOST}"
  gcloud compute instances describe "${HOST}" --zone="${ZONE}" --project="${PROJECT_ID}" \
      --format="table(networkInterfaces[].name,networkInterfaces[].vlan,networkInterfaces[].networkIP)"
done

不一致の Dynamic NIC をすべて削除してから、再度追加する: インターフェースを再度追加する前に、不一致のすべてのホストで不一致の Dynamic NIC（vMotion の nic0.2 インターフェースと vSAN の nic0.3 インターフェース）をすべて削除します。そうしないと、2 つのホスト間で IP アドレスが入れ替わり、IP_IN_USE エラーが発生します。

# Example: VCF assigned esxi-h7 vMotion 192.168.2.22 and vSAN 192.168.3.22
HOST="esxi-h7"
VCF_VMOTION_IP="192.168.2.22"
VCF_VSAN_IP="192.168.3.22"

# 3a. Delete mismatched NICs (run on all mismatched hosts before running 3b)
gcloud compute instances network-interfaces delete "${HOST}" \
    --network-interface=nic0.2 \
    --zone="${ZONE}" --project="${PROJECT_ID}" --quiet
gcloud compute instances network-interfaces delete "${HOST}" \
    --network-interface=nic0.3 \
    --zone="${ZONE}" --project="${PROJECT_ID}" --quiet

# 3b. Re-add the dynamic NICs with the VCF-allocated IP addresses
# vMotion (VLAN 2)
gcloud compute instances network-interfaces add "${HOST}" \
    --parent-nic-name=nic0 --vlan=2 \
    --network="${VPC_NETWORK}" --subnetwork="${VMOTION_SUBNET}" \
    --private-network-ip="${VCF_VMOTION_IP}" --no-address \
    --zone="${ZONE}" --project="${PROJECT_ID}"

# vSAN (VLAN 3)
gcloud compute instances network-interfaces add "${HOST}" \
    --parent-nic-name=nic0 --vlan=3 \
    --network="${VPC_NETWORK}" --subnetwork="${VSAN_SUBNET}" \
    --private-network-ip="${VCF_VSAN_IP}" --no-address \
    --zone="${ZONE}" --project="${PROJECT_ID}"

失敗したクラスタタスクを再試行する: VCF Operations で、[フリート管理] > [タスク] に移動してタスクを再試行するか、次の SDDC Manager API コマンドを実行します。
```
curl -s -X PATCH "https://${SDDC_MANAGER}/v1/tasks/${TASK_ID}" \
    -H "Authorization: Bearer ${TOKEN}" -H "Content-Type: application/json" \
    -d '{"status": "RETRY"}'
```
再試行されたタスクは、vSAN と vMotion の接続チェックを再度実行し、すべての Compute Engine Dynamic NIC が VCF で割り当てられた IP アドレスと一致すると成功します。

NSX TEP Dynamic NIC を調整する

NSX がホストをトランスポートノードとして構成したら、新しいホストで VLAN 4 NSX TEP（vmk10）Dynamic NIC を確認して調整します。

NSX で割り当てられた TEP IP アドレスを取得する: ターゲットドメイン（NSX_MANAGER）の NSX Manager にクエリを実行するか、各 ESXi ホストで esxcli network ip interface ipv4 get -i vmk10 コマンドを実行します。
```
NSX_PW="NSX_ADMIN_PASSWORD"

# Map transport node ID to hostname
curl -s -u "admin:${NSX_PW}" "https://${NSX_MANAGER}/api/v1/transport-nodes" \
    | jq -r '.results[] | [.id, .display_name] | @tsv'

# Map transport node ID to TEP device and IP address
curl -s -u "admin:${NSX_PW}" "https://${NSX_MANAGER}/api/v1/transport-nodes/state" \
    | jq -r '.results[] | [.transport_node_id, .state,
        ([.host_switch_states[]?.endpoints[]? | .device_name + "=" + .ip] | join(","))] | @tsv'
```
コマンドを実行する前に、NSX_ADMIN_PASSWORD を NSX Manager の admin パスワード（SDDC Manager の /v1/credentials エンドポイントまたは VCF Operations のパスワード管理から取得可能）に置き換えます。
Compute Engine TEP NIC（VLAN 4）と比較する: NSX によって割り当てられた vmk10 IP アドレスを、新しいホスト（esxi-h7、esxi-h8、esxi-h9）の VLAN 4 Dynamic NIC IP アドレスと比較します。新しいホストのみが対象です。他のクラスタのホストの TEP NIC は変更しないでください。

不一致の TEP NIC を再作成する: 不一致の新しいホストすべてについて、まず各ホストを TEP NEG から切断し、不一致のホストすべてで nic0.4 インターフェースを削除します。次に、nic0.4 インターフェースを再度追加し、ホストを TEP NEG に再度アタッチします。

# Example: Compute Engine has 192.168.4.21 on esxi-h7, but NSX assigned 192.168.4.23
HOST="esxi-h7"
CURRENT_TEP_IP="192.168.4.21"
NSX_TEP_IP="192.168.4.23"

# 3a. Detach the host from the TEP NEG
gcloud compute network-endpoint-groups update "${TEP_NEG}" \
    --zone="${ZONE}" --project="${PROJECT_ID}" \
    --remove-endpoint="instance=${HOST},ip=${CURRENT_TEP_IP}"

# 3b. Delete the mismatched TEP NIC (nic0.4) on all mismatched hosts first
gcloud compute instances network-interfaces delete "${HOST}" \
    --network-interface=nic0.4 \
    --zone="${ZONE}" --project="${PROJECT_ID}" --quiet

# 3c. Re-add nic0.4 with the NSX-allocated IP address
gcloud compute instances network-interfaces add "${HOST}" \
    --parent-nic-name=nic0 --vlan=4 \
    --network="${VPC_NETWORK}" --subnetwork="${TEP_SUBNET}" \
    --private-network-ip="${NSX_TEP_IP}" --no-address \
    --zone="${ZONE}" --project="${PROJECT_ID}"

# 3d. Re-attach the host to the TEP NEG
gcloud compute network-endpoint-groups update "${TEP_NEG}" \
    --zone="${ZONE}" --project="${PROJECT_ID}" \
    --add-endpoint="instance=${HOST}"

クラスタのデプロイを確認する

クラスタ作成タスクが完了し、すべての Dynamic NIC を調整したら、次のことを確認します。

vCenter Server（vc01 または vc02）: cl02 クラスタと 3 つのホストすべてが接続され、ネットワークアラームなしで正常に動作しています。
vSAN: cl02 クラスタで、[Monitor] > [vSAN] > [Skyline Health] に移動し、すべてのヘルスチェックに合格していること、vSAN データストアに 3 つのホストすべての合計容量が表示されていることを確認します。
NSX Manager: [System] > [Fabric] > [Hosts] に移動し、新しいホストごとに [Success] と [Up] が表示されていること、すべてのオーバーレイトンネルが稼働していることを確認します。
VCF オペレーション: ターゲットドメインでクラスタのステータスが [アクティブ] になり、タスクリストに失敗したタスクが表示されません。
既存のクラスタ: ドメイン内の他のすべてのクラスタは正常なままです。
省略可: 既存のクラスタと cl02 クラスタ間、および cl02 クラスタ内のホスト間で vMotion を使用してテスト VM を移行します。

ESXi ホストシェル（esxi-h7 など）から、vMotion、vSAN、NSX TEP インターフェースを介したジャンボフレーム接続（8896 MTU から 28 バイトの IP/ICMP ヘッダーを引いた値 = 8868 バイト）を確認します。

esxcli network ip interface ipv4 get                        # Verify vmk0, vmk1, vmk2, and vmk10 IPs
vmkping -S vmotion -I vmk1 -d -s 8868 192.168.2.22          # vMotion
vmkping -I vmk2 -d -s 8868 192.168.3.22                     # vSAN
vmkping ++netstack=vxlan -I vmk10 -d -s 8868 192.168.4.22   # NSX TEP

省略可: 許容する vSAN 障害を構成する

vSAN ESA の場合、VCF はクラスタタイプとホスト数に基づいてデフォルトのデータストアストレージポリシーを作成して割り当てます。FTT 設定を明示的に構成するには、クラスタのホスト数でサポートされているポリシーを選択します。

許容障害数	データプレースメントスキーム	最小ホスト数
`FTT=1`	RAID-1（ミラーリング）または RAID-5（消失訂正符号）	3（ホスト障害後またはメンテナンス中に再構築する場合は 4 以上を推奨）
`FTT=2`	RAID-1（ミラーリング）	5
`FTT=2`	RAID-6（消失訂正符号）	6

ターゲットドメインの vCenter Server（vc01 または vc02）の vSphere Client でデフォルトのストレージポリシーを設定するには、次の操作を行います。

vSAN がカスタムのデフォルトポリシーを上書きしないように、vSAN ESA クラスタの自動ポリシー管理を無効にします。
[Policies and Profiles] > [VM Storage Policies] > [Create] に移動し、vSAN ストレージルールを有効にします。[Availability] セクションで、[Failures to tolerate] を選択します（たとえば、3 ～ 4 台のホストの場合は [1 failure - RAID-1 (Mirroring)]、6 台以上のホストの場合は [2 failures - RAID-6 (Erasure Coding)]）。
新しいポリシーをデータストアのデフォルトとして設定します。cl02 vSAN データストアを選択し、[構成] > [全般] > [デフォルトのストレージポリシー] > [編集] に移動して、新しいポリシーを選択します。
既存の VM にポリシーを適用します（[VM Policies] > [Edit VM Storage Policies]）。cl02 クラスタの [Monitor] > [vSAN] > [Virtual Objects] に移動して、コンプライアンスを確認します。

クラスタ作成のトラブルシューティング

次の表に、vSphere クラスタをドメインに追加する際の一般的な問題、原因、解決策を示します。

問題	原因	解決策
vSAN と vMotion の接続性検証が失敗する。新しいホストが異常を報告する	クラスタを作成または拡張すると、SDDC Manager はホストの順序を保持せずに、ネットワークプールから `vmk1` と `vmk2` の IP アドレスを割り当てます。	検証を有効にしたままにします。Compute Engine NIC の IP アドレスに一致する専用ネットワークプールを作成し、デプロイ前の調整を確認します。接続チェックでタスクが一時停止した場合は、Dynamic NIC を調整してタスクを再試行します。
クラスタを追加した後、NSX ホストのステータスが `Degraded` になるか、トンネルがダウンする	NSX Manager は、IP プールから TEP（`vmk10`）IP アドレスをランダムに割り当てるため、Compute Engine TEP NIC と一致しない可能性があります。Dynamic NIC サブネットは DHCP をサポートしていません。	Compute Engine TEP IP アドレスに一致する専用の TEP IP プールを使用し、NSX ホストの準備後に TEP Dynamic NIC を調整します。
BFD が稼働しているときに `NSX_VDL2` エージェントまたはホストが `Degraded` を報告する	NSX TEP IP プールにゲートウェイ IP アドレスがありません。	TEP IP プールでサブネットゲートウェイ（`192.168.4.1`）を構成します。
Dynamic NIC を再追加すると `IP_IN_USE` エラーが発生する	2 つのホストが IP アドレスを交換したか、計画された IP アドレスが別のクラスタと重複しています。	インターフェースを再度追加する前に、まずすべてのホストで不一致の Dynamic NIC をすべて削除し、IP プランが既存のクラスタと重複していないことを確認します。
NSX 仮想スイッチモードはサポートされていません	VCF 9.x では、デフォルトの NSX 仮想スイッチモードは拡張データパス標準です。これは、VMware ソリューションホストではサポートされていません。	[Apply the default virtual switch mode configured in NSX Manager] をオフにして、[Operational Mode] を [Standard]（API 仕様では `"hostSwitchOperationalMode": "STANDARD"`）に設定します。詳細については、NSX 仮想スイッチモードをご覧ください。
ホストがサブネットゲートウェイ（`.1`）に ping を実行できない	Google Cloud は、サブネットゲートウェイ IP アドレスの ICMP エコーリクエストに応答しません。	想定される動作。ゲートウェイの ping 警告は無視してください。
時刻同期（NTP）の構成	ベアメタルホストは、時刻同期に Compute Engine メタデータサーバーを使用します。	メタデータサーバーの IP アドレス（`169.254.169.254`）を NTP サーバーとして直接使用します。
ホストのサムプリントまたは証明書に内部名が表示される	DNS 検索ドメインがホストに設定されていないか、ホスト名の末尾にドットが付いています。	`esxcli network ip dns search add -d vmware.gve` コマンドを実行し、`/var/lib/vmware/osdata/init.sh` スクリプトを再実行してから、`/sbin/generate-certificates` コマンドを実行して `rhttpproxy` サービスと `hostd` サービスを再起動します。
ホストのコミッショニングが失敗する	起動サービスが変換しなかったため、`vmk0` VMkernel アダプタは引き続き DHCP を使用します。	`esxcli network ip interface ipv4 get -i vmk0` コマンドを実行します。タイプが `DHCP` の場合は、手動で静的に設定します（例: `esxi-h7` の場合は `esxcli network ip interface ipv4 set -i vmk0 -t static -I 192.168.0.161 -N 255.255.255.0 -g 192.168.0.1`）。
vSAN レプリケーションエラー、vMotion タイムアウト、NSX オーバーレイの断片化	VCF は、VDS、VMkernel アダプタ、NSX プロファイルの MTU をデフォルトで `9000` バイトに設定します。VPC ネットワークは、`8896` バイトを超えるフレームをドロップします。	VDS、ネットワークプール（vMotion と vSAN）、NSX アップリンクプロファイルで `8896` バイトの MTU を構成します。詳細については、VDS MTU の不一致をご覧ください。
ウィザードで、オーバーレイポートグループの VLAN ID の入力を求められます。	デフォルトの VDS プロファイルには、NSX ホストオーバーレイ VLAN ID が必要です。	既存の NSX 構成の TEP VLAN ID（このガイドでは `4`）を入力します。
新しいクラスタにワークロード VM のポートグループが存在しない	デフォルトの VDS プロファイルでは、インフラストラクチャポートグループのみが作成されます。	クラスタの作成後にワークロード VM の分散ポートグループを作成するか、カスタムスイッチ構成を使用します。
選択した vLCM イメージを使用してホストを追加することはできません	クラスタの vLCM イメージが、ホストにインストールされている ESXi ビルドと異なります。	既存のクラスタで使用しているものと同じ ESXi イメージファミリーを使用するか、新しいホストのいずれかからイメージを抽出します。

次のステップ

vSphere クラスタにノードを追加または削除するで、既存のクラスタを拡張または圧縮する。
ノード容量を管理するの Google Cloud コンソールで、ベアメタルノードの容量を管理します。
vSphere クラスタについてで、クラスタのサイズ設定とアーキテクチャのガイドラインを確認します。
既知の問題で、一般的なデプロイと運用の回避策を確認する。
Dynamic NIC とベアメタルインスタンスの詳細を確認する。

vSphere クラスタをドメインに追加する

アーキテクチャの概要

始める前に

環境要件を確認する

環境パラメータの例を確認する

IP アドレスとホスト名を計画する

ターゲット ドメインを選択する

リージョンの割り当てを確認する

環境変数を設定する

DNS レコードを作成する

ベアメタル インスタンスを作成する

プレースメント ポリシーの作成

ブートディスクとベアメタル ESXi インスタンスを作成する

NEG メンバーシップを更新する

ESXi root パスワードをリセットする

専用ネットワーク プールを作成する

VCF Operations

SDDC Manager API

ホストをコミッショニングする

VCF Operations

SDDC Manager API

デプロイ前の IP アライメントを確認する

クラスタを追加する

VCF Operations

SDDC Manager API

vMotion と vSAN の Dynamic NIC を調整する

NSX TEP Dynamic NIC を調整する

クラスタのデプロイを確認する

省略可: 許容する vSAN 障害を構成する

クラスタ作成のトラブルシューティング

次のステップ

ターゲットドメインを選択する

ベアメタルインスタンスを作成する

プレースメントポリシーの作成

専用ネットワークプールを作成する