Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Problemi noti

Questa pagina elenca i problemi noti e le soluzioni alternative per il deployment e il funzionamento di VMware Cloud Foundation (VCF) nella soluzione VMware su Google Cloud.

Mancata corrispondenza degli indirizzi IP vMotion e vSAN dell'host durante il deployment di VCF

Quando esegui il deployment di un dominio di gestione VCF, il programma di installazione VCF ordina il pool di indirizzi IP vMotion e vSAN in ordine numerico crescente e assegna gli indirizzi IP in sequenza agli host ESXi nell'ordine esatto in cui vengono visualizzati nell'array hostSpecs. Quando crei un dominio workload VI o espandi un cluster, SDDC Manager alloca gli indirizzi IP VMkernel vMotion e vSAN dal pool di indirizzi IP configurato senza preservare l'ordine degli host hostSpecs.

Poiché le reti VPC Google Cloud eseguono controlli rigorosi degli IP di origine e di destinazione sulle NIC dinamiche di ogni nodo bare metal, l'indirizzo IP assegnato da VCF all'adattatore vmk1 (vMotion) o vmk2 (vSAN) di un host deve corrispondere all'indirizzo IP configurato sulla NIC dinamica di Compute Engine corrispondente (nic0.VLAN_ID). Se l'indirizzo IP della NIC dinamica di un host non corrisponde all'indirizzo IP di runtime assegnato da VCF, l'hypervisor riceve o trasmette il traffico con un indirizzo IP non corrispondente e la convalida della rete o il deployment del cluster non va a buon fine.

Ad esempio, considera un deployment di un dominio di gestione di quattro host con le seguenti allocazioni di NIC dinamiche di Compute Engine:

FQDN host	IP vMotion (`vmk1`)	IP vSAN (`vmk2`)	IP NSX-TEP (`vmk10`)
`esxi-h0.40-vmware.gve`	`10.40.2.2`	`10.40.3.2`	`10.40.4.2`
`esxi-h1.40-vmware.gve`	`10.40.2.5`	`10.40.3.5`	`10.40.4.5`
`esxi-h2.40-vmware.gve`	`10.40.2.3`	`10.40.3.3`	`10.40.4.3`
`esxi-h3.40-vmware.gve`	`10.40.2.4`	`10.40.3.4`	`10.40.4.4`

Se gli host sono ordinati nella configurazione di input come esxi-h0, esxi-h2, esxi-h1, esxi-h3, il programma di installazione VCF ordina il pool (10.40.2.2, 10.40.2.3, 10.40.2.4, 10.40.2.5) e mappa gli indirizzi in sequenza a esxi-h0, esxi-h2, esxi-h1 e esxi-h3. L'host esxi-h1 riceve 10.40.2.4 dal programma di installazione anche se la NIC dinamica di Compute Engine sottostante prevede 10.40.2.5.

Soluzione: utilizza una delle seguenti opzioni a seconda che tu stia eseguendo il deployment di un nuovo dominio di gestione o l'espansione di un dominio o cluster di workload esistente.

Opzione 1: pre-ordina le specifiche dell'host per il deployment del dominio di gestione

Quando utilizzi il toolkit della soluzione VMware (self-managed-vmware-solution-toolkit), il toolkit esegue automaticamente query sugli indirizzi IP delle NIC dinamiche dei nodi bare metal e ordina gli array hostSpecs e includeIpAddressRanges nel file JSON del deployment VCF.

Se crei o modifichi manualmente il file JSON di deployment di VCF, allinea l'ordine delle voci nell'array hostSpecs in modo che corrisponda all'ordinamento numerico crescente degli indirizzi IP delle NIC dinamiche allocate (per l'esempio precedente: 10.40.2.2 per esxi-h0.40-vmware.gve, 10.40.2.3 per esxi-h2.40-vmware.gve, 10.40.2.4 per esxi-h3.40-vmware.gve e 10.40.2.5 per esxi-h1.40-vmware.gve):

