Tutti gli articoli di Lorenzo Moglie

How to cancel an hang task of a VM?

Facebooktwittergoogle_plusredditlinkedin
Problema
Una VM risulta essere bloccata, non risponde più al ping, non si riescono ad effettuare le normali attività di gestione della VM come, migrazione, riavvio, spegnimento della VM ecc.
Tutto, per questa VM sembra essere in uno stato di blocco impossibile da annullare, la stessa VM è in fase di migrazione da un host esxi ad un altro da oltre 24 ore.

Come possibile vedere dall’immagine sotto, quando si provava a spegnere via web client la VM si otteneva il seguente messaggio di errore: “The attempted operation cannot be performed in the current state (“Powered on”). An error was received from ESX host while powering off VM <VM NAME>.”



Idem provando via command line direttamente sull’host ESXi con i vari comandi vim-cmd, si ottiene lo stesso messaggio di errore. 
Non resta che “killare” il processo che gestisce la VM procedendo nel seguente modo:

  • 1. Lanciare il comando ps.
  • 2. Identificare i processi in esecuzione relativi alla VM problematica usando il comando grep in questo modo “ps | grep VM-Name“. Nel mio caso la VM si chiama COGNOS_TEST, quindi “ps | grep COGNOS_TEST
  • 3. Uccidere (kill) il processo genitore (parent) con il comando “kill Parent_ID“. In questo caso “kill 4730011


Verificato che i processi relativi alla VM non sono più in esecuzione…. la VM risulta ancora accesa e quando si prova a spegnerla, si ottiene il solito messaggio di errore.

Soluzione
La soluzione trovata indicata anche dalla seguente KB1014165 … è stata quella di verificare i processi relativi alla VM bloccata con i comandi esxicli nel modo seguente:
  • 1. Lanciare il comando “esxcli vm process list” per identificare il “World ID” della VM. Nel mio caso “4730012
  • 2. Spegnere brutalmente la VM con il comando “esxcli vm process kill -t [soft, hard, force] -w World_ID”. Nel mio caso “esxcli vm process kill -t force -w 4730012 ” 
  • 3. In questo caso la VM risulta essersi spenta.

VMware Identity Manager 2.9 – Could not Pull the Required Object From Identity Manager

Facebooktwittergoogle_plusredditlinkedin
Disclaimer: Some of the procedures described below is not officially supported by VMware. Use it at you own risk.

Problema
Sono stato contattato da un cliente perché l’Identity Manager che avevo messo in piedi un pò di tempo fa, sembra non autenticare più correttamente gli utenti. Sembra che l’IDM non contatti più i Domain Controllers.
Effettuato il login come utente amministratore all’interno dell’Appliance IDM (nel mio caso l’IDM è una versione 2.9.2.0 Build 6095217) vado a verificare sotto la tab Identiry & Access Management i Directories e noto che a fianco del bottone Sync Now nella riga corrispondente del Directory Name interessato c’è una X rossa che indica che l’IDM non riesce correttamente a sincronizzarsi/contattare l’AD (Active Directory).
Clicco quindi sul Sync Now  e vado a verificare in Sync Log cosa sta succedendo; il seguente messaggio di errore:

Could not pull the required object from Identity Manager


Ci si connette in SSH sull’Identity Manager cercando di reperire maggiori info dai file di logs. 
I file di logs per quello che riguarda l’vIDM sono nella directory “/opt/vmware/horizon/workspace/logs/”  nello specifico ho trovo alcune informazioni interessanti nel file di log connector.log (vedi sotto)


