Habe bei meiner VM testweise die OS-Disk von 30GB auf 40GB im ausgeschalteten Zustand vergrößert.
Nun lässt sie sich nicht mehr starten: "Failed to start VM {name}"
Falls sich das jemand ansehen möchte: VM ID: 019fd71f-b929-7599-8859-6f4b89c0c4c2
Ansonsten lösche ich die VM und lege eine neue an falls nicht von Interesse.
Mir fehlt die Variante eine DVD/ISO-Image zum Boot einzulegen.
Anwendungsfall: Restore eines Veeam Backups durch Boot der VM vom Veeam-Boot-ISO.
Danke, gefunden - funktioniert.
Intuitiv wäre ich da ohne Deinen Hinweis/Anleitung aber denke ich nicht drauf gekommen ... sollte man denke ich irgendwie kennzeichnen/erläutern warum hier etwas "gesperrt" ist.
Mir ist euer Konzept wonach jedes Netz eine Public-IP erhält (die ich auch nicht löschen kann) noch nicht ganz klar.
Warum kann ich kein Netz anlegen, das keine Public-IP hat?
Wenn ich vor habe der VM in diesem Netz eine dedizierte Public-IP zuzuweisen, und es keine weiteren VMs in diesem Netz gibt oder andere VMs in diesem Netz keinen Bedarf nach Kommunikation mit dem Internet haben, wozu dann diese Public-IP des Netzes? Ich vermute für jede Public-IP fällt später eine Gebühr an. Die würde ich in der Situation (da völlig unnötig) eigentlich vermeiden wollen.
Ich habe mir über den erhaltenen Einladungs-Link einen Account angelegt.
Nach Vor- und Nachname wurde ich hierbei nicht gefragt.
In den User-Settings bei der Profile-Information scheint daher ein nicht änderbares "Max Muster" auf.
Es wäre denke ich komfortabel (und kenne ich auch so von anderen Anbietern), wenn IP-Adressen ein selbst gewähltes Label / Namen (Unique) haben könnten oder zumindest eine Description konfiguriert werden könnte.
Mir fehlt in der EOS Cloud aktuell die Möglichkeit PTR-Konfigurationen / Reverse-DNS Einträge zu Public-IPs zu konfigurieren.
Betrieb z.B. eines Mailservers in der EOS Cloud ist somit aktuell noch nicht möglich.
Einen PAYG Account muss man ohnehin anlegen um dann die Free Tier Ressourcen nutzen zu können, ohne Zahlungsmittel-Verifikation gibt dir O*acle denke ich schon länger keine Free Tier Ressourcen mehr.
Wie auch immer, es sind jedenfalls nach wie vor nicht genug Ressourcen frei, um neue Instanzen anzulegen.
Ach so ... na da kann ich Dir einen Trick verraten: Man erstellt eine „VM.Standard.A2.Flex“ (die kostet etwas, ist aber immer verfügbar) und ändert danach aber sofort die Shape auf A1.Flex - voila, Free-Tier. Da in den paar Minuten in denen man die A2.Flex gehabt hat noch nichteinmal ein cent Kosten angefallen ist kommt auch keine Rechnung.
Das ist genau, was ich schreiben würde, damit mal ein paar Cores und RAM freigeräumt werden und ich endlich meine zweite Instanz hochziehen kann...
Kann sein.
Allerdings sind die Geschäftspraktiken von O schlichtweg auf Gewinnmaximierung ausgelegt, die Geschäftsbedingungen sehen keinerlei Verständigung über Preiserhöhungen vor, man muss selbst die Preisliste diffen oder sich eigenständig mit Cost-Forecasting-Alerts laufend informieren um keine Überraschungen zu erleben. Ich traue es O also zu, dass sie die Leute ins Messer laufen lassen. Auch dann werden vermutlich einige Cores frei. Wenn es also darum geht RAM und Cores frei zu bekommen ist es tatsächlich durchzuziehen und nicht nur anzukündigen die effizientere Vorgangsweise.
Bei O*acle dürfte ab 15.06.2026 das "Always Free Tier" Kontingent für die ARM-Instanzen halbiert werden. Anscheinend hat man sich als Strategie ausgedacht niemanden vorab zu informieren sondern die Limits ab 15. zu ändern und auch die Website erst dann anzupassen ... das ist jedenfalls der Outcome den sich die Reddit-Gemeinde zusammen-recherchiert hat, z.B. hier: https://www.reddit.com/r/oraclecloud/…oracle_support/
Ich habe meine Instanz mal vorsorglich auf 2 Cores / 12GB RAM reduziert. Wir werden sehen was wirklich passiert.
Nehme an die Netcup Foren Community empfiehlt getreu dem Motto "Ente gut, alles gut" den Wildduck Mailserver, https://docs.wildduck.email/
Danke,
Das in Go geschriebene https://www.xmox.nl/ ist über v0.15 Beta nie hinausgekommen und scheint seit mehr als einem Jahr nun eingeschlafen zu sein. Auch im GitHub repo / issues tut sich da nicht viel.
Das ebenfalls in golang geschriebene https://maddy.email/ ist noch aktiv in Entwicklung, ich vermisse aber ad-hoc Dinge wie Spamfilter, Kalender und Kontakt-Synchronisation etc... Auf den ersten Blick deutlich minimalistischer als Stalwart.
Ich weiß, hier im Forum ist die Fraktion Mailcow stark vertreten.
Ich betreibe seit mehr als 25 Jahren Mailserver, aktuell (die letzten 15+ Jahre) basierend auf manuell installiertem und betriebenen Postfix + Dovecot + RoundCube WebMail auf Ubuntu.
Nun werde ich wegen Major OS Release Wechsel das Setup neu machen, und überlege, ob es mittlerweile bessere Kandidaten gibt.
Und da bin ich bei der Recherche bei Stalwart Mail hängen geblieben, als WebMailer hierfür würde sich dann Bulwark (mit JMAP Support) anbieten.
Warum ich damit liebäugle: Aus einem Guss, in Rust geschrieben, ressourcenschonend, ansprechendes Web-Administrations-Interface aber auch CLI-Administration (die ich für vieles bevorzugen würde), moderner JMAP Support (nebst freilich auch IMAP/POP3) ... und bei den Features geht mir bei Durchsicht der Community-Edition-Feature-Liste aktuell nichts ab.
Hat sich jemand damit bereits beschäftigt und möchte mir das Produkt ausreden? 
Hat sich jemand einen aktuellen Marktüberblick verschafft, gibt es weitere aktuelle Lösungen die nicht bereits altbekannt sind und man sich ansehen sollte?
Danke Zierleiste für den Hinweis, ist am Spickzettel korrigiert und ergänzt.
Ich habe Ubuntu 26.04 auf dem 1GB RAM Piko nun doch wieder zum Laufen bekommen, indem ich in der Grub-Config /etc/grub.d/42_my-netcup-gfx folgende im Rahmen des des Updates entfernte Zeilen ergänzt habe:
GRUB_GFXMODE=1024x768
GRUB_GFXMODE_LINUX=keep
gefolgt von einem "update-grub"
Meinen Piko mit 1GB RAM hatte ich vor ca. 2 Wochen erfolgreich von Ubuntu 24.04 auf 26.04 hochgezogen, definitiv auch freilich mehrfach seitdem rebootet. Seit dem Update gestern für die copy.fail Schwachstelle bootet die VM nun allerdings nicht mehr, Kernel Panic, System is deadlocked on memory.
Werde wohl doch auf Debian umsteigen müssen.
Meine Server (ebenfalls Standort NUE) waren von der gestrigen Abschaltung/Ausfall NICHT betroffen. Habe davon nur hier im Forum gelesen.
Mir wird nun aber ein KVM-Update im SCP angeboten, welches ich soeben durch Ausschalten + wieder Einschalten der Server angewendet habe.
Möglicherweise besteht also ein Zusammenhang zwischen KVM-Update und euren Ausfällen ... scheinbar wurde ja jedenfalls am Hypervisor was geändert.
Hatte Netcup mir da aus versehen kurz eine andere (nicht meine) vdisk angeschlossen?
Ich sehe da kein Indiz für eine angeschlossene Disk.
Diese Speed-Messungen macht dieser raid6-Treiber doch vermutlich bei jedem Neustart?
Welche Arbeitsleistung steckt denn in so einem Setup?
Ist eine ernst gemeinte Frage!
Die Gründe (explodierende, unkalkulierbare Hardware-Kosten bei RAM/NVME durch die AI-Spekulationen) sind im verlinkten Artikel eigentlich nachvollziehbar dargestellt.
