Proxmox alte VM wieder kriegen

[Liesel Weppen]

Hi,

habe einen Proxmoxserver laufen.
Der hatte ein 128GB SSD auf der Proxmox selbst installiert war und eine 750GB HDD auf der die VMs in einem LVM lagen.
Die VMs sollen auf eine neue 2TB SSD umziehen.

Dummerweise war das Bootgeraffel auf der HDD installiert, hat also ohne die HDD nicht gebootet, also habe ich mal eben Proxmox neu auf die 128GB SSD installiert.

Ich dachte eigentlich, das ich "einfach" die alte HDD wieder einbinden kann, die VMs dann wieder da wären (oder einfach neu importiert werden können) und die dann einfach irgendwie auf die neue SSD verschieben könnte.
Da war ich wohl zu naiv, aber das wäre ja eigentlich der Sinn der ganzen Virtualisierung.

Die HDD ist da, das LVM kann ich auch einbinden, aber irgendwie finde ich nichts, wie ich an die VMs wieder drankomme.

Komischerweise hat mir Proxmox bei der Installation die 128GB in 30GB "local" und 80GB "local-lvm" geteilt (oder war schon mit der alten Installation so, weiß ich nichtmehr). Auf dieser "local-lvm" werden mir unter VM-Disks die alten VMs sogar mit Snapshots angezeigt, allerdings mit Größen die bei weitem gar nicht auf die 80GB passen würde (die waren/sind ja auch auf der HDD und auch deutlich größer). Aber das wird mir da nur angezeigt, ich kann damit irgendwie nix machen.

Komm ich da noch irgendwie ran?

Wenn das nicht geht, oder ich das jetzt selbst schon irgendwie verbockt habe, ist das nicht wirklich schlimm, nur nervig, weil dann muss ich halt erst neue VMs aufsetzen.
Aber dann stellt sich die Frage, bevor ich mir da jetzt die Mühe mache, ob Proxmox mit diesem LVM-Quatsch das richtige für mich ist. Die VMs sind eigentlich extra deswegen auf einer extra Platte. Im Prinzip will ich diese Platte im Extremfall auch einfach in einen anderen Rechner (mit auch wieder Proxmox drauf) stecken können und die VMs sollen davon trotzdem einfach wieder lauffähig sein.

Ich will aber halt auf jedenfall ein Webinterface haben, über das man zumindest die wichtigsten Sachen machen kann, so wie das eben bei Proxmox ist.

 

[spyfly]

Ich dachte eigentlich, das ich "einfach" die alte HDD wieder einbinden kann, die VMs dann wieder da wären (oder einfach neu importiert werden können) und die dann einfach irgendwie auf die neue SSD verschieben könnte.
Da war ich wohl zu naiv, aber das wäre ja eigentlich der Sinn der ganzen Virtualisierung.

Die VMs haben Konfigurationsdateien, diese liegen unter /etc/pve/qemu-server auf deinem Root Dateisystem. Da du diese aber unglücklicherweise durch die Neuinstallation vernichtet hast, müsstest du diese neu erstellen. Das Proxmox Wiki ist für die einzelnen Konfigurationsoptionen nen ganz guter Anlaufpunkt.

Hast du von deinen VMs Backups erstellt? In den VZDump Backups ist normalerweise eine QEMU Konfigurationsdatei enthalten, diese könntest du dann einfach übernehmen.

 

[Liesel Weppen]

Die VMs haben Konfigurationsdateien, diese liegen unter /etc/pve/qemu-server auf deinem Root Dateisystem. Da du diese aber unglücklicherweise durch die Neuinstallation vernichtet hast, müsstest du diese neu erstellen.

Die VM ansich neu erstellen wäre ja kein Problem, aber wie krieg ich die dazu, die alte "Disk" wiederzverwenden? Und wie finde ich die wieder?

Hast du von deinen VMs Backups erstellt? In den VZDump Backups ist normalerweise eine QEMU Konfigurationsdatei enthalten, diese könntest du dann einfach übernehmen.

Selbstverständlich nicht. Und es ist nicht Sinn der Sache, das ich eine eigentlich intakte VM auf einer Festplatte nur wieder herstellen kann, wenn ich vorher ein Backup gemacht habe.

 

[spyfly]

Die VM ansich neu erstellen wäre ja kein Problem, aber wie krieg ich die dazu, die alte "Disk" wiederzverwenden? Und wie finde ich die wieder?

Da würde ich dir die vom Proxmox-Mitarbeiter Dominic empfohlene Methode ans Herz legen wollen.

Du packst quasi die VM Daten vom LVM in eine image.raw Datei und diese kannst du dann in neu erstellte VMs importieren. Das kann dann auch schon auf die neue 2TB SSD geschehen.

Selbstverständlich nicht. Und es ist nicht Sinn der Sache, das ich eine eigentlich intakte VM auf einer Festplatte nur wieder herstellen kann, wenn ich vorher ein Backup gemacht habe.

Nein, weil auf der HDD nur die reinen VM Daten liegen und mehr nicht. Um diese 1:1 wiederherzustellen benötigst du eben auch die Konfiguration und diese liegt bekanntlich nicht innerhalb der VM-Disk selber und hätte dort auch nix verloren. Du könntest natürlich in Zukunft zusätzlich noch deine VM-Konfigurationen auf der HDD sichern.

 

[Liesel Weppen]

