Link all'Articolo: http://www.hwfiles.it/articoli/3461/microsoft-windows-server-2012-hyper-v_index.html

Microsoft nel presentare alcune settimane fa Windows Server 2012 ha posto particolare attenzione all'emergente fenomeno del cloud nei suoi molteplici aspetti, compreso il Private Cloud. Proprio questi ambiti hanno guidato Microsoft nello sviluppo del nuovo sistema operativo

Click sul link per visualizzare l'articolo.

molto interessante, ma gradirei qualche esempio pratico e meno 'pubblicitario' :) p.s. occhio agli errori ;)

@Twisted87: ci saranno altri approfondimenti e alcuni video a cui sto lavorando. Questo è solo il primo appuntamento. Grazie per le indicazioni: c'è stato un problema di "versionining" ;)

che ci fa di metro? :doh:
e soprattutto, chi oserebbe usare in un server di produzione HyperV piuttosto che non KVM? :mbe:

che ci fa di metro? :doh:
e soprattutto, chi oserebbe usare in un server di produzione HyperV piuttosto che non KVM? :mbe:

per lo stesso motivo che spinge una persona a usare vmware xen o altro perche fa quello che gli serve, nella mia azienda abbiamo tutto basato su vmware e vorremmo passare a HyperV gia dalla versione precedente (la 2) ma avendo investito molto su altri prodotti non ci conviene economicamente (abbiamo centinaia di server virtulizzati), se dovessimo iniziare ora sicuramente useremmo il prodotto ms che è ormai maturo come quelli della concorrenza.

Per il resto stiamo gia finendo i test per migrare l'intera infrastuttura a windows 2012 server sia come AD che come servizi.

PS l'interfaccia della nuova GUI fa schifo quella di 8 che non mi dispiace è infinitamente piu comoda.

per lo stesso motivo che spinge una persona a usare vmware xen o altro perche fa quello che gli serve, nella mia azienda abbiamo tutto basato su vmware e vorremmo passare a HyperV gia dalla versione precedente (la 2) ma avendo investito molto su altri prodotti non ci conviene economicamente (abbiamo centinaia di server virtulizzati), se dovessimo iniziare ora sicuramente useremmo il prodotto ms che è ormai maturo come quelli della concorrenza.

Per il resto stiamo gia finendo i test per migrare l'intera infrastuttura a windows 2012 server sia come AD che come servizi.

PS l'interfaccia della nuova GUI fa schifo quella di 8 che non mi dispiace è infinitamente piu comoda.

ma se mi parli di una rete su AD allora ok, win server 2012 ci sta..
altrimenti consiglio di provare proxmox (100% kvm) ;)

ma se mi parli di una rete su AD allora ok, win server 2012 ci sta..
altrimenti consiglio di provare proxmox (100% kvm) ;)

non potremmo usarlo perche non è un software certificato/adatto per l'uso in ambiente enterprise e i server e applicativi se non girano su sistemi supportati non possono funzionare per motivi di certificazioni e garanzie.

Sinceramente prima di ora non sapevo nemmeno che esistesse (ma mi sono letto ora cosa fa e supporta) eppure di convegni presentazioni ecc ne vedo fin troppe da molti anni sull'argomento, ma esiste qualcuno che lo usa (domanda seria).

Sai quele è il problema sia vmware che hiperv che xen sono gratuiti nelle versioni base quindi passare a altro senza avere feature che siano davvero un musto è difficile da giustificare.

che ci fa di metro? :doh:
e soprattutto, chi oserebbe usare in un server di produzione HyperV piuttosto che non KVM? :mbe:Piuttosto semmai chi mai oserebbe usare in produzione KVM o Hyperv piuttosto che vmware?

Mio caro Fabio e redazione in generale, vedo che il lupo "cambia" il pelo ma non il vizio, le markette cominciano ad essere un po' troppo spudorate.
Benissimo che ci sia una sfilza di articoli su questo prodotto, ma come mai non si vede mai niente riguardo a vmware visto che di fatto è leader incontrastato di mercato in tema di virtualizzazione?
Direttive dagli sponsor? ;)

per lo stesso motivo che spinge una persona a usare vmware xen o altro perche fa quello che gli serve, nella mia azienda abbiamo tutto basato su vmware e vorremmo passare a HyperV gia dalla versione precedente (la 2) ma avendo investito molto su altri prodotti non ci conviene economicamente (abbiamo centinaia di server virtulizzati), se dovessimo iniziare ora sicuramente useremmo il prodotto ms che è ormai maturo come quelli della concorrenza.Per quanto mi riguarda io ci penserei bene a invischiarmi nei meandri MS, spero che abbiate fatto bene i conti ;)
Da quanto vedo (correggimi se sbaglio) la migrazione da un host all'altro è permessa su HyperV solo per la versione Datacenter di Win2012, il che implica anche l'uso del clustering quantomeno per lo storage. Personalmente ho avuto poche esperienze con clustering MS e tutte piuttosto dolorose, costose e infinitamente complesse per i vantaggi che danno.