2018-06-20 14:11:28,514 INFO  (Timer-24) [3002@WSIDM;;] com.vmware.horizon.connector.admin.StateService - Saving config for 3002@WSIDM to file /usr/local/horizon/conf/states/WSIDM/3002/config-state.json
2018-06-20 14:11:28,521 INFO  (Timer-24) [3002@WSIDM;;] com.vmware.horizon.connector.admin.StateService - Saving state config to disk DONE.
2018-06-20 14:12:26,057 INFO  (Timer-18) [3002@WSIDM;;] com.vmware.horizon.connector.utils.RestClient - END   sendRequestBase (https://wsidm.<NOME CLIENTE>.it/SAAS/t/wsidm/jersey/manager/api/connectormanagement/directoryconfigs/19321c7b-0172-4eaa-89b4-c54a316a4514/syncprofile, ..., application/vnd.vmware.horizon.manager.connector.management.directory.sync.profile+json, GET, null, ...)
2018-06-20 14:12:26,057 WARN  (Timer-18) [3002@WSIDM;; com.vmware.horizon.engine.ObjectPullEngine - Code from Service :-404
2018-06-20 14:12:26,057 ERROR (Timer-18) [3002@WSIDM;;] com.vmware.horizon.engine.ObjectPullEngine - Error message from Service :-Request timed out..[response-Request timed out.
2018-06-20 14:12:26,057 ERROR (Timer-18) [3002@WSIDM;;] com.vmware.horizon.engine.ObjectPullEngine - Could not retrieve required object from Horizon com.vmware.horizon.connector.exception.PullEngineException: Could not retrieve required object from Horizon
        at com.vmware.horizon.engine.ObjectPullEngine.getObjectFromHorizon(ObjectPullEngine.java:98)
        at com.vmware.horizon.connector.connectormanagement.DirectorySyncConfigPullEngine.getDirectorySyncConfigFromService(DirectorySyncConfigPullEngine.java:44)
        at com.vmware.horizon.connector.admin.DirectorySyncConfigUpdateService.updateDirectorySyncConfigFromService(DirectorySyncConfigUpdateService.java:43)
        at com.vmware.horizon.connector.admin.SyncScheduleService.syncIfAppropriate(SyncScheduleService.java:153)
        at com.vmware.horizon.connector.admin.ScheduleService$1.run(ScheduleService.java:83)
        at java.util.TimerThread.mainLoop(Timer.java:555)
        atjava.util.TimerThread.run(Timer.java:505)
2018-06-20 14:12:26,060 ERROR (Timer-18) [3002@WSIDM;;] com.vmware.horizon.connector.admin.ScheduleService - Sync of Directory aborted.com.vmware.horizon.connector.exception.PullEngineException: Could not retrieve required object from Horizon<
        at com.vmware.horizon.engine.ObjectPullEngine.getObjectFromHorizon(ObjectPullEngine.java:98)
        at com.vmware.horizon.connector.connectormanagement.DirectorySyncConfigPullEngine.getDirectorySyncConfigFromService(DirectorySyncConfigPullEngine.java:44)
        at com.vmware.horizon.connector.admin.DirectorySyncConfigUpdateService.updateDirectorySyncConfigFromService(DirectorySyncConfigUpdateService.java:43)
        at com.vmware.horizon.connector.admin.SyncScheduleService.syncIfAppropriate(SyncScheduleService.java:153)
        at com.vmware.horizon.connector.admin.ScheduleService$1.run(ScheduleService.java:83)
        at java.util.TimerThread.mainLoop(Timer.java:555)
        at java.util.TimerThread.run(Timer.java:505)
2018-06-20 14:12:26,060 INFO  (SimpleAsyncTaskExecutor-171294) [3002@WSIDM;;] com.vmware.horizon.client.rest.Utils -BEGIN sendRequestBase (https://wsidm.< NOME CLIENTE>.it/SAAS/t/wsidm/API/1.0/REST/auth/cert, ..., application/x-www-form-urlencoded, GET, null, ...)
2018-06-20 14:12:26,060 ERROR (Timer-18) [3002@WSIDM;;] com.vmware.horizon.connector.mvc.UIAlerts - Could not pull the required object from Identity Manager. Request timed out..[response-Request timed out.]
2018-06-20 14:12:26,060 INFO  (Timer-18) [3002@WSIDM;;] com.vmware.horizon.connector.admin.SyncScheduleService - Directory sync method: end.
2018-06-20 14:12:26,070 INFO  (SimpleAsyncTaskExecutor-171294) [3002@WSIDM;;] com.vmware.horizon.client.rest.Utils -END   sendRequestBase (https://wsidm.<NOME CLIENTE>.it/SAAS/t/wsidm/API/1.0/REST/auth/cert, ..., application/x-www-form-ur lencoded, GET, null, ...)

Noto una entry con “Could not retrieve required object from Horizon”, il che mi fa pensare a qualche cambiamento di cui non sono a conoscenza 🙂 ….. googlando un pochino la stringa presente nell’interfaccia web “Could not Pull the Required Object From Identity Manager” vedo che non sono l’unico con il problema e trovo un interessante post di Matt Allfrod a questo link .

Chiedo quindi al cliente se ci sono cambiamenti con i Domain Controllers e scopro che uno di questi è stato spento (perché dismesso).
L’Identity Manager una volta configurato non effettua automaticamente delle query per verificare quali sono i Domain Controllers disponibili, ma fa riferimento ad un file “domain_krb.properties” creato in fase di configurazione.

Documentazione ufficiale VMware nell’area Integrazione con Active directory


Individuato il nome del DC dismesso procediamo alla modifica manuale del fie domain_krb.properties nel modo seguente:

1. effettuare il login all’interno dell’vIDM (Utilizzare sshuser e poi diventare root)

2. effettuare una copia del file originale 
cp /usr/local/horizon/conf/domain_krb.properties  /usr/local/horizon/conf/domain_krb.properties .ORIG

3.editare il file vi /usr/local/horizon/conf/domain_krb.properties

4. effettuare le modifiche in base ai cambiamenti dei Domain Controller e salvare le modifiche. Nel nostro caso eliminare la entry del DC che non esiste più.

5. cambiare l’ownership del file eseguendo 
chown horizon:www /usr/local/horizon/conf/domain_krb.properties

6. riavviare il servizio eseguendo service horizon-workspace restart

7. lanciare un Sync Now per verificarne il corretto funzionamento.
Con mia sorpresa mi accorgo che la procedura appena indicata non ha sortito effetto, il problema è ancora lì ed l’vIDM continua a non sincronizzarsi correttamente con l’infrastruttura Active Directory.


Soluzione
Analizzando in modo più approfondito i file di logs del connector ed ispirato dalla KB2145438 ho notato che tutte le richieste effettuate sembrano essere iniziate da un initiator (nel mio caso 3002@<nome server>) che ha un file di configurazione posizionato in /usr/local/horizon/conf/states/<NOME SERVER>/3002/config-state.json (vedi sopra riga 1 nel file di log).

Verificando il contenuto del file config-state.json, riscontro che ci sono delle entry con il nome del Domain Controller dismesso. 


Decido quindi di procedere come d seguito…

8. effettuare una copia del file  sorgente (prima di effettuare qualsiasi modifica) nel modo seguente… cp /usr/local/horizon/conf/states/<NOME SERVER>/3002/config-state.json /usr/local/horizon/conf/states/<NOME SERVER>/3002/config-state.json.ORIG

wsidm:~ # cp /usr/local/horizon/conf/states/WSIDM/3002/config-state.json /usr/local/horizon/conf/states/WSIDM/3002/config-state.json.ORIG


9. sostituisco il nome del DC dismesso con uno esistente sed -i ‘s/<DC Vecchio>/<Nuovo DC>/g’ /usr/local/horizon/conf/states/<NOME SERVER>/3002/config-state.json

wsidm:~ # sed -i 's/sgrsodc2017/sgrbodc2/g' /usr/local/horizon/conf/states/WSIDM/3002/config-state.json

10. riavviare il servizio eseguendo service horizon-workspace restart 
11. lanciare un Sync Now per verificarne il corretto funzionamento



12. Verificare l’accesso con una utenza di servizio. Avendo utilizzato un DC prossimo all’vIDM, a sensazione (non avendolo monitorato) la procedura di autenticazione è sembrata più veloce.

Conclusione

Consiglio di verificare tutti gli step indicati, sia per modificare il file  domain_krb.properties (eliminando i DC non più presenti) e sostituendo le entry del DC dismesso all’interno del file config-state.json con con un DC in cui è abilitata la ricerca della Posizione servizio DNS (record SRV) come indicato qui 

MAC – Installare PowerCLI

Facebooktwittergoogle_plusredditlinkedin
Nel precedente post abbiamo installato la “PowerShell” su mac, siamo quindi pronti per poter procedere con l’installazione della PowerCLI VMware.

Apriamo il terminale ed accediamo alla PowerShell digitando:

LIF:~ Lorenzo$ pwsh

Possiamo procedere con l’installazione della PowerCli VMware semplicemente digitando:


PS /Users/lorenzo> Install-Module -Name VMware.PowerCLI -Scope CurrentUser  

e confermare con “Y” per procedere con il download e l’installazione dei vari moduli….. per verificare che siano stati correttamente installati lanciare il comando …


PS /Users/lorenzo> Get-Module -Name VMware.* -ListAvailable

Tutto sembra essere stato installato correttamente. Siamo pronti per poter utilizzare la PowerCLI su nostro macOS.


Alcuni link utili: 
https://ithinkvirtual.com/2018/03/04/install-powershell-and-vmware-powercli-on-centos/
https://blogs.vmware.com/PowerCLI/2018/03/installing-powercli-10-0-0-macos.html
https://notesfrommwhite.net/2018/02/28/installing-powershell-powercli-on-a-mac/

MAC – Installare PowerShell Core

Facebooktwittergoogle_plusredditlinkedin
Abbiamo precedentemente installato il tool (homebrew) necessario per procedere con l’installazione della PowerShell Core come indicato da documentazione Microsoft.

La successiva componente che dobbiamo installare per poter installare PowerShell e successivamente la PowerCLI, è Homebrew-Cask. Procediamo come indicato di seguito:

LIF:~ Lorenzo$ brew tap caskroom/cask

e continuiamo con l’installare la PowerShell

LIF:~ Lorenzo$ brew cask install powershell

Se tutto è andato correttamente ….

Verifichiamo che tutto funzioni correttamente lanciando il comando …

LIF:~ Lorenzo$ pwsh

Come possiamo vedere la PowerShell installata in questo caso è la v6.0.2, tuttavia per avere maggiori dettagli sulla PowerShell installata possiamo digitare direttamente dal prompt della pwsh:

PS /Users/lorenzo> $PSVersionTable 



Verifichiamo i moduli installati di default 

PS /Users/lorenzo> Get-Module * -ListAvailable




Nel prossimo post procederemo con l’installazione della PowerCli VMware.

MAC – Installare Homebrew

Facebooktwittergoogle_plusredditlinkedin
Problema
Ho la curiosità e la necessità di installare “PowerShell” e la PowerCLI VMware su macOS.

Soluzione
Per prima cosa (come prima componente), se non presente nel proprio sistema, installare Homebrew. Homebrew è una delle soluzioni più diffuse su macOS per la gestione dei pacchetti.

L’installazione è molto semplice si tratta di aprire un “Terminale” e di lanciare il comando riportato sotto…

LIF:~ Lorenzo$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Procedere premendo Invio

Inserire la password e premere Invio per continuare 


Sembra che tutto si sia installato correttamente (Installation succesful). Possiamo procedere con l’installazione della PowerShell Core.



LUN ID 256 missing on VMware

Facebooktwittergoogle_plusredditlinkedin

Problema
Creato una nuova LUN con ID 256 da Pure Storage e mappata all’Host Group degli Host VMware, non viene vista VMware. La versione degli host ESXi sono 6.5.

Di seguito si vede la nuova LUN Vol07 (ID 256) aggiunta all’host group.

Effettuato il rescan dell’HBA lato VMware, la LUN non appare nella lista di quelle raggiungibili/disponibili.


Ho quindi verificato nel configuration maximum di VMware se presenti dei limiti per la 6.5. Con sorpresa scopro che il limite per il LUN ID è 16383 (vedi immagine sotto – pag.13 del documento indicato in precedenza).


Soluzione
Il problema è stato risolto come anche indicato da Cody Hosterman andando ad associare alla LUN un ID inferiore al 256 (nel mio caso era disponibile il 246).

Quindi procediamo per step:

  • Rimuovere la LUN dall’Host Group.
  • Ri-Assegnare la LUN all’Host Group, questa volta sostituendo la dicitura “automatic” con il valore desiderato. Nel mio caso LUN ID 246 e confermando l’operazione premendo sul bottone “Confirm”
  • Accedere all’Host ESXi effettuare il Rescan delle LUN e verificare che la LLUN sia presente in lista (come possiamo vedere sotto)
  • Recent tasks pane – doesn’t show any activity

    Facebooktwittergoogle_plusredditlinkedin
    Problema
    Il Pannello delle attività recenti (“Recent Tasks”) del Web-Client non mostra nessuna attività …. nonostante si stia gestendo delle atività.


    Soluzione
    Tutto quello che è necessario fare per risolvere la problematica è ripristinare le impostazioni predefinite cliccando su “Reset To Factory Defaults” aprendo il menù a fianco del nome utente utilizzato per loggarsi all’interno del WebClient (come mostrato nell’immagine sotto)

    Accettare le condizioni di reset premendo “Yes”. Se sono state effettuate delle personalizzazioni queste verranno perse e re-impostate come originariamente.


    Una volte premuto “YES” se i tasks non vengono ancora visualizzati e necessario effettuare un “log out” ed un “login” dal web client. Come possiamo vedere dall’immagine sotto, tutto riprende a funzionare correttamente.

    VPXV_EVENT_1

    Facebooktwittergoogle_plusredditlinkedin
    Problema
    In fase di migrazione di un Virtual Center 5.5 dalla piattaforma Windows alla VCSA, il processo è stato interrotto manualmente per insufficienza di spazio disco necessario per terminare la migrazione.

    Ad un secondo lancio del tool di migrazione, il sistema si è fermato nella fase di migrazione dei dati da Windows a VCSA con il seguente messaggio di errore:


    Error while exporting events and task data:pyodbc.ProgrammingError: ('42S01', "[42S01] 
    [Microsoft][SQL Server Native Client 11.0][SQL Server]There is already an object named
    'VPXV_EVENT_1' in the database. (2714) (SQLExecDirectW)")



    Soluzione
    Da una veloce ricerca in google per “VPXV_EVENT_1”, ho trovato subito la KB2148401 che ha permesso di risolvere il problema.
    La soluzione consiste semplicemente, nel rilanciare nuovamente le operazioni di migrazione.

    Da come si può vedere dall’immagine sotto tutto sembra essere migrato come desiderato.