Сегодня мы столкнулись с действительно странным поведением на двух одинаковых хостах kvm и qemu (Dell R910). Каждая хост-система имеет 4 x 10 ядер, что означает, что 40 физических ядер отображаются как 80 в операционной системе (Ubuntu Linux 10.04 64 Bit, Kernel 3.0).
Мы запустили 32-разрядную виртуальную машину Windows 2003 (1 ЦП, 1 ГБ ОЗУ, мы меняли эти значения несколько раз) на одном из узлов и заметили, что до начала процесса загрузки потребовалось 15 минут. В течение этих 15 минут отображается черный экран, и ничего не происходит. libvirt и хост-система показывают, что процесс qemu-kvm для гостя почти простаивает. изучение этого процесса показывает только некоторые записи FUTEX, но ничего особенного.
По прошествии этих 15 минут виртуальная машина Windows внезапно начинает загружаться, и появляется логотип Windows. Через несколько секунд виртуальная машина будет готова к использованию. Сама виртуальная машина очень производительна, так что это не проблема производительности.
Мы пытались закрепить процессоры с помощью инструментов virsh и taskset, но это только усугубило ситуацию.
Когда мы загружаем виртуальную машину Windows с Linux Live CD, также появляется черный экран в течение нескольких минут, но не до 15. При загрузке другой виртуальной машины на этом хосте (Ubuntu 10.04) также возникает проблема с черным экраном, и здесь тоже черный экран отображается всего 2-3 минуты (вместо 15).
Итак, подведем итоги: каждый гость на каждом из этих идентичных узлов страдает от простоя через несколько минут после запуска. Через несколько минут процесс загрузки внезапно начнется. Мы заметили, что время простоя происходит сразу после инициализации биографии гостя.
У одного из наших сотрудников возникла идея ограничить количество процессоров с maxcpus = 40 (из-за наличия 40 физических ядер) в Grub (параметр ядра), и внезапно исчезло поведение «черный экран-холостой ход».
Поиск известных ошибок и т. Д. В списках рассылки KVM и Qemu, в Интернете, на форумах, на серверах и других сайтах не дал никаких полезных результатов. Даже запрос в IRC-каналы разработчиков не принес новых идей. Люди там рекомендуют нам использовать закрепление ЦП, но, как уже говорилось ранее, это не помогло.
У меня вопрос: есть ли какое-то ограничение на количество процессоров для хост-системы qemu или kvm? Просмотр исходного кода этих двух инструментов показал, что KVM отправит предупреждение, если ваш хост имеет более 255 процессоров. Но мы даже не стремимся к этому пределу.
Немного о хост-системе:
3.0.0-20-server
kvm 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4
kvm-pxe 5.4.4-7ubuntu2
qemu-kvm 0.14.0+noroms-0ubuntu4
qemu-common 0.14.0+noroms-0ubuntu4
libvirt 0.8.8-1ubuntu6
4 x Intel(R) Xeon(R) CPU E7-4870 @ 2.40GHz, 10 Cores
Изменить: также пробовал ядро 3.2 (с не используемым параметром maxcpus) - к сожалению, это ухудшило ситуацию. dstat показывает растущее количество переключений контекста:
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
0 0 99 0 0 0|1164k 638k| 0 0 | 0 0 |4972 6319
0 1 99 0 0 0| 0 0 |3456B 4847B| 0 0 | 18k 33k
0 1 99 0 0 0| 0 0 |6126B 4550B| 0 0 | 17k 33k
0 1 99 0 0 0| 0 0 |1772B 4139B| 0 0 | 17k 33k
0 1 99 0 0 0| 0 0 |5507B 3674B| 0 0 | 17k 32k
Нормальные значения будут около 7000 для этой системы с одной виртуальной машиной.
Изменить: я запустил хост-системы с maxcpus = 40 в качестве параметра загрузки. virsh nodeinfo показывает 40 физических ядер без гиперпотоковых ядер.
При запуске виртуальной машины у нее все еще есть «перерыв на загрузку» около 30 секунд. В течение этого времени количество переключений контекста увеличивается с 300 (в секунду) до 600 000 (в секунду). После 30 секунд черного экрана виртуальная машина запускает нормальный процесс загрузки, и переключение контекста опускается до <7000 секунд:
----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read writ| recv send| in out | int csw
1 2 97 0 0 0| 943k 0 | 26k 12k| 0 0 | 22k 40k
3 7 84 6 0 0| 26M 64k| 71k 18k| 0 0 | 10k 16k
1 1 97 1 0 0|5282k 2560B|9751B 15k| 0 0 | 13k 23k
1 4 95 0 0 0|1216k 0 | 14k 18k| 0 0 | 295k 592k
1 3 96 0 0 0| 0 52k|5518B 7299B| 0 0 | 228k 456k
1 3 96 0 0 0| 12k 24k|1228B 1514B| 0 0 | 258k 518k
1 4 96 0 0 0| 0 0 | 14k 32k| 0 0 | 280k 565k
1 3 96 0 0 0| 0 0 | 19k 38k| 0 0 | 284k 573k
1 3 96 0 0 0| 0 0 |6465B 7203B| 0 0 | 288k 581k
1 3 96 0 0 0| 0 172k| 26k 11k| 0 0 | 290k 584k
1 3 96 0 0 0| 0 0 | 23k 11k| 0 0 | 288k 580k
1 3 96 0 0 0| 0 12k|5678B 4556B| 0 0 | 289k 583k
1 3 96 0 0 0| 0 0 |1192B 2929B| 0 0 | 288k 580k
1 3 96 0 0 0| 0 0 |6304B 10k| 0 0 | 272k 547k
1 3 96 0 0 0|4096B 52k|8330B 14k| 0 0 | 300k 605k
1 3 96 0 0 0| 0 24k| 11k 20k| 0 0 | 293k 591k
1 3 96 0 0 0| 0 0 | 13k 28k| 0 0 | 291k 587k
1 3 96 0 0 0| 0 512B| 10k 18k| 0 0 | 291k 587k
2 3 95 0 0 0| 0 0 |6653B 10k| 0 0 | 167k 337k
3 0 97 0 0 0| 0 160k| 23k 5524B| 0 0 | 10k 19k
7 0 92 0 0 0| 0 36k| 22k 3335B| 0 0 | 949 924
10 0 90 0 0 0| 0 0 |5172B 3318B| 0 0 | 908 923
5 0 94 0 0 0| 0 0 |2234B 2825B| 0 0 | 846 875
Изменить: по запросу я добавлю отрывок из strace -f -p:
25734 <... read resumed> "\16\0\0\0\0\0\0\0\376\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0"..., 128) = 128
25752 futex(0x927e60, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
25734 rt_sigaction(SIGALRM, NULL, {0x4b2300, ~[KILL STOP RTMIN RT_1], SA_RESTORER, 0x7fe09ac108f0}, 8) = 0
25734 write(8, "\1\0\0\0\0\0\0\0", 8) = 8
25734 read(15, 0x7fffcea69f70, 128) = -1 EAGAIN (Resource temporarily unavailable)
25734 timer_gettime(0x1, {it_interval={0, 0}, it_value={0, 0}}) = 0
25734 timer_settime(0x1, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0
25734 timer_gettime(0x1, {it_interval={0, 0}, it_value={0, 182592}}) = 0
25734 futex(0x927e60, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
25752 <... futex resumed> ) = 0
25734 <... futex resumed> ) = 1
25752 futex(0x927e60, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
25734 select(25, [7 10 14 15 16 17 18 24], [], [], {1, 0} <unfinished ...>
Как рекомендовано в одном из комментариев (спасибо cperrin88), Ubuntu 12.04 принес решение. Некоторые параметры:
Гость Windows теперь показывает панель загрузки в течение первых 30 секунд загрузки, а затем просто загружается (нормальное поведение).
Количество переключений контекста теперь очень мало по сравнению с тестовым сценарием, который у меня был ранее (от 200 до 24 КБ в секунду).
Итак, проблема решена. Мне просто нужно выяснить, что изменилось (я думаю, это была ошибка KVM).
Спасибо всем комментариям и вашим усилиям!
Я обнаружил довольно много ошибок с KVM в Ubuntu 10.04. (который мне все еще приходится использовать), включая растущие кеши, которые меняются местами, и серьезные проблемы с производительностью.
Я рекомендую обновиться до последней версии LTS в надежде, что она исправит несколько ошибок.