Pagine

martedì 17 aprile 2018

Disconnect all CD Drives on all VMs of the Cluster

Problema
Spesso capita che gli utenti a seguito di installazioni e/o aggiornamenti lascino i CD agganciati alle VM, e questo può causare dei problemi. In caso di DRS attivo in modalità "Fully Automated" VMs con CD-ROM  attivi non migrano da un host all'altro; stessa condizione quando si ha la necessità di mettere in "Maintenance" un nodo.


Soluzione
Per risolvere il problema, si è deciso di creare due script in powershell. Il primo script "ListVMsWithDrive.ps1" per ottenere la lista delle VMs che ha i CD-ROM connessi producendo come output un file di testo che può essere editato ed utilizzato come input del successivo script "DisconnectDrive.ps1" per la rimozione dei CD-ROM dalle VM contenute nel file.

Di seguito lo script "ListVMsWithCDDrive.ps1" per avere una lista delle VMs con i CD-ROM connessi.

########################################################################################
#  File  : ListVMsWithCDDrive.ps1
#  Author: Lorenzo Moglie
#  Date  : 17.04.2018
#  Description : The output of the script is a txt file, containing the list of VMs with 
#                the CD-Rom configured for that cluster
#######################################################################################
$vCenter = "<VIRTUALCENTER>"
$CLS = "<CLUSTER-NAME>"
$User = "<USERNAME>"
$Password = "<PASSWORD>"
$VMlist = ".\VMlist.txt"
Connect-VIServer -Server $vCenter -User $User -password $Password | Out-Null
#List of VMs with CD-ROM connected for the whole vCenter
#Get-VM | Get-CDDrive | Where {$_.ISOPath -ne $null} | Sort-Object -Unique ParentID | FT -AutoSize Parent, IsoPath 
#List of VMs with CD-ROM connected only for the specified Cluster - Output on TXT file
#The file can be used as input od the script DisconnectDrive.ps1
Get-VM -Location $CLS  | Get-CDDrive | Where {$_.ISOPath -ne $null} | Sort-Object -Unique ParentID | FT -AutoSize Parent | Out-File $VMlist
#List of VMs with CD-ROM connected - Output on TXT file 
#The file can be used as input od the script DisconnectDrive.ps1
#Get-VM | Get-CDDrive | Where {$_.ISOPath -ne $null} | Sort-Object -Unique ParentID | FT -AutoSize Parent | Out-File $VMlist
Disconnect-VIServer * -Confirm:$false 

Di seguito lo script "DisconnectDrive.ps1" per disconnettere i CD-ROM


########################################################################################
#  File  : DisconnectDrive.ps1
#  Author: Lorenzo Moglie
#  Date  : 17.04.2018
#  Description : This script disconnect the CD-ROM from the VMs present in the input 
#                file
#######################################################################################
$vCenter = "<VIRTUALCENTER>"
$CLS = "<CLUSTER-NAME>"
$User = "<USERNAME>"
$Password = "<PASSWORD>"
$VMlist = ".\VMlist.txt"
Connect-VIServer -Server $vCenter -User $User -password $Password | Out-Null
foreach($VM in Get-Content $VMlist) {
    if ($VM -ne $null) {
        if (($VM.TrimEnd() -contains "Parent") -or ($VM.TrimEnd() -contains "------")){       
        } else {
            Get-VM -Name $VM.TrimEnd() |Get-CDDrive | Where {$_.ISOPath -ne $null} | Set-CDDrive -NoMedia -Confirm:$false 
        }
    }
}
Disconnect-VIServer * -Confirm:$false 
Si è deciso di creare due script proprio per avere la possibilità di decidere su quale VM andare o meno a rimuovere il CD-ROM.

Se non si ha questo tipo di necessità e si vuole disconnettere il CD-ROM sull'intero DataCenter è possibile lanciare il comando di seguito:

 Get-VM | Get-CDDrive | Where {$_.ISOPath -ne $null} | Set-CDDrive -NoMedia -Confirm:$false 



.

sabato 14 aprile 2018

MaintenanceMode - This action is not available for any of the selected objects at this time

