teletubbieland

Moin,

hab's gelöst bekommen:

Die Win7 VMs waren tatsächlich fehlerhaft. Zumindest 2 davon.

Nachdem ich sfc /scannow und chkdsk angewandt habe, sind die Fehler weg.

Allerdings verstehe ich nicht, warum in den VMs selbst nix im Eventlog stand, aber der RAID Controller eine Inkonsistenz festgestellt hat

Auf jeden Fall Danke für Eure Unerstützung !

vor 3 Minuten schrieb djmaker:

Ich würde auf dem RAID 1 für die Win7 VMs entweder im Controller eigene Volumes oder im Server-OS eigene Volumes machen, auch wenn die Ursache damit nicht geklärt ist.

Das hatte ich gemacht. Der Erfolg war, dass die Fehler nur auf dem RAID-Verbund der Win7 VMs kam.

Somit konnte ich das Problem ja eingrenzen.

Gerade eben schrieb Nobbyaushb:

Speicher wird grundsätzlich nicht dynamisch zugewiesen!

Ich meine RAM, du auch?

Ja

Bei Servern vermeide ich eine dynamische Zuweisung.

Was spricht bei Workstation-VMs dagegen?

vor 7 Minuten schrieb NilsK:

Moin,

 

was sagen denn die Win7-VMs selbst dazu? Die werden doch sicher auch was davon mitbekommen. Vielleicht hilft das weiter.

 

Gruß, Nils

 

Nix, was auf HDD-Fehler zeigt. Allerdings gibt es wohl ein Problem mit der dynamischen Speicherzuweisung.
Ich stelle das mal auf statisch um.

vor 9 Minuten schrieb cj_berlin:

Moin,

meinst Du die Consistency Checks am RAID-Controller? Ist Hyper-V-seitig NTFS oder ReFS im Einsatz?

Ja, vom Controller. Dateisystem steht auf NTFS.

Moin,

ich habe auf einem Windows 2022'er Server verschiedene VMs laufen (Neues System Supermicro-Board + LSI-Controller).

Nachdem die SSDs durchgetauscht wurden (inkl. Herstellerwechsel) gab es immer constistency check errors bei den SSDs auf denen die VMs laufen.

Habe jetzt einen neuen RAID1-Verbund aufgesetzt und ein paar VMs umgezogen mit dem für mich überraschenden Ergebnis, dass die errors dort auftauchen wo die Win7-VMs laufen.

Zur Erklärung: Der Kunde hat eine uralte Software (und nein - ich konnte ich in den letzten 20 Jahren nicht davon überzeugen, dass das Mist ist) für die diese VMs benötigt werden.

Hat jemand eine ähnlich Erfahrung gemacht, bzw. eine Idee, was bei einer Win7 VM zu ändern ist, damit das nicht mehr auftaucht ?

vor einer Stunde schrieb JustTheNextUser:

Hallo,

 

kurzes Feedback.

Nach ausgiebigen Tests scheint es nun wie gewünscht zu funktionieren.

RSS/RSC/LSO deaktivieren hat wohl geholfen.

Vielen Dank für die Unterstützung!

 

Viele Grüße

Sehr schön

Es geht beide Male um die Auswertungen.

Das Eine ist Automobilbranche mit SQL-Server (Kein MS)

Das Andere eine Objektverwaltungs-SW mit MS SQL

Ob das jetzt schlecht programmiert ist, was ich nur vermuten, aber man hält sich im Zweifel an die Vorgaben, damit man nicht ewige Diskussionen führt

Du wirst Dir da die Zähne ausbeissen.

Klräre den Kunden darüber auf, dass er um ein Update nicht rum kommt.

Gerade eben schrieb NilsK:

 

Ich würde den Terminalserver neu machen und den SQL Server separieren.

 

 

 

Moin,

das sollte vorher mit Inloox abgesprochen werden.
Habe 2 Installationen verschiedener Hersteller, die den SQL auf dem TS haben wollen wg. performance.

Moin,

ich schau vor Allem darauf, wie viele User auf die Systeme Zugriff haben.

In kleineren Betrieben mit einer simplen Domänenarchitektur und nur Fileserver reichen tatsächlich noch HDDs.

Allerdings verbaue ich allein wegen der Wartungsarbeiten mindestens S-ATA SSDs.

