LVM in combinatie met Xen - Wat is LVM?

[Verwijderd]

Beste Mensen,

Ik ben me de laatste tijd aan het verdiepen in HyperVM (mainstream Xen Control Panel) in combinatie met Xen 3/Centos 5.

Ik had mijn partitie standaard gepartitioneerd en vervolgens blijkt dat ik geen VM's kan aanmaken met HyperVM. Zonder HyperVM is het al gelukt, maar ik wil graag alles via HyperVM doen.

Het blijkt dat HyperVM vereist dat alle VM's op LVM gezet worden. "Logical Volume Manager"
Op http://ds9a.nl/lvm-howto/...o/output/lvm-howto-2.html heb ik de uitleg gelezen. In principe erg sterk en duidelijk, maar ik hou wel een paar vragen over.

Is LVM nu gewoon ongepartitioneerde ruimte die je kunt clusteren?
Is LVM gepartitioneerde ruimte met mogelijkheid van toevoegen van extra schijven die op dezelfde partitie gebruikt kunnen worden?
Wat is nu het wezenlijke verschil verder? Als ik /home als LVM instel, maakt HyperVM dan losse ext3-partities die heel makkelijk zijn te vergroten en verkleinen?

Ik ga binnenkort weer naar het datacentrum, ik gebruik een Q6600 server met 4GB DDR en 2x500GB SATARAID. Het gaat om een test-server, in productie zal hij de komende 3 maand niet gebruikt worden.

Partitietabel (toekomstig)
25GB / ext3
8GB SWAP
1GB /boot ext3
466GB /home LVM

Hierop ga ik HyperVM downloaden en installeren in combinatie met een Centos Virtualizatie install. Kan ik er vanuit gaan dat m'n partitietabel correct is en HyperVM dan goed moet functioneren?
Moet ik nog met dingen rekening houden met het gebruik van LVM?

[Nvidiot]

LVM is een abstractielaag tussen schijven en partities. Met LVM kun je alle schijven aan een verzameling ruimte toevoegen, welke je vervolgens weer kunt opdelen in verschillende partities.

Het mooie van LVM is dat je die ook weer groter en kleiner kunt maken zonder dat je data verliest. Niet genoeg ruimte op /home ? Disk toevoegen, LVM uitbreiden, /home uitbreiden, klaar

[Creepy]

Je LVM partitie wordt niet gezien als een echte bruikbare partitie. Je maakt hierop weer losse "virtuele" partities aan die je kan gebruiken voor bijv Xen. Als je dus een 466GB LVM hebt en je zet hierop een 466GB home dan heb je dus geen ruimte meer voor partities voor je Xen VM's. Qua performance is het gebruik van een partitie op je LVM partitie voor je Xen VM sneller dan het gebruik van een file die een virtuele disk voorstelt.

offtopic:
Dit om het simpel te houden. Eigenlijk heb je 1 of meerdere LVM partities ("physical volumes") die je samenvoegt tot een groep ("virtual group"). Op deze groep maak je dan weer 1 of meerdere partities (logical volumes) aan. Elk van deze logical volumes kan direct door Xen worden gebruikt als een partitie voor je VM's

LVM kan zelfs nog wat geavanceerder zodat je LVM partities over meerdere disken kan gebruiken als virtuele 1 disk ala software raid. Maar een fatsoenlijke LVM howto kan je precies uitleggen wat LVM nu is en hoe het werkt.

[ Voor 42% gewijzigd door Creepy op 17-05-2008 18:27 ]

[Sebazzz]

Is LVM eigenlijk interressant voor een general purpose (beetje office, beetje firefox, beetje evolution, beetje id_tech_4, beetje Wine) desktop systeem?

[Sosabowski]

Sebazzz schreef op zaterdag 17 mei 2008 @ 21:56:
Is LVM eigenlijk interressant voor een general purpose (beetje office, beetje firefox, beetje evolution, beetje id_tech_4, beetje Wine) desktop systeem?

Als graag meerdere partities wil hebben die je later nog van grootte kan veranderen is lvm wel handig ja. Een lvm partitie kan over meerdere schijven lopen, dus als er een vol is kan je een schijf er bij stoppen en die ruimte toevoegen aan een of meerder bestaande partities.

[LauPro]

