http://blog.vettore.org/
Non sono mai stato un sostenitore di LVM.
Nelle installazioni server lo evito come la peste perché, a fronte di qualche indubbio vantaggio, vi è il rischio concreto di dover profondere un impegno aggiuntivo nel recupero dei dati nelle situazioni di disaster-recovery.
Per questo motivo solitamente opto per una normalissima partizione EXT4 con il mountpoint di root :-).
Ma addentrandomi nel mondo di KVM-qemu come già visto nel mio precedente articolo, mi sono reso conto della grande utilità di gestire le immagini delle macchine virtuali come volumi logici.
Il vantaggio più evidente è il supporto degli snapshot: e’ possibile in qualsiasi momento effettuare uno snapshot di un volume. Tale snapshot si comporta a tutti gli effetti come un volume logico e può essere utilizzato senza intaccare il volume originale.
Questo aspetto è molto utile in un sistema virtualizzato in quanto consente di effettuare backup e clonare a caldo le macchine virtuali.
Tra i vantaggi accessori vi è la possibilità di ridimensionare facilmente i volumi per adattarsi alle mutate esigenze della macchina virtuale che contengono.
Nella precedente installazione mi ero affidato ad immagini su file. Il sistema ha funzionato per 2 anni senza il minimo problema, ma ora voglio portare le immagini su volumi logici per effettuare sperimentazioni avanzate. Si può fare?.
La risposta ovviamente è positiva. Uno degli aspetti di LINUX che mi ha sempre affascinato è il fatto che il sistema può trattare allo stesso modo i file ed i dispositivi a blocchi. E’ possibile creare un filesystem in un file e montarlo come se fosse un disco. O copiare l’immagine di un disco su un file ed utilizzarla per lavorare.
Quello che andremo a fare ora, con qualche cautela, è esattamente l’opposto. Bisognerà trasferire un immagine in un dispositivo a blocchi (volume LVM) appositamente creato.
Per l’occorrenza ho installato un nuovo disco da 2TB vuoto che è diventato il nostro /dev/sdb.
Il disco separato velocizzerà il trasferimento delle immagini in quanto la copia di una grossa quantità di dati (parliamo di centinaia di GB) tra unità differenti è molto più celere.
Partiamo da una situazione con 4 macchine virtuali in esecuzione, tutte con immagine su file (alcune raw altre QCOW2):
Iniziamo creando una partizione da 960GB con fdisk:
[root@kvm ~]# fdisk /dev/sdb
Comando (m per richiamare la guida): n
Azione comando
e estesa
p partizione primaria (1-4)
p
Numero della partizione (1-4): 1
Primo cilindro (1-243201, predefinito 1):
Utilizzo del valore predefinito 1
Last cilindro, +cilindri or +size{K,M,G} (1-243201, predefinito 243201): +960G
Comando (m per richiamare la guida): p
Disco /dev/sdb: 2000.4 GB, 2000398934016 byte
255 testine, 63 settori/tracce, 243201 cilindri
Unità = cilindri di 16065 * 512 = 8225280 byte
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Identificativo disco: 0x00000000
Dispositivo Boot Start End Blocks Id System
/dev/sdb1 1 125321 1006640901 83 Linux
Comando (m per richiamare la guida): w
Ora che abbiamo la partizione andremo a creare il volume fisico (phisical volume) nel quale posizioneremo il gruppo delle immagini e, per concludere, tutte le immagini delle macchine virtuali.
Questo non è ovviamente l’unico layout possibile.
Troverete altre guide su internet che suggeriscono di creare un unico volume logico contenente tutti i file delle immagini, acquisendo comunque il vantaggio dello snapshot (in questo caso di tutte le macchine virtuali contemporaneamente).
Io preferisco un volume per ogni immagine perché a livello di prestazioni credo per LINUX sia più agevole lavorare con volumi piuttosto che con file di grossissime dimensioni.
Inoltre mi sembra un layout più ordinato e consente di gestire ogni singolo volume separatamente dando la possibilità di effettuare, oltre che gli snapshot, anche operazioni di ampliamento/ridimensionamento in maniera molto più semplice.
Ecco come creare un volume fisico:
[root@kvm ~]# pvcreate /dev/sdb1 Physical volume "/dev/sdb1" successfully created [root@kvm ~]# pvdisplay "/dev/sdb1" is a new physical volume of "960,01 GiB" --- NEW Physical volume --- PV Name /dev/sdb1 VG Name PV Size 960,01 GiB Allocatable NO PE Size 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID 1fsEer-kgmc-fE6K-BM8J-ErYi-FcUQ-kQD6c0
Il comando pvdisplay visualizza tutte le caratteristiche del volume.
Ora, all’interno del nuovo volume fisico, creiamo il gruppo logico immagini_kvm che diventerà la nostra nuova area di storage:
[root@kvm ~]# vgcreate immagini_kvm /dev/sdb1 Volume group "immagini_kvm" successfully created [root@kvm ~]# vgdisplay --- Volume group --- VG Name immagini_kvm System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 1 Act PV 1 VG Size 960,00 GiB PE Size 4,00 MiB Total PE 245761 Alloc PE / Size 0 / 0 Free PE / Size 245761 / 960,00 GiB VG UUID q34miK-iqQl-hpLi-ndjh-5lLy-CVJ0-bIvP9J
Il comando vgdisplay è molto utile perché, tra le altre informazioni, riporta quanto spazio di allocazione è ancora disponibile nel volume fisico.
Ora è giunto il momento di dire al nostro KVM che può usare questo gruppo per lo storage dei volumi delle VM. Si può fare direttamente da virt-manager:
Ecco che compare nell’elenco degli storage disponibili:
Se non viene visualizzato e sufficiente cliccare sul pulsantino di refresh (quello in fianco a “volumi”).
A partire da questo momento potrete utilizzare direttamente la GUI di virt-manager per creare nuovi volumi, per esempio durante l’installazione di nuove maccine virtuali.
Ora arriva la parte più delicata. Dobbiamo trasformare immagini di tipo diverso (QCOW, RAW) in volumi logici.
Ci verrà in aiuto l’utility qemu-img, vero e proprio coltellino svizzero dello storage KVM-Qemu.
Iniziamo con il server MINECRAFT che ha uno storage su immagine di tipo Qcow2.
Prima di tutto dobbiamo conoscere la dimensione esatta del volume logico che dobbiamo creare.
L’occupazione del file immagine non è attendibile in quanto il alcuni formati (p. es qcow) hanno implementato il thin-provisioning, cioè lo spazio su disco viene allocato solo all’occorrenza.
Ma con qemu-img possiamo ricavare tutte le informazioni necessarie:
[root@kvm images]# qemu-img info MINECRAFT.qcow2 image: MINECRAFT.qcow2 file format: qcow2 virtual size: 100G (107374182400 bytes) disk size: 48G cluster_size: 65536
Per essere più precisi prendiamo il valore in byte dell output precedente e creiamo il volume nel gruppo immagini_kvm chiamandolo MINECRAFT:
root@kvm images]# lvcreate -L 107374182400b -n MINECRAFT immagini_kvm Logical volume "MINECRAFT" created [root@kvm images]# lvdisplay --- Logical volume --- LV Path /dev/immagini_kvm/MINECRAFT LV Name MINECRAFT VG Name immagini_kvm LV UUID cHFaH0-QtQZ-jieD-55CN-fYyT-ycfv-mzghvS LV Write Access read/write LV Creation host, time kvm.vettore.loc, 2013-06-02 09:20:04 +0200 LV Status available # open 0 LV Size 100,00 GiB Current LE 25600 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0
Il suffisso b che abbiamo usato nel comando lvcreate ci ha consentito di creare un volume che occupa un numero di byte precisamente uguale a quella dello storage da trasferire.
Ora purtroppo dobbiamo arrestare la macchina virtuale per ottenere un’immagine consistente e statica.
Altrimenti con ogni probabilità l’immagine stessa cambierebbe durante la copia, portando a risultati imprevedibili.
In questo caso, avendo utilizzato Qcow2 si potrebbe effettuare uno snapshot e lanciare la copia senza arrestare il server, ma dalla mia esperienza gli snapshot su Qcow2 non sono molto affidabili: ecco come appare l’info su un immagine di storage (tuttora online) sulla quale ho giocato un po’ con gli snapshot:
[root@kvm images]# qemu-img info UBUNTU12.qcow2
image: UBUNTU12.qcow2
file format: qcow2
virtual size: 40G (42949672960 bytes)
disk size: 31G
cluster_size: 65536
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
� 2.0K 2030-11-04 12:19:44 00:18:19.914
0 1970-01-01 01:00:00 00:00:00.000
4.0G 1970-01-01 01:00:005124095:34:33.709
Quindi, inutile andare a cercarsi rogne, i giocatori di MINECRAFT che si connettono al mio server possono attendere qualche minuto mentre trasferisco l’immagine.
Dopo l’arresto della macchina virtuale:
[root@kvm images]# qemu-img convert MINECRAFT.qcow2 -O raw /dev/immagini_kvm/MINECRAFT
Lanciato il comando non resta che attendere che la nostra utility converta l’immagine da Qcow2 a raw e la copi sul volume logico appena creato. L’operazione può richiedere da qualche minuto a qualche ora.
Fatto questo non resta che editare le proprietà della macchina virtuale utilizzando l’interfaccia grafica, cancellare il vecchio storage ed aggiungerne uno nuovo di tipo virtIO (evitate la più lenta emulazione IDE) con immagine in formato raw selezionando dallo storage immagini_kvm l’unità MINECRAFT.
Avviando la macchina non dovrebbero esserci sorprese. Il boot avviene infatti senza problemi.
Sul mio server ho notato la brutta tendenza ad andare in SWAP effettuando queste operazioni sulle immagini, nonostante abbia più di 3 GB di ram disponibile. Ecco come si presenta lo stato della memoria:
[root@kvm ~]# free
total used free shared buffers cached
Mem: 7801732 7664200 137532 0 2638420 2602632
-/+ buffers/cache: 2423148 5378584
Swap: 1435440 1435440 0
Con una situazione di questo tipo prestazioni globali sono del tutto compromesse e anche l’operazione di copia, rischia di andare per il lungo.
Vista l’abbondanza di memoria libera ho deciso di rischiare disattivando lo swap:
[root@kvm images]# swapoff -a ...............................
Le prestazioni sono ritornate normali una volta raggiunto il seguente stato:
[root@kvm ~]# free
total used free shared buffers cached
Mem: 7801732 7644716 157016 0 2005808 1938776
-/+ buffers/cache: 3700132 4101600
Swap: 0 0 0
Se decidete di farlo ricordatevi, una volta finita la manutenzione, di riattivare lo swap!
In maniera analoga trasferiamo le altre immagini.
Ecco la situazione finale sullo storage:
Per il momento ho notato un certo incremento globale delle prestazioni.
Non so se sia dovuto all’utilizzo di volumi veri e propri o al provisioning che non è più thin (lo spazio è allocato per intero).
Nel prossimo articolo vedremo come sia possibile sfruttare le caretteristiche di LVM per creare snapshot a caldo, duplicare (sempre a caldo) le macchine virtuali ed effettuare backup consistenti senza interrompere le operazioni della singola macchina virtuale.
Fabrizio Vettore
[…] E’possibile persino “clonare” la VM (non in esecuzione) direttamente dall’interfaccia grafica (nelle prossime puntate vedremo come farlo a caldo). […]
[…] riferimento al precedente articolo, ecco qual’era la situazione durante l’esportazione delle immagini delle macchine […]
[…] Nell’articolo precedente abbiamo visto il modo d organizzare i filesystem delle VM come volumi LVM. […]
Complimenti per l’ottimo articolo per la gestione di snapshot con Qemu, ma la mia perplessità è se si utilizza la procedure per macchine virtuali windows la consistenza dei dati è garantita o bisogna utilizzare dei client sui guest per lo snapshot ?
E’ possibile fare snapshot incrementali delle macchine guest ?
Grazie mille per l’articolo