Von einem Server lese ich nichts.saxandl hat geschrieben:22.11.2022 09:29:02Ich möchte nicht die ganze Installation mit den individuellen Anpassungen 10 mal durchführen
Wo ist das Problem? Auch aus einer VM heraus kann man ein Image der Dateisysteme, die auf den virtuellen Disks liegen, machen. Alternativ könnte man ein System auch per rsync klonen.KP97 hat geschrieben:22.11.2022 16:16:56Der TE hat ein Debian in einer VM installiert, angepaßt, und möchte dieses System aus der VM exportieren und ausrollen.
Weiß ichKP97 hat geschrieben:22.11.2022 16:27:15@cosinus
Ich bin nicht der TE und habe auch kein Problem...
hab deine AW aber als so eine Art Einwand/Hinweis verstanden, dass das zu klonende System in einer VM liegt.
Server = NUCKP97 hat geschrieben:22.11.2022 16:16:56@heisenbergVon einem Server lese ich nichts.saxandl hat geschrieben:22.11.2022 09:29:02Ich möchte nicht die ganze Installation mit den individuellen Anpassungen 10 mal durchführen
Der TE hat ein Debian in einer VM installiert, angepaßt, und möchte dieses System aus der VM exportieren und ausrollen.
Nicht unbedingt. Ich habe auch einen NUC, das sind Mini-PC's von z.B. Intel
Ich verstehe leider gar nicht, was Du mir mit Deiner Reaktion auf meinen Post sagen möchtest. Ein NUC ist ein Stück Hardware - ganz egal ob Server oder Desktop, oder Mini-PC oder sonst was. Der TE möchte das System, was virtuell ist, auf diese HW bringen. Solange der Softwarestand der VM ausreichend neu ist und der NUC-Typ genug Speicher hat, sollte das übertragen von VM auf NUC kein Problem sein.KP97 hat geschrieben:22.11.2022 16:41:11Nicht unbedingt. Ich habe auch einen NUC, das sind Mini-PC's von z.B. Intel
https://de.wikipedia.org/wiki/Next_Unit_of_Computing
dachte nicht, dass das von Bedeutung ist. Es ist ein Debian11 in der proxmox-VM. Dort befindet sich die "Master"-Version.KP97 hat geschrieben:22.11.2022 16:38:48Solange der TE nicht verrät, welche VM er überhaupt einsetzt, ist das alles nur Spekulation. Soweit ich weiß, haben aber die VM's intern auch Mechanismen, um das umzusetzen.
Was meinst du denn da? Dass man mit Virtualisierungssoftware VMs exportieren kann? Falls ja, ich glaub das wäre in diesem Fall nicht zielführend, da er ja das gesamte System, was jetzt in der VM ist, auf "richtige" Hardware bringen will.KP97 hat geschrieben:22.11.2022 16:38:48Soweit ich weiß, haben aber die VM's intern auch Mechanismen, um das umzusetzen.
Mit proxmox hab ich keine Erfahrungen. Aber grundsätzlich gibt es zwei Möglichkeiten ein System zu klonen. Entweder du machst ein komplettes Image der Dateisysteme des Quellsystems (zB mit dd oder pv) und stellst dieses auf dem Zielsystem über ein Livesystem wieder her. Beachte dabei, dass du hier auch die UUIDs der Dateisysteme mitkopierst.saxandl hat geschrieben:22.11.2022 18:57:10dachte nicht, dass das von Bedeutung ist. Es ist ein Debian11 in der proxmox-VM. Dort befindet sich die "Master"-Version.
Diese sollte dann Konfigurations-ident, mit Usern, LXDE-Konfigurationen, Drucker-Einstellungen, Applikationen auf 10 NUC's portiert werden. Ev. muss der LAN-Treiber nachinstalliert werden.
Richtig, und das funktioniert völlig unabhängig von der Virtualisierung (weshalb ich die Nachfrage nach der Virtualisierung nicht nachvollziehen kann).cosinus hat geschrieben:22.11.2022 22:35:45Oder du kopierst auf Dateilevelebene alle relevanten Dateien und Ordner mit rsync und startest dann auf dem Zielsystem ein Livesystem, richtest mit fdisk oder gdisk die SSD ein, hängst sie ein und kopierst dahin mit rsync alles rein. Danach musst du natürlich noch grub installieren, sonst startet das System nicht.
Die kann man einfach beim Filesystemanlegen mitgeben,dann stimmen die UUID überein und das editieren entfällt.Wenn man die Zielplatte/SSD neu formatiert, bekommt diese eine neue UUID.
Ja richtig, ich hab es auch nur grob skizziert, weil ich nicht weiß, ob der TO damit was anfangen kann. Selbstverständlich muss man danach noch alles anpassen wie die fstab und natürlich auch andere Einstellungen, die ja später für jede geklonte Maschine individuell sind.MSfree hat geschrieben:23.11.2022 08:23:57Ein Bißchen mehr als das, was cosinus beschreibt, ist aber doch noch nötig:
Mit sowas wie dd oder pv geht das auch, aber damit werden u.U. sehr viele unbelegte Blöcke des Filesystem mitkopiert und geschrieben. Und wie gesagt klonst du auch die UUID des Dateisystems mit, das will man auch nicht unbedingt, dass jede Maschine die gleichen UUIDs in den Dateisystemen hat...saxandl hat geschrieben:23.11.2022 11:03:06Erstmal vielen Dank für die zahlreichen inputs!
Ich werde jetzt mal mit dd ein image erstellen und sehen, welche Hürden entstehet.
Werde hier berichten!
Mir fallen dazu gerade keine negativen Nebeneffekte ein. Die Images für den Raspberry Pi sind auch mit der selben UUID versehen und damit laufen weltweit über 100 Millionen Pis, ohne sich gegenseitig negativ zu beeinflussen.cosinus hat geschrieben:23.11.2022 11:06:46Und wie gesagt klonst du auch die UUID des Dateisystems mit, das will man auch nicht unbedingt, dass jede Maschine die gleichen UUIDs in den Dateisystemen hat...
Code: Alles auswählen
#!/bin/bash
BUDIR=/root
FILENAME=$BUDIR/backup-`date +%d.%m.%y`.tgz
tar cvzf $FILENAME \
--exclude=("/proc/*","/sys/*","/run/*","/dev/*",$FILENAME) \
--preserve-permissions \
--numeric-owner /Falls man mal auf die Idee kommt, die Platte aus einem System herauszurupfen und in anderes System zu stecken, bei dem aber die dortigen Dateisysteme dieselben UUIDs haben...aber ja, ansonsten macht das natürlich keine Probleme. Windows klone ich ja auch und da haben die Volumes natürlich auch alle dieselben Seriennummern/UUIDsMSfree hat geschrieben:23.11.2022 11:31:40Mir fallen dazu gerade keine negativen Nebeneffekte ein. Die Images für den Raspberry Pi sind auch mit der selben UUID versehen und damit laufen weltweit über 100 Millionen Pis, ohne sich gegenseitig negativ zu beeinflussen.
Das ist doch garnicht nötig wenn du mit dd klonst. Da wird auch die UUID mitgeklont und somit ist keine Anpassung in der fstab notwendig.