Sinceramente prima di ora non sapevo nemmeno che esistesse (ma mi sono letto ora cosa fa e supporta) eppure di convegni presentazioni ecc ne vedo fin troppe da molti anni sull'argomento, ma esiste qualcuno che lo usa (domanda seria).Io l'avevo già sentito nominare in un paio di occasioni, però anch'io non ho mai visto nessuno che lo proponesse come soluzione concreta.
Se si esclude vmware a me è capitato di trovare soltanto un fornitore che mi abbia offerto soluzioni virtualizzate con OpenVZ, da quanto ho letto pare tutt'altro che banale (il servizio di questo fornitore poi si è rivelato davvero ottimo).

Sarà che il pranzo mi ha appesantito ma non mi è chiara una cosa:

Shared Nothing Live Migration che consente lo spostamento di una virtual machine da un host all'altro senza downtime, senza spegnimento e anche nel caso in cui i due host siano su differenti nodi del cluster
un host nel caso di un cluster non è identificabile come un nodo del cluster? Se lo spostamento avviene tra due host è ovvio siano due nodi diversi del cluster...

Sarà che il pranzo mi ha appesantito ma non mi è chiara una cosa:


un host nel caso di un cluster non è identificabile come un nodo del cluster? Se lo spostamento avviene tra due host è ovvio siano due nodi diversi del cluster...

l'articolo dice un altra cosa, mentre oggi con i prodotti attuali la migrazione avviene solo se vi è un datastore condiviso quindi all'interno dello stesso cluster ora si puo migrare un server anche su cluster che non condividono nessuno storage cosa che attualmente non si puo fare.

l'articolo dice un altra cosa, mentre oggi con i prodotti attuali la migrazione avviene solo se vi è un datastore condiviso quindi all'interno dello stesso cluster ora si puo migrare un server anche su cluster che non condividono nessuno storage cosa che attualmente non si puo fare.Ah quindi nessun cluster nemmeno per lo storage, deo gratias, sicuramente questo è un aspetto positivo che serve ad alleggerire molto il prodotto e rendere più solida l'architettura.

Piuttosto semmai chi mai oserebbe usare in produzione KVM o Hyperv piuttosto che vmware?


Ciao,
sicuramente vmware gioca la parte del leone, ma KVM è un prodotto che, con i dovuti accorgimenti, è assolutamente utilizzabile anche in ambito aziendale. Per esempio, è utilizzato dalla borsa di New York come piattaforma di virtualizzazione principale.

Nel nostro piccolo, lo usiamo ormai da diversi mesi e proprio in questi giorni sto facendo un'analisi per un nostro cliente che vorrebbe passare da una versione free di ESXi (3.5) a qualcosa di più flessibile (nota: ESXi di per sé ha un mare di features bellissime, solo che vanno licenziate più o meno singolarmente e non ci staremmo col budget :D)

Detto questo, ESXi dovutamente licenziato rimane probabilmente il top :)


Io l'avevo già sentito nominare in un paio di occasioni, però anch'io non ho mai visto nessuno che lo proponesse come soluzione concreta.
Se si esclude vmware a me è capitato di trovare soltanto un fornitore che mi abbia offerto soluzioni virtualizzate con OpenVZ, da quanto ho letto pare tutt'altro che banale (il servizio di questo fornitore poi si è rivelato davvero ottimo).

Proxmox è una delle soluzioni che stavo valutando, ma ha due problemi:
1) a livello di licenze non è poi messo benissimo, dato che con costi paragonabili dovrebbe potersi prendere una licenza base di ESXi
2) è basato su Debian, e questo (che di per se è cosa buona e giusta :p) può essere un problema in ambito enterprise dove in genere si lavora con RHEL/CentOS o Suse.

l'articolo dice un altra cosa, mentre oggi con i prodotti attuali la migrazione avviene solo se vi è un datastore condiviso quindi all'interno dello stesso cluster ora si puo migrare un server anche su cluster che non condividono nessuno storage cosa che attualmente non si puo fare.

ESXi + vMotion non è in grado di fare la stessa cosa (migrazione senza storage condiviso)?

