kvm e' ovviamente molto piu' veloce di virtualbox, si sente anche 'a tatto'. Ed anche molto piu' flessibile. Come xen, che pero' ha un principio di funzionamento differente.
La differenza tra questi e virtualbox e' che kvm e' un hypervisor base metal (tipo 1), mentre virtualbox e' un hosted hypervisor (tipo 2).
il primo gira direttamente sull'hardware come un kernel minimale, si occupa dello scheduling-timesharing, non tra le applicazioni ma tra i "domini", i sistemi operativi ospiti, gli garantisce accesso alle risorse ed restrizione a fini di isolamento/sicurezza, e fornisce un'astrazione ai sistemi operativi guest, a volte, come nel caso di xen in modalita' paravirtual, si tratta di hardware virtuale, praticamente delle API.
Xen puo' permettere di interagire con l'hypervisor (xen) mediante delle API "paravirtuali" che permettono di ottenere le stesse funzionalita' di un dispositivo fisico, con un overhead molto minore. Il tutto richiede una modifica software all'os guest. In pratica il sistema operativo guest, invece di andare a comunicare con un device pci per inviare frame ethernet, ha un kernel 'speciale' (linux e' cosi' da tempo) che fa una chiamata (hypercall) ad un IRQ definito dall'hypervisor (virtual interrupt), e comunica direttamente con quest'ultimo in un formato (struct) simile ad una api, ad una 'syscall' all'hypervisor, comunicando solo quanto necessario a quest'ultimo a svolgere la funzione, inviare il frame ethernet, senza che entrambe le parti debbano occuparsi di interagire con un dispositivo pci e di emularlo.
XEN puo' anche emulare hardware reale, per il quale esistono gia' driver, come fa virtualbox, o dare accesso all'os guest a determinati componenti fisici, ivi incluse vere schede video pci (modalita' HVM); le risorse fisiche esposte ad un dominio sono accessibili solo da quest'ultimo.
Anche kvm supporta sia la virtualizzazione che la paravirtualizzazione, ed e' parte del kernel, gira in ring0. Tuttavia, c'e' per questo motivo incertezza sulla sua definizione, non si sa se definirlo di tipo 1 o tipo 2.
degli hypervisor bare metal come xen sono davvero minimali, e fanno a loro volta partire un dominio amministrativo (dom0) tramite il quale gestire l'hypervisor. Significa che, tipicamente, xen parte, e fa partire un kernel linux (ed una distro minimale) per gestirlo dal "dom0" e far partire gli os "guest", le domu, ma la "dom0" non ha accesso diretto all'hardware, non ha l'ultima parola sullo scheduling, deve sempre passare da xen e da quanto gli e' concesso accedere. (puoi anche specificare determinati device pci *fisici* da assegnare ad ogni dominio-dom)
In kvm, l'hypervisor e' parte del kernel linux, della dom0. E' piu' simile ad hyperv di windows che a xen, diciamo. E' una via di mezzo tra virtualbox e xen, basti pensare che lo stesso kernel che fa da hypervisor interagisce direttamente con gli strumenti amministrativi. Va all'aria il concetto di dominio0, o meglio, dominio amministrativo, separato logicamente dall'hypervisor.
Un hypervisor di tipo 1 sara' sempre piu' veloce di un hosted hypervisor, perche' oltre che poter sfruttare tecnologie di virtualizzazione hardware, gira direttamente sull'hardware, nessuna astrazione sotto a lui, lo domina completamente
Un hypervisor tipo 2 (virtualbox), dovra' effettuare syscall al kernel, ed andra' sempre a sprecare context switch in piu' rispetto ad un hypervisor bare metal (anche se ci sono estensioni kernel che permettono all'hosted hypervisor di interfacciarsi col kernel ed eseguire codice direttamente, c'e' sempre un context switch da virtualbox in ring3 al modulo in ring0, che deve a sua volta adattarsi alle logiche del kernel)
qui c'e' una spiegazione molto migliore di quella che potrei dare io:
http://www.ok-labs.com/blog/entry/some- ... some-dont/
Per questo ed altri motivi, kvm e xen sono utilizzati in ambito server, per virtualizzare o nel 'cloud' (basti pensare che amazon ec2 e' basato su xen).
la maggior parte dei progetti nati per il cloud, diciamo openstack per fare un nome famoso, si occupano di gestirli.
in quell'ambito, gli hypervisor tipo 2 non esistono. Di vmware si parla solo di ESXi, che comunque e' tipo 1 e sta lasciando sempre piu' spazio ai competitor gratuiti, nei grossi datacenter.
kvm lo puoi anche gestire con libVirt e l'interfaccia cli 'virsh', molto piu' comodo che lanciare qemu a mano.
esiste un abbozzo di vecchia applicazione gtk, virt-manager, che sfrutta libvirt. IMHO, fa cacare, e' bacata, seriamente bacata, ed incompleta per uso desktop. Manca di molte opzioni (ottenibili in altri modi con kvm/libvirt) che sono quasi essenziali ad un uso desktop, e che virtualbox&co forniscono all'utente.
Gnome-Boxes usa kvm e si basa su libvirt, ma credo sia ancora acerba, molto acerba. In classico stile gnome, se e' nuovo e' facile da usare ma manca di cosi' tante feature, opzioni, usage pattern possibili che e' praticamente inutilizzabile. E buona fortuna con cose tipo accelerazione grafica e ridimensionamento automatico su kvm.
semplicemente, e' nato per un altro ambito d'utilizzo.
spero di aver chiarito qualche dubbio, anche se non ne sono convinto, mi esprimo come un libro chiuso con le pagine stracciate (cit) e son pure le due di notte.