Il nodo non ad entrare in "Maintenance Mode" in quanto delle VMs non riescono ad essere migrate; ne in modalità automatica ne in modalità manuale ottenendo il messaggio di errore  "This action is not available for any of the selected objects at this time"


Cercando un pò in giro sul web ho visto la KB VMware (2087163) che nel mio caso non ha risolto in quanto l'utente che sto utilizzando per la migrazione ha tutti i permessi necessari.

Analizzando le due VMs in questione, ho riscontrato che non ci sono "CD ROM" e/o snapshot che ne potrebbero limitare la vMotion...... dando un'occhiata al file log del vmkernel dove gira la VM e filtrando per il nome della VM


riscontro dei stani messaggio dove i file della VM sembrano essere "Busy" e/o bloccati da una VM "VeeamProxy" proxy dell'infrastruttura di backup Veeam.

Edito le impostazioni della VM "VeeamProxy", per verificare se fossero presenti i dischi aggiunti in hot-add della prima Virtual Machine da migrare. Nessun disco diverso da quelli originali della VM "VeeamProxy" stessa. 

SOLUZIONE:
Provo quindi a lanciare un nuovo JOB di backup dalla console Veeam relativo alla VM... e terminato il backup la Virtual Machine è migrata da sola.
La stessa cosa non ha funzionato per entrambe le VM. Quindi, ripensando a come ho risolto per la prima VM, per la seconda decido di creare una snapshot temporanea. Rimossa la snapshot e riprovato la migrazione manuale la VM è migrata senza errori ed il nodo è entrato in maintenance.


venerdì 13 aprile 2018

ESXi may take long time to boot - Perennialy Reserved

Il riavvio dei nodi ESXi risultano essere estremamente lento; un nodo impiega a salire circa 45 minuti rimanendo in uno stato apparentemente frizzato come nell'immagine seguente "vmw_satp_alua"...



terminato l'avvio verifico che all'host sono mappate ben 69 LUN di tipo VMFS e 24 LUN RDM (Allocate a dei cluster Microsoft :-) ).

Come indicato dalla KB VMware (1016106) "ESXi/ESX hosts with visibility to RDM LUNs being used by MSCS nodes with RDMs may take a long time to start or during LUN rescan" si è deciso di realizzare lo script (in powershell) seguente per identificare le LUN Raw e marcarle su ogni host che fa parte del cluster come perennialy-reserved.

#------------------------------------------------------
# Il seguente script viene fornito "AS IS"
# Author: Lorenzo Moglie
#------------------------------------------------------

$vCenter = "<VIRTUALCENTER>" #<== Inserire FQDN del vCenter
$CLS = "<CLUSTER NAME>" #<== Il nome del cluster 
$User = "<USERNAME>" 
$Password = "<PASSWORD>"
$PerenniallyReserved = $true #<== $true=per mapparle ; $false=per smappare le LUN

#Connessione al vCenter
Connect-VIServer -Server $vCenter -User $User -password $Password | Out-Null
#Identifichiamo tutte le LUN RDMs che sono configurate su questo cluster
$RAWDisks = Get-VM -Location $CLS | Get-HardDisk -DiskType "RawPhysical","RawVirtual" | Select ScsiCanonicalName

#Identifichiamo gli Hosts ESXi che fanno parte del cluster
$Hosts = Get-VMHost -Location $CLS

foreach($ESXi in $Hosts) {
    $ESXi
    $myesxcli = Get-EsxCli -VMHost $ESXi
    foreach($RDM in $RAWDisks){
        #Comando esxcli come da KB(1016106)
        #esxcli storage core device setconfig -d naa.id --perennially-reversed=true
        $myesxcli.storage.core.device.setconfig($false, ($RDM.ScsiCanonicalName), $PerenniallyReserved)
    }
    echo "------------------------------------------------------"
}

Disconnect-VIServer * -Confirm:$false

Lanciato lo script, i server si riavviano in 10 minuti.

venerdì 6 aprile 2018

MacOS High Sierra: trackpad and keyboard not working. Fixed