Ciao. :)

non potremmo usarlo perche non è un software certificato/adatto per l'uso in ambiente enterprise e i server e applicativi se non girano su sistemi supportati non possono funzionare per motivi di certificazioni e garanzie.

Sinceramente prima di ora non sapevo nemmeno che esistesse (ma mi sono letto ora cosa fa e supporta) eppure di convegni presentazioni ecc ne vedo fin troppe da molti anni sull'argomento, ma esiste qualcuno che lo usa (domanda seria).

Sai quele è il problema sia vmware che hiperv che xen sono gratuiti nelle versioni base quindi passare a altro senza avere feature che siano davvero un musto è difficile da giustificare.
io lo uso :D ed è mostruoso, se vuoi dettagli ok però prima magari leggiti cosa è kvm altrimenti non puoi apprezzare, alla fine proxmox è un kernel patchato che supporta kvm e openvz, interfaccia in extjs, backup a caldo ecc..

Ciao,
sicuramente vmware gioca la parte del leone, ma KVM è un prodotto che, con i dovuti accorgimenti, è assolutamente utilizzabile anche in ambito aziendale. Per esempio, è utilizzato dalla borsa di New York come piattaforma di virtualizzazione principale.
quoto!


Proxmox è una delle soluzioni che stavo valutando, ma ha due problemi:
1) a livello di licenze non è poi messo benissimo, dato che con costi paragonabili dovrebbe potersi prendere una licenza base di ESXi
2) è basato su Debian, e questo (che di per se è cosa buona e giusta :p) può essere un problema in ambito enterprise dove in genere si lavora con RHEL/CentOS o Suse.

1) ok ma non c'è paragone tra la tecnologia di kvm e quella "software" di vmware, ci sono vari bench in giro..
2) veramente secondo stime recenti sono più diffusi server web basati su debian :sofico: e cmq a parte questo, kvm lo puoi usare anche senza proxmox, solo che proxmox ti facilita molto la gestione delle macchine..
io mi trovo bene, ormai è 1 anno e mezzo che lo uso, anche io prima stavo su vmware ma in quanto a performance non ci sono paragoni

Piuttosto semmai chi mai oserebbe usare in produzione KVM o Hyperv piuttosto che vmware?
io :sofico: e provenendo proprio da vmware, non tornerei indietro :O

quoto!


1) ok ma non c'è paragone tra la tecnologia di kvm e quella "software" di vmware, ci sono vari bench in giro..


Occhio che la maggior parte dei benchmark "amatoriali" di KVM / VirtualBox / VMWare che vedi in giro sono completamente sballati e spesso le misurazioni sono fatte in condizioni profondamente differenti (es: write barrier abilitate da una parte e disabilitate dall'altra, caching in scrittura del disco abilitato vs caching disabilitato, ecc.)

Personalmente sono anni che faccio test dei vari virtualizzatori (nella firma c'è il mio sito :D) e posso assicurarti che se non configurati a dovere, mostrano risultati completamente fuorvianti (in peggiore probabilmente è KVM, che con il default setting "writethrough" ha prestazioni 5 volte peggiori nell'I/O disco). Comunque qui entriamo in un altro discorso...

Riguardo alla tecnologia sottostante, su hardware che supporta le VT-x / AMD-V il concetto è simile per tutti i virtualizzatori: eseguire nativamente il codice applicativo direttamente all'intero dei costruitti ASM VMENTER / VMEXIT. Questo vuol dire che dal punto di vista computazionale, su processori recenti tali sistemi sono molto simili. Discorso diverso per i processori più vecchiotti, dove il binary recompliler di VMWare (ma anche di VirtualBox) è molto avanti rispetto a quello di Qemu (volutamente tralasciato).

Se poi mi parli di VMWare Server concordo col dire che è un prodotto da sconsigliare, in quanto vecchio e non più aggiornato (e con problemi di compatibilità con le libc recenti). Tuttavia ESXi è tutto un altro paio di maniche ;)


2) veramente secondo stime recenti sono più diffusi server web basati su debian :sofico: e cmq a parte questo, kvm lo puoi usare anche senza proxmox, solo che proxmox ti facilita molto la gestione delle macchine..
io mi trovo bene, ormai è 1 anno e mezzo che lo uso, anche io prima stavo su vmware ma in quanto a performance non ci sono paragoni

Sicuramente in ambito web le Debian sono (giustamente) diffuse, ma in ambito database / virtualizzatori, a livello enterprise le distribuzioni più usate sono RHEL e Suse (soprattutto nei datacenter).

Ciao. :)

