Proxmox als Verwaltung und Dienste in LXC Container?

    Moin,

    ich experimentiere in einem anderen Zusammen mit Proxmox und VM / LXC Containern.
    Dabei viel mir auf, dass proxmox viele praktische Dinge liefert, die ich normalerweise "kompliziert" nachbauen muss.
    z.B. Backups und der Umzug von VM / LXC Containern auf einen anderen Host, Backup, Snapshot usw.
    Daher habe ich proxmox auf einem RS installiert und einzelne Dienste wie den Webserver noch mal in einem LXC Container virtualisiert.
    Bei einem Upgrade kann ich den Container clonen, updaten, testen und einfach den alten durch den neuen ersetzen.
    Einzelne Ports leite ich dabei einfach auf die entsprechenden Container um.

    Das klappt erstaunlich gut.
    Bevor ich jetzt alles darauf umstelle, wollte ich einmal fragen ob das evt. jemand im produktiven Einsatz nutzt und Langzeiterfahrung hat.

    Ich nutze Proxmox zuhause auf einem NUC als Homeserver - dies schon seit einigen Jahren und bin sehr zufrieden. Laufen ca. 10 LXC-Container drauf und seit neustem auch eine VM. Klar, könnte man auch alles händisch selbst machen, aber ich finde das WebUI sehr angenehm und gröbere Fehler sind mir bisher nicht aufgefallen.


    Die Container und das integrierte Backupsystem (inkl. Recovery) laufen anstandslos.


    Auf einem RS hatte ich es jedoch noch nicht im Einsatz. Da können sich gern andere zu melden.

    Proxmox ist in meinen Augen noch lange nicht Enterprise ready.

    Beispiele: Fehlende Dokumentation / wenige Suchtreffer bei Problemen, Failover bei Netzwerkkarten, Backups sind uU. defekt und Cluster sterben, wenn ein einziger Node kaputt geht.


    Aber für ein Home-Datacenter oder ähnliches ist Proxmox absolut in Ordung.

    Witzigerweise läuft der bei mir auch auf einem Intel NUC! :D


    Mal eine ganz andere Frage: Auf einem RS bräuchte man doch das kostenpflichtige Virtualisierungs Flag auf jedem CPU Kern, um VMs in Proxmox nutzen zu können.

    Oder hat sich das inzwischen geändert? Wenn ich einfach nur Container verwalten will mit einer WebGUI, dann kann ich z.B. auch Rancher verwenden. Der läuft ziemlich stabil, und man hat die typischen K8S Werkzeuge zur Hand.

    Quote from NieSommer

    Auf einem RS bräuchte man doch das kostenpflichtige Virtualisierungs Flag auf jedem CPU Kern, um VMs in Proxmox nutzen zu können.

    Ja. Das Flag wird allerdings nicht mehr angeboten. LXC funktioniert aber auf Netcup Servern.

    compi.dev

    Ein Mensch hat zwei Beine, ein Regenwurm hat keine.

    Quote from NieSommer

    […] wenige Suchtreffer bei Problemen […]

    Dafür hat man im Proxmox-Forum einen direkten Draht zu den Entwicklern, wahlweise auf Deutsch oder Englisch. Und das sogar ohne Subscription ^^

    Quote from NieSommer

    […] Backups sind uU. defekt […]

    Bitte mehr Details, da werde ich hellhörig. Welche Bugs kenne ich noch nicht? ?(

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Edited once, last by KB19 ().

    Like 1
    Quote from KB19

    Dafür hat man im Proxmox-Forum einen direkten Draht zu den Entwicklern, wahlweise auf Deutsch oder Englisch. Und das sogar ohne Subscription ^^

    Bitte mehr Details, da werde ich hellhörig. Welche Bugs kenne ich noch nicht? ?(

    Die VM Backups waren es, wenn ich mich richtig erinnere. Ich hab auf die schnelle diesen Bug gefunden:

    https://bugzilla.proxmox.com/show_bug.cgi?id=2874

    Ich weiß aber offengestanden nicht mehr, ob dass das einzige Problem in dem Zusammenhang ist/war.


    Bzgl Support:

    Bei anderen Produkten hatten schon 100 Leute vor dir das Problem, und du findest Infos im Netz.

    Support in einem Forum zu deutschen Ladenzeiten ist für uns toll, aber halt nicht wirklich Enterprise Ready. Das meine ich absolut nicht abwertend, nur wenn jemand wissen möchte ob es Produktionsgeeignet ist, dann ist das vielleicht ein NoGo. Bei anderen Herstellern bekomme ich 24/7 Expertensupport, bei Proxmox bekomme ich für Geld maximal innerhalb von 2 Stunden eine "Erstreaktion". Eine Erstreaktion kann auch sein, dass man dem lieben Kunden aus den USA mitteilt, dass die Entwickler gerade alle im Bett liegen. Proxmox ist halt ein kleines Unternehmen und hat laut LinkedIn nur zwischen 11 und 50 Mitarbeiter.

    In den Augen der meisten IT-Verantwortlichen im Enterpriseumfeld wäre Proxmox damit schlichtweg ein Risiko. Für KMU hingegen kann das Risiko durchaus akzeptabel und Proxmox eine Lösung sein.

    Quote from NieSommer

    In den Augen der meisten IT-Verantwortlichen im Enterpriseumfeld wäre Proxmox damit schlichtweg ein Risiko. Für KMU hingegen kann das Risiko durchaus akzeptabel und Proxmox eine Lösung sein.

    Deine Argumentation schließt eine Verwendung von Linux dann auch aus? Da gibts auch keinen Support den ich anrufen kann.

    Das Risiko ist mir bewusst - bzw. gehe es ein. Wird schon nicht schlimmer als bei einer Ubuntu installation sein :D (Ironie)

    Die Basis von Proxmox ist Debian, daher läuft der Core sehr stabil und ist mehr als umfassend dokumentiert. Im Endeffekt haben die ein schönes Webinterface und viel praktisches um vorhandene Lösungen gebaut. Genau das sucht ich.
    In meinem Testsetup konnte ich einen Minecraft-Server wieder herstellen und der lief problemlos weiter.
    Webserver geht heute Abend dann in die installation.
    Ich fummel vorher noch etwas an SSH hinter Wireguard und etwas mehr Absicherung.

    Ich benutze Proxmox mittlerweile seit knapp 3 Jahren produktiv für ein KMU mit 20 MA. Mehrere Proxmox Server im RZ und OnSite, Backup+Restore hunderte Male problemlos, selbst HA funktioniert nahezu ohne große Anpassungen. Was eben bei Netcup "stört" ist der fehlende Flag für die VMs, aber je nach Use-Case lässt sich darauf auch gut verzichten.


    Support ist grundsätzlich eine Sache, für Konzerne stimme ich aber zu das Proxmox eher noch nicht ready ist, was aber mehr an der Compliance liegt als der Funktionalität und Stabilität.


    Falls ihr Fragen habt, vielleicht kann ich euch mit meinem/unserem Know-How etwas aushelfen.

    Quote from NieSommer

    Fehlende Dokumentation

    Alles da, was man braucht.



    Quote from NieSommer

    Failover bei Netzwerkkarten

    Ganz normales Interface-Bonding im Linux Kernel.

    Hardware-Switch richtig konfiguriert?



    Quote from NieSommer

    Cluster sterben, wenn ein einziger Node kaputt geht.

    Split / Brain?


    Quote from Homwer

    Bevor ich jetzt alles darauf umstelle, wollte ich einmal fragen ob das evt. jemand im produktiven Einsatz nutzt und Langzeiterfahrung hat.

    Läuft prima, bei bestimmten Sachen musst du mit der Shell umgehen können - ein Großteil lässt sich jedoch über die GUI direkt machen.

    Quote

    Alles da, was man braucht.

    Im Vergleich zu anderen Produkten ist sie ziemlich schwach.

    Das ist einer der häufigsten Kritikpunkte bei Proxmox. Markantes Zitat:

    "While I do mostly like Proxmox, the only thing I dislike is its atrocious documentation. The wiki itself is alright, but it's missing a lot too and the moment it does you'll likely have to hope there are solutions other places than their forum. It's one of the few forums I can wholeheartedly call awful."


    Nicht selten wird kritisiert, dass man erst ein gewisses Maß an Revers-Engineering machen muss, da es eben an der Dokumentation hapert.

    Dass man das machen kann ist schön - aber die Notwendigkeit ist zweifelsfrei ein Kontraargument und kein Pro.

    Quote

    Ganz normales Interface-Bonding im Linux Kernel.

    Hardware-Switch richtig konfiguriert?

    Ebenfalls bekanntes Proxmox Thema. Ich hab mal google bemüht:

    https://old.reddit.com/r/sysadmin/comments/yzm5hc/shout_out_to_proxmox_ve_devs_best_hypervisor_imo/ix1l2e7/

    Davon abgesehen ist die Bobachtbarkeit des Datenverkehrs echt mittelgut.

    Quote

    Split / Brain?

    Nein, da stirbt ja nicht das ganze Cluster.

    Bekanntes Beispiel nach 5 Sekunden Googlen:

    "Tesla devs used proxmox and trusted it. One host went down and the entire cluster failed. They lost everything on it. The entire config was wiped. They were down for quite a while. I knew a guy that helped them bring it back to life. They lost a ton of work."

    Klar kann man da bei der Schuldfrage über viele Dinge streiten.Trotzdem darf das einfach nicht passieren.


    Bei einem split brain sieht es aber auch nicht so rosig aus. Da ist man schnell in der Welt des Frickelns, und im Enterprise zahlt man gerne einen Aufpreis für Systeme, die sich selbst heilen. Frickeln ist da unangemessen.


    Das schöne ist ja, das Proxmox alle Themen kennt und teilweise auch offen zugibt, dass es sie zumindest "vereinzelt" gibt. Ein IT-Entscheider würde sich hier fragen "Reicht uns Proxmox, oder brauchen wir etwas besseres?". Und natürlich die Frage "Gibt es Proxmox in 10 Jahren überhaupt noch? Was passiert, wenn die kleine Firma aufgekauft und die primären Entwickler abgezogen werden?


    Versteht mich nicht falsch, ich will das Produkt nicht schlecht reden. Die Frage, ob etwas für Produktion geeignet ist, ist vielschichtig. Es ist wichtig nicht die subjektive Wahrnehmung als objektive Wahrheit darzustellen. Wenn für H6G als Beispiel die Doku ausreichend ist, dann ist das für ihn einfach ein Kritikpunkt, der kein Gewicht hat . Wenn er allerdings gefragt wird müsste er klar differenzieren: Für ihn ist die Dokumentation ausreichend, aber andere finden sie unzureichend.

    Analog dazu "Alles da, was man braucht." müsste es inhaltlich heißen: "Alles da, was H6G gebraucht hat. Andere kritisieren allerdings dass gerade bei besonderen Problemstellungen im Gegensatz zu anderen Hypervisors keine einfache Lösung für das Problem ergoogelt werden kann. Das kann gerade bei gemischten Skillstufen im Team problematisch sein."


    Und sorry dass ich da jetzt echt ein bisschen lang drauf herumgeritten bin H6G.

    Quote from NieSommer

    The wiki itself is alright, but it's missing a lot too and the moment it does you'll likely have to hope there are solutions other places than their forum.

    Proxmox bietet nicht nur das Wiki und ein Forum. Du hast auch eine Dokumentation und man-Pages.

    Eine gute Übersicht findest du hier: https://pve.proxmox.com/pve-docs/


    Das ganze ist bei Linux / Unix Projekten / Sammlungen von Tools nicht unüblich - vorallem bei Betriebssystem-Distributionen ist es genau so.

    Genau so wie Proxmox eine Sammlung von Tools ist, ist VMware genau so eine Sammlung von Tools.


    ESXi ist der eigentliche Hypervisor, vSphere vCenter das bessere Verwaltungstool, vSAN für Speicher und NSX-T für das SDN.



    Quote from NieSommer

    Und natürlich die Frage "Gibt es Proxmox in 10 Jahren überhaupt noch? Was passiert, wenn die kleine Firma aufgekauft und die primären Entwickler abgezogen werden?

    Das Zeug ist Open Source: https://git.proxmox.com/ - das kann jeder weiter entwickeln, wenn es Proxmox in 10 Jahren nicht mehr geben sollte.

    Komischerweise stellt da keiner die Frage: gibt es Linux und Qemu in 10 Jahren noch? Beides sind Bestandteile von PVE und von Netcup Servern.


    Quote from NieSommer

    Tesla devs used proxmox and trusted it.

    Softwareentwickler? DevOps?

    Infrastrukturbetrieb ist nicht ohne Grund eine eigene Disziplin und ein eigenständiger Ausbildungsberuf.

    Einem Entwickler Operations anzuvertrauen, der von Operations keine Ahnung hat, ist ein Pulverfass.


    Quote from NieSommer

    Andere kritisieren allerdings dass gerade bei besonderen Problemstellungen im Gegensatz zu anderen Hypervisors keine einfache Lösung für das Problem ergoogelt werden kann.

    Proxmox ist kein Hypervisor.

    Warum müssen eigentlich Systembetreiber eine Lösung ergooglen können?


    Ich bin mir durchaus der Unterschiede zwischen der Enterprise Welt und dem Unix-Kosmos bewusst - das ist teilweise ein Kampf der Kulturen.


    Die Realität bei VMware sieht doch aber folgendermaßen aus: du zahlst entweder für teuren Support, den du nicht nutzt, oder du zahlst ein Systemhaus dafür, dass du eine vollständige Lösung bereitgestellt bekommst.

    Quote from H6G

    Proxmox ist kein Hypervisor.

    Mal zum Verständnis diese Frage: Möchtest du uns damit mitteilen, dass Proxmox auf deren eigenen Kernel, der den Hypervisor beinhaltet, nicht wirklich angewiesen ist und ich als Anwender dessen GUI problemlos auch auf einem Rocky Linux oder Almalinux mit dessen eigenen Kernel mit integriertem Hyperviser verwenden könnte?

    Quote from andreas.

    Möchtest du uns damit mitteilen, dass Proxmox auf deren eigenen Kernel, der den Hypervisor beinhaltet, nicht wirklich angewiesen ist und ich als Anwender dessen GUI problemlos auch auf einem Rocky Linux oder Almalinux mit dessen eigenen Kernel mit integriertem Hyperviser verwenden könnte?

    Was definitiv geht und ich bereits probiert habe: Proxmox mit Vanilla Debian Kernel.

    Ob das unter RHEL problemlos funktioniert? Wahrscheinlich nicht: Pfade von Executables (Qemu) und Konfigurationen werden anders sein, deb Pakete sind nicht installierbar. Netzwerk ist auch auf ip-route2 ausgelegt.


    Auf Debian wird das gehen, bei Ubuntu wirst du ein paar Anpassungen brauchen.

    Quote from H6G

    Was definitiv geht und ich bereits probiert habe: Proxmox mit Vanilla Debian Kernel.

    Das ist gut zu wissen. Denn ich experimentiere auch gerade mit Proxmox 7.x und habe Proxmox schon seit einigen Wochen auf einem RS 8000 ohne den benötigten Flags zur Vollvirtualisierung installiert.


    Das Problem, welches du mal hier im Forum schon uns mitgeteilt hast, dass es nur ein paar Tage läuft, habe ich gerade auch auf diesen RS. Denn Proxmox mit dessen eigenen Kernel läuft auf diesen RS nur zwischen 9 und sehr selten 15 Tagen. Auch dann, wenn kein LXC gerade auf dem System läuft.


    Auf einem Dedicated Server, auf dem ich auch eine KVM-Maschine installiert habe, in der auch Proxmox 7.x so installiert ist wie hier bei Netcup, habe ich dieses Problem nicht. Denn auf Diesem läuft Proxmox 7.x schon seit monaten ohne ungewollte Neustarts.


    Auch dieser KVM-Maschine (VM) habe ich die nötigen Flags zur Vollvirtualisierung weggenommen. Denn das muß man mittlerweile auf dem Host unter Rock Linux oder Almalinux sogar aktive deaktivieren.

    Quote from andreas.

    Das Problem, welches du mal hier im Forum schon uns mitgeteilt hast, dass es nur ein paar Tage läuft, habe ich gerade auch auf diesen RS.

    Schreib mal dem Support, unter Verweis auf das Forenthema. Das wurde ja mal gelößt und bei mir funktionieren neue, wie alte RS weiterhin mit Proxmox.

    Ggf. auch nochmal auf den Thread antworten und Lars verlinken.

    Proxmox versteht sich selbst als Produkt/Plattform und nicht als Toolsammlung. Das wäre auch sonst nicht wirklich wertschätzend Proxmox gegenüber, da es dann doch etwas mehr ist, als nur die Summe seiner "Tools".

    Und die Abstaktion soll ja eben ermöglichen, dass der Hersteller die darunter liegenden Tools ggf. austauschen kann, ohne dass die Plattform bricht.

    Wenn ich bei jedem Feature erst mal ermitteln muss welches "Tool" im Hintergrund genutzt wurde, dann ist das ungut. Und genau wird ja auch bemängelt.


    OpenSource:

    Nehmen wir einfach mal an es gibt einen zwingenden Anlass und du machst einen Fork.

    Hast du genug Entwickler, um die Plattform auf dem aktuellsten Stand zu halten? Haben die überhaupt das passende KnowHow?

    Macht es überhaupt Sinn extrem knappe Entwicklerressourcen dafür einzusetzten, anstatt für das Produkt, mit dem die Firma Geld verdient?

    Du kannst nicht einfach die hauseigenen Entwickler drauf werfen und hoffen dass ein Wunder geschieht. Bei MySQL und PfSense war ja der Knackpunkt, dass viele der bisherigen Entwickler den Fork jeweils mitgegangen sind. Ohne die Proxmox eigenen Entwickler, und deren Wissen, kann man das Projekt kaum fortführen.


    10 Jahre:

    Natürlich schaut man sich vor seinem Investment an, wie "sicher" es ist. Migrationen sind halt teuer, dauern lange und haben ein hohes Risiko.

    Wenn ich also meine Infrakstuktur mit etwas aufbaue, bei dem ich garnicht weiß ob es eine gesicherte Zukunft hat oder nicht, dann ist das eine schlechte Wette. Stell dir mal vor ein Unternehmen mit über 1Mrd € Umsatz wäre vom Erfolg einer 30 Mann Klitsche abhängig. Fühlt sich das richtig an oder nicht? Wenn ich jetzt aber ein KMU bin, der innerhalb von 2 Wochen auf ein anderes System umziehen könnte - klar, dann kann ich mit dem Risiko leben.


    Linux, Netcup usw.:

    Ich unterstelle Netcup einfach mal ihre Tool- und Produktwelt nicht mit einer rosaroten Opensource-Brille zusammengetackert, sondern bewusst einzelne Technologien und Werkzeuge ausgewählt zu haben. Einfach wild "Toolsammlungen" im Unternehmen einzuführen, nur weil sie OpenSource sind, ist ein markantes Sicherheitsrisiko. Auch wenn das etablierte Tools oder Pakete sind, so steigert jedes einzelne die Chance von einem Supplychain Angriff erwischt zu werden.


    Linux hat viele große Firmen als Sponsoren und Unterstützer gewonnen. Wieviele hat Proxmox?

    In den Fortbestand von Proxmox zu vertrauen, weil man schließlich ja auch bei Linux oder Quemo darauf vertraut, ist für mich keine nachvollziehbare Haltung.


    Tesla:

    Ein Wipe darf in keiner Welt passieren.

    Bezüglich Ops bin ich bei dir. Ich kenne leider kaum DevOps Teams, die wirklich einen Ops im Team haben.

    Da hilft oft nur lernen durch Schmerz.


    Kostenpflichtiger Support:

    Der ist ja wie eine Versicherung zu verstehen. Du bist froh, wenn du ihn nicht brauchst. Brauchst du ihn, bist du froh dass du ihn hast. Hast du ihn nicht, dann ist der Schaden in der Regel deutlich größer. Oft ist der Support deutlich billiger, als wenn der Betrieb ein paar Tage sillsteht. Es kann also durchaus Sinn machen, damit einfach das unernehmerische Risiko zu senken oder die Kosten des Ausfallrisikos auf mehrere Jahre zu verteilen. Da muss man echt im Detail drauf schauen, was da Sinn macht und was nicht. Macht es keinen Sinn - ja klar, dann spart man sich das Geld.

    Quote from NieSommer

    Das wäre auch sonst nicht wirklich wertschätzend Proxmox gegenüber, da es dann doch etwas mehr ist, als nur die Summe seiner "Tools".

    Das ist so - egal ob das abwertend ist, oder nicht.

    Proxmox ist natürlich mehr, als die Summe seiner Tools, weil die Tools gute Synergieeffekte erzeugen - bspw. der Proxmox Backup Manager.



    Quote from NieSommer

    Und die Abstaktion soll ja eben ermöglichen, dass der Hersteller die darunter liegenden Tools ggf. austauschen kann, ohne dass die Plattform bricht.

    Das nennt sich Unix Philosophie.



    Quote from NieSommer

    Nehmen wir einfach mal an es gibt einen zwingenden Anlass und du machst einen Fork.

    Hast du genug Entwickler, um die Plattform auf dem aktuellsten Stand zu halten? Haben die überhaupt das passende KnowHow?

    Macht es überhaupt Sinn extrem knappe Entwicklerressourcen dafür einzusetzten, anstatt für das Produkt, mit dem die Firma Geld verdient?

    Du kannst nicht einfach die hauseigenen Entwickler drauf werfen und hoffen dass ein Wunder geschieht. Bei MySQL und PfSense war ja der Knackpunkt, dass viele der bisherigen Entwickler den Fork jeweils mitgegangen sind.

    Ist in sich ad absurdum geführt. Bei MySQL gab es den Fork, weil es von Oracle gekauft wurde, damit gab es den Anlass.

    Ziel eines Forkes ist ja auch nicht die Weiterentwicklung, sondern ein behalten des Status Quo: sicherer und stabiler Betrieb.



    Quote from NieSommer

    10 Jahre:

    Natürlich schaut man sich vor seinem Investment an, wie "sicher" es ist. Migrationen sind halt teuer, dauern lange und haben ein hohes Risiko.

    In der IT migrierst du ständig. Tuest du es nicht, erzeugst du unnötige Kosten - bestes Beispiel dafür ist Banken- und Behördensoftware, die noch auf irgendwelchen Mainframes läuft.

    Ansonsten mirgriert man innerhalb des 10 Jahreszeitraumes - oder setzt bei dir noch jemand Windows 8, Office 2013 und den Adobe Flashplayer ein?

    Laufen da auch noch Intel Core-i Modelle der dritten Generation?


    Quote from NieSommer

    Auch wenn das etablierte Tools oder Pakete sind, so steigert jedes einzelne die Chance von einem Supplychain Angriff erwischt zu werden.

    Naja, halte ich für stark fragwürdig diese Aussage.



    Quote from NieSommer

    Linux hat viele große Firmen als Sponsoren und Unterstützer gewonnen. Wieviele hat Proxmox?

    In den Fortbestand von Proxmox zu vertrauen, weil man schließlich ja auch bei Linux oder Quemo darauf vertraut, ist für mich keine nachvollziehbare Haltung.

    Eigentlich egal, wie viele Unterstützer ein Projekt hat. Wenn morgen Landunter ist, weiß ich immer noch, wie ich an meine virtuellen Maschinen rankomme und wie ich diese ohne PVE starten könnte.


    Evtl. ein schlechtes Beispiel dafür: https://www.freexian.com/lts/php/ solange es mind. einen zahlenden Supporter gibt, bekommt man dort Updates für PHP 5.6



    Quote from NieSommer

    Ein Wipe darf in keiner Welt passieren.

    Bezüglich Ops bin ich bei dir. Ich kenne leider kaum DevOps Teams, die wirklich einen Ops im Team haben.

    Da hilft oft nur lernen durch Schmerz.

    Also lernen durch Schmerz, ja - aber rm -rf darf dann trotzdem nicht funktionieren?



    Quote from NieSommer

    Der ist ja wie eine Versicherung zu verstehen. Du bist froh, wenn du ihn nicht brauchst. Brauchst du ihn, bist du froh dass du ihn hast. Hast du ihn nicht, dann ist der Schaden in der Regel deutlich größer. Oft ist der Support deutlich billiger, als wenn der Betrieb ein paar Tage sillsteht. Es kann also durchaus Sinn machen, damit einfach das unernehmerische Risiko zu senken oder die Kosten des Ausfallrisikos auf mehrere Jahre zu verteilen.

    Die Kosten des Ausfallrisikos sind die gleichen. Die Kosten des Ausfalls sind dann aber unterschiedlich.

    Ein kostenpflichtiger Support senkt nicht das Ausfallrisiko.


    Sollte doch mal der Fall eintreten, dass die dich anrufen, du sollst bitte upgraden auf die neue Version, dann telefonierst du gerade mit der Sales Abteilung, nicht mit der Support Abteilung.

    An Proxmox stört mich tierisch, dass die auf das "normale" Debian und nicht auf eine LTS-Distribution, von mir aus auch auf Ubuntu LTS setzt. Aufgrund des Enterprise-Supports von Ubuntu hätte man über Jahre Ruhe... Bei Netcup hänge ich wg. des Virtualisierungsbugs (wir haben das Flag noch) auf der alten Proxmox-Version fest, die jetzt EOL ist. Es gibt allerdings keine Firmware-Updates mehr... ich musste mir daher ein Franken-Debian und -kernel bauen.