[SOLVED] PVE Umzug auf kleinere SSD - Wie vorgehen?

[tobi471]

Hallo,

aktuell läuft PVE auf einer 500 GB SSD.
Ich würde gerne auf eine vorhandene 480 GB SSD (Intel DC S4500 480GB Enterprise) umziehen, da die aktuelle SSD es wohl nicht mehr lange macht.

Wie wäre hier das Best Practice?

Mein Gedanke:
Clonezilla auf USB-Stick und mit Clonezilla booten.
Eingebaute 500 GB SSD auf 480 GB SSD clonen. Kann clonezilla das oder muss vorher irgendwie die Partition /dev/sda3 verkleinert werden?
SSDs tauschen.


So sieht es jetzt aus:

fdisk -l /dev/sda
Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: xxxxxxxx

Device       Start       End   Sectors   Size Type
/dev/sda1       34      2047      2014  1007K BIOS boot
/dev/sda2     2048   1050623   1048576   512M EFI System
/dev/sda3  1050624 976773134 975722511 465.3G Solaris /usr & Apple ZFS

fdisk -l /dev/sdb
Disk /dev/sdb: 3.64 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: WDC WD40EFAX-68J
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: xxxxxxxxxx

Device          Start        End    Sectors  Size Type
/dev/sdb1        2048 7814019071 7814017024  3.6T Solaris /usr & Apple ZFS
/dev/sdb9  7814019072 7814035455      16384    8M Solaris reserved 1

 

[Hqu]

Hey,

mehr als das Clonezilla sich beschwert, das die Größe nicht passt, wird nicht viel passieren.

Schau vorab die technischen Spezifikationen der beiden SSDs an, beide entweder gleich groß sind oder die Intel Enterprise SSD größer ist.
Insofern die aktuelle PVE SSD nicht schon 100% belegt ist, ein backup der Konfigurationsdatein zu machen und die root Partition zu verkleinern.

LG

 

[aaron]

Auf eine kleinere Disk umzuziehen ist nie ganz einfach. Du musst alles davor entsprechend verkleinern.

Es sieht so aus, als ob das eine ZFS Installation ist. Man kann einen ZFS Pool nicht direkt einfach verkleinern. Aber ich war selbst vor ein paar Jahren in einer sehr ähnlichen Situation, dass ich meinen rpool auf kleinere SSDs umziehen wollte. Das wie habe ich in meinem persönlichen Blog dokumentiert.

Falls es keine ZFS Installation ist, wirst du das LVM und evtl. Filesystem in Partition 3 verkleinern müssen. Evtl. ist das data LV eh nicht ganz voll und kann leicht verkleinert werden. Ansonsten evtl. das root FS zuerst und dann die LV verkleinern. Ob Clonezilla das selbst kann weiß ich nicht.
Grundsätzlich muss man beim Verkleinern sehr vorsichtig sein, um nicht versehentlich etwas abzuschneiden.

Es bietet sich auch an, das Prozedere in kleinerer Form in einer VM nachzustellen bevor man es am Livesystem macht.

 

[tobi471]

Vielen Dank für die Unterstützung.
Es handelt sich um eine ZFS Installation:

zpool status rpool
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:04:05 with 0 errors on Sun Mar 10 00:28:08 2024
config:

        NAME                                                   STATE     READ WRITE CKSUM
        rpool                                                  ONLINE       0     0     0
          ata-Samsung_SSD_860_EVO_500GB_S4X9NF0M822828D-part3  ONLINE       0     0     0

errors: No known data errors

persönlichen Blog dokumentiert.

Ich schaue mir die Anleitung mal in Ruhe an. Sieht für mich als "Laie" nicht gerade einfach aus, aber man wächst ja mit seinen Aufgaben.
Die Samsung SSD 860 EVO wird ja mit 500GB angegeben, hat aber real nur:

fdisk -l /dev/sda Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors Disk model: Samsung SSD 860

Vieleicht habe ich ja Glück und die Intel DC S4500 480GB Enterprise hat real mehr als 465GB. Das sehe ich mir auch einmal vorab an.

 

[Dunuin]