Configura il pool di indirizzi IP: a seconda che le allocazioni IP siano contigue o meno, specifica il pool utilizzando intervalli continui o indirizzi IP espliciti:

Intervalli IP continui:

"includeIpAddressRanges": [
  {
    "startIpAddress": "10.40.2.2",
    "endIpAddress": "10.40.2.5"
  }
]

Indirizzi IP non continui:

"includeIpAddress": [
  "10.40.2.2",
  "10.40.2.3",
  "10.40.2.4",
  "10.40.2.5"
]

Pre-ordina l'array hostSpecs in modo che gli host vengano visualizzati in ordine crescente in base agli indirizzi IP allocati:

"hostSpecs": [
  {
    "hostname": "esxi-h0.40-vmware.gve"
  },
  {
    "hostname": "esxi-h2.40-vmware.gve"
  },
  {
    "hostname": "esxi-h3.40-vmware.gve"
  },
  {
    "hostname": "esxi-h1.40-vmware.gve"
  }
]

Opzione 2: riconfigura le NIC dinamiche durante l'espansione del dominio o del cluster del workload

Quando esegui il deployment di un dominio workload VI o espandi un cluster utilizzando SDDC Manager, riconcilia le NIC dinamiche vMotion e vSAN con gli indirizzi IP di runtime assegnati da VCF:

