Привет знатокам!
Имею небольшую непонятность. А именно - всё хорошо, когда оно (KVM-виртуализация) работает на идентичном оборудовании. В моем же случае это несколько не так. А именно, есть "большой" сервер на двух четырехядерных ксеонах (опознается в virt-manager как Nehalem) и пара простеньких серверочков на двухядерных процессорах типа E5300 или что-то вроде того. Они опознаются virt-manager'ом как Core2Duo.
Если не трогать тонкие настройки гостевого процессора, то миграция без проблем ходит между одинаковыми серверами. А вот если мы захотим смигрировать с большого сервера на маленький - опаньки. virt-manager нам черным по понятному сообщает, что есть некоторые CPU Features (в моем случае rdtscp и dca), которые требуются, но не поддерживаюся процессором на целевом хосту. Даже если поставить принудительно на всех хостах для гостей одинаковые CPU - Core2Duo - эти самые CPU Features не подстраиваются под новый целевой CPU.
Если эти требуемые CPU Features явно запретить везде, то миграция оживает.
Вопрос - правильно ли я поступаю, запрещая эти CPU Features (ведь их нет на малых серверах и там и без них виртуалка работает). И какой вообще в таком случае CPU следует выбирать? По минимально определившемуся? Или брать "стандартный" KVM64?
Как поступают умные люди в таком случае?
Q про CPU при миграции в KVM
Давно где-то читал, что если хочется миграции без проблем, что лучше CPU Features не юзать.
брать нижнюю планку из доступных, то есть если везде поднимать машинки как core2duo все будет работать. жалко терять дополнительные фишки nehalem-а конечно.
Давно где-то читал, что если хочется миграции без проблем, что лучше CPU Features не юзать.
У меня как раз наоборот получается. Ставлю на малых серверах самоопределяемое Core2Duo, на большом - принудительно то же самое. А вот CPU Features у них различное получается. Если на малых серверах rdtscp и dca (совершенно не знаю - что это такое и для чего нужно) стоят в положении off, то на большом, ксеоновом, они стоят в положении require. Ну и при попытках смигрировать - идет ругачка на эти _требуемые_ параметры. Если их принудительно запрещаю (на малых серверах их и так нет, значит и большому не очень то и нужно) - тогда миграция идет. Складывается полное ощущение, что в virt-manager (штатный, из репов CentOS 6, версии 0.9.0) не до конца отрабатывает выбор процессора. Процессор то выбирает, а CPU Features под этот процессор не корректирует.
Так что без ручного шаманства на CPU Features, похоже, не обойтись.
жалко терять дополнительные фишки nehalem-а конечно.
Да кому они нужны, если в виртуалке почтовый сервер или астериск?... Этим приложениям они нужны?
Да и жалко если знаешь, что теряешь. А я понятия не имею, что именно там за этими фишками кроется. А поскольку таким сокровенным знанием я не обладаю, то и жалости особой не испытываю.
Я такую мысль подумал:
1. Посмотреть вывод команды cat /proc/cpuinfo | grep flags | uniq
2. Отобрать только те флаги, что есть на обоих процессорах, их затребовать явно, а остальные - не менее явно запретить, жестко или не очень, юзать при наличии возможности...
Тогда, вроде, гостевая ось будет ездить по моим разнопроцессорным хостам без какого либо сопротивления. Я верную мысль думаю?
И еще простой вопрос. Я поставил KVM из репозиториев CentOS 6. Поставилась версия qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.2.x86_64. Сайт разработчика говорит, что это есть версия конца 2009 года. В принципе - оно работает и не глючит. По крайней мере я этого не замечаю. В тоже время последний релиз имеет версию 1.2 и выпущен в обращение в сентябре 2012 года. С исправленными ошибками и новыми, добавленными за 3 года активной разработки... Ну и вопрос - имеет ли смысл обновить KVM и всё что его окружает до последних релизов? Или - старое правило - не тронь технику, она и не подведет?
Если их принудительно запрещаю (на малых серверах их и так нет, значит и большому не очень то и нужно) - тогда миграция идет
разве это не то что я и сказал? ориентируемся на нижнюю планку
Да кому они нужны, если в виртуалке почтовый сервер или астериск?... Этим приложениям они нужны?
вряд ли нужны, но очень может быть что полезны.
А я понятия не имею, что именно там за этими фишками кроется.
ну это как закрыв глаза думать что никто тебя не видит :) смешно, и к реальности никакого отношения не имеет...
Я верную мысль думаю?
в принципе да, только модели которые уже определяет либвирт как раз для этого и существуют.
[quote="Cruiser78⇓"]Я верную мысль думаю?
в принципе да, только модели которые уже определяет либвирт как раз для этого и существуют.[/quote]
Так вот мой virt-manager определяет набор этих флагов только если сказать ему - копировать информацию о CPU. Тогда он берет правильный процессор и расставляет CPU Features по тому, что прочитал. А вот если ему принудительно назначить иной процессор, то он эти флаги уже не трогает. И под иной процессор их не корректирует. Видимо это надо сделать руками.
Поставилась версия qemu-kvm-0.12.1.2-2.355.0.1.el6.centos.2.x86_64. Сайт разработчика говорит, что это есть версия конца 2009 года.
Версия сборки очень большая. Надо смотреть srpm. Наверняка накладывали тучу патчей из новых версий.
Давно где-то читал, что если хочется миграции без проблем, что лучше CPU Features не юзать.
Эти CPU features даже в пределах одного локалхоста порой проблем подкидывают: например, у меня Sabayon вылетал с kernel panic.