Ik heb een tijd lang LVM gedraaid maar doe het inmiddels niet meer. Het is een beste overhead (10-20%) en hoe realtime zijn je systemen nou eenmaal? Ook bij resizen moet je je fs unmounten en is er dus downtime. Ik dimensioneer mijn systemen altijd 2-5 jaar vooruit, dus van plotseling schijfruimtetekort is vrijwel nooit sprake, en is die er wel dan ga ik geen risico's nemen met de nog deels experimentele tools om filesystems aan te passen. Het is dan veel beter om een back-up van een volume te maken (moet sowieso) en die terug te zetten in een nieuw volume, heb je meteen de zaak gedefragmenteerd (ja kan ook onder Linux).

[freggy]

Ook bij resizen moet je je fs unmounten en is er dus downtime.

Dat hangt niet van LVM af, maar van je file systeem. En zowat alle gangbare Linux file systemen kunnen zeker online vergroot en verkleind worden (xfs enkel vergroten):
http://tldp.org/HOWTO/LVM-HOWTO/extendlv.html

dan ga ik geen risico's nemen met de nog deels experimentele tools om filesystems aan te passen.

Geen enkele van de tools ivm LVM en het online vergroten van file systemen zijn vandaag de dag nog experimenteel, ze worden al geruime tijd in productie gebruikt (bvb. in RHEL 5 en SLES 10)

[ Voor 34% gewijzigd door freggy op 18-05-2008 00:08 ]

[LauPro]

freggy schreef op zondag 18 mei 2008 @ 00:05:
Dat hangt niet van LVM af, maar van je file systeem. En zowat alle gangbare Linux file systemen kunnen zeker online vergroot en verkleind worden (xfs enkel vergroten):
http://tldp.org/HOWTO/LVM-HOWTO/extendlv.html

Voor serveromgevingen zou ik toch zeker ext3 of xfs pakken, de laatste kan inderdaad online vergroten maar niet verkleinen (komt door de opzet). Bij ext2/ext3 is het onmogelijk om online te resizen en reiserfs/jfs zijn de laatste tijd een beetje in opspraak geraakt.

Geen enkele van de tools ivm LVM en het online vergroten van file systemen zijn vandaag de dag nog experimenteel, ze worden al geruime tijd in productie gebruikt (bvb. in RHEL 5 en SLES 10)

Stroomuitval tijdens een resize van xfs/reiserfs/jfs kan voor grote problemen zorgen, het blijft link om op paritieniveau aan filesystems te rommelen. Het wordt dan ook altijd geadviseerd om extra back-ups te maken voor een migratie.

[froggie]

Ik maak eigenlijk alleen in een server omgeving gebruik van LVM. Tegenwoordig maak ik nog maar twee partities op disk aan; een kleine bootpartitie van 64 - 128MB en een LVM physical device. Daarin maak ik vervolgens een root, usr, var, swap etc LV. Ik begin altijd klein, 512MB voor m'n root, 1G voor var en usr etc. Door gebruik te maken van reiserfs kan ik vervolgens, wanneer dit nodig is, simpelweg online een partitie vergroten met een lvresize en resize_reiserfs. Ik heb dan ook bijna nooit last van partities die ik aanvankelijk veel te groot heb gemaakt en weer moet verkleinen (wat wel offline moet).

Ik gebruik LVM ook in ons Xen cluster. Iedere nacht maak ik automatisch een snapshot van LVM, mount het filesystem op die snapshot readonly en kan vervolgens eenvoudig een backup maken.

Duss... verdiep je in LVM, want het is best een leuke tool.