Nein, weil auf der HDD nur die reinen VM Daten liegen und mehr nicht. Um diese 1:1 wiederherzustellen benötigst du eben auch die Konfiguration und diese liegt bekanntlich nicht innerhalb der VM-Disk selber und hätte dort auch nix verloren.

Ich muss doch eine neue VM anlegen können und der dann einfach sagen "Das da ist deine Festplatte". Noch habe ich die alte HDD ja eingebaut und eingebunden.

Das hab ich jetzt prinzipiell auch hingekriegt, indem ich eine neue VM angelegt habe und dann in /etc/pve/qemu-server/100.conf editiert habe:
-scsi0: local-lvm-ssd:vm-100-disk-0,size=500G
+scsi0: local-lvm-old:vm-100-disk-0,size=500G


Die sind ja offensichtlich noch da, auch wenn ich sie im Webinterface nicht angezeigt kriege und die auch nicht beim Anlegen einer VM angeben kann und im Webinterface das auch nicht editieren kann.

root@T20:/etc/pve/qemu-server# lvs
  LV                              VG            Attr       LSize   Pool Origin        Data%  Meta%  Move Log Cpy%Sync Convert
  vm-100-disk-0                   local-lvm-ssd -wi-a----- 500.00g                                                         
  vm-101-disk-0                   local-lvm-ssd -wi-a----- 400.00g                                                         
  data                            pve           twi-a-tz-- <63.38g                    0.00   1.60                         
  root                            pve           -wi-ao----  29.00g                                                         
  swap                            pve           -wi-ao----   8.00g                                                         
  data                            pve_old       twi---tz-- 566.57g                    85.95  4.39                         
  root                            pve_old       -wi-------  96.00g                                                         
  snap_vm-100-disk-0_Init         pve_old       Vri---tz-k 500.00g data vm-100-disk-0                                     
  snap_vm-100-disk-0_LANReady     pve_old       Vri---tz-k 500.00g data vm-100-disk-0                                     
  snap_vm-101-disk-0_Works_better pve_old       Vri---tz-k 400.00g data vm-101-disk-0                                     
  snap_vm-101-disk-0_works        pve_old       Vri---tz-k 100.00g data vm-101-disk-0                                     
  swap                            pve_old       -wi-------   8.00g                                                         
  vm-100-disk-0                   pve_old       Vwi---tz-- 500.00g data                                                   
  vm-100-state-LANReady           pve_old       Vwi---tz-- <32.49g data                                                   
  vm-101-disk-0                   pve_old       Vwi-aotz-- 400.00g data               51.40                               
  vm-101-state-Works_better       pve_old       Vwi---tz--  <4.49g data                                                   
  vm-101-state-works              pve_old       Vwi---tz--  <4.49g data

Die Windows-VM hats jetzt anscheinend durch meine Experimente zerlegt. Es bootet noch ein Windows, aber endet in einem Bluescreen mit "inaccessible boot device".
Die Linux-VM hats anscheinend überlebt, die kann ich jetzt wieder starten und sie läuft auch.

Das taugt mir so ehrlich gesagt überhaupt nicht. Ich will die "Festplatte" einer VM einfach kopieren/verschieben/... können, ohne das ich irgendwelchen lvm-Quatsch brauche oder gar noch über Backup-Restore gehen muss. Da fehlt mir schon der Speicherplatz für so einen Extraschritt. Um eine 500GB-VM so zu "kopieren" brauche ich dann ja schon 1,5TB.

Jetzt habe ich natürlich noch die Disks der neu angelegten VMs auf local-lvm-ssd und die kann ich jetzt nichtmal im Webinterface löschen, weil eine VM mit dieser ID existiert *grrr*.

Ich versteh nichtmal, wo ich die "virtuellen Festplatten" überhaupt finde. Wovon müsste ich da jetzt überhaupt dd-n, wenn ich da von einer virtuellen Festplatte ein Image machen will?

root@T20:/dev/local-lvm-ssd# ls -la
total 0
drwxr-xr-x  2 root root   80 Jan  7 19:02 .
drwxr-xr-x 23 root root 4720 Jan  7 19:14 ..
lrwxrwxrwx  1 root root    7 Jan  7 18:39 vm-100-disk-0 -> ../dm-5
lrwxrwxrwx  1 root root    7 Jan  7 19:02 vm-101-disk-0 -> ../dm-6

Das wäre dann also /dev/dm-5
Aber /dev/local-lvm-old gibts nicht. Wieso? Ich hab das doch eingestellt.


Gibts das ganze auch irgendwie in "einfach" und "funktioniert"?
Nachdem ichs jetzt anscheinend eh schon geschrottet habe (zumindest die Windows-VM) und es damit eh neu machen muss, habe ich fürs nächste mal keine Lust auf den gleichen Murks nochmal.

Edit: Wenn ich die 2TB SSD als Directory statt als LVM einbinde und beim Anlegen der (neuen) VMs das Directory dann angebe, werden dort dann einfach Dateien für die virtuellen Festplatten angelegt? Bevor so jetzt neue VMs mache und dann wieder so ein umständlicher Quatsch rauskommt?

Verzeiht mir die Ausdrucksweise. Ich kann schon verstehen, das in komplexeren Setups sowas wie LVM durchaus sinnvoll ist, aber das ganze Zeug brauch ich nicht.

Edit2:
Ok, mit Directory legt er mir eine qcow2-Datei an. Das gefällt mir schonmal besser. Die wird allerdings direkt mit der ganzen Disk-Size angelegt. Kann man die auch irgendwie wachsen lassen, wie bei VirtualBox und Co? Wenn man ein anderes Format nimmt oder so?

 

