How to reset the NSX l2vpn edge standalone appliance password

Problem
I was working to an infrastructure deployed by someone else, and I needed to get into the "NSX l2vpn edge" standalone appliance to check some information without having to change the settings.
As can be seen from the image below, the user appears to be also locked due to 9 failed logins attempts.

Let's covering the process down here in detail, step by step, with screenshots.

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

Solution
The fastest way I found to access the NSX l2vpn Edge Appliance and reset the password, is to start the VM from a CDROM with a Linux live CD.

First of all, we turn off the VM and take a cold snapshot.

after that we connect to the appliance the Linux live CD (in my case I used lubuntu)

and we boot the appliance selecting the CD-ROM Drive options

Start linux in live mode (without installing anything), and once started open a Terminal and ....

lubuntu@lubuntu:~$ sudo su
root@lubuntu:~# fdisk -l

as we can see from the below picture, we have disk /dev/sda with four partitions

The partition that interests us is the /dev/sda1 ...

root@lubuntu:~# mount /dev/sda1 /mnt/
root@lubuntu:~# chroot /mnt/
bash-4.3# passwd admin

Then, need to provide a new password ...

If everything went fine, the message password update successfully should be appear.

Repeat the same command to reset the password of the user "enable", and if the password was successfully reset, reboot the NSX l2vpn edge appliance.

When the appliance is up and running, try to get into providing the admin username and password ....

If everything went as expected remove the snapshot.

That's it.

VxRail Appliance Event Codes

Problema
Da una certa versione in poi, EMC ha iniziato a personalizzare, migliorare, dettagliare e codificare i messaggi di errore delle VxRail Appliance con una propria numerazione alfanumerica denominata "Symptom Code".
Pur essendo il codice, esplicato in modo abbastanza dettagliato nell'area "Description" sarebbe utile disporre dei riferimenti alle KB per la risoluzione della problematica.

Soluzione
Di seguito la guida di riferimento dei codici di evento "Event Code Reference" per le VxRail Appliance dalla versione 4.5.X alla versione 4.7.X con riferimento alla KB per la risoluzione del problema.

That's it.

PowerCLI - Check Netflow settings

Problema
Ho la necessità di verificare le impostazioni del parametro "Netflow" sui vari virtual distributed portgroup tramite PowerCLI.

Soluzione
Cercando in rete ho trovato quello che fa la mio caso "DISABLING NETFLOW WITH POWERCLI" direttamente scritto da Alan Renouf.

Non mi resta che verificare le impostazioni Netflow di tutti i VDPortGroups con il comando .....

Get-VDPortgroup | Select Name, VirtualSwitch, @{Name="NetflowEnabled";Expression={$_.Extensiondata.Config.defaultPortConfig.ipfixEnabled.Value}}

That's it.

Repoint VxRail Manager Appliance to a new embedded PSC

Problema
A seguito delle operazioni di convergenza del domino Single Sign-On di una PSC esterna a una singola Virtual Machine vCenter ed Embedded Platform Services Controller si è verificata l'impossibilità di accedere via web all'Appliance VxRail Manager, con qualsiasi utenza registrata. Nello specifico l'utenza amministrativa administrator@vsphere.local visualizzando il seguente messaggio di errore ....

Authentication could not be completed due to network connectivity problems.

Sembra che la VxRail Manager Appliance non sia più connessa al vCenter Server.


Soluzione

WARNING: Procedures described below are not officially supported. Procedures can be performed ONLY with supervision of technical support DELL EMC. Use it at your own risk.

Connessi in SSH sulla VxRail Manager Appliance (VRM) con l'utenza mystic diventare root e procedere come indicato di seguito ...

1. analizziamo i log
   
   vxrailserver:/home/mystic # find / -iname web.log
   vxrailserver:/home/mystic # cat /var/log/mystic/web.log
   
   
   
   
   quello che possiamo riscontrare è che la VRM sta tentando di accedere al vCenter (nel mio caso indicato come vCenter.FQDN) cercando di ottenere un token sso dalla PSC (nel mio caso indicato come vpsc.FQDN) per l'utenza management@vsphere.local. In questo caso, vpsc.FQDN è la vecchia PSC esterna non più disponibile.
   

   2019-09-09T08:07:53.266+0200 INFO  [myScheduler-8] com.vce.commons.core.services.ConnectionHelper ConnectionHelper.refreshConnection:34-- VC connection timed out, reconnecting.
   2019-09-09T08:07:53.601+0200 INFO  [myScheduler-8] com.vce.commons.core.services.ConnectionHelper ConnectionHelper.refreshConnection:36 - Connecting to virtualcenter.FQDN username management@vsphere.local
   2019-09-09T08:07:53.266+0200 INFO  [myScheduler-8] com.vce.commons.core.connection.misc.ConnectionUtils ConnectionUtils.getSsoUrl:124 - Trying to obtain sso token from: https://vpsc.FQDN/sts/STSService/vsphere.local
   2019-09-09T08:07:56.412+0200 ERROR [myScheduler-8] com.vce.commons.core.connection.services.ConnectionFactoryImpl ConnectionFactoryImpl.createVCConnection:94 - unable to connect to VCcom.sun.xml.ws.client.ClientTransportException: HTTP transport error: java.net.NoRouteToHostException: No route to host (Host unreachable)
   

