Vcenter миграция виртуальной машины
FAQ по vMotion в VMWare vSphere: особенности, типы, настройка
Технология vMotion позволяет перенести запущенную виртуальную машины VMWare с одного физического хоста ESXi на другой без прерывания ее работы и остановки сервисов. В этой статье мы рассмотрим особенности технологии VMWare vMotion: как работает vMotion, какие виды vMotion бывают, как настроить vMotion в VMWare vSphere и как вручную смигрировать виртуальную машину между хостами ESXi или хранилищами с помощью vMotion. Рассмотрим основные способы оптимизации vMotion и решения проблем.
Как мы уже сказали, vMotion позволяет выполнить “живую миграцию” виртуальных машин без простоя и прерывания работы пользователей. Технология vMotion позиционируется не как средство обеспечения высокой доступности ВМ при авариях. В первую очередь это простое и удобное средство переноса продуктивных ВМ, когда вам нужно выполнить обслуживание/обновление/замену физических серверов с установленным гипервизором ESXi или дисковых массивов. Также vMotion является основой технологии распределения (выравнивания) нагрузки на физические сервера — DRS (Dynamic Resource Scheduler)).
Как работает VMWare vMotion?
Для миграции ВМ между физическим хостами с помощью vMotion используются следующие компоненты VMWare:
Как происходит vMotion? Сначала на целевом хосте создается теневой клон исходной ВМ с такой-же конфигурацией из vmx файла. Эта ВМ-клон видит все файлы ВМ на общем хранилище. Содержимое оперативной памяти и состояние запущенной ВМ передается по сети между исходным и целевым хостом ESXi. vMotion делает снапшот состояния памяти ВМ, копирует его на целевой сервер по сети. vMotion при этом отслеживает изменения в страницах памяти, а затем до-копирует модифицированные сегменты памяти (это может происходить в несколько этапов, каждый раз копируется все меньший объем данных и за меньшее время).
В какой-то момент состояние исходной ВМ замораживается, выполняется копированию изменённых сегментов памяти и команд процессора, и ВМ запускается на целевом ESXi. Весь процесс для 1/10 Гб Ethernet сети для средних размеров ВМ занимает несколько секунд.
Виды VMware vMotion
VMWare под названием vMotion понимает целый стек различных технологий, позволяющих переместить на лету запущенные ВМ между серверами, дисковыми массивами, городами или между наземной и облачной инфраструктурой.
Особенности VMware Storage vMotion
Как мы уже сказали, технология Storage VMotion позволяет переместить файлы запущенной виртуальной машины (виртуальные диски и файлы конфигурации) на другое VMFS/NFS хранилище (LUN, дисковый массива) без остановки ВМ.
Требования для успешного выполнения Storage VMotion:
Enhanced vMotion Compatibility (EVC) в VMWare
Режим Enhanced vMotion Compatibility (EVC) для кластеров VMware HA/DRS используется, если кластер построен на хостах с процессорами разных поколений (но не разных производителей!!). При включении EVC для кластера, гипервизор начинает маскировать инструкции CPU, которые поддерживаются не на всех хостах. При включении EVC все функции процессоров хостов ESXi в кластере начинают соответствовать некому базовому минимальному набору инструкций CPU, который задал администратора vSphere в настройках.
Таким образом благодаря EVC вы можете мигрировать ВМ между хостами с разными наборами инструкций процессора.
При включении EVC для кластера вам нужно выбрать режим EVC (для AMD или Intel) и выбрать в выпадающем списке минимальное поколение процессоров вендора, которые имеются в вашем кластере.
В VMware vSphere 6.7 появились технологии миграции между облаком и on-prem (Cross-Cloud Cold и Hot Migration). Для реализации ВМ в облако теперь можно включать в настройках ВМ Per-VM EVC (доступно в vSphere 6.7 с Hardware Version 14).
Можно получить базовые уровни EVC выставлены для ВМ в кластере из PowerCLI:
Чтобы получить максимально поддерживаемый режим EVC на:
Get-VMHost | Select-Object Name,ProcessorType,MaxEVCMode
Как включить vMotion в VMWare vSphere?
Выберите ваш VMkernel интерфейс и откройте его свойства (Edit).
В свойствах vmk порта в секции Enabled Service включите опцию vMotion.
vMotion: как мигрировать ВМ между серверами
Чтобы с помощью vMotion перенести запущенную ВМ между двумя ESXi хостами, запустите vSphere Client, щелкните по ВМ и выберите Migrate.
Выберите тип миграции, который вы хотите использовать:
Я выбрал первый вариант.
Мастер миграции предложит выбрать хост, кластер, resourse pool или vApp, в который нужно перенести данную виртуальную машину. Выберите хост. Если vMotion настроен правильно, и не обнаружено конфликтов, в секции Compatibility будет указано: Compatibility checks succeeded.
Мастер миграции ВМ предложит выбрать в какую сети нужно поместить vNIC сетевой ВМ при миграции. Если вы хотите, чтобы ВМ была доступна после миграции, она должна быть помещена в тот же самый сегмент (VLAN), как и на исходном хосте. Если у вас используется стандартный vSphere Switch, нужно создать одинаковые группы портов (Port Group) на всех ESXi хостах. При использовании VDS, группы портов на всех хостах кластера одинаковые.
На последнем этапе нужно выбрать приоритет задачи миграции vMotion. По-умолчанию используется наивысший приоритете (Schedule vMotion with high priority). Я всегда использую именно его.
Убедитесь, что ваша ВМ теперь запущена на другом хосте ESXi.
Можно переместить запущенную ВМ на другой хост с помощью PowerShell командлета Move-VM из PowerCLI. Например, мы хотим перенести все ВМ с хоста esxi-1 на esxi-2:
Get-VMHost esxi-1|Get-Vm| Move-VM –Destination (Get-VMHost esxi-2)
Почему не работает vMotion?
Перечислим основные причины, из-за которых vMotion может завершаться с ошибкой или миграция ВМ выполняться очень медленно:
Как ускорить/оптимизировать vMotion для быстрой миграции ВМ?
Вы можете ускорить миграцию ваших виртуальных машин несколькими способами.
Чтобы предоставить для процессов vMotion более одного ядра CPU, нужно создать несколько VMkernel интерфейсов с включенной опцией vMotion и привязать их к одному NIC интерфейсу. Один поток vMotion имеет среднюю пропускную способность около 15 GbE, соответственно, чтобы загрузить сеть 100 GbE вам нужно 6 потоков.
Vcenter миграция виртуальной машины
Всем привет сегодня расскажу как мигрировать работающую виртуальную машину без общего datastore в VMware vCenter. Если у вас есть кластер на VMware ESXI 5.5, то там проблем нет, так как в кластере все хосты имеют общий датастор, где лежат виртуальные машины, и во время миграции, по сути файлы виртуальной машины остаются на том же датасторе, у нас же ситуация что нет общего starage и холодная миграция, то есть выключенная виртуалка, нас не устраивает, в виду того, что она важная и должна работать без перерывов, смотрим ниже как решить данную проблему.
Что такое vMotion
VMotion это технология, которая помогает виртуальной машине производить миграцию, как на другие хосты ESXI так и datastore. Первое что я вам советую сделать это посмотреть карту vMotion на вашем esxi хосте. Для этого выбираете vm и переходите во вкладку Maps и сразу становится понятно куда можно двигать без проблем а куда нельзя и по каким причинам, либо CPU не соответствует либо не включено перемещение.
Изучив карту vmotion можно понять какой вид миграции нам нужен, их всего три типа.
Миграция Change both Host and datastore
Так как нам нужно смигрировать vm в работающем состоянии без общего диска, то нам подходит только Change both Host and datastore. Щелкаем правым кликом по виртуальной машине и выбираем Migrate, у вас откроется окно для выбора метода. Как можете заметить в толстом клиенте VMware ESXI Client для Windows на живую Change both Host and datastore выполнить не дает, функция не активна, такое ограничение, но не спешите отчаиваться, у VMware vCenter есть Web Client, в котором это можно осуществить.
Vmware Web Client
Во первых он у вас должен стоять как вместе с vCenter или отдельно. Его дистрибутив находится на установочном диске с VMware vCentert. Скачать Vmware Web Client можно тут. Заходим по адрес
Так как у меня настроена аутентификация через Active Directory, то вводим формат вот такой домен\логин и пароль. Выбираем там вашу виртуальную машину и жмем Migrate.
Выбираем Change both Host and datastore, как видите все активно. Данная функция еще называется Enhanced vMotion или «Shared-Nothing» vMotion. Ниже мы рассмотрим ее принципы.
выбор вида миграции
Теперь вас попросят указать на какой ESXI Host вы поедите, мастер проверит все ли выполнены требования для vmotion, о них мы поговорим ниже. Если есть проблемы то вам сразу об этом скажут, у меня например на esxi21 не был включен vmotion на виртуальном коммутаторе. Как включить vmotion читайте тут.
Требования к vmotion
Вот пример ошибки при Enhanced vMotion. Проблема в несовместимости CPU масок. К счастью в vmware vcenter это в большинстве случаев можно поправить, но могут и быть синие экраны.
После того как все требования выполнены все становится зеленым и можно продолжать миграцию
Все будет происходить по обычной сети vMotion, по ней передаются и диск Vm, и ее память с регистрами процессора для обеспечения непрерывной работоспособности виртуальной машины во время миграции
Миграция Enhanced vMotion
bulk copy и mirror mode driver
Mirror mode driver игнорирует те блоки исходного хранилища, которые меняются, но еще не были скопированы на целевое хранилище. Чтобы удерживать максимальную скорость копирования, Mirror mode driver использует отдельный буфер, чтобы не использовать отложенную запись блоков.
После того как вы разобрались с самим процессом, нужно двигаться дальше. Следующим шагом будет указать datastore на новом ESXI хосте.
выбор датасторе ESXi
теперь нужно указать vMotion Priority, советую оставить рекомендуемый, при этом варианте будет установлена оптимальная производительность при vMotion.
Смотрим сводку по заданию и жмем finish.
В правом верхнем углу Vmware Web Client появится задание с переездом виртуальной машины.
Для чистоты эксперимента можете проверить доступность vm во время миграции, запустив команду ping до нее.
доступность vm при миграции
Вот так вот просто мигрировать работающую виртуальную машину без общего datastore в VMware vCenter, главное знать функции того чем управляешь.
Миграция виртуальных машин из vCenter 7 в vCenter 6.7
Недавно писал статью про миграцию виртуалок из vCenter 6.7 в vCenter 7.
Сегодня выполним обратную операцию, перенесём БЕЗ ПРОСТОЯ виртуальную машину из vCenter 7 в vCenter 6.7. В этом нам поможет новая опция vCenter 7 под названием «Cross vCenter Server Export».
Нам не понадобится перемещать хост из vCenter 7 в vCenter 6.7, но подготовительные работы провести придётся.
Рабочий стенд
Подготовка распределённых коммутаторов
Для успешного переноса виртуальной машины с помощью «Cross vCenter Server Export» нужно, чтобы совпадала версия распределённого коммутатора на источнике и получателе. У меня же версии не совпадают.
vCenter 6.7 поддерживает следующие версии распределённых коммутаторов:
vCenter 7 поддерживает следующие версии распределённых коммутаторов:
Поэтому нам требуется на обоих vCenter создать коммутаторы с версией 6.5.0 или 6.6.0. Лучше использовать максимальную совместимую версию 6.6.0.
Распределённый коммутатор на vCenter 6.7
На vCenter 6.7 создаю распределённый коммутатор «DSwitch test» версии 6.6.0.
Создаю на коммутаторе сеть управления и сеть для виртуальной машины.
Подключаю к коммутатору хост, на который буду мигрировать виртуальную машину. vMotion должен работать.
Распределённый коммутатор на vCenter 7
То же самое выполняю на vCenter 7. Создаю распределённый коммутатор «DSwitch temp».
Создаю на коммутаторе сеть управления и сеть для виртуальной машины. Подключаю к коммутатору хост, я одним проводом подключил тот же хост, на котором лежит виртуалка для миграции. vMotion должен работать.
Переключаю сеть виртуальной машины на новый распределённый коммутатор «DSwitch temp».
Подготовительные работы завершены.
Миграция виртуальной машины из vCenter 7 в vCenter 6.7
Выполняем миграцию виртуальной машины.
Попадаем в раздел Select a migration type. Выбираем тип миграции Cross vCenter Server export. NEXT.
Попадаем в раздел Select a target vCenter Server. Указываем FQDN или IP адрес от vCenter 6.7, куда будем мигрировать виртуальную машину. Также указываем логин и пароль пользователя. Я использую в качестве логина учётную запись administrator@vsphere.local от vCenter 6.7. LOGIN.
Игнорируем уведомление безопасности. YES.
Successfully connected. NEXT.
Попадаем в раздел Select a computer resource. Вбираем хост, который подключали к распределённому коммутатору 6.6.0. NEXT.
Попадаем в раздел Select storage. Выбираем хранилище. NEXT.
Попадаем в раздел Select folder. Выбираем location. NEXT.
Попадаем в раздел Select network. Указываем сеть для виртуальной машины.
Если версии виртуальных коммутаторов источника и получателя не совпадают, то получим ошибку:
Currently connected network interface ‘Network adapter 1’ cannot use network ‘XXX’ (DSwitch XXX), because «the destination distributed switch has a different version or vendor than the source distributed switch».
Если версии виртуальных коммутаторов источника и получателя совпадают, то ошибок не будет. NEXT.
Попадаем в раздел Select vMotion priority. Оставляю рекомендованный вариант. NEXT.
Попадаем в раздел Ready to complete. FINISH. Начинается миграция.
В vCenter 7 выполняется задача «Relocate virtual machine».
В vCenter 6.7 выполняется задача «Initiate vMotion receive operation».
Вот таким нехитрым образом мы БЕЗ ПРОСТОЯ перенесли виртуальную машину из vCenter 7 в vCenter 6.7.
Подготовка к миграции vCenter Server в vSphere 6.0 Update 2m. Часть 1
Недавно VMware объявили о выходе vSphere 6.0 Update 2m, официально поддерживающего инструмент миграции. Под катом чеклист, как подготовится к миграции (важные точки проверки), какие модели миграции есть, и на что обратить внимание при миграции с 5.5 Windows vCenter на версию 6.0
Миграция автоматически включена в новый vCenter Server Appliance 6.0 Update 2, уже доступна конфигурация миграции, и включена по умолчанию функция сохранения критических данных из Windows vCenter Server 5.5.
Если в вашей среде vSphere используются VDS (virtual distributed switch), то они мигрируют автоматически без дополнительных действий. Если вы хотите сохранить свою историю конфигураций и данные о производительности (статистику, события, задачи) с конфигурациями, есть опция которая позволяет перенести и эти данные. Только нужно помнить — это увеличит время вашей миграции и объем данных в вашей БД в vCenter Server.
Очень рекомендую использовать статью из вики KB 214620, которая поможет оценить и показать каким будет процесс миграции (как долго, какие ресурсы задействует и т.д.). В этом посте есть чек-лист того что нужно учитывать при подготовке к миграции, это имеет отношение к vSphere Single Sign-On домену и модели развертывания vCenter Server. Есть два самых главных момента, о инструменте миграции, которые я бы хотел особо подчеркнуть.
Первое. Будет выполнена не только ваша миграция, но и обновление версии 5.5 (с любыми апдейтами) до версии 6.0 (Update 2). Перед миграцией проверьте все ли части VMware и все решения сторонних вендоров поддерживают vSphere 6.0. Процедура миграции и апдейта не изменилась с прошлой версии, но сейчас есть механизм, который значительно упростил этот процесс.
Второй важный момент – нужно удостоверится что все конфигурации Windows vCenter Server уже сохранены. Сюда входят такие (но не только) данные и настройки: IP адреса, FQDN, UUID, сертификаты и MoRef IDs. Это делает процесс миграции намного проще, так как все части структуры общаются с vCenter Server через стандарт идентификации UUID, и они будут задействованы уже после миграции, как было и в старой версии. Этот список пунктов проверки очень важная часть подготовки процесса безболезненной миграции.
vSphere домен
Золотое правило подготовки к любой миграции и апдейтам: «нужно хорошо знать свою ИТ-инфраструктуру». Есть две сферы, на которых также нужно сфокусироваться — это модели развертывания vSphere Single Sign-On домен (SSO) и vCenter Server.
Давайте вначале разберемся с SSO доменом. В vSphere 5.5 у вас должна быть возможность объединить vSphere SSO домен, если вам это необходимо. Единственная ваша возможность сделать такое объединение – это в версии 5.5, потому что в версии 6.0 это сделать будет невозможно.
Если у вас есть желание объединить домены vSphere SSO, необходимо до миграции сделать следующее:
• Разверните новый внешний SSO сервер
• Укажите vCenter Inventory Service, Web Client, и vCenter Server Service на новом SSO сервере
• Если вы идете от внутренней модели развертывания к внешней, должен быть установлен внутренний SSO компонент
После того, как процесс завершен, ваш SSO домен будет объединен, как показано на диаграмме справа, и вы можете приступать к процессу миграции. Во время этого объединительного процесса, обратите внимание, что есть — vSphere 6.0 SSO maximums. В этом гайде – детали, которые важны при объединении vSphere SSO домена в версии 5.5. Если вас устраивают ваша существующая топология vSphere SSO, тогда вы можете спланировать развертывание vCenter Server.
Модели развертывания
Это следующий важный момент в развертывании vCenter Server. Windows vCenter Server 5.5 имеет две модели развертывания: простая и пользовательская.
Простая модель включена во все службы vCenter Server, на одной виртуальной машине. С другой стороны, пользовательская модель позволяет разделить службы vCenter Server (SSO, Inventory Service, Web Client и vCenter Server) на разные виртуальные машины. В vSphere 6.0 упрощена модель развертывания благодаря внедренному компоненту Platform Services Controller (PSC). Теперь мы можем управлять разными службами, которые распределены по единичному домену vSphere SSO. В такие службы входят: Single Sign-On (SSO), управление сертификатами, лицензирование, роли, тегирование и категоризацию, управление общим доступом).
В vSphere 6.0 у нас также две модели развертывания, только теперь они называются «внутренняя» и «внешняя». Внутренняя модель развертывания vSphere 6.0 соответствует простой модели в версии 5.5. Это значит, что все сервисы vCenter Server и компонент PSC остаются на той же виртуальной машине. Во внешнем развертывании vSphere 6.0 на виртуальных машинах уже есть PSC компонент и vCenter. Сейчас каждый компонент отвечает и управляет службами. Список рекомендованных топологий для версии 6.0 здесь.
Среди преимуществ внешней модели внедрения Enhanced Linked Mode может делать автоматические масштабирование через добавление Enhanced Linked Mode и vCenter Server.
Важно! vSphere 6.0 Update 2m – НЕ позволяет менять топологию развертывания по время процесса миграции.
Правила внешней модели миграции версии 5.5:
• Не держите vCenter Inventory Service на той же виртуальной машине, что и внешний SSO Server. Внутренний SSO Server выключится после того как vSphere SSO Service мигрирует, сделав vCenter Inventory Service недоступным.
• Когда все службы разделены (SSO, vCenter Inventory Service, Web Client и vCenter Server, есть отдельно на каждой виртуальной машине) вам нужно всего лишь запустить ассистент миграции.
• Ассистент миграции сделает блокировку, когда все расширения с сохранными настройками будут установлены на vSphere SSO Server. Расширение с сохранением настроек – это может быть один из сервисов, таких как vCenter Inventory Service, Auto Deploy, и vSphere Authentication Proxy.
• Ассистент миграции просигнализирует, когда расширения без сохранения настроек будут установлены на vSphere SSO Server. Расширение без сохранения настроек, которые используют данные, но не хранят их — vSphere Web Client и Dump Collector.
• Доступна миграция vSphere SSO Servers в обход балансировщика загрузки.
VMware получили много вопросов о том, стоит или нет менять модель разворачивания vCenter Server из внутренней на внешнюю, и когда стоит менять модель внедрения — до или после процесса миграции. Если вам не нужно объединять домены SSO – тогда вначале используйте встроенную модель. После этого используйте cmsso-команду, чтобы пересобрать и заново сконфигурировать вашу внутреннюю модель на внешнюю. Больше информации по использованию cmsso для изменения своей топологии доступно здесь. Если вам нужно объединить SSO домены, тогда ваша внутренняя модель станет внешней как часть процесса объединения доменов. Когда процесс объединения завершен, вы можете начать процесс миграции. В миграции внешних моделей сначала идет миграция всех vSphere SSO серверов в рамках vSphere домена, а затем миграция всех серверов vCenter. Это ничем не отличается от процесса обновления.
Как было отмечено выше, процесс миграции и обновления не изменился. До сих пор есть много действий, которые нужно выполнить, перед тем как начать миграцию, но сейчас у нас появился инструмент, позволяющий сделать процесс миграции гораздо проще.
И дайте нам знать, у вас получилось мигрировать или нет, можете отписаться в комментариях или в Твиттере через тег #migrate2vcsa так что техподдержка VMware может это отследить и ответить.
Сейчас мы разобрались с разными моделями миграции, внутренней, внешней для SSO доменов и серверов vCenter, в следующем посте в этой серии мы узнаем больше насчет Windows vCenter Server.
Мы разобрали чеклист, на что стоит обратить внимание при миграции, в версии 5.5 Windows vCenter.
Выделенные серверы в надежных дата-центрах Германии!
Любая конфигурация, быстрая сборка и бесплатная установка