[spyfly]

Ich muss doch eine neue VM anlegen können und der dann einfach sagen "Das da ist deine Festplatte". Noch habe ich die alte HDD ja eingebaut und eingebunden.

Das hab ich jetzt prinzipiell auch hingekriegt, indem ich eine neue VM angelegt habe und dann in /etc/pve/qemu-server/100.conf editiert habe:
-scsi0: local-lvm-ssd:vm-100-disk-0,size=500G
+scsi0: local-lvm-old:vm-100-disk-0,size=500G

Top, alles richtig gemacht soweit. Du kannst VMs auch ohne Disk anlegen und die dann nachträglich manuell hinzufügen.

Die Windows-VM hats jetzt anscheinend durch meine Experimente zerlegt. Es bootet noch ein Windows, aber endet in einem Bluescreen mit "inaccessible boot device".
Die Linux-VM hats anscheinend überlebt, die kann ich jetzt wieder starten und sie läuft auch.

Ich tippe auf einen falschen Disk Typ. Du kannst mal statt scsi sata probieren, dass hat der bei meiner Windows 10 VM out of the box genutzt.

Jetzt habe ich natürlich noch die Disks der neu angelegten VMs auf local-lvm-ssd und die kann ich jetzt nichtmal im Webinterface löschen, weil eine VM mit dieser ID existiert *grrr*.

Füge die Disk in der qemu config der VM als unused hinzu und dann sollten die sich übers Webinterface löschen lassen. Gleiches Format wie bei den scsis.

Gibts das ganze auch irgendwie in "einfach" und "funktioniert"?
Nachdem ichs jetzt anscheinend eh schon geschrottet habe (zumindest die Windows-VM) und es damit eh neu machen muss, habe ich fürs nächste mal keine Lust auf den gleichen Murks nochmal.

LVM ist dachte ich schon die einfach und funktioniert Lösung unter Proxmox . Wirklich komplex wird es erst mit ZFS. Du kannst natürlich auch Dateien nutzen, aber das produziert nur unnötigen overhead. Und du kannst dann keine Snapshots mehr machen.

Am sinnvollsten wäre es deine neue SSD erneut mit LVM zu provisionieren, da du dann einfach die deine bestehenden VMs ohne großen Aufwand direkt über die Proxmox GUI umziehen kannst.

Edit2:
Ok, mit Directory legt er mir eine qcow2-Datei an. Das gefällt mir schonmal besser. Die wird allerdings direkt mit der ganzen Disk-Size angelegt. Kann man die auch irgendwie wachsen lassen, wie bei VirtualBox und Co? Wenn man ein anderes Format nimmt oder so?

Schau mal mit df -h nach ob er das wirklich tut. Theorethisch sollte die Datei dynamisch wachsen, ls -a zeigt das nur nicht richtig an.

 

[Liesel Weppen]

Top, alles richtig gemacht soweit. Du kannst VMs auch ohne Disk anlegen und die dann nachträglich manuell hinzufügen.

Ah, jetzt hab ich kapiert, wie man das ohne Disk macht. Einfach den Diskeintrag löschen und des geht dann trotzdem weiter.

Ich tippe auf einen falschen Disk Typ. Du kannst mal statt scsi sata probieren, dass hat der bei meiner Windows 10 VM out of the box genutzt.

Wäre vorstellbar.
Kann ich das nachträglich ändern?
Aktuell hat die als SCSI-Controller VirtioSCSI eingetragen. Default wäre wohl "LSI 53C895A". Das ist aber das falsche, oder? Beim Anlegen einer VM wähle ich den Controller und den Festplattentyp separat aus, aber bei der schon erstellten VM finde ich jetzt keinen Festplattentyp.

Füge die Disk in der qemu config der VM als unused hinzu und dann sollten die sich übers Webinterface löschen lassen. Gleiches Format wie bei den scsis.

Probiere ich nachher.

LVM ist dachte ich schon die einfach und funktioniert Lösung unter Proxmox . Wirklich komplex wird es erst mit ZFS. Du kannst natürlich auch Dateien nutzen, aber das produziert nur unnötigen overhead. Und du kannst dann keine Snapshots mehr machen.

Öh, wenn dann keine Snapshots mehr gehen ist auch blöd.
Zusätzlicher Vorteil von Directory wäre, das ich einfach Zugriff auf die SSD habe und da dann auch anderweitig Zeugs hinkopieren kann, z.B. Kopien der VMs und so und zur Not eben auch von jedem anderen System aus einfach drauf zugreifen kann und direkt an die Festplattenimages rankomme.

Am sinnvollsten wäre es deine neue SSD erneut mit LVM zu provisionieren, da du dann einfach die deine bestehenden VMs ohne großen Aufwand direkt über die Proxmox GUI umziehen kannst.

Ich probier noch rum. Würde schonmal aufwand sparen, wenn ich jetzt erstmal die alten VMs von ihrem originalen Platz wieder zum Laufen kriege.

Schau mal mit df -h nach ob er das wirklich tut. Theorethisch sollte die Datei dynamisch wachsen, ls -a zeigt das nur nicht richtig an.

Hast Recht, laut df ist kaum Platz belegt.

