[gelöst] LVM Partition auf neue Platte übertragen
[gelöst] LVM Partition auf neue Platte übertragen
Hallo,
zunächst ein paar Fakten zur Situation:
SSD-Platte alt: 1GB (GPT) - 2 Partitionen (sda1=/boot + sda2=LVM-Member)
innerhalb von sda2 waren LVs angelegt ( z.B. KVM-Host, swap und einige LVs, die KVM-VMs enthielten.
Die Plattenkapazität war nur zu etwa zu 70% belegt.
Von sda2 existiert ein mit dd erzeugtes Image, die Platte selbst ist nicht mehr vorhanden.
SSD-Platte neu: 1GB (GPT) - 3 Partitionen (sdb1=/EFI + sdb2=/boot + sdb3=LVM-Member)
Nun soll der Inhalt von dem ehemaligen sda2 (backup.img) teilweise auf die neue sdb3 Partition kopiert werden.
Der Rechner wurde mit einer Live-CD gestartet.
Mein Problem ist, dass ich das Image zwar temporär mit "dd" auf eine Dreh-Platte kopieren konnte aber dann keine Möglichkeit finde den Inhalt zu mounten. (unknown filesystem type 'LVM2_member')
Ist es überhaupt möglich auf die Daten (speziell auf die im Image enthaltenen LVs) zuzugreifen?
zunächst ein paar Fakten zur Situation:
SSD-Platte alt: 1GB (GPT) - 2 Partitionen (sda1=/boot + sda2=LVM-Member)
innerhalb von sda2 waren LVs angelegt ( z.B. KVM-Host, swap und einige LVs, die KVM-VMs enthielten.
Die Plattenkapazität war nur zu etwa zu 70% belegt.
Von sda2 existiert ein mit dd erzeugtes Image, die Platte selbst ist nicht mehr vorhanden.
SSD-Platte neu: 1GB (GPT) - 3 Partitionen (sdb1=/EFI + sdb2=/boot + sdb3=LVM-Member)
Nun soll der Inhalt von dem ehemaligen sda2 (backup.img) teilweise auf die neue sdb3 Partition kopiert werden.
Der Rechner wurde mit einer Live-CD gestartet.
Mein Problem ist, dass ich das Image zwar temporär mit "dd" auf eine Dreh-Platte kopieren konnte aber dann keine Möglichkeit finde den Inhalt zu mounten. (unknown filesystem type 'LVM2_member')
Ist es überhaupt möglich auf die Daten (speziell auf die im Image enthaltenen LVs) zuzugreifen?
Zuletzt geändert von max123kl am 03.05.2019 18:13:38, insgesamt 1-mal geändert.
Re: LVM Partition auf neue Platte übertragen
Du musst dein Image als Loopdevice einhängen, dann kannst du LVM so konfigurieren (/etc/lvm/lvm.conf) das auf Loop-Devices sucht und danach mit vgscan und vgimport deine VG importieren.
Re: LVM Partition auf neue Platte übertragen
Ich hatte das Image auch schon mit dem Befehl:bluestar hat geschrieben:29.04.2019 22:22:30Du musst dein Image als Loopdevice einhängen, dann kannst du LVM so konfigurieren (/etc/lvm/lvm.conf) das auf Loop-Devices sucht und danach mit vgscan und vgimport deine VG importieren.
Code: Alles auswählen
losetup /Pfad/zum/Image/backup.img /dev/loop1
Das ging vor ein paar Tagen problemlos aber pvscan, vgscan und lvscan lieferten kein entsprechendes Ergebnis.
Heute früh habe ich den Befehl noch einmal abgesetzt und eine Error-Meldung erhalten:
Code: Alles auswählen
/dev/loop1: failed to set up loop device: Inappropriate ioctl for device
Einen Tipp dazu?
Re: LVM Partition auf neue Platte übertragen
Hast du vor pvscan, die Datei /etc/lvm/lvm.conf angepasst, dass auf Loop-Devices überhaupt nach VGs gesucht wird?max123kl hat geschrieben:30.04.2019 08:00:26Das ging vor ein paar Tagen problemlos aber pvscan, vgscan und lvscan lieferten kein entsprechendes Ergebnis.
Re: LVM Partition auf neue Platte übertragen
Nein, hatte ich nicht.bluestar hat geschrieben:30.04.2019 11:24:09Hast du vor pvscan, die Datei /etc/lvm/lvm.conf angepasst, dass auf Loop-Devices überhaupt nach VGs gesucht wird?max123kl hat geschrieben:30.04.2019 08:00:26Das ging vor ein paar Tagen problemlos aber pvscan, vgscan und lvscan lieferten kein entsprechendes Ergebnis.
Aber ist das überhaupt notwendig wenn Folgendes eh schon aktiv ist:
Code: Alles auswählen
devices {
dir = "/dev"
scan = [ "/dev" ]
...
}
Abgesehen davon habe ich momentan das Problem dass ich das Loop-Device gar nicht einhängen kann (s. meinen letzten Post).
Re: LVM Partition auf neue Platte übertragen
In dem Abschnitt devices sollte es auch noch eine Zeile filter=.... geben, darüber wird gesteuert, welche Devices nicht gescannt werden dürfen.
Ich frage mal so am Rande, warum du deine LVM-Partition als Datei und nicht einfach über vgextend, pvmove und vgreduce auf die externe Platte geschrieben hast, dann hättest du auf selbigem Weg die Daten auch wieder auf die neue xDD schieben können.
Habe gerade noch eine einfache Zusammenfassung für dich gefunden http://www.utilities-online.info/articl ... d-with-dd/
Code: Alles auswählen
man lvm.conf
Habe gerade noch eine einfache Zusammenfassung für dich gefunden http://www.utilities-online.info/articl ... d-with-dd/
Re: LVM Partition auf neue Platte übertragen
Die filter = -Zeilen sind im Original alle auskommentiert.bluestar hat geschrieben:30.04.2019 16:51:22In dem Abschnitt devices sollte es auch noch eine Zeile filter=.... geben, darüber wird gesteuert, welche Devices nicht gescannt werden dürfen.Code: Alles auswählen
man lvm.conf
Leider enthält die Manpage keine Informationen wie die Syntax der filter = -Option exakt lautet. Immerhin ist die Datei gut kommentiert und ettliche Beispiele aufgelistet. Ich hoffe, dass ich damit zum Ziel komme.
Weil die ursprünglich verbaute Platte inzwischen anderweitig genutzt wird.Ich frage mal so am Rande, warum du deine LVM-Partition als Datei und nicht einfach über vgextend, pvmove und vgreduce auf die externe Platte geschrieben hast, dann hättest du auf selbigem Weg die Daten auch wieder auf die neue xDD schieben können.
Als ich mal von einer 256GB-SSD auf eine 1TB-SSD umgezogen bin, hatte ich den beschriebenen Weg auch genutzt.
Vielen Dank!Habe gerade noch eine einfache Zusammenfassung für dich gefunden http://www.utilities-online.info/articl ... d-with-dd/
Ich hatte doch geschrieben, dass sich das Loop-Device nicht mehr einhängen lässt.
Beim Durchsehen des Links ist mir aufgefallen, dass ich bei meinem losetup-Befehl von heute früh die Argumente vertauscht hatte. Statt:
Code: Alles auswählen
losetup <Loop-Device> <Image.Datei>
PS: Nachdem ich verschiedene filter-Optionen in der lvm.conf erfolglos getestet habe, bin ich nun auf der Suche nach einer guten Beschreibung der Syntax.
Re: LVM Partition auf neue Platte übertragen
Versuch mal die Zeile
=> Die stammt aus der Original lvm.conf aus Debian Stretch, dort stehen diverse Beispiele drin:
Code: Alles auswählen
filter = [ "a|loop|", "r|.*|" ]
Code: Alles auswählen
# Configuration option devices/filter.
# Limit the block devices that are used by LVM commands.
# This is a list of regular expressions used to accept or reject block
# device path names. Each regex is delimited by a vertical bar '|'
# (or any character) and is preceded by 'a' to accept the path, or
# by 'r' to reject the path. The first regex in the list to match the
# path is used, producing the 'a' or 'r' result for the device.
# When multiple path names exist for a block device, if any path name
# matches an 'a' pattern before an 'r' pattern, then the device is
# accepted. If all the path names match an 'r' pattern first, then the
# device is rejected. Unmatching path names do not affect the accept
# or reject decision. If no path names for a device match a pattern,
# then the device is accepted. Be careful mixing 'a' and 'r' patterns,
# as the combination might produce unexpected results (test changes.)
# Run vgscan after changing the filter to regenerate the cache.
# See the use_lvmetad comment for a special case regarding filters.
#
# Example
# Accept every block device:
# filter = [ "a|.*/|" ]
# Reject the cdrom drive:
# filter = [ "r|/dev/cdrom|" ]
# Work with just loopback devices, e.g. for testing:
# filter = [ "a|loop|", "r|.*|" ]
# Accept all loop devices and ide drives except hdc:
# filter = [ "a|loop|", "r|/dev/hdc|", "a|/dev/ide|", "r|.*|" ]
# Use anchors to be very specific:
# filter = [ "a|^/dev/hda8$|", "r|.*/|" ]
Re: LVM Partition auf neue Platte übertragen
Genau diese Einstellung habe ich schon versucht. Laut Kommentar in der lvm.conf sollten nur die Loop-Devices genutzt werden. Da bei mir wegen der Live-CD neben loop1 zusätzlich noch loop0 existiert erhalte ich ein verwirrendes Ergebnis.bluestar hat geschrieben:30.04.2019 23:49:04Versuch mal die ZeileCode: Alles auswählen
filter = [ "a|loop|", "r|.*|" ]
Wie kann man die Filter-Zeile so modifizieren damit nur loop1 genutzt wird?
Code: Alles auswählen
# pvs #(original lvm.conf)
PV VG Fmt Attr PSize PFree
/dev/sda3 host1_vg lvm2 a-- 930.82g <851.67g
/dev/sdb1 host1_vg lvm2 a-- 232.88g 232.88g
/dev/sdc1 host1_hdd_vg lvm2 a-- <5.46t <4.03g
# pvs #(modifizierte lvm.conf)
WARNING: Device for PV Xnq0lv-tUS7-wAGP-vYYP-Hb8Q-u6Ef-7cA2Pu not found or rejected by a filter.
WARNING: Device for PV XNH3vm-lXX0-Onhy-5SeG-S7CM-T3nK-FpUUOV not found or rejected by a filter.
WARNING: Device for PV dcm4IM-eVqj-Q6FX-ULu1-Nuwe-mL7d-IjG2Qh not found or rejected by a filter.
WARNING: Device for PV XNH3vm-lXX0-Onhy-5SeG-S7CM-T3nK-FpUUOV not found or rejected by a filter.
WARNING: Couldn't find all devices for LV host1_hdd_vg/nas-hdd1 while checking used and assumed devices.
WARNING: Device for PV Xnq0lv-tUS7-wAGP-vYYP-Hb8Q-u6Ef-7cA2Pu not found or rejected by a filter.
WARNING: Device for PV dcm4IM-eVqj-Q6FX-ULu1-Nuwe-mL7d-IjG2Qh not found or rejected by a filter.
WARNING: Couldn't find all devices for LV host1_vg/system while checking used and assumed devices.
WARNING: Couldn't find all devices for LV host1_vg/swap while checking used and assumed devices.
PV VG Fmt Attr PSize PFree
[unknown] host1_hdd_vg lvm2 a-m <5.46t <4.03g
[unknown] host1_vg lvm2 a-m 930.82g <851.67g
[unknown] host1_vg lvm2 a-m 232.88g 232.88g
Mit pvck erhalte ich Folgendes:
Code: Alles auswählen
# pvck /dev/loop1
Found label on /dev/loop1, sector 1, type=LVM2 001
Found text metadata area: offset=4096, size=1044480
Wenn ich "pvck -vvv" verwende erhalte ich eine umfangreiche Ausgabe in der diverse Offset-Werte erscheinen (Werte sind identisch für sdd2 und loop1).
(Download bei: http://zlocal.bplaced.net/uploads/pvck_vvv.txt)
Es sollte doch möglich sein mit diesen Informationen die Partition zu mounten auch ohne dass ich die Verenkungen über das Loop-Device mache.
Re: LVM Partition auf neue Platte übertragen
Hast du die Imagedatei schon wieder auf die HDD geschrieben?
Re: LVM Partition auf neue Platte übertragen
Ja, aber sie lässt sich nicht mounten:bluestar hat geschrieben:01.05.2019 20:24:21Hast du die Imagedatei schon wieder auf die HDD geschrieben?
Code: Alles auswählen
# mount /dev/sdd2 /media/sdd2
mount: /media/sdd2: unknown filesystem type 'LVM2_member'
Re: LVM Partition auf neue Platte übertragen
Du kannst LVM Partitionen nie mounten, beschreib doch mal den exakten Aufbau deiner VG auf der alten Platte.
Re: LVM Partition auf neue Platte übertragen
Die Platte selbst war eine Crucial 1GB SSD mit GPT-Partitionstabelle.bluestar hat geschrieben:01.05.2019 21:02:32Du kannst LVM Partitionen nie mounten, beschreib doch mal den exakten Aufbau deiner VG auf der alten Platte.
Darauf zwei primäre Partitionen (sda1 /boot ext2 200MB) (sda2 LVM Restkapazität)
VG_alt enthält sda2 als PV
LV_system (50 GB) war als root (/*) eingehängt. Das System (Debian-Jessie) war als Host für KVM/Qemu konfiguriert. Daneben gab es ein LV_swap, das als Swap-Partition (32 GB) fungierte.
Unter libvirt waren dann diverse VMs mittels LVM-Storage-Pool angelegt. Den letzten Stand der genauen Größen und Anzahl kann ich jetzt nicht mehr nennen, da zu Testzwecken öfters Änderungen gemacht wurden. Das könnte auch die hohe Anzahl der Metadatenblöcke im Backup-Image erklären.
Ursprünglich hatte die Platte eine GPT Partitionstabelle aber keine EFI-Partition.
Weil an einem anderen Rechner die Systemplatte auszufallen drohte musste die SSD als Notfall-Ersatz herhalten. Zuvor wurden die Partitionen mit dd als Image auf eine Backup-Platte gesichert.
Heute möchte ich den Server (wieder mit einer 1GB SSD) neu aufbauen, jetzt mit EFI-Partition und aktuellem Debian-Buster im Host-System. Deshalb ist der zur Verfügung stehende Platz auf der neuen sda3 etwas kleiner als auf der alten sda2. Aus den alten VMs sind eigentlich nur drei für mich intessant aber nicht wirklich wichtig. Von daher wäre es sinnvoll eine komplette Neuinstallation zu machen. Ich sehe das auch als Lernprojekt. Da ich, glücklicherweise, bisher noch nicht zwingend auf ein Backup angewiesen war, möchte ich diesen Fall nun einmal durchspielen.
Ergänzung:
Wie gesagt habe ich das Image auf sdd2 kopiert.
Unter "fdisk -l /dev/sdd" wird sdd2 als Linux-Filesystem erkannt, unter gparted dagegen als LVM-Member (nicht aktiv, kein Mitglied einer VG). Mit parted (select sdd - print) wird überhaupt kein Flag für sdd2 angezeigt. gdisk meldet für sdd2 Code 8300.
Könnte da die Ursache liegen?
Zuletzt geändert von max123kl am 02.05.2019 09:43:37, insgesamt 1-mal geändert.
Re: LVM Partition auf neue Platte übertragen
Da ich so nie LVM-Partitionen kopiert habe, kann ich dir nur bedingt weiterhelfen.... Was jedoch mit ziemlicher Sicherheit nicht funktionieren wird, das Image von EX-sda2 auf sda3 zu übernehmen, wenn sda3 kleiner ist als EX-sda2.max123kl hat geschrieben:02.05.2019 09:10:23Heute möchte ich den Server (wieder mit einer 1GB SSD) neu aufbauen, jetzt mit EFI-Partition und aktuellem Debian-Buster im Host-System. Deshalb ist der zur Verfügung stehende Platz auf der neuen sda3 etwas kleiner als auf der alten sda2. Aus den alten VMs sind eigentlich nur drei für mich intessant aber nicht wirklich wichtig. Von daher wäre es sinnvoll eine komplette Neuinstallation zu machen. Ich sehe das auch als Lernprojekt. Da ich, glücklicherweise, bisher noch nicht zwingend auf ein Backup angewiesen war, möchte ich diesen Fall nun einmal durchspielen.
Mein Ansatz wäre folgender:
0) Sauber Live System neu booten
1) sda3 mit nullen überschreiben
2) Das Image der alten Partition als Loopback-Device (loopX) einhängen
3) /etc/lvm/lvm.conf => filter anpassen:
Code: Alles auswählen
filter = [ "a|loop|","a|sd|" "r|.*|" ]
4) Mit vgscan und vgimport deine alte VG (Name unbekannt) von /dev/loopX an den Start bekommen.
5) Danach deine VG vergrößern: vgextend vg-unbekannt /dev/sda3
6) Mit pvmove alle Datenblöcke in der VG unbekannt von /dev/loopX nach /dev/sda3 verschieben: pvmove /dev/loopX
7) Deine Volume Gruppe um /dev/loopX verkleinern: vgreduce VG-unbekannt /dev/loopX
Re: LVM Partition auf neue Platte übertragen
Danke für deine schnelle Antwort.
Sie hat sich mit meiner Ergänzung zum vorigen Post überschnitten.
Speziell weiß ich nicht ob das Anlegen einer VG für sdd2 zu Datenverlusten führen kann.
Deine Antwort muss ich noch genauer lesen und testen um darauf zu reagieren.
Sie hat sich mit meiner Ergänzung zum vorigen Post überschnitten.
Speziell weiß ich nicht ob das Anlegen einer VG für sdd2 zu Datenverlusten führen kann.
Deine Antwort muss ich noch genauer lesen und testen um darauf zu reagieren.
Re: LVM Partition auf neue Platte übertragen
Das ist mir klar. Ich will ja auch gar nicht die komplette Ex-sda2 in die neue sda3 transferieren. S. untenbluestar hat geschrieben:02.05.2019 09:29:29.... Was jedoch mit ziemlicher Sicherheit nicht funktionieren wird, das Image von EX-sda2 auf sda3 zu übernehmen, wenn sda3 kleiner ist als EX-sda2.
zu 1) Warum? Doch nur falls ich die ehemals vorhandene Installation komplett übernehmen wollte.Mein Ansatz wäre folgender:
0) Sauber Live System neu booten
1) sda3 mit nullen überschreiben
2) Das Image der alten Partition als Loopback-Device (loopX) einhängen
3) /etc/lvm/lvm.conf => filter anpassen:verwendenCode: Alles auswählen
filter = [ "a|loop|","a|sd|" "r|.*|" ]
4) Mit vgscan und vgimport deine alte VG (Name unbekannt) von /dev/loopX an den Start bekommen.
5) Danach deine VG vergrößern: vgextend vg-unbekannt /dev/sda3
6) Mit pvmove alle Datenblöcke in der VG unbekannt von /dev/loopX nach /dev/sda3 verschieben: pvmove /dev/loopX
7) Deine Volume Gruppe um /dev/loopX verkleinern: vgreduce VG-unbekannt /dev/loopX
zu 3) Die neue Filteregel reichte nicht aus: vgscan -vvv (Zeile 4)
Code: Alles auswählen
devices/global_filter not found in config: defaulting to global_filter = [ "a|.*/|" ]
Erst als ich global_filter in: global_filter = [ "a|loop|","a|sd|" "r|.*|" ] geändert habe sind sowohl für loop1 als auch für sdd2 Einträge gelistet. (http://zlocal.bplaced.net/uploads/vgscan_vvv2.txt)
pvs erkennt jetzt auch die LVM-Partition auf sdd2 (auch mit der default lvm.conf). Ich habe deshalb das loop1-Device deaktiviert
Code: Alles auswählen
# pvs
WARNING: Device for PV CB7VSM-ogyq-lnCz-WqN4-usay-wPDR-eFlcJi not found or rejected by a filter.
PV VG Fmt Attr PSize PFree
/dev/sda3 host1_vg lvm2 a-- 930.82g <851.67g
/dev/sdb1 host1_vg lvm2 a-- 232.88g 232.88g
/dev/sdc1 host1_hdd_vg lvm2 a-- <5.46t <4.03g
/dev/sdd2 host1_vg lvm2 a-- 931.31g <280.09g
[unknown] host1_vg lvm2 a-m 232.88g 232.88g
Es existieren doppelte Namen von PVs, VGs und LVs. Ich werde nun erst mal die derzeit existierenden so umbenennen, dass es mit den alten keine Namen-Kollisionen gibt.
Ich werde vorläufig mit sdd2 weiterarbeiten weil a) die Daten schon auf der Platte sind, sie b) inzwischen erkannt wird und c) um zu verhindern, dass Manipulationen im Loop-Device sich negativ auf das DD-Image auswirken.
zu 4-7) Da ich auf keinen Fall die alte Jessie-Installation einspielen und anschließend auf Buster upgraden will, werde ich mir einen angepassten Weg überlegen müssen. Ich möchte lediglich einige der KVM-VMs, die als LVM-LVs in der EX-sda2 liegen importieren.
Falls es Probleme gibt oder wenn ich Erfolg habe, werde ich mich wieder melden.
[gelöst] LVM Partition auf neue Platte übertragen
Hallo,
Nachdem "vgscan -vvv" den Hinweis geliefert hatte, dass "devices/global_filter not found in config" — habe ich in der lvm.conf die global_filter Zeile auskommentiert. Jetzt wurden sowohl im Loop-Device als auch auf der sdd2-Partition die fehlenden LVs gefunden, leider doppelt. Deshalb habe ich das Loop-Device mit "losetup -d /dev/loop1" ausgehängt — auch um das backup.img nicht weiter anfassen zu müssen.
Was jetzt noch zu Fehlermeldungen führte war die Namensgleichheit der VG im aktuellen System (sda3) und der VG des Backup-Images (in sdd2). Um gezielt die richtige VG umbenennen zu können muss sie über ihre UUID angesprochen werden, die mit vgdisplay ausgelesen werden konnte. In der Backup-VG war aber noch ein nicht mehr vorhandenes PV gelistet. Ich war mir sicher, dass dieses Laufwerk keine Daten enthielt und konnte es mit vgreduce entfernen. Jetzt liefen die Befehle pvs, vgs und lvs ohne Error-Meldungen durch. Ich babe dann die beiden VGs mit vgmerge zusammengeführt. Nun konnte ich die benötigten LVs mit pvmove von der sdd2-Partition auf die sda3 verschieben. Die nicht benötigten LVs wurden mit lvremove entfernt. Als das PV_backup (sdd2) leer war konnte ich die die Partition aus der VG_aktuell mit vgreduce entfernen
Im Einzelnen habe ich folgende Befehle benutzt:
Damit war mein Ziel erreicht — ich konnte Teile aus einem Image von einer LVM-Partition auf eine neue Partiton transferieren.
Nachdem "vgscan -vvv" den Hinweis geliefert hatte, dass "devices/global_filter not found in config" — habe ich in der lvm.conf die global_filter Zeile auskommentiert. Jetzt wurden sowohl im Loop-Device als auch auf der sdd2-Partition die fehlenden LVs gefunden, leider doppelt. Deshalb habe ich das Loop-Device mit "losetup -d /dev/loop1" ausgehängt — auch um das backup.img nicht weiter anfassen zu müssen.
Was jetzt noch zu Fehlermeldungen führte war die Namensgleichheit der VG im aktuellen System (sda3) und der VG des Backup-Images (in sdd2). Um gezielt die richtige VG umbenennen zu können muss sie über ihre UUID angesprochen werden, die mit vgdisplay ausgelesen werden konnte. In der Backup-VG war aber noch ein nicht mehr vorhandenes PV gelistet. Ich war mir sicher, dass dieses Laufwerk keine Daten enthielt und konnte es mit vgreduce entfernen. Jetzt liefen die Befehle pvs, vgs und lvs ohne Error-Meldungen durch. Ich babe dann die beiden VGs mit vgmerge zusammengeführt. Nun konnte ich die benötigten LVs mit pvmove von der sdd2-Partition auf die sda3 verschieben. Die nicht benötigten LVs wurden mit lvremove entfernt. Als das PV_backup (sdd2) leer war konnte ich die die Partition aus der VG_aktuell mit vgreduce entfernen
Im Einzelnen habe ich folgende Befehle benutzt:
Code: Alles auswählen
vgdisplay # UUID auslesen
vgrename UUID VG_neuer_Name # vergibt an die VG_mit_UUID den neuen Namen
vgreduce --removemissing VG_backup # löscht das fehlende Laufwerk aus der VG_backup
vgmerge VG_backup VG_aktuell # beide VGs werden in der VG_aktuell zusammengeführt
pvmove LV01 /dev/sdd2 /dev/sda3 # verschiebt LV01 nach sda3
...
pvmove LV05 /dev/sdd2 /dev/sda3 # verschiebt LV05 nach sda3
lvremove VG_aktuell LVxx # löscht LVxx aus der VG_aktuell
vgreduce VG_aktuell /dev/sdd2 # entfernt sdd2 aus der VG_aktuell