Exchange läuft darauf auch performant (zumindest in KMU Bereich).

Wenn komplexere Systeme zum Einsatz kommen orientiere ich mich gleich in Richtung NVMe.

Hoffe, das hilft ein wenig.

vor 2 Minuten schrieb Dutch_OnE:

Das ist ein HP Server. Müsste ich mal über ILO nachschauen. VM hat 2 vCPU und 8GB Speicher. Netzwerkkarte ist mit anderer VM geteilt. 

VM liegt auf einem RAID5 SAS Laufwerk mit HDDs, also keine SSDs.

Zum Austesten würde ich zuerst 4 vCPUs vergeben und wenn das nicht reicht, auf eine SSD verschieben.

Wenn das immer noch nicht besser ist, eine neue VM aufsetzen.

vor einer Stunde schrieb Dutch_OnE:

ich möchte das hier nicht kapern, daher möchte ich kurz mein Problem erklären und wenn das damit nicht zusammenhängt, mache ich nochmal einen neuen T. auf.

Bei mir dauert das Starten, Anmelden und Arbeiten mit einer Windows 10 22H2 VM sehr lange, bzw. ist sehr träge. 

 

Energieoptionen habe ich auf Höchstleistung gestellt, VMQ, RSC und LSO nach Vorgabe deaktiviert. An der NWK im Hyper-V, sowie am Guest. (Sofern die Einstellungen vorhanden waren, bzw. einiges war schon deaktiviert)

 

Bitte um Rückmeldung, ob ich hier weiter mitschreiben kann, oder lieber as Thema neu eröffne.

Ketzerische Frage: Wie viele CPU-Kerne hast Du der VM gegeben ?

dann schalt doch einfach mal das LSO aus und guck was passiert

Bei der Pysikalischen und Virtuellen Maschine die ganzen offloads deaktivieren.

Bevor Du die Clienst testest, teste doch mal wie die Geschwindigkeit zwischen VMs ist.

Wenn die gut ist, dann hast Du ein 'externes' Problem.

Du kannst die disablen, solltest danach die VM aber neu starten.

Kenne keine Komplikationen.

Hast Du bei den NICs RSC, LSO und VMQ deaktiviert ?

Moin,

welche Serverversion setzt Du denn ein ?

Unternehmensgröße 1-200 MA.

Und steter Tropfen höhlt den Stein.

Spamassassin habe ich auch im Einsatz aber er wird immer zahnloser nach meiner Einschätzung, so dass man an professionelleren Lösungen nicht mehr vorbei kommt.

Moin,

persönlich halte ich 1+2 für sinnlos, da die Benutzer Meldungen gerne einfach weg klicken und eben sich somit auch an Markierungen gewöhnen und Diese überlesen.

Punkt 3 führe ich stetig durch und habe die meisten Anwender soweit, dass sie rückfragen, wenn sie sich nicht sicher sind.

Abgesehen davon rechnet sich langfristig die Anschaffung einer professionellen Lösung wie NoSpamProxy o. Ä.

Moin,

wenn ich mich recht entsinne, hatte ich das mal bei einem Kunden.

Dort war das Problem, dass nicht alle DCs synchron waren (mehrere Standorte).

Moin,

die DCs müsse sich gegenseitig als primären DNS haben. Dann geht das.

Kontrollieren kannst Du die Replikation mit repadmin.

Sorry Essentials als SBS gelesen.

Dürfte aber aber an der Aussage nichts ändern.

N'Abend.

Die Migration ist die gleiche, wie bei Standard.

Im Nachgag kann man die Essential-Spezifischen Gruppen usw. entfernen.

Der alte SBS kann als Member-Server weiterbetrieben werden.

Die Einschränkung beszieht sich nur auf einen zweiten SBS.

Sieht sehr nach Systemboard aus.

Ein RAID wird auch nicht angezeigt...

Abschließend zu diesem Thread noch die Lösung:

Es lag tatsächlich am dem Schutzmodul von Panda, welches den SCL nicht mehr gesetzt hat.

Die Text-Markierung kam von einer anderen Maschine, daher die erfolglose Analyse.

Werde mich jetzt aber dennoch Richtung Nospamproxy oder Ähnlichen orientieren.