Edit: Nochmal ne neue VM angelegt, nochmal nen 1GB Dummy erzeugt, damit die Configs erzeugt werden, diesmal mit SATA, dann wieder die cfg händisch geändert... Endet zumindest nicht im Bluescreen sondern rödelt sich gerade einen ab mit "Geräte werden Betriebsbereit gemacht". Vermutlich weil das Windows jetzt denkt es wäre auf neuer/anderer Hardware, aber das war zu erwarten.
Aha, im cfg einfach sata0: statt scsi0: hätts wohl auch getan.

 

[spyfly]

Wäre vorstellbar.
Kann ich das nachträglich ändern?
Aktuell hat die als SCSI-Controller VirtioSCSI eingetragen. Default wäre wohl "LSI 53C895A". Das ist aber das falsche, oder? Beim Anlegen einer VM wähle ich den Controller und den Festplattentyp separat aus, aber bei der schon erstellten VM finde ich jetzt keinen Festplattentyp.

Einfach die qemu Datei von der VM direkt bearbeiten. Die verfügbaren Plattentypen stehen in der vorhin verlinkten Doku.

Zusätzlicher Vorteil von Directory wäre, das ich einfach Zugriff auf die SSD habe und da dann auch anderweitig Zeugs hinkopieren kann, z.B. Kopien der VMs und so und zur Not eben auch von jedem anderen System aus einfach drauf zugreifen kann und direkt an die Festplattenimages rankomme.

Es hält dich doch niemand davon ab auf dem LVM ein Directory einzurichten 😉

 

[Liesel Weppen]

Es hält dich doch niemand davon ab auf dem LVM ein Directory einzurichten 😉

Ahso, ne gut, wenn das auch geht.

Aber wie komme ich die VM-Disks dann ran? Das mit dd kopieren habe ich gelesen, aber ich checke nicht, was das if da jetzt sein muss.

Siehe Edit oben und die Windows-VM hat jetzt gerade erfolgreich gebootet. Immerhin.

Und die Disk kann ich jetzt vermutlich in der Webgui mit "move disk" einfach verschieben, wenn ich aus der SSD wieder ein LVM mache?

 

[spyfly]

Aber wie komme ich die VM-Disks dann ran? Das mit dd kopieren habe ich gelesen, aber ich checke nicht, was das if da jetzt sein muss.

Unter /dev/{Name Deiner Volume Group}/ und da solltest du dann deine Volumes finden

So ist das zumindest bei meinem Ubuntu Desktop:

root@~:/dev/ubuntu-vg# ls
root  swap_1

Und die Disk kann ich jetzt vermutlich in der Webgui mit "move disk" einfach verschieben, wenn ich aus der SSD wieder ein LVM mache?

Korrekt

 

[Liesel Weppen]

Unter /dev/{Name Deiner Volume Group}/ und da solltest du dann deine Volumes finden

Das verwirrt mich eben. Das neu auf der SSD angelegte LVM ist (war) unter /dev/local-lvm-ssd zu sehen. Hab ja oben das ls gepostet.

Aber das alte auf der HDD, das ich ja jetzt als local-lvm-old eingebunden habe und von dem es ja jetzt auch die Images lädt, sehe ich da nicht und in der Webgui werden mir auch keine VMs auf diesem LVM angezeigt.

Es gibt bei mir kein /dev/local-lvm-old.

Was hat das mit LVM-Thin aufsich?

Das pve_old müsste eigentlich von der Größe die alte HDD sein.

LVM sieht so aus:

Aber auf dem LVM selbst werden mir keine VM Disks angezeigt:

Auf der CLI via "lvs" seh ich sie aber, wie oben schon gepostet.

Edit: Jetzt kopiere ich erstmal die Disks der beiden VMs auf die LVM-SSD. Dann steck ich die alte HDD ab, die ist dann sozusagen gleich mal ein Notfallbackup auf dem man nicht mehr versehentlich was kaputt schreiben kann. Das wird eine Weile dauern.

 

[spyfly]

Es gibt bei mir kein /dev/local-lvm-old

Das ist der Name von deinem Storage unter Proxmox. Die Volume Group selber heißt laut deinem lvs Ausschnitt pve_old, so sollte es ja auch in deiner Proxmox Storage Config stehen.

Was hat das mit LVM-Thin aufsich?

Ermöglicht Thin-Provisioning, siehe PVE Wiki

Aber auf dem LVM selbst werden mir keine VM Disks angezeigt:

Weil die Storage GUI soweit ich weiß nur über Proxmox erstellte Disks anzeigen kann.

 

[Liesel Weppen]

Das ist der Name von deinem Storage unter Proxmox. Die Volume Group selber heißt laut deinem lvs Ausschnitt pve_old, so sollte es ja auch in deiner Proxmox Storage Config stehen.

Ja und was heisst das jetzt?
/dev/pve_old gibts, aber da liegt nur eine vm-101-disk-0? Das ist dann die von der SteamCache-VM?
Wo ist die vm-100-disk-0 von der Windows-VM?

Weil die Storage GUI soweit ich weiß nur über Proxmox erstellte Disks anzeigen kann.

Ach, das ist doch Mist.
Wenn ich eine LVM-HDD also in einen anderen Rechner stecke, geht da mit der Webgui gar nix, dann muss auf der CLI mit "lvs" gucken was die Disks sind und Configs händisch ändern?

Bin jetzt mal gespannt, die 101 Disk hat 400GB, die 100 Disk hat 500GB. Beides liegt auf einer 750GB-HDD. Bei der 101-Disk will er jetzt anscheinend tatsächlich 400GB auf die SSD kopieren.

 

[spyfly]

Ja und was heisst das jetzt?

Storage - Proxmox VE

pve.proxmox.com

