Newsgroup: it.comp.virtualizzazione
Titolo: LVM su vmware

Vorrei implementare LVM sui miei host Debian (Squeeze) all'interno di un virtual 
center (VmWare 5) da 6 server in san con un'eva e mi stavo chiedendo come LVM 
cambia la logica e si adatta all'uso su vmware.
Nel senso che adesso, senza LVM, quando devo espandere lo spazio dati di un 
server faccio ancora alla vecchia maniera: creo un disco piï¿œ grande e l'associo 
all'host, gli creo sopra un fs (tipicamente ext3), lo monto e ci copio sopra i 
dati dal vecchio disco sperando di aver calcolato bene lo spazio di crescita.
 
Sperando di aver capito bene come funziona, il dubbio che ho ï¿œ se avendo poi la 
partizione che devo allargare su LVM, la logica di creare un altro volume (da 
inserire poi nel VG che voglio espandere) rimane vera oppure posso gestirlo come 
faccio con gli host windows aggiungendo semplicemente dei Giga al disco e 
facendo il rescan del disco via disk manager.
 
In ogni caso mi andrebbe bene comunque perï¿œ vorrei capire se alla fine mi 
conviene cercare di essere di manica larga con la dimensione del disco nel 
momento in cui lo creo per evitare il proliferare di tanti dischi all'interno 
dell'host oppure se posso creare un solo disco, farlo anche poco sopra a quanto 
mi serve e andarlo ad espandere di volta in volta usando solo quel disco nel VG.
 
Altri consigli o attenzioni da prestare per LVM su vmware dove posso trovarli? 
La documentazione che trovo fin ora ï¿œ abbastanza datata (2010/2011) perciï¿œ non 
sï¿œ quanto sia affidabile o attuale.
 
Grazie
Rizio
 
--- news://
freenews.netfront.net/
 - complaints: 
ne...@netfront.net
 ---

 (2010/2011) perciï¿œ non sï¿œ quanto sia affidabile o attuale.
 
Boh, LVM ï¿œ sempre quello, e il fatto di usarlo in virtuale non ne cambia
la sostanza, sicchï¿œ valgono all'incirca le stesse cose...
 
 
Piuttosto, se usi meccanismi di backup+DR agganciati a vmware (a partire
da VDR), assicurati che riescano a gestire il layout che ti proponi di
usare, o ti trovi nella condizione di poter ripristinare tutta una VM ma
non di poter prelevare un singolo file dal backup...
 
 
A parte ciï¿œ, nulla da segnalare.
 
 
 
 
[1] per inciso, ciï¿œ vale anche senza LVM. Se hai un volume "dati", per
dire, che sai poter crescere nel tempo, puoi dedicargli tutto un disco,
*senza* partition table ma formattando e utilizzando direttamente il device.
 
In tal modo, se hai necessitï¿œ di ingrandire tale disco, ti ï¿œ
- ingrandire il disco da VMware
- blockdev --rereadpt
- resize2fs (o quel che ï¿œ)
 
Di fatto, in 'sto scenario LVM nemmeno ti serve...

 lo spazio di crescita.
 
Perchè non ti limiti semplicemente ad espandere il disco virtuale della 
vm e fare un resize2fs del file system?
 
-- 
Bye
Gianfranco Bartolini
(gianfranco punto bartolini at tiscali punto it)

 Di fatto, in 'sto scenario LVM nemmeno ti serve...
 
Si, il timore che ho sempre avuto ï¿œ nell'ultima parte: resize2fs
Ho letto diverse volte di problemi dati dallo shrink di volumi ext3 e ho sempre 
avuto timore di farlo. E se devo fare il backup per poi fare lo shrink dalla via 
facci oil backup su un volume piï¿œ grande e tengo quello.
LVM mi sembrava fosse un pï¿œ piï¿œ flessibile e meno rischioso per quanto riguarda 
i dati, sbaglio?


 fare un resize2fs del file system?
 
Perchï¿œ come dicevo a Skull ho letto alcune volte di perdita di dati dopo un 
resize perciï¿œ ho sempre avuto molta paura. Ammetto che ï¿œ solo ed esclusivamente 
per quello.
 
Lavorando in un'azienda molto "statica" in termini informatici ho sempre creduto 
che il gioco non valesse la candela.
 
