Un hypervisor è una combinazione di software, hardware o firmware che crea, esegue e gestisce macchine virtuali (VM). Il computer che esegue un hypervisor è noto come host, mentre ogni VM sull’host è nota come guest. Un hypervisor fornisce agli ospiti una piattaforma operativa virtuale che gestisce i loro sistemi operativi (OS), permettendo a più OS di condividere risorse virtualizzate sullo stesso host.
La capacità di condividere risorse è una delle ragioni più significative per un’azienda per implementare gli hypervisor. Tuttavia, la varietà di hypervisor attualmente disponibili può rendere questo processo decisionale impegnativo. La selezione di un hypervisor spesso si riduce a una scelta tra VMware e Kernel-based Virtual Machine (KVM). VMware è il nome di una società che sviluppa una gamma di hypervisor, tra cui l’ESXi di classe enterprise. KVM è un’infrastruttura per il kernel Linux che gli fornisce le capacità di un hypervisor.
I seguenti punti di confronto possono aiutare le organizzazioni che hanno bisogno di un hypervisor a scegliere tra VMware e KVM.
- Performance
- Integrazione
- Costo
- Complessità
- Maturità
- Scalabilità
- Funzionalità di supporto
Overview
Un hypervisor virtualizza un ambiente informatico, il che significa che gli ospiti in quell’ambiente condividono le risorse fisiche come la capacità di elaborazione, la memoria e l’archiviazione che comprendono un cloud privato. Ogni ospite esegue il proprio sistema operativo, il che lo fa sembrare come se avesse le proprie risorse, anche se non è così. La condivisione efficiente delle risorse richiede che il processore fisico supporti la virtualizzazione, che si chiama AMD-V per i processori AMD e VT-x per i processori Intel.
Un hypervisor deve isolare efficacemente ogni guest, in modo che il funzionamento di un guest non possa influenzare gli altri guest in esecuzione sull’host. Questo requisito significa che un hypervisor deve emulare accuratamente l’hardware fisico per impedire agli ospiti di accedervi se non in circostanze attentamente controllate. Il metodo che un hypervisor usa per fare questo è un fattore chiave per le sue prestazioni.
Gli hypervisor spesso usano driver “paravirtualizzati” (PV) per emulare l’hardware fisico, che agiscono come hardware come dischi di archiviazione e schede di rete. Questi driver sono specifici del sistema operativo e spesso specifici di un particolare hypervisor. I driver PV possono migliorare le prestazioni di un hypervisor di un ordine di grandezza.
Performance
Gli hypervisor possono essere classificati in due tipi, che possono influire sulle loro prestazioni. Gli hypervisor di tipo 1, conosciuti anche come hypervisor “bare metal”, vengono eseguiti direttamente sull’hardware fisico, e il sistema operativo di ogni guest viene eseguito sopra l’hypervisor. Questi hypervisor tipicamente permettono ad alcuni guest di controllare l’hypervisor. La maggior parte delle aziende usa hypervisor di tipo 1.
Un hypervisor di tipo 2, noto anche come hosted hypervisor, viene eseguito all’interno di un sistema operativo che gira sull’hardware fisico. Il sistema operativo di ogni ospite viene quindi eseguito sopra l’ipervisore. Gli hypervisor per desktop sono di solito hypervisor di tipo 2.
Xen è probabilmente il miglior esempio di hypervisor puro di tipo 1, anche se ESXi è chiaramente un hypervisor di tipo 1 perché non è un’applicazione installata su un sistema operativo. ESXi include un kernel e altri componenti del sistema operativo che integra nel sistema operativo nativo.
La classificazione di KVM è più difficile perché condivide caratteristiche di entrambi i tipi di hypervisor. È distribuito come un componente Linux, il che significa che un utente Linux può avviare KVM da una linea di comando o da un’interfaccia grafica utente (GUI). Questi metodi di avvio di KVM fanno sembrare che l’hypervisor sia in esecuzione sul sistema operativo host, anche se KVM è in realtà in esecuzione sul bare metal.
Il sistema operativo host fornisce a KVM un meccanismo di lancio e stabilisce una relazione di co-processing con esso, permettendo a KVM di condividere il controllo sull’hardware fisico con il kernel Linux. KVM usa le istruzioni di virtualizzazione del processore quando gira su hardware x86, permettendo all’hypervisor e a tutti i suoi ospiti di girare direttamente sul bare metal. L’hardware fisico esegue la maggior parte delle traduzioni delle risorse, quindi KVM soddisfa i criteri tradizionali per un hypervisor di tipo 1.
Un hypervisor di tipo 1 dovrebbe superare un hypervisor di tipo 2, a parità di altri fattori. Gli hypervisor di tipo 1 evitano l’overhead che un hypervisor di tipo 2 incorre quando richiede l’accesso alle risorse fisiche dal sistema operativo host. Tuttavia, anche altri fattori giocano un ruolo importante nelle prestazioni di un hypervisor. Per esempio, ESXi generalmente richiede più tempo per creare e avviare un server rispetto a KVM. ESXi ha anche prestazioni più lente quando esegue i server, anche se questa differenza può essere insignificante per carichi tipici.
Integrazione
Gli hypervisor usano metodi diversi per comunicare con l’hardware fisico dell’host. KVM usa un agente installato sull’host per comunicare con l’hardware, mentre ESXi usa il management plane di VMware per comunicare con l’hardware. Il processo offre il vantaggio di permettere a ESXi di accedere ad altri prodotti VMware che usano questo piano di gestione. Tuttavia, richiede anche che ESXi usi lo stack di controllo di VMware, che può aumentare i requisiti hardware.
La stretta integrazione con il sistema operativo host è la ragione principale per cui gli sviluppatori Linux preferiscono KVM, che è stato incorporato nel kernel Linux poco dopo il suo rilascio nel 2007. In confronto, Xen non è diventato ufficialmente parte del kernel Linux fino al 2011, otto anni dopo il suo rilascio iniziale. Gli sviluppatori di Linux sono anche più propensi ad usare KVM perché Red Hat e altri distributori di Linux l’hanno adottato preferendolo ad altri hypervisor. Illumos è un sistema operativo open-source basato su OpenSolaris che ha anche scelto KVM rispetto ad altri hypervisor quando ha aggiunto il supporto per la virtualizzazione hardware.
Costo
KVM vince chiaramente su VMware sulla base del costo. KVM è open source, quindi non comporta alcun costo aggiuntivo per l’utente. È anche distribuito in una varietà di modi, spesso come parte di un sistema operativo open-source.
VMware fa pagare una licenza per usare i suoi prodotti, incluso ESXi. È in grado di farlo perché VMware è stata la prima azienda a rilasciare software di virtualizzazione di classe enterprise ed è ancora leader di mercato in questo segmento. Il suo marchio è quindi ancora rilevante per gli utenti finali di un’azienda, indipendentemente da ciò che gli sviluppatori possono pensare al riguardo. Un utente ESXi deve anche acquistare una licenza per utilizzare vSphere, la suite di strumenti VMware per il cloud computing che utilizza ESXi. Potrebbero essere necessarie ulteriori licenze software, il che aumenterà ulteriormente il costo di implementazione di ESXi.
IBM ha eseguito alcuni calcoli riguardanti il costo totale di proprietà (TCO) per KVM e VMware nel 2012. Questi calcoli hanno mostrato che il TCO di KVM era tipicamente inferiore del 39% rispetto a VMware, anche se il TCO effettivo dipenderà da fattori specifici del sito come l’impostazione operativa e il carico di lavoro. Questa differenza di TCO indica che i fornitori di servizi cloud probabilmente vorranno implementare KVM su almeno un cluster, indipendentemente dagli altri fattori da considerare.
Complessità
Un confronto tra KVM e VMware mostra anche una chiara differenza nella dimensione del codice di base, che influenza i costi di manutenzione di un hypervisor. KVM è stato inizialmente rilasciato per sfruttare le estensioni del processore che permettevano di virtualizzare i guest senza tradurre il codice binario. Questa origine ha fatto sì che la prima versione stabile di KVM fosse essenzialmente un driver di virtualizzazione leggero, con poco più di 10.000 linee di codice (LOC).
Si ritiene cheVMware abbia oltre 6 milioni di LOC, anche se questo fatto non può essere verificato poiché il suo codice sorgente non è pubblicamente disponibile. Questo totale non influisce direttamente sulle prestazioni, poiché VMware utilizza estensioni hardware per virtualizzare il guest. Tuttavia, il suo codice originale non è mai stato completamente riscritto, risultando in una base di codice più complessa di KVM.
Maturità
KVM e ESXi sono entrambi molto maturi e stabili. KVM fa parte del kernel Linux da oltre un decennio, ed ESXi è disponibile al pubblico dal 2006. Tuttavia, KVM è più ampiamente distribuito poiché è open source ed è incluso in molti pacchetti come Redhat Enterprise Virtualization (RHEV). KVM supporta anche più funzioni di qualsiasi altro hypervisor.
Scalabilità
KVM è generalmente più scalabile di VMware, principalmente perché vSphere ha alcune limitazioni sui server che può gestire. Inoltre, VMware ha aggiunto un gran numero di Storage Area Networks (SAN) per supportare vari fornitori. Questa caratteristica significa che VMware ha più opzioni di storage rispetto a KVM, ma complica anche il supporto allo storage di VMware quando si scala.
Supporto alle funzionalità
Gli hypervisor variano molto nel loro supporto alle funzionalità. Il supporto della rete e dello storage sono particolarmente importanti e sono probabilmente più importanti di qualsiasi altro fattore oltre all’integrazione del sistema operativo. Non dovrebbe essere una sorpresa sapere che il supporto di ESXi per altri prodotti VMware è ineguagliato da qualsiasi altro hypervisor. D’altra parte, KVM offre più opzioni per il supporto di rete rispetto a VMware.
Sommario
KVM è tipicamente la scelta più popolare per gli utenti che sono preoccupati del costo di gestione di ogni VM e meno interessati alle caratteristiche di livello enterprise. Questa regola si applica principalmente ai fornitori di servizi cloud e host, che sono particolarmente sensibili al costo e alla densità dei loro server. Questi utenti sono molto propensi a scegliere hypervisor open-source, specialmente KVM.
La stretta integrazione con il sistema operativo host è una delle ragioni più comuni per cui gli sviluppatori scelgono KVM, specialmente quelli che usano Linux. L’inclusione di KVM in molte distribuzioni Linux lo rende anche una scelta conveniente per gli sviluppatori. KVM è anche più popolare tra gli utenti che non si preoccupano dei nomi dei marchi.
Vedi anche VMWare vs Proxmox