Разница в производительности виртуальной машины после перехода на другой экземпляр ProxMox

У меня два сервера ProxMox, и когда я переместил одну из моих виртуальных машин, возникли проблемы с производительностью.

ProxMox 3.4, работающий на Intel Xeon E5606 (2 процессора, 4 ядра каждый, @ 2,13 ГГц). ProxMox 4.1, работающий на Intel Xeon E5-2650L v3 (2 CPUS, 24 ядра каждый, @ 1,8 ГГц)

Я переместил две виртуальные машины с сервера 3.4 на сервер 4.1 (я сделал резервную копию на 3.4, восстановление на 4.1).

VM 816, похоже, работает примерно так же, но VM 814 сильно пострадала от производительности (теперь загрузка занимает 4-6 минут).

Интересные факты о них:

• Оба имеют более старый процессор coreduo.
• 814 работает под управлением Fedora Core 6.
• 816 работает под управлением CentOS 6.
• 814 использует ide для своего HD.
• 816 использует virtio для своего HD.
• HD-диски обоих отключены.

Очевидно, сразу видно различие в том, что один - ide, а другой - virtio. Но они были именно такими на старом сервере - почему он намного медленнее на новом сервере? Я пытался переключить 814 на virtio, но потом он не загружается.

Наиболее важно выяснить, связано ли это с более новой версией KVM на ProxMox 4.1. Я планирую обновить старый сервер до последней версии proxmox, но если это приведет к поломке моих виртуальных машин, это будет проблемой.

uname -a от 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 из 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-строки, полученные из 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, 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

ПРИМЕЧАНИЯ. Смена ОС на 814 не является вариантом - эта виртуальная машина была создана из образа, взятого из реального оборудования, чтобы мы могли его сохранить. Это' s используются для сборки для некоторых из наших старых систем, и у нас действительно нет времени на проверку модифицированной системы сборки.

ОБНОВЛЕНИЕ: Вероятно, корень проблемы - это различия в картах RAID на двух серверах. При проектировании нового сервера другой администратор вспомнил, что у нас НЕ был флэш-модуль для карты RAID, поэтому мы аналогичным образом сконструировали новый сервер.

Дальнейшее исследование показывает, что у нас ДЕЙСТВИТЕЛЬНО есть флэш-модуль на старом сервере, и что он активен, обеспечивая кэширование записи. Это, в сочетании с различными шаблонами доступа, вероятно, является корнем разницы в производительности.