2. verifichiamo le impostazione presenti nella tabella "settings" del database ...
   
   vxrailserver:/home/mystic # psql -U postgres mysticmanager
   mysticmanager=# select * from settings;
   
   
   
   
   
   
   
   Come possiamo notare nell'immagine precedente, le impostazioni fanno riferimento alla vecchia PSC (vpsc.FQDN).


3. e della tabella "management_account" ...
   
   mysticmanager=# select * from management_account;
   
   
   
   
   Anche in questo caso si fa riferimento alla vecchia PSC.
   Prendiamo nota dell'id corrispondente alla riga con component=PSC; nel mio caso ID=5.


4. Non fanno eccezione le impostazioni presenti nel file "runtime.properties"; che fanno sempre riferimento alla vecchia PSC.
   
   
   vxrailserver:/home/mystic # find / -iname runtime.properties
   vxrailserver:/home/mystic # cat /var/lib/vmware-marvin/runtime.properties
   
   
   
   


5. generiamo nuovamente la password associata all'utente manager@vsphere.local.
   
   vxrailserver:/home/mystic # echo -n "<password>" | openssl bf-ecb -nosalt -K $(xxd -p < /etc/vmware-marvin/password.key) | xxd -p
   
   
   
   
   prendiamo nota della nuova password cifrata....


6. editare il file runtime.properties tramite il comando .....
   
   
   vxrailserver:/home/mystic # vi /var/lib/vmware-marvin/runtime.properties
   
   e sostituire, le righe
   
   data.vcenter.pscHost=vpsc.FQDN
   con
   data.vcenter.pscHost=virtualcenter.FQDN #(1) Nuova PSC interna al vcenter
   
   e
   
   data.managementPassword=blowfish\:bffe...........df8aa0
   con
   data.managementPassword=blowfish\:3bfa...........2a9e34 #(2) chiave generata in precedenza
   
   
   
   


7. infine aggiornare le tabelle settings ed management_account del database nel modo seguente ...
   
   
   vxrailserver:/home/mystic # psql -U postgres mysticmanager
   mysticmanager=# update settings set psc_ip='virtualcenter.FQDN';
   
   
   
   
   
   
   mysticmanager=# update management_account set host='virtualcenter.FQDN' where id=5;
   mysticmanager=# update management_account set password='3bfa...........2a9e34' where id=5;
   
   
   
   


8. aggiorniamo la pagina Web e verifichiamo l'accesso .....
   
   
   
   
   
   

That's it.

Decommission the Platform Services Controller

Nel precedente post "PSC and VCSA converge into a single embedded VM" ho trattato come convergere una PSC e un vCenter in una singola Virtual Machine.
Non essendo (nel mio caso) la Platform Services Controller più necessaria, vediamo come rimuoverla in modo corretto utilizzando il vSphere Client.
Dopo aver verificato via command line o via Web tramite vSphere Client che la PSC è stata inclusa internamente al vCenter ...

Accedere al vCenter Server tramite vSphere Client, selezionare la voce Menu > Administration e sotto la sezione Deployment selezionare System Configuration.

Nell'area view as topology possiamo vedere come sono connessi i vCenter alle PSC.

mentre "command line" connettendosi al vCenter possiamo lanciare il comando ...
# /usr/lib/vmware-vmafd/bin/vmafd-cli get-ls-location --server-name localhost

Verificato che è tutto OK.

Selezionare la PSC node (da dismettere) > cliccare DECOMMISSION PSC

Inserire l'utenza di domino del Single Sign-On (nel mio caso administrator@vsphere.local) > digitare la password > spuntare la voce "I acknowledge that I have made a back up of my Platform Services Controller before initiating decommission" > cliccare DECOMMISSION.

Operazioni in progress ...

Se l'operazione è andata a buon fine, possiamo leggere: "Unregistering node successfully completed."

Rimuovere cliccando "Delete from Disk" la Virtual Machine dall'infrastruttura.

That's it.

PSC and VCSA converge into a single embedded VM

Come indicato nella KB60229 a partire da vSphere 6.7, VMware ha annunciato una semplificazione delle propria architettura di domino Single Sign-On del vCenter abilitando il supporto vCenter Enhanced Linked Mode (ELM) anche per le installazioni di vCenter Server Appliance con la Platform Service Controller integrata.

A partire da questa versione, l'architettura della Platform Services Controller esterna è obsoleta e non sarà disponibile nelle versioni future.
Con il rilascio della versione 6.7 Update 1, VMware mette a disposizione un Tool per la convergenza della PSC esterna nel vCenter Server tramite CLI. Il funzionamento del tool e gli steps necessari da eseguire per la convergenza sono indicati nel sito di Emad Younis al seguente link e nel blog ufficiale VMware alla pagina "Understanding the vCenter Server Converge Tool".

