Mit so einer Temparatur hast du hoffentlich den nc-Hitzerabatt genutzt
Den habe ich leider verpasst 
Die nächste Aktion kommt bestimmt. Vielleicht dann sogar mit Servern der Generation 9 
Beiträge von Cydex
-
-
Eh kühl.. 28 hatte es gestern nordseitig im Erdgeschoß bei uns - allerdings bei offenen Fenstern und Türen.
Das ist ordentlich
die Südseite ist dann vermutlich deutlich wärmer 
da wohnt man doch lieber in der Mitte - 2 unter mir und 2 über mir
Die goldene Mitte
Wenn das Wohn- / Schlafzimmer gen Norden ausgerichtet ist lässt es sich dann doch einigermaßen aushalten ohne das man schmilzt
-
Den geladen Treiber kannst du dir mit dmesg | grep scsi anzeigen lassen.
SCSI:
[ 4.835669] scsi host0: ata_piix
[ 4.860808] scsi host1: ata_piix
[ 4.992726] scsi host2: Virtio SCSI HBA
[ 4.995224] scsi 2:0:0:0: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5
Die Festplatte heißt dann sda:
[root@sysresccd ~]# ls -l /dev/ | grep sd
brw-rw---- 1 root disk 8, 0 Jul 27 15:12 sda
VirtIO:
[root@sysresccd ~]# dmesg | grep virtio
[ 5.579211] virtio_blk virtio1: [vda] 268435456 512-byte logical blocks (137 GB/128 GiB)
[ 7.903422] virtio_net virtio3 ens6: renamed from eth1
[ 7.961721] virtio_net virtio0 ens3: renamed from eth0
Bei VirtIO heißt diese vda:
[root@sysresccd ~]# ls -l /dev/ |grep vd
brw-rw---- 1 root disk 254, 0 Jul 27 15:18 vda
Generell würde ich aber auch den Support anschreiben, dass diese den Server mal prüfen.
Vielleicht ist auch etwas an der VM kaputt.
-
Das wäre eine willkommene Abwechslung
Eine Wohnung direkt unterm Dach macht im Sommer keinen Spaß :-/
-
-
Als "oldshool" Trending-Tool nutze ich seit Jahren Munin mit einer zentralen Instanz.
Diese ist mit den Munin-Nodes über SSH-Tunnel (Portforwarding) verbunden und pullt sich die Daten regelmäßig.
Läuft sehr stabil und dank autossh muss ich im Fehlerfall nicht jede Verbindung neu herstellen wenn mal eine ausfällt
Als "richtiges" Monitoring Tool hat sich bei mir Check_MK (ebenfalls über SSH) bewährt.
P.S:
Hallo an alle, als längerer stiller Mitleser habe ich mich nun entschlossen auch den ein oder anderen Beitrag zu leisten.
Die Community hier bei Netcup ist echt super
-
Den Fehler kann ich leider nicht reproduzieren :-/
Auf einem Root Server Spring 2019 lassen sich die Treiber einwandfrei einbinden.
Um was für ein Produkt handelt es sich denn?
Sind im SCP die Optimierungen für Windows ausgewählt?
Du könntest auch versuchen die Festplatte über das SCP komplett zu löschen (Achtung, ggf. das vorhandene Windows sichern), damit diese bei der Installation leer ist. Es könnte sein, dass die vorherige Windows Server 2016 Installation das Problem verursacht (Kenne mich in der Windows Server Welt allerdings zu wenig aus).
Und dann nochmal alles von vorne:
1. Server komplett herunterfahren.
2. Als Treiber SCSI auswählen
3. Server wieder starten
4. Treiber vioscsi auswählen
Vielleicht hilft dies.
VG
-
Ich habe es gerade auf einem meiner Testserver ausprobiert und dort funktioniert es ohne Probleme (wechsel VirtIO und SCSI). Die Festplatten werden nach einlegen der Treiber ISO entsprechend geladen.
Verwendet habe ich die von Netcup bereitgestellte Windows Treiber ISO.
Hast du den Server komplett heruntergefahren und wieder gestartet nachdem du zwischen VirtIO und SCSI gewechselt hast? Ein Reboot aus der VM heraus reicht nicht aus.
VG
-
Hallo Hitman,
hab es Aktuell wieder auf SCSI gestellt
hast du nach der Änderung den Order vioscsi von der Treiber CD bei der Installation ausgewählt?
Wenn im SCP SCSI gewählt ist sollte er die passenden Treiber finden.
VG
Cydex
-
Ein Backup war auch mein erster Gedanke.
Vermutlich hat hier ein zusätzlich installiertes Paket Einträge in der crontab erzeugt.
Wie sieht denn die /etc/crontab aus, bzw. gibt es separate Dateien unter /etc/cron.d oder /etc/cron.daily die zu dem Zeitpunkt ausgeführt werden?
Ggf. wird auch zu dem Zeitpunkt etwas in das Syslog geschrieben.
-
So Tasse bestellt
Die letzten Male hatte ich kein Glück
