La virtualizzazione è un tema interessante: capita spesso per chi lavora nell’IT di dover usare macchine virtuali, che siano per uso personale (magari testare un software) o per uso infrastrutturale (fornire VM all’azienda o a clienti), così come capita spesso di usare i container, ossia una forma “democristiana” di virtualizzazione spesso ignorata.
Ma vediamo un po’ insieme i principi.
Cos’è la virtualizzazione?
L’idea di virtualizzazione è molto semplice: “scardinare” l’idea di corrispondenza biunivoca hardware-software e permettere a più sistemi operativi di convivere sul medesimo hardware, per poter fare molte cose, ad esempio:
- Vendere un sistema virtuale a prezzo economico, che gira su un’infrastruttura più costosa e grande (i famosi VPS)
- Partizionare meglio un sistema, ad esempio usando un unico computer ma con tre OS diversi per fare da firewall, reverse proxy e server
- Usare un sistema diverso da quello su cui funziona il computer, per usare qualche software che non gira sul proprio sistema
- Offrire, in un’azienda fortemente dipartimentalizzata, varie soluzioni pur gestendone solamente una come IT
- Migrare più liberamente l’infrastruttura, non legandola ad uno specifico hardware
Virtualizzazione: nativa o a livello di OS?
Il tipo principale di virtualizzazione, ossia quello più noto, è quella nativa. Nella virtualizzazione nativa, essenzialmente, vengono create delle macchine virtuali dall’hypervisor – che vedremo nel prossimo paragrafo – che emulano in tutto e per tutto un sistema hardware, con un grado di separazione hardware dal “metallo” che si può adattare, ad esempio solitamente le macchine virtuali hanno un hard disk e una RAM autonome ma sono collegate direttamente alla rete.
Nella virtualizzazione a livello di OS, invece, non viene emulato quasi nulla. Infatti, tutti i container hanno in comune il medesimo kernel, quello del sistema che esegue il sistema, e un grado di isolamento variabile, ma mai solido quanto quello di un sistema di VM native, potete vedere questo video, ne consiglio la visione totale ma il concetto viene espresso dai 2:30 in poi.
Hypervisor: il cuore di tutto
L’Hypervisor, nella virtualizzazione nativa, è ciò che crea, uccide e gestisce le macchine virtuali, astraendo quindi l’hardware dal software e facendo da intermediario tra l’hardware vero (host) e le richieste hardware ricevute dal computer virtuale e mandate dal sistema operativo (guest).
Generalmente si parla di due tipi di hypervisor:
- Tipo 1: sono quelli usati nei contesti professionali e sono installati direttamente sull’hardware, permettendo un uso migliore delle risorse, come Proxmox o ESXI
- Tipo 2: sono quelli usati su altri sistemi operativi, usano in modo meno efficiente le risorse, dato che devono condividerle con il sistema operativo su cui vengono eseguiti, ma sono ottimi per usare brevemente software che non girano su altri sistemi o eseguire software sospetti in modo sicuro e isolato dal sistema principale, i più famosi sono VMware e VirtualBox
In ogni caso, è importante notare, che entrambi i tipi di hypervisor agiscono in modo quasi identico e cambia solo la mentalità alla base, uno per usi promiscui e uno per usi generali. Vengono sempre create delle macchine virtuali, isolate dal computer principale se non diversamente deciso e la possibilità che risorse del sistema principale vengano usate senza autorizzazione dalle macchine virtuali viene considerata una grave vulnerabilità.
Può essere utile, tra l’altro, ricordare l’origine del termine hypervisor: uno dei nomi del kernel – ormai desueto – è supervisor. Si è scelto di accrescere il prefisso in modo da indicare una sorta di “kernel dei kernel”.
La virtualizzazione coi container: a cosa serve?
Autore: Drinkler
Quella coi container, ossia la virtualizzazione a livello di OS, è una virtualizzazione “monca”: l’isolamento, come già accennato, è ridotto e tutte le macchine condividono il kernel e varie componenti del sistema.
Ciò ha un limite importante: una macchina virtuale su hypervisor Linux potrà eseguire tranquillamente Windows, ma un sistema a container Linux non potrà eseguire un’immagine di Windows Server, dato che il kernel è diverso.
La condivisione del kernel, però, ha anche un vantaggio non indifferente: permette di fare deployment molto velocemente (come racconto qui). Pensateci: installare un sistema operativo in una macchina virtuale richiede tempo, almeno una ventina di minuti, perché devono essere creati i file-system, copiati i file e le applicazioni devono essere installate, mentre con un sistema a container c’è quasi tutto e si devono scaricare poche immagini che resteranno a disposizione per altri deployment.
Non a caso, oggi, molti hypervisor permettono di fare sia container (solitamente col LXC) che macchine virtuali classiche, cosa che riduce nettamente i tempi di installazione, ma che può essere inadatta per distro con kernel strani, come può essere Kali.
Meglio i container o le macchine virtuali?
Dipende tutto dalla vostra necessità. Le macchine virtuali, essendo veri e propri computer, vi consentono di eseguire qualsiasi sistema operativo, a prescindere dal sistema host. Potete tranquillamente provare Windows 98 sulla vostra Unix-box o Haiku su Windows, così come potete avere un OS Windows per eseguire programmi sospetti o malware.
I container, invece, sono meno isolati, ma permettono un deployment molto più semplice e veloce, accettando il kernel in comune.
