Eigenes Image auf Rootserver installieren schlägt fehl

    Hallo zusammen,

    ich bin neu hier und habe mir vor ein paar Tagen einen Rootserver bei Netcup bestellt und wollte nun ein KVM .raw-Image meines alten Servers (Jiffybox Cloudserver) auf dem Netcup-Rootserver installieren. Habe also die .raw-Datei im Server Control Panel hochgeladen unter "Eigene Images" und dann versucht, das Image installieren zu lassen. Dies schlug aber fehl, es kommen nur Input/Output-Fehler:


    Code
    Boot from SAN device 0x80 failed: Input/output error
Could not boot image: Input/output error
No more network devices
No bootable devices

    Im Server Control Panel steht, dass .raw-Images funktionieren würden, und ich habe mir das auch vom Netcup-Support vor der Bestellung des Servers schriftlich bestätigen lassen. So wurde mir am 12.02.2024 unter der Ticket-ID NCSUP-314362 explizit bestätigt, dass man KVM raw Images installieren kann:

    Zitat von Netcup-Support
    General ist es möglich KVM raw images zu importieren. Das Betriebssystem spielt dabei keine Rolle. Sie sollten aber darauf achten, dass die Festplatte des Zielsystems gleich groß oder besser noch etwas größer ist.

    So, jetzt kommt aber die große Enttäuschung und Verwunderung: Nachdem der Import des Images offensichtlich nicht erfolgreich war, habe ich den Support nochmals angeschrieben und unter der Ticket-ID NCSUP-328757 gestern eine Antwort erhalten, die im krassen Widerspruch zu der ersten Supportantwort aus dem Februar steht:

    Zitat von Netcup-Support

    vielen Dank für Ihre Anfrage.

    Bedauerlicherweise verwenden unsere Server nur .qcow2-Dateien. Daher wird eine .raw Datei nicht auf den Server geladen.

    Ich fühle mich nun schon leicht verschaukelt, zumal im Server Control Panel unter "Eigene Images laden" immer noch folgendes steht: "Es werden nur Dateien vom Typ qcow, qcow2 und raw offiziell unterstützt."


    Kann mir vielleicht hier im Forum jemand erklären, was nun stimmt? Den Glauben an den Netcup-Support habe ich mittlerweile bereits verloren und bin kurz davor, den Server wieder zu kündigen und meine Zelte hier nach wenigen Tagen schon wieder abzubrechen.


    PS: Falls es mit raw-Images doch allgemein funktionieren sollte, und jemand etwas zum eigentlichen Fehler beitragen kann ("Input/Output-Error") und woran dieser liegen könnte, würde ich mich über Hinweise auch freuen.

    Zitat von Keyser Soze
    Jiffybox Cloudserver

    Die JiffyBox verwendet nicht KVM sondern Xen. Wenn ich das richtig im Kopf habe, war bei den dortigen Images standardmäßig nicht einmal ein Kernel oder Bootloader enthalten, weil das bei der verwendeten Virtualisierung nicht notwendig war. Einen eigen Kernel konnte man auf Anfrage zwar nutzen, aber das war dann trotzdem eher eine Frickellösung. Weiters sind die "Festplatten" dort eigenständige Devices und haben gar keine Partitionen.


    Wenn ich nicht komplett am Holzweg bin, ist es wahrscheinlich einfacher, Du installierst bei netcup das Betriebssystem Deiner Wahl neu und kopierst danach ausgewählte Konfigurationen und Daten manuell z.B. mittels rsync über SSH rüber.

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

    Gefällt mir 1
    Zitat von KB19

    Die JiffyBox verwendet nicht KVM sondern Xen. Wenn ich das richtig im Kopf habe, war bei den dortigen Images standardmäßig nicht einmal ein Kernel oder Bootloader enthalten, weil das bei der verwendeten Virtualisierung nicht notwendig war. Einen eigen Kernel konnte man auf Anfrage zwar nutzen, aber das war dann trotzdem eher eine Frickellösung. Weiters sind die "Festplatten" dort eigenständige Devices und haben gar keine Partitionen.

    Bei den sogenannten JiffyBoxen basierend auf Xen des Mitbewerbers war es möglich, sich noch vor dem Installationsprozess zwischen einer Container- und einer Voll-Virtualisierungs-Installation zu entscheiden. Denn hatte man seinen Voll-Virtualisierten vServer mit einem Betriebssystem seiner Wahl als Voll-Virtualisierungs-Installation installiert, so verhielt sich der Voll-Virtualisierte vServer wie auch hier die vServer von Netcup.


    Vor einem Jahr habe ich für einen Bekannten einen Xen-Container und einen Xen-Voll-Virtualisierten vServer hier zu Netcup erfolgreich umgezogen.


    Wie bin ich bei beiden Varianten dabei vorgegangen?

    1. Den bisherigen vServer habe ich im Rettungssystem gestartet.
    2. Sofern die virtuelle Platte vom Rettungssystem nicht gemountet war, sie noch gemountet.
    3. Vom / ab den kompletten Inhalt der virtuellen Platte per TAR in einer TAR-Datei gepackt.
    4. Auf dem Zielserver das gleiche OS mit gleicher Versionsnummer installiert.
    5. Ein Snapshot vom Zielserver erstellt.
    6. Das Rettungssystem des Zielservers gestartet und darin die virtuelle Platte gemountet.
    7. Die TAR-Datei ab / auf der gemounteten virtuellen Platte ausgepackt.
    8. Danach IP-Adresse bzw. IP-Adressen und MAC-Adresse bzw. MAC-Adressen des Zielserver angepaßt.
    9. Den Zielserver in beiden Varianten erfolgreich neu gestartet.
    10. Und danach glücklich sein.

    Ich bin kein Experte was die Virtualisierungsumgebungen angeht. Hier steht noch etwas zu den Jiffybox-Kerneln:

    https://www.df.eu/de/support/df-faq/cloudserver/control-panel/profile-und-festplatten/


    Ich kann mich nicht erinnern, was ich damals, vor sehr vielen Jahren bei der Installation ausgewählt hatte, wahrscheinlich habe ich einfach die Standardeinstellung übernommen. In meinem Account steht bei der zugehörigen Jiffybox "Empfohlener PV (5.4.x)", was auf die Option "PV-Kernel" auf der verklinkten FAQ-Seite hindeutet. Kann mir das jemand erklären, was das nun bedeutet? Weitere Versuche, irgendwas mit dem Jiffybox-Image hier bei Netcup zu importieren, sind sinnlos? Und ich brauche auch nicht zu versuchen, das Image vom .raw-Format ins qcow2-Format zu konvertieren, weil das auch nicht installierbar wäre?


    Alles von Grund auf neu zu installieren und zu konfigurieren, wäre halt sehr sehr aufwändig. Deshalb wäre es mit dem Image die eleganteste Lösung gewesen.

    PV klingt nach Paravirtualisierung. Da hast du keinen eigenen Kernel im Image.


    Zitat von andreas.

    Nebenbemerkung: Vor einem Jahr habe ich für einen Bekannten einen Xen-Container [...] hier zu Netcup erfolgreich umgezogen.

    Wie genau? Wahrscheinlich nicht durch einfaches Einspielen eines Images? Das war eher ein file-basierter Ansatz, oder?

    Zitat
    vielen Dank für Ihre Anfrage.

    Bedauerlicherweise verwenden unsere Server nur .qcow2-Dateien. Daher wird eine .raw Datei nicht auf den Server geladen.

    Da hatte der Mitarbeiter entweder keine Ahnung oder es hat sich inzwischen diesbezüglich was geändert.

    Bisher war das möglich.


    Es wird also wohl einen anderen Grund haben, dass es nicht geht. Die bisherigen Beiträge hier zeigen ja auch in diese Richtung.

    Zitat von andreas.

    Bei den sogenannten JiffyBoxen basierend auf Xen des Mitbewerbers war es möglich, sich noch vor dem Installationsprozess zwischen einer Container- und einer Voll-Virtualisierungs-Installation zu entscheiden.

    Reden wir hier wirklich vom gleichen Produkt? Jene JiffyBoxen mit dem Controlpanel ursprünglich unter admin.j****b**.de, die im Mai 2024 eingestellt werden? Ich nutzte die JiffyBox seit sie eingeführt wurden und das wäre mir vollkommen neu. Ich habe sogar noch einen Account und könnte nachher nachsehen :/


    Es geht wohl nicht um die neueren VPS des gleichen Anbieters? Die heißen (afaik) nicht JiffyBox :)

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

    Gefällt mir 1
    Zitat von andreas.

    Sihe mein Beitrag #3.

    Oh ja, sorry, das hatte ich übersehen. Aber so in etwa hatte ich mir das vorgestellt. Zunächst ein System zu installieren vor dem Übertragen der Daten, hätte ich nicht erwartet, aber das geht natürlich und erspart später den Kampf mit dem Bootloader.

    Der Kundensupport hat sich übrigens nicht mehr in der Lage gesehen, meine allgemeine Frage bzgl. KVW-raw-Images zu beantworten. Ich hatte nur allgemein nochmal nachgefragt, ob KVM-raw-Images weiterhin importiert werden können oder nicht, weil es mich allgemein interessiert hat. Aber ich hatte meinen Server zwischenzeitlich wieder gelöscht, und das reichte dem Support schon, um meine Supportanfrage abzuwürgen, ohne aufzuklären, ob nun weiterhin KVM-raw-Images importiert werden können oder nicht (obwohl diese allgemeine Frage nach dem allgemeinen Leistungsumfang der Netcup-Dienste überhaupt nichts damit zu tun hat, ob mein Server nun gelöscht ist oder nicht).


    Solche schlechten Erfahrungen mit einem Kundensupport habe ich wirklich selten gemacht. Ich erwarte hier keinen Support zur Administration von Servern, da das zu 100% meine Aufgabe ist, aber wenn es nicht mal dazu reicht, allgemeine Fragen zum Leistungsumfang zu beantworten, obwohl der Kunde hier durch sehr widersprüchliche Aussagen vor und nach der Bestellung in die Irre geführt wurde, dann geht das m.E. auf keine Kuhhaut mehr.


    Gleichwohl bedanke ich mich bei allen, die sich hier im Thread beteiligt haben. Zumindest hat es mir sehr geholfen, die Entscheidung zu fällen, dass ich einen komplett neuen Server einrichten muss, und alle Webseiten manuell umziehen muss, weil das mit einer Jiffybox-Imagedatei nicht funktionieren wird. Da ich dann bei einem neuen Server eine neuere PHP-Version nutzen muss, und viele Webseiten und Scripte deshalb ändern muss, damit sie überhaupt mit neueren PHP-Versionen laufen, wird das ein ziemlicher Aufwand, aber der ist wohl nicht mehr vermeidbar.

    Zitat von Keyser Soze

    Da ich dann bei einem neuen Server eine neuere PHP-Version nutzen muss, und viele Webseiten und Scripte deshalb ändern muss, damit sie überhaupt mit neueren PHP-Versionen laufen, wird das ein ziemlicher Aufwand, aber der ist wohl nicht mehr vermeidbar.

    Ich weiß nicht, welches Betriebssystem Du verwendest, aber z.B. bei Debian/Ubuntu gibt es über ein inoffizielles Repo auch die alten PHP-Versionen: https://deb.sury.org/


    Das geht notfalls zurück bis PHP 5.6 und stammt vom gleichen Maintainer, der schon seit Ewigkeiten die offiziellen PHP-Pakete von Debian pflegt. Ich würde es zwar nicht empfehlen, uralte und nicht mehr unterstützte Versionen ewig weiterzubetreiben, aber so kann man die unausweichliche Migration wenigstens auf einen längeren Zeitraum verteilen und alles in Ruhe parallel testen. Für die MySQL/MySQLi Umstellung gibt es übrigens einige Wrapper.


    Viel Erfolg!

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

    Einmal editiert, zuletzt von KB19 ()

    Gefällt mir 1
    Zitat von KB19

    Ich weiß nicht, welches Betriebssystem Du verwendest, aber z.B. bei Debian/Ubuntu gibt es über ein inoffizielles Repo auch die alten PHP-Versionen: https://deb.sury.org/

    Danke für den Hinweis. Ich verwende Debian. Das mit dem Sury-Repo ist mir bekannt, allerdings erst seit gestern, weil ich da detaillierter angefangen hatte zu recherchieren. Ich muss da aber noch mehr recherchieren, wie PHP damit genau eingebunden wird, weil eine meiner Webseiten sehr viel Traffic hat und PHP momentan als FastCGI läuft.


    Ich bin leider schon seit 2 Wochen erkrankt, weshalb es mit der ganzen Serverumzugsgeschichte nur sehr langsam vorwärts geht. Da die Deadline der endgültigen Jiffybox-Abschaltung schon Ende Mai ist, ist meine Tendenz momentan deshalb tatsächlich, es über das Sury-Repo zu probieren (selbst falls es weniger performant sein sollte als meine bisherige Lösung auf der Jiffybox). Die ganz neue Rootserver-Generation bei Netcup (die vorgestellt wurde einen Tag, nachdem ich meinen Netcup-Rootserver bestellt hatte ?() ist tatsächlich preislich so attraktiv, dass ich sogar zwei der günstigsten Rootserver bestellen könnte, und das zusammen trotzdem noch günstiger wäre als meine bisherige Jiffybox. Dann hätte ich erstmal nur zur "Rettung" meiner Webseiten einen ersten Server (mit weiterhin veraltetem PHP) und könnte dann in aller Ruhe im Anschluss eine Webseite nach der anderen für neuere PHP-Versionen fit machen und auf den zweiten Rootserver umziehen.

    Zitat von KB19

    installierst bei netcup das Betriebssystem Deiner Wahl neu und kopierst danach ausgewählte Konfigurationen und Daten manuell z.B. mittels rsync über SSH rüber.

    wenn ich das richtig verstanden habe ist diese J1ffyB0x ein container. müsste man also in einem proxmox zb zum laufen bekommen.


    einen container mit nginx davorsetzen und in einem dritten container ein gänzlich frisches setup beginnen und die inhalte von der J1ffyB0x kontinuierlich migrieren.

    Zitat von KB19

    Ich weiß nicht, welches Betriebssystem Du verwendest, aber z.B. bei Debian/Ubuntu gibt es über ein inoffizielles Repo auch die alten PHP-Versionen: https://deb.sury.org/

    Das geht notfalls zurück bis PHP 5.6 und stammt vom gleichen Maintainer, der schon seit Ewigkeiten die offiziellen PHP-Pakete von Debian pflegt.

    Auch wenn dort derzeit noch Pakete mit PHP 5.6 zu finden sind, würde ich in diesem Fall raten, schnellstens eine lokale Kopie von diesen zu archivieren, da diese Version laut Beschreibung des Repositories selbst dort eigentlich nichts mehr "verloren" hat:

    Zitat von Ondřej Surý: The main PPA for supported PHP versions with many PECL extensions
    Co-installable PHP versions: PHP 5.6, PHP 7.x, PHP 8.x and most requested extensions are included. Only Supported Versions of PHP (http://php.net/supported-versions.php) for Supported Ubuntu Releases (https://wiki.ubuntu.com/Releases) are provided. Don't ask for end-of-life PHP versions or Ubuntu release, they won't be provided.

    Hierzu: Supported Versions, Unsupported Branches (http://www.php.net)

    In der Vergangenheit wurden ältere Versionen bereits mit sehr kurzer Vorwarnung gelöscht; auch der obige Zusatz "most requested extensions" kann ggf. zu Problemen führen, so dass sich ein initialer Abgleich aller erforderlichen Bibliotheken/Module empfiehlt.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    2 Mal editiert, zuletzt von m_ueberall ()

    Gefällt mir 3 Ente gut, alles gut 1
    Zitat von m_ueberall

    Auch wenn dort derzeit noch Pakete mit PHP 5.6 zu finden sind, würde ich in diesem Fall raten, schnellstens eine lokale Kopie von diesen zu archivieren, da diese Version laut Beschreibung des Repositories selbst dort eigentlich nichts mehr "verloren" hat:

    Danke für den wertvollen Hinweis. Ich habe mir nun heute wieder einen Rootserver bestellt (diesmal Generation 11 anstatt 9.5) und damit begonnen, ihn abzusichern (Root-Login deaktivieren, Firewall etc). Dann werde ich das Thema Apache und dann insbesondere PHP als nächstes angehen, bevor irgendwann die genannten Pakete im Repo ggf. verschwunden sind.