Some useful commands to configure zoning on a Brocade switch FC

Dal momento che Java non sta più funzionando sui nuovi browser è il momento di prendere confidenza con la command line interface (CLI) degli switch Fibre Channel (FC) Brocade.

Di seguito alcuni comandi utili per effettuare lo zoning direttamente da linea di comando.

1. Verifica dell'attuale configurazione e delle informazioni necessarie per la configurazione.  
   
   

   #BR5460-SWFC1:admin> switchshow

   Il precedente comando switchshow permette di vedere il nome della zona configurata e le WWN delle nuove HBA connesse.

   #BR5460-SWFC1:admin> cfgshow

   Eseguire il comando cfgshow per visualizzare la configurazione e vedere come sono attualmente configurate le zone.
2. Controllo della nameserver zone

   #BR5460-SWFC1:admin> nsshow
   ......
   #BR5460-SWFC1:admin> zoneshow

   Permette di verificare il nome delle Zona configurata sul device.
3.  Creare l'Alias
   
   
   

   #BR5460-SWFC1:admin> alicreate "ESXi01_B","50:00:08:XX:XX:XX"
   #BR5460-SWFC1:admin> alicreate "ESXi02_B","50:00:08:XX:XX:XX"
   #BR5460-SWFC1:admin> alicreate "HUS110_1A","50:06:0e:XX:XX:XX"
   #BR5460-SWFC1:admin> alicreate "HUS110_1D","50:06:0e:XX:XX:XX"

   alicreate permette di dare un nome "alias" alla WWN; da rendere più agevole
   