/dev/pve_old gibts, aber da liegt nur eine vm-101-disk-0? Das ist dann die von der SteamCache-VM?
Wo ist die vm-100-disk-0 von der Windows-VM?

Vielleicht in der Windows VM gemounted? Aber da bin ich auch überfragt. Ich kenne mich mit LVM nicht annähernd so gut aus wie mit ZFS.

Ach, das ist doch Mist.
Wenn ich eine LVM-HDD also in einen anderen Rechner stecke, geht da mit der Webgui gar nix, dann muss auf der CLI mit "lvs" gucken was die Disks sind und Configs händisch ändern?

Du hast einfach unrealistische Anforderungen an einen Enterprise Hypervisor.

Niemand fängt da an irgendwelche Festplatten mit Produktiv-VMs rumzutauschen. Das einzige was ich mir vorstellen könnte wäre ne externe HDD mit kompletten VM Backups. Aber normalerweise würde man da nen externes Speichersystem haben was mit NFS, CIFS, etc. angebunden ist auf welchem dann die Backups bzw. VMs direkt gespeichert sind. Und da steckt in den PVE Hosts dann nicht mehr als nen paar redundanter SSDs im ZFS Mirror drin. Und alle diese oben gegannten Anwendungsfälle werden fast zu 100% von der Proxmox GUI abgedeckt.

Und für so ein "Gebastel" wie du vorhast musst dann eben auf die CLI zurückgreifen. Weil sowas halt von Proxmox nicht vorhergesehen ist.

Hättest du deinen /etc/pve Ordner oder deine VMs vorher gesichert wärst du jetzt auch nicht in dieser Situation.

Ich würde dir deshalb einfach mal die Proxmox VE Dokumentation nahelegen und für alles weitere ist das Proxmox Forum eine gute Anlaufstelle.

Bin jetzt mal gespannt, die 101 Disk hat 400GB, die 100 Disk hat 500GB. Beides liegt auf einer 750GB-HDD. Bei der 101-Disk will er jetzt anscheinend tatsächlich 400GB auf die SSD kopieren.

Weil LVM-Thin Provisioning. Anders könntest du gar nicht mehr als die 750GB zuweisen.

 

[Liesel Weppen]

Vielleicht in der Windows VM gemounted? Aber da bin ich auch überfragt. Ich kenne mich mit LVM nicht annähernd so gut aus wie mit ZFS.

Das Disk-Image der Windows-VM soll in der Windows-VM gemountet sein?

Du hast einfach unrealistische Anforderungen an einen Enterprise Hypervisor.

Nein, keine unrealistischen Anforderungen, sondern eigentlich brauche ich für meinen Anwendungsfall überhaupt keinen "Enterprise" Hypervisor. Wobei "Enterprise" auch relativ ist, Proxmox nutzt afaik untenrum auch nur OSS KVM.
Eigentlich würde mir ein Windows mit installiertem VirtualBox reichen, nur das ist wieder kaum Headless benutzbar, sprich, hat kein Webinterface mit dem unter anderem auch direkt von einem Browser auf die "Graphicausgabe" einer VM kommt, wie das eben mit dem Proxomox-Webinterface geht.

Niemand fängt da an irgendwelche Festplatten mit Produktiv-VMs rumzutauschen. Das einzige was ich mir vorstellen könnte wäre ne externe HDD mit kompletten VM Backups.

Ja, wie gesagt, "Anwendungsfall". Bei mir ist nichts wirklich "produktiv", läuft auch nichtmal 24/7 sondern eher 5/365 . Und ich brauche auch keine Backups. Da ist nichts unverzichtbares drauf, was man nicht wieder neu installieren könnte.
Im wesentlichen will ich "nur" ein Windows und ein Linux auf einem einzigen Rechner parallel laufen haben. Und es sollte Headless zugreifbar sein ohne irgendwelche speziellen Anforderungen, also von einem beliebigem PC, der einfach nur einen Browser installiert hat.
Wenn ich aber schon virtualisiere, dann erwarte ich, das ich eine Festplatte auf der VM-Images sind einfach umziehen kann. Im Worst-Case will ich die SSD mit den Images aus dem aktuellen Rechner rausnehmen können, in einen anderen Rechner (mit dem selben Hypervisor) wieder reinstecken können und dann die VMs direkt und unkompliziert wieder importieren können (im Idealfall würde der sie sogar automatisch erkennen).
Sozusagen wie bei VMWare Workstation/VirtualBox wenn ich mir einfach das ganze VM-Verzeichnis kopiere (wo auch die VM-Einstellungen, nicht nur die Virtuelle Disk drinliegen).

Und für so ein "Gebastel" wie du vorhast musst dann eben auf die CLI zurückgreifen. Weil sowas halt von Proxmox nicht vorhergesehen ist.

Das was ich mache ist eigentlich kein Gebastel, sondern ein wesentlich einfacherer Anwendungsfall. Das Gebastel kommt nur davon, das Proxmox alles wesentlich komplizierter macht, als ich es überhaupt brauche. Was ich durchaus verstehen kann, weil es eben für wesentlich komplexere Anwendungsfälle gedacht ist.