Inoltre al seguente link è disponibile il "vSphere 6.7 Topology and Upgrade Planning Tool". Prima di procedere con la migrazione leggere: "Moving from a Deprecated to a Supported vCenter Server Deployment Topology Before Upgrade or Migration" e "Converging vCenter Server with an External Platform Services Controller to a vCenter Server with an Embedded Platform Services Controller".

Con il rilascio della versione 6.7 U2 il Tool di convergenza oltre ad essere migliorato, viene integrato nella GUI.
Di seguito vediamo gli steps necessari per convergere i servizi di una PSC esterna in una singola Virtual Machine interna al vCenter.

Procediamo assicurandoci di disporre di un backup valido e consistente sia della PSC che della vCSA.
Quindi per effettuare la procedura di Converge to Embedded, dalla vCSA selezionare la voce Menu > Administration e sotto la sezione Deployment selezionare System Configuration.

Nell'area view as topology possiamo vedere come sono connessi i vCenter alle PSC.

Selezionare il vCenter(1) di riferimento > CONVERGE TO EMBBEDDED(2).

Inserire l'utenza di domino del Single Sign-On (nel mio caso administrator@vsphere.local) > digitare la password > spuntare la voce "I acknowledge that I have made a back up of my vCenter Server Appliance before initiating convergence" > cliccare CONVERGE.

Sfortunatamente, dopo qualche istante il processo si interrompe con il messaggio di errore:
<vCenter Server> could not be converged.

Analizzando i log non ho riscontrato nulla di particolare. Tuttavia, pur avendo completo accesso ad internet ho deciso di provare la procedura descritta in "Download and Mount the vCenter Server Appliance Installer for UI Convergence" per eseguire la convergenza utilizzando il vSphere Client in modalità off-line.

Ripuliamo l'ambiente e procediamo come segue:

1. Effettuare una Snapshot di entrambi vCSA e PSC.
   
   
2. Eliminare all'interno del vCenter tutto il contenuto della cartella "/var/log/vmware/converge". Nel mio caso lo archivio in una nuova cartella che chiamo "old" ...
   
   # cd /var/log/vmware/converge/
   # mkdir old
   # mv * old/
   
   
   
   
   
3. Stessa cosa per la cartella "velma" che è stata creata in root ....
   
   # cd /root
   # mv velma/ velma.old
   
   
4. Eseguire il reboot della PSC ed attendere che tutti i servizi siano attivi, verificando con il comando service-control --status --all
   
   
5. Effettuare il reboot del vCenter Server Appliance ....
   
   
6. Scaricarsi la ISO di vCenter Server Appliance 6.7 Update 2.
   
   
7. Effettuare l'attach dell'immagine ISO all'unità CD/DVD di vCenter Server Appliance.
   
   
8. Montare l'immagine ISO nella cartella /mnt/cdrom con il comando
   
   # mount /dev/cdrom /mnt/cdrom
   
   
   
   
   
9. Prova a lanciare il tool di convergenza del vCenter.

Il tool è ripartito correttamente, ed il sistema ci segnala che il vCenter Server verrà riavviato e che l'operazione potrebbe richiedere qualche minuto ....

Terminata l'attività di convergenza, verifichiamo che il vCenter punti alla PSC interna.
Via command line è possibile verificarlo connettendosi in SSH sul vCenter lanciando il comando ...

# /usr/lib/vmware-vmafd/bin/vmafd-cli get-ls-location --server-name localhost

Mentre via Web Client possiamo verificarlo nell'area "view as topology" ..

Terminata la convergenza, nel mio caso la PSC non risulta più essere necessaria e quindi può essere dismessa.

That's it.

VxRail: mystic account locked out due too many failed logins

Problema
Di recente mi è successo di dover accedere via SSH ad una appliance "VxRail Manager". L'accesso via SSH di default è consentito solo all'utenza "mystic", ma come possibile vedere dall'immagine di seguito l'utente risulta essere "locked" a seguito di un numero X di tentativi.

Account locked due to X failed logins
La problematica non si risolve con il riavvio dell'appliance in quanto l'utenza "mystic" continua a risultare locked. L'unica cosa che cambia è il numero di tentativi falliti per tentare di accedere via SSH.

Soluzione
Il metodo per resettare il numero di tentativi falliti e quindi poter permettere nuovamente l'accesso via SSH a mystic é quello di:

1. Accedere con l'utenza "root" via console alla virtual machine "VxRail Manager"
   
   
   
   
   
2. Aprire una sessione "xterm"
   
   
3. Lanciare il comando: "pam_tally2 --user=mystic --reset"
   
   
   
   
   
4. Verificare che l'accesso via ssh con l'utenza mystic avviene in modo corretto.
   
   
   

That's it.