UCS-Server (VM) extrem langsam seit Proxmox darunter liegt

[pixel24]

Hallo zusammen,

ich habe den UCS-Server als VM unter Proxmox 6.1.5 installiert. Die Hardware ist:

2 x Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz
128GB RAM registered ECC
LSI SAS 9361-8i RAID-Controller (12GB/s)
4 x 2TB SSD (RAID5)

Der Zugriff auf den UCS - egal ob auf Samab oder NFS - ist unterirdisch (11MB/s). Zuvor lag ein UCS als VM-Host (gleiche Hardware) darunter und da war gerade NFS um Faktor 10 schneller. Ich habe den UCS nicht migriert sondern unter Proxmox neu installiert. In Proxmox liegt LVM-Thin als Storage-Konzept zu Grunde. Die virtuellen HD's sowie die NIC sind VIRTIO.




Den UCS habe ich wie immer installiert -> Neue UCS-Domäne -> Benutzer angelegt -> Freigabe angelegt. Da habe ich noch nie mehr tun müssen.

Wo kann ich mit der Problemsuche ansetzen?

Viele Grüße
pixel24

 

[dietmar]

RAID5 is extrem langsam für virtualisierung.

 

[aaron]

Als ersten Versuch der evtl. ein bisschen was bringt würde ich die Festplatten von Virtio Block auf SCSI mit dem Virtio SCSI Controller (der eh schon gesetzt ist) umstellen.

Das sollte die Festplatten der VM performanter machen. Nicht vergessen die Boot Order in den Einstellungen der VM anpassen.

 

[pixel24]

RAID5 is extrem langsam für virtualisierung.

Naja, vorher war es auch RAID5 .... per NFS 90-120 MB/s .... so langsam finde ich das nicht bzw. Würde mir völlich reichen

 

[pixel24]

Als ersten Versuch der evtl. ein bisschen was bringt würde ich die Festplatten von Virtio Block auf SCSI mit dem Virtio SCSI Controller (der eh schon gesetzt ist) umstellen.

Das sollte die Festplatten der VM performanter machen. Nicht vergessen die Boot Order in den Einstellungen der VM anpassen.

teste ich gleich. Installaiere gerade noch eine Test-VM mit Ubuntu-Desktop um das LAN (physisch) als mögliche Fehlerquelle raus zu nehmen.

 

[dietmar]

Naja, vorher war es auch RAID5 .... per NFS 90-120 MB/s ....

Schon, aber vorher hast Du halt nicht virtualisiert. Die VMs produzieren ganz andere Zugriffsmuster, und RAID5 is dann halt langsamer.

 

[dietmar]

Auch die Cache Einstellungen bei deinen Benchmarks sind vermutlich verschieden (stell mal den Cache Modus der VM disk auf WriteBack ...)

 

[pixel24]

Schon, aber vorher hast Du halt nicht virtualisiert. Die VMs produzieren ganz andere Zugriffsmuster, und RAID5 is dann halt langsamer.

Doch, der Virtualisierungs-Host war eben nur ein UCS-Member anstatt Proxmox …. steht aber oben

 

[pixel24]

ich habe jetzt en ganz anderes Problem. Wie kann ich in einer VM die Disk einer anderen VM temporär einbinden?

Denn nach dem Umstellen auf SCSI bootet der UCS nicht mehr. Ich muss also die virtuellen Disks in einer anderen VM mounten um zu prüfen ob sich da UUID's geändert haben ,,,

 

[pixel24]

Auch die Cache Einstellungen bei deinen Benchmarks sind vermutlich verschieden (stell mal den Cache Modus der VM disk auf WriteBack ...)

WriteBack ist bereits aktiv. Nutze ich immer

 

[pixel24]

Also der Umgang unter Proxmox mit den Device-Bezeichnungen ist grauselig. Unter einem Standard KVM-Host mit libvirt kommen in der VM die Geräte in der Reihenfolge an wie ich sie hinzufüge … als vda, vdb … Unter Proxmox kommen die immer anders. Im Endeffekt habe ich mir durch das einmalige aushängen der Disks, ändern auf SCSI und wieder einhängen mein System kaputt gemacht.

Einfach wieder zurück VirtIO-Block hat auch nicht geklappt. Wenn dann wenigstens die Lokalisierung wenn man ein LiveCD startet richtig funktionieren würde aber da kommt irgend ein Tastaturlayout an aber nicht das was man konfiguriert. Unter LibVirt kein Problem bisher damit gehabt.

 

[aaron]

Hast du die Festplatten so geändert, dass sie wieder in der gleichen Reihenfolge wie am Screenshot in der Config stehen (scsiX mit x gleich 0 bis 2)?

Die Startreihenfolge in den Optionen der VM hast du entsprechend angepasst, so dass von scsi0 gebootet wird?

Wenn dem so ist sollten die Festplatten in der richtigen Reihenfolge in der VM auftauchen.

Denn nach dem Umstellen auf SCSI bootet der UCS nicht mehr. Ich muss also die virtuellen Disks in einer anderen VM mounten um zu prüfen ob sich da UUID's geändert haben ,,,

Die UUIDs der Partitionen ändern sich nicht wenn man den Controller der Festplatten ändert. Wie äußert sich das nicht mehr booten?

Wenn eine VM nicht will und die äußeren Faktoren wie zB die Startreihenfolge passen ist der einfachste Weg die VM von einer LiveCD, zB Ubuntu, zu starten anstatt die Festplatte an eine bestehende VM anzubinden.

 

[pixel24]

Hast du die Festplatten so geändert, dass sie wieder in der gleichen Reihenfolge wie am Screenshot in der Config stehen (scsiX mit x gleich 0 bis 2)?

Die Startreihenfolge in den Optionen der VM hast du entsprechend angepasst, so dass von scsi0 gebootet wird?

Wenn dem so ist sollten die Festplatten in der richtigen Reihenfolge in der VM auftauchen.

Habe diese wieder so gesetzt wie sie m Screenshot waren VirtIO und die Reihenfolge ist exakt identisch.

Ja, die UUID's sind gleich. Aber er bootet nur noch in den Notfall-Modus und hier habe ich das Problem das das Tastaturlayout nicht passt was überigens in allen VM's (PFSense, UCS, SystemRescueCD …) so ist

 

[pixel24]

Ich habe nochmal alles ausgehängt und als VirtIO wieder in der richtigen Reihenfolge eingehängt. Die VM bootet. Nochmal alles ausgehängt und als SCSI (gleiche Reihenfolge) eingehängt. Damit bootet er nicht.

 

[pixel24]

auch wenn ich das Keyboard-Layout irgendwie noch lösen muss, wenn eine VM streikt muss ich ja mittels REscueCD-ISO booten und das OS reparieren können. Ich habe das Geschwindigkeits-Problem mal weiter eingegrenzt. Eine Ubuntu 19.10-VM auf dem gleichen VM-Host installiert, in die Domäne gejoint und per NFS an den UCS-Master der ja auch als VM läuft angebunden. Hier lese ich mit 600 MB/s vom NFS-Server.
Hier habe ich jetzt keinen Vergleichswert zu vorher aber dass dürfte ja völlig in Ordnung sein.

Für die Anbindung der VM's untereinander habe ich auf dem PVE eine Bridge eingerichtet und die ist mit dem LAN-Port der NIC und dem Switch verbunden. Dies hatte ich unter UCS als KVM-Host aber genauso. Könnte hier irgendwo das Problem liegen, also in der Bridge-Config? Der Switch (physisch) und Kabel haben sich ja nicht verändert