Nel nostro piccolo, lo usiamo ormai da diversi mesi e proprio in questi giorni sto facendo un'analisi per un nostro cliente che vorrebbe passare da una versione free di ESXi (3.5) a qualcosa di più flessibile (nota: ESXi di per sé ha un mare di features bellissime, solo che vanno licenziate più o meno singolarmente e non ci staremmo col budget :D)

Detto questo, ESXi dovutamente licenziato rimane probabilmente il top :)




ESXi + vMotion non è in grado di fare la stessa cosa (migrazione senza storage condiviso)?

Ciao. :)
rimane un problema rispetto ad Hyper-V: la compatibilità hardware è molto inferiore...hyper-v gira se ci gira sopra win server 2008 e versioni successive: praticamente ogni cosa sulla terra (certo le prestazioni cambiano ma il punto rimane: se hai un server uscito dopo il 2007 al 99.9% puoi installare l'hypervisor di casa MS)....e per piccole cose è comodo visto che ce l'hai già se hai una macchina con win server attivando il relativo ruolo.
Ancora da win 8 in avanti Hyper-v è disponibile anche nella versione client del SO con piccole differenze rispetto alla verione server: comodo per preparare al volo macchine virtuali e metterle in linea su un server adatto quando possibile.
Per piccole aziende che non hanno grosse esigenze ed hanno già un server win 2008R2 e successivi hyper-v è un buon affare nel rapporto risultati/mal di testa...per situazioni più grandi onestamente non saprei dire ma girando comincio a vederne.

rimane un problema rispetto ad Hyper-V: la compatibilità hardware è molto inferiore...hyper-v gira se ci gira sopra win server 2008 e versioni successive: praticamente ogni cosa sulla terra (certo le prestazioni cambiano ma il punto rimane: se hai un server uscito dopo il 2007 al 99.9% puoi installare l'hypervisor di casa MS)....e per piccole cose è comodo visto che ce l'hai già se hai una macchina con win server attivando il relativo ruolo.
Ancora da win 8 in avanti Hyper-v è disponibile anche nella versione client del SO con piccole differenze rispetto alla verione server: comodo per preparare al volo macchine virtuali e metterle in linea su un server adatto quando possibile.
Per piccole aziende che non hanno grosse esigenze ed hanno già un server win 2008R2 e successivi hyper-v è un buon affare nel rapporto risultati/mal di testa...per situazioni più grandi onestamente non saprei dire ma girando comincio a vederne.

Assolutamente vero, io mi riferivo a situazioni che hanno bisogno di qualcosa in più che 1-2 VM.

Per farti un esempio, l'altro giorno ero in visita da un cliente con centinaia di VM e backend su SAN EMC2: ovviamente usa VMWare Infrastructure / vSphere (basati su nodi ESX/ESXi) e, altrettanto ovviamente, non gli consiglierei mai di usare nient'altro. :D

Per quelle aziende che invece hanno intenzione di gestire un numero non proprio piccolissimo di VM ma allo stesso tempo neanche troppo elevato (~20) un sistema KVM mi sembra proponibile, così come un sistema Hyper-V ;)

Ciao. :)

Assolutamente vero, io mi riferivo a situazioni che hanno bisogno di qualcosa in più che 1-2 VM.

Per farti un esempio, l'altro giorno ero in visita da un cliente con centinaia di VM e backend su SAN EMC2: ovviamente usa VMWare Infrastructure / vSphere (basati su nodi ESX/ESXi) e, altrettanto ovviamente, non gli consiglierei mai di usare nient'altro. :D

Per quelle aziende che invece hanno intenzione di gestire un numero non proprio piccolissimo di VM ma allo stesso tempo neanche troppo elevato (~20) un sistema KVM mi sembra proponibile, così come un sistema Hyper-V ;)

Ciao. :)

già, a leggere certi interventi invece sembra che se non hai il "top dei top (topper harley)" (citaz. hot shots :D ) non hai capito una mazza/sei uno schiavo di questo o quel prduttore...contento di sapere che ci sono altri che pur riconoscendo l'utilità di avere un cannone sanno ammettere che per sparare alla mosche è un tantinello esagerato :)

ciao :)

Occhio che la maggior parte dei benchmark "amatoriali" di KVM / VirtualBox / VMWare che vedi in giro sono completamente sballati e spesso le misurazioni sono fatte in condizioni profondamente differenti (es: write barrier abilitate da una parte e disabilitate dall'altra, caching in scrittura del disco abilitato vs caching disabilitato, ecc.)

in due nano secondi, cosa sono le write barrier?

ESXi + vMotion non è in grado di fare la stessa cosa (migrazione senza storage condiviso)?

Ciao. :)

senza storage condiviso gli ESX non possono lavorare assiemne nello stesso cluster quindi oltre al vMotion non puoi fare praticamente nulla.

senza storage condiviso gli ESX non possono lavorare assiemne nello stesso cluster quindi oltre al vMotion non puoi fare praticamente nulla.

Interessante, grazie dell'info.

A dire il vero immaginavo che la migrazione senza storage condiviso fosse possibile, ma evidentemente è un "artefatto" della natura prettamente enterprise di ESXi.

Ciao. :)

in due nano secondi, cosa sono le write barrier?

Sono dei costrutti che garantiscono che l'informazione sia salvata su un supporto durevole (es: piatto del disco fisso). Senza di esse, anche quando il s.o. esegue delle scritture sincrone i dati vanno a finire nella memoria cache dei dischi, e solo in un secondo momento vengono sparati sui piatti fisici.

Abilitando le write barrier o i comandi FUA (forced unit access - accesso forzato ai piatti), una scrittura sincrona non viene considerata "ok" se prima non raggiunge i piatti fisici (e quindi lo storage permanente). Ovviamente un setup con write barrier abilitato è più lento di uno con le stesse disabilitate, ma è anche più sicuro. La cosa "simpatica" è che ext3, di default, teneva la barrier disabilitate.

Per fare un esempio della differenza di prestazioni che può passare tra una configurazione e l'altra, pgbench (un benchmark per postgresql) può passare dalle ~30 transazioni al secondo con barrier abilitate a oltre 200 con barrier disabilitate.

Per altre info, ti rimando a un articolo che ho scritto io: http://www.ilsistemista.net/index.php/virtualization/23-kvm-storage-performance-and-cache-settings-on-red-hat-enterprise-linux-62.html?start=1

Ciao. :)

grazie mille :)

rimane un problema rispetto ad Hyper-V: la compatibilità hardware è molto inferiore...hyper-v gira se ci gira sopra win server 2008 e versioni successive: praticamente ogni cosa sulla terra (certo le prestazioni cambiano ma il punto rimane: se hai un server uscito dopo il 2007 al 99.9% puoi installare l'hypervisor di casa MS)....e per piccole cose è comodo visto che ce l'hai già se hai una macchina con win server attivando il relativo ruolo.
Ancora da win 8 in avanti Hyper-v è disponibile anche nella versione client del SO con piccole differenze rispetto alla verione server: comodo per preparare al volo macchine virtuali e metterle in linea su un server adatto quando possibile.
Per piccole aziende che non hanno grosse esigenze ed hanno già un server win 2008R2 e successivi hyper-v è un buon affare nel rapporto risultati/mal di testa...per situazioni più grandi onestamente non saprei dire ma girando comincio a vederne.Io non ne sono così convinto.
Premesso che non l'ho usato in prima persona, però data l'integrazione con Windows Server immagino si porterà dietro tutte le rogne storiche di Windows, non ultima il fatto che "una settimana sì a l'altra pure" ti toccherà riavviare l'hypervisor per qualche becero aggiornamento del sistema operativo, con tutti i disagi e i casini intergalattici che questo comporta.

Hyper-V sarà anche buono come si vocifera (fin'ora di prove concrete sul campo, ovvero esperienza concrete in produzione per periodi di tempo consistenti non ne ho ancora viste) ma il punto focale è che di fatto sotto c'è Windows con tutti i suoi difetti, oltre al fatto che il supporto OS lato guest mi pare alquanto ridotto.
Leggere i dettagli sugli os supportati lato guest e trovare postille che dicono di affidarsi a qualche plugin o soluzione home-made dello smanettone di turno... beh non so voi ma a me non da molta fiducia.
E francamente dal mio punto di vista è un tantino più importante la compatibilità guest piuttosto che host, il server che ospiterà l'hypervisor si può progettare, selezionare e adattare con calma e seguendo le direttive del produttore dell'hypervisor (e da questo punto di vista la tabella di compatibilità dell'hw di vmware è esemplare); dalla mia esperienza è lato guest che può succedere tutto e il contrario di tutto, ci sono scenari in cui le vm vengono accuratamente preparare, ma molti casi in cui la virtualizzazione è il classico ciambellone di salvataggio in caso di disaster recovery, e scoprire in quei casi che l'os del proprio guest non gira... beh immagino possa essere "spiacevole" ;)

Si identifica vmware come il cannone di turno perchè di fatto lo è, volente o nolente è la tecnologia di virtualizzazione leader di fatto, e meritatamente imho.
Ma ricordiamoci che non è leader solo perchè permette di implementare architetture complesse e scalabili, "enterprise" se vogliamo parlare figo; ricordiamoci che fino a pochi anni fa erano veramente in pochi anche solo a ipotizzare che vmware esx sarebbe riuscito a sfondare in produzione.
VMware ha veramente sfondato solo quando ha reso la sua offerta modulare e adatta anche alle piccole realtà, che di cluster non sanno che farsene ma che comunque con un semplice kit Essentials posso ottenere features che con pochi sforzi permette loro di ottenere ottimi risultati paragonabili a quelli di architetture enterprise ben più costose.
Vmware che saputo creare fiducia nei suoi sostenitori con un'ottima gestione lato guest maturata in anni e anni di workstation, player, GSX, Server 1.0, Server 2.0, fondamentali per convincere la gente che con vmware le vm (che poi sono il vero obbiettivo) girano, punto.
Consolidato lo scenario guest Vmware ha cercato di consolidare l'approccio host con ESX e poi ESXi e la sua offerta modulare (a mio parere uno dei pochissimi caso in cui questo approccio ha funzionato, e ha funzionato benissimo).
Vmware ha creato consenso e fiducia partendo dal basso, sia tecnicamente che dal punto di vista dell'approccio al cliente (prima che esplodesse presso il grande pubblico con ESXi vmware era un nome conosciuto solo tra gli addetti ai lavori).

Microsoft a mio parere sta seguendo la strada opposta, e imho in questo sta facendo un errore grossolano.
Mi pare che si stia prodigando in sforzi colossali (soprattutto di marketing) per convincere analisi e media che il loro prodotto è migliore, ma focalizzandosi sull'hypervisor e non sui guests, sullo strumento e non sul risultato finale (che poi è quello che conta); il tutto poi condito da campagne stampa e sforzi di marketing incredibili, tanto da arrivare prima alle orecchie degli utenti comuni piuttosto che a quelle degli addetti ai lavori (che nel frattempo sono occupati a lavorare con vmware :asd: ). Questa marketta di hwupgrade è solo l'ennesima, ed è un esempio eclatante di questo approccio.

Questo è quello che sto percependo io, utente finale della virtualizzazione che tutto fa tranne che amministrare hypervisor (a parte un paio di gloriosissimi vmware server 1.0 e 2.0 che ancora oggi fanno la loro porca figura e in paio di occasioni hanno "bagnato il naso" agli ipercluster Telecom basati su ESX ;) ).

Riguardo alle possibilità di Hyper-V però dovresti tener presente che lo scenario che hai proposto (server con qualche vm senza troppe pretese, client gratuito dove poter lavorare in pace e in grado di migrare la vm al server) è tranquillamente fattibile anche con ESXi e Vmware Player, il tutto senza sganciare una lira.

Occhio che la maggior parte dei benchmark "amatoriali" di KVM / VirtualBox / VMWare che vedi in giro sono completamente sballati e spesso le misurazioni sono fatte in condizioni profondamente differenti (es: write barrier abilitate da una parte e disabilitate dall'altra, caching in scrittura del disco abilitato vs caching disabilitato, ecc.)

Personalmente sono anni che faccio test dei vari virtualizzatori (nella firma c'è il mio sito :D) e posso assicurarti che se non configurati a dovere, mostrano risultati completamente fuorvianti (in peggiore probabilmente è KVM, che con il default setting "writethrough" ha prestazioni 5 volte peggiori nell'I/O disco). Comunque qui entriamo in un altro discorso...

Riguardo alla tecnologia sottostante, su hardware che supporta le VT-x / AMD-V il concetto è simile per tutti i virtualizzatori: eseguire nativamente il codice applicativo direttamente all'intero dei costruitti ASM VMENTER / VMEXIT. Questo vuol dire che dal punto di vista computazionale, su processori recenti tali sistemi sono molto simili. Discorso diverso per i processori più vecchiotti, dove il binary recompliler di VMWare (ma anche di VirtualBox) è molto avanti rispetto a quello di Qemu (volutamente tralasciato).

Se poi mi parli di VMWare Server concordo col dire che è un prodotto da sconsigliare, in quanto vecchio e non più aggiornato (e con problemi di compatibilità con le libc recenti). Tuttavia ESXi è tutto un altro paio di maniche ;)



Sicuramente in ambito web le Debian sono (giustamente) diffuse, ma in ambito database / virtualizzatori, a livello enterprise le distribuzioni più usate sono RHEL e Suse (soprattutto nei datacenter).

Ciao. :)
grazie per le info, molto interessanti :D
mi spieghi sta cosa del writethrough? dove posso smanettarla ? :sofico:

proprio ieri mi è capitata una cosa strana, ho untarrato un file di 12 gb e si è creato un lag nelle vm che con file inferiori (6-7 gb) non avevo notato..sarà colpa di questo parametro?

grazie per le info, molto interessanti :D
mi spieghi sta cosa del writethrough? dove posso smanettarla ? :sofico:


Guarda, il concetto è abbastanza semplice.

Quanto un normale programma scrive qualcosa sul disco, i dati in realtà non raggiungono il disco ma vengono temporaneamente parcheggiati in un'area di memoria che si occupa del write-caching. Questo consente al sistema di accumulare parecchie scritture (anche divesi GB di dati), non impegnando immediatamente i dischi e quindi non inficiando la velocità di risposta del sistema. Tale modalità di caching si chiama writeback.

C'è un problema però: cosa succede se la macchina crasha? Semplicemente, quei dati (mantenuti nell'area di memoria dedicata al write-caching) vanno persi. Di conseguenza, se un'applicazione ha da scrivere dati importanti, dopo ogni scrittura deve invocare un fsync() (o similari) per indicare al sistema operativo che quei dati devono essere immediatamente sparati sul disco.

A questo punto, se le write barrier sono abilitate, si può essere ragionevolmente certi che i dati siano davvero arrivati sui piatti del disco.

Ora spostiamo il discorso in campo virtual machine. Dal punto di vista del s.o., i vari software di virtualizzazione come KVM e VirtualBox non sono altro che normali applicazioni. Dato che però all'interno delle immagini dei dischi delle VM ci sono dati vitali per le VM stesse (per esempio, i metadata del filesystem delle singole VM), l'accoppiata KVM + virt-manager impostava l'apertura dei file immagine con il flag O_SYNC, specificando al s.o. che _ogni_ scrittura che raggiunge il file immagine deve essere sincrona. Questa modalità è detta write-through.

Il problema è che i vari FS (così come il layer VFS) supportati da Linux non garantiscono performance ottimali quando un file viene aperto col flag O_SYNC (questo è proprio il motivo per chi generalmente i file vengono aperti senza tale frag e solo quando necessario viene invocata una fsync()).

Di conseguenza, usando le impostazioni predefinite (per lo meno fino a RHEL 6.1, ma immagino anche nelle 6.2/6.3) KVM + virt-manager hanno prestazioni molto basse. Basta cambiare tipologia di caching e le prestazioni aumentano di molto.

Ma usare una VM in modalità write-back non è pericoloso per l'integrità dei dati? Si, e proprio per questo di default viene usata una cache write-through. Tuttavia, con i recenti avanzamenti fatti nel codice storage di KVM, usare una cache write-back è diventato sicuro, in quanto qualunque fsync() invocata all'interno della VM viene passata _anche_ al sistema operativo host, con tanto di write barrier.

In altre parole, una cache write-through è intrinsecamente più sicura, a tal punto che le applicazioni che girano nella VM possono avere un livello di sicurezza nella scrittura dei dati uguale o superiore a quello delle applicazioni che girano sull'host. Tuttavia, le prestazioni sono così basse che la soluzione migliore è quella di usare una cache writeback + fsync() + barrier o, in alternativa, impostare KVM per non usare nessuna cache ("none"). In questo caso, il file immagine verrebbe aperto col flag O_DIRECT che, pur non dando le stesse garanzie di O_SYNC o delle fsync(), è sicuramente più affidabile che una cache write-back _senza_ fsync().

Chiaramente ho semplificato un po', ma per altre info puoi vedere i seguenti link:
- http://www.ilsistemista.net/index.php/virtualization/11-kvm-io-slowness-on-rhel-6.html?start=2
- http://www.ilsistemista.net/index.php/virtualization/23-kvm-storage-performance-and-cache-settings-on-red-hat-enterprise-linux-62.html?start=2
- http://www.linuxfoundation.jp/jp_uploads/JLS2009/jls09_hellwig.pdf

Poi ci sarebbe tutto il discorso da fare sui file Qcow2, che fino a RHEL 6.1 erano lentissimi a meno che non venissero preallocati i dati in fase di creazione del file. E comunque i file Qcow2 secondo me hanno anche altri problemini, e per questo molte interfaccie basate su KVM creano, di default, file RAW.

Detto questo, quando feci delle prove con ProxMox non ricordo palesi cali di performance, quindi penso che i suoi settaggi di default siano più che ragionevoli.


proprio ieri mi è capitata una cosa strana, ho untarrato un file di 12 gb e si è creato un lag nelle vm che con file inferiori (6-7 gb) non avevo notato..sarà colpa di questo parametro?

Quanta RAM ha la tua macchina? Se ne hai parecchia, è possibile che la maggior parte dei file che hai estratto finissero nella write-cache, e solo in un secondo momento (e con un'efficienza maggiore) venissero inviati al disco.
Con un file da 12 GB invece la write-cache si sarà riempita e quindi sarà stata inviata al disco immediatamente, causando il rallentamento.

Ciao. :)

Quanta RAM ha la tua macchina? Se ne hai parecchia, è possibile che la maggior parte dei file che hai estratto finissero nella write-cache, e solo in un secondo momento (e con un'efficienza maggiore) venissero inviati al disco.
Con un file da 12 GB invece la write-cache si sarà riempita e quindi sarà stata inviata al disco immediatamente, causando il rallentamento.

Ciao. :)

grazie per la risposta molto interessante, in effetti è una spiegazione convincente :D
ma secondo te con file di quelle dimensioni (che poi sarebbero i backup dei vari hd.raw) non mi conviene quindi tarrarli? meglio backupparli nudi e crudi? :D
grazie ancora ;)
ram non esagerata, 8GB

grazie per la risposta molto interessante, in effetti è una spiegazione convincente :D
ma secondo te con file di quelle dimensioni (che poi sarebbero i backup dei vari hd.raw) non mi conviene quindi tarrarli? meglio backupparli nudi e crudi? :D
grazie ancora ;)
ram non esagerata, 8GB

Ciao,
sul fatto se convenga o meno usare tar dipende da quanti file hai da archiviare e da come intendi gestirli. Personalmente, per il backup dei raw stocco i file così come sono, senza usare tar.

Un paio di cose utili da fare:
- se usi "cp" per copiare i raw, assicurati di passargli l'opzione --sparse=always, così le parti dei file sorgenti che sono pieni di zeri verranno automaticamente copiate in una modalità che prevede che il file destinazione non sia riempito di zeri, ma con dei segnaposto che ne indicano la presenza. Risultato: maggiore velocità nella copia e minore dimensione dei file destinazione
- se vuoi fare ancora di meglio, non usare cp ma usa ddrescue con le opzioni "-d -S", così da avere sia gli sparse file (-S) sia un migliore utilizzo della memoria (-d indica di aprire il file sorgente in modalità diretta, bypassando la cache del sistema operativo, e andando così a evitare che la lettura dei grossi file raw interferisca con il read caching delle virtual machine che stanno girando).

Ciao. :)

Ciao,
sul fatto se convenga o meno usare tar dipende da quanti file hai da archiviare e da come intendi gestirli. Personalmente, per il backup dei raw stocco i file così come sono, senza usare tar.

Un paio di cose utili da fare:
- se usi "cp" per copiare i raw, assicurati di passargli l'opzione --sparse=always, così le parti dei file sorgenti che sono pieni di zeri verranno automaticamente copiate in una modalità che prevede che il file destinazione non sia riempito di zeri, ma con dei segnaposto che ne indicano la presenza. Risultato: maggiore velocità nella copia e minore dimensione dei file destinazione
- se vuoi fare ancora di meglio, non usare cp ma usa ddrescue con le opzioni "-d -S", così da avere sia gli sparse file (-S) sia un migliore utilizzo della memoria (-d indica di aprire il file sorgente in modalità diretta, bypassando la cache del sistema operativo, e andando così a evitare che la lettura dei grossi file raw interferisca con il read caching delle virtual machine che stanno girando).

Ciao. :)
ti ringrazio molto, sempre gentile :D
ddrescue lo provo al volo, ottima sta cosa degli 0 infatti era l'unico motivo per cui usavo tar... per evitare inutili sprechi di spazi con gli zeri :ciapet:

root@debian-pc:~# ddrescue
bash: ddrescue: command not found
:wtf:

root@debian-pc:~# ddrescue
bash: ddrescue: command not found
:wtf:

Prova a cercarlo nel repository via apt ;)

senza storage condiviso gli ESX non possono lavorare assiemne nello stesso cluster quindi oltre al vMotion non puoi fare praticamente nulla.

Ciao,
riquoto il post solo per segnalare che nella versione 5.1 di ESXi c'è la possibilità di effettuare live migration anche _senza_ storage condiviso: http://www.vmware.com/products/datacenter-virtualization/vsphere/vmotion.html

Ciao. :)