Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    [SOLVED] Миграция ВМ с ESXi на PVE (ovftool)

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    [SOLVED] Миграция ВМ с ESXi на PVE (ovftool), Proxmox Виртуальная Среда
     
    linux
    Guest
    #1
    0
    14.12.2020 01:57:00
    Привет из Австралии! У нас возникла проблема, с которой нам нужна помощь. 4 управляемые ВМ работают на 2 хостах ESXi (2+2), и нет официального пути миграции (то есть избавиться от ESXi в пользу PVE). Во всей нашей инфраструктуре ESXi с радостью был удалён, и наши миграции прошли успешно, хотя мы управляли этими серверами, и они в основном были на базе CentOS, а не Debian. Программные стеки на остальных серверах зафиксированы и были восстановлены — на этих управляемых серверах используется собственное/закрытое ПО. При дальнейшей проработке этой темы мы выяснили, что у ESXi есть некоторые интересные особенности, которые сильно усложняют миграцию. К тому же, мы никогда не превышали лимиты бесплатной версии VMware. ESXi работает на бесплатных лицензиях, версии в ветке 6.x. У нас есть запасные хранилища и вычислительные мощности, чтобы создать промежуточный этап, если понадобится. Лучший успех, который мы имели, был в отключении службы usbarbitrator на хостах, а затем копировании VMDK, однако, несмотря на то что мы использовали WD USB SSD, напрямую подключенный к машинам, скорость была значительно снижена самими VMware. На копирование каждой ВМ уходило 1-2 дня, и в какой-то момент нам пришлось бы терпеть некоторые несоответствия в логах, хотя, надеемся, что собственные системы достаточно умные, чтобы всё свести воедино, так как 4 ВМ работают в кластере. На данный момент мы можем позволить себе некоторые трудности, если это уничтожит ESXi. Одна из проблем — версия VMFS (USB SSD) трудна для чтения извне. Использование ВМ крайне критично, поэтому мы перенастроили наши системы так, чтобы можно было отключать по 2 ВМ за раз, хотя 2 ВМ могут вызвать головную боль, а другие нет (то есть 1 ВМ — кластерный мастер). Эти 2 ВМ можно мигрировать на выходные, чтобы минимизировать прерывания. Мы смотрели на бесплатное ПО, которое утверждает, что позволяет делать именно то, что нам нужно (экспорт VMDK на уровне машинного кода, подобно Drive Snapshot), чтобы далее преобразовать в qcow2 и импортировать в PVE после того, как основные узлы будут перестроены и переустановлены, но результаты были не впечатляющими, хотя я бы не сказал, что мы пробовали все варианты на рынке. Какой самый логичный подход к этой задаче? Наша любовь к VMware нулевая, так что мы не планируем брать поддержку. Планы управления по ВМ не включают миграции, а стоимость их воссоздания колоссальна. Это сейчас вся наша нагрузка на ESXi, и мы хотим завершить эти работы и перейти на 100% PVE. Если есть проверенная система или подход к этой проблеме, мы с радостью запланируем окно и попробуем это сделать. PVE на нашем другом оборудовании великолепно работает, особенно по сравнению с ESXi. Если ничего другого, то стабильный и удобный веб-интерфейс ставит PVE далеко впереди конкурентов, так как мы использовали множество гипервизоров за эти годы. Последний релиз впечатляющий, и очевидно, что многолетняя работа достигает своего пика и приводит к созданию многофункционального гипервизора, достойного конкуренции с другими. Буду рад ответить на вопросы, если это поможет прояснить, где мы находимся. Огромное спасибо за внимание к нашему запросу. Всего доброго, LinuxOz
     
     
     
    linux
    Guest
    #2
    0
    03.01.2021 02:45:00
    @Dominic - Я отметил это как решённое и создам новую тему для проблемы с живой миграцией. Большое спасибо! Однако, пожалуйста, посмотри в начало ответа №6 на некоторые детали, которые стоит добавить в вашу Вики (по поводу ovftool).
     
     
     
    Dominic
    Guest
    #3
    0
    04.01.2021 09:24:00
    Спасибо, я добавил все три (совместимость, нехватка памяти, отсоединение дисков) в Wiki.
     
     
     
    linux
    Guest
    #4
    0
    04.01.2021 10:46:00
    Фантастика! Спасибо за это, Доминик. Очень ценю твою помощь с этой и другой темой. Прошу прощения, однако - я допустил ошибку и хотел написать ESXi 6.5 и 6.7 выше (я уже исправил свой ответ). Также, что ты думаешь о поведении по умолчанию SCSI, которое я объяснил в ответе #6? Я не уверен, является ли это ошибкой или ожидаемым поведением. Хотя, возможно, не стоит тратить время на исследование, но если ты сможешь воспроизвести это в PVE 6.3, тогда, возможно, стоит зафиксировать это для дальнейшего анализа и исправления?
     
     
     
    Dominic
    Guest
    #5
    0
    04.01.2021 11:12:00
    Рад помочь. Проблема с вики-страницей решена. Что касается SCSI: если вы создаете виртуальную машину через командную строку/API без указания параметра "scsihw", то в конфигурационном файле виртуальной машины этого свойства не будет. Если в конфигурации виртуальной машины не упоминается свойство "scsihw", подразумевается значение по умолчанию "lsi". Вы можете поискать в справочной странице qm информацию о "scsihw". Обратите внимание, что "lsi" в конфигурации — это сокращение для LSI 53C895A в графическом интерфейсе. Перевод происходит непосредственно в коде, кстати. Быстрый предположение: функция импорта не устанавливает scsihw, и тогда используется значение по умолчанию "lsi". На самом деле, я не знаю, почему мы используем другое значение по умолчанию в мастере создания виртуальной машины, чем в API. То же самое происходит, например, и с выделенной памятью. 2048 — это значение по умолчанию в мастере создания виртуальной машины, а в API — 512. Так что это не баг. Если вам нужен другой контроллер, вы можете изменить его в графическом интерфейсе в меню "Аппаратное обеспечение" виртуальной машины.
     
     
     
    linux
    Guest
    #6
    0
    04.01.2021 11:54:00
    Спасибо за исправление моих ошибок и за объяснения. Всё это имеет смысл - рад знать, что это всего лишь разница. Ценю ссылки на man и git - интересно увидеть переводы и узнать больше о внутреннем устройстве (какое сравнение с закрытым исходным кодом ESXi!). Любопытно, что между GUI и API есть различия в настройках по умолчанию. Получается, что GUI может быть "опережает" API по этим настройкам? Если бы ты сравнил соответствующие строки кода, которые задают эти настройки, интересно, удалось бы найти момент, когда они совпадали. Например, выделение 512 МБ памяти кажется чем-то, что я бы ожидал от старого гипервизора, а 2 ГБ - это уже современная норма.
     
     
     
    Dominic
    Guest
    #7
    0
    04.01.2021 12:29:00
    Я думаю, можно так сказать. Мы стараемся поддерживать API как можно более стабильным. Это изменение произошло в мае 2020 года https://git.proxmox.com/?p=pve-manager.git;a=commit;h=954c7dd8cc670074e8bfc0ad90fecdbc0aaeaf0e
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

    Конфиденциальность Оферта
    © 2026 Proxmox.su
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры