Hyper V logische Prozessoren mehrfach in VMs verwenden

[Dutch_OnE 36]

Moin,

 

wenn ich den Link hier richtig verstanden habe:

Virtuelle CPUs (vCPU) für VMs unter VMware und Hyper-V konfigurieren | WindowsPro

 

kann ich mit meinem "Spielsystem" 

1 CPU, 4 Kerne, 4 logische Prozessoren

 

2 VMs jeweils 4 vCPUs zuteilen oder gibt das mit Überbuchung Probleme?

 

Gruß DO

[Nobbyaushb 1.359]

Moin,

zusätzlich siehe hier

https://www.faq-o-matic.net/2011/01/26/hyper-v-sizing-virtuelle-und-echte-cpus/

 

Ich habe ein Ratio von etwa 4 zu 1

[Dutch_OnE 36]

Alles klar. Vielen Dank.

[cj_berlin 1.138]

vor 1 Stunde schrieb Dutch_OnE:

 

oder gibt das mit Überbuchung Probleme?

Probleme mit der CPU-Überbuchung sind solange subjektiv wie Du für die VMs keine SLA zu erfüllen hast. Aber das typische Überbuchungsverhalten bei CPU sieht wie folgt aus:

• kaum CPU-Verbrauch laut Task-Manager am Host
• kaum CPU-Verbrauch laut Task-Manager im Gast
• und trotzdem ist die Performance im Gast ungenügend.

Du kannst es auch messen, es gibt einen Perfmon-Counter namens "Hyper-V Hypervisor Virtual processor\CPU Wait time per dispatch" in Nanosekunden. Solange das nicht in Richtung halbe Millisekunde tendiert, sondern unter 200.000 bleibt, sollte alles soweit in Ordnung sein, zumindest aus Sicht der VMs...

 

Und da es keine Möglichkeit gibt, den Host-Bedarf an CPU zu reservieren, kann es passieren, dass CPU-Überbuchungsprobleme sich zuerst als wahrgenommene Storage- oder Netzwerkprobleme äußern.

[NilsK 2.785]

Moin,

 

man muss bei dem Thema immer unterscheiden, von welchen Umgebungen man spricht. Natürlich kann sich CPU-Überbuchung negativ auswirken, sie kann aber auch völlig irrelevant sein. Meine These ist: In vielen realen Umgebungen ist sie irrelevant. Da braucht man sich um die CPU-Last keine Sorgen zu machen. Auf dieser Perspektive beruht meine oft zitierte Darstellung auf faq-o-matic.net. Wohlgemerkt: In vielen Umgebungen, nicht in allen.

 

Es gibt Anwendungen, die CPU-intensiv sind. Da gelten die simplen Betrachtungen dann nicht mehr, da muss man großzügiger dimensionieren oder mit größerem Aufwand messen und entwerfen. Das ist so wie bei allen simplen Betrachtungen - sie gelten eben nur in simplen Fällen.

 

Trotzdem ist mir meine "Passt-schon"-Haltung wichtig, weil ich im Mittelstand und in kleinen Umgebungen oft beobachte, dass sich Admins viel zu viele Sorgen machen, ihre Systeme viel zu groß dimensionieren und viel zu viel Geld, Energie, CO2 usw. aufwenden, wo es gar nicht nötig ist. Immerhin war eine wichtige Idee bei der Virtualisierung mal, Ressourcenverschwendung zu reduzieren.

 

Bezogen auf die Eingangsfrage und deren konkretes Szenario: Das wird kein Problem darstellen. Sollte es tatsächlich in beiden VMs Tasks geben, die gleichzeitig alle vier vCPUs voll und dauerhaft auslasten, dann wird es sich ggf. negativ bemerkbar machen. Sonst nicht.

 

Gruß, Nils

 

[Dutch_OnE 36]

Ersteinmal möchte ich mich bei allen hier bedanken. Da eine der beiden VMs, sowie das Host System sehr viel Leerlauf haben, sollte sich das Sharing gut aufteilen und zu keinen Leistungsproblemen führen. SLAs mit Performance Garantien sind nicht vorhanden.

[cj_berlin 1.138]

vor 6 Minuten schrieb Dutch_OnE:

 Da eine der beiden VMs, sowie das Host System sehr viel Leerlauf haben, sollte sich das Sharing gut aufteilen und zu keinen Leistungsproblemen führen. 

Achtung! Genau das ist (nicht in Deinem Lab natürlich, in der realen Welt) der Trugschluss, dem mit am häufigsten aufgesessen wird. Wenn Du zwei VMs auf einem Host hast, und jede von ihnen hat so viele vCPUs wie der Host Hyperthreading-Kerne hat (*), und die VMs sind im Hypervisor gleich gewichtet, bekommt jede VM exakt 50% der CPU-Zeit, ganz gleich, wieviel die andere VM zu tun hat. Es kann aber durchaus ausreichend sein und im Betrieb nicht auffallen. 

 

Ist also von vornherein bekannt, dass eine VM CPU-mäßig mehr zu tun hat als die andere, kann es sich lohnen, die VMs zu gewichten. Das muss man aber akribisch dokumentieren und auch bei der Ressourcenplanung  für die Weiterentwicklung der Plattform berücksichtigen.

 

(*) genauer gesagt, VM1.ProcessorCount + VM2.ProcessorCount > Host.HTCoreCount so dass nicht beide VMs gleichzeitig CPU kriegen können.

[NilsK 2.785]

Moin,

 

jupp. Das ist der Effekt, den ich in meinem oben bereits zitierten Artikel in dem Abschnitt "Immer rein - kost ja nix!?" beschrieben habe.

 

Aber weil Evgenij ja zu Recht auf die Grenzen dieser simplen Betrachtungen hinweist: Beide hier zitierten Artikel sind über zehn Jahre alt. Sie treffen im Grundsatz immer noch zu, berücksichtigen aber nicht, was sich im Detail in den letzten Jahren getan hat. Und sie sind ausdrücklich nicht für SLA-, Enterprise- oder Spezialanforderungen gedacht.

 

Gruß, Nils