Newsgroup: it.comp.os.linux.sys
Titolo: Xen: merge di dischi

Ho una idea folle: devo fare il merge dei dischi virtuali attaccati ad una VPS.
Sono *undici* visti dal sistema come device fisici con sopra un PV, associato ad un VG e un LV esteso.
 
Se esporto la VM, estraggo il file XVA, riesco a fare il merge dei dischi RAW? Magari un "cat disco1 disco2 disco3 > discofinale" ?
 
Altrimenti faccio la strada più lunga: snapshot, converto in VM, sego tutti i dischi, allargo quello primario (non ho idea di come si faccia, per questo mi ritrovo con 11 dischi) e ripristino i dati dalla VPS rimasta online (quella snapshottata). In 3-4 ore [1] ovvero il tempo di rsync dei dati, dovrei cavarmela.
 
[1] più il tempo di export/restore. 
Xenserver fa brutte cose con gli snapshot convertiti in VM (crea una gigantesca catena di snapshot in stile COW riferita alla VM principale), se sego i dischi ho paura di fare danni, con export+import invece la VM è del tutto indipendente da quella originale. E visto che IMHO, XenServer ha più bug di Wordpress, preferisco stare sul sicuro.

 associato ad un VG e un LV esteso.
 
Aggancia un dodicesimo disco della dimensione totale di tutti i dischi che hai
ora al VG, dopodiché pvmove come se non ci fosse un domani
 
Enrico

 ora al VG, dopodiché pvmove come se non ci fosse un domani
 
Ecco il colpo di genio :)
 
Si può fare online? Migrato tutto, posso eliminare i mille-mila dischi ?

 ora al VG, dopodiché pvmove come se non ci fosse un domani
 
Mentre tiro giù una immagine virtualbox debian per fare dei test, facciamo un po di supposizioni.
 
Io ho
 
/dev/xvda
/dev/xvdb
/dev/xvdc
/dev/xvdd
 
xvda lo lasciamo stare dov'è, c'è il sistema operativo e parte della /home (che è la partizione più grossa)
 
su ciascun disco c'è un PV
Poi ho un VG unico (vg0) che si estende su tutti i PV (che sono 11 in realtà)
Sopra il vg0 ho un po di LV, tra cui quello /home che è 200GB
 
Ora, attacco un nuovo disco, grande come tutti gli altri o di più (supponiamo 250GB), lui me lo assegna come /dev/xvde
Creo un PV:
 
pvcreate /dev/xvde
 
Estendo il vg0 sopra di esso
 
vgextend vg0 /dev/xvde
 
Poi sposto tutti i PV, tranne xvda, in xvde
 
pvmove /dev/xvdb /dev/xvde
pvmove /dev/xvdc /dev/xvde
pvmove /dev/xvdd /dev/xvde
 
Stringo il vg0
 
vgreduce vg0 /dev/xvdb
vgreduce vg0 /dev/xvdc
vgreduce vg0 /dev/xvdd
 
Adesso in teoria posso rimuovere fisicamente xvdb, xvdc, xvdd ?

 Si può fare online? Migrato tutto, posso eliminare i mille-mila dischi ?
 
Sì, personalmente ho usato pvmove per deframmentare volumi LVM su hypervisor
mentre lavoravano senza che gli utenti se ne accorgessero.
Per il tuo caso, personalmente farei così:
 
 - Aggiungo il disco 12:
 - Per ogni disco:
   - pvmove datidisco disco12
   - vgreduce vg disco
   - pvremove disco
 
Il pvremove è opzionale, più che altro rimuove la label che permette il
riconoscimento della partizione come PV LVM
 
Enrico

 Adesso in teoria posso rimuovere fisicamente xvdb, xvdc, xvdd ?
 
Sì
 
Enrico

    - pvremove disco
 
Ok.

 La cosa mi preoccupa alquanto.
 
Che dirti, funzionò e non ho avuto perdita di dati. Poi se non ti fidi posso
essere d'accordo, ma dalla mia esperienza posso affermare che in questo caso
LVM funziona :)
 
Enrico

 LVM funziona :)
 
Ho provato su virtualbox e funziona alla grandissima. Non è nemmeno più presente il warning sulla pardita di dati trovato in un vecchio documento online.
Bisogna però usare la testa e non azzardarsi a fare una cosa del genere da remoto via SSH, che se per sfiga dovesse saltare la sessione, il comando viene killato, è vero che riparte da dove si è interrotto ma meglio usare vnc, per non sapere ne leggere ne scrivere.
 
Detto ciò, la manpage[1] dice:
 
"If pvmove gets interrupted for any reason (e.g. the machine crashes) then run pvmove again without any PhysicalVolume arguments to restart any moves that were in progress from the last checkpoint. Alternatively use pvmove --abort at any time to abort them at the last checkpoint."
 
pertanto mi sembra piuttosto affidabile. Fortunatamente ho tanti dischi piccoli (10-15GB), quindi farne uno alla volta con il tuo metodo (pvmove+vgreduce), potrebbe essere la soluzione, liberando man mano i vecchi dischi in poco tempo.
Discorso diverso con tanti dischi grossi (100-200GB), in quel caso presumo che l'operazione inizi a farsi sentire in termini di load
 
 
[1] 
https://linux.die.net/man/8/pvmove
 

 che l'operazione inizi a farsi sentire in termini di load
 
Come ti ho detto, io ho usato questa tecnica per deframmentare un VG su di una
macchina in esercizio, e non ho avuto rallentamenti di sorta
 
Enrico

 macchina in esercizio, e non ho avuto rallentamenti di sorta
 
Posso provare. Mi preoccupa solo Xen. Non ho idea se mi fa rimuovere o meno un disco da una macchina in funzione (come se fosse hotplug) e se bisogna per forza spegnerla.
 
Comunque sia, se riesco a fare tutto online, mi hai tolto dalle mani una patata bollente, devo fare questa operazione su 3-4 macchine e successivamente upgradare a Jessie. Con il mio metodo sarebbero stati necessari due passaggi invasivi, con il tuo solo quello di upgrade a Jessie

 LVM funziona :)
 
A parte la CAZZATA STRATOSFERICA di dare errore quando si è in test mode :)
 
Se faccio un test, presumo che il risultato finale corrisponda a ciò che mi ritroverei senza test. Invece se faccio vgmove con "-t" esce con errore 5.
 
Comunque, sta migrando, un PV alla volta. iowait nullo. Mah.

 macchina in esercizio, e non ho avuto rallentamenti di sorta
 
Ok. Ho migrato tutti i PV ed ho i rimosso i vecchi dischi da Xen.
speriamo non sia esploso nulla, un controllo terra-terra ha avuto esito positivo: i file sono ancora li.
 
Per non saper ne leggere ne scrivere, ora ho snapshottato e sto facendo un backup della VM da fuori