Hallo Zusammen, nach dem ich mich jetzt einigermaßen tief in Debian eingearbeitet habe und die Umgebung soweit steht, habe ich seit gestern das Phänomen, das mein Speicher fast vollständig verwendet wird. Eigentlich wollte ich nur die VMs hochfahren und musste feststellen, dass schon die erste VM extrem lange zum starten brauchte und sich nicht flüssig bedienen ließ. Da ich gestern Abend noch damit gearbeitet hatte und alles ok war komme ich aktuell nicht mehr weiter. Was haben wir gemacht: 1. alle VMs vom NAS auf den SSD der Rechners kopiert. 2. alle Maschinen nacheinander hochgefahren und alle aktuell notwendigen Updates eingespielt. Bis zu diesem Zeitpunkt wahr alles ok, die VMs liefen geschmeidig und alles war gut. Anschließend: 1. VMs runter gefahren, defragmentiert und Optimierung durchgeführt. 2. alle Maschinen wieder auf den NAS gespielt als Backup. Da dieser Vorgang durch die Größe von 470GB ein wenig dauert, lasse ich das über Nacht laufen. Heute Morgen habe ich die Maschine einmal durchgestartet und wollte anschließend die VMs hochfahren. Seit dem, habe ich ein ganz merkwürdiges Speicherverhalten s. angehangenes Bild das ich mir nicht erklären kann und die VMs sind nicht bedienbar. Ich gehe davon aus das das Problem mal wieder 42cm vor dem Monitor sitzt aber ich komme nicht weiter. Ich gehe allerdings davon aus, dass da irgendetwas im Hintergrund läuft, was ich nicht sehe. Tools: 1. VMWare Workstation pro 16 2. FreeFileSync Danke für jeden Tipp Gruß Frank
Angehängte Dateien:
-
Speicherauslastung.PNG
730 KB
Wieviel RAM genehmigen sich denn Deine VMs lt. Config? Der RAM wird bei einem Linux (wie auch Windows) immer möglichst komplett genutzt. Zwar nicht unbedingt für die Anwendungen, sondern als Filecache (zumindest nach einiger Zeit mit rel. viel an IO). In Deinen Screenshots ist ja noch einiges frei, und Swap wird auch nicht benutzt - kann also nicht die Ursache sein, sondern irgendwas anderes.
Hallo Jens, aktuell läuft keine VM! Die VMs sind auf 16GB Speicher eingestellt und liefen bis gestern Abend einwandfrei und ich war mit dem System auch super zufrieden. Heute Morgen wollte ich die Maschinen lediglich hochfahren und musste feststellen, dass nichts ging. Interessant war, das VMware mich beim Hochfahren der ersten VM nach einem mindestens 8GB großem Swapfile gefragt hat. Das Bild zeigt das System ohne das auch nur eine VM gestartet ist bzw. nur die Anwendungen die auf dem Bild sichtbar sind laufen. Allerdings habe ich gestern ein wenig mit XFCE experimentiert, da mir die Schriftgröße auf einem 4K Display in Verbindung mit meinem 15" Notebook einfach zu klein war. Hier habe ich aber lediglich die DPI Zahl hoch gesetzt. Für mich sieht es so aus als wenn da "unsichtbar" eine Session läuft die ich nicht sehen kann. Ich war zum Zeitpunkt als ich die Bilder gemacht habe als "root" per RemoteDesktop angemeldet. Auf dem Rechner selber auch als "root" angemeldet erhalte ich die gleiche Speicherverteilung. Als Administrator auf dem Rechner direkt angemeldet sehe ich auch keine laufende Anwendung. Gruß Frank
Aus dem Bild ist kein Problem ersichtlich. Die Anwendungsdaten belegen nur 4 Prozent. Das die verschiedenen Festplattenpuffer 66% belegen ist unkritisch und sogar gut denn für ungenutzten Speicher gibt es kein Geld zurück. Sobald die Anwendungen mehr Speicher benötigen werden die Puffer automatisch verkleinert. Bei VMWare bin ich unsicher aber ich denke aus Sicht des Hosts sind das normale Anwendungen. Daher sollten sich 3 VMs mit je 16 GB starten lassen ohne dass er überhaupt den Swap anfassen muss. Nebenfrage, warum verwendest du überhaupt VMWare und nicht das Linuxeigene KVM?
Blechbieger schrieb: > Daher sollten sich 3 VMs mit je 16 GB starten > lassen ohne dass er überhaupt den Swap anfassen muss. Genau so funktioniert das auch, in Ubuntu, wenngleich eine VM mit voll genutzten 16 GB sich etwas mehr als diese 16 GB genehmigt. Da kommt noch der Overhead der Virtualisierung dazu. Zu beachten ist die I/O-Last. Zumindest bei VMware Player/Workstation in Windows auf HDD habe ich die Erfahrung gemacht, dass eine VM mit hoher Disk-Last den Rest bei Zugriff darauf ziemlich ausbremsen kann.
:
Bearbeitet durch User
Blechbieger schrieb: > Bei VMWare bin ich unsicher aber ich denke aus Sicht des Hosts sind das > normale Anwendungen. VMware hat auch Module im Kernel laufen.
:
Bearbeitet durch User
(prx) A. K. schrieb: > VMware hat auch Module im Kernel laufen. Die könnten auch das Problem sein. Beim Start gestern waren die nach der Installation schon geladen, alles lief schnell. Dann: Frank L. schrieb: > Heute Morgen habe ich die Maschine einmal durchgestartet Jetzt fehlen die Module evtl. Wenn VMware dann nicht paravirtualisiert sondern als Komplett-Emulation läuft, würde es erklären, warum heute alles furchtbar langsam ist.
Εrnst B. schrieb: > Wenn VMware dann nicht paravirtualisiert sondern als Komplett-Emulation > läuft, würde es erklären, warum heute alles furchtbar langsam ist. Kann es das überhaupt? > Jetzt fehlen die Module evtl.
1 | $ lsmod|grep "^vm" |
2 | vmnet 53248 9 |
3 | vmw_vsock_vmci_transport 32768 0 |
4 | vmw_vmci 69632 1 vmw_vsock_vmci_transport |
5 | vmmon 114688 0 |
:
Bearbeitet durch User
NB: Welches Programm liefert die Systeminformation im Bild links oben?
Angehängte Dateien:
-
SpeicherAuslastung.PNG
240 KB
Hallo A.K. die Info habe ich über das KDE-Infozentrum ermittelt. Ich habe allerdings eben mal den Rechner nicht direkt an der Hardware neu gestartet sondern über den RemoteDesktop "Rechner neu starten" ausgewählt. Jetzt passen die Zahlen wieder. Keine Ahnung, wo der Zusammenhang ist. Ich kann da nur vermuten... Aber vielleicht hat sich XFCE die verschiedenen Sessions irgendwo gemerkt und ich habe versehentlich mehrmals die VMs gestartet was den Speicherverbrauch erklären würde. Aber keine Ahnung und davon ganz viel :-) Insgesamt, wenn man jetzt mal von den Kinderkrankheiten aus Unwissenheit absieht, bin ich von der mehr oder weniger einfachen Installation ganz angetan. Wir hatten gestern mal einen Lasttest laufen, der alle drei VMs in denen jeweils eine SharePoint Instanz (2013, 2016 und 2019) werkelt mit HTTP Zugriffen bombardiert. Die Zugriffszeiten und die Zuverlässigkeit waren gegeben. Die Reaktionszeiten waren nicht besser oder schlechter als bei unserem bisherigen Host System Windows 2019 Server. Wir werden das System jetzt mal eine Zeitlang beobachten und damit arbeiten und sehen wie es läuft. Wenn alles glatt läuft, werden wir die anderen 3 Maschinen ebenfalls auf Debian als HOST Betriebssystem umstellen. Wobei wir parallel noch ein VM aufsetzen werden um zu schauen in wie weit wir auch einen Teil unserer Entwicklermaschinen umstellen können. Gruß Frank P.S. Wenn mir jemand den Unterschied von Screenshot 1 zu Screenshot 2 erklären könnte, wäre ich dankbar.
:
Bearbeitet durch User
Frank L. schrieb: > Wir hatten gestern mal einen Lasttest laufen, der alle drei VMs > in denen jeweils eine SharePoint Instanz (2013, 2016 und 2019) werkelt > mit HTTP Zugriffen bombardiert. Für sowas ist eigentlich VMware ESXi gedacht, nicht die Workstation. Obendrein billiger (lies: kostenlos), wenn man keine Ansprüche an erweiterte Features und ans Management hat.
:
Bearbeitet durch User
Frank L. schrieb: > P.S. Wenn mir jemand den Unterschied von Screenshot 1 zu Screenshot 2 > erklären könnte, wäre ich dankbar. Frisch gestartet (2) vs schon deutlich verwendet (1). Der erste hat viel Disk-Daten im Cache, der zweite praktisch nichts.
:
Bearbeitet durch User
Frank L. schrieb: > P.S. Wenn mir jemand den Unterschied von Screenshot 1 zu Screenshot 2 > erklären könnte, wäre ich dankbar. Im zweiten Screenshot wurde der Rechner wirklich neu gebootet. Der erste Screenshot zeigt einen Rechner, der schon eine gewisse Arbeit hinter sich hat (schon gut gefüllter Filesystem Cache). Vielleicht haste den Rechner ja zur Problemzeit gar nicht neu gestartet, sondern nur mal zwischendurch schlafen gelegt, was dem evtl. nicht ganz gut bekam ... Denn was soll denn sonst der Unterschied sein zw. Restart via Remote Desctop oder direkt an der Hardware.
:
Bearbeitet durch User
Hallo A.K. wie kommst Du darauf, das VMware ESXi kostenlos ist? Das Produkt gibt es nur in Zusammenhang mit vSphere und das ist alles andere als kostenlos. https://www.vmware.com/de/products/esxi-and-esx.html Aber vielleicht hast Du noch eine andere Quelle. Mir ist es bisher nicht gelungen ESXI von den offiziellen Seiten herunter zu laden. Gruß Frank
Frank L. schrieb: > wie kommst Du darauf, das VMware ESXi kostenlos ist? Weil es laut Aussage von VMware auch in 7.0 immer noch eine dauerhaft einsetzbare kostenlose Version gibt. Registrierung ist aber nötig. Natürlich kriegst du umso mehr, je mehr du zahlst. https://my.vmware.com/de/web/vmware/evalcenter?p=free-esxi7 HOWTO und Einschränkungen: https://www.altaro.com/vmware/esxi-free/ Wenn die Kiste ein echter Server ist, kein 08/15 PC, gibt es u.U. ESXi ISOs vom Hersteller, die weitere Treiber für deren Hardware drauf haben. Ob free oder nicht ergibt der Lizenzschlüssel, nicht das Image.
:
Bearbeitet durch User
Frank L. schrieb: > P.S. Wenn mir jemand den Unterschied von Screenshot 1 zu Screenshot 2 > erklären könnte, wäre ich dankbar. In beiden Fällen sind 1,4/1,6 gb-RAM belegt. No Swap. Was auch durch die Prozessauflistung (übern Daumen) bestätigt wird! Im ersten Fall könnte es sich (RAM = 64gb ?? ) a) um einen Aktualisierungsfehler handeln (unwahrscheinlich) da die Anwendungsdaten im RAM (blau) nur ~4%/2,6gb belegen (statt 1,4gb) das beweist auch der Taskmanager- 285 Prozesse = 4%!! jedoch: 66% auf Festplatte (grün) liegen - und nicht im RAM! b) Hast irgendwas installiert ? oder laufen gehabt, was weiterhin im Speicher gehalten wurde. Das bleibt solange drinnen, bis es gelöscht wird. Dazu gehören auch diese un-/genutzten +1,1gb-RAM. Bei anderen Distros ist es jedenfalls so, daß im RAM auch Speicherplatz für Prozesse unnachsichtig reserviert wird. So ergeben sich (zeitweise) gewisse Unterschiede in div.'Darstellungen' . c) ich glaube, daß du nur "GRÜN" übersehen hast, und zu Unrecht in Aufruhr versetzt worden bist. Ich kenn zwar weder debian noch VM, aber prinzipiell..
Oder anders ausgedrückt: Im ersten Bild sind 1,4gb-RAM in Benutzung, der Rest von +1,1gb ist bereits 'frei', wird aber gelöscht, sobald 'Bedarf' ist. Das kann bei 96%-FREE aber ziemlich lange dauern .
Dann fährst die Maschine hoch, die alten Prozesse sind futsch - und die neuen Prozesse belegen w i e d e r u m eben --NUR-- die ~1,5gb und dann wächst das wieder an. Reserviert also VMware Speicher, tut das debian, bis VMware den Befehl zum 'Löschen' gibt. Oder VMware beendet wird.... ? Kopierst in windoof was übers Clipboard, bleibt das ebenfalls solange im Speicher , bis es gelöscht wird. Viele Programme fragen beim Beenden danach: Löschen ? Linux ist eben seltsam. Manche Dinge sind (oft) hart am Gerade-Noch-Erträglichen. In den meisten Fällen ist es einfach "maßlos Über-Informativ" .
Poste mal die Ausgaben zu relevanten Zeitpunkten ps aux --sort -vsz | head -n8 ps aux --sort -rss | head -n8 sar -rBS 5 3
(prx) A. K. schrieb: > Wenn die Kiste ein echter Server ist, kein 08/15 PC, gibt es u.U. ESXi > ISOs vom Hersteller, die weitere Treiber für deren Hardware drauf haben. > Ob free oder nicht ergibt der Lizenzschlüssel, nicht das Image. Ist die Treiberunterstützung von VMWare wirklich so schlecht?
Warum um alles in der Welt benutzt man VMWare auf einem Linux? Diese externen Lösungen ( ebenso wie Oracle's VirtualBox) machen nur Probleme weil sie selten gut mit der gerade benutzen Kernelversion zusammenspielen. Für VMs unter Linux nutzt man KVM. Das geht am einfachsten über "libvirt" zu konfigurieren und integriert sich hervoragend ins System: https://wiki.debian.org/KVM Wehr grafische Verwaltungstools mag, dem sei das paket "virt-manager" empfohlen. Kritisch im ersten Screenshot würde ich den Bereich "Festplatten-Pufferspeicher" sehen. (Dirty-Pages) Dabei handelt es sich um Daten die noch auf die Festplatte geschrieben werden müssen. Das sieht für mich extrem viel aus. Könnte es sein, das die vmware Module hier ihre Finger im Spiel haben? Bei einer KVM Virtualisierung wird standardmäßig kein Schreibcache benutzt. Die Emulation verhält sich da wie eine echte Platte, ein Schreibvorgang wird erst dann zur VM bestätigt, wenn die Daten auch wirklich auf der Platte im Image liegen. Zu den Dirty Pages: Bei Standardeinstellung fängt Linux bei 10% an diese Daten auf die Platte zu schreiben (im Hintergrund). Ab 20% wird jeder Schreibvorgang syncron durchgeführt, der Process wird also angehalten bis die Daten wirklich auf der Platte sind. Letzlich geht es darum Datenverluste bei Stromausfall zu verhindern. 20% von 64GB sind immerhin 13GB, dafür braucht auch einen SSD einige Zeit. Es könnte sein das die vmware VMs bei Dir gerade dadrinnen hängen. Diese Parameter kann man aber einstellen, Stichworte "dirty_ratio", "dirty_background_ratio". Gerade bei VMs muss man sich damit auseinandersetzten.
Andreas M. schrieb: > Warum um alles in der Welt benutzt man VMWare auf einem Linux? Das Thema hatten wir im Ursprungs-Thread ( Beitrag "Suche Linuxdistribution für X570 AMD Chipsatz" ) schon. "Weil die offizielle Lizenz vorhanden ist". Wär ja schade, die teure Software ungenutzt zu lassen :-/
Andreas M. schrieb: > 20% von 64GB sind immerhin 13GB waren aber 40% Puffer , also 25gb (von 470gb) plus 26% Cache = 66% Vielleicht is ja die SSD in der Nacht hinich geworden. Hab mir auch so ein Glump gekauft, 33h und 209 Starts. Ende .
Frank L. schrieb: > Aber vielleicht hast Du noch eine andere Quelle. Mir ist es bisher nicht > gelungen ESXI von den offiziellen Seiten herunter zu laden. https://my.vmware.com/en/web/vmware/evalcenter?p=free-esxi7 Das ist der "freie", die sog. "Enterprise Plus"-Features darin sollte man aber nicht verwenden, weil die sind eine Testversion. Hier gibt es den Microsoft Hyper-V Server 2019, den ich für "kostenlose Virtualisierung" echt besser finde als Free-ESXI: https://www.microsoft.com/en-us/evalcenter/evaluate-hyper-v-server-2019 KVM und die meisten darum gebauten Toolsets sind, bei guter Konfiguration, echt gut, aber auch leider sehr verstrickt und komplex in der Verwaltung. VMWare Workstation ist eine Krücke und wonirgends gut. Aber das hatten wir ja schon im anderen Thread.
Angehängte Dateien:
-
_TheGoldOld.jpg
110 KB
Sorry! 'das ist ein 'Client-Fenster' und kein normales Fenster.
Rudi Ratlos schrieb: > waren aber 40% Puffer , also 25gb (von 470gb) > plus 26% Cache = 66% Mein Rechnung war auf die Standardwerte vom Linux bezogen. Ja hier sind es 40%. Das ist nicht normal. Ich gehe davon aus, dass das mit der VMWare zusammenhängt. > Vielleicht is ja die SSD in der Nacht hinich geworden. Dann würde gar nichts mehr gehen. > Hab mir auch so ein Glump gekauft, 33h und 209 Starts. Ende . Welches Modell? Das ist mir noch nie passiert, allerdings kaufe ich bei Platten auch nie den Gamerschrott mit den hochtrabenden Namen. Win95/98 können allerdings mit SSDs nicht wirklich umgehen, z.B. das TRIM Kommando. Deine ST-Platte würde ich mal tauschen: "Unkorrigierbare Sektoren: 1" Das ist normalerweise der Anfang vom Ende. [Edit]: Jetzt sehe ich erst was Du mit den 40% meinst. Die Beziehen sich auf den RAM, nicht auf die Platte.
:
Bearbeitet durch User
Εrnst B. schrieb: > Andreas M. schrieb: >> Warum um alles in der Welt benutzt man VMWare auf einem Linux? > > Das Thema hatten wir im Ursprungs-Thread ( > Beitrag "Suche Linuxdistribution für X570 AMD Chipsatz" ) schon. > > "Weil die offizielle Lizenz vorhanden ist". > > Wär ja schade, die teure Software ungenutzt zu lassen :-/ Hmm. Eine schlechte, unperformante Software einsetzen und deren Probleme in Kauf nehmen weil man sie schon bezahlt hat, obwohl es eine (kostenfreie) bessere Alternative gibt? Naja, jeder darf sich das Leben natürlich so schwer machen wie er mag :-)
Andreas M. schrieb: > Mein Rechnung war auf die Standardwerte vom Linux bezogen. Habs mir eh gedacht. Viel gelernt von dir, froh auch: debian läuft jetzt auch auf K. ? Ich hasse GNOME. > Dann würde gar nichts mehr gehen. Meine hat nur zu schreiben aufgehört. Lesen alles normal, 'schreibt' auch, aber am Ende ist jedesmal nix drauf. Läßt sich auch jetzt nicht mehr partitionieren . War eine Intenso-TOP (128gb), war zuerst für ASRock (35-50 Starts), dann dieses Biostar mit "Gaukel-UEFI" ( Beitrag "CPU-Kühler-Umbau (aktiv-passiv)" ), Root-Dateisystemfehler . Ende . SMART-Status : SSD versagt komplett innerhalb von 48h. > TRIM Kommando. Dieses TRIM muß ich mir jetzt mal "anschauen", was das genau is. Auch der Raspi ist plötzlich völlig am: Ende. Jetzt muß ich endlich mal 'modernisieren ', keine andere Lösung. > Win95/98 können allerdings mit SSDs nicht wirklich umgehen auf w2k auf P4 läufts auch nicht, wird auch via USB pausenlos ausgeworfen. > Deine ST-Platte würde ich mal tauschen: "Unkorrigierbare Sektoren: 1" Das war schon vor über 1 Jahr. Hab ich auf "2 Sektoren" korrigiert. Gut aufgepaßt ! Genug neue HDD ... > [Edit]: Jetzt sehe ich erst was Du mit den 40% meinst. Die Beziehen sich > auf den RAM, nicht auf die Platte. Das ist Linux. Auskünfte? kriegt man so gut wie nirgends, die meisten kennen sich ja selbst auch nicht aus. Es ist ein sehr! individuelles, sehr komplexes, sehr spezielles System. Entweder man wird selbst zum Linux-Chef - oder man holt sich gleich den RedHat-, Ubuntu-, Suse-, debian -Support ins Haus. LINUX, frei nach : Das geht DICH einen Scheiß an, was ich da -auf meinem PC- mache. Oder wie 'das da' funktioniert... Die See-Ei-äh ist immer und überall. Alles! sehr geheim und komplett undurchsichtig .
Dentaa schrieb: > Ist die Treiberunterstützung von VMWare wirklich so schlecht? Die Unterstützung herstellerspezifischer Komponenten wie System-Management und von Adaptern mit herstellerspezifischer PCI-ID ist nicht notwendigerweise enthalten. Das hat u.A. auch damit zu tun, dass die maximale Grösse vom Boot-Image limitiert ist und deshalb schlicht nicht alles reinpasst, was jemals rauskam. Ausserdem kriegt man auf diese Art deutlich einfacher ein von VMware zertifiziertes System zustande. Abhängig vom Serverhersteller können verschiedene Treiberversionen für den gleiche Adapter zertifiziert sein. Und das merkt man spätestens beim Supportcall.
Christian F. schrieb: > Hier gibt es den Microsoft Hyper-V Server 2019, den ich für "kostenlose > Virtualisierung" echt besser finde als Free-ESXI: Seit wann ist ein Windows-Server kostenlos? (Server, weil Vergleich mit ESXi)
:
Bearbeitet durch User
(prx) A. K. schrieb: > Seit wann ist ein Windows-Server kostenlos? Hyper-V Server war schon immer kostenlos, auch die vorigen Versionen. Es ist halt keine Lizenz dabei um Windows in VMs laufen zu lassen.
Rudi Ratlos schrieb: > War eine Intenso-TOP (128gb), war zuerst für ASRock (35-50 Starts), dann > dieses Biostar mit "Gaukel-UEFI" ( Na dann wunderts mich nicht. SSD sollte man von denen kaufen die auch selbst Flashspeicherchips herstellen. Ich verbaue nur Samsung oder Intel. Von denen ist noch keine einzige Ausgefallen. Wobei die älteste gerade mal 5 Jahre sein wird. Rudi Ratlos schrieb: > Auch der Raspi ist plötzlich völlig am: Ende. Jetzt muß ich endlich mal > 'modernisieren ', keine andere Lösung. Das liegt am falschen Dateisystem der Standardimages. Das ist komplett ungeeignet für SD Karten. Damit ein Raspi lange läuft braucht man eine größere ( mind. 32GB ) und gute SD Karte. Außerdem muss man das F2FS Dateisystem verwenden, dieses ist speziell für MMC Speicher (wie es eine SD-Karte ist) ausgelegt. Dazu sind diverse Stellen zu konfigurieren um die Schreibzugriffe etwas zu minimieren. Ich habe eine selbstgebaute Wildkamera (Vogelhaus)auf Raspi Zero Basis. Die läuft durchgängig seit zwei Jahren, nur im Frühjahr hatte ich mal ausversehen den Strom abgeschaltet. Die zeichnet jede Woche mehrere GB an Videomaterial auf. (Altes wird automatisch entsorgt) Rudi Ratlos schrieb: > Das ist Linux. Auskünfte? kriegt man so gut wie nirgends, die meisten > kennen sich ja selbst auch nicht aus. Es ist ein sehr! individuelles, > sehr komplexes, sehr spezielles System. Nö eigentlich nicht. Allerdings arbeite ich damit auch schon gut und gerne 20 Jahre :-). Für mich ist Windows ein undurchsichtiges "System", eigentlich ist es für mich eine Krankheit. Das letzte halbwegs brauchbare Windows war Windows 7. Unverständlich für mich warum Windows 10 kommerziell eingesetzt wird. Jeder Boot ist ne Wunderkiste, man wies nie was das nächste Update so für Überraschungen gibt. Rudi Ratlos schrieb: > LINUX, frei nach : Das geht DICH einen Scheiß an, was ich da -auf meinem > PC- mache. Oder wie 'das da' funktioniert... Die See-Ei-äh ist immer > und überall. Alles! sehr geheim und komplett undurchsichtig . Nein das stimmt so nicht. Die meisten Dinge sind gut dokumentiert. Du kannst dir von allem den Quellcode besorgen und durchlesen. Es gibt halt oft keine grafische Oberfläche zum Einstellen und die schier unendliche Anzahl an Konfigurationsparametern lässt einen Anfangs verzweifeln, aber das ist alles Übungssache. Man muss ja auch nicht an allem rumdrehen. Ganz im Gegensatz dazu hast du bei Windows gar keinen Einblick was innen passiert. Und was die ganzen Registrykeys bedeuten ist nirgends allumfassend dokumentiert. An der Oberfläche bekommst halt nur die "wichtigsten" Einstellungen zu sehen. Übrigens sieht Microsoft Windows ab Windows 10 eigentlich nicht mehr als eigenständiges Betriebssystem. Lt. Nutzungs/Lizenzbedingunen ist Windows 10 nur ein Fortsatz der Microsoft Cloud. Microsoft erlaubt dir gnädigerweise diesen Fortsatz auf deiner eigenen Hardware auszuführen. Da sieht man wo der Weg hingeht. [EDIT]: Falsches Dateisystem korrigiert
:
Bearbeitet durch User
Andreas M. schrieb: > Lt. Nutzungs/Lizenzbedingunen ist Windows 10 nur ein Fortsatz der > Microsoft Cloud. Microsoft erlaubt dir gnädigerweise diesen Fortsatz auf > deiner eigenen Hardware auszuführen. Na guate Nacht! Ohne OEM-PC -Verträge wäre MS eh schon lange am Ende. Outside Web bleibe ich weiter bei w98se. Klein, fein, mein. Raspi: 'Undervoltage detected!' - Ende. Spannungsregler am Board seit 'Anbeginn' defekt . Ich sehe, wir verstehen uns ! > kannst dir von allem den Quellcode besorgen und durchlesen. Sind ja nur 18 Trilliarden Seiten ... zum Glück ! Nur wer 'das kali' besiegt , kann von der Göttin Kali ncht mehr verschlungen werden.
(prx) A. K. schrieb: > Die Unterstützung herstellerspezifischer Komponenten wie > System-Management und von Adaptern mit herstellerspezifischer PCI-ID ist > nicht notwendigerweise enthalten. Das hat u.A. auch damit zu tun, dass > die maximale Grösse vom Boot-Image limitiert ist und deshalb schlicht > nicht alles reinpasst, was jemals rauskam. Linux kriegt das hin.
Dentaa schrieb: > Linux kriegt das hin. Hat ESXi nicht so einen Linux-Simulations-Kernel-Teil, damit Linux-Treiber auch für ESXi verwendet werden können?
Dentaa schrieb: >> die maximale Grösse vom Boot-Image limitiert ist und deshalb schlicht >> nicht alles reinpasst, was jemals rauskam. > > Linux kriegt das hin. Das hat mit Linux nichts zu tun. ESXi ist kein Linux, und dessen Boot-Flash (USB, SDcard) war vor 7.0 auf 2GB limitiert, egal wie gross das Teil war.
:
Bearbeitet durch User
Εrnst B. schrieb: > Hat ESXi nicht so einen Linux-Simulations-Kernel-Teil, damit > Linux-Treiber auch für ESXi verwendet werden können? Auch das. Auf den gängigen Servern (HP, Dell, Lenovo, ...) gibt es kein Problem mit der Verfügbarkeit von Treibern. Nur gab es vor 7.0 ein Platzproblem, wenn alle möglichen Treiber aller Hersteller aller ... zusammen mit dem ESXi in 2 Versionen in 2GB passen sollten.
:
Bearbeitet durch User
Hallo Zusammen, nur ein Statement von mir zu all den Hinweisen. Vielen Dank dafür. Ich habe das System heute nochmal komplett platt gemacht und werde kvm testen. Die Ergebnisse mit VMWare sind ernüchtern! Wobei es nicht an der Performanz liegt. Aus irgend einem Grund zieht sich der Speicher mit jeder Anmeldung per RDP immer weiter zu obwohl ich den User immer korrekt abmelde. Aber ich habe keine Lust das weiter zu recherchieren. Gruß Frank
Wie zuzieht ? Festplatten-Zwischen und -Puffer-Speicher wachsen an? Also je öfter sich jemand anmeldet, desto mehr Disc-Daten werden im RAM dauerhaft zwischengespeichert? Und wenn sich der User abmeldet, löscht VM im RAM gar nichts ? Das deutet dann aber auf eine fehlerhafte VM-Einstellung hin. (? ) Ich habe mir ursprünglich gedacht, daß bei der DeFragmentierung irgendwas nicht geschrieben wurde, deshalb zurückblieb - der Rechner in den Deep-State ging - und dir daher !einige! Dateien auf Festplatte fehlen. Ich persönlich würde da nicht so schnell aufgeben. Unabhängig von KVM; Sonst gehst unter bei Linux ! Ich hab schon mehrere Linux-Nächte mit Tränen in den Augen verbracht ... aber wenn du es geschafft hast- lachst. Bis zur Nächsten Nacht !
Knalls nochmal schnell -drauf, und laß den DeFragmentier-Scheiß!
Letztendlich Frage, was bewirkt das? Ich würde sagen, richte für VM mal einen 'swap' ein, wo es seine dämlichen ScheißDaten hinschreiben kann, ohne daß es jemand im RAM stört . Das ist ja das alte windoof-Problem, jeden Scheiß muß es auf Platte schreiben, und der RAM ist völlig leer. Also entweder schreibt VM das -nun- direkt in den swap, der ?10gb! ist aufgrund der bisherigen Datenmenge (60gb+) sowieso v i i i i e l zu klein, --das-- aber muß man erstmal irgendwo konfigurieren, oder auch direkt in eine eigene (100-200gb) (NTFS-?)VM- TEMP-Partition .
Hallo Rudi, ja so in etwa kann man es beschreiben. In meiner ersten Grafik die ich gepostet hatte, steht der physische Arbeitsspeicher (blau) auf 63% und das System verhält sich auch so. Zu diesem Zeitpunkt ist keine VM gestartet. Wohl, hatte ich eine zu dem Zeitpunkt mal hochgefahren hatte und alle Updates für Windows 2019 Server und SharePoint 2019 installiert wurden. Nach den Updates wird die VM runtergefahren und auf dem NAS gesichert. Um sie anschließend wieder hochzufahren. Das Bild zeigt genau diesen Zeitpunkt. Angemeldet war ich immer über den Windows Remote Desktop am LINUX. Ein anmelden auf der VM klappt immer und führt auch nicht zu großartigen Veränderung am Speicher. Der Taskmanager von Windows in der VM zeigt mir auch nur die erwarteten Daten zur Speicherauslastung und CPU Nutzung an. Da ist alles ok. Die VM läuft mit den gleichen Einstellungen wie auf meinem Windows 2019 Server Host. Das Thema kvm hat sich auch gerade erstmal erübrigt. Trotz Konvertierung nach raw bzw. in das andere Format, habe ich es bisher nicht geschafft die VM mit SharePoint 2019 ans Rennen zu bekommen. Ich erhalte die Fehlermeldung: no boot device oder so ähnlich. Jetzt habe ich erstmal keine Lust mehr. Ich werde die VMs garantiert nicht neu bauen! Gruß Frank
Rudi Ratlos schrieb: > und laß den DeFragmentier-Scheiß! Linux füllt den RAM solange auf, bis er überläuft. Dann erst kommt der swap. Hast du genug RAM?? läuft Linux als "RAM-Disk" ,dann brauchst auch keinen swap mehr. So, jetzt geh ich nähen ..
Hallo Rudi, das swap file für VMWare war eingerichtet. Das sind die 8,55GB ganz rechts. Ich werde es nochmals an testen und berichten. Diesmal ausschließlich auf der physischen Maschine. Gruß Frank
Rudi Ratlos schrieb: > Rudi Ratlos schrieb: > Linux füllt den RAM solange auf, bis er überläuft. Dann erst kommt der > swap. Ähm, nicht ganz. ›/proc/sys/vm/swappiness‹ bestimmt ab wann langsam mit dem swap System gearbeitet wird.
Frank L. schrieb: > das swap file für VMWare war eingerichtet. dann funktioniert irgendwas nicht. Da sind --ultraschnelle-- riesige Puffer und Zwischenspeicher, zwischen diesen beiden wird im Betrieb pausenlos hinundherkopiert. > Ich werde es nochmals an testen und berichten. Laß mal die 'Maschinen' mal auf Hochlast laufen und wart, bis der RAM überläuft . Je nachdem was du da genau machst, lassen entweder die 'Festplatten' den überlaufen, zuerst vmtl der Schreib-Cache , danach der 'Puffer', oder umgekehrt, überprüfen , oder die VM-Multi-Prozesse verschlingen den RAM. AM BESTEN IST , du läßt den RAM immer -randvoll laufen-. Weil sonst is nix mit deiner (s.o.) gelobten "VM- Performance" mit 64 gb RAM ! Ich habs mit makulu und mageia nie geschafft, trotz youtube-Stunden, über 2,7gb hinauszukommen. !Swap? hab ich seit Jahren keinen, reine Platzverschwendung . ---- # Sehe gerade, wir haben gleichzeitig gepostet: # > und auf dem NAS gesichert. Das Bild zeigt genau diesen Zeitpunkt. Also sind das doch übriggebliebene Daten fürs NAS ? War das nach dem Hochfahren, würde ich ggfs. > die SSD checken. > Arbeitsspeicher (blau) auf 63% und das System verhält sich auch so. Wie genau 'so' ? sind doch noch 20gb RAM frei ! Wieviel brauchen denn diese Maschinen? Du mußt permanent diese (2-3) Linux-Fenster (Bild 1) beobachten, was passiert wann genau, wenn du: was tust ? Was der Task'manager' dir nebenher anzeigt ist doch nur Windoof. Eines Tages wirst dieses Schimpfwort begreifen. Ehrenrettung? Ich habe mit w2k ein Visual-C++.net (2003) gekauft, da war eine Bonus- "MSDN"-DVD dabei, mein lieber Schwan, da gehts runter in den win-OS-Keller, das glaubst nicht. Schlimmer als 'man -k Norbert schrieb: > Ähm, nicht ganz. ›/proc/sys/vm/swappiness‹ bestimmt ab wann Klar, auch das kann 'man -k' einstellen.
Frank L. schrieb: > Das Thema kvm hat sich auch gerade erstmal erübrigt. Der einzige Unterschied zwischen Windoof und Lin-Unix ist, bei Ersterem bist und bleibst ein konfiguriertes Lizenz-Würschtel beim Zweiten k a n n s t Dein eigener Herr werden - und bleiben. Aber: Was ist das Beste für mich ? https://distrowatch.com/search.php?ostype=All&category=All&origin=All&basedon=All¬basedon=None&desktop=All&architecture=All&package=All&rolling=All&isosize=All&netinstall=All&language=All&defaultinit=All&status=Active#simple bevor du die geladene Flinte ins Korn wirfst.
Hallo Frank, ich möchte dich hier nicht persönlich angehen, aber ich habe das Gefühl, Du bist mit der Aufgabe einfach überfordert: Frank L. schrieb: > In meiner ersten Grafik die ich gepostet hatte, steht der physische > Arbeitsspeicher (blau) auf 63% und das System verhält sich auch so. Zu > diesem Zeitpunkt ist keine VM gestartet. Wohl, hatte ich eine zu dem > Zeitpunkt mal hochgefahren hatte und alle Updates für Windows 2019 > Server und SharePoint 2019 installiert wurden. Löse Dich bitte endlich von der Vorstellung eines "freien" RAMs. Ein Linux System bei dem nach einer entsprechenden Nutzungsdauer nicht der gesamte RAM in Verwendung ist, hat entweder mehr RAM als Festplattenspeicher oder das Caching wurde abgeschaltet. Der Linuxkernel verwendet sämtlichen verfügbaren RAM, der nicht von Anwendungen belegt ist immer als Festplattencache. Kurz nach dem Systemstart ist der Cache noch klein (2. Screenshot) weil bis dahin nur wenig Daten von der Festplatte geladen wurden. Jedesmal wenn Daten von der Platte geladen werden, wird davon eine Kopie im RAM gespeichert und der Cache wird größer. Wenn eine Anwendung RAM anfordert und kein weiterer ungenutzter RAM verfügbar ist - und nur dann - wird der Festplattencache wieder verkleinert damit die Anwendung bedient werden kann. Windows macht das übrigens genauso. Nur wird im Taskmanager der Festplattencache grafisch nicht berücksichtigt. Frank L. schrieb: > Das Thema kvm hat sich auch gerade erstmal erübrigt. Trotz Konvertierung > nach raw bzw. in das andere Format, habe ich es bisher nicht geschafft > die VM mit SharePoint 2019 ans Rennen zu bekommen. Ich erhalte die > Fehlermeldung: no boot device oder so ähnlich. Jetzt habe ich erstmal > keine Lust mehr. Ich werde die VMs garantiert nicht neu bauen! Das war zu erwarten, die Plattenkonfiguration unter KVM ist vermutlich anders und damit fällt der Bootloader vom Windows auf die Nase. Ein Umzug von einer Virtualisierungslösung zur anderen ist je nach der ursprünglichen Konfiguration wie ein Mainboardtausch vor 20 Jahren. Der größte Knackpunkt sind die Festplattentreiber und die Windowsaktivierung. Typischerweise kommen die verschiedenen Virtualisierungslösungen mit ihrer eigenen (optimierten) Treibervariante daher, die alle zueinander inkompatibel sind. Bevor man irgendwas konvertiert muss man zunächst einmal einige Grundeinstellungen der Ursprungs-VM in Erfahrung bringen: - System/Hardware UUID, evtl. Mac Addresse aller Netzwerkkarten (notwendig um die Windowsaktivierung zu behalten. - Bootmodus: UEFI oder Biosboot? - Verwendeter Festplattentreiber / Bootkonfiguration Danach konfiguriert man dann die Ursprungs VM so es sich um ein Windows handelt so, dass sie fest in den Abgesicherten Modus fährt. Dann sollte man die VM mindestens einmal neu booten um sicherzustellen das das auch klappt und fährt sie wieder herunter. (Im abgesicherten Modus booted Windows mit allen Festplattentreibern im Bauch) Erst jetzt zieht man das Image. Nun kann man die neue VM nach den oben extrahierten Informationen konfigurieren. Es ist wichtig darauf zu achten unbedingt den gleichen Bootmodos(Bios/UEFI) und möglichst die gleichen Festplattenemulation zu verwenden (IDE->IDE, AHCI->AHCI..) Außerdem unbedingt die UUID einstellen bevor man die neue VM das erste mal startet. Sonst ist die Aktivierung futsch, was bei Windows 10 inzwischen leider ein ganz großer Spaß ist, wenn man nicht bereits vorher ein Microsoftkonto mit der Installation verknüpft hat. (Telefonische Aktivierung gibt es nicht mehr) Ein bischen was wie man an die UUIDs kommt: https://www.linux-kvm.org/page/How_To_Migrate_From_Vmware_To_KVM Abgesicherter Modus um Festplattentreiber bei Windows zu ändern: https://superuser.com/a/1253728 Hier etwas wie eine kleine Anleitung zur migration, die UUID steht ganz oben: https://backdrift.org/converting-windows-guests-from-vmware-esx-to-kvm-with-virtio-drivers In dem dort beschriebenen XML würde ich jedoch die vollständigen Systeminformationen einbauen, wie im folgenden Link beschrieben. (Die unbekannten Felder kannst einfach Leer lassen oder mit dummywerten füllen): https://www.slicewise.net/debian/bios-informationen-an-kvm-gast-durchreichen/
@Andreas, mit der "Überforderung" könntest Du leider Recht haben, von daher kein persönlicher Angriff :-) Aber aufgeben gilt nicht. Ich werde mich dadurch kämpfen. NUR, wenn man die Threads die ich zum Thema Linux eröffnet habe mal durchschaut, dann tun alle so als wenn das Thema kvm JA so einfach wäre. Also bin ich mal ganz blauäugig an das Thema rangegangen. :-). Da es nicht so einfach geht war und ist mir schon klar. Da das Thema LINUX nur nebenher läuft ich habe ja auch noch ein Tagesgeschäft und das läuft zu 100% auf Windows heraus, ist LINUX nur ein Nebenkriegsschauplatz zu mindestens aktuell. Was das Thema Speicheranzeige angeht, da habe ich es auch mittlerweile begriffen das ich dieser Anzeige keine Bedeutung geben darf. Ich habe mittlerweile auf der Maschine alle 3 VMs unter VMWare stabil und performant laufen. Ich vermute, dass das erste hochfahren der SharePoint 2019er Maschine das eigentliche Problem war. Die zickte auch unter Windows 2019 Server schon mal rum. Der einzige Punkt, den ich noch nicht so ganz begriffen habe, ist das Thema swap File. VMWare möchte gerne mindestens 8GB swap File haben. Die hat es auch bekommen. Ist es sinnvoll das swap File noch größer zu machen frei nach dem Motto viel hilft viel oder ist das eher kontraproduktiv? Platz auf der Betriebssystempartition ist genug vorhanden. An dieser Stelle mal an alle die mir geholfen haben DANKE Gruß Frank
:
Bearbeitet durch User
Rudi Ratlos schrieb: > Linux füllt den RAM solange auf, bis er überläuft. Dann erst kommt der > swap. Hast du genug RAM?? läuft Linux als "RAM-Disk" ,dann brauchst auch > keinen swap mehr. Das hängt von dem Parameter "swappiness" ab.
Frank L. schrieb: > Der einzige Punkt, den ich noch nicht so ganz begriffen habe, ist das > Thema swap File. VMWare möchte gerne mindestens 8GB swap File haben. Die > hat es auch bekommen. Ist es sinnvoll das swap File noch größer zu > machen frei nach dem Motto viel hilft viel oder ist das eher > kontraproduktiv? Platz auf der Betriebssystempartition ist genug > vorhanden. Auch Hersteller von Software labern Müll und verstehen nicht alles. Ich hatte oben Kommandos vorgeschlagen mit den man sich das genauer anschauen kann, allerdings gab es kein Feedback von dir.
Frank L. schrieb: > Der einzige Punkt, den ich noch nicht so ganz begriffen habe, ist das > Thema swap File. VMWare möchte gerne mindestens 8GB swap File haben. Die > hat es auch bekommen. Ist es sinnvoll das swap File noch größer zu > machen frei nach dem Motto viel hilft viel oder ist das eher > kontraproduktiv? Platz auf der Betriebssystempartition ist genug > vorhanden. Swap brauchst du nur wenn RAM knapp wird - ist aber nicht performant. Ein gutes System soll nicht swappen - ist ein Notbehelf. Swap wird auch gebraucht um coredumps speichern zu können - ob du die brauchst / auswerten kannst ist eine andere Frage -für diesen Zweck würde man klassisch zweimal physikalisches Ram reservieren - ich mach das nicht bei Ram > 8GB. Es schadet nichts Swap zu vergrössern - bringt aber auch nichts. Und Hardwareanforderungen von Softwareherstellern - meine Meinung - man will halt auf der sicheren Seite stehen, also mehr ist besser (gilt für Cpu, Grafik, Memory)
@Dentaa sorry, diesen Eintrag habe ich tatsächlich übersehen. ich werde das aber nach holen, nur nicht mehr heute, da ruft das Tagesgeschäft. Gruß Frank
Frank L. schrieb: > Der einzige Punkt, den ich noch nicht so ganz begriffen habe, ist das > Thema swap File. VMWare möchte gerne mindestens 8GB swap File haben. Die > hat es auch bekommen. Ist es sinnvoll das swap File noch größer zu > machen frei nach dem Motto viel hilft viel oder ist das eher > kontraproduktiv? Platz auf der Betriebssystempartition ist genug > vorhanden. Hmm. Ich kenne VMWare jetzt nicht, aber unter Linux gibt es normalerweise kein einzelnes Swapfile was im Dateisystem liegt. Der Swapspeicher von Linux wird typischweise von mindestens einem (aber gerne auch mehr) "Blockdevices" gebildet. Üblicherweise ist das eine Partition der Festplatte. Es kann aber auch eine dedizierte Festplatte, ein Raid-Array oder z.B. auch ein iSCSI Netzlaufwerk sein. Kann es sein das VMWare hier ein eigenen Swap Implementiert auf Basis einer Datei? Wenn das der Fall ist, dann würde ich folgendes machen: Eine dedizierte Festplatte (Keine SSD) im Server nur für diesen Zweck installieren. Diese Festplatte mit GPT Partitionstabelle versehen (dadurch keine Begrenzung in der Anzahl der Partitionen). Auf dieser Festplatte für jede VM eine eigene Partition für das Swapfile anlegen. VMWare direkt diese Partitionen ("/dev/block/by-uuid/..." o.ä.) statt einer "normalen" Datei als Swapfile nutzen lassen. Das hat den Vorteil, das die Swapoperationen auf eine eigene Platte gehen und so den restlichen Betrieb nicht stören und vermeidet den "Overhead" eines Dateisystems. (Verbesserte Variante: Man könnte dass Ganze auch noch in einen LVM container legen, dann kann man sogar zur Laufzeit den Auslagerungsspeicher auf andere Festplatten verschieben wenn man mal Platten tauschen muss)
Andreas M. schrieb: > Kann es sein das VMWare hier ein eigenen Swap Implementiert auf Basis > einer Datei? Auslagerung von VM-Speicher auf Swapspace gibt es im ESXi, aber bei der Workstation ist mir das nicht bekannt. In den Requirements finde ich auch nichts über eine Mindestgrösse des Swapspace des Host-Betriebssystems.
:
Bearbeitet durch User
Zur Präzisierung, das Tool VMare Workstation pro möchte beim Start ein Swapfile von min. 8GB. Beim Start einer VM kommt keine Meldung. Beim erstmaligen Start und nach der Einrichtung von Debian war das Swapfile auf Standard 5xx MB oder so eingestellt. Jetzt ist es 8GB groß. Die VMs sind mit 16GB/RAM, 250GB/HDD und 4 CPUs in VMWare angemeldet. Gruß Frank
Frank L. schrieb: > Gruß Und wo ist jetzt genau das Problem bei dem du Hilfe benötigst? Die RAM-Belegung ist offenbar normal, mind.drei VirtMachines laufen > VMs sind mit 16GB/RAM, 250GB/HDD und 4 CPUs in VMWare angemeldet. Gilt das für jede der vier VM? --> 4x16=64gb , da klemmt auch nix? > mit der "Überforderung" könntest Du leider Recht haben, So ist das, wenn man mit debian anfängt. Super Erklärungen ! immer. amesser ... Danke .
Hallo Rudi, Es gibt nur drei VMs pro Rechner, der Speicher variiert ein wenig. Da der SharePoint 2019 ein wenig meckert haben Ich Ihm 24MB RAM gegeben. Aktuell laufen ohne Auffälligkeiten 16/16/24 GB in den VMs und 8 GB für den Host. Ich denke, daß ich mich von diesem blöden grafischen Tool und dem ersten etwas holprigen Start der VM ins Boxhorn habe jagen lassen. Zu mal, wenn man es mal nüchtern mit etwas Abstand betrachtet, es sogar okay war. Immerhin ist die VM von einem Windows 2019 Server Host auf einen Debian Host umgezogen. Da wir keine großen Datenmengen in den SharePoints hosten verhalten sich alle VMs in den gegebenen Parametern normal. Die Last die durch die VMs auf dem Host erzeugt wird ist eher gering. Wenn alles weiter so läuft, werden wir nächste Woche die erste Maschine mit drei virtuellen Entwicklungsumgebungen umziehen. Dann wird sich zeigen wie so ein System mit Last umgeht wenn da drei Entwickler zeitgleich per Remote Zugriff auf jeweils einer VM arbeiten. Insgesamt betrachtet, war die Migration einfacher als erwartet auch Dank der Hilfe hier. Mein Migrationshandbuch enthält alle wichtigen Kommandos und Tipps die ich brauche um weiter zu machen. Das LINUX viel Konsole benötigt war mir vorher klar. Aber wenn man SharePoint online macht ist die PowerShell in vielen Fällen Dein bester Freud also alles bekannt :-) Gruß Frank
Frank L. schrieb: > Ich denke, daß ich mich von diesem blöden grafischen Tool und dem ersten > etwas holprigen Start der VM ins Boxhorn habe jagen lassen. Ich glaube ehrlich gesagt nicht, daß es das GUI-Werkzeug war. Du warst nur nicht daran gewöhnt, daß Linux gnadenlos ehrlich ist und auf seine Dateisystempuffer und andere Performancedaten offen kommuniziert. Nicht schlimm, aber eben anders und für erfahrene Windows-Anwender und -Entwickler sehr ungewohnt. Wenn ich Dir dazu drei Titel zur Lektüre empfehlen darf, wären das: das Debian Administrationshandbuch [1], das Debian Anwenderhandbuch [2], sowie -- wenn Du lieber bedrucktes Papier magst -- Michael Koflers "Linux" [3]. > Insgesamt betrachtet, war die Migration einfacher als erwartet auch Dank > der Hilfe hier. Mein Migrationshandbuch enthält alle wichtigen Kommandos > und Tipps die ich brauche um weiter zu machen. Das LINUX viel Konsole > benötigt war mir vorher klar. Aber wenn man SharePoint online macht ist > die PowerShell in vielen Fällen Dein bester Freud also alles bekannt :-) Ähnliches höre ich von einem guten Freund, der früher bei IBM war und heute bei MS als Exchange-Spezialist beschäftigt ist. Der sagt, er benutzt das GUI-Zeugs gar nicht mehr, sondern nur noch die Powershell. ;-) [1] https://debian-handbook.info/browse/de-DE/stable/ [2] https://debiananwenderhandbuch.de/ [3] https://kofler.info/buecher/linux/
Danke Sheeva P. sind im LINUX Bookmark Ordner abgelegt und werde ich mir anschauen. Gruß Frank
Sheeva P. schrieb: > Der sagt, er > benutzt das GUI-Zeugs gar nicht mehr, sondern nur noch die Powershell. > ;-) PreLoad: *MS-Back-To-The-Roots-11.1* NEU!! auf 14 Floppies und als BONUS : alle Floppies auf CD Frank L. schrieb: > auf einen Debian Host umgezogen Ich empfehle dir dringend, vor dem Start des 'Testlaufes' , sofern dabei verwertbare Entwicklungen erzielt werden könnten, grundsätzlich -ALLES- auf Externen Win-filesystemen zu speichen UND keinelei Update-Orgien zu veranstalten ! Das ist nicht Windows mit zertifizierten Aktualisierungen. Wenn das System erstmals zusammenkracht, wirst du an mich denken ! PS.: Ich persönlich kenne keine fehlerfreie Distro.
Rudi Ratlos schrieb: > Das ist nicht Windows mit zertifizierten Aktualisierungen. Nichts gegen zertifizierte Aktualisierungen, wenn sie denn funktionieren. Zertifizierter Unfug bleibt Unfug. ;-) Im letzter Zeit pflegen diese zertifizierten Aktualisierungen in Bursts zu erscheinen. Da wird so lange zertifiziert rumgepatcht, bis entweder das Problem aufgibt, oder Microsoft.
:
Bearbeitet durch User
Rudi Ratlos schrieb: > Ich empfehle dir dringend, vor dem Start des 'Testlaufes' , sofern dabei > verwertbare Entwicklungen erzielt werden könnten, grundsätzlich -ALLES- > auf Externen Win-filesystemen zu speichen UND keinelei Update-Orgien zu > veranstalten ! > Das ist nicht Windows mit zertifizierten Aktualisierungen. > Wenn das System erstmals zusammenkracht, wirst du an mich denken ! Sorry Rudi, Ich habe kein Wort von dem was Du sagen willst verstanden.
Macht ja nix. Warte.... bis das System zusammenkracht press TAB for help <initramfs> Viel Spaß und Erfolg ! Ich habe noch die debian-6 DVDs da liegen. Und CentOS... und jetzt wird endlich aufgeräumt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.