Deswegen schrieb ich bereits in meinem ersten Post: Ich bin mir nichtmehr sicher, ob Proxmox überhaupt das Richtige für mich ist und muss auch nicht zwangsläufig bei Proxmox bleiben. Allerdings kenne ich nur die "Customer-Lösung" ala VMware oder VirtualBox auf einem PC, aber das ist nicht wirklich Headlesstauglich. Oder dann eben sowas wie Proxmox, was für mich wie mir ja bewusst ist auch wieder völliger Overkill ist.
Wenn jemand eine entsprechende Zwischenlösung kennt, nur raus damit.
Nein, auf einem Debian KVM händisch einrichten und sich selbst ein Webinterface programmieren ist keine entsprechende Zwischenlösung.
Und der Hypervisor sollte Linux sein, weil ich keine Lust habe mir noch eine Windowslizenz nur für einen Hypervisor zu kaufen.

Weil LVM-Thin Provisioning. Anders könntest du gar nicht mehr als die 750GB zuweisen.

Naja und wenn ich Directory mache, kann ich auch 15TB VirtualDisks auf einer 1TB Festplatte anlegen, weil die Disk-Images ja erst wachsen. Wenn alle zusammen die physischen 1TB überschreiten gibts natürlich ein Problem. Aber wenn direkt die volle Größe belegt wird, muss ich mich halt schon vorab entscheiden, ob jetzt VM A 500GB braucht und VM B auch 500GB. Und wenn sich dann rausstellt, das VM A 800GB bräuchte, aber VM B doch mit 100GB auskäme, habe ich wieder endloses Gefrickel.

Heisst jetzt andersrum: Auf dem LVM-(nicht-Thin)-Volume belegt das direkt die angegebene Größe?

 

[spyfly]

Das Disk-Image der Windows-VM soll in der Windows-VM gemountet sein?

Es ist kein Disk Image, es ist ein Volume. Und dieses ist wenn die Windows-VM läuft von QEMU in die Windows-VM gemounted. Probier mal die Windows VM zu stoppen und schau dann ob das Volume dann auftaucht.

Das was ich mache ist eigentlich kein Gebastel, sondern ein wesentlich einfacherer Anwendungsfall. Das Gebastel kommt nur davon, das Proxmox alles wesentlich komplizierter macht, als ich es überhaupt brauche. Was ich durchaus verstehen kann, weil es eben für wesentlich komplexere Anwendungsfälle gedacht ist.

Deswegen schrieb ich bereits in meinem ersten Post: Ich bin mir nichtmehr sicher, ob Proxmox überhaupt das Richtige für mich ist und muss auch nicht zwangsläufig bei Proxmox bleiben. Allerdings kenne ich nur die "Customer-Lösung" ala VMware oder VirtualBox auf einem PC, aber das ist nicht wirklich Headlesstauglich. Oder dann eben sowas wie Proxmox, was für mich wie mir ja bewusst ist auch wieder völliger Overkill ist.
Wenn jemand eine entsprechende Zwischenlösung kennt, nur raus damit.
Nein, auf einem Debian KVM händisch einrichten und sich selbst ein Webinterface programmieren ist keine entsprechende Zwischenlösung.
Und der Hypervisor sollte Linux sein, weil ich keine Lust habe mir noch eine Windowslizenz nur für einen Hypervisor zu kaufen.

In dem Fall vielleicht einfach das ganze LVM Gedöns weglassen und die VMs-Disks direkt auf der Platte in QCOW2 Dateien speichern. Die ganze Materie zu verstehen geht halt nicht mal eben so.

Und eine kleine Ergänzung zu vorhin. Snapshots funktionieren mit dem Directory Storage unter der Vorraussetzung, dass das QCOW2 Format zum Einsatz kommt. Also quasi alles was du brauchst ohne alles unnötig kompliziert zu machen.

Heisst jetzt andersrum: Auf dem LVM-(nicht-Thin)-Volume belegt das direkt die angegebene Größe?

Korrekt, wenn man einen LVM Pool ohne Thin nutzt oder dieses bei ZFS nicht explizit aktiviert wird direkt die angegebene Größe belegt.

 

[Liesel Weppen]

Es ist kein Disk Image, es ist ein Volume. Und dieses ist wenn die Windows-VM läuft von QEMU in die Windows-VM gemounted. Probier mal die Windows VM zu stoppen und schau dann ob das Volume dann auftaucht.

Taucht auch nicht auf, wenn die VM nicht läuft.

In dem Fall vielleicht einfach das ganze LVM Gedöns weglassen und die VMs-Disks direkt auf der Platte in QCOW2 Dateien speichern. Die ganze Materie zu verstehen geht halt nicht mal eben so.

Korrekt, die ganze komplexe Materie interessiert mich für diesen Fall auch nicht, weil ich sie nicht brauche. Und wenn ich das vermeiden kann, werde ich das auch vermeiden. Daher oben ja schon das Experiment mit Directory statt LVM.

Und eine kleine Ergänzung zu vorhin. Snapshots funktionieren mit dem Directory Storage unter der Vorraussetzung, dass das QCOW2 Format zum Einsatz kommt. Also quasi alles was du brauchst ohne alles unnötig kompliziert zu machen.

Das klingt gut und wäre für mich komplett ausreichend, auch wenn es einen gewissen Overhead erzeugt. Glaube die neue SSD wird das mehr als nur ausgleichen.

Nicht unbedingt nötig, weil neu machen ja durchaus auch drin wäre, würde es mir dennoch viel Arbeit ersparen, wenn ich jetzt noch wüsste, wie ich die vorhandenen VMs aus dem LVM dann entsprechend zu QCOW2 konvertiere.
Was ich bisher so gelesen habe, scheint das möglich zu sein? Da die neue 2TB noch frei ist, wäre das für den einmaligen Umzug ja auch über die Backup-Funktion denkbar, nachdem die Original-VMs von der HDD ja jetzt zumindest wieder laufen?

