LINUX.ORG.RU
решено ФорумAdmin

Как перенести хост с linux в виртуалку vmware esxi?

 , ,


0

1

Есть образ img, снятый с хоста и конвертированный в vmdk. Он загружается и успешно работает на виртуалках virtualbox и vmware workstation. Но при добавлении его в виртуалки vmware esxi никак не могу получить работающую виртуалку. С virtualbox и vmware, я экспортировал, чтобы получить ovf, но похоже толку от этого ноль. Выбираю пункт Deploy a virtual machine from an OVF or OVA file При попытке создания виртуалки из файлов vmdk+ovf в vmware получаю ошибку:

Line 25: Unsupported hardware family 'virtualbox-2.2'.

Review your settings selection before finishing the wizard

There was an error creating the import specification from the OVF file. 

Попробовал конвертировать родной программой установленной на виндовс 10 - vmware workstation. И повторить тот-же процесс, но получаю аналогичную ошибку при добавлении виртуалки на wvmare.

Line 25: Unsupported hardware family 'vmx-19' 

Попытка тоже самого процесса через vsphere при выборе пункта Deploy OVF template тоже привела к ошибке через пол минуты валидации:

Transfer failed: The OVF deskriptor oa not available 

При попытке создания виртуалки и добавлении диска vmdk в качестве Existing Hard Disk тоже ошибка (как на vmware, так и на vsphere):

Unfortunately, we hit an error that we weren't expecting.

The client may continue working, but at this point, we recommend refreshing your browser and submitting a bug report.

Пытался также скопировать все файлы виртуальной машины на vmware и выполнить Register VM. Процесс вернул status invalid. Кажется, идей больше не осталось, как и пунктов куда можно потыкать, чтобы получить виртуалку. В интерине решения не могу найти.

Где-то пишут про ovftool.exe где-то про vmkfstools. Что из этого нужно, а что нет? Буду благодарен за описание процесса по пунктам.

Версия ESXI 6.5



Последнее исправление: crazy (всего исправлений: 1)

Создай новую виртуалку и подсунь ей образ диска. Останется только сеть перенастроить. А эти якобы универсальные форматы машин - херня.

thesis ★★★★★
()

Твой перенос в виде OVA образа более сложная процедура.

С Linux вообще можно поступить проще.

Как тебе посоветовал другой комментатор в теме - просто создай новую машину, залей на гипервизор VMDK образ, подключи его к ВМ и попробуй загрузиться.

А так, Linux вообще переносится на другое железо или в виртуальное окружение через создание архива файл системы или rsync.

Например через rsync последовательность действий такая:

  • загружаешься на исходной системе с LiveCD;
  • загружаешься в ВМ куда будешь переносить систему с LiveCD;
  • разрешаешь вход root по SSH на обоих LiveCD системах;
  • ставишь пакет rsync, если его нет;
  • создаёшь на целевой ВМ разделы на диске, на них файловые системы;
  • монтируешь файловые системы на целевой системе, например в /mnt;
  • Если создаёшь отдельный /boot, то ещё и его монтируешь; т.е. в /mnt монтируешь корневую ФС, в /mnt/boot - файловую систему /boot, если нужно ещё /boot/EFI и прочие файловые системы, если хочешь создать другую схему разметки;
  • на исходной системе так же монтируешь исходные файловые системы, например в /mnt и прочие файловые системы в нужной последовательности;
  • выполняешь перенос:
cd /mnt
rsync -zavp ./ root@IP:/mnt/

IP - IP адрес виртуальной машины, куда переносишь исходную систему.

  • Далее в ВМ куда перенёс систему смотришь новые идентификаторы файловых систем и имена разделов
blkid
  • правишь /etc/fstab
  • обновляешь initramfs и ставишь загрузчик
mount -o bind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
chroot /mnt /bin/bash
dpkg-recongiure initramfs-tools
grub-install /dev/sda
grub-mkconfig > /boot/grub/grub.cfg

Последние команды могут немного отличаться в зависимости переносимой системы.

Перенос в виде архива аналогичен, только ты в начале архивируешь исходную систему, потом распаковываешь на целевой системе, точно также правишь /etc/fstab, обновляешь initramfs, ставишь загрузчик и генерируешь его конфиг.

Всё.

kostik87 ★★★★★
()

Создаёшь в esxi пустой диск такого же размера (ну или больше, если там из-за округлений не получается), грузишься виртуалкой с livecd, и заливаешь с помощью dd raw-образ на /dev/sda.

Если образ доступен по http то можно так:

wget -q -O - https://domain/path.img | dd of=/dev/sda bs=1048576 status=progress

Если не http то можно через netcat его прислать (в том числе с запущеной исходной системы, если там read-only всё смонтировано) но поскольку netcat везде разный то конкретную команду не скажу (там надо сделать чтоб он сам закрылся после пересылки данных, иначе будет висеть и не поймёшь прислалось оно или нет + буферы всякие).

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 2)
Ответ на: комментарий от firkax