Contavo molto su btrfs un paio di anni fï¿œ ma dopo averlo provato sul mio desktop 
ho abbandonato completamente l'idea di utilizzarlo sui server. Come ti dicevo 
sono pochi e statici ma l'idea di rifarli solo perchï¿œ mi ï¿œ andato male un resize 
non mi piace per nulla.


Il 24/07/2013 16.45, Rizio ha scritto:
 
 > Perchï¿œ come dicevo a Skull ho letto alcune volte di perdita di dati dopo
 > un resize perciï¿œ ho sempre avuto molta paura. Ammetto che ï¿œ solo ed
 > esclusivamente per quello.
 
Personalmente non ho mai avuto problemi nï¿œ letto o sentito parlare di 
perdite di dati per un resize di ext3, specialmente nel caso di 
espansione di volume che ï¿œ un'operazione tutto sommato semplice.
Ovviamente sono cose da fare sempre con buon senso, ovvero con un backup 
sempre pronto, ma questo vale per tutto.
 
 > Come ti dicevo sono pochi e statici ma l'idea di rifarli solo perchï¿œ mi
 > ï¿œ andato male un resize non mi piace per nulla.
 
Non vedo rischi minori nel fare un resize di un lvm. Ti puï¿œ andare 
storto qualcosa esattamente allo stesso modo. Piuttosto vedo molto piï¿œ 
utile nel tuo caso l'utilizzo di dischi thin provisioned, che 
probabilmente ti risolverebbero il problema a monte.
 
A mio avviso in un ambiente virtuale come il tuo lvm ha poco senso a 
meno che non si debbano usare i suoi tool specifici per fare backup o 
snapshot. Le feature di LVM (e molto altro di piï¿œ) sono giï¿œ fornite 
dallo storage sottostante, ed in alcuni casi come giustamente faceva 
notare Skull utilizzarlo potrebbe essere penalizzante, ad es. quando 
cerchi di fare backup consistenti a livello d'immagine disco 
direttamente da VMware.


 desktop ho abbandonato completamente l'idea di utilizzarlo sui server.
 
L'ho provato anche io in ambiente di test senza alcun problema pochi
mesi fa.
Poi, per la produzione, ho optato per una soluzione piï¿œ conservativa,
ma solo per non rischiare, non perchï¿œ avessi avuto problemi.
 
Nel tuo caso, invece, cosa ti ha fatto abbandonare l'idea?
 
-- 
Gerolamo

 Nel tuo caso, invece, cosa ti ha fatto abbandonare l'idea?
 
Allora ebbi delle corruzioni della partizione con perdita di dati. La cosa non 
mi tocco piï¿œ di tanto perchï¿œ era proprio per fare dei test ma effettivamente 
anche iscrivendomi alla mailing list notai che non ero l'unico e che erano 
problemi abbastanza frequenti.
 
Sinceramente perï¿œ, come dicevo in apertura parliamo di tantissimo tempo fï¿œ 
perciï¿œ dovrei solo riprovare.
Diciamo che ero attratto da LVM perchï¿œ mi sembrava leggermente piï¿œ flessibile in 
quanto opera ad un layer inferiore rispetto al fs perciï¿œ sopra posso mettergli 
quello che voglio. Non avendo applicazioni mission critical o affamate di 
velocitï¿œ mi posso permettere un pï¿œ di reattivitï¿œ in meno.
 
Ma se sono qui a parlarne ï¿œ proprio per chiarirmi le idee perciï¿œ sono benvenuti 
tutti i confronti, anzi.


 livello d'immagine disco direttamente da VMware.
 
Forse hai ragione, non sò, stavo cercando proprio di raccogliere pareri per 
chiarirmi le idee. Forse la cosa migliore è fare dei lab per verificare con mano 
le due strade. Sicuramente è oro il parere di chi ci è già passato perciò mi fà 
piacere confrontarmi con voi, dopo credo che dipenda solo dal tipo di politica 
con cui voglio gestire le macchine.
 
Intanto grazie


 riguarda i dati, sbaglio?
 
Mah, se il timore ï¿œ il resize del volume, quello lo fai paro-paro sia
che il volume stia su un block device sia che stia su un volume logico...
Anzi, a ben vedere, con LVM hai un layer in piï¿œ a creare potenziali casini.
 
