0

I've got two ProxMox servers and when I moved one of my VMs, it's running into performance issues.

ProxMox 3.4 running on Intel Xeon E5606 (2 CPUs, 4 cores each, @2.13 GHz). ProxMox 4.1 running on Intel Xeon E5-2650L v3 (2 CPUS, 24 cores each, @1.8GHz)

I've moved two VMs from the 3.4 server to the 4.1 server (I did backup on the 3.4, restore on the 4.1).

VM 816 seems to perform about the same, but VM 814 has taken a major performance hit (it now takes 4-6 minutes to boot).

Interesting things about them:

  • Both have the older 'coreduo' processor.
  • 814 is running Fedora Core 6.
  • 816 is running CentOS 6.
  • 814 is using ide for it's HD.
  • 816 is using virtio for it's HD.
  • both have their HD's set to no cache.

Obviously the immediately visible difference is that one is ide and one is virtio. But they were exactly this way on the old server - why is the one so much slower on the new server? I did try switching 814 to virtio, but then it doesn't boot.

What's most important to find out is whether this is something related to the newer version of KVM on ProxMox 4.1. I'm planning to upgrade the older server to the latest proxmox, but if it's going to break my VMs that's going to be a problem.

uname -a from VM 814: Linux SWBuild-Fedora.moberg 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:54:20 EDT 2006 i686 i686 i386 GNU/Linux

uname -a from VM 816: Linux SWBuild-CentOS 2.6.32-71.el6.i686 #1 SMP Fri Nov 12 04:17:17 GMT 2010 i686 i686 i386 GNU/Linux

KVM lines obtained from ps:

/usr/bin/kvm -id 814 -chardev socket,id=qmp,path=/var/run/qemu-server/814.qmp,server,nowait -mon chardev=qmp,mode=control -vnc unix:/var/run/qemu-server/814.vnc,x509,password -pidfile /var/run/qemu-server/814.pid -daemonize -smbios type=1,uuid=709a3672-bb7e-40a8-9815-69129f612924 -name SWBuild-Fedora -smp 1,sockets=1,cores=1,maxcpus=1 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000 -vga cirrus -cpu coreduo,+kvm_pv_unhalt,+kvm_pv_eoi,enforce -m 512 -k en-us -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -iscsi initiator-name=iqn.1993-08.org.debian:01:1a1a811322d -drive file=/var/lib/vz/images/814/vm-814-disk-1.raw,if=none,id=drive-ide0,format=raw,cache=none,aio=native,detect-zeroes=on -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,bootindex=100 -drive if=none,id=drive-ide2,media=cdrom,aio=threads -device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200 -netdev type=tap,id=net0,ifname=tap814i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown -device e1000,mac=7A:9F:7F:7C:08:BA,netdev=net0,bus=pci.0,addr=0x12,id=net0

/usr/bin/kvm -id 816 -chardev socket,id=qmp,path=/var/run/qemu-server/816.qmp,server,nowait -mon chardev=qmp,mode=control -vnc unix:/var/run/qemu-server/816.vnc,x509,password -pidfile /var/run/qemu-server/816.pid -daemonize -smbios type=1,uuid=06458c85-061e-4783-9152-e0d7f8a9685d -name SWBuild-CentOS -smp 1,sockets=1,cores=1,maxcpus=1 -nodefaults -boot menu=on,strict=on,reboot-timeout=1000 -vga cirrus -cpu coreduo,+kvm_pv_unhalt,+kvm_pv_eoi,enforce -m 512 -k en-us -device pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e -device pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f -device piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -iscsi initiator-name=iqn.1993-08.org.debian:01:1a1a811322d -drive file=/var/lib/vz/images/816/vm-816-disk-1.raw,if=none,id=drive-virtio0,format=raw,cache=none,aio=native,detect-zeroes=on -device virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100 -drive if=none,id=drive-ide2,media=cdrom,aio=threads -device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200 -netdev type=tap,id=net0,ifname=tap816i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown -device e1000,mac=F6:CE:EE:91:65:2B,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300

NOTES: Changing the OS on 814 is not really an option - this VM was built from an image taken from real-world hardware so that we could preserve it. It's used to build for some of our older systems, and we really don't have the time to validate a modified build system.

UPDATE: Probably the root of the problem is differences in the RAID cards on the two servers. When speccing the newer server another admin remembered us NOT having the flash module for the RAID card, so we specced the new server in the same way.

Further investigation shows that we DO have the flash module in the old server, and that it IS active, providing write caching. This, coupled with different access patterns, is likely the root of the performance difference.

1 Answer 1

0

I don't really understand why the VM is mis-behaving, but I found that if I turned on write-back caching for that VM, it behaves normally.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .