Beiträge von remote

    Das mit dem "feature" kann aber nur ironisch gemeint sein. Lustig ist das nämlich nicht, jedesmal vor einem reboot die Angst zu haben, den bootloader reparieren zu müssen.


    Stimmt... deswegen läuft auf dem neuen vServer nun auch Red Hat, nicht SUSE.
    Schade drum, aber ist mir das Frickeln nicht wert :)

    It's not a bug, it's a feature.


    1. vServer mit openSUSE Leap 42.1 minimal image provisionieren
    2. zypper update -y && shutdown -r now
    3. bootet nicht mehr (GRUB _)


    … reproduzierbar.
    Hätte jetzt gedacht, dass man bei obigem setup noch nicht viel falsch machen kann, aber so täuscht man sich :)

    Ich betreibe ähnliches auf einem Root L v5 (Jira und Gitlab hinter Apache) und würde sagen, dass die Performance ok ist. Bottleneck ist die CPU obwohl es beim L ja dedizierte cores sind und keine vCores. Bei Jira kommt es sicher auch darauf an, wie komplex die Permissions sind und um wie viele Tickets es geht (das zieht die Leistung eher in den Keller als 1–2 zusätzliche Sessions).
    Auf welcher Hardware läuft der Kram denn momentan?

    Also ich weiß nicht wie du das siehst, aber mir sagt diese Fehlermeldung folgendes: …


    Danke für die Übersetzung der Fehlermeldung.
    Vielleicht war ich etwas undeutlich – mein Problem ist nicht das Verständnis der englischen Sprache, sondern die Frage, weshalb diese Fehlermeldung geworfen wird.
    Das sich der Support mit der eigenen Software auskennt ist naheliegend. Dass man in einem Forum mit dem Namen "VCP (vServer Control Panel)" Fragen zu Problemen mit selbigem System stellt aber eigentlich auch.
    Falls also jemand Vorschläge zur Eingrenzung des Problems hat, freue ich mich über Hilfe.


    Hier noch als Nachtrag die Übersicht der Volumes auf der Snapshot Quelle:


    Code
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/vda2       154G   21G  125G  15% /
    tmpfs           3,9G     0  3,9G   0% /dev/shm
    /dev/vda1       190M  107M   73M  60% /boot

    Ich versuche gerade einen Snapshot von einem alten vServer auf einen neuen vServer einzuspielen (beide mit 160 GB quota gem. Vertrag).
    Der Import schlägt allerdings fehl:


    Zitat

    Source file too large. Cannot copy to disk.



    In der Annahme, dass ggf. vor Import des Snapshots die Partition vergrößert werden muss, habe ich dies wie im wiki beschrieben ausgeführt:



    Hier wird eine Cylinder Range von 1 bis 2 vorgeschlagen … das erscheint mir etwas knapp.
    Werte >2 werden als "out of range" abgelehnt. ;)


    Kann mir jemand erklären was hier falsch läuft?

    Vielen Dank für die Antwort.


    Allerdings fehlen auch zwei CPU-Cores


    In dem Punkt kann ich nicht ganz folgen, da ich davon ausging, dass 2 "echte" Cores ebenfalls 4 parallele Threads bieten würden, nur etwas näher an der Hardware?


    Bezüglich des Aufwands:
    Gehe ich recht in der Annahme, dass es möglich sein sollte ein Image zu exportieren und im neuen Server zu importieren (für den Umzug von Saturn KVM auf Root-L 5 oder Root XL 5)?

    . . .
    - Saturn KVM Root-L 5
    CPU 4 x vCore 2 echte Cores a 2.0 Ghz
    RAM 8 GB 8 GB
    Disk 160 GB HDD Raid 50 160 GB SSD Raid 10
    Preis 22,99 € 15,99 €



    SaturnKVM Datenblatt: netcup.de - Produktdetails
    Root Server L 5 Datenblatt: netcup.de - Produktdetails


    Im Saturn ist wohl eine E5645 / 2.40GHz verbaut (behauptet jedenfalls der Host), während es bei den neuen Server ein E5-2620 / 2.0 Ghz ist.
    Von der Leistung erstmal recht ähnlich (E5-2620 hat trotz niedrigerem Takt leicht die Nase vorn: PassMark - CPU Performance Comparison )


    Ich kann hier keinen richtigen Nachteil entdecken, ausser, dass ein Upgrade vermutlich nicht möglich und der Umweg über Kündigung und Neuvertrag samt IP-Wechsel anfallen würde.
    Übersehe ich da etwas?

    Gibt es die /etc/rc.d/rc.sysinit.vserver bei Dir?

    Ja, die gibt es:


    Code
    #! /bin/sh
    
    
    
    
    rm -f /var/lock/subsys/* /var/run/* /var/run/*/* 2>/dev/null
    true




    edit:


    Ich habe nun probeweise mal die frühen "console output" Statements die ich im init Ablauf finden konnte auskommentiert
    (primär /etc/init/rc.conf):



    Nun wird nicht mehr versucht auf eine nicht initialisierte(?) console zuzugreifen und der init Vorgang läuft wieder vollständig ab.
    Soviel zum "was" - das "warum" gibt mir noch Rätsel auf ;)





    edit 2:


    Nach wie vor besteht allerdings das Problem, dass mingetty nicht auf die Beine kommt - das messages log wächst schnell:


    Code
    Mar 11 23:55:18 vserver /sbin/mingetty[28818]: tty[1-6]: No such file or directory
    Mar 11 23:55:23 vserver init: tty (/dev/tty[1-6]) main process (28818) terminated with status 1
    Mar 11 23:55:23 vserver init: tty (/dev/tty[1-6]) main process ended, respawning
    Mar 11 23:55:23 vserver /sbin/mingetty[28927]: tty[1-6]: No such file or directory
    Mar 11 23:55:28 vserver init: tty (/dev/tty[1-6]) main process (28927) terminated with status 1
    Mar 11 23:55:28 vserver init: tty (/dev/tty[1-6]) main process ended, respawning

    Nachdem ich bereits eine andere Centos 6.3 Installation problemlos auf
    6.4 aktualisiert habe, war ich leichtsinnig genug den zweiten vServer
    dann ohne vollständiges Backup zu updaten. Murphy hat aufgepasst und nun
    kommt der vServer beim init nicht auf die Beine:



    Der
    inline code funktioniert (zumindest in meinem browser) leider nicht so
    recht, daher Prozessliste und messages log auch via pastebin:
    http://pastebin.com/0HuHLJ7Q


    Im
    inittab ist runlevel 3 als default gesetzt, insofern wundert mich das
    auftauchen des splash-manager ein wenig. Ich nahm eigentlich der wird
    für das GUI benötigt.


    Wenn mir jemand eine Tipp geben kann wie
    man den init process nun sinnvollerweise debugged oder einen
    entsprechenden Link zu hilfreichen mans parat hätte, wäre mir sehr
    geholfen.


    Vielen Dank