In un contesto di virtualizzazione con xen si vuole effettuare un’immagine delle vm: la via più semplice a mio avviso è quella di utilizzare lvm per i dischi virtuali delle vm, e di usare le funzioni di snapshotting integrate in lvm2.
Questo consente di fare l’immagine dei fs delle vm in modo ordinato e pulito. Si fa lo snapshot del filesystem, lo si copia, si rimuove lo snapshot, il tutto live, senza interruzioni di servizio ed evitando rischi. Il risultato sarà un file immagine della vm, che può essere usato, fa le altre cose, per testare updates su un’altra vm usando la direttiva “file” nella configurazione di xen.
Questo è quello che si può ottenere usando dd o simili per fare l’immagine. Tuttavia esiste un’altra soluzione che diventa interessante se il file immagine che si ottiene non deve essere utilizzato “direttamente”. Se al posto di dd usiamo partimage otteniamo tempi molto più brevi e un’occupazione di spazio del file immagine molto minore. Partimage si avvia con una interfaccia n-curses di default, tuttavia è possibile pilotarlo in modalità batch da console specificando le operazioni da utilizzare. Fra le tante:
- split dei files in parti di dimensione specificata
- impostazione di un commento sull’operazione
- impostazione della compressione (niente, gzip, bzip2)
- configurazione di una istanza di partimaged e invio dei files immagine via rete
I vantaggi sono dati principalmente dal fatto che il ripristino dell’immagine è “guidato” lanciando partimage e utilizzandolo via gui ( e questo è importante.. visto che nel caso in cui si vuole ripristinare un’immagine nel 90% dei casi si è “già nei pasticci” e si è piuttosto “tesi”..:) ) e dal fatto che l’utilizzo dello spazio su disco è ridotto rispetto a utility come dd o altri, perchè partimage è filesystem-aware e salta la copia di blocchi ripetuti o inutilizzati, oltre a questo comprime con bzip2 as usual. Facendo dei tests su una immagine di prova da 4.5 GB piena al 60% circa, dd+bzip è stato il doppio del tempo e ha prodotto come risultato 1 file da 600 MB, mentre partimage, nella metà del tempo ha prodotto un file da 400MB circa.
Tutto questo, naturalmente, consente di effettuare delle immagini “full” ad ogni run, non parziali.