Das hatten wir die Tage gerade erst mit ZFS auf kleinere Disk. Kannst du ein Raid0/Stripe aus beiden Disks machen, dann die größere Disk entfernen und die kleinere verbeibt. Guck nur dass du Backups hast, kein raidz1/2/3 vorkommt und beide Disks die selben Sektorgrößen haben: https://forum.proxmox.com/threads/replace-512gb-ssds-with-500gb-ssds.143077/

 

[news]

ZFS "Raid0/Stripe"
Sorry eine SSD/ HDD kann ich nicht aus einem bestehenden ZFS Stripe Set nicht mehr entfernen.
Das ist für ein Mirror/ Raid1 anders.
Ich würde mir erst die 1te und 2te Partition neu an legen und anschließend die Daten auf die neu ZFS Partition 3 dublizieren. Dabei muss man das ZFS Layout einhalten und anschließend noch den UUID Namen der Bootpartion eintragen.

 

[UdoB]

Sorry eine SSD/ HDD kann ich nicht aus einem bestehenden ZFS Stripe Set nicht mehr entfernen.
Das ist für ein Mirror/ Raid1 anders.

Auf einem aktuellen pve 8.1.4 / zfs 2.2.2 geht das, siehe man zpool-remove - man beachte "...and non-redundant primary top-level vdevs"

DESCRIPTION
     zpool remove [-npw] pool device…
             Removes the specified device from the pool.  This command sup‐
             ports removing hot spare, cache, log, and both mirrored and non-
             redundant primary top-level vdevs, including dedup and special
             vdevs.

 

[news]

Interessant, denn ich hatte vor zwei Monaten das Problem eine ZFS-Raid0 erstellt zu haben, aber wollte auf eine größeres ZFS Raid1 wechseln.

 

[ivenae]

Ich gebe zu bedenken, dass der Aufwand einer Neuinstallation mit vorherigem vzdump aller Maschinen ein verhältnismäßig kleiner Aufwand ist.
Darüber hinaus besteht sogar die Möglichkeit eines Fallbacks (einbau der alten SSD), falls etwas schief geht.

Ich persönlich würde mir den Aufwand nicht geben, zumal ich die Befürchtung hätte, dass man sich etwas zerschießt, was sich erst auf den zweiten Blick bemerkbar machst, z.B. nach dem nächsten Kernel-Upgrade oder pve 8 -> 9 upgrade.

 

[Dunuin]

Ich gebe zu bedenken, dass der Aufwand einer Neuinstallation mit vorherigem vzdump aller Maschinen ein verhältnismäßig kleiner Aufwand ist.
Darüber hinaus besteht sogar die Möglichkeit eines Fallbacks (einbau der alten SSD), falls etwas schief geht.

Ich persönlich würde mir den Aufwand nicht geben, zumal ich die Befürchtung hätte, dass man sich etwas zerschießt, was sich erst auf den zweiten Blick bemerkbar machst, z.B. nach dem nächsten Kernel-Upgrade oder pve 8 -> 9 upgrade.

Immer eine Frage der Situation. Bei mir ist z.B. nichts mit mal schnell neu aufsetzen. Dafür muss der PVE Host viel zu sehr umkonfiguriert werden. Und dafür extra etwas zu scritpen, für das schnelle Neuausrollen von PVE Hosts, würde bei den paar Nodes nicht lohnen. Besonders wenn man das Script dann für jedes PVE Major Release neu umschreiben und testen müsste.
Weiterer Vorteil ist, dass es da keine Downtime gibt und alles im laufenden Betrieb gemacht werden kann. Gerade nützlich wenn man keinen Cluster hat oder Passthrough nutzt und eine Live Migration zwecks Neuaufsetzen keine Option ist.

 

[tobi471]

Ich gebe zu bedenken, dass der Aufwand einer Neuinstallation mit vorherigem vzdump aller Maschinen ein verhältnismäßig kleiner Aufwand ist.
Darüber hinaus besteht sogar die Möglichkeit eines Fallbacks (einbau der alten SSD), falls etwas schief geht.

Mittlerweile denke ich auch dass es für mich auch der einfachere und sicherere Weg ist. Backups habe ich sowieso unter anderem auch immer wöchentlich von allen Maschinen gemacht.


Somit ist das Thema für mich hiermit gelöst.
Noch einmal vielen Dank an alle für die rege Diskussion