Newsgroup: it.comp.os.linux.sys
Titolo: Migrazione su LVM

Ciao a tutti.
Ho un server che gira tranquillamente con Debian Sarge.
Vorrei, sul disco sul quale gira il sistema operativo, implementare LVM
senza dover reinstallare tutto da zero, per poi installare Xen e alcune
macchine virtuali sfruttando il partizionamento del disco con LVM. Le
partizioni di sistema non girano su RAID.
E' possibile una migrazione di un sistema funzionante su LVM senza
perdere tutti i dati?
Qual'è la tecnica da adottare?
Grazie mille!
Ciao
Decibel.

pvmove e vgreduce sono tuoi amici :-)

 perdere tutti i dati?
Certo, fai un bel tar, riformatti tutto e applichi il tar :)
Se intendi invece che vuoi ridurre il downtime della macchina, avrai delle
difficoltà con la partizione di root, posto che volessi migrarla su LVM (e
non è detto che serva). 
-- 
Per rispondermi, togli il nome del poeta

 non è detto che serva).
Non serve ed è anzi una cosa da evitare come la peste.
-- 
Flavio Visentin
Membro del CICAP
Comitato Italiano per il Controllo delle Affermazioni di P4

 
e perche'?

 e perche'?
Non serve perché la root non è un filesystem che varia in modo
considerevole lo spazio occupato, e in ogni caso ad eventuali esigenze
future si può tranquillamente sopperire in modo elegante e pulito
isolando porzioni di filesystem su nuovi volumi (o con mount -o bind).
E' da evitare come la peste perché in caso di problemi è più
difficoltoso il recupero di un server con la root su LVM e non tutti i
cd live lo supportano (
p.es
 Knoppix > 3.4 non integra lvm).