Esegui il provisioning degli host ESXi bare metal in SDDC Manager e vCenter Server e avvia il workflow di creazione del dominio o del cluster del workload. Consenti al workflow di essere messo in pausa o di non riuscire nella fase di verifica della connettività vSAN e vMotion.
Recupera gli indirizzi IP di runtime allocati da VCF utilizzando il database di SDDC Manager o l'API REST di SDDC Manager (oppure esamina gli adattatori VMkernel nel client vSphere):
- Query sul database VCF (eseguita sull'appliance SDDC Manager):
```
psql -h localhost -U postgres -d platform -c "select * from host;"
```
- API REST di SDDC Manager:
```
curl -u ADMIN_USER:ADMIN_PASSWORD \
   -X GET https://SDDC_MANAGER_FQDN/v1/hosts
```
  Prima di eseguire il comando curl, sostituisci quanto segue:
  - ADMIN_USER: il tuo nome utente amministratore di SDDC Manager.
  - ADMIN_PASSWORD: la password dell'amministratore di SDDC Manager.
  - SDDC_MANAGER_FQDN: il nome di dominio completo o l'indirizzo IP della tua appliance SDDC Manager.
Elimina prima la NIC dinamica (nic0.VLAN_ID) non corrispondente su tutti gli host ESXi interessati. Devi completare tutte le eliminazioni delle NIC dinamiche su tutti gli host prima di aggiungere nuovamente le interfacce; in caso contrario, Compute Engine rifiuta l'aggiunta dell'interfaccia con un conflitto di indirizzi IP se un altro host detiene ancora l'indirizzo IP di destinazione:
```
gcloud compute instances network-interfaces delete HOST_INSTANCE_NAME \
   --zone=ZONE \
   --network-interface=nic0.VLAN_ID \
   --project=PROJECT_ID
```
Dopo aver eliminato tutte le NIC dinamiche non corrispondenti su tutti gli host, aggiungi nuovamente la NIC dinamica (nic0.VLAN_ID) su ogni host con l'indirizzo IPv4 esatto assegnato da VCF.

Nota: il flag --private-network-ip accetta un indirizzo IPv4 o il nome di una risorsa di indirizzo IP interno prenotato. Se utilizzi indirizzi IP prenotati, specifica l'indirizzo IP prenotato esistente che corrisponde all'indirizzo IP assegnato da VCF, originariamente prenotato per un altro host. Non eliminare o ricreare le risorse degli indirizzi IP interni prenotati.
```
gcloud compute instances network-interfaces add HOST_INSTANCE_NAME \
   --zone=ZONE \
   --parent-nic-name=nic0 \
   --vlan=VLAN_ID \
   --subnetwork=SUBNET_NAME \
   --no-address \
   --private-network-ip=VMWARE_ASSIGNED_IP \
   --project=PROJECT_ID
```
Prima di eseguire i comandi precedenti, sostituisci quanto segue:
- HOST_INSTANCE_NAME: il nome dell'istanza ESXi bare metal in Compute Engine.
- ZONE: la zona in cui si trova l'istanza bare metal.
- VLAN_ID: l'ID VLAN mappato alla NIC dinamica (ad esempio, 2 per vSAN o 3 per vMotion), che forma il nome dell'interfaccia nic0.VLAN_ID.
- SUBNET_NAME: il nome della subnet vSAN o vMotion.
- VMWARE_ASSIGNED_IP: l'indirizzo IPv4 o il nome della risorsa dell'indirizzo IP interno prenotato esistente che corrisponde all'indirizzo IP assegnato all'adattatore VMkernel dell'host da VCF.
- PROJECT_ID: l'ID del tuo progetto Google Cloud .
Riprendi e completa l'attività di deployment del cluster in SDDC Manager.

Mancata corrispondenza dell'indirizzo IP NSX-TEP sugli host

Durante la preparazione del nodo di trasporto NSX, NSX Manager alloca gli indirizzi IP del Transport Endpoint (TEP) (vmk10 o vmk3) dal pool di IP NSX configurato (DHCP non è supportato nelle subnet VPC Google Cloud per le NIC dinamiche). Poiché NSX Manager assegna gli indirizzi IP dal pool in modo casuale, l'indirizzo IP TEP configurato sull'adattatore vmk10 di un host ESXi potrebbe non corrispondere all'indirizzo IP inizialmente preallocato sulla NIC dinamica NSX-TEP (nic0.TEP_VLAN_ID) dell'host.

Soluzione alternativa: al termine della configurazione del nodo di trasporto NSX, aggiorna le NIC dinamiche NSX-TEP sui tuoi host in modo che corrispondano agli indirizzi IP TEP assegnati da NSX:

Controlla l'indirizzo IP TEP assegnato a ogni host ESXi nell'interfaccia utente di NSX Manager (vai a Sistema > Fabric > Host in VCF 9.1) o nel client vSphere.

Rimuovi tutte le istanze host bare metal dal gruppo di endpoint di rete (NEG) NSX prima di modificare le interfacce di rete NSX-TEP:

gcloud compute network-endpoint-groups update NSX_NEG_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --remove-endpoint="instance=HOST_INSTANCE_NAME"

Elimina prima la NIC dinamica NSX-TEP (nic0.TEP_VLAN_ID) su tutti gli host interessati. Completa tutte le eliminazioni di NIC dinamiche NSX-TEP su tutti gli host prima di aggiungere nuovamente le interfacce per evitare conflitti di indirizzi IP tra gli host:
```
gcloud compute instances network-interfaces delete HOST_INSTANCE_NAME \
    --zone=ZONE \
    --network-interface=nic0.TEP_VLAN_ID \
    --project=PROJECT_ID
```
Dopo aver eliminato tutte le NIC dinamiche NSX-TEP su tutti gli host, ricrea l'interfaccia nic0.TEP_VLAN_ID su ogni host con l'indirizzo IPv4 TEP assegnato da NSX Manager.

Nota: il flag --private-network-ip accetta un indirizzo IPv4 o il nome di una risorsa di indirizzo IP interno prenotato. Se utilizzi indirizzi IP riservati, specifica l'indirizzo IP riservato esistente che corrisponde all'indirizzo IP TEP assegnato da NSX, originariamente riservato per un altro host. Non eliminare o ricreare le risorse degli indirizzi IP interni prenotati.
```
gcloud compute instances network-interfaces add HOST_INSTANCE_NAME \
    --zone=ZONE \
    --parent-nic-name=nic0 \
    --vlan=TEP_VLAN_ID \
    --subnetwork=TEP_SUBNET_NAME \
    --no-address \
    --private-network-ip=TEP_IP_ADDRESS \
    --project=PROJECT_ID
```

Ricollega tutte le istanze host bare metal al NEG NSX:

gcloud compute network-endpoint-groups update NSX_NEG_NAME \
    --zone=ZONE \
    --project=PROJECT_ID \
    --add-endpoint="instance=HOST_INSTANCE_NAME"

Prima di eseguire i comandi precedenti, sostituisci quanto segue:

NSX_NEG_NAME: il nome del NEG a livello di zona NSX.
HOST_INSTANCE_NAME: il nome dell'istanza ESXi bare metal.
ZONE: la zona in cui si trova l'istanza bare metal.
TEP_VLAN_ID: l'ID VLAN assegnato alla NIC dinamica NSX-TEP (ad esempio, 4), che forma il nome dell'interfaccia nic0.TEP_VLAN_ID.
TEP_SUBNET_NAME: il nome della tua subnet NSX-TEP.
TEP_IP_ADDRESS: l'indirizzo IPv4 TEP o il nome della risorsa dell'indirizzo IP interno prenotato esistente che corrisponde all'indirizzo IP assegnato all'host ESXi (vmk10) da NSX Manager.
PROJECT_ID: l'ID del tuo progetto Google Cloud .

Mancata corrispondenza della MTU VDS con i frame jumbo VPC di Google Cloud

Le reti VPCGoogle Cloud supportano un'unità massima di trasmissione (MTU) fino a 8896 byte per i frame jumbo. Per impostazione predefinita, VCF configura vSphere Distributed Switch (VDS), adattatori VMkernel (vSAN, vMotion e NSX-TEP) e profili dei nodi di trasporto NSX con un'MTU di 9000 byte. Se un host invia pacchetti di dimensioni superiori a 8896 byte tramite l'underlay VPC, la rete VPC ignora i frame di dimensioni eccessive, causando errori di replica vSAN, timeout di vMotion o problemi di frammentazione dell'overlay NSX.

Soluzione: configura la MTU su 8896 byte nella specifica del deployment di VCF prima dell'attivazione o aggiorna le impostazioni della MTU in vCenter Server e NSX Manager dopo il deployment:

Aggiorna l'MTU del VDS nel client vSphere

Nel client vSphere, vai a Networking e seleziona lo switch distribuito vSphere per il tuo cluster.
Fai clic con il tasto destro del mouse sullo switch distribuito e seleziona Settings (Impostazioni) > Edit Settings (Modifica impostazioni).
Fai clic sulla scheda Avanzate, imposta MTU (byte) su 8896 e fai clic su OK.

Aggiorna gli adattatori VMkernel e i profili NSX

Per ogni host ESXi nel cluster, vai a Configura > Networking > Adattatori VMkernel, modifica gli adattatori vMotion (vmk1) e vSAN (vmk2) e imposta MTU su 8896.
Nella UI di NSX Manager, vai a System > Fabric > Profiles > Uplink Profiles, modifica i profili di uplink host e perimetrale attivi e imposta MTU su 8896 (e imposta la MTU del fabric fisico globale in System > Fabric > Settings > Global Fabric Settings su 8896).

Modalità switch virtuale NSX

In VCF 9.x, la modalità predefinita dello switch virtuale configurata in NSX Manager è impostata su Enhanced Datapath Standard, che non è supportata sugli host VMware Solution.

Soluzione alternativa: nella sezione NSX del programma di installazione di VCF, deseleziona la casella di controllo Applica la modalità di switch virtuale predefinita configurata in NSX Manager e, per Modalità operativa, seleziona Standard, come mostrato nello screenshot seguente (fai clic per ingrandire):

Configurazione NSX che mostra la casella di controllo della modalità di switch virtuale predefinita deselezionata e la modalità operativa impostata su Standard.

Errore di risoluzione DNS con il forwarding in entrata di Cloud DNS su subnet di trasmissione di livello 2

Quando abiliti una policy dei server in entrata di Cloud DNS sulla rete VPC che ospita i nodi della tua soluzione VMware, Cloud DNS prenota automaticamente un indirizzo IP DNS_RESOLVER interno in ogni subnet regionale nella rete VPC. Sono incluse la subnet di gestione ESXi non codificata (MGMT) e le subnet NIC dinamiche con tag VLAN (vSAN, vMotion e NSX-TEP) che utilizzano la trasmissione del protocollo di risoluzione degli indirizzi (ARP) di livello 2 e l'apprendimento MAC personalizzato (ARP_BROADCAST_PRIMARY_RANGE_WITH_LEARNING).

Se configuri gli host ESXi o le appliance di gestione VCF per eseguire query su un indirizzo IP DNS_RESOLVER dalla stessa subnet o da qualsiasi subnet di nodi abilitata per la trasmissione ARP e l'apprendimento MAC, l'host tratta l'indirizzo IP dell'agente di inoltro come un nodo adiacente di livello 2 locale e invia richieste di trasmissione ARP per risolvere il suo indirizzo MAC. Poiché l'agente di forwarding in entrata di Cloud DNS è un servizio di proxyGoogle Cloud anziché un endpoint di livello 2 sulla subnet, non risponde alle richieste ARP né partecipa all'apprendimento MAC personalizzato. Di conseguenza, la voce adiacente rimane incompleta (esxcli network ip neighbor list) e le query DNS (nslookup) scadono.

Lo stesso comportamento si applica agli endpoint Private Service Connect (PSC) (GCE_ENDPOINT), come l'endpoint utilizzato per connettersi al deposito offline regionale. Se esegui il deployment di un endpoint Private Service Connect in una subnet di nodi con broadcast ARP di livello 2 o con tag VLAN, la risoluzione ARP per l'indirizzo IP dell'endpoint non va a buon fine e le connessioni al repository offline scadono.

Soluzione alternativa: utilizza una subnet standard esistente (non VLAN, non broadcast di livello 2) nella stessa regione e nella stessa rete VPC o crea una subnet standard dedicata, se non esiste già, per l'indirizzo IP Cloud DNS in entrataDNS_RESOLVER (e per l'endpoint del repository offline di Private Service Connect). Se nella regione esiste già una subnet standard, Cloud DNS ha già allocato un indirizzo IP DNS_RESOLVER in quella subnet che puoi utilizzare:

Se non esiste già una subnet standard nella stessa regione e nella stessa rete VPC, crea una subnet standard dedicata senza specificare il flag --resolve-subnet-mask. Non collegare questa subnet alle interfacce principali dei nodi o alle NIC dinamiche con tag VLAN:
```
gcloud compute networks subnets create DNS_SUBNET_NAME \
    --network=VPC_NAME \
    --region=REGION \
    --range=DNS_SUBNET_RANGE \
    --project=PROJECT_ID
```
Recupera l'indirizzo IP DNS_RESOLVER prenotato da Cloud DNS nella subnet standard:
```
gcloud compute addresses list \
    --filter="purpose=DNS_RESOLVER AND subnetwork:DNS_SUBNET_NAME" \
    --project=PROJECT_ID
```
Prima di eseguire i comandi precedenti, sostituisci quanto segue:
- DNS_SUBNET_NAME: il nome della subnet standard esistente o dedicata per il forwarding in entrata di Cloud DNS.
- VPC_NAME: il nome della tua rete VPC.
- REGION: la regione Google Cloud in cui si trovano i nodi bare metal.
- DNS_SUBNET_RANGE: un intervallo CIDR IPv4 primario non sovrapposto per la subnet standard dedicata (ad esempio, 10.0.100.0/28).
- PROJECT_ID: l'ID del progetto Google Cloud.
Configura gli host ESXi, le appliance di gestione VCF e il toolkit della soluzione VMware (dns_server in config.json) in modo che utilizzino l'indirizzo IP DNS_RESOLVER di DNS_SUBNET_NAME anziché gli indirizzi IP DNS_RESOLVER associati alle subnet di gestione ESXi (MGMT), vSAN, vMotion o NSX-TEP.