mercoledì 11 settembre 2019

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.

lunedì 9 settembre 2019

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.

giovedì 5 settembre 2019

VxRail: How to reset the root password for VxRail Manager



Problema
Ho la necessità di dover accedere ad una appliance "VxRail Manager" senza però conoscere ne la password di root ne la password dell'utente di sistema mystic.

Soluzione
Il metodo più veloce per poter ri-accedere alla console è quello di ripristinare la password di root come indicato nel documento ufficiale EMC al link "VxRail: How to reset the root password for VxRail Manager".

Di seguito i passi indicati nel documento:

  1. Restart Guest (Not Reset) for VRM VM from vCenter & Press “e” at below screen

  2. Add init=/bin/bash as below screen (highlight in red circle), then press F10 or Control-x

  3. Try to change password by "passwd", but you might see below error;

    If above error - "Authentication token lock busy" popup, try:
    "mount -o remount rw -t ext3 /"
    "chmod -v 4711 /usr/bin/passwd"


  4. Try change password again by "/usr/bin/passwd"

  5. Exit from VRM Console, then click "Restart Guest" (Not Reset) on VRM VM from vCenter.

Tuttavia non è possibile eseguire il precedente punto 5 perché i VMware Tools non sono attivi ed il "Restart Guest" dal vCenter risulta disabilitato ...


Possiamo riavviare la VRM con i comandi "systemctl --force --force reboot" direttamente da linea di comando all'interno della console.


That's it.

lunedì 26 agosto 2019

PowerCLI 11.4.0 Updates - Automatic script to remove unnecessary modules improved


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

Il 20 Agosto scorso è stata rilasciata la nuova versione PowerCLI 11.4.0 che include numerosi nuovi miglioramenti. Il modulo Horizon View è stato aggiornato per supportare la versione più recente di Horizon View che è la versione 7.9. Esistono alcuni aggiornamenti al modulo Storage, inclusi gli aggiornamenti e tre nuovi cmdlet. Infine, ci sono numerosi aggiornamenti ai cmdlet nel modulo HCX.

Con PowerCLI 11.4.0 vengono forniti i seguenti aggiornamenti:

  • Add support for Horizon View 7.9
  • Added new cmdlets to the Storage module
  • Updated Storage module cmdlets
  • Updated HCX module cmdlets

maggiori informazioni possono essere trovare sul blog ufficiale VMware a questo link.

L'update della PowerCLI di per se è semplice, come indicato anche in un mio precedente post è sufficiente lanciare il comando 'Update-Module -Name VMware.PowerCLI' ... accettare premendo 'A' e listare i moduli disponibili sul sistema con il comando 'Get-Module -Name VMware.* -ListAvailable'


... e come per le precedenti versioni, utilizzando il comando Update-Module per aggiornare i moduli, le versioni esistenti non vengono rimosse. Come vediamo dall'immagine sopra ci sono righe che contengono gli stessi moduli ma con diverse versioni.

Esattamente come indicato nel precedente post "PowerCLI 11.0.0 Updates - Automatic script to remove unnecessary modules" procedo con la rimozione dei moduli non più necessari; utilizzando lo script per la rimozione automatica dei moduli più vecchi.

Lo script è stato modificato per avere un Output migliorato, nel seguente modo
#!/usr/local/bin/pwsh 
########################################################################################
#  File  : PurgeDuplicatePowerCliModules.ps1
#  Author: Lorenzo Moglie
#  Date  : 17.10.2018
#  Update : 26.08.2018
#  Version     : 1.5.0.0
#  Disclaimer  : The script is provided as is, use at your own risk.
#  Description : This script list the VMware Modules Available into a TXT file. Read 
#                the txt file, line by line and comparing the duplicate modules 
#                uninstalling the older version
#######################################################################################