Ich danke dir aber schonmal, du hast mir sehr gut weitergeholfen und ich hab auch wieder was gelernt (wenn auch noch nicht wirklich alles verstanden. )

Oh und wo wir schon bei unrealistischen Anforderungen sind: Man kann Proxmox nicht zufällig irgendwie beibringen, das die VM-Config dann auch gleich mit auf das Directory neben dem Disk-Image gespeichert wird, so das man tatsächlich die Platte samt VM-Config in einen anderen Rechner stecken könnte, ohne auch leere VMs neu einzurichten?

 

[spyfly]

Taucht auch nicht auf, wenn die VM nicht läuft.

Ist ja auch egal, solange es in die VM gemounted wird, sollte es sich auch sichern und im Anschluss mit ein wenig extra Aufwand restoren lassen.

Nicht unbedingt nötig, weil neu machen ja durchaus auch drin wäre, würde es mir dennoch viel Arbeit ersparen, wenn ich jetzt noch wüsste, wie ich die vorhandenen VMs aus dem LVM dann entsprechend zu QCOW2 konvertiere.
Was ich bisher so gelesen habe, scheint das möglich zu sein? Da die neue 2TB noch frei ist, wäre das für den einmaligen Umzug ja auch über die Backup-Funktion denkbar, nachdem die Original-VMs von der HDD ja jetzt zumindest wieder laufen?

Du machst einfach über die integrierte Backup Funktion ein Backup und kannst die dann manuell via cli restoren.

Dazu machst du einfach (wenn Storage der Name von dem Directory Storage auf deiner neuen SSD ist)

qmrestore {Backup_Datei} {Neue_VMID} --storage Storage

 

[Liesel Weppen]

Ok, man kann mit "move disk" anscheinend direkt die VM vom LVM als QCOW2-Datei auf das Directory moven. Das sieht soweit erstmal vielversprechend aus.

Du machst einfach über die integrierte Backup Funktion ein Backup und kannst die dann manuell via cli restoren.

Ja stimmt, da sich die eigentliche VM-Config ja normalerweise nie ändert, kann man das nach dem Einrichten einmalig als "Backup" aufs Directory kopieren.

Jo, dann lass ich den Kopiervorgang jetzt mal laufen. Denke das ist vielversprechend und klingt ziemlich genau nachdem was ich mir so vorstelle. War dann quasi mit dem Umzug nur recht umständlich weil ich das initial "falsch" (für meinen Anwendungsfall) aufgesetzt habe.

 

[spyfly]

Ja stimmt, da sich die eigentliche VM-Config ja normalerweise nie ändert, kann man das nach dem Einrichten einmalig als "Backup" aufs Directory kopieren.

Du kannst das Backup auch ohne VM-Disks machen, dann hättest du das gewünschte Config Backup.

Ok, man kann mit "move disk" anscheinend direkt die VM vom LVM als QCOW2-Datei auf das Directory moven. Das sieht soweit erstmal vielversprechend aus.

Gut, das ist tatsächlich noch einfacher als der Umweg über das Backup und Restore.

 

[Liesel Weppen]

Du kannst das Backup auch ohne VM-Disks machen, dann hättest du das gewünschte Config Backup.

Meinte ich ja, ob/wie das geht steht noch zum Experiment aus.

Gut, das ist tatsächlich noch einfacher als der Umweg über das Backup und Restore.

Erstmal abwarten obs auch funktioniert, aber wenn man als Move-Destination schon ein Directory auswählen kann und dann auch noch den Image-Typ gehe ich mal davon aus, das es auch funktioniert.

 

[Liesel Weppen]

Woah, wie geil, beide VMs starten jetzt vom Directory. Das ist sogar hörbar... bzw. nichtmehr hörbar... und so schnell
Und die Files belegen sogar nur den Platz den sie wirklich brauchen, also wesentlich weniger als die angegebene Disksize.

 

[Liesel Weppen]

Meine Fresse, wenn denn nur mal irgendwas einfach nur funktionieren könnte.

Jetzt kennt die Windows10-Installation den Netzwerkadapter nichtmehr.

Sysprep habe ich probiert.
Netzwerkadapter auf E1000 geändert, geht auch nicht.
Netzwerkadapter auf VirtIo geht auch nicht.
Virtio-Guest-VM-iso eingebunden, findet auch keinen passenden Treiber.
MachineType auch schon auf q35 geändert, trotzdem kein Netzwerk.

Meine Fresse, es kotzt mich langsam an. Ich will meinen 386er zurück. Mit nem ganz einfachen Bios wo man einfach sagen konnte: Das ist die fucking Festplatte von er du zu booten hast und das einfach geht. Mit ganz einfacher Hardware, nicht diesem verfickten EFI-Dreck, das zwar theoretisch alles kann, aber nichts einfach funktioniert. GRRRRR!
Boah, diese ganze Scheiße, das jeder Fotzendreck irgendwie alles mögliche können muss und dadurch sogar das denkbar Einfachste auch immer sau kompliziert werden muss und NICHTS mehr einfach funktioniert.

Windows erkennt einen RedHat VirtIo Ethernet Adapter, findet aber keine Treiber dafür, auch nicht auf der VirtIo-Cd...

