I vantaggi di KVM rispetto ad un hypervisor baremetal

[Ste]

Leggo sempre più spesso del passaggio a KVM da parte di alcune aziende, a parte Red Hat che ha deciso di fare lo switch da Xen a KVM, mi sembra che anche in diversi documenti venga sempre più spesso citato come a fianco di VMware o di Xen, con i quali però condivide ben poco.

Quali sono i vantaggi che portano ad usarlo rispetto a Xen ad esempio? Riusciamo a delineare qualche punto? Io non vedo moltissimi vantaggi nella virtualizzazione software, almeno non a livello di performance, ma c'è anche da dire che non sono certo un profondo conoscitore di KVM

[guest]

Be, come prima cosa KVM è integrato nel kernel di linux, quindi dal punto di vista di un sysadmin, molti meno problemi, fai i normali update della tua distribuzione e sei a posto. Xen invece sono una vagonata di Patch, non incluse nel kernel e sviluppate da gente esterna.

KVM non richiede alcun kernel modificato lato guest, quindi meno problemi e più libertà per gli utenti. Ed in caso di distribuzioni linux come guest, anche qui fai i normali update della distro, senza preoccuparti di quale kernel installare. (sembra una sciocchezza ma non è così.)

Ciascun guest KVM viene visto a livello di sistema come un normalissimo processo e puoi gestirlo con i comandi più consueti (top, ps, kill, etc). Xen ad esempio ti obbliga ad usare una vagonata di strumenti e per sapere quanto sta occupando un domU sei costretto ad installare i tools lato client.