Ага, сложно, но зато быстро.

Но вообще, ничего сложного нет, это был сарказм, достаточно включить голову.

А теперь представь, у тебя есть диск размером ну допустим 100 ГБ, хотя там, скорее всего не 100, а все 500. А занято допустим 20 Гб. И тебе твоим dd нужно лить по сети или в образ диска, не 20 Гб, а все 100 или 500 Гб.

То, что я описал, в зависимости от скорости сети делается минут за 15-20. Ты же свою операцию будешь делать несколько часов.

И все равно может потребоваться делать chroot и обновлять initramfs.

Тебе это сложно, потому что ты не понимаешь смысл и не хочешь разбираться.

Более того эту процедуру можно проделать из работающей системы, но здесь есть некоторые особенности.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от firkax

Мда, советы даёшь а даже то, что образ dd можно лить через ssh не в курсе.

На исходной системе загружаешься с LiveCD на целевой тоже и делаешь:

dd if=/dev/sda | ssh root@ip 'dd of=/dev/sda'

Но так ты будешь передавать весь объем диска.

Поэтому rsync быстрее, позволяет продолжить после обрыва связи.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от pfg

Ну так прочитай мой комментарий на два сообщения выше.

Собственно, второй комментарий в теме.

В виртуальном окружении обычно используется bios, а не uefi.

kostik87 ★★★★★
()
Последнее исправление: kostik87 (всего исправлений: 1)
Ответ на: комментарий от kostik87

И тебе твоим dd нужно лить по сети или в образ диска, не 20 Гб, а все 100 или 500 Гб.

Ок, добавим gzip -1 в середину. Но да, если занято 20гб и ещё 500 не занято, но записано каким-то старым мусором - будет дольше. Зато преимущество огромное: качается то оно само, трафик обычно бесплатный, своё ценное время на лишние действия не тратишь. И совместимо с практически любыми ОС.

И все равно может потребоваться делать chroot и обновлять initramfs.

Только если оно кастомное строго под конкретное железо собиралось.

Тебе это сложно, потому что ты не понимаешь смысл и не хочешь разбираться.

Чего-чего? Тут вопрос чисто в затратах личного времени. Если нет аргументов за то, чтобы его тратить - лучше не тратить. Если б там был критичный к простою сервер - то даже твой способ всё равно бы не годился: надо было бы сначала поднимать работающий его экземпляр в виртуалке, а потом планировать как максимально незаметно сделать финальное переключение с финальной синхронизацией данных (естественно, минимизируя объём для этой последней передачи и переслав всё что можно заранее). А автор явно никуда не торопится, зачем ему эта возня? Пусть оно копирует хоть 5 часов, зато само и без ручной возни.

firkax ★★★★★
()
Ответ на: комментарий от firkax

Решил воспользоваться этим способом, потому что он показался самым простым. Перенёс диск с помощью ssh. Всё получилось.

Хочу только уточнить насчет опций. Я пока в dd не писал ничего.

bs 1048576 байт это нормально для диска большого объема? 500+ГБ ?

crazy
() автор топика
Ответ на: комментарий от crazy

Не понял, как ты перенёс диск но не делал при этом dd.

bs=1048576 это норм, просто дефолтное значение там 512 - он бы копировал блоками по 512 байт, это явно плохо. Вообще 32к наверно уже тоже норм, но я на всякий случай 1м ставлю.

firkax ★★★★★
()
Ответ на: комментарий от crazy

Хорошо, а теперь подумай вот над чем.

В системах виртуализации виртуальный диск обычно создаётся необходимого размера, но физически занимаемое пространство в системе хранения зависит от объёма записанных данных.

Вот ты пишешь про 500+ Гб размер диска системы откуда ты переносил данные в систему виртуализации.

У тебя на этом диске суммарный объём записанных файлов быть несколько десятков Гб. Но тебе пришлось прочитать всю ёмкость диска и записать тоже всю ёмкость диска в виртуальный диск в системе виртуализации. И пространство, которое виртуальный диск занимает на системе хранения системы виртуализации тоже равно всему размеру диска исходной системы.

Если у тебя объём файлов, которые были в исходной системе сопоставим со всей ёмкостью диска, то тут даже нечего думать, ты сделал нормально.

А если у тебя из 500 Гб с лишним от размера диска занято 20 Гб, то ты поступил не очень хорошо.

Поэтому и целесообразно использовать rsync.

Но другой комментатор упомянул мысль, что если у тебя там много мелких файлов размером в несколько килобайт, то такая процедура копирования будет идти очень медленно.

Правда он удалил этот комментарий, но он тоже по своему прав.

kostik87 ★★★★★
()