VMware

Prethodna lekcija završila se testiranim planom oporavka. Ova lekcija obrađuje trenutak u kojem monitoring, korisnik ili administrator prijavi da usluga više ne ispunjava očekivani nivo: kako ograničiti štetu, sačuvati dokaze, vratiti poslovnu funkciju, pravilno eskalirati problem i dokazati da se isti osnovni uzrok neće ponoviti. Incident nije isto što i problem, promena ili disaster recovery događaj. Incident je neplanirani prekid ili degradacija usluge; problem je uzrok jednog ili više incidenata; promena je kontrolisana intervencija; disaster recovery aktivira se kada lokalni oporavak ne može da ispuni dogovoreni RTO i RPO.

1. Ishodi učenja i operativni okvir

Nakon ove lekcije administrator treba da ume da:

• razdvoji simptom, obim, poslovnu posledicu, neposredni tehnički uzrok i osnovni uzrok;
• odredi prioritet incidenta prema uticaju i hitnosti, a ne prema glasnoći prijave;
• uspostavi vremensku osu iz događaja, alarma, metrika, logova, audit traga i evidencije promena;
• prikupi ESXi i vCenter support bundle bez nepotrebnog opterećenja ili gubitka podataka;
• vodi komunikaciju, eskalaciju i tehnički handoff sa proverljivim podacima;
• primeni privremeno zaobilazno rešenje, validira oporavak i kontroliše povratak promene;
• izradi RCA zasnovan na dokazima i pretvori nalaz u merljivu korektivnu i preventivnu akciju.

2. Životni ciklus incidenta: od signala do zatvaranja

U većem incidentu odvojene su uloge incident commander-a, tehničkih vodilaca za compute, mrežu, storage, backup i aplikaciju, zapisničara i osobe zadužene za komunikaciju. U manjem okruženju jedna osoba može nositi više uloga, ali ne sme nestati razdvajanje odgovornosti: ko odlučuje, ko izvršava i ko beleži. Incident commander upravlja prioritetima i rizikom; ne mora lično da izvršava svaku komandu.

3. Trijaža: simptom, obim, uticaj i prioritet

Prva prijava je često opis korisničkog iskustva, a ne dijagnoza. „VMware ne radi” može značiti nedostupan vSphere Client, prekid vCenter upravljačke ravni uz VM-ove koji i dalje rade, izolovan ESXi host, storage zastoj, mrežni gubitak ili problem same aplikacije. Zato početni zapis mora da odgovori na pitanja: šta je pogođeno, šta nije, od kada, da li je kvar stalan ili povremen, šta se promenilo neposredno pre toga i postoji li rizik po integritet ili poverljivost podataka.

4. Zlatni zapis incidenta i vremenska korelacija

Pouzdan zapis incidenta predstavlja zajedničku istinu tima. Mora sadržati identifikator, servis i vlasnika, okruženje i verzije, pogođene objekte, početak i način detekcije, uticaj, prioritet, poslednju poznatu dobru tačku, nedavne promene, aktivne hipoteze, prikupljene dokaze, sve izvršene akcije i rezultate, odluke i odobrenja, status komunikacije, vreme oporavka i preostali rizik. Lozinke, tokene i privatne ključeve ne upisivati u tiket.

Incident: INC-2026-0048
Vremenska zona: UTC
Početak simptoma: 2026-07-14T08:17:00Z
Detekcija: alarm + prijava aplikativnog tima
Uticaj: 18 VM-ova sa povišenom storage latencijom; nema potvrđenog gubitka podataka
Nije pogođeno: drugi datastore i management mreža
Poslednja poznata dobra tačka: 2026-07-14T08:10:00Z
Poslednja promena: CHG-2026-0312, storage zoning, završeno 08:05Z
Hipoteza H1: degradirana ili nestabilna storage putanja
Dokazi: vCenter events, vmkernel.log, storage telemetry, support bundle
Sledeće ažuriranje: 09:00Z
Vlasnik incidenta: I. Prezime

Svi sistemi moraju imati ispravno vreme i dokumentovan NTP izvor. Korelacija bez iste vremenske osnove stvara lažan redosled događaja. Čuvaju se apsolutno vreme i vremenska zona, a ne samo „pre deset minuta”. Posebno se beleže trenutak simptoma, alarm, početak i kraj svake intervencije, povratak tehničkih metrika i potvrda korisnika.

5. Dokazi pre intervencije: od najmanje invazivnih provera

1. Potvrdi signal: ponovi bezbednu proveru iz drugog izvora; razlikuj nedostupan UI od nedostupne usluge.
2. Odredi obim: jedan VM, host, klaster, datastore, VLAN, vCenter servis ili više lokacija.
3. Proveri zavisnosti: DNS, NTP, identitet, sertifikate, fizičku mrežu, storage fabric, backup i aplikativnu bazu.
4. Pregledaj promene: taskove, evente, audit trag, lifecycle operacije, automatizaciju i promene izvan VMware domena.
5. Sačuvaj prolazne podatke: trenutne alarme, performansne metrike, stanje putanja, servisni status, memorijske ili crash artefakte kada su relevantni.
6. Formuliši hipotezu: navedi dokaz koji bi je potvrdio i dokaz koji bi je opovrgao.
7. Tek tada menjaj stanje: jedna kontrolisana promena po koraku, sa validacijom i rollback kriterijumom.

Read-only provere u vSphere Client-u obuhvataju Monitor > Issues and Alarms, Tasks and Events, performansne grafikone i health prikaze. Na ESXi Shell-u sledeće komande čitaju stanje; izvršavaju se samo kada je Shell/SSH dozvoljen politikom, sa odgovarajućim privilegijama i uz audit zapisa:

# READ-ONLY: identitet/verzija, vreme, filesystem i osnovni storage/mrežni pregled
vmware -vl
date
esxcli system time get
esxcli system ntp get
vdf -h
esxcli storage core path list
esxcli network nic list
esxcli network ip interface list

Izlaz se čuva uz incident. Komande nad velikim inventarom mogu dati obiman rezultat, ali ne menjaju stanje. Ako se i read-only komanda blokira, to je dokaz mogućeg problema sa storage-om, filesystem-om ili management servisom; ne ponavljati je agresivno.

6. Mapa vSphere logova i pravilno tumačenje

Na savremenom ESXi-u kanonske lokacije su pod /var/run/log; kompatibilne putanje pod /var/log mogu postojati. Na vCenter Server Appliance-u servisni logovi su pod /var/log/vmware. Windows vCenter je istorijski model: deprecated je u 6.7, a od vSphere 7.0 vCSA je jedina opcija. Rotirane i kompresovane datoteke moraju se uključiti kada incident prethodi aktivnom logu.

# READ-ONLY na ESXi Shell-u: ograničen vremenski i tekstualni pregled
tail -n 200 /var/run/log/vmkernel.log
grep -Ei 'apd|pdl|nmp|timeout|error|failed' /var/run/log/vmkernel.log | tail -n 100
tail -n 200 /var/run/log/hostd.log

# READ-ONLY na vCSA Bash shell-u
service-control --status --all
df -h
tail -n 200 /var/log/vmware/vpxd/vpxd.log

Filter je početna navigacija, ne dokaz sam po sebi. Reč error može biti posledica, ponovljeni retry ili bezazlen raniji događaj. Tumačenje zahteva komponentu, timestamp, objekt, identifikator zadatka i susedne redove. Ne povećavati logging na verbose/trivia nivo u produkciji bez razloga: raste I/O i potrošnja prostora, može prikupiti osetljivije podatke i zahteva plan vraćanja prethodnog nivoa.

7. Support bundle: sadržaj, izbor obima i bezbednost

Support bundle je vremenski snimak dijagnostičkih podataka: logova, konfiguracionih i statusnih informacija, a zavisno od izbora i proizvoda može uključiti performansne podatke, core dump ili širi skup osetljivih podataka. On nije backup i nije automatska RCA analiza. Njegova vrednost zavisi od pravilnog trenutka, obima i opisa incidenta.

• Prikupljanje započeti što bliže incidentu, po mogućstvu pre restarta i pre rotacije logova.
• Odabrati samo relevantne hostove i komponentne grupe, osim kada je obim nepoznat ili podrška zahteva kompletan paket.
• Performansne podatke uključiti kada su potrebni i uskladiti trajanje/interval sa simptomom; širi zahvat traje duže i povećava paket.
• Proveriti slobodan prostor na ciljnom filesystem-u ili datastore-u pre generisanja.
• Arhivu čuvati uz strogu kontrolu pristupa, propisani retention i odobren kanal prenosa; ne slati javnim servisima.
• Ne menjati sadržaj paketa namenjenog podršci. Zabeležiti naziv, veličinu i kontrolni zbir radi integriteta pri internom prenosu.

7.1. Prikupljanje kroz vSphere Client i VAMI

Za ESXi host ili skup hostova u Hosts and Clusters izabrati objekat, zatim Export System Logs. Za objedinjeno prikupljanje mogu se izabrati relevantni hostovi, opcija uključivanja vCenter Server i vSphere UI Client logova, kao i performansni podaci kada su opravdani. Za vCenter-only paket dostupan je i VAMI na portu 5480, opcija Actions > Create Support Bundle. Potrebna je odgovarajuća administrativna privilegija; za host dijagnostiku zvanična dokumentacija navodi Global.Diagnostics.

7.2. ESXi vm-support

# READ-ONLY u smislu konfiguracije, ali resursno intenzivno: generiše arhivu
vm-support

# Upis paketa na prethodno provereni shared VMFS datastore
vm-support -w /vmfs/volumes/incident-staging

# Prvo proveriti opcije baš na instaliranoj verziji
vm-support -h

Komanda se izvršava kao root preko DCUI/ESXi Shell-a ili privremeno omogućenog SSH-a. Ne menja konfiguraciju vSphere-a, ali troši CPU, memoriju, I/O i prostor, pa nije bez uticaja. Opcije se razlikuju između verzija; zbog toga je izlaz vm-support -h na konkretnom hostu merodavan. Opcija -w usmerava izlaz na proverenu lokaciju i smanjuje rizik punjenja lokalnog prostora. Streaming preko SSH-a postoji, ali nije primenljiv u lockdown mode-u i mora pratiti bezbednosnu politiku.

7.3. vCenter Server Appliance vc-support

# READ-ONLY provere prostora pre generisanja paketa
df -h
vc-support -h

# GENERIŠE ARHIVU; cilj birati tek posle provere prostora
vc-support -w /storage/core

Komande se izvršavaju u Bash shell-u vCSA sa privilegovanim nalogom u skladu sa politikom. Podrazumevani paket može biti velik jer obuhvata servise i core dump podatke; za usko definisan problem zvanični KB opisuje komponentno ograničeno prikupljanje. Putanju iz primera ne kopirati mehanički: izabrati filesystem sa dovoljnim prostorom. Poznat problem u nekim vCenter 8.0 izdanjima ostavlja pakete u /storage/log; Broadcom navodi da je ispravljen u 8.0 Update 3 i novijim izdanjima. Čišćenje se radi tek posle potvrde preuzimanja, u skladu sa tačnim KB-om i change procedurom.

7.4. Integritet i evidencija paketa

# Na bezbednoj Linux administratorskoj stanici, ne na opterećenom ESXi hostu
sha256sum esx-host01-incident-INC-2026-0048.tgz
ls -lh esx-host01-incident-INC-2026-0048.tgz

Kontrolni zbir ne potvrđuje da je paket semantički potpun, ali dokazuje da se isti bajtovi koriste tokom internog prenosa i analize. Evidencija sadrži izvorni objekat, vreme generisanja, vremensku zonu, incident/SR broj, veličinu, hash, vlasnika, lokaciju i datum brisanja. Ako paket sadrži core dump, primenjuje se stroža klasifikacija; zvanična dokumentacija upozorava da vCenter core dump podaci nisu šifrovani.

8. Eskalacija Broadcom podršci i kvalitetan tehnički handoff

Support Request treba otvoriti prema važećem entitlement-u i nivou ozbiljnosti. Severity ugovora nije zamena za interni prioritet, i mora verno opisivati stvarni produkcioni uticaj. Paket se prenosi samo metodom vezanom za SR koju navodi Broadcom Support Portal. Dobar handoff skraćuje vreme do korisne analize i sadrži:

• jasan problem statement: očekivano naspram stvarnog ponašanja;
• proizvod, build broj, topologiju, licencni/support okvir i pogođene objekte;
• UTC timeline, poslovni uticaj, učestalost i reproduktivnost;
• poslednju poznatu dobru tačku i sve relevantne promene;
• tačne korake i rezultate već izvršenih provera, bez prećutkivanja restarta ili workaround-a;
• nazive bundle-ova, vreme prikupljanja i objašnjenje šta se u njima očekuje;
• konkretno pitanje i granicu odobrenih intervencija.

9. Oporavak usluge, workaround i kontrola promena

Restore service i resolve root cause su različiti ciljevi. Privremeno preusmeravanje workload-a, izolovanje problematičnog hosta ili vraćanje poznate konfiguracije može ispuniti RTO, ali incident ostaje povezan sa problem record-om dok uzrok i trajna mera nisu rešeni. Emergency change mora imati makar minimalno odobrenje, tačan obim, pre-check, očekivani rezultat, stop-uslov, rollback i post-check.

Tehnička validacija proverava stanje hostova, vCenter servisa, datastore-a, mrežnih putanja, HA/DRS alarma i performansi. Poslovna validacija proverava aplikativnu transakciju, integritet podataka i korisnički tok. Incident se ne zatvara zato što je alarm postao zelen ako usluga još nije potvrđena.

10. RCA: od neposrednog uzroka do sistemskog objašnjenja

Root Cause Analysis nije potraga za krivcem niti prepričavanje vremenske ose. Dobar RCA razlikuje: trigger koji je pokrenuo događaj, neposredni tehnički uzrok koji je proizveo simptom, osnovni uzrok zbog kojeg je sistem bio podložan kvaru i doprinoseće faktore koji su povećali uticaj ili usporili oporavak. Tvrdnja je prihvatljiva samo ako je podržana dokazom ili jasno označena kao ograničena hipoteza.

10.1. Pet „zašto”, fault tree i granice zaključka

Metoda „pet zašto” korisna je za linearne lance, ali ne sme nasilno proizvesti jedan uzrok u distribuiranom sistemu. Fault tree ili mapa uzročnosti bolji su kada se prepliću failure domeni: pogrešna promena, nedovoljna redundansa, neadekvatan alarm i spor handoff. RCA mora navesti koje podatke nije bilo moguće pribaviti i koliki je nivo sigurnosti zaključka. „Ljudska greška” nije dovoljan osnovni uzrok; potrebno je objasniti zašto je sistem dopustio da jedna očekiva ljudska omaška proizvede ozbiljan incident.

10.2. Korektivne i preventivne akcije (CAPA)

Akcija mora biti SMART: konkretna, merljiva, dodeljena vlasniku, vremenski ograničena i proverljiva. „Povećati pažnju” nije korektivna mera. Dobre mere uklanjaju uzrok ili jačaju kontrolu: ispravka konfiguracije, podržani patch posle kompatibilnosne provere, automatizovani pre-check, bolji alarm, runbook, uklanjanje single point of failure-a ili test oporavka. Svaka akcija dobija kriterijum delotvornosti; na primer, game day mora dokazati da pogrešna promena biva blokirana ili otkrivena pre poslovnog uticaja.

11. Praktikum: incident od alarma do zatvorenog RCA

Vežba 1 – Trijaža bez promene stanja

Cilj i kontekst: u laboratoriji je jedan ESXi host prikazan kao disconnected/not responding, dok testni VM odgovara na aplikativni health check. Cilj je dokazati da prekid upravljačke ravni nije automatski prekid workload-a.

Topologija i preduslovi: vCSA, dva laboratorijska ESXi hosta, shared datastore i jedan nekritičan testni VM; sinhronizovan NTP; nalog sa read-only pristupom inventaru, događajima i performansama; poseban privilegovani nalog dostupan samo za kasniju odobrenu akciju. Ne izazivati stvarni storage ili mrežni prekid: instruktor može zadati istorijski događaj ili kontrolisano blokirati samo management putanju izvan produkcije.

1. Otvoriti incident, zapisati UTC vreme, izvor prijave, pogođeni host i testni VM.
2. Iz dve nezavisne tačke proveriti aplikativni health test i zabeležiti da li workload radi.
3. U vSphere Client-u prikupiti alarm, Tasks/Events i performansni grafikon za interval deset minuta pre i posle simptoma.
4. Proveriti da li su drugi hostovi, datastore i management mreža pogođeni; ne restartovati agente.
5. Pregledati poslednje promene i formulisati najmanje dve hipoteze: management mreža/DNS ili lokalni management agent.
6. Za svaku hipotezu navesti dokaz koji je potvrđuje i opovrgava. Odrediti prioritet prema poslovnom uticaju, uz rizik gubitka redundanse.

Očekivani rezultat i validacija: zapis jasno razlikuje vCenter prikaz, dostupnost ESXi management-a i rad VM-a; nema neodobrene promene stanja; timeline i sledeći bezbedan korak mogu da preuzmu drugi administratori.

Rollback: nije potreban jer je vežba read-only. Ako je korišćena laboratorijska mrežna simulacija, instruktor uklanja isključivo pravilo kojim je ona uvedena i proverava reconnect hosta.

Vežba 2 – Ciljano prikupljanje dokaza i support bundle-a

Cilj: prikupiti dokazni paket za vremenski ograničen incident bez punjenja sistemskih particija i bez nepotrebnog izlaganja podataka.

Rizik: generisanje paketa troši resurse i prostor. Vežbu izvoditi samo na laboratorijskom hostu. Ne uključivati memorijske dump opcije ili suspenziju VM-a; takvi postupci su invazivni i izvršavaju se isključivo po specifičnom vendor uputstvu i odobrenju.

1. Proveriti verziju, trenutno vreme i slobodan prostor read-only komandama iz prethodnih odeljaka.
2. Napraviti staging direktorijum na laboratorijskom datastore-u samo ako je unapred odobren i ima dovoljno prostora.
3. Pokrenuti vm-support -w /vmfs/volumes/incident-staging. Ne prekidati proces osim ako ugrožava host; zabeležiti početak, kraj i prijavljenu putanju.
4. Preneti arhivu na zaštićenu administratorsku stanicu odobrenim kanalom; izračunati SHA-256 i zabeležiti veličinu.
5. Proveriti da arhiva može da se izlista bez greške, ali je ne menjati:

# Na administratorskoj Linux stanici
gzip -t esx-host01-incident-INC-2026-0048.tgz
tar -tzf esx-host01-incident-INC-2026-0048.tgz | head -n 30
sha256sum esx-host01-incident-INC-2026-0048.tgz

Moguće grane: ako GUI export timeout-uje, prikupljanje pokrenuti lokalno na relevantnom hostu; ako nema prostora, ne brisati nasumične fajlove, već promeniti odobrenu ciljnu lokaciju; ako nedostaju očekivani logovi, proveriti izabrane manifest/grupe, trenutak rotacije i zvanični KB za konkretan build.

Kriterijum završetka i rollback: paket ima evidenciju izvora, vremena, veličine i hash-a. Posle potvrđenog prenosa i isteka internog retention-a, laboratorijska kopija i staging direktorijum uklanjaju se kontrolisano; trajno čuvanje ostaje samo u odobrenom repozitorijumu.

Vežba 3 – Korelacija logova i testiranje hipoteze

Cilj: povezati vCenter događaj, ESXi log i eksterni storage zapis bez zaključivanja na osnovu jedne poruke.

1. Definisati incidentni prozor, na primer od 08:05Z do 08:35Z, i normalizovati sve timestamp-ove na UTC.
2. U izdvojenoj kopiji paketa pronaći relevantne vmkernel, hostd i vpxa logove; sačuvati kontekst pre i posle pogotka.
3. Napraviti tabelu: vreme, izvor, objekat, događaj, tumačenje i stepen sigurnosti.
4. Uporediti sa storage telemetry-jem i change zapisom. Potvrditi da isti identifikator uređaja/putanje i vreme povezuju nalaze.
5. Dokumentovati alternativno objašnjenje i razlog zbog kojeg je odbačeno.

Očekivani rezultat: hipoteza nije „u logu piše error”, već proverljiv uzročni iskaz. Ako dokazi nisu dovoljni, rezultat je „uzrok nije dokazan” sa preciznim spiskom podataka koji nedostaju.

Vežba 4 – Oporavak, komunikacija i trajna mera

Cilj: izraditi emergency change i RCA za simulirani problem storage putanje, bez stvarnog prekida produkcije.

1. Definisati workaround, na primer povratak laboratorijske zoning promene, očekivani efekat, rizik, stop-uslov i rollback.
2. Pre izvršenja sačuvati stanje putanja; dobiti odobrenje instruktora/incident commander-a i zabeležiti vreme.
3. Izvršiti samo unapred pripremljen laboratorijski rollback iz domena storage tima. VMware administrator zatim read-only proverava stabilnost putanja, datastore dostupnost i latenciju.
4. Validirati testnu aplikativnu transakciju i pratiti najmanje jedan dogovoreni interval bez novih alarma.
5. Napisati statusnu poruku: uticaj, trenutno stanje, primenjena mera, rizik i vreme sledećeg ažuriranja.
6. Popuniti RCA: trigger, neposredni i osnovni uzrok, doprinoseći faktori, dokaz, workaround, trajne akcije, vlasnici, rokovi i kriterijum delotvornosti.

Kriterijum završetka: tehnička i poslovna validacija su uspešne, incident timeline je potpun, a najmanje jedna korektivna akcija uklanja uzrok i jedna detekciona akcija skraćuje budući MTTD. Vežba se vraća u dokumentovano početno stanje.

12. Administratorske prakse

• Održavaj runbook, matricu eskalacije, kontakte, support entitlement i testiran kanal za upload pre incidenta.
• Centralizuj ESXi/vCenter logove i uskladi retention sa vremenom potrebnim za detekciju; lokalni rotirani log ne sme biti jedini dokaz.
• Sinhronizuj vreme preko pouzdanih NTP izvora i nadgledaj odstupanje.
• Za svaki kritičan servis dokumentuj vlasnika, zavisnosti, SLO, RTO/RPO, health test i kriterijum poslovnog oporavka.
• Ne koristi root/Administrator nalog za rutinski pregled; dodeli najmanje privilegije, a privilegovane sesije audituj.
• Ne restartuj, ne briši logove i ne menjaj nivo logovanja pre očuvanja dokaza i procene blast radius-a.
• Odvoji restore service od RCA/problem procesa; workaround dobija rok i vlasnika da ne postane trajni dug.
• RCA vodi bez okrivljavanja, ali sa jasnom odgovornošću za sprovođenje i proveru akcija.
• Periodično sprovedi game day iz Dodatka 3 i meri MTTD, vreme do trijaže, MTTR, kvalitet handoff-a i procenat izvršenih RCA akcija.

13. Završna kontrolna tačka

Lekcija je savladana kada administrator može da dokaže da ume da:

• iz prve prijave izdvoji simptom, obim, uticaj, hitnost i preostali rizik;
• napravi UTC timeline koji povezuje monitoring, događaje, promene, metrike i logove;
• odabere tačan ESXi/vCSA log i objasni šta iz njega može, a šta ne može zaključiti;
• bezbedno prikupi ciljani support bundle, proveri prostor, integritet i evidenciju prenosa;
• razlikuje read-only proveru, resursno intenzivno prikupljanje i state-changing korekciju;
• napiše vendor eskalaciju koju drugi inženjer može odmah da reprodukuje i nastavi;
• definiše workaround, stop-uslov, rollback i tehničku i poslovnu validaciju;
• izradi dokazni RCA sa osnovnim uzrokom, doprinosećim faktorima i merljivim CAPA akcijama;
• zatvori incident tek posle potvrđene stabilnosti, kompletne evidencije i dogovorenog daljeg vlasništva.

Zaključak

Zreo VMware administrator ne meri kvalitet incident response-a brojem izdatih komandi, već sposobnošću da brzo ograniči posledice, očuva činjenice i donosi reverzibilne odluke zasnovane na dokazima. vCenter događaj, ESXi log, support bundle i vendor SR postaju vredni tek kada su smešteni u tačnu vremensku i poslovnu sliku. Oporavljena usluga završava hitnu fazu, ali tek RCA i proverena trajna mera zatvaraju krug učenja. Time se incident pretvara iz neplaniranog prekida u dokazano poboljšanje dostupnosti, bezbednosti, održavanja i sposobnosti oporavka cele platforme.