Tag Archives: ESXi

Despre timestamp in log-uri pe ESXi

Uneori mai ajungem să analizăm înregistrări în log-uri pe host-uri ESXi. Pentru referință, acestea sunt întotdeauna însoțite cu un timestamp (marcaj de timp) care ne ajută să localizăm în timp un eveniment sau altul. Valoarea timestamp-ului la un moment dat se deduce din valoarea clock-ului de sistem pentru acel moment, așa că pentru o localizare corectă a evenimentelor avem nevoie de un clock setat corect sau și mai bine sincronizat la o sursa de timp de referință. Sincronizarea la o sursă de referință comună e cu atât mai importantă cu cât avem de corelat mai mult evenimente pe mai multe sisteme separate.

Ceea ce vreau să descriu mai jos e modul in care se formează timestamp-urile in log-urile pe ESXi. Pentru claritate vom face următoarele câteva teste simple:

  • configurăm serverul ESXi pentru o sincronizare a ceasului de sistem la o sursă de timp de referință.  
  • verificam valorile pentru system time pină și după sincronizarea cu sursa de referință
  • producem un eveniment pe ESXi după care analizam în log-uri amprenta lăsată de acesta. Verificăm modul în care se formează timestamp-ul.

Așadar, pe ESXi (eu am folosit unul nested in VMware Workstation) accesăm setările de timp prin vSphere Client – Host – Configuration – Software – Time Configuration. În fereastra deschisă verificăm valoarea curentă Date & Time care cel mai probabil e abătută de la timpul și data corectă. Tot de aici se observă că nu avem setat nici un server sursă de timp de referință (NTP server) – configurație implicită. 

Printr-un click pe Properties (link dreapta sus) deschidem fereastra Time Configuration în care reconfigurăm timpul și data la valorile curente. Intenționat, introducem o abatere mică pe timp (de câteva minute) astfel încât să observăm mai târziu efectul sincronizării cu un server NTP. Se recomandă ca înainte de a configura serverul NTP de ajustat manual timpul si data la cât mai aproape de valorile curente, motivul nu-l cunosc dar intuiesc că sincronizarea are loc iterativ și cu cât ceasul de sistem e mai aproape de adevăr cu atât mai puține iterați au loc deci și o durata mai scurtă pentru perioada de sincronizare totală (trebuie verificat). 

În fereastra Time Configuration click pe Options …  după care in NTP Daemon (ntpd) Option – NTP settings specificam un server NTP (din Internet sau intern din rețeaua companiei). Tot de aici (general settings) ne asigurăm că avem pornit clientul și că acesta va porni automat cu pornirea serverului ESXi.

about_esxi_timestamps_NTP_daemon_options

Așteptăm câteva minute după care comparăm valorile pentru timpul pe ESXi și ceasul de referință – acesta ar trebui să ajungă identice. Într-adevăr in cazul meu NTP-ul și-a făcut treaba și am obținut un timp identic cu sursa de referință.

about_esxi_timestamps_NTP_initial_time

Verificam aceeași data și timp cu următoarele două comenzi din consola ESXi –ului (un pic delayed pentru că am luat screen-urile la diferite momente de timp):

about_esxi_timestamps_time_from_console

Se observă un lucru interesant: Timpul obținut din CLI e cu două ceasuri mai devreme decât ora din vSphere Client. Există o diferență de două ore, 9:22 in comparație cu 11:22. Ora curentă e cea cu 11:22, iar timpul -2 e timpul in reprezentare UTC (timpul universal coordonat). De unde știe ESXi-ul să adauge exact 2 ore că prezinte ora curentă în vSphere Client ? Pentru că nu am configurat nici-unde în altă parte Time Zone intuiesc că acesta se scoate tot prin NTP (trebuie verificat).

De ce m-am legat de subiectul ăsta e pentru că ESXi-ul folosește ca timestamp in log-uri tocmai valoarea în UTC și nu cea curentă (pe care o citim pe ceasul de mănă). Deci odată apucat de analizat log-uri e important să luăm în calcul și ajustarea de +2 ore: la timestamp-ul din log adăugăm două ore ca să ajungem la timpul curent.

Mai este un moment important de remarcat. Plus două ore menționate mai sus sunt valabile doar pentru perioada de iarna nu și cea de vara când va trebui să adăugam deja +3 ore la timestamp-urile din log-uri. Diferența se datorează sistemului de  Daylight Saving Time.  Valorile de +2/+3 reprezintă fusul orar in care se află Republica Moldova, pentru alte țări se folosesc valorile corespunzătoare fusului orar.

Pe final să generam un eveniment pe ESXi după care să urmărim amprenta in unul din log-uri. Cel mai simplu e sa pornim un VM după care sa analizam vmware.log la VM-ul respect. Cu fiecare re-pornire de VM fișierul vmware.log pornește de la început așa că în cazul nostru vom urmări doar evenimentele legate de ultima pornire a VM-ului. Așadar, am pornit VM-ul TEST-VM la ora 11:55 după care am deschis fișierul vmware.log din folderul VM-ului pe datastore (excerpt mai jos):