Il MAC non risponde più :-( il trackpad e la tastiera sembrano non voler accettare i comandi in nessun modo.... hanno smesso di funzionare.
L'unico tasto funzionante è quello dello spegnimento. Ricercando un pò su google scopro che non sono l'unico ad avere questo problema.  Il mio MAC è completamente bloccato esattamente come mostrato da questo utente su youtube.

SOLUZIONE:

Nel mio caso la soluzione è stata quella di avviare in modalità recovery il mac tenendo premuti i tasti CMD + R fino a che non si sente il classico suono di avvio del mac (chime). Dopo di che aprire una console Terminal e digitare


[-bash-3.2# nvram -c
per pulire la NVRAM/PRAM e quindi provare a riavviare il dispositivo. 

Se il device no parte ancora, riavviare in modalità recovery, eseguire il reset della NVRAM via terminal come indicato in precedenza ed effettuare un controllo del disco aprendo l'interfaccia di check "S.O.S." del disco "Utility Disco" come indicato dall'immagine seguente:



Nel mio caso ottengo dei messaggi di errore che non mi permettono di verificare correttamente il disco.

Decido quindi di procedere ad effettuare il check del disco via command line da Terminal.

- Apro il terminal e lancio (nel mio caso) il comando ...


[-bash-3.2# fsck_hfs /dev/disk0s2

L'errore che ottengo è "Invalid node structure" per il quale il sistema non è in grado di verificare completamente il volume del mio MAC.

A questo punto decido, tramite lo stesso comando "fsck_hfs" di ricostruire il catalogo btree... come di seguito:


[-bash-3.2# fsck_hfs -r /dev/disk0s2


ATTENZIONE: Nell'effettuare questa operazione il disco non deve essere montato.

Terminata l'operazione di ricostruzione del catalogo, mio caso, fortunatamente con successo riavvio il MAC ed il sistema riparte correttamente come se nulla fosse successo.

martedì 3 aprile 2018

VCSA: 503 Service Unavailable Error Fixed

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


Problema con il vCenter che a seguito di un reboot non parte più e presenta i seguenti messaggi di errore:


503 Service Unavailable (Failed to connect to endpoint: 
[N7Vmacore4Http20NamedPipeServiceSpecE:0x7f76fce961e0] _serverNamespace = / 
_isRedirect = false _pipeName=/var/run/vmware/vpxd-webserver-pipe)
vedi sotto ...



o alternativamente a seguito di un ulteriore reboot il seguente:

503 Service Unavailable (Failed to connect to endpoint: 
[N7Vmacore4Http16LocalServiceSpecE:0x7f3dc0086970] _serverNamespace = /vsphere-client 
_isRedirect = false _port = 9090)
vedi di seguito ...



Effettuando un veloce ricerca su google; tra i primi link appare "503 service unavailable" error when connecting to vSphere Web Client che corrisponde alla KB VMware 2121043

Tuttavia dopo aver verificato quanto indicato dalla KB, non ha risolto il mio problema.

Ho deciso quindi di accedere nuovamente in SSH al vCenter Server Appliance, abilitare la shell ...


... e verificare l'occupazione dello spazio disco con il comando "df -h" ...


con grande stupore mi accorgo che la directory "/" è completamente piena. 

Cerco nuovamente in google la stringa "vmware vcenter /dev/sda3 full" e come primo link ottengo la KB 2149278 (vCenter Appliance root Partition 100% full due to Audit.log files not being rotated). 

Verifico quindi, immediatamente la cartella indicata nella KB con l'intento di eliminare qualche file di log.
Come possiamo vedere dall'immagine sotto non ci sono file da eliminare ...


Anche questa KB non ha risolto il problema.

Decido quindi di investigare sotto la cartella "/var/log/" e "/var/log/vmware/" per eliminare manualmente più file possibili.
Dopo aver eliminato svariati file "*.gz" all'interno delle directory indicate ... e lanciando nuovamente il comando "df -h" per verificarne l'effetto. Mi accorgo che lo spazio non cenna a diminuire, rimane sempre con un tasso di occupazione del 100%. Effettuo un riavvio del vCenter per verificare ... ma nulla di concreto.

Verificato anche quando indicato da Anthony Spiteri in questo link ma senza successo.

Analizzando più in dettaglio nella cartella "/var/log/"

virtualcenter:~ # cd /var/log/
virtualcenter:/var/log # ls -larth
 noto che il file "dnsmasq.log" occupa 5.2G. 




SOLUZIONE:

Eliminare il file "dnsmasq.log".


eliminato il file e lanciato nuovamente "df -h" per visionare se sia stato liberato spazio mi accorgo che lo spazio occupato è ancora del 100%.

Lo step successivo è quindi quello di riavviare l'Appliance; ed al riavvio verificare se lo spazio si è liberato ...


Spazio liberato e servizi partiti correttamente...

.

giovedì 22 marzo 2018

Host Cannot Download Files From VMware vSphere Update Manager Patch Store

Effettuando una scansione degli host ESXi dall'Update Manager del vCenter Server si è riscontrato il seguente errore:

Host cannot download files from VMware vSphere Update Manager patch store.  
Check the network connectivity and firewall setup, and check esxupdate logs for details.


All'interno dei logs in /var/log/esxupdate.log abbiamo rilevato degli errori relativi alla risoluzione DNS del nome del vCenter Server Appliance. Nel nostro caso trattandosi della VCSA 6.5 corrisponde anche al vCenter Update Manager Server. 

L'errore è:


ERROR: pycurl.error: (6, "Couldn't resolve host '<vcenter_name.fqdn >'").
Come di seguito:  


constatato anche tramite command line, l'impossibilità di risolvere correttamente il nome del vCenter Update Manager Appliance ...



abbiamo provveduto a verificare e sistemare i DNS server. 
Nel mio caso, per ragioni che non sto qui a spiegare è stato sufficiente inserire l'entry corretta nel file /etc/hosts perché tutto riprendesse a funzionare correttamente.



martedì 20 marzo 2018

iSCSI LUNs Connected but Datastore Not Visible/Available

Strana problematica sulla connettività iSCSI. Le LUN vengono correttamente riconosciute e montate su tutti gli host del cluster, ad eccezione di un host, nel quale sembrano essere riconosciute/agganciate ma non montate come DataStore come possibile vedere dalle immagini sottostanti dell'area "Storage Adapters".

Verificando visivamente dalla console web, si può notare che le LUN 0 ed 1 sono correttamente riconosciute ed agganciate.


Il "Network Port Binding" sembra correttamente configurato.


Stessa, corretta configurazione sembra essere anche lato storage. Gli "Initiator iqn" dell'host vengono visti correttamente e correttamente mappati alle due LUN.


Resta il fatto che le LUN non vengono montate e di conseguenza non ci resta che analizzare qualche log.
Analizzando i log del vmkernel direttamente sul nodo incriminato ... abbiamo riscontrato riversi "fail" relativi all'identificativo del disco in questione ..


Cerchiamo di avere maggiori informazioni sui messaggi di stato del dispositivo SCSI osservati durante la revisione degli errori NMP nel file di log del vmkernel.

In base a quanto rilevato possiamo, grazie a questo sito, convertire i "sense codes" ricevuti in errore dagli Hosts ESXi in formato leggibile.

Inserendo i vari codici ..


Dalla decodifica dei codici di errore abbiamo riscontrato che il problema è dato da: "This status occur due to dropped FCP frames in the environment".

Verifichiamo di conseguenza (come pure riscontrato nella KB2150992 di VMware) le configurazioni e la velocità impostata sui vSwitch. Selezionare il nodo in questione (1) - cliccare su Configure (2) - "Virtual switches" (3) - selezionare il primo switch relativo all'iSCSI (4) e quindi editare le impostazioni (5).


Come possiamo osservare il problema sembra essere nella configurazione dell'MTU impostato a 1500; 


mentre sappiamo essere impostato lato storage e sogli switch di rete a 9000.
Impostiamo il nuovo valore e salviamo la configurazione premendo "OK".


Torniamo sull'area dello "Storage Adapter" (1) ed effettuiamo un nuovo rescan delle LUN (2).


Terminata la scansione delle LUN, verifichiamo con successo dalla tab "Datastore" che le LUN VNX-LUN00 e VNX-LUN01 sono correttamente visibili ...


Ulteriori riferimenti ed informazioni per l'interpretazione dei codici di rilevamento SCSI in VMware ESXi si può consultare la kb di riferimento KB289902 e il sito Technical Committee T10