Praktični primeri – Modul 21 – Virtuelizacija i laboratorijsko okruženje

Ovaj dokument sadrži pet detaljno rešenih praktičnih primera i jedan integrativan poslovni scenario.

Primer 1 – Izbor tipa adaptera za tri različita scenarija

Situacija: Potrebno je odlučiti koji tip mrežnog adaptera koristiti za tri VM sa različitim namenama.

Rešenje:

• VM koja treba da preuzima ažuriranja sa interneta, ali ne treba da bude dostupna spolja: NAT (Tema 6).
• VM koja treba da bude vidljiva i dostupna sa telefona i drugih uređaja na kućnoj mreži: Bridged (Tema 5).
• Dve VM koje treba da komuniciraju isključivo međusobno, bez ikakvog pristupa internetu ili host računaru: Internal Network (Tema 8).

Objašnjenje: Izbor adaptera direktno prati potrebu za izolacijom naspram povezanosti — što je veća potreba za izolacijom (Internal Network), manja je povezanost sa spoljnim svetom; NAT i Bridged nude povezanost (internet, fizička mreža) po ceni manje izolacije.

Primer 2 – VM sa dva adaptera koja rutira između dva segmenta

Situacija: Potrebno je da centralna Ubuntu Server VM poveže dva odvojena Internal Network segmenta („LAN-A" i „LAN-B").

Konfiguracija (koncept, VirtualBox Settings za VM):

Adapter 1: Internal Network, ime "LAN-A"
Adapter 2: Internal Network, ime "LAN-B"

Konfiguracija unutar Ubuntu Server VM (Modul 18 veštine):

$ sudo sysctl -w net.ipv4.ip_forward=1

Objašnjenje: Sama konfiguracija dva adaptera (Tema 9) ne čini VM ruterom — Linux podrazumevano ne prosleđuje pakete između sopstvenih interfejsa dok se eksplicitno ne uključi IP forwarding. Nakon ovoga, klijenti na LAN-A i LAN-B mogu komunicirati kroz centralnu VM, pod uslovom da imaju ispravno podešene rute (default gateway) ka odgovarajućem interfejsu te VM (Modul 11 princip).

Primer 3 – Snapshot pre rizične izmene

Situacija: Pre nego što se na Windows Server VM iz Modula 17 primeni major ažuriranje operativnog sistema, potrebno je obezbediti brz način povratka ako nešto pođe po zlu.

Koraci:

1. Isključiti VM (ili je ostaviti uključenu, zavisno od tipa snapshot-a).
2. VirtualBox Manager → desni klik na VM → Take Snapshot → nazvati ga npr. „Pre-Update-2026-09".
3. Primeniti ažuriranje.
4. Ako nešto ne uspe: desni klik → Restore to „Pre-Update-2026-09".

Objašnjenje: Ovo je tačna primena Teme 10 — snapshot pruža brz, praktičan povratak na poznato dobro stanje u okviru iste VM/host kombinacije. Ovo NIJE zamena za pravi backup (Tema 11/Primer 4) — da je ceo host disk otkazao tokom ažuriranja, i VM i njen snapshot bi bili podjednako nedostupni.

Primer 4 – Export VM-a kao pravi backup

Situacija: Nakon što je Ubuntu Server VM iz Modula 18 potpuno konfigurisana (SSH, UFW, nginx), potrebno je napraviti pravu, nezavisnu kopiju za slučaj katastrofalnog kvara host računara.

Koraci:

1. VirtualBox Manager → File → Export Appliance.
2. Izabrati VM „LINUX1".
3. Format: OVA.
4. Sačuvati na eksterni disk ili cloud skladište (ne na isti host disk gde je originalna VM).

Objašnjenje: Za razliku od Primera 3, ovaj .ova fajl je potpuno samostalan (Tema 11) — može se prekopirati na drugi računar, čak i uvesti u VMware umesto VirtualBox-a, i ostaje upotrebljiv čak i da originalni host računar potpuno otkaže. Ključna praktična razlika: ovo treba ponoviti nakon svake značajne izmene da bi backup ostao ažuran, za razliku od snapshot stabla koje se gradi postepeno.

Primer 5 – Dijagnostika konflikta Hyper-V i VirtualBox-a

Situacija: Nakon instalacije Docker Desktop-a na Windows host računaru, VM-ovi iz Modula 17-18 u VirtualBox-u postaju ekstremno spori ili se uopšte ne pokreću.

Dijagnostički koraci:

(PowerShell, kao Administrator)
> Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

Uočeno: State: Enabled.

Rešenje:

(PowerShell, kao Administrator)
> bcdedit /set hypervisorlaunchtype off

(zahteva restart računara)

Objašnjenje: Docker Desktop je u pozadini tiho uključio Hyper-V (Tema 4) radi sopstvenog rada — ovo je preuzelo hardversku virtuelizaciju, ostavljajući VirtualBox bez direktnog pristupa istim resursima. Isključivanje Hyper-V lansiranja rešava konflikt, ali po cenu da Docker Desktop (ako zavisi isključivo od Hyper-V, ne WSL2) prestane da radi — administrator mora odlučiti koji od ta dva alata mu je prioritet u datom trenutku rada.

Poslovni scenario – Projektovanje trajne domaće laboratorije

Kontekst: Nakon završetka Modula 1-20, entuzijasta želi da napravi trajnu, uvek dostupnu laboratoriju za dalje vežbanje i pripremu sertifikacije, umesto povremenog pokretanja VirtualBox VM-ova na ličnom laptopu.

Zahtevi:

• Laboratorija treba da bude dostupna 24/7, nezavisno od toga da li je lični laptop uključen.
• Potrebno je nekoliko odvojenih, segmentisanih mrežnih zona za vežbanje scenarija iz Modula 9 i 16.
• Potrebna je mogućnost brzog vraćanja na poznato stanje pre svakog novog eksperimenta.

Projektovano rešenje:

Zašto ovakav dizajn: Prelazak sa Type 2 (VirtualBox na laptopu) na Type 1 (Proxmox na namenskom serveru) rešava osnovno ograničenje dosadašnjeg pristupa — zavisnost od toga da lični laptop bude uključen i posvećen laboratoriji. Kombinacija snapshot-a i redovnog OVA export-a obezbeđuje da entuzijasta može slobodno da eksperimentiše (npr. namerno pogrešna ACL pravila iz Modula 16 vežbi) bez straha od trajnog gubitka rada, dok segmentisana mrežna arhitektura omogućava ponavljanje i proširivanje svih laboratorijskih vežbi iz ovog kursa u realističnijem, trajnijem okruženju.