about_esxi_timestamps_crop_vmware.log

Din screen re-confirmăm că timestamp-ul e deplasat cu 2 ore în trecut (-2) față de ora curentă: 9:55 in comparație cu 11:55. De menționat că în interfață peste tot se afișează totuși ora curent, ca exemplu am urmărit data creării fișierului vmware.log în datastore browser care este afișat ca 11: 55 (coincide cu moment pornirii VM-ului).

Dual boot Windows și ESXi instalat pe stick USB

Mai devreme sau mai târziu unul din studenții din clasele noi de VMware îmi dă aceeași “Cum ai configurat dual boot-ul de Windows și ESXi pe PC-urile din clasă ?” Ca să am explicația la îndemână am să fac o descriere pe pași pentru configurația de dual boot utilizată pe PC-urile din clasa de VMware academie DNT. Dual boot-ul e configurat intre două sisteme de operare: unul de Windows 7 (pre-instalat) și o imagine ESXi instalată pe un stick USB.

Înainte să continuu e bine să explic contextul în care am avut nevoie de dual booting pe PC-urile din sala de studiu VMware. Încă de la bun început s-a pus problema ca în cadrul orelor practice VMware să putem organiza scenarii complexe de laborator cu minim de achiziție de echipament. Printre soluții, varianta cu destinație dublă pentru PC-urile deja instalate sa dovedit a fi cea mai potrivită, pe de-o parte PC-urile le putem folosi ca desktop-uri cu Windows iar pe de altă parte ca host-uri ESXi in scenariile de laborator. Configurația am realizat-o cu dual boot intre SO-ul Windows deja instalat pe discul rigid și imagine ESXi instalată pe un stick USB compact fixat in spatele PC-ului. Drept datastore pentru VM-uri pe ESXi folosim spațiul pe un server iSCSI dedicat.

Ce opțiuni am încercat pentru dual-boot ?

Ca să găsim o variantă mai optimă am încercat câteva opțiuni pentru dual-boot:

  • dual-boot Windows vs ESXi pe același disk rigid, idee care sa dovedit a fi imposibil de implementat. Problema e că procesul de setup ESXi distruge automat restul partițiilor pe disk și deci și pe cea de Windows. ESXi-ul nu e prea prietenos când vine vorba de a partaja același disk cu alte sisteme de operare.
  • dual-boot Windows vs ESXi pe disk-uri rigide separate – indezirabil pentru că: (1) nu avem spațiu liber pentru un disk nou in case-urile PC-urilor (Optiplex 780 – ultrasmall form factor) și (2) implica achiziții in plus pentru 10 HDD-uri noi (3) overhead de spațiu pe dikc-urile noi – o imagine de ESXi nu are nevoie de mai mult de câțiva GB pentru setup.
  • dual-boot Windows vs ESXi cu imagine ESXi instalată pe stick USB extern. Soluție realizabilă și practică pentru că: (1) minim investiții – doar pentru 10 stick-uri de 4GB noi (2) partițiile Windows pe disk-ul existent nu sunt atinse (3) configurație simplă.

Evident că am mers pe varianta cu ESXi-ul instalat pe stick-uri USB. Urma să găsim modul in care vom configura dual-boot-ul:

  • no at all – ne bazăm pe BIOS boot meniu, din care alegi fie USB pentru ESXi fie Hard Disk pentru Windows. Realizabil, dar cam non-practic: bunăoară nu poți să setezi ca meniul să-ți apară automat și dacă ai scăpat moment-ul pentru BIOS boot meniu (care e foarte scurt) ești nevoit să mai treci odată prin reboot.
  • or modificăm boot loader-ul din Windows în așa fel încât să fie posibilă și încărcarea ESXi.

Evident că am mers pe varianta cu modificarea boot loader-ului din Windows, configurație pe care o voi descrie în textul de mai jos.

dual_boot_esxi_and_win7_scheme

Cum se încarcă sistemele de operare Windows ?

Până a merge mai departe fac un overview scurt la cum se încarcă sistemele de operare Windows. Cred că de folos pentru ce urmează.

(1) Windows XP, Server 2003:

  • folosește NTLDR ca boot loader – hidden, boot partition, C:\
  • folosește boot.ini pentru boot configuration – hidden, boot partition, C:\
  • boot.ini conține opțiunile pentru boot menu.
  • boot.ini editabil cu notepad sau cu System Configuration Utility.
  • NTLDR e încărcat de loader-ul din MBR (VBR): bootstrap.
  • NTLDR încarcă ntoskernel.exe
  • aceeași partiție pentru system și boot partition

(2) Windows Vista, 7, Server 2008, 2012:

  • boot manager complet nou: Windows Boot Manager
  • folosește Boot Configuration Date (BCD) in loc de boot.ini
  • BCD in format Windows Registry: HKEY_LOCAL_MACHINE\BCD00000
  • BCD conține opțiunile pentru boot menu.
  • BCD poate fi modificat cu: bcdedit.exe, regedit.exe sau cu mai simplu cu EasyBCD.
  • Windows Boot Manager încarcă winload.exe
  • implicit partiții diferite pentru (1) system partition (boot loader files, no letter) și (2) boot partition (..\windows folder, c:\)

Instalare imagine ESXi pe stick-ul USB

Primul pas a fost să instalez ESXi-ul pe stick-urile USB. Inițial credeam că fac un install pe unul din stick-uri după care găsesc un tool cu care le clonez pe restul. Până la urmă le-am instalat de la zero pe fiecare, tool-urile de clonning pe care le-am încercat copiau rău de tot, iti lua o groza de timp pină făcea copua. Install-ul l-am făcut din VMware Workstation într-un VM la care am adus stick-urile USB. Printre altele, metodă documentată de VMware (link aici). Procedura pentru insalarea ESXi pe stick cu VMware Workstation se reduce la:

  • Creăm un VM pentru setup-ul de ESXi (2x vCPU, 4GB RAM, no HDD)
  • Montam CD/DVD-ul sau ISO file de instalare ESXi la VM
  • Pornim VM-ul după care facem pass-through in VM pentru dispozitivul stick-ului
  • Pornim procesul standard de setup. Se asigura ca installer-ul a detectat stick-ul.
  • După ce setup-ul este încheiat, shutdown la VM, eject USB stick.
  • ESXi-ul este instalat pe stick și gata de utilizare

Configurare boot menu in BCD pe Windows.

Acum că avem stick-ul cu ESXi preparat, il instalăm in unul din porturile USB pe PC. La academie am folosit cele mai mici posibile stick-uri USB, de 4GB, cu urechiușe, pe care le-am montat aproape invizibil în spatele PC-utilor, pentru siguranță le-am fixat suplimentar cu coliere din plastic pentru cabluri.

Pentru editare configurație boot BCD, prefer să folosesc EasyBCD care e simplu de utilizat și gratuit pentru non-comercial use (link aici). Tool-ul distribuit împreună cu sistemul de operare bcdedit.exe sau editarea directă a registrului nu sunt tocmai confortabile.

Așadar, după ce instalăm EasyBCD pe stația cu SO Windows (nu merită să descriu aici) parcurgem următorii pași pentru a configura dual-boot-ul cu imaginea ESXi:

  • Vom instala loader-ul GRUB (NeoGrub) care in serie cu Windows Boot Manager va încarcă loader-ul ESXi (syslinux bootloader). Serializam prin GRUB pentru că loader-ul ESXi nu poate fi inițiat din Windows Boot Manager. Din EasyBCD Toolbox click pe Add New EntryNeoGrub bootloader (install).
  • După install, pe disk-ul de sistem vor fi copiate fișierele bootloader-ului: neogrub, neogrub.mbr și menu.lst (ultimele in folderul NST pe root)
  • Din aceeași fereastră click pe Configure (sau edit fișier menu.lst cu notepad). În notepad-ul deschis inserăm configurația cu textul de mai jos:

Note1: Dacă mai tirziu nu funcționează, se va juca cu alte valori pentru hd1: hd2, hd3 …

  • Până aici suficient pentru dual boot, la repornirea PC-ului vor apărea consecutiv două ferestre de dialog pentru selecție opțiuni de boot: (1) una din Windows Boot Manager cu variante pentru Windows și GRUB și (2) a două din GRUB cu o singura variantă pentru disk-ul pe care este instalat ESXi-ul. In fereastra GRUB titlu opțiunii va fi cea specificată fișierul menu.lst după linia title.
  • Ce se mai poate de făcut e să redenumim opțiunile din Windows Boot Manager:

dual_boot_esxi_and_win7_modify_menu_entries

Așa că in final vom avea, primul dialog pentru Windows Boot Manager:

dual_boot_esxi_and_win7_windows_boot_manager_boot_menu

și dacă selectăm VMware ESXi urmează să se deschidă următorul boot menu:

dual_boot_esxi_and_win7_GRUB_boot_menu

Așa cum meniul din GRUB nu prea are sens (o singura opțiune care se selectează automat după timeout) e bine ca acesta sa nu mai fie afișat. Pentru asta in configurația GRUB setăm un timeout de 0 secunde așa că la momentul afișării se va trece automat peste el.

Configurațiile de mai sus au mers pentru ESXi 5.1/5.5 și sisteme de operare Windows Server 2008R2/Windows 7. Cred că și alte mix-uri funcționează.