[VM] Gevirtualiseerde gameserver hangt

[Tead]

Ik ben al een tijdje gechameerd van Virtualisatie. Het gemak van snel een backup maken en het eindeloos kopieren van gehele VM machines tussen verschillende servers wegen bij mij op tegen het (klein) stukje performance verlies. Dacht ik ...

Laatst werd mij gevraagd of ik een aantal gameservers wil hosten op een Lan party. Ik had nog een server over waar Debian 4.0 met VMWare Server 1.0.4 op draaide en binnen de kortste keren had ik een nieuwe VM ook met Debian 4.0 en een Call of Duty 4 gameserver draaien. Nu merkte ik op dat de gameserver af en toe "hangt". Het gaat maar om nutteloze milliseconden maar bij een gameserver wordt dat toch wel erg irritant. Aan de ping ligt het niet, deze schiet ook niet omhoog als hij hangt. Zelf heb ik er last van als ik via LAN speel maar ook andere mensen die over het internet verbinding maken naar de gameserver. Ik heb al geprobeerd de VM op 1 CPU te laten draaien ipv 2 en meer geheugen te alloceren. Ik heb ingesteld dat het geheugen alleen in RAM blijft en niet wordt geswapt. Ook goed om te weten is dat er nog een andere VM op staat maar het probleem blijft bestaan na het uitschakelen van deze machine. Ook bij een clean boot met alleen de gameserver aan geeft het zelfde probleem.

De specs van de server:
Dual Opteron 242
3GB DDR (6x 512MB)
40 GB HD
gbit (LAN), 100 Mbit (WAN)

De specs van de VM:
2 cores (ook geprobeerd met 1)
2048 MB RAM
18 GB HD
bridged gbit

Nu geef ik de schuld hiervan aan het hele virtualisatie process. Maar nu zou ik graag willen weten of er mensen zijn met de zelfde of andere ervaringen over het virtualiseren van (game)servers waar vertraging optreed.

[sh4d0wman]

Zit die 18 GB van je VM op de 40 GB harddisk of is het een tweede harddisk?

Mocht je de mogelijkheid hebben dan zou ik zeker eens testen met ESX aangezien je dan geen last hebt van eventueel het host OS.

[asfaloth_arwen]

Als ik zo de specs bekijk is je HDD de beperkende factor, kun je eens monitoren of deze problemen opleverd?

[Tead]

sh4d0wman schreef op woensdag 19 maart 2008 @ 10:09:
Zit die 18 GB van je VM op de 40 GB harddisk of is het een tweede harddisk?

Mocht je de mogelijkheid hebben dan zou ik zeker eens testen met ESX aangezien je dan geen last hebt van eventueel het host OS.

Die 18GB is een vmdk op de 40GB HD.

ESX heb ik geprobeerd. Deze draait ook op de server maar ik kan geen storage initialiseren omdat de 40 GB een IDE schijf is. Het betreft een 1U server en ik heb geen riser er bij om er nog een SCSI controller in te zetten oid. Maar zou ESX daar echt sneller in zijn? De Debian installatie als Host OS is kaal. Dus alleen het brood nodige om een VMWare Server te draaien.

asfaloth_arwen schreef op woensdag 19 maart 2008 @ 10:11:
Als ik zo de specs bekijk is je HDD de beperkende factor, kun je eens monitoren of deze problemen opleverd?

Hoe zou ik het beste realtime dit kunnen testen onder debian?

Het lijkt mij dat bij een gameserver alles in het geheugen benodigde bestanden in het geheugen wordt gestopt. De HD zou dan geen beperkte factor kunnen zijn. Maar zeker de moeite waard om even te bekijken.

Wat ik me nu ook bedenk is dat het Host OS amd64 release is (64bit) en het Guest OS i386 release is (32bit). Dit moet geen probleem zijn lijkt mij?

[asfaloth_arwen]

Tead schreef op woensdag 19 maart 2008 @ 10:30:
[...]
Hoe zou ik het beste realtime dit kunnen testen onder debian?

Google?

* asfaloth_arwen mompelt iets over iostat

Wat ik me nu ook bedenk is dat het Host OS amd64 release is (64bit) en het Guest OS i386 release is (32bit). Dit moet geen probleem zijn lijkt mij?

Dit lijkt me idd geen probleem te zijn

Overigens, je kent 2 van de 3 GB RAM toe aan deze VM, heb nog je host OS + andere VM draaien? Waarschijnlijk gaan je host OS + andere VM dan behoorlijk swappen, wat de HDD bezig houd. Heb je echt 2GB nodig voor deze VM?

[ Voor 19% gewijzigd door asfaloth_arwen op 19-03-2008 11:03 ]

[FatalError]

Ik vermoed dat het n probleem is met de tijdsynchronisatie tussen de host en het guest OS. Hier heb ik zelf al veel problemen mee ondervonden in andere situaties, maar ik kan me zo voorstellen dat gameservers afhankelijk zijn van n goed lopende klok.
Zo liep bij mij de klok van het guest OS binnen 1 minuut al meer dan 10 seconde voor of achter.
Hier is een oplossing voor te vinden in de vmware knowledgebase.

Verder had ik het probleem dat vmware niet goed kon zien op welke klokfrequentie de host cpu draait. Vmware dacht dat ie op 2.4GHz draaide ipv op 2.8 GHz bijvoorbeeld. Dat deed ook rare dingen. Je kan in de config van vmware opgeven wat de werkelijke klokfrequentie van de de CPU is.

[ Voor 12% gewijzigd door FatalError op 19-03-2008 10:47 ]

[Tead]

asfaloth_arwen schreef op woensdag 19 maart 2008 @ 10:39:
Overigens, je kent 2 van de 3 GB RAM toe aan deze VM, hebt nog je host OS + andere VM draaien? Waarschijnlijk gaan je host OS + andere VM dan behoorlijk swappen, wat de HDD bezig houd. Heb je echt 2GB nodig voor deze VM?

Zoals ik al zei wordt er niet geswapt. Het Host OS verbruikt nog geen 300 MB. Andere VM machines draaien niet en zijn dus geen beperkte factor. Voordat ik 2 GB gebruikte had deze VM maar 1 GB, met het zelfde probleem.

iostat ga ik wel even proberen.

FatalError schreef op woensdag 19 maart 2008 @ 10:46:
Ik vermoed dat het n probleem is met de tijdsynchronisatie tussen de host en het guest OS. Hier heb ik zelf al veel problemen mee ondervonden in andere situaties, maar ik kan me zo voorstellen dat gameservers afhankelijk zijn van n goed lopende klok.
Zo liep bij mij de klok van het guest OS binnen 1 minuut al meer dan 10 seconde voor of achter.
Hier is een oplossing voor te vinden in de vmware knowledgebase.

Verder had ik het probleem dat vmware niet goed kon zien op welke klokfrequentie de host cpu draait. Vmware dacht dat ie op 2.4GHz draaide ipv op 2.8 GHz bijvoorbeeld. Dat deed ook rare dingen. Je kan in de config van vmware opgeven wat de werkelijke klokfrequentie van de de CPU is.

Deze 2 dingen ga ik even nakijken. Zoiets zou het wel eens kunnen zijn. Als ik meer weet laat ik het weten.