VMware в плане живой миграции несколько выигрывает у XEN, у нее есть некоторое абстрагирование от типа процессора и необязательно в пуле иметь однотипные машины.
Боюсь, это несколько… м… не так. Проблема с разнопроцовыми миграциями не в том, что гипервизору плохо, а в том, что запускающаяся программа в начале получает одни capabilities, а в ходе работы — совсем другие.
Например, программа смотрит, что может сделать команду XCHBLDRDK (у неё есть две ветки кода — медленная и быстрая, ветка выбирается исходя из процессора). Проверка происходит на этапе запуска программы. Потом её мигрируют, программа пытается сделать команду, падает с no op.
У VMware ESX поддерживается маскирование поддерживаемых инструкций в пределах кластера (EVC), что позволяет 'выравнить' доступный функционал по самой старой модели процессора.
Хм. Ну так же рассуждая можно и говорить про миграцию между разными процессорами. Реальность же такова, что во многих конторах зоопарк с возможной чехардой из разных процессоров.
разные проци — амд/интел нужны редко, согласен.
а вот апгрейд серверного железа на одной платформе обычно происходит.
в вмвари я могу начать создавать машины на старых ксеонах, потом переместить их на рабочее облако. и запросто дальше переместить на еще более новые, при апгрейде. и при этом, если флаги так и не снимать, в любой момент можно вернуть на самые старые.
Насколько я слежу за обсуждениями в -devel, они этим злоупотребляют только для NFS, для iscsi оно честное и нормальное. (хотя я вообще со снапшотами мало работал, видимо, перед написанием следующего раздела нужно будет глубже зарыться).
Xen Cloud Platform в условиях предприятия [2]