Qemu/kvm contro virtualbox

[steff]

Ammetto che in certe cose sono un ignorante. Fino adesso ho a volte usato virtualbox, a pena che mi si rallenta ognicosa sul portatile con 2gb di ram e dual core. Ieri altro ho abilitato dal BIOS il supporto hardware alla virtualizzazione cpu, installato qemu, kvm&co e ho installato per prova una xubuntu che lancio con

Codice: Seleziona tutto

qemu-system-i386 --enable-kvm  -vga std -m 600 ~/immagini_iso/disco-xubuntu

Mi sembra una differenza colossale nel uso, entrambi sistemi (kde con razor-qt e xubuntu) sono reattivi con 1,25gb ram in uso.

E' una mia impressione o kvm è davvero molto pi performante di virtualbox?

[maxbigsi]

occhio che qemu - kvm vanno in conflitto con virtualbox http://forum.ubuntu-it.org/viewtopic.php?f=8&t=491306 ... non ho mai provato con qemu a dire il vero... come si crea/avvia una macchina virtuale?

[steff]

Ho provato ad avviare virtualbox con qemu in esecuzione, partiva sì ma non avvia nessuna macchina virtuale

Codice: Seleziona tutto

 Apertura di una sessione per la Macchina Virtuale LiveCD non riuscita.

VT-x is being used by another hypervisor. (VERR_VMX_IN_VMX_ROOT_MODE).

VirtualBox can't operate in VMX root mode. Please disable the KVM kernel extension, recompile your kernel and reboot (VERR_VMX_IN_VMX_ROOT_MODE).

Ma se chiudo qemu mi partono bene.

Ho seguito l'inizio del wiki di arch, ho anche usato virt-manager che assomiglia alla finestra di gestione di virtualbox ma veramente ci si fa a meno, poi era un casino con il disco virtuale, ho dovuto spostarlo in / per problemi di permessi che non ho potuto risolvere.

Per avviare una iso basta

Codice: Seleziona tutto

qemu-system-i386 --enable-kvm   -m 600 ~/immagini_iso/precise-desktop-i386.iso 

-m è la memoria, di default assegna 128mb.

[maxbigsi]

io ho messo il modulo kvm-intel in blacklist non perché abbia installato qemu di mia volontà, ma perché lo installa multisystem, un programma che avvia diverse distro in una chiavetta usb ... ho contattato anche lo sviluppatore del programma sul forum francese di ubuntu per alcune delucidazioni... ora faccio qualche prova... grazie

[steff]

Ho scoperto adesso che non mi funzionava l'audio nelle macchine qemu. Ma basta -soundhw all nelle opzioni del comando.

[kimj]

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.

[steff]

Caspita, ci sono almeno una ventina di parole che non capisco solo all'incirca o neanche cosa significano, ma grazie infinite!
Che virt-manager sia bucato ci sta bene, mi ha cacciato in un loop di permessi insufficienti.

[kimj]

Caspita, ci sono almeno una ventina di parole che non capisco solo all'incirca o neanche cosa significano, ma grazie infinite!
Che virt-manager sia bucato ci sta bene, mi ha cacciato in un loop di permessi insufficienti.

ed e' il problema minore di virt-manager. Evita di creare storage repository nella tua home, o di montare iso, etc. A me una volta ha cambiato ownership della home tagliandomi fuori.
diciamo che va usato con lvm.

poi ha bachi tipo questo: https://bugs.launchpad.net/ubuntu/+sour ... ug/1263534
che credo possano essere considerati anche problemi di sicurezza, o al minimo funzionalita' mancanti ed un comportamento non in linea con quello suggerito.

un'altro che ho segnalato, e' che non permette di delistare (virStoragePoolUndefine) degli storage pool, li vuole prima deattivare (virStoragePoolDestroy), se fallisce non ha fallback. Il che e' ottimo se come storage pool/repository hai un gruppo lvm su cui ci sono anche normali filesystem montati, o /...

come e' tipico, non hanno risposto a nessun bug report, indice di quanto sia mantenuto il progetto...

virt-manager e' sempre stato un po' traballante, e credo che non ci sia piu' interesse nel mantenerlo, perche' alcuni bachi sono giganteschi. Era un progetto redhat, si saranno spostati al cloud (openstack) e rhev.

Gnome-Boxes non so come possa essere diventato. La miglior cosa al momento e' "virsh", se si esclude l'installare http://www.openstack.org/ o https://www.eucalyptus.com/ su una singola macchina desktop/portatile giusto per far prove con alti os.

[steff]

Io nel mio piccolo mi accontento di due alias per lanciarli:

Codice: Seleziona tutto

alias xubuntu="qemu-system-i386 --enable-kvm  -vga std -soundhw all -m 600 ~/VirtualBox\ VMs/immagini_iso/disco-xubuntu"
alias ubuntu="qemu-system-i386 --enable-kvm -soundhw all -vga std -m 600 -k it ~/VirtualBox\ 
VMs/immagini_iso/precise-desktop-i386.iso"

Mi servono per provare delle iso sopratutto, una spettacolare in termini di velocità è slitaz.

[toni00c]

voi usate kvm solo da riga di comando? dove avete imparato come sfruttarlo al massimo?
è possibile utilizzare la cpu reale?

[saxtro]

kvm supporta il passthrought di una eventuale seconda scheda grafica? (so che xen ed esxi lo supportano, ma mica posso metterli sul computer di casa....)

[saxtro]

eccolo !

https://wiki.debian.org/VGAPassthrough

[spider-net]

Supporta il passthrough di qualsiasi periferica installata su una qualsiasi linea PCI-E, quindi non solo schede video. Supporta anche il passthrough di periferiche di I/O (mouse, tastiera, stampante, ...) collegate tramite bus USB.