[ Voor 1% gewijzigd door froggie op 18-05-2008 09:30 . Reden: typo's ]

[LauPro]

Het is wel grappig dat je snapshot-support noemt, want deze is nog steeds als experimental gemarkeerd in de kernel.

LVM is inderdaad een leuke tool maar helaas zijn een aantal kritische functies nog steeds experimental.

[freggy]

Bij ext2/ext3 is het onmogelijk om online te resizen

Zoals ik reeds zei, het kan wél, en al veel langer dan vandaag: http://michael-prokop.at/.../01/ext3-online-resizing/ (ik geloof dat ik het voor het eerst gedaan heb in Fedora 5).

Het is wel grappig dat je snapshot-support noemt, want deze is nog steeds als experimental gemarkeerd in de kernel.

In 2.25.4 staat deze zeker niet meer als experimental gemarkeerd. Het enige wat nog onder "Device Mapper Support "als experimental staat is: I/O delaying target (EXPERIMENTAL) en DM uevents (EXPERIMENTAL)

[ Voor 39% gewijzigd door freggy op 18-05-2008 23:07 ]

[tomato]

LauPro schreef op zaterdag 17 mei 2008 @ 22:56:
Ik heb een tijd lang LVM gedraaid maar doe het inmiddels niet meer. Het is een beste overhead (10-20%)

Hoe kom je hierbij? Van horen zeggen (ben benieuwd naar je bronnen) of heb je resultaten van eigen tests?

Ik herken er namelijk niets in en het is nogal een stevige opmerking.

[LauPro]

freggy schreef op zondag 18 mei 2008 @ 23:02:
Zoals ik reeds zei, het kan wél, en al veel langer dan vandaag: http://michael-prokop.at/.../01/ext3-online-resizing/ (ik geloof dat ik het voor het eerst gedaan heb in Fedora 5).

Dat is inderdaad sinds E2fsprogs 1.39 van 29 mei 2006, toch zullen er nog distributies zijn die deze nog niet meeleveren. Verder zie ik het ook nog niet terugkomen in de officiële LVM-howto wat ook lichtelijk dubieus is. Maargoed, al met al heb je een punt.

In 2.25.4 staat deze zeker niet meer als experimental gemarkeerd. Het enige wat nog onder "Device Mapper Support "als experimental staat is: I/O delaying target (EXPERIMENTAL) en DM uevents (EXPERIMENTAL)

2.6.25.4 (die je neem ik aan bedoelt) is vrij nieuw, nog geen 2 maanden oud. Zo'n kernel zou ik niet in productie gaan draaien.

tomato schreef op maandag 19 mei 2008 @ 01:03:
Hoe kom je hierbij? Van horen zeggen (ben benieuwd naar je bronnen) of heb je resultaten van eigen tests?

Ik had een MD-RAID1 over 2 schijven met daar bovenop een LVM volume en daar was de performance zeer slecht van, zeker 10-20% minder dan zonder LVM. De opstelling heb ik niet meer, misschien dat ik het binnenkort kan testen op een andere server. Tevens heb ik ook op veel fora getallen (en benchmarks) voorbij zien komen van dergelijke overhead. Misschien dat het bij een enkele disk, met een enkele volume group, enkele logical volume niet opgaat (wat is dan nog het nut van LVM?).

[ Voor 26% gewijzigd door LauPro op 19-05-2008 01:44 ]

[Verwijderd]

LauPro schreef op maandag 19 mei 2008 @ 01:41:

Misschien dat het bij een enkele disk, met een enkele volume group, enkele logical volume niet opgaat (wat is dan nog het nut van LVM?).

Dan is nog steeds het nut dat je een "partitie" kunt maken die groter is dan een physical volume, en je kunt het mirroren.

Maarrrr... Ik werk niet echt met Linux maar met AIX. In AIX ben ik nog nooit een systeem tegen gekomen die geen gebruik maakt van LVM. De LVM van AIX is wel iets anders, maar het principe is hetzelfde. Maar kent Linux geen JFS2?

[tomato]

LauPro schreef op maandag 19 mei 2008 @ 01:41:
Ik had een MD-RAID1 over 2 schijven met daar bovenop een LVM volume en daar was de performance zeer slecht van, zeker 10-20% minder dan zonder LVM. De opstelling heb ik niet meer, misschien dat ik het binnenkort kan testen op een andere server. Tevens heb ik ook op veel fora getallen (en benchmarks) voorbij zien komen van dergelijke overhead. Misschien dat het bij een enkele disk, met een enkele volume group, enkele logical volume niet opgaat (wat is dan nog het nut van LVM?).

Het lijkt inderdaad een bekend probleem te zijn dat LVM op software RAID zeer slecht performed (lezen, schrijven zou geloof ik ok moeten zijn). Er zijn patches, maar die zitten voor zover ik zie nog niet in een kernel die je kunt draaien.

Probleem is de dm code. Je kunt het (enigzins?) verhelpen door de read-ahead van je raid en lvm volumes aan te passen.