Zu wenig Speicherplatz für Win 7 in QEMU/KVM?

Hinweis: In dem Thema Zu wenig Speicherplatz für Win 7 in QEMU/KVM? gibt es 24 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Ich brauche das Windows nur für meine Bildbearbeitung 1-2 mal in der Woche mehr nicht und die Bilder werden auf der ext. Platte gespeichert, das wars!

    Mal über gimp nachgedacht?

    Für den Inhalt des Beitrages 128566 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Danke schon mal @Schoerch für Deine Hilfe, läuft noch nicht so gut wie es mal war aber mit Deiner Hilfe schaffen wir das auch noch! :rolleyes:




    Mal über gimp nachgedacht?

    Ja hab ich, aber bis ich damit einigermaßen Ergebnisse erziele dauert mir das persönlich zu lange, ist ein wirklich geniales Programm aber die Zeit würde ich dann doch lieber dahingehend nutzen mich mit der Konsole anzufreunden was mir eigentlich wichtiger erscheint! <X

    Systeminfo:


    Prozessor: 16 x AMD Ryzen 7 1800X. Board: ASRock KILLER SLI X 370. RAM: 32GB


    Grafik: NVIDIA® GeForce® GTX1060 6GB läuft mit dem Nouveau Treiber


    Betriebssystem: SSD: Leap 15.3 x64, Plasma 5.3.18-59.19-default

    Für den Inhalt des Beitrages 128570 haftet ausdrücklich der jeweilige Autor: Fritzle

  • Es mag einem leicht schwindlig werden, wenn man mit all den verwirrenden Speichergedöns konfrontiert wird.
    Leichter wird es, wenn man den berühmten Grundsatz alle unixoiden Betriebssysteme "Everything is a file" auf die Bithalden anwendet.


    Wir denken das Konzept "Datei" oft sehr herkömmlich. Auf einer Festplatte ein Stück mit Bits.
    Aber schon auf dieser einfachen Stufe liegen diverse Abstaktionsschichten verborgen.
    Teilweise machen das die Festplatten innerhalb ihrer eingebauten Elektrik selbst, ohne dass das OS, das aus Festplattensicht hoch im Himmel schwebt, davon gar nichts mitbekommt. Aber die verschiedenen Schichten sind immer da und arbeiten auch zusammen. Immer.


    Damit das funktioniert, werden diese Schichten einfach übereinander gestapelt.
    Jede Schicht ist alleine dafür verantwortlich, was in dieser Schicht passiert.
    Aber jede Schicht hat zwei Verträge, die nicht verhandelbar sind:
    Einen mit der "höheren" Schicht, einen mit der "tieferen" Schicht.
    Das nennen wir "Interface".
    Und in dem stellen diese Verträge die geringstmögliche Anzahl von Operationen dar, die zum Funktionieren nötig sind.
    Das sind letztlich lediglich Lesen und Schreiben (und ein paar "Verwaltungsakte".
    (Alle anderen Operationen setzen sich aus diesen zwei "Fundamentaloperationen" zusammen)


    Damit haben wir auch im einfachsten Fall einer stinknormalen Festplatte schon eine Treiberkette.
    Jede Schicht verfügt über zwei solcher Treiber: einen "für oben", einen "für unten".
    Ganz oben ist es völlig egal, wieviele solche Schichten übereinander gestapelt sind:
    Ganz oben gibt es ein paar Operationen (Lesen,Schreiben, Löschen, Neu anlegen, Verschieben), die wir anstossen.
    Was daraus in den unteren Schichten wird, kann uns völlig egal sein.
    Der durchgehend einzuhaltenden "Interfaceverträge" stellen sicher, dass die Bits irgendwie, irgendwo rumliegen.
    Und dass diese Bits, egal, wo sie rumhängen, bei einer Leseoperation wieder Schicht für Schicht so zusammengeklaubt werden,
    dass wir wieder die Datei sehen.


    Aus Sicht des Kernels gibt es zwei grundlegende Arten von Speicher: Einmal lokal zu bedienende Blockgeräte (wir schreiben immer Blöcke, sprich Sektoren bei Festplatten), und dann noch Speicher der über Netzwerk angeschlossen ist.


    Von beiden gibt es wiederum unzählig verschiedene Unterarten. Bei lokalen Speichergeräten kennen wir RAID, LVM, als "logische Geräte" und physikalisch Magnetbäner, Silberscheiben, Magnetplatten und neuerdings Chips, um nur die bekanntesten zu nennen.
    Bei "Netwerkspeicher" gibt es genauso unzählig viele verschiedene Methoden.
    Vielleicht ein Ceph-Cluster, bei dem eine riesige virtuelle Festplatte auf viele Rechner verteilt ist, und jeder Rechner für das gesamte Netzwerk einen Festplattencontroller spielt,
    oder etwas schlichter eine Freigabe auf einem anderen Rechner -sei das via CIFS (sprich Samba) angebunden oder über NFS (das NetzwerkFileSystem der Unixoiden).


    Uns ist das weiterhin völlig egal: Wir führen nur die paar grundlegenden Operationen aus.
    Ob der Stapel der Speichertreiber zwischendrin eine Netzwerkschicht hat, oder nicht, ist uns schnuppe.
    Everything is a file!


    Selbst wir User können uns solche virtuelle Geräte einfach erstellen: man mknod
    Wir können sogar einfach eine Datei auf der Festplatte basteln lassen, die wir dann selbst wiederum als Festplatte behandeln.
    Als root ein schlichtes mount -o loop /Pfad/zu/einer/isoDatei.iso /Pfad/zu/einem/Mountpoint/sprich/irgendein/Verzeichnis/
    und schwups können wir auf die Silberscheibe zugreifen, als wäre es eine eine normale (schreibgeschützte) Datei, die normal auf irgendeiner Partition rumhängt.
    Everything is a file!, auch Geräte. Daher der Name "Gerätedatei".


    Ob das iso nun wirklich eine Silberscheibe ist, oder als Datei auf einer normalen Parition rumliegt, ist völlig egal:
    Everything is a file!
    Lediglich dir Treiberketten unterscheiden sich.


    Das Mounten ist in gewisserweise das für das jeweilige Ziel korrekte Zusammenstellen einer solcher Treiberkette.
    Ich habe mal auf einem Server im $HOME eine komprimierte Archivdatei anlegen lassen, die via SSHFS (das SecureSHellFileSystem) als "Platte" lokal eingebunden war.
    Dort wurde diese "Verbindung" mit arfs (dem ARchiveFileSystem) in ein weiteres Verzeichnis gemountet. Und dieses Verzeichnis wurde dann noch in ein weiteres Verzeichnis gemountet, aber diesmal mit dem encfs (dem ENCryptedFileSystem).
    Obwohl ich in diesem letzten Verzeichnis ganz normal meine paar Operationen Lesen,Schreiben... ausgeführt habe, wurde tatsächlich auf einem anderen Rechner dort im $HOME ein komprimiertes Archiv, das verschlüsselt war, geschrieben und gelesen.
    Everything is a file!
    Nur die Treiberkette ist ein wenig länger, ein wenig komplizierter-


    Bei der Virtualisierung ist das nicht anders.
    Da der "Virtualisierer" den VMs (wie auch immer gearteten) Speicherplatz vorgaukeln muss, den die VMs dann als ihre "physikalischen Speicherplatten" sehen, tut jeder Virtualsierer auch genau das, was wir oben mit einer Isodatei gemacht haben: Er bindet mit irgendeiner Treiberkette irgendeinen Speicherplatz ein.
    Everything is a file!
    Bei Qemu/kvm erledigt das qcow (das QemuCopyOnWrite Filesystem) Format für die einzelne VMs.
    Der "Speicher- Pool" ist lediglich eine abstrakte Verwaltungsschicht, die aus vielerlei Arten von tatschächlichen Speichern (respektive verschiedenen Treiberkette) bestehen kann.
    Der Virtualisierer seinerseits, sieht nur einen Speicherpool. Und in dem mountet er seine einzelnen QCOWs.
    Egal, aus wievielen verschiedenen Treiberketten dieser Pool zusammengesetzt ist.


    Per Default hat bei openSUSE Qemu/kvm seinen Pool in /var/lib/libvirt/images
    Dort wird dann bei der Installation einer neuen VM eine neue qcow2 Datei für diese VM angelegt.
    Damit ist klar, dass der freie Speicher auf der Partition, auf der /var liegt maßgeblich ist, wie groß diese neue Maschine werden kann. (Oder um wieviel man eine solche qcow2 vergrößern kann.)


    Aber natürlich kannst du diesem Speicherpool jederzeit erweitern. Klicke einfach mal im virt-manager bei der Installation in dem Dialog "Speicherdatenträger auswählen" links unten auf den +Button. Dort kannst du dem Speicherpool weitere "Treiberketten" hinzufügen und damit den für die VMs vorhanden Speicherplatz erweitern. Egal, ob das auf irgendeinem Cluster im Netz ist, oder lokal auf einer USB Platte dümpelt.
    Wir wissen ja: Everything is a file!


    Letztlich muss auf dem Weg vom User zum Speicher nur eines sichergestellt werden: Egal, wie lange diese Treiberkette ist, egal, wieviele verschiedene Medien und Schichten zwischendrin werkeln: am anderen Ende muss eine tatsächliche physikalisches Gerät stehen, das dann auch wirklich speichert. In die hohle Luft können nicht einmal Linuxgötter speichern.
    Egal, wie kompliziert das sein mag: Wir schreiben und lesen nur.
    Sonst nicht.
    Everything is ja schließlich nur a file!

  • Danke @Berichtigung für diesen Express Kurs in "Everything is a file" um diese Uhrzeit. =O


    Wünsche mir natürlich von ganzem Herzen das es weder: "Zum Stundensatz von 180,-€ + MwSt. + Schmerzensgeld + Negerzulage" noch umsonst ist für mich! :)

    Systeminfo:


    Prozessor: 16 x AMD Ryzen 7 1800X. Board: ASRock KILLER SLI X 370. RAM: 32GB


    Grafik: NVIDIA® GeForce® GTX1060 6GB läuft mit dem Nouveau Treiber


    Betriebssystem: SSD: Leap 15.3 x64, Plasma 5.3.18-59.19-default

    Für den Inhalt des Beitrages 128577 haftet ausdrücklich der jeweilige Autor: Fritzle