Re: kvm very slow

[Ulrich Schreiner <ulrich.schreiner-sZDnKEZIvs8b1SvskN2V4Q@public.gmane.org>]

Matthew, your the hero of the day!

with "acpi=force" in the guest the clock ticks correct.

> ACPI: no DMI BIOS year, acpi=force is required to enable ACPI

is it possible to use another bios where the acpi=force switch is not
needed? or to fix the bios (i think kvm uses it's own bios, not the
original qemu-bios)

Am Donnerstag, den 09.08.2007, 17:09 -0700 schrieb Matthew Kent:
> [oops sorry. should have included the full dmesg from the bad boot and
> cc'd the original poster]
> 
> On Thu, 2007-09-08 at 16:23 -0700, Matthew Kent wrote:
> > On Wed, 2007-01-08 at 07:22 +0200, Ulrich Schreiner wrote:
> > > hi,
> > > 
> > > im using a 64 bit fedora7 system with a quad-core processor to host
> > > multiple virtual machines.
> > > 
> > 
> > literally the exact same setup here
> > 
> > > my current kernel is:
> > > 
> > > Linux testserver 2.6.22.1-27.fc7 #1 SMP Tue Jul 17 17:19:58 EDT 2007
> > > x86_64 x86_64 x86_64 GNU/Linux
> > > 
> > > (now there is a 2.6.22.1-33.fc7 to download, but i think it is not the
> > > point here).
> > > 
> > 
> > 2.6.22.1-41.fc7 x86_64 host
> > 
> > > i installed
> > > 
> > >   kvm.x86_64: 31-1.fc8
> > 
> > kvm-33
> > 
> > > 
> > > because of a crash i reported as a bug with the older kvm module.
> > > 
> > > this system starts a F7 image with the following command:
> > > 
> > > /usr/bin/qemu-kvm 
> > >   -net nic,macadr=52.54.00.12.34.57 
> > >   -net tap,script=./ifup.py,ifname=tap0
> > >   -hda /var/qemu/vm_images/F7image.img 
> > >   -boot c: -m 512 -vnc :2 -k de
> > > 
> > > inside the image there is fedora 7, but a 32bit system.
> > > 
> > 
> > almost exact same as here except using 32 bit fedora rawhide
> > (development) guest running kernel 2.6.23-0.74.rc2.git1.fc8
> > 
> > > almost everything works (reboot hangs), but the system is extremely
> > > slow! the clock inside the system is extremely slow: every *virtual*
> > > second in the image is about two or more seconds in the *real* world.
> > 
> > and I'm having the exact same issue here. The hardware clock works fine
> > (least from the output of /proc/driver/rtc and hwclock) but the system
> > time quickly falls behind in the guest, approx 0.5 secs for every 1 real
> > second.
> > 
> > No combination of selecting different clocksources in the guest,
> > disabling CONFIG_NO_HZ, etc seemed to make any difference. And the fact
> > is my fc7 x86_64 install works just great so I doubt its the host.
> > 
> > What I did notice though was ACPI wasn't being enabled by default for
> > the 32bit kernel with the message
> > 
> > ACPI: no DMI BIOS year, acpi=force is required to enable ACPI
> > 
> > and that the acpi_pm clocksource the x86_64 guest picked by default,
> > which worked fine, was missing. eg:
> > 
> > 2.6.23-0.74.rc2.git1.fc8 i686 default boot:
> > 
> > /sys/devices/system/clocksource/clocksource0/available_clocksource
> > pit jiffies tsc
> > /sys/devices/system/clocksource/clocksource0/current_clocksource
> > pit
> > 
> > 2.6.23-0.74.rc2.git1.fc8 i686 with acpi=force:
> > 
> > /sys/devices/system/clocksource/clocksource0/available_clocksource
> > tsc acpi_pm pit jiffies
> > /sys/devices/system/clocksource/clocksource0/current_clocksource
> > tsc
> > 
> > and now everything seems great, hardware and system time seem 1:1
> > again. 
> > 
> > Attached is a diff of the dmesg from each boot.
> > 
> > As to why this is...


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/