KVM è più flessibile in ambienti eterogenei, ad esempio puoi migrare da un nodo 32 bit verso un 64 e viceversa (ovviamente il guest può essere solo a 32 in questo caso, un 64 su un 32 non può andare mentre il 32 può andare sul 64). Puoi migrare da AMD a Intel e viceversa. Xen ti obbliga ad avere un cluster di nodi tutti uguali, o meglio, *identici*. Noi ad esempio abbiamo un 5520 e un 5420, stessa quantità di ram, stessi dischi, e non possiamo metterli in cluster quindi niente HA e migrazione a caldo fatta da XenServer il che ti obbliga a spengere il domU, esportare la VM, reimportarla nel nuovo e riaccendere (se la VM è bella grossa, come spesso accade su VM ad uso interno, l'esportazione può richiedere ore)

Comunque sia, se si deve virtualizzare in un ambiente omogeneo, ovvero tutti i guest uguali e tutti i nodi uguali, Xen è un valido competitor, noi stessi usiamo Xen ma perchè virtualizziamo sempre uguale e su nodi identici (tolto uno, di cui ho parlato sopra)

Come scritto sopra, Xen richiede delle patch esterne al kernel, quindi o si usa XenSource patchando il dom0, oppure si installa XenServer che è un hypervisor bare-metal, con tutto quello che ne consegue a livello di customizzazione. KVM lo installi dove ti pare perchè è una features fatta a livello di kernel. Prendi ad esempio una lenny, installi il kernel kvm fornito da debian, e via......

[Rebel]

Premettendo che non uso e conosco KVM, credo però che il giudizio su Xen sia un pò troppo affrettato.

Be, come prima cosa KVM è integrato nel kernel di linux, quindi dal punto di vista di un sysadmin, molti meno problemi, fai i normali update della tua distribuzione e sei a posto. Xen invece sono una vagonata di Patch, non incluse nel kernel e sviluppate da gente esterna.
KVM non richiede alcun kernel modificato lato guest, quindi meno problemi e più libertà per gli utenti. Ed in caso di distribuzioni linux come guest, anche qui fai i normali update della distro, senza preoccuparti di quale kernel installare. (sembra una sciocchezza ma non è così.)

A partire da Xen 4 la situazione è praticamente la medesima. Da ormai un paio di anni è in corso un lungo lavoro di adattamento delle patch lato kernel di Xen alla nuova capacità del kernel vanilla di capire quando gira sotto un hypervisor baremeta e di conseguenza attivare il relativo codice Xen o altro che sia. A breve il codice a cui stanno lavorando gli sviluppatori di Xen dovrebbe essere accettato nel kernel upstream, quindi in futuro non ci sarà più la necessità di patchare alcun kernel. Ciò inoltre significa che sarà molto più semplice aggiornare il kernel ad una versione più recente.
Già ora è possibile utilizzare un kernel paravirt_ops, ma purtroppo non è considerato abbastanza stabile per la produzione. O almeno, bisogna essere un pò temerari. Questione di tempo comunque.
Per chi fosse interessato:
XenParavirtOps - Xen Wiki

Ciascun guest KVM viene visto a livello di sistema come un normalissimo processo e puoi gestirlo con i comandi più consueti (top, ps, kill, etc). Xen ad esempio ti obbliga ad usare una vagonata di strumenti e per sapere quanto sta occupando un domU sei costretto ad installare i tools lato client.

Xen dispone di xentop che ti fornisce più o meno tutte le informazioni necessarie per capire che risorse usa un DomU. Mem, cpu, dischi, rete.

KVM è più flessibile in ambienti eterogenei, ad esempio puoi migrare da un nodo 32 bit verso un 64 e viceversa (ovviamente il guest può essere solo a 32 in questo caso, un 64 su un 32 non può andare mentre il 32 può andare sul 64).

Questo è possibile anche con Xen.

Puoi migrare da AMD a Intel e viceversa. Xen ti obbliga ad avere un cluster di nodi tutti uguali, o meglio, *identici*.
Comunque sia, se si deve virtualizzare in un ambiente omogeneo, ovvero tutti i guest uguali e tutti i nodi uguali, Xen è un valido competitor, noi stessi usiamo Xen ma perchè virtualizziamo sempre uguale e su nodi identici (tolto uno, di cui ho parlato sopra)

KVM virtualizza nativamente. Anche Xen lo può fare, e in questo caso non credo ci siano problemi a migrare un guest tra due ambienti diversi.
Xen però offre performance maggiori di KVM quando utilizza la paravirtualizzazione. Credo che ora anche KVM possa paravirtualizzare, ma immagino che in questo caso presenterà i medesimi problemi di Xen.

Come scritto sopra, Xen richiede delle patch esterne al kernel, quindi o si usa XenSource patchando il dom0, oppure si installa XenServer che è un hypervisor bare-metal, con tutto quello che ne consegue a livello di customizzazione. KVM lo installi dove ti pare perchè è una features fatta a livello di kernel. Prendi ad esempio una lenny, installi il kernel kvm fornito da debian, e via......

Come scritto sopra questo non è più esatto a partire da Xen 4.

La cosa che bisogna chiedersi è però perchè Red Hat ha abbandonato Xen. Non di certo perchè non è una tecnologia matura o affidabile o in declino, ma solamente perchè ne stava perdendo il controllo e quindi economicamente non era più una buona soluzione. Si è quindi buttata su KVM, iniziando a partecipare pesantemente allo sviluppo.

Sinceramente credo che Xen sia tutto tranne che morto o inferiore a KVM. Il problema più che altro è che è diminuito la scelta a disposizione a livello di distribuzioni enterprise. E' un bel problema non poter fare affidamente sulle prossime versioni di Red Hat, ma ci sono anche XenServer e Suse.

[guest]

Be, io non ho mai detto che Xen è morto.
Semplicemente, ad oggi, non c'è alcun supporto Xen nel kernel di Linux pertanto, ad oggi, devi patchare con tutti i problemi del caso.

Non dico che Xen sia scadente, noi stessi lo usiamo ed abbiamo circa una sesantina di VM paravirtualizzate con Xen (XenServer, no XenSource).

Per quanto riguarda la migrazione, non so XenSource, ma XenServer di Citrix, ovvero la versione ad uso enterprise, non ti permette di mettere in cluster due nodi non identici pertanto non ti fa attivare alcun tipo di HA ne di migrazione a caldo.

CTX115813 - FAQ: XenMotion, Live Migration - Citrix Knowledge Center

In ambito Enterprise difficilmente ci si può appoggiare ad un progetto non sviluppato direttamente da una azienda (come Xen opensource) a maggior ragione se tale software per funzionare necessita sia di patch al nodo virtualizzatore, sia di patch ad ogni guest che andrai a virtualizzare (la virtualizzazione HVM, oltre che sconsigliata da Citrix stessa ha prestazioni che definir ridicole sarebbe fare un complimento. Esattamente 40-50 minuti per installare una Lenny minimale da 400M tramite mirror in rete. 10 minuti se paravirtualizzato)

Credo sia questo il motivo per il quale RH stia abbandonando Xen.
RH sviluppa attivamente il kernel, di conseguenza avrebbe meno difficoltà a sviluppare anche per KVM, visto che è integrato nel kernel stesso.
Con Xen dovrebbe seguire due progetti differenti che non sempre vanno di pari passo con lo sviluppo del kernel. Dato che RH è un sistema operativo esclusivamente enterprise, secondo me questa potrebbe essere una motivazione valida per il divorzio.

[Ste]

Be, come prima cosa KVM è integrato nel kernel di linux, quindi dal punto di vista di un sysadmin, molti meno problemi, fai i normali update della tua distribuzione e sei a posto. Xen invece sono una vagonata di Patch, non incluse nel kernel e sviluppate da gente esterna.

KVM non richiede alcun kernel modificato lato guest, quindi meno problemi e più libertà per gli utenti. Ed in caso di distribuzioni linux come guest, anche qui fai i normali update della distro, senza preoccuparti di quale kernel installare. (sembra una sciocchezza ma non è così.)

Ciascun guest KVM viene visto a livello di sistema come un normalissimo processo e puoi gestirlo con i comandi più consueti (top, ps, kill, etc). Xen ad esempio ti obbliga ad usare una vagonata di strumenti e per sapere quanto sta occupando un domU sei costretto ad installare i tools lato client.

KVM è più flessibile in ambienti eterogenei, ad esempio puoi migrare da un nodo 32 bit verso un 64 e viceversa (ovviamente il guest può essere solo a 32 in questo caso, un 64 su un 32 non può andare mentre il 32 può andare sul 64). Puoi migrare da AMD a Intel e viceversa. Xen ti obbliga ad avere un cluster di nodi tutti uguali, o meglio, *identici*. Noi ad esempio abbiamo un 5520 e un 5420, stessa quantità di ram, stessi dischi, e non possiamo metterli in cluster quindi niente HA e migrazione a caldo fatta da XenServer il che ti obbliga a spengere il domU, esportare la VM, reimportarla nel nuovo e riaccendere (se la VM è bella grossa, come spesso accade su VM ad uso interno, l'esportazione può richiedere ore)

Comunque sia, se si deve virtualizzare in un ambiente omogeneo, ovvero tutti i guest uguali e tutti i nodi uguali, Xen è un valido competitor, noi stessi usiamo Xen ma perchè virtualizziamo sempre uguale e su nodi identici (tolto uno, di cui ho parlato sopra)

Come scritto sopra, Xen richiede delle patch esterne al kernel, quindi o si usa XenSource patchando il dom0, oppure si installa XenServer che è un hypervisor bare-metal, con tutto quello che ne consegue a livello di customizzazione. KVM lo installi dove ti pare perchè è una features fatta a livello di kernel. Prendi ad esempio una lenny, installi il kernel kvm fornito da debian, e via......

Bel post, complimenti Alessandro e grazie per la risposta. In tutto questo però non parliamo delle performance, è evidente che la facilità di installazione e gestione ci sia, ma se andiamo poi a parlare di cloud o di applicazioni nel campo dei server virtuali io non credo che abbia performance paragonabili a quelle di un hypervisor baremetal, senza alcuno "strato" sotto, hai esperienze in merito?

@rebel: Red Hat ha abbastanza "spolpato" Xen fino a quando c'era XenSource "libera" come dici giustamente, dopo di che con Citrix tra i piedi ha voluto cambiare aria, ma non poteva fare diversamente a meno di non scendere un po' a compromessi con chi tiene le redini del progetto.

[Rebel]

Be, io non ho mai detto che Xen è morto.
Semplicemente, ad oggi, non c'è alcun supporto Xen nel kernel di Linux pertanto, ad oggi, devi patchare con tutti i problemi del caso.

Non dico che Xen sia scadente, noi stessi lo usiamo ed abbiamo circa una sesantina di VM paravirtualizzate con Xen (XenServer, no XenSource).

Per quanto riguarda la migrazione, non so XenSource, ma XenServer di Citrix, ovvero la versione ad uso enterprise, non ti permette di mettere in cluster due nodi non identici pertanto non ti fa attivare alcun tipo di HA ne di migrazione a caldo.

CTX115813 - FAQ: XenMotion, Live Migration - Citrix Knowledge Center

Per esperienza non ho avuto problemi a migrare vps su XenSource tra due nodi con caratteristiche hw e distro differenti. Ad esempio recentemente abbiamo migrato tutte le vps da debian a centos, senza grossi problemi. Considera che i due sistemi avevano cpu (ambedu intel pero'), ram, dischi, versione hypervisor e versione kernel diversi....
Beninteso pero' che non e' sempre possibile senza fare delle modifiche ai guest. Soprattuto se fai un downgrade di hypervisor e kernel.

Non ho mai avuto pero' modo di provare Xen con una SAN ad esempio. Ma credo che allo stesso modo non ci siano problemi. Credo che XenServer richieda nodi perfettamente identici per minimizzare quanto piu' possibile eventuali problemi. Debuggare sistemi identici su due macchine identiche e' decisamente piu' semplice.

In ambito Enterprise difficilmente ci si può appoggiare ad un progetto non sviluppato direttamente da una azienda (come Xen opensource) a maggior ragione se tale software per funzionare necessita sia di patch al nodo virtualizzatore, sia di patch ad ogni guest che andrai a virtualizzare (la virtualizzazione HVM, oltre che sconsigliata da Citrix stessa ha prestazioni che definir ridicole sarebbe fare un complimento. Esattamente 40-50 minuti per installare una Lenny minimale da 400M tramite mirror in rete. 10 minuti se paravirtualizzato)

Ti do perfettamente ragione sulla prima parte. Avere un supporto enterprise e' fondamentale, soprattutto per quanto riguarda i driver e bugfix.
Per quanto riguarda le perfomance in virtualizzazione HVM. Mi pare strano che tu abbiamo registrato risultati cosi' scadenti. Personalmente mi e' capitato di utilizzare Windows su Xen HVM e non ho rilevato particolari problemi. Mi pare anche strano perche' la virtualizzazione in hardware e' una feature che Xen possiede da molti anni ormai, ben prima di KVM.

Credo sia questo il motivo per il quale RH stia abbandonando Xen.
RH sviluppa attivamente il kernel, di conseguenza avrebbe meno difficoltà a sviluppare anche per KVM, visto che è integrato nel kernel stesso.
Con Xen dovrebbe seguire due progetti differenti che non sempre vanno di pari passo con lo sviluppo del kernel. Dato che RH è un sistema operativo esclusivamente enterprise, secondo me questa potrebbe essere una motivazione valida per il divorzio.

Guarda, considerando il discorso che ho fatto prima sul nuovo kernel, la scelta di redhat a me pare dovuta semplicemente ad un calcolo di convenienza economica, come dice Ste, e dal fatto che non poteva stare nella stessa barca di Citrix, uno dei suoi competitor.
Dal mio punto di vista crea solo problemi a noi poveri cristi che ci troveremo a dover migrare tutto tra un paio di anni.....

[DonChisciotte]

Tempo fa chiesi ad un amico che lavora in RedHat come mai fossero passati da Xen a KVM e la risposta e' stata circa la seguente: una grossa percentuale di ticket aperti riguardavano Xen e veniva quindi impiegato un determinato numero di sviluppatori per risolvere i problemi. Come strategia hanno pensato di acquistare l'azienda che sviluppava prima KVM (Qumranet se non erro) impiegando a tempo pieno un numero inferiore di sviluppatori e riuscendo, tra l'altro, a dare un contributo non trascurabile al codice.

Per il resto ho visto xen 4 in azione e mi ha dato un'ottima impressione: prestazioni elevate in paravirtualization e live migration con i dischi su san+drdb fatta con openfiler (si la cosa era fatta for fun, quindi niente di enterprise) che funziona perfettamente.

My 2 cents.

[guest]

XenServer è praticamente la versione bug-free e pesantemente testata di XenSource.
Diciamo che come tutte le aziende che hanno due linee di sviluppo, una open ed una a pagamento di fascia enterprise, gli esperimenti si fanno sulla open (a meno che non si tratti di features 'di nicchia' come l'HA) per poi implementarli sulla enterprise.

XenSource si può intendere come una beta di XenServer, non tanto come funzionalità (le beta solitamente hanno features maggiori rispetto alle stable) ma come testing effettuato.
Di conseguenza, su XenServer han rimosso tutte le features non stabili al 100% o che possano comportare problematiche in determinate situazioni, come ad esempio la migrazione tra nodi non identici. Puoi passare la VM tra i due nodi, l'ho già fatto più volte, ma non a caldo.
Te che migrazioni hai fatto ? A caldo o a freddo? Le migrazioni a freddo (dump/restore) funzionano anche tra processori con flag differenti (non so con quale limite però) mentre quelle a caldo devono essere uguali.

Idem per HVM, Citrix lo sconsiglia, suggerisce (a ragione) di usare sempre la modalità paravirtualizzata e lasciare HVM solo come estrema misura.
Non mi sento quindi di considerarla una features stabile da mandare in produzione. Non si è mai visto una azienda sconsigliare una sua stessa feature. Se lo fanno avranno i loro motivi, visto che HVM renderebbe Xen un doppio hypervisor, sia full che para. Loro puntano tutto sul para.

Come dicono DonChisciotte e Ste, quando una azienda del calibro di Redhat deve impiegare buona parte del suo tempo a sviluppare ad un progetto esterno, o si impossessa del progetto esterno (o della sua azienda) o lo lascia perdere.
Xen è stata acquisita da Citrix, sicuramente ci saranno state divergenze tra Citrix e RH (inevitabile, prima o poi) pertanto RH ha mollato tutto passando KVM, che da questo punto di vista è più stabile, essendo un prodotto del kernel stesso.
Sviluppi per il kernel, sviluppi anche per KVM. RH è probabilmente il più grosso contributore del kernel Linux, pertanto non ha alcun problema a sviluppare parallelamente anche KVM, cosa che invece avrebbe con Xen essendo anche soggetta alle politiche di Citrix.

Fai una patch, Citrix la boccia, la devi rimodificare, la ribocciano, Citrix cambia politica, ti devi adattare e così via. In pratica, le tensioni sono inevitabili.

Quanto alle prestazioni inferiori di KVM: vero, ma non è così tragico, altrimenti anche vmware sarebbe scandaloso eppure è il maggior player del mercato.
Stranamente ho trovato scandalose le prestazioni di Xen in HVM.
Forse (ma su questo non sono affatto sicuro) perchè Xen in HVM si basa su qemu (il quale di default emula) mentre kvm si basa su un qemu patchato per non emulare ma usare le estensioni VT native della CPU.

[Rebel]

A freddo, sempre, ho scritto infatti che non ho vuto modo di provare Xen in ambieni HA. In una migrazione a caldo mi pare normale che il kernel della vps possa non essere molto contento se gli cambi il tipo di processore sotto il naso.

Per il resto stai confermando quello che ho detto fin dal mio primo post e cioe' che RH e' passata a KVM per un semplice motivo di convenienza economica e stategica, non perche' Xen non fosse una tecnologia matura ed affidabile. Ed aggiungo, con buona pace di chi ha creato la sua infrastruttura su Xen e si vedra' costretto a passare ad un nuovo sistema.

Non capisco il discorso che fai sulla stabilita'. Se Xen non fosse ultrastabile non sarebbe utilizzato da anni dai maggiori player del settore.... In base a cosa affermi che KVM e' piu' stabile? Che sia integrato nel kernel lo rende si' piu' facile da mantenere, ma non ne garantisce una maggiore stabilita' a priori.

Credo che Citrix sconsigli HVM per il semplice motivo che non ha molto senso utilizzarlo dato il divario mostruoso a livello di prestazioni rispetto alla paravirtualizzazione.

Anche Xen utilizza le estensioni native VT della cpu. Dove hai letto il contrario?

Secondo me KVM ci mettera' anni prima di ritagliarsi un spazio serio nella virtualizzazione ad alta densita'. Le soluzioni per questo settore sono gia' molte e ben testate e non mi pare che KVM abbia molto di originale da offrire rispetto agli altri.
Situazione diversa per il mercato casalingo. Li' KVM puo' veramente fare la parte da leone.

[guest]

Non capisco il discorso che fai sulla stabilita'. Se Xen non fosse ultrastabile non sarebbe utilizzato da anni dai maggiori player del settore.... In base a cosa affermi che KVM e' piu' stabile? Che sia integrato nel kernel lo rende si' piu' facile da mantenere, ma non ne garantisce una maggiore stabilita' a priori.

Ti rispondo con una domanda: dove hai letto che Xen non è affidabile? Dove l'ho scritto? Anzi, ho detto l'opposto, tant'è che noi per primi virtualizziamo in Xen in ambienti omogenei.

Credo che Citrix sconsigli HVM per il semplice motivo che non ha molto senso utilizzarlo dato il divario mostruoso a livello di prestazioni rispetto alla paravirtualizzazione.

Non sempre puoi paravirtualizzare e se non puoi paravirtualizzare ti sconsigliano di virtualizzare tale ambiente.

Anche Xen utilizza le estensioni native VT della cpu. Dove hai letto il contrario?

Leggi bene, ho scritto: "su questo non sono affatto sicuro".
Non ho detto che è il contrario.
Però per esperienza ti posso dire che Xen in HVM ha prestazioni comparabili a qemu (che non virtualizza ma emula) mentre la stessa VPS su Xen o VirtualBox va nettamente più veloce.

[Rebel]

Ti rispondo con una domanda: dove hai letto che Xen non è affidabile? Dove l'ho scritto? Anzi, ho detto l'opposto, tant'è che noi per primi virtualizziamo in Xen in ambienti omogenei.

Xen è stata acquisita da Citrix, sicuramente ci saranno state divergenze tra Citrix e RH (inevitabile, prima o poi) pertanto RH ha mollato tutto passando KVM, che da questo punto di vista è più stabile, essendo un prodotto del kernel stesso.

Si hai ragione, ho letto velocemente questa parte ed inteso che ritenessi KVM piu' stabile di Xen a livello di codice, ma immagino ti riferissi al processo di sviluppo invece.

Per tutto il resto, sarebbe da cercare qualche benchmark in giro e capire veramente a che punto stanno le due tecnologie.

A me KVM ancora non convince e non lo farà per un paio di anni ancora.

[Derevko]

Quali sono i vantaggi che portano ad usarlo rispetto a Xen ad esempio? Riusciamo a delineare qualche punto? Io non vedo moltissimi vantaggi nella virtualizzazione software, almeno non a livello di performance

Il fatto che la gestione della rete sia stata progettata da uno sano di mente è valida come risposta?

[DonChisciotte]

Il fatto che la gestione della rete sia stata progettata da uno sano di mente è valida come risposta?

puoi espandere la tua tesi per cortesia?

grazie