Pull to refresh

Comments 17

Наверняка шакарное ПО.

Скажите, а как в ней обстоят дела с различающимися наборами инструкций?

Ну т.е. если мы к примеру Windows 2008 r2 с какого-нибудь Sandy Bridge будем переезжать на Penryn, все ли у нас будет хорошо?
Спасибо за вопрос.
Не совсем понял о возможном «переезде». В приведенном примере будет происходит миграция ВМ (с процессором, эмулированным гипервизором) на другой сервер, где гипервизором эмулируются такие же процессора, то есть внутри ОС машина и не узнает о этом «переезде». Все будет хорошо.
Я не настолько хорошо знаю внутреннюю кухня эмуляции процессора гипервизором, но все таки проблемы должны быть.

Предположим у нас есть первый сервер который умеет SSE 4.2, допустим что с помощью этой инструкции гипервизор будет «эмулировать» процессор внутри VM тоже с SSE 4.2.

Также у нас есть второй сервер, который умеет только SSE3. И гипервизор в силу отсутствия набора инструкций, не умеет «эмулировать» SSE4.2.

И наконец, у нас есть виртуалка которая работает на первом сервере, и использует SSE4.2. Так вот суть вопроса, что же будет с виртуалкой при переезде с первого сервера на второй.
В VMware есть технология сокрытия процессорных фичей (EVC) в соответствии с поколениями ЦП (Sandy Bridge, Ivy Bridge, Haswell и т.д.), который применяется при включении ВМ. Благодаря ей можно мигрировать ВМ на сервер с таким же или более новым процессором. Мигрировать на сервер с более старым процессором не получится, если заранее не включен режим совместимости.

Было бы интересно узнать как это реализовали в Veeam, так как мне не удалось найти никакой информации по использованию EVC за пределами vSphere Client.
Об EVC мы знаем. Но я спросил именно о том, как это работает в Veeam,

upd: Проблема в том, что EVC нельзя включить на уже работающей машине.
Она автоматически включается при миграции на сервер с более новым процессором и работает до перезагрузки ВМ.
Как мне мигрировать с Sandy Bridge на Merom, не перезагружая виртуалку?

Никак, vMotion возможен на такой же или более новый ЦП. Это в посте опустили, как и любые технические детали :-(
Вы не могли бы описать принцип работы и особенности реализации?
Спасибо за вопрос. Более подробно о принципе работы:
Сначала Veeam Backup & Replication анализирует доступность технологии vMotion в конкретном установленном экземпляре vSphere. Если технология vMotion доступна, они и будет применяться (здесь будет автоматически (функциями самой VMware) произведена проверка совместимости, согласно EVC, и можно будет мигрировать ВМ на сервер с таким же или более новым процессором). Если vMotion не возможен, то будет использована технология Veeam “SmartSwitch“, работа которой не зависит от совместимости процессоров (за исключением случая, когда прикладное программное обеспечение жестко требует наличия некоторой функциональности процессора (например, упомянутой SSE4), и которая есть на исходном хосте, но отсутствует на целевом), так как выполняется через “быстрый перезапуск” ВМ.

Алгоритм Smart Switch:
1) Создание снапшота оригинальной ВМ
2) Создание ВМ на целевом хосте, копирование снапшота и конфигурации ВМ на целевой хост
3) Остановка исходной ВМ
4) Копирование изменений на дисках ВМ, произошедших с момента п.1
5) Запуск ВМ на целевом хосте
Выходит, что миграция не совсем «на лету», так как происходит приостановка или выключение исходной ВМ.
Я правильно понимаю, что общий сторадж не нужен для такого «переезда»?
Он и для обычного vMotion не нужен, хотя тут скорее всего просто копируют снепшот с оперативкой.
Для VMware VMotion общий сторадж обязателен. Без него работает только оффлайн миграция (не онлайн).
ESXi 6.0 поддерживается начиная с версии 8.0.0.2021 — Veeam Backup & Replication 8.0 Update 2. Вообще уже лучше поставить Update 3, там еще по мелочи добавили хороших вещей.
Sign up to leave a comment.