Get-Module -Name VMware.* -ListAvailable | select Name,Version > ModuleList.txt
$NameStr = ""
$VersionApp = ""
$Report = @()
Get-Content ./ModuleList.txt | where {$_ -ne ""} | ForEach-Object { 
 $line=[regex]::Replace($_, "\s+", " ")
 $NameModule,$VersionModule = $line.split(' ')
 $tempModule=@{}
 if($NameStr -match $NameModule) {  
     $tempModule.NameModule = $NameModule
     $tempModule.VerOne = $VersionModule
     $tempModule.VerTwo = $VersionApp
     if ([System.Version]::Parse($VersionModule) -lt [System.Version]::Parse($VersionApp)){
      $tempModule.Removed_Ver = $VersionModule
      Invoke-Expression  "Uninstall-Module -Name $NameModule -RequiredVersion $VersionModule -force"
     } else {
      $tempModule.Removed_Ver = $VersionApp
      Invoke-Expression  "Uninstall-Module -Name $NameModule -RequiredVersion $VersionApp -force"
     }
     $temp = New-Object -TypeName PSObject -Property $tempModule
     $Report += $temp
 }
 $NameStr = $NameModule
 if (($VersionModule -match "Version") -Or ($VersionModule -match "-------")) {
   # Do Nothing 
 } else {
   $VersionApp = $VersionModule
 }
}
$Report | Select NameModule, VerOne, VerTwo, Removed_Ver | Format-Table -AutoSize 
rm ./ModuleList.txt


L'output è il seguente :

That's it.

mercoledì 14 agosto 2019

PowerShell script to retrieve information on VM

Problema
Recentemente mi è capitato di dover recuperare velocemente tramite script PowerShell alcune informazioni come:
  1. Nome Virtual Machine (Inventario vCenter)
  2. Sistema Operativo
  3. Indirizzo IP
  4. Nome host della VM (FQDN)
  5. Indirizzo MAC
per le Virtual Machine presenti in un determinato Datacenter.

Soluzione
Di seguito lo script in powershell per fare questo.
Connect-VIServer -Server <VCSA> -User <Userrname> -Password <Password>
$DTC = "<Datacenter>"

$Report = @()
ForEach ($VM in (Get-Datacenter $DTC) | Get-VM) {
 $tempvm=@{}
 $tempvm.Name = $VM.Name
 $tempvm.GuestOS = If (!$VM.Guest.OSFullName) {"Tools Not Running\Unknown"} Else {$VM.Guest.OSFullName}
 $tempvm.IP = If (!$VM.Guest.IPAddress[0]) {"Tools Not Running\Unknown"} Else {$VM.Guest.IPAddress[0]}
 $tempvm.FullName = If (!$VM.Guest.hostname) {"Tools Not Running\Unknown"} Else {$VM.Guest.hostname}
 $tempvm.MacAddress = (Get-NetworkAdapter -VM $VM.Name).MacAddress
 #$tempvm.CustomFields = $VM.CustomFields
 $temp = New-Object -TypeName PSObject -Property $tempvm
 $Report += $temp
} 
$Report | Select Name, GuestOS, IP, FullName, MacAddress |  Sort Name | Format-Table -AutoSize #Output on Screen
#$Report | Select Name, GuestOS, IP, FullName, MacAddress |  Sort Name | export-csv ".\Export-VMInfo.csv" #Output on file
Come possibile vedere dallo script sopra, l'output viene mostrato in formato tabella direttamente a video, ma può anche essere esportato e salvato in un file .CSV.


That's it!

giovedì 1 agosto 2019

PowerCli to configure and modify Syslog on Hosts ESXi - "update"

Qualche tempo fa ho scritto un post sul come configurare/modificare tramite powercli l'entry syslog degli host ESXi.
Tuttavia l'output che si ottiene non permette di verificare a quale host ESXi si riferisce la configurazione. Modificando gli script nel seguente modo possiamo ottenere il seguente risultato:

Ottenere Informazioni (attuali impostazioni)
foreach ($ESXi in Get-VMHost) {
 Get-AdvancedSetting -Name "Syslog.global.logHost" -Entity $ESXi.Name | Select @{L='Host';E={$ESXi.Name}}, Value
} Format-Table -AutoSize


Impostare syslog
foreach ($ESXi in Get-VMHost) {
 Get-AdvancedSetting -Name "Syslog.global.logHost" -Entity $ESXi.Name | Set-AdvancedSetting -Value "udp://10.1.1.1:514" -Confirm:$false | Select @{L='Host';E={$ESXi.Name}}, Value
} Format-Table -AutoSize


That's it!

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.