Pagine

lunedì 8 luglio 2019

Unconventional way to use HOL

Essendo il mio Home Lab "temporarily out of service" ... mi avvalgo dell'utilizzo degli HOL.
Tutti conosciamo gli "Hands-on Labs" di VMware, sono dei laboratori pre configurati che VMware mette a disposizione degli utenti per testare/verificare ed/o imparare le nuove funzionalità introdotte nei propri prodotti. Seguendo la guida passo-passo si viene guitati nell'utilizzo di tali funzionalità.
Tuttavia non sempre ci sono laboratori pronti per testare tutto ciò che vogliamo. Nel mio caso avevo la necessità di testare le nuove Cmdlets messe a disposizione per SRM PowerCLI descritte in questo sito. Non disponendo di un LAB pre-configurato ad-hoc, ho trovato ricercato un il LAB (HOL-1905-01-SDC - VMware Site Recovery Manager - Data Center Migration and Disaster Recovery) dove è possibile scoprire ed imparare tutto quello che c'è da sapere su VMware Site Recovery Manager (SRM) 8.1.

Effettuato l'accesso al laboratorio, vado a creare la stessa struttura file scaricata dal sito (semplicemente dei file vuoti). Come mostrato nella seguente immagine.


Trasferisco tramite il bottone "INVIA TESTO" i file inviando il testo copiato dal file originale.


Utilizziamo il NOTEPAD (o qualsiasi applicazione che gestisce i file TXT), per editare i file precedentemente creati ed accettare lo streaming di testo che stiamo per inviare .... copiamo il testo del file che vogliamo trasferire, lo incolliamo nell'apposito box "INVIARE UN TESTO ALLA CONSOLE" e premiamo "INVIA" (come mostrato sotto). Attendiamo che tutto il testo sia stato copiato remotamente (questa attività potrebbe richiedere un pò di tempo dipende dalla velocità della connessione) salviamo il file.


Ripetiamo la stessa operazione per il file successivo, fino a quando non abbiamo terminato di trasferire tutti i file necessari.

Possiamo editare i file anche con "Windows PowerShell ISE"



Apriamo la PowerSwhell ed importiamo il modulo
PS C:\> Import-Module -Name C:\LM\Meadowcroft.Srm.psd1
.... provvediamo ad inserire le credenziali lanciando il comando
$creential = Get-Credential


Possiamo lanciare il comando di connessione all'SRM.
PS C:\> Connect-SrmServer -Credential $credential -RemoteCredential $credential


Stabilita la connessione lanciamo il comando oggetto di questo test: "la possibilità di gestire l'orchestrazione/l'attivazione del Plan SRM di attivazione del Disaster Recovery via PowerCLI".
Get-SrmRecoveryPlan -Name "Instruction to Site Recovery Manager" | Start-SrmRecoveryPlan -RecoveryMode Test


Come possibile vedere dalla successiva Immagine, abbiamo attivato il disaster Recovery Plan di SRM via PowerCLI.


Questo è tutto. Abbiamo visto un modo diverso di utilizzare gli Hands-On-Lab di VMware.

martedì 18 giugno 2019

USB to Serial from MAC

Mi capita di dover utilizzare il connettore USB-to-Serial sul MAC e non ricordarmi i comandi per attivare la visualizzazione dal terminale.
In linea di massima non è necessario installare del software aggiuntivo sul MAC per farlo funzionare, diamo quindi per scontato qual ora fosse necessario che sia installato e correttamente funzionante.
Di seguito i passi:
  1. Aprire una sessione Terminal

  2. Ricerchiamo il device TTY corretto in /dev. Digitando: ls -l /dev/cu.*


    Nel mio caso il risultato è "/dev/cu.usbserial"

  3. Connettiamoci, utilizzando il comando:
    screen /dev/cu.usbserial <baud rate>


    Nel mio caso screen /dev/cu.usbserial 115200


    That's it.

Maggiori dettagli sull'utilizzo del comando screen, possono essere ottenuti dal Terminal digitando man screen.

martedì 28 maggio 2019

NSX Controllers - Get privileged mode

Disclaimer: Don't try this on NSX production environment.

Qualche tempo fa ho scritto un post sul come poter accedere in modalità "Tech Support Mode" e/o "root shell" alla console NSX Manager.

In questo post andrò a descrivere come ottenere accesso in modalità Tech Support Mode alle Controller NSX.

