Search results

Your guest system is running low on memory and it failed to allocate pages (even if you still have some RAM free, the kernel was not able to allocate what it needed). Most likely it's a bug in virtio if the traffic stops altogether as it happens - you should report your findings to KVM mailing...

Seems to work fine - thanks!

It's not intended - as in original ksmtuned, the script looks for "qemu". Here, we look for "kvm" processes, and find "kvm-irqfd-clean", too. However as kvm-irqfd-clean is a kernel thread, "ps -o vsz" for this process returns 0 VSZ, so it's "neutral". We might well use this to get rid of...

It returns an empty string when "qemu" is there. With "kvm", it works fine: ++ committed_memory ++ local progname ++ progname=kvm ++ awk '{ sum += $1 }; END { print sum }' +++ pgrep kvm ++ ps -o vsz 3721 3961 3991 4020 4051 4071 4102 4120

Hmm, do we need this? --- /usr/sbin/ksmtuned.orig 2010-02-01 13:03:29.000000000 +0100 +++ /usr/sbin/ksmtuned 2010-02-01 13:16:15.000000000 +0100 @@ -63,7 +63,7 @@ committed_memory () { # calculate how much memory is committed to running qemu processes local progname -...

/usr/sbin/ksmtuned script has a hardcoded "qemu" binary name - where Proxmox VE uses "kvm" binary. So this code will never give any results: committed_memory () { # calculate how much memory is committed to running qemu processes local progname progname=${1:-qemu} ps -o vsz...

Can you assign this virtual machine a virtio network card and try again (even if this card will be not used)?

If you ping the guest (i.e. from the host) - are ping replies generally "low", i.e.: 64 bytes from 192.168.10.43: icmp_seq=2 ttl=64 time=0.494 ms 64 bytes from 192.168.10.43: icmp_seq=3 ttl=64 time=0.367 ms 64 bytes from 192.168.10.43: icmp_seq=4 ttl=64 time=0.348 ms or do you get, every...

You can also look here (although that's probably the reverse from what you're trying to achieve): http://pve.proxmox.com/wiki/FAQ (How can I access Linux guests through a serial console?).

You have to find what causes it. Read: what processes read or write a lot. Run htop, iotop, atop etc. Write some scripts (i.e. ps aux saved every 30 secs; then compare it with sar output where the load happened etc.). With some luck, you will be able to find something.

Are these SSD drives? If not, than these figures are only valid for single linear read. With multiple processes accessing different parts of the disk, disk heads will start to seek, and your performance will drop significantly. How do you have your guest images stored? In LVM files, or in...

"load average" comes not only from CPU, but also IO: disk and network traffic. So if more processes are hammering your disk at the same time, load average will go high, even if the CPU is idle.

You need ACPI enabled in your guest - this is how the guest receives reboot/shutdown notifications.

After doing any changes in the web interface, you have to "save" them before they are applied - look for a red "save" link...

Please run: ps aux | grep " D" It will show you the processes in "uninterruptible sleep" state (i.e. waiting for IO). Each of such processes will add one to the load average; these processes will (usually) not take much CPU, so may not be obvious to spot in htop/top. For example, it can...

I guess implementing lxc would be welcome here, but would need the following, at the minimum: - more manpower to support a third virtualization technology, - yet more manpower to test it, since lxc is not yet widely used, - support both OpenVZ and lxc at the same time, since it's not yet clear...

Maybe even earlier than 2.6.27 (at least it's available in Debian Lenny): $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource kvm-clock $ uname -a Linux dns1 2.6.26-2-686 #1 SMP Wed Aug 19 06:06:52 UTC 2009 i686 GNU/Linux

So the load happens from time to time. So, run iotop *and* htop when you see the server is slow, and you'll find the guilty. Running these commands at different times and pasting their output here does not make much sense.

If the time skew is too big, ntp daemon will not attempt to sync the time. One has to use ntpdate to sync it - but ntp daemon can't be running at the same time. So: /etc/init.d/ntpd stop ntpdate pool.ntp.org /etc/init.d/ntpd start Also, if you have a Linux guest, make sure kvm-clock is...

Try removing mlocate, this may impose _great_ load on your IO. Also, please install "sysstat" package and enable it in /etc/default/sysstat. When some time passes, run "sar" - it will show you when the server is loaded and when it's not. Typically, it can be some cronjob.