Ich hätte die Scheiße einfach bleiben lassen sollen. Es lief, das Proxmox war zwar von 2017, aber es lief. Das Update der Windows-VM hat zwar ne gute Stunde gedauert, aber es lief. Es geht halt doch nichts über "never change a running system". Jetzt spiel ich schon den ganzen Tag an dem Scheißdreck rum, das ist schon mehr Zeit als die nächsten 5 Jahre verbraten worden wäre, wenn es für jeden verdammten einzelnen Boot eine ganze Stunde gebraucht hätte.

Ich kann nicht in Worte fassen, wie mich das gerade aufregt!

 

[spyfly]

Netzwerkadapter auf E1000 geändert, geht auch nicht.

E1000 ist der Standard der eigentlich funktionieren sollte.

Du könntest mal probieren den OS Type in Proxmox auf Windows 11 zu ändern.

 

[Liesel Weppen]

Du könntest mal probieren den OS Type in Proxmox auf Windows 11 zu ändern.

Ändert leider nichts, weder mit Virtio noch mit E1000. Weder mit Win10 noch mit Win11.

Im Gerätemanager wird ein Ausrufezeichen angezeigt mit "die Klassenkonfiguration für dieses Gerät wird von Windows noch eingerichtet (Code 56)". Auf gut Deutsch: Fick dich, geht halt nicht, ich sag dir aber nicht warum.
Egal welcher Netzwerkadapter, Windows behauptet es wären die aktuellsten Treiber, auch wenn ich die ISO durchsuchen lasse.
Netzwerk zurücksetzen hat auch nach jeglicher Änderung nichts gebracht.

Nochmal Danke für deine Hilfe, aber ich geh jetzt erstmal ins Bett, bevor die ganze Kiste noch brennend durchs geschlossene Fenster fliegt und dabei noch jemanden erschlägt.

 

[spyfly]

Klingt mir eher nach nem Windows Problem, als nem Problem mit dem Hypervisor. Du könntest versuchen ein zweites Netzwerkinterface hinzuzufügen und ansonsten bleibt wohl wirklich nur noch die Neuinstallation.

 

[Liesel Weppen]

Moing,

ja, das mit dem Netzwerk jetzt liegt ziemlich sicher an Windows, nicht am Proxmox. In der Linux-VM funktioniert das ja auch wie gewohnt.

 

[Liesel Weppen]

Frisch installiertes Windows hat das gleiche Problem mit dem Netzwerk. Sowohl mit E1000 als auch mit Virtio.

Benutzt ihr SeaBIOS, oder was anderes?
Machine-Type habe ich i440fx-6.1 und 5.2 probiert. In beiden Fällen das gleiche.

Edit:

Reddit - Dive into anything

www.reddit.com

Der hat genau das gleiche Problem. Hab auch die gleichen dmesg-Ausgaben.

Ich probier jetzt auch mal eine englische Windows-Version.

Windows hängt sich auch beim Setup gerne mal auf, meist schon beim ersten Kopieren der Installationsdateien. Nicht immer an der gleichen Stelle, aber irgendwie sehr oft.

Edit:
Alter, das gibts nicht!! Hab jetzt den SCSI-Controller mal auf den Default (LS-irgendwas) geändert und bin damit durchs Setup der englischen Version gekommen.
Virtio-Guest-Zeugs installiert, Netzwerk geht sofort.

(Jetzt mit Machine-Type q35-6.1. Weil ich auch häufig gelesen habe, das das Problem wohl am anderen Type liegen soll... keine Ahnung was das ausmacht, aber wenns jetzt erstmal läuft, ists ja schonmal gut)

Wie kriegts Microsoft nur immer hin sowas zu verkacken?

 

[Digi-Quick]

Die VMs haben Konfigurationsdateien, diese liegen unter /etc/pve/qemu-server auf deinem Root Dateisystem. Da du diese aber unglücklicherweise durch die Neuinstallation vernichtet hast, müsstest du diese neu erstellen. Das Proxmox Wiki ist für die einzelnen Konfigurationsoptionen nen ganz guter Anlaufpunkt.

Hast du von deinen VMs Backups erstellt? In den VZDump Backups ist normalerweise eine QEMU Konfigurationsdatei enthalten, diese könntest du dann einfach übernehmen.

Was soll der Quatsch denn? Die VM Konfiguration gehört zu der VM und nicht zum Virtualisierer.

Bei VMWare (ESXi, Vmware-Player / Workstation) importiert man einfach die VM, nachdem man den VM-Datasstore eingebunden hat

 

[Liesel Weppen]

Bei VMWare (ESXi, Vmware-Player / Workstation) importiert man einfach die VM, nachdem man den VM-Datasstore eingebunden hat

Ja, so kenne ich das auch.

Weiß auch nicht, ob das ein Proxmox-Ding ist, oder ob das grundsätzlich ein KVM-Thema ist, aber ich habs jetzt mit Directory nichtmal hingekriegt die QCOW2-Festplatte meiner VM 103 in die VM 100 einzuhängen, weil die liegt unter Storage/images/103/103-disk-0.qcow2 und damit nicht im Ordner der VM 100.
Also die Datei kopiert (und umbenannt) nach Storage/images/100/100-disk-2.qcow2, voila, einbinde geht.

Noch habe ich genug Speicherplatz frei für solche unnütze Spielchen...
Versteh nicht was so schwer daran ist, ein Festplattenimage einzubinden, das nicht im eigenen VM-Verzeichnis liegt. Und wenn ich ihm sage "binde das Festplattenimage von /fick/dich/ins/Knie.qcow2 ein", dann soll er doch bitte genau das tun.