Ripeto: quanto descritto non va testato in un ambiente in produzione in quanto qualsiasi modifica apportata al sistema sottostante se non coadiuvato dal supporto tecnico di VMware potrebbe portare ad una inconsistenza di sistema ed invalidare la possibilità di ottenere assistenza dallo stesso GSS.

Procediamo nel seguente modo:
  1. Per prima cosa otteniamo l'accesso "Tech Support Mode" all'NSX Manager come descritto nel precedente articolo.

  2. Identifichiamo su quale controller vogliamo accedere. Nel nostro caso controller-1



  3. Dal NSX Manager recuperiamo la password della "controller-1" digitando il comando:
    /home/secureall/secureall/sem/WEB-INF/classes/GetNvpApiPassword.sh controller-1


    Ottenendo come risultato la password... di cui prendiamo nota.

  4. Accediamo via ssh alla Controller NSX ....



    Inserendo la password utilizzata in fase di deploy ...



  5. Entriamo in modalità engineering digitando
    : debug os-shell



  6. Alla richiesta di password, utilizziamo la password recuperata precedentemente al punto 3 ......



    That's it.



venerdì 5 aprile 2019

Steps to move primary NSX manager role within of a Cross-vCenter implementation

This post comes from this request asked to the vCommunity. Essentially, he/she wonder understand if is it possible to move the primary NSX manager role within a Cross-vCenter implementation.

The answer is "YES" and is written here in "How Cross-vCenter NSX Works". If you change the role of a primary NSX Manager to standalone and any universal objects exist in the NSX environment, the NSX Manager will be assigned the transit role. The universal objects remain, but they cannot be changed, and no other universal objects can be created. You can delete universal objects from the transit role. The transit role should only be used temporarily, for example, when changing which NSX Manager is the primary.

Briefly the steps are:
  1. Perform a Backup of the all NSX Managers you have deployed into your environment
  2. Perform Universal Synchronization (before doing any action)
  3. Select the Primary NSX Manager and Remove Primary role (Now all NSX manager change in Transit Mode)
  4. Now switch on "NSX Controller Nodes" and clean up (deleting) all the controllers.
  5. Then switch back to the tab "NSX Managers" and select the New NSX Manager that you want to become Primary and Assign the Primary Role.
  6. Create new Controllers assigned to the New Primary NSX Manager
  7. When correctly deployed.... switch back to the tab "NSX Managers"
  8. Select the New Primary NSX Manager and -> Actions -> Add Secondary Manager (Proceed accepting the certificate until the end)
  9. Repeat for the others NSX Manager .....
  10. Verify that the Communication Channel is healty


But, let's covering the process down here in detail, step by step, with screenshots. To do so, I used the HOL-1925-01-NET provided from VMware.

First of all, a quick check on Primary and Secondary NSX Managers that "Segment IDs" doesn't overlap. In our case we have only one primary and one secondary, we don't have more than one secondary NSX Manager.





... and that "Universal Segment ID Pool" must be the same cross-vCenter (in our case "10000-10999" as shown above).

I created two new objects (in our case Logical Switch), the first one "LM_local" assigned to local transport zone and second one "LM_Universal" assigned to a Universal Transport Zone (that span across vCenters); just to be sure that everything works fine.


the result is ...



Perform a "Universal Synchronization" from the Primary NSX Manager (192.168.110.42)






Select the Primary NSX Manager and Remove Primary role (Now all NSX manager change in Transit Mode)





Now switch on "NSX Controller Nodes" and clean up (deleting) all the controllers.





Then switch back to the tab "NSX Managers" and select the New NSX Manager that you want to become Primary (in our case 192.168.210.42) and Assign the Primary Role.






Create new Controllers assigned to the New Primary NSX Manager (192.168.210.42)







When correctly deployed.... switch back to the tab "NSX Managers"
Select the New Primary NSX Manager and -> Actions -> Add Secondary Manager (192.168.110.42) and proceed accepting the certificate until the end.








Repeat for the others NSX Manager .....
Verify that the Communication Channel is healthy



If the "Communication Channel Health" is not green wait few second .... or try to force the communication ... and everything will go UP




Let's check the Logical Switch previously created and, as aspected, we can see that the "LM_Universal" is present on the new Primary as Universal Object and that "LM_local" is present only locally on the new Secondary NSX Manager.




Now to verify that everything is working fine, let's create a new universal object, of course must be created on the Primary NSX Manager and we verify that will be properly propagated on the Secondary as well.




That's it.