Che sia piï¿œ flessibile ï¿œ fuor di dubbio, ma ci sono casi in cui si vuole
esplicitamente evitare di usarlo, per diverse ragioni...
Il pur piccolo degrado di prestazioni ad esempio, o la mancanza di
supporto da parte -zut zut- di tool di backup ;-)
 
 

 supporto da parte -zut zut- di tool di backup ;-)
 
Diciamo che fortunatamente il mio caso non rientra nelle due casistiche che hai 
citato, mi sento abbastanza fortunato.
 
Cmq sia tu che Gianfranco avete consigliato il semplice uso degli strumenti 
"basici", proverï¿œ poi in caso sï¿œ che mi aspetta il salto verso LVM e a quel 
punto non avrï¿œ piï¿œ dubbi sul farlo, mettiamola cosï¿œ.
 
Grazie del parere


 per quello e *SE* fï¿œ il suo lavoro degnamente dovrebbe solo aiutarti.
 
Lo fa, ma il punto ï¿œ un altro.
 
Hai 3 casi:
 
1) dischi (LUN o virtual disk, fa lo stesso) ingrandibili a piacere e
una partition table al loro interno:
* HAI: puoi fare il resize di quel che ti pare *ma* hai il limite che
quando lo fai devi "spostare in giro" le partizioni esistenti, poichï¿œ lo
spazio assegnato ad una specifica partizione deve essere contiguo.
* NON HAI la possibilitï¿œ di accorpare piï¿œ partizioni o dischi per
sommarne lo spazio (a meno di non farci RAID SW o simili)
 
2) dischi (LUN o virtual disk, fa lo stesso) ingrandibili a piacere
*senza* partition table:
* HAI: puoi fare il resize di quel che ti pare, dato che ogni volume sta
su un device e lo spazio guadagnato dall'extend ï¿œ necessariamente
contiguo a quello giï¿œ in uso. Il limite ï¿œ che devi avere un disco per
ogni filesystem, e con tanti FS diventa un problema.
* NON HAI la possibilitï¿œ di accorpare piï¿œ partizioni o dischi per
sommarne lo spazio (a meno di non farci RAID SW o simili)
 
3) uso di un sistema di astrazione dei block device tipo LVM:
* HAI: puoi fare il resize di quel che ti pare, dato che la contiguitï¿œ
dello spazio allocato non ï¿œ piï¿œ rilevante in quanto astratta.
Per la stessa ragione, anche l'accorpamento di spazio risiedente su
device diversi non ï¿œ un problema.
A gratis, ti vengono anche funzionalitï¿œ tipo snapshot e simili.
 
 
Fine.
In tutti e 3 i casi l'ingrandimento del filesystem viene eseguito dallo
stesso tool (resize2fs per ext*, appunto); il fatto che lo spazio
sottostante sia grezzo oppure astratto ï¿œ irrilevante; le operazioni
eseguite sono le stesse.
Sicchï¿œ, se non ti fidi di resize2fs nel caso 1 o 2, non ï¿œ che il caso 3
possa darti qualche grado di fiducia in piï¿œ...
 
 

 Intanto grazie
 
Prego


 Lo shrink è sempre una brutta bestia, anche quando funziona.
 
Mi aggancio e confermo, shrink da evitare *sempre* ;-)


Mi aggancio e confermo, shrink da evitare *sempre* ;-)
 
Oddio, sul sempre non sarei così netto.  L'ho usato più di una volta con
soddisfazione.  Certo, incorciando le dita :)

 soddisfazione.  Certo, incorciando le dita :)
 
A me è bastata una volta sola, quando invece del shrink ho ottenuto 
un'insalata di partizioni ;-)
Da quel momento, se posso, creo nuova partizione/copio i files/cancello 
vecchia partizione
Approccio molto preistorico ma altettanto sicuro :)


Approccio molto preistorico ma altettanto sicuro :)
 
Beh, certamente più sicuro e preferibile, avendo lo spazio.

 Uhhh.  Quanto tempo fa?
 
Era una meravigliosa Red Hat 7.2, primi anni 2000 a memoria. Riconosco 
che sia passato molto tempo da allora però sai com'è, scottati una 
volta... ;-)


volta... ;-)
 
Capisco, ma non conta.  Sono passati undici anni :)

 Capisco, ma non conta.  Sono passati undici anni :)
 
Però squadra che vince non si cambia :)
