Hänger unter Windows VM mit Sophos Endpoint

P

Petbotson

New Member
Proxmox Subscriber
Aug 30, 2024
15
5
3
Hallo Zusammen,

wir haben ein komisches Phänomen mit unseren Windows VMs und Sophos Endpoint Protection.

Die VM "hängt" für 1 bis 2 Sekunden sporadisch.
Windows loggt nichts und der Sophos Support sagt mir, dass es expected behaviour ist.

Wenn ich Sophos deinstalliere, habe ich keine Probleme mehr.
Wenn ich es wieder installiere, habe ich keine Probleme für ca. 2 - 3 Wochen und dann tauchen die wider auf.

In der VM sind die latest virtio tools installiert 0.1.266.

Hier einmal die VM config:
Code: 
agent: 1
bios: ovmf
boot: order=scsi0;scsi1;ide2
cores: 4
cpu: x86-64-v3
efidisk0: CC-ST03-OS-PVE:vm-105-disk-2,efitype=4m,pre-enrolled-keys=1,size=528K
ide2: none,media=cdrom
machine: pc-q35-9.0
memory: 12288
meta: creation-qemu=9.0.0,ctime=1722493290
name: hostname
net0: virtio=BC:24:11:99:0A:F1,bridge=CITEXT,firewall=1
numa: 0
ostype: win10
scsi0: CC-ST03-OS-PVE:vm-105-disk-1,discard=on,iothread=1,size=70G,ssd=1
scsi1: CC-ST03-OS-PVE:vm-105-disk-0,discard=on,iothread=1,size=40G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=517439a7-7b14-4049-a6c3-4ba6e90f5dc0
sockets: 1
tags:
vmgenid: d145f321-47ea-428f-be2e-231268a3304b


Und noch der Host:
Code: 
proxmox-ve: 8.3.0 (running kernel: 6.8.12-4-pve)
pve-manager: 8.3.2 (running version: 8.3.2/3e76eec21c4a14a7)
proxmox-kernel-helper: 8.1.0
proxmox-kernel-6.8: 6.8.12-4
proxmox-kernel-6.8.12-4-pve-signed: 6.8.12-4
proxmox-kernel-6.8.12-2-pve-signed: 6.8.12-2
proxmox-kernel-6.8.8-4-pve-signed: 6.8.8-4
proxmox-kernel-6.8.8-3-pve-signed: 6.8.8-3
proxmox-kernel-6.8.4-2-pve-signed: 6.8.4-2
proxmox-kernel-6.5.13-5-pve: 6.5.13-5
ceph-fuse: 17.2.7-pve3
corosync: 3.1.7-pve3
criu: 3.17.1-2+deb12u1
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx11
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.1
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.4
libpve-access-control: 8.2.0
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.0.10
libpve-cluster-perl: 8.0.10
libpve-common-perl: 8.2.9
libpve-guest-common-perl: 5.1.6
libpve-http-server-perl: 5.1.2
libpve-network-perl: 0.10.0
libpve-rs-perl: 0.9.1
libpve-storage-perl: 8.3.2
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.5.0-1
proxmox-backup-client: 3.3.2-1
proxmox-backup-file-restore: 3.3.2-2
proxmox-firewall: 0.6.0
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.3.1
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.7
proxmox-widget-toolkit: 4.3.3
pve-cluster: 8.0.10
pve-container: 5.2.2
pve-docs: 8.3.1
pve-edk2-firmware: 4.2023.08-4
pve-esxi-import-tools: 0.7.2
pve-firewall: 5.1.0
pve-firmware: 3.14-1
pve-ha-manager: 4.0.6
pve-i18n: 3.3.2
pve-qemu-kvm: 9.0.2-4
pve-xtermjs: 5.3.0-3
qemu-server: 8.3.3
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.6-pve1

Hat irgendjemand Sophos AV auf seinen Windows VMs zum Laufen bekommen?

Beste Grüße
~VIncent
 
Zwei Dinge die du testen könntest:
CPU Typ umstellen von : x86-64-v3 auf "HOST"
VirtioIO Treiber 0.1.248

Alternativen Virenschutz testen, Bsp: ESET, Avira
Ansonsten wäre da mit Sophos halt das "erwartete Verhalten" - was ja auf eine Routine in der AV Software deuten würde (evtl. mal ältere Programmversion prüfen).
 
Last edited:
  • Like
Reactions: Johannes S and Falk R.
Hi,

danke für das Feedback.
HOST als CPU Type haben wir bereits getestet.

Die Probleme hatten wir auch mit den virtio Treibern von 0.1.240, 0.1.248 und eben jetzt auch mit 0.1.266.
 
Also für den Fall, dass es noch jemanden betreffen könnte.
Ich habe nun nach Monaten mit dem Sophos Support herausgefunden, dass es ein Problem zwischen der Kombination AMD <-> KVM <-> Sophos ist.

Mittlerweile ist dieses Issue auch auf der Known Issues List von Sophos gelistet unter Central Endpoint/Server - Windows mit der Reference: WINEP-61407
https://docs.sophos.com/support/kil/index.html

Ob das Problem je gefixt wird, steht noch in den Sternen, aber immerhin habe ich die Ursache meiner Probleme gefunden.
 
  • Like
Reactions: Johannes S and ThoSo
Petbotson said:
Also für den Fall, dass es noch jemanden betreffen könnte.
Ich habe nun nach Monaten mit dem Sophos Support herausgefunden, dass es ein Problem zwischen der Kombination AMD <-> KVM <-> Sophos ist.

Mittlerweile ist dieses Issue auch auf der Known Issues List von Sophos gelistet unter Central Endpoint/Server - Windows mit der Reference: WINEP-61407
https://docs.sophos.com/support/kil/index.html

Ob das Problem je gefixt wird, steht noch in den Sternen, aber immerhin habe ich die Ursache meiner Probleme gefunden.
Click to expand...
Danke fürs teilen. Die Lösung ist doch einfach, Sophos gegen etwas austauschen, dass vernünftig funktioniert. ;)
 
  • Like
Reactions: Johannes S and cwt
Was testest Du für einen Hersteller ?
ich nutze ESET Produkte (bin Partner) und damit gerade auch in VM Umgebungen mit der Performance sehr zufrieden. Bisher keine Probleme.
 
Ich habe bisher (soll keine Werbung sein) mit ThreatDown von Malwarebytes recht gute Erfahrungen gemacht. Je nach Paket kann man auch Mobilgeräte absichern und überwachen.
 
Hi,
wir hatten bei einem Kunden ein ähnliches Problem. Leider wissen wir bis aber heute nicht, ob es 100%tig am sophos lag.

Seitdem wir die CPU auf x86-64-v4 gestellt haben, läuft alles.
 
lucavornheder said:
Hi,
wir hatten bei einem Kunden ein ähnliches Problem. Leider wissen wir bis aber heute nicht, ob es 100%tig am sophos lag.

Seitdem wir die CPU auf x86-64-v4 gestellt haben, läuft alles.
Click to expand...

Hallo,
leider können meine älteren AMD EPYC 7302P nicht den x86-64-v4 als CPU Type.
Es wäre aber super zu wissen, ob dass das Problem löst.

Hättest du Lust, das zu testen? Ich kann die die ganzen Tests geben, die Sophos mir gegeben hat.
Ist relativ simpel. Man muss in der Registry nur den Debug Mode aktivieren und dann kann man mit einem Powershell Befehl prüfen, wie lange diese DCR Runtime benötigt.
 
Petbotson said:
Hallo,
leider können meine älteren AMD EPYC 7302P nicht den x86-64-v4 als CPU Type.
Es wäre aber super zu wissen, ob dass das Problem löst.

Hättest du Lust, das zu testen? Ich kann die die ganzen Tests geben, die Sophos mir gegeben hat.
Ist relativ simpel. Man muss in der Registry nur den Debug Mode aktivieren und dann kann man mit einem Powershell Befehl prüfen, wie lange diese DCR Runtime benötigt.
Click to expand...
Das wird leider nicht so einfach. Wir haben auf das Cluster keinen durchgehenden Fernzugang und sind quasi nur auf Zuruf tätigt.

Das ursprüngliche Fehlerbild sah eigentlich nach einem Storagethema aus, zumal das storage iscsi/datacore ist. Der Kunde konnte mir allerdings bestätigen, das der Wechsel von v2/v4 alles langsam/schnell macht. Und mit v4 soll es sogar schneller sein, als mit esx auf der selben Hardware :D
 
  • Like
Reactions: Johannes S
Also für Alle, die mal prüfen wollen, ob Sie von dem Problem betroffen sind, hier mal eine kleine Schritt für Schritt Anleitung:

1. Deaktiviert den Manipulationsschutz über Sophos Central für die VM
2. Passt in der Windows Registry folgende Werte an, um das Debug Logging zu aktivieren von Sophos Endpoint Defense:
Code: 
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Sophos Endpoint Defense]
"DebugFacilities"=dword:00000080
"DebugLevel"=dword:00000001

3. Öffnet Powershell als Administrator und gebt folgenden Befehl ein
Code: 
gc 'C:\ProgramData\Sophos\Endpoint Defense\Logs\sed.log' -wait -tail 5000 | Where-Object {$_ -match "SED File Debug Current total" -or $_ -match "SED File Debug Max percent DB memory" -or $_ -match "Debug Starting backup of file records to the disk" } | ogv

4. Nach ca. 5 Minuten sollten die ersten Einträge zu sehen sein, wie lange der DCR Clean up benötigt um die Daten auf die Disk zu schreiben
1751892708576.png

Als Beispiel sehr ihr hier mal einen Screenshot. 08:30:44.378Z bis 08:30:46:849Z. Sind ca. 2,5 Sekunden in denen die VM einfach freezed, ohne dass das OS das mitbekommt.
Die Maximale Zeit, die ich in einem solchen Test mal gesehen habe, waren ca. 8 Sekunde bei einem Terminalserver mit 48GB RAM.

Ich hoffe das hilft jemandem.
P.S. ich hatte das Problem auch, wenn ich host als CPU Type angegeben habe.

Beste Grüße
Vincent
 
  • Like
Reactions: Johannes S
Falls es noch jemanden geben sollte, der von dem Problem betroffen ist. Ich habe mittlerweile einen Workaround vom Hersteller bekommen.

Man muss den Inhalt des sog. Data Content Records Ordners löschen. Hier eine kleine Anleitung:

  1. Manipulationsschutz über Sophos Central deaktivieren
  2. Navigiere in den Ordner C:\ProgramData\Sophos\Endpoint Defense\Data\Data Content Records
  3. Dort liegen ganz viele BIN-Dateien
    1752141214422.png
  4. Markiert alles und Löscht die Daten
  5. Server Neustarten
  6. Manipulationsschutz wieder aktivieren

Das Problem skaliert auch proportional. Also je mehr Daten in dem Data Content Records Ordner liegen, desto schlimmer sind die Hänger der VM.
 
  • Like
Reactions: Johannes S and Falk R.
You must log in or register to reply here.
Top Bottom