Una manovra di emergenza classica come l'avvio con il parametro
init=/bin/sh non sempre è possibile se hai la root su LVM (
p.es
. se
perdi l'initrd) e quindi ci si troncano inutilmente delle possibilità
senza avere come controparte alcun vantaggio apprezzabile.
Per lo stesso motivo è sempre consigliabile utilizzare sul root
filesystem ext3 come FS, dato che le performance non sono fondamentali
mentre è utilissimo potervi accedere come ext2 in caso di corruzione del
journal o altri eventi catastrofici.
Quindi rootfs su partizione standard in formato ext3 e del resto fai
quel che vuoi.


 journal o altri eventi catastrofici.
Se fossimo nel 2002 ti potrei forse ancora dare ragione ma adesso non è 
più sostenibile (reiserfs,jfs,xfs sono supportati da tutte le distro).

 più sostenibile (reiserfs,jfs,xfs sono supportati da tutte le distro).
E chi ha mai detto che non sono supportati? Io uso sia reiserfs che xfs,
ma non sul rootfs dove la possibilità di montare il disco come ext2 mi è
tornata utile in più occasioni e dove la differenza non la fanno le
performance ma la fa l'affidabilità (imho superiore in ext2/3).


 Non serve ed è anzi una cosa da evitare come la peste.
Dici quindi che tutte le Fedora che mettono / con LVM per default non
funzionano? 


 E chi ha mai detto che non sono supportati? 
Da RHEL non sono supportati.


 funzionano? 
Non ho detto che non funzionano, ho detto e ripeto che in caso di
problemi rendono più difficoltoso il ripristino della macchina.
Finché non ci sono problemi è tutto perfetto, ma tentare di complicarsi
inutilmente la vita è stupido se c'è una valida alternativa.


 filesystem su due nodi diversi.
In tale caso partizionare la SAN offre decisamente maggiori garanzie.


 viene quindi SEMPRE visto come sda da tutti i nodi.
E questo funziona se non ti sbagli a definire la visibilità delle partizioni
sulla SAN. Perchè se ti sbagli hai lo stesso nodo che bho, vede un sda e
magari uno sdb, e diventa difficile capire quale partizione è quella giusta
(ovvero, magari monti sda che è in realtà la sda di un altro nodo). Mentre,
se monti un volume con un nome univoco, hai una garanzia ulteriore, peggiore
ipotesi non monti niente, che è meglio che distruggere i dati.


 Finché non ci sono problemi è tutto perfetto, 
E questo direi che è ovvio. Comunque non hai problemi particolari a
recuperare una partizione con LVM rispetto ad una che abbia direttamente
ext3, assunto che usi una distribuzione che se ti suggerisce LVM abbia poi
dei tool di ripristino congruenti.


 sulla SAN.
Ah beh, se sbagli sono sempre cazzi :-)
La sintesi del mio pensiero, giusto per chiudere, è che LVM sia un
ottimo prodotto ma che *normalmente* sia meglio non usarlo per la
partizione di root se non vi sono chiari motivi che consiglino altrimenti.
Questo non significa che non possa essere usato per questo scopo o che
in determinate circostanze, come quella da te citata, non possa
rappresentare una soluzione anche migliore di quella da me sostenuta.
E' però innegabile che più del 90% dei server GNU/Linux non sono
collegati ad una SAN con la partizione di root sulla stessa, ma sono
comuni server con boot dai dischi interni che al limite su una SAN hanno
i soli dati, configurazione nella quale la root su LVM non offre alcun
vantaggio.
Spero di essermi spiegato meglio adesso.


 dei tool di ripristino congruenti.
]zac[
Su questo ci conterei molto poco.
Problema:
- Prime esperienze di raid1 software e del sistema di installazione.
- Il sistema di installazione ha configurato correttamente un raid1 software
sulla root.
- Rimosso un disco (in maniera un tantinello selvaggia e con inchiodamento
totale) per testare il raid, dopo il successivo riavvio, è venuto alla luce
che il boot loader è presente solo su un disco (curioso che il sistema di
installazione configurando un raid1 software non consideri il guasto del
disco di boot), e guarda caso è quello che è stato selvaggiamente rimosso.
- Il sistema di ripristino già con la root su un semplice raid1 software
fallisce con messaggi un tantinello fuorvianti (del tipo nessuna partizione
trovata!, partizioni non valide!!, formattiamo tutto??).
- Curiosamente(?) dopo l'uso più o meno casuale delle varie opzioni di
ripristino, pur continuando a dire che le partizioni non sono valide e a
suggerire velatamente e senza impegno la 'rasatura totale', la root viene
montata automaticamente ed è correttamente funzionante.
Soluzione:
- Riavvio con DVD di installazione, passaggio immediato alla console, mount
della partizione in raid1 software e rinstallazione del boot loader su
tutti e due i dischi del raid1.
Tempo:
- 1h di tentativi falliti con il sistema di ripristino.
- 1h di lettura di documentazione sul raid1 software, sul boot loader, 10min
per esecuzione del ripristino da console (con una dimostrazione ad un
collega che dare i comandi senza capire che cosa fanno è un tantinello
fonte di trappoloni (il boot loader installato puntava alla /boot presente
su un altro disco, rendendo inutile e pericoloso il raid1)).

 montata automaticamente ed è correttamente funzionante.
Quindi, non è vero che i tool di ripristino non funzionino.


 Quindi, non è vero che i tool di ripristino non funzionino.
???
Quando doveva non è c'è riuscito, facendo una operazione diversa e con
smanettamenti vari è riuscito a montare (per sbaglio) il raid, e comunque
ha sempre fallito la riparazione del bootloader (che era l'unico problema), 
''segnalando'' comunque la necessità di ripartizionare causa partizioni non
valide .......
In sintesi, la mia opinione è che i sistemi di ripristino falliscono già nei
casi più semplici, figurarsi con configurazioni complesse, e che è molto
meglio, se possibile, avere configurazioni risolvibili velocemente dalla
console di ripristino (quindi con una configurazione di avvio del kernel
(di installazione) molto parziale).
Poi è sempre possibile organizzarsi, crearsi i propri strumenti, dal
semplice script a un sistema personalizzato, ma la vedo molto molto dura.