Dies sind einige Überlegungen warum man mehr als einer Volumegroup verwenden will und wie man sich seine Volume Groups organisiert. Auf vielen "einfachen" Servern wird es sinnvoll sein alle physikalischen Platten in eine Volume Group zu nehmen, vorallem, wenn Sie keine Verfügbarkeitsunterscheidung zwischen den Verzeichnissen treffen. Sinnvoll ist es sicher gesonderte Volume Groups anzulegen für "billigen" IDE Speicherplatz und "performanteren" SCSI Speicherplatz oder Speicherplatz auf einem (redundanten) Hardware RAID.
Mehrere PVs in einer Volume Group erhöhen das statistische Ausfallrisiko.
Nur wenige oder sogar nur ein PV in einer VG schränken die Flexibilität in der Speicherzuordnung ein.
"Removable Disks" sind am besten in einer eigen Volume Group aufgehoben um den Im- und Export zu erleichtern. Hier sollten auch auf jedenfall sprechende VG Namen vergeben werden. Recht praktisch ist es auch, die Volume Group am Systemnamen anzulehnen, denn so kann man Namenskonflikte vermeiden, wenn z.B. die Platte von "kira" mal temporär an "dax" gehängt wird. Würden beide Systeme ihre erste Volume-Group vg00 nennen, wäre das nicht so einfach.
Die maximale Speichergrösse einer Volume Group ist abhängig von der Grösse der Physical Extents, die beim anlegen der Volume Group gesetzt wird. Diese Belegungseinheit gilt für alle Physikalischen Volumes der Volume Group.
Linux benötigt zum booten mindestens ein boot volume, das nicht auf LVM basiert. (Für Details siehe Kapitel "Booten von einem logical Volume".) Es empfiehlt sich aber auch das root volume auf einer gewöhnlichen Partition zu haben.
Can i have my root filesystem in a logical volume?
Yes you can. There's basic support since LVM 0.7 to create an initial ram disk containing the necessary executables, device specials etc. to switch to a logical volume containing a root filesystem. See script lvmcreate_initrd(8).
lvmcreate_initrd creates a new compressed initial ramdisk
in /boot/initrd.gz. The initial ramdisk contains all nec
essary binaries, shared libraries and a linuxrc file to
switch to a logical volume based root filesystem. To
build an initial ramdisk for a not running but generated
kernel add the KernelVersion parameter (for eg. 2.3.25) on
the command line.
The necessary actions to change your system into a "root
on logical volume" one are:
Create a small (~20MB) partition which is bios reachable
to hold the /boot filesystem (if you already have a small
partition based root filesystem this can as well be used).
If you like to standalone boot from this partition in case of an emergency, copy all necessary binaries and libraries
to that filesystem as well and create a corresponding
/etc/lilo.conf entry. In order to be able to edit
lilo.conf in case you booted standalone, you should move
/etc/lilo.conf to /boot/lilo.conf and create a symbolic
link to it in /etc instead. This is not needed if you
have a boot/root floppy which contains the LVM binaries
and the library in addition.
Create all logical volumes you need (for root, usr, opt
etc.), create filesystems in them, mount them and transfer
all files from the partition based filesystems into the
logical volumes based ones.
You have to setup your /etc/lilo.conf with a boot configuration like:
image = /boot/vmlinuz initrd = /boot/initrd.gz root = /dev/YourVG/YourRootLV label = rootonlv append = "ramdisk_size=8192"
Replace YourVG and YourRootLV by your actual volume group
and root logical volume names. In addition to that your
/etc/fstab in your root logical volume has to contain:
/dev/YourVG/YourRootLV / ext2 defaults 0 1 /dev/YourBootPartition /boot ext2 defaults 0 2 /dev/YourVG/YourUsrLV /usr ext2 defaults 0 3 /dev/YourVG/YourOptLV /opt ext2 defaults 0 4
etc.
You can use other supported filesystem types as well
(reiserfs for eg.) in case you generated support for those
into your kernel. Run lilo, reboot and try...
The partitions containing the former /usr, /opt etc.
filesystems can now be used as physical volumes. pvcre
ate(8) them and add them for eg. to YourVG.
lvcmcreate_initrd return 0 for success. 1 is returned in
all other cases.
Mit etwas Mut und Pioniergeist, läßt sich sogar ein System zusammenstellen, dass /boot und die Root ebenfalls in logischen Volumes hält. Siehe dazu
Beispiel: Die VG 'tmpvg' wird auf ein anderes System übertragen. Dies bedeutet, dass z.B. eine externe Platte oder ein RAID an einem anderen Computer betrieben werden soll.
vgexport tmpvg
Ab jetzt ist die VG tmpvg im System nicht mehr sichtbar. Man sollte sich vorher gemerkt haben, auf welchem Device sie vorhanden war! Auf dem neuen System, kann die VG (unter Angabe eines neuen Namens) aus dem Device importiert werden, im Beispiel als newvg von /dev/hdc1:
vgimport newvg /dev/hdc1
vgextend vg00 /dev/loop7 lvcreate -i 2 -L20M -n striped vg00
Sie können lediglich ein Stripe Set anlegen und dann Ihre Daten von einem bestehenden LV dorthin verschieben. (Ist das richtig??? -richard)
Wenn Sie zwei oder mehr Physikalische Volumes (PVs) verwenden, die alle auf Partitionen auf der gleichen Festplatte basieren, dann werden Sie keine Performance Vorteile erzielen. Es ist zwar völlig zulässig mehere Partitionen der gleichen Platte als PVs zu verwenden, (this only makes sense for next free allocated logical volumes on those physical volumes). Bei IDE Platten bringen Stripe Sets nur bedingte Geschwindigkeitsvorteile, da auf Master und Slave Platte eines Adapters nicht parallel zugegriffen werden kann.
I'm using quite a few ide-drives in a raid0 volume (hda -> hdh) and I came to think of that it would be good to know in which order I added the drives to the volume in case I need to remove one from the volume, is there any way I can get the order in which the drives are placed in the raid0 volume?
(In a list like hda, hdc, hdb, hdg, ... etc) please try "lvdisplay -v /dev/YourVG/YourLV | less" and have a look at the information about distribution of the volume over the physical volumes. Tell me if that answers your question. BTW: if your RAID0 volume is spread over all the disks, you can't remove a disk because you can't remove a stripe without destroying the total volume.
LVM selbst unterstützt keine Spiegelung sondern kümmert sich nur um die dynamische Belegung des Speicherplatzes. Die Spiegelung von Logischen Volumes kann durch den Einsatz von RAID Hardware oder der Verwendung von MD, einem Software RAID, erreicht werden. Diese Trennung sorgt für eine einfachere und damit stabilere Systemarchitektur. Aus diesem Grund ist auch keine Integration der beiden Funktionen vorgesehen. MD erweitert den Kernel um die Möglichkeit der RAID 1, 4 und 5 Softwarespiegelung. LVM kann problemlos über MD eingesetzt werden. Alternativ kann sich der Einsatz von leichter zu Administrierender RAID Hardware anbieten. LVM erweitert die RAID Hardware so um die Flexibilität der dynamischen Speicherplatz Managments. (Siehe Kapitel "Referenzen" für Verweise auf RAID Literatur).
Einige Benutzer setzen ReiserFS zusammen mit LVM produktiv ein. Generelle Unverträglichkeiten gibt es nicht.
http://sdb.suse.de/sdb/de/html/lvm.html
Bezieht sich auf SuSE Linux: Version 6.3
Symptom: Sie haben in YaST den Punkt "Logical Volume Manager konfigurieren" ausgewählt. Die darauf folgende Frage haben Sie mit "Nein" beantwortet. Jedoch sucht der LVM beim Booten immer nach Logical Volumes.
Ursache: Ein Fehler sorgt dafür, daß auch beim Beantworten der obigen Frage mit "Nein" der LVM beim Booten gestartet wird.
Lösung: Löschen Sie einfach die Datei /etc/lvmtab und das Verzeichnis /etc/lvmtab.d. Auf der Kommandozeile können Sie das als root folgendermaßen machen:
rm -r /etc/lvmtab*
Jetzt wird beim Booten nicht mehr nach Logical Volumes gesucht.
Für Test- und Übungskonfigurationen können Sie mehr als eine LVM Partition auf einer Festplatte haben. Dies ist im Fall eines Stripe Sets aber nicht zu empfehlen, da Sie eine Performance Einbusse haben werden.
Es gibt einen Kernel Patch der die Erweiterung eines gemounteten und aktiven ext Volumes ermöglicht.
Snapshots are virtual copies of logical volumes. Such a copy is read only
and doesn't change when you write to the cloned volume. This is often used for backups: If you backup a filesystem while it's in use, you may end up with an inconsistant or incomplete backup. (after you wrote the first half of your filesystem to tape, someone moves a file from the second half to the first one, so you miss it when you write the second half to tape, for example.) If you have snapshots, you create the snapshot at one moment and then write the (read only) snapshot to tape.
Support for multiple snapshot logical volumes per original logical volume to for eg. enable consistent online backups or recovery in filesystems and database systems.
(lvremove, lvcreate, lvchange,lvextend,lvreduce)
"lvcreate --size 100m --snapshot --name snap /dev/vg00/lvol1"
creates a snapshot logical volume named /dev/vg00/snap wich gains access to the contents of /dev/vg00/lvol1 at snapshot logical volume creation time.
lvcreate
{-l/--extents LogicalExtentsNumber |
-L/--size LogicalVolumeSize[kKmMgGtT]}
[-c/--chunksize ChunkSize]
-s/--snapshot -n/--name SnapshotLogicalVolumeName
LogicalVolumePath [PhysicalVolumePath...]
Die 'size' gibt dabei an, wieviel sich am Originalfilesystem ändern darf bevor der Snapshot unbrauchbar wird. Im Idealfall also die Size genausogroß wählen wie das Originalfilesystem.
Im Augenblick sind die Snapshots unter LVM noch nicht beständig, d.h. sie überleben keinen Reboot oder eine Volumegroup Deaktivierung. Die Beständigkeit wird in einer der nächsten Versionen hinzugefügt.