4. Creare una Zona

   #BR5460-SWFC1:admin> zonecreate "ESXi01_HUS110_1A","ESXi01_B;HUS110_1A"
   #BR5460-SWFC1:admin> zonecreate "ESXi01_HUS110_1D","ESXi01_B;HUS110_1D"
   #BR5460-SWFC1:admin> zonecreate "ESXi02_HUS110_1A","ESXi02_B;HUS110_1A"
   #BR5460-SWFC1:admin> zonecreate "ESXi02_HUS110_1D","ESXi02_B;HUS110_1D"
   

   Il comando zonecreate crea una zona in cui associa (utilizzando l'alias precedentemente creato) la WWN dell'host VMware alla WWN della controller dello storage.
   
   Queste zone vanno quindi aggiunte alla configurazione attiva ...
5. Creare una Zone Configuration o Aggiungere una Zona ad una Configurazione esistente
   
   Se la "zone config" non esiste occorre crearne una oppure aggiungere quanto precedentemente creato nel punto 4 alla zona di default.
   In questo caso ne creiamo una nuova, nel seguente modo:

   #BR5460-SWFC1:admin> cfgCreate "FCSW1","ESXi01_HUS110_1A;ESXi01_HUS110_1D;ESXi02_HUS110_1A"

   nel precedente comando ho volutamente omesso di aggiungere alla configurazione la zona "ESXi02_HUS110_1D" in modo da poter utilizzare il comando indicato di seguito

   #BR5460-SWFC1:admin> cfgadd "FCSW1","ESXi02_HUS110_1D"

   cfgadd permette di aggiungere una zona ad una configurazione già esistente.
6. Salviamo la configurazione
   
   
   

   #BR5460-SWFC1:admin> cfgsave

   Il comando cfgsave salva la configurazione in modo permanente sullo switch, alla richiesta di procedere con il salvataggio della configurazione digitare "yes" e confermare.
7. Attivare la configurazione
   
   
   La configurazione precedentemente salvata non è ancora attiva, è necessario attivarla con il seguente comando

   #BR5460-SWFC1:admin> cfgenable FCSW1

Abbiamo quindi terminato ed attivato la nuova configurazione sullo switch.

Di seguito altri comandi che potrebbero essere utili:

1. Disabilitare la zona
   
   

   #BR5460-SWFC1:admin> cfgdisable

   Il comando cfgdisable disabilita la corrente zona.
   
   
2. Ripulire la Zona
   
   

   #BR5460-SWFC1:admin> cfgclear

   Utilizzare questo comando (cfgclear) per cancellare tutte le informazioni presenti sul "transaction buffer". Tutti gli oggetti presenti nel "transaction buffer" vengono cancellati.
   
   

Maggiori dettagli possono essere reperiti dalla "Command Reference Guide"

Hardware configuration of host is incompatible. Check scan results for details.

Disclaimer: The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a reader's responsibility. Use it at you own risk.

Giornata di upgrade .... quest'oggi devo aggiornare una serie di lame Blade di un Hitachi Compute Blade 520HA1.

Ho caricato la nuova ISO custom  ESXi-6.5.0-4564106-custom-hitachi-0100 nel VUM del nuovo vCenter Server 6.5.0 (build-7119157) ed ho fatto ma mia bella "Baseline" e l'ho attaccata all'host come indicato di seguito.

A questo punto non resta che lanciare lo "Scan for Updates..." 

Tutto sembra OK, procedo con il mettere in Maintenance il nodo e con il "Remediate..."

Parte la procedura di "Remediation" e dopo qualche secondo appare il seguente messaggio di errore....

Hardware configuration of host <Hostname> is incompatible. Check scan results for details.

Mi accorgo di quanto segue:
- lo script di precheck fallisce con un errore "unknown" ....
- e che la Acceptance Level è impostata a "Partner"

vado quindi a verificare e cercare maggiori informazioni all'interno dei log.

Mi connetto al vCenter (tramite putty)  ed entro diretto nella cartella dove sono il log relativi all'Update Manager ...

# cd /var/log/vmware/vmware-updatemgr/vum-server/hostUpgrade

verifico quindi i file sulla directory con

# ls -ltr

alla ricerca dell'ultimo file modificato per l'host che sto upgradando. Nel mio caso "vua-<hostname>-9.log.gz"

Lo edito alla ricerca di informazioni :

# gunzip -c vua-<hostname>-9.log.gz | less

Provando a ricercare per "ERROR", salta fuori una riga interessante 

Mi connetto quindi all'Host e verifico ulteriormente il livello di "acceptance"

# esxcli software acceptance get

e lo modifico come indicato di seguito

# esxcli software acceptance set --level=VMwareAccepted

Verifico quindi che il valore sia stato impostato correttamente, e lancio nuovamente il "Remediate..." 

Questa volta il comportamento sembra leggermente diverso ......

... il classico comportamento dell'Update Manager.

Dopo aver atteso per un pò, in quanto l'host in fase di upgrade effettua un paio di reboot .... di seguito il risultato:

Host aggiornato con successo.

PS: Prima di effettuare l'operazione indicata sopra (soprattutto se stiamo parlando di un ambiente di produzione) verificare bene tutte le matrici di compatibilità VMware. 

'UserVars.VshieldVsmConnetionInfo' is invalid or exceeds the maximum number of characters permitted

A seguito di un upgrade ho riscontrato il seguente messaggi di errore:

'UserVars.VshieldVsmConnectionInfo' is invalid or exceeds the maximum number of characters permitted

Cercando in rete ho trovato la seguente KB2149015 che però non ha risolto il mio problema.

Soluzione 

Verificando via CLI ho riscontrato che il VIB  "epsec-mux" non erano stato correttamente aggiornato ..

Per la risoluzione procedere come indicato in un mio precedente post "UserVars.UsvmConfig is invalid or exceeds the maximum number of characters permitted"

Check SHA1 Checksum in Mac OS X

Come per la verifica md5, è possibile verificare il checksum sha1 da linea di comando con il mac tramite il comando "shasum"

# shasum <path>/to/file.name 

di seguito un esempio:

Verifichiamo quindi con il file di testo fornito con il pacchetto scaricato.

Se la sequenza di numeri coincide, significa che il file scaricato è corretto.

'UserVars.UsvmConfig' is invalid or exceeds the maximum number of characters permitted

In fase di installazione delle Guest Introspection su ambiente NSX (ver. 6.2.4-4292526) ed ESXi (ver. 6.0.0 build-5572656) ho ottenuto il seguente comportamento:

- Guest Introspection installata ed avviata correttamente;
- Tuttavia analizzando lo status:

Il VIB epsec-mux responsabile della comunicazione tra ESXi e GI appliance non viene installato.
Analizzando meglio i messaggi di errore nei task, osserviamo uno strano messaggio di errore:

'UserVars.UsvmConfig' is invalid or exceeds the maximum number of characters permitted

Soluzione 

La soluzione è quella di installare manualmente il VIB scaricandolo direttamente dal NSX Manager a questo path:

https://<nsx manager ip>/bin/epsec/6.2.4/vibs/6.0/offlinebundle/vShield-Endpoint-Mux-6.0.0esx60-3796715.zip

procedere con l'installazione manuale:

Verifichiamo che il VIB sia presente:

E magicamente tutto prende a funzionare correttamente.


NOTE:
Un interessante link che mi ha aiutato per la risoluzione di questo problema è il seguente "VMware NSX Component Build Matrix"

Test connettività con NetCat

Se abbiamo la necessità di verificare la connettività tra hosts; ESXi mette a disposizione il comando nc che permette di verificare se l'host remoto è in ascolto sulla porta che stiamo tentando di contattare.

nc -z <destination-ip> <destination-port>

Di seguito un esempio:

I parametri a disposizione con nc sono molteplici, per maggiori dettagli rimandiamo alle "man pages" per sistemi Linux e per sistemi MacOSX.

Problema con la Management Network (vmk0) su vDS

Disclaimer: The procedure described below is not officially supported by VMware. Use it at you own risk.

La problematica che andiamo a descrivere si è presentata su un ambiente vSAN a 4 nodi. 

Ogni nodo dotato di schede di #2 schede rete a 10GB dove c'è configurato un unico vDS (ar-ds-vSAN) dove gli Uplink sono configurati in LACP. Ovviamente :-) la Management Interface e l'interfaccia di vSAN sono state migrate all'interno del Distributed Virtual Switch 

A seguito di una problematica sul Cluster, ci si è trovati a dover eseguire una KB che indicava di mettere in "Maintenance Mode" il nodo ("Ensure data accessibility from other hosts"), trascinare il nodo al di fuori dal Cluster, Disconnetterlo, rimuoverlo dall'inventario e quindi aggiungere nuovamente al Datacenter il nodo; ecc. ecc.

A seguito della rimozione del nodo dal vCenter abbiamo anche effettuato un riavvio del nodo.

In condizioni normali il nodo a seguito del riavvio ritorna raggiungibile ed è quindi possibile continuare le operazioni aggiungendolo al Cluster e riconfigurare il vDS.

Noi ci siamo trovati nelle condizioni che il nodo ESXi non era più raggiungibile sulla Managment Interface (vmk0) tuttavia la parte vSAN risultava essere integra (descriverò i controlli al cluster vSAN in un'altro post).

Ci siamo connessi tramite iDRAC per verificare le condizioni del nodo, ed abbiamo riscontrato lanciando il comando di seguito:

# esxcli network ip interface list

che la vmk0 sembra essere disabilitata (Enabled = false), MTU=0 e Port ID = 0. 

Proviamo quindi a riabilitare l'interfaccia (comando di seguito) sperando che le informazioni relative al DVS siano ancora disponibili e presenti sul nodo ESXi

# esxcli network ip interface set -e true -i vmk0

Otteniamo il messaggio di errore di seguito "Operation not permitted" 

indagando all'interno dei log  

# cat /var/log/vmkernel.log

osserviamo...  

che:

• il sistema tenta di riconnettere l'interfaccia alla porta 10
• ma i CID non "matchano"  (OLD VDS Connection = 117018537 ... nuovo 2093141832) 

risultato non è possibile ABILITARE la vmk0.

Soluzione:

Non ci resta che rimuovere la Management Network vmkernl (vmk0) e ricreala utilizzando la "command line" ESXi direttamente dalla console.

1. Prendere nota dell'attuale IP, la netmask ed il Default GW associati alla vmk0

                        IP: 10.0.100.232

          NETMASK: 255.255.255.0

         Default GW: 10.0.100.1
 

# esxcli network ip interface ipv4 get

Nel caso non dovesse venir visualizzata la riga vmk0 lanciare il comando 

# esxcfg-vmknic -l | grep vmk0

e prendere nota ....

2. Conoscere il Port ID sul quale era agganciato il vmk0. Nel nostro caso possiamo vederlo dai log in fase di abilitazione della vmk0.

Possiamo anche verificarlo (in modo meno preciso) andando a vedere i Port ID relativi al "Port Group" (relativo) tramite Web client  

e quindi matcharli con quelli associati all'host

# esxcfg-vswitch -l

come possiamo vedere la porta 10 non è associata a nessuna NIC (ma associata all'host).

3. Eliminare l'interfaccia vmk0
Rimuovendo l'interfaccia vmk0 rimuoviamo ogni riferimento non corretto sull'host.

# esxcli network ip interface remove --interface-name=vmk0

di seguito l'output dei log

4. Creare la nuova interfaccia vmk0

Ricreiamo l'interfaccia vmk0 nel seguente modo (fornendo il DVS name ed il Port ID precedentemente identificato) :

# esxcli network ip interface add --interface-name=vmk0 --dvs-name=ar-ds-vSAN --dvport-id=10

verifichiamo:

# esxcfg-vswitch -l

5. Configurare l'IP verificare il Default GW

Configurata l'interfaccia dobbiamo associare l'indirizzo IP ed impostare il Default GW, nel seguente modo

# esxcli network ip interface ipv4 set --interface-name=vmk0 --ipv4=10.0.100.232 --netmask=255.255.255.0 --type=static

ora il Default GW

# esxcfg-route -a default 10.0.100.1 # esxcfg-route

6. Impostare l'interfaccia come Management

# esxcli network ip interface tag add -i vmk0 -t Management

In questo modo il nodo ritorna nuovamente disponibile.

7. Verifica..

Lanciamo il comando comando di seguito:

# esxcli network ip interface list

That's IT