Qual è il formato immagine migliore, raw o qcow2, da utilizzare come immagine di base per altre VM?

Sto usando una baseimage e basandomi sulla creazione di molte macchine virtuali. E ora voglio sapere quale è meglio, qcow2 o raw da usare per un'immagine di base. Inoltre, puoi dirmi se c'è qualche vantaggio nell'usare questa cosa baseimage, invece di clonare l'intero disco. La velocità può essere un fattore, ma in termini di efficienza c'è qualche problema nell'uso di una baseimage e nella creazione di macchine virtuali usando quella base?

Modifica 1:

Ho eseguito alcuni esperimenti e ho ottenuto inserisci qui la descrizione dell'immagine

Il primo è quando sia l'immagine di base che l'overlay sono qcow2. Secondo Quando baseimage è raw ma l'overlay è qcow2 e nel terzo caso sto dando un'immagine di disco raw individuale a ogni VM. Sorprendentemente, l'ultimo caso è molto più efficiente rispetto agli altri due.

Setup sperimentale: 
Sistema operativo in base immagine: Ubuntu Server 14.04 64 bit.
Sistema operativo host: Ubuntu 12.04 64 bit
RAM: 8 GB
Processore: CPU Intel® Core ™ i5-4440 a 3,10 GHz × 4 
Disco: 500 GB

Sull'asse x: numero di macchine virtuali avviate contemporaneamente. A partire da 1 e incrementato fino a 15.

Sull'asse y: tempo totale di avvio del numero "x" di macchine.

Dai grafici, sembra che fornire l'immagine completa del disco alla VM sia molto più efficiente di altri 2 metodi.

Modifica 2: inserisci qui la descrizione dell'immagine

Questo è il caso in cui stiamo dando un'immagine grezza individuale a ciascuna VM. Dopo aver eseguito lo svuotamento della cache, questo è il grafico. È quasi simile al grezzo baseimage + qcow overlay.

Grazie.

— AB
fonte

Vorrei utilizzare un'immagine di base non elaborata e sovrapporre QED invece di qcow2. QED è più veloce di qcow2 e ha meno probabilità di essere danneggiato dalla progettazione.

— Matt,

@Matt si prega di commentare la domanda modificata.

— AB

Le differenze di prestazioni sono interessanti. Puoi provarlo con qed? potrebbe essere un problema di contesa / blocco nell'implementazione di qcow2. Credo che abbia alcuni problemi ed è per questo che hanno inventato Qed.

— Matt,

@Matt Ho controllato con overlay raw baseimage-qed e overlay raw baseimage-qcow2. Ma qed è molto più lento di qcow2 in questa impostazione.

— AB,

Risposte:

Per il tuo caso d'uso specifico (immagine di base + overlay qcow2), il formato RAW dovrebbe essere preferito:

È più veloce: poiché non ha metadati associati, è il più veloce possibile. D'altra parte, Qcow2 ha due livelli di riferimento indiretto che devono essere attraversati prima di colpire i dati effettivi
Poiché il livello di overlay deve essere un file Qcow2, non si perde la capacità di istantanea sempre utile (le immagini RAW non supportano le istantanee da sole)

La scelta tra immagine di base + overlay qcow2 rispetto a più copie complete dipende dalla priorità:

Per prestazioni assolute, utilizzare immagini RAW con errori di riproduzione. Questo ha il rovescio della medaglia di non supportare lo snapshot, con nella maggior parte degli ambienti un prezzo troppo alto da pagare
Per flessibilità ed efficienza dello spazio usa immagini di base RAW + overlay Qcow2.

Comunque, ho trovato i file Qcow2 un po 'fragili.

Per i miei hypervisor KVM di produzione utilizzo sostanzialmente due diverse configurazioni:

dove le prestazioni sono n. 1 Uso i volumi LVM direttamente collegati alle macchine virtuali e utilizzo la funzionalità di snapshot LVM per eseguire backup coerenti
dove posso sacrificare alcune prestazioni per una maggiore flessibilità, uso un singolo, grande volume LVM Thin Provisioned + immagini XFS + RAW

Un'altra possibilità è quella di utilizzare un normale volume LVM + immagini XFS + RAW. L'unico aspetto negativo è che le normali snapshot LVM (non sottili) sono molto lente e lo snapshot di un volume LVM normale occupato causa la morte delle prestazioni (per tutta la durata dell'istantanea). Ad ogni modo, se prevedi di utilizzare solo un uso sporadico di istantanee, questa può essere la scommessa più semplice e sicura.

Alcuni riferimenti:
Lentezza I / O KVM su RHEL 6
Prestazioni di archiviazione KVM e prellocalizzazione Qcow2 su RHEL 6.1 e Fedora 16
Prestazioni di archiviazione KVM e impostazioni della cache su Red Hat Enterprise Linux 6.2
LVM volume ridotto

— shodanshok
fonte

Come detto sopra: le singole immagini RAW saranno più veloci a causa di livelli indiretti non indiretti. Ricorda che stai rinunciando a istantanee (a livello di immagine) e all'efficienza dello spazio, tuttavia. Inoltre, ho l'impressione che il tuo terzo risultato sia stato distorto dalla cache dell'host. A dire il vero, ripetere tutti i test emettendo "sync; echo 3> / proc / sys / vm / drop_caches" tra ogni esecuzione.

— shodanshok,

In realtà stavo pensando lo stesso. Ma poi ho pensato che, in caso di uso effettivo, seguirà lo stesso flusso.

— AB

Non proprio: in questo ambiente di test, stai semplicemente avviando le tue macchine virtuali, senza usarle. In un caso reale, dopo l'avvio verranno utilizzate le macchine virtuali, inquinando la cache. In generale, è meglio eseguire un benchmark con un caso d'uso ragionevole.

— shodanshok,

Hai idea del perché la memorizzazione nella cache non abbia un ruolo così importante nel grafico 1 e nel grafico 2, ad esempio immagine di base Qcow2 + overlay Qcow2 e immagine di base Raw + overlay Qcow2.

— AB,

Si prega di essere informati .... se si utilizza Linux è possibile utilizzare rawe ottenere gli stessi vantaggi per qcow2quanto riguarda le dimensioni.

... Se il tuo file system supporta i fori (ad esempio in ext2 o ext3 su Linux o NTFS su Windows), solo i settori scritti riserveranno spazio.

https://docs.fedoraproject.org/en-US/Fedora/18/html/Virtualization_Administration_Guide/sect-Virtualization-Tips_and_tricks-Using_qemu_img.html

raw Formato immagine disco grezzo (impostazione predefinita). Questo può essere il formato basato su file più veloce. Se il tuo file system supporta i buchi (ad esempio in ext2 o ext3 su Linux o NTFS su Windows), solo i settori scritti riserveranno spazio. Usa qemu-img info per ottenere la dimensione reale usata dall'immagine o ls -ls su Unix / Linux.

— ehi
fonte

Buon punto! Ma sembra che nel backup / copia / compressione venga utilizzata l'intera dimensione del file immagine grezzo. Un file raw da 20 GB che alloca solo 4 MB su disco è stato compresso a 20 MB

— MrCalvin

Questo è stato completamente nuovo per me. Ho una VM in Proxmox VE con un disco virtuale di 30 GB ... e posso vedere che il disco ha le dimensioni nel file system host. Ma il file system host ha un utilizzo complessivo di << 10 GB. Questo è il motivo per cui stavo cercando.

— cljk