Конвертировать vmware в proxmox

Обновлено: 02.07.2024

Конфигурация компьютера
Процессор: FX6300
Материнская плата: Asus
Память: "Kingston" 8GB
HDD: SSD Virtex 120Gb, WD 500Gb, Samsung PATA 500Gb, WD 1,5 Tb
Видеокарта: Asus Radeon 7750 1024mb
Блок питания: FPS 550W
CD/DVD: NEC
Монитор: Samsung 940N
Ноутбук/нетбук: Lenovo
ОС: Windows 7, FreeBSD 10, Debian 7 (new)
Индекс производительности Windows: 7.0

Добрый день.
Есть Витруальная машина (ProxMox) основанная на KVM.
Необходимо конвертнуть KVM с расширением *.raw, в Hyper-V на Windows.

ps Поиск в гугле мало что показал, все в основном делают на оборот.

Конфигурация компьютера
Процессор: FX6300
Материнская плата: Asus
Память: "Kingston" 8GB
HDD: SSD Virtex 120Gb, WD 500Gb, Samsung PATA 500Gb, WD 1,5 Tb
Видеокарта: Asus Radeon 7750 1024mb
Блок питания: FPS 550W
CD/DVD: NEC
Монитор: Samsung 940N
Ноутбук/нетбук: Lenovo
ОС: Windows 7, FreeBSD 10, Debian 7 (new)
Индекс производительности Windows: 7.0

Сам задал сам отвечу
Если вы переносите VM из среды Linux и там установлены KVM и QEMU
то можно воспользоваться встроенными утилитами QEMU

Для конвертации одного формата образа в другой используется опция convert:

Следом VBoxManage.exe конвертируем из vdi в vhd
создаём машину в Hyper-V и пользуемся.

Последний раз редактировалось kaEwituS, 21-01-2015 в 11:07 .

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

Конфигурация компьютера
Процессор: FX6300
Материнская плата: Asus
Память: "Kingston" 8GB
HDD: SSD Virtex 120Gb, WD 500Gb, Samsung PATA 500Gb, WD 1,5 Tb
Видеокарта: Asus Radeon 7750 1024mb
Блок питания: FPS 550W
CD/DVD: NEC
Монитор: Samsung 940N
Ноутбук/нетбук: Lenovo
ОС: Windows 7, FreeBSD 10, Debian 7 (new)
Индекс производительности Windows: 7.0

Кому интересно:
все новые версии qemu могут портировать в любой формат.
код прежний:

Конфигурация компьютера
Процессор: FX6300
Материнская плата: Asus
Память: "Kingston" 8GB
HDD: SSD Virtex 120Gb, WD 500Gb, Samsung PATA 500Gb, WD 1,5 Tb
Видеокарта: Asus Radeon 7750 1024mb
Блок питания: FPS 550W
CD/DVD: NEC
Монитор: Samsung 940N
Ноутбук/нетбук: Lenovo
ОС: Windows 7, FreeBSD 10, Debian 7 (new)
Индекс производительности Windows: 7.0

Дополню:
как ещё проще перенести Вин машину из любой виртуалки.
Скачиваем disk2vhd, запускаем на виртуальной машине, программа делает полный образ любой Win машины, и запускаем в Hyper-V

Фарумчане, прошу помощи.

Я хочу использовать qemu-img conver, но у меня нет исходного файла!

тут исходный файл 100-2008r2.raw

все новые версии qemu могут портировать в любой формат.
код прежний:
Код:
qemu-img convert -f raw -O vhd 100-2008r2.raw 100-2008r2.vhd »

Я ни как не могу получить доступ к этому исходному файлу. Не могу зайти на хранилище

вот хранилище:

оно не имеет Path/Target`a . я не могу его ни куда примонтировать

Примонтировать просто /dev/sda3 неполучится - это же LVM.

так же мне не помогает vgdisplay -v . Непонятно как его примонтировать.

Увижу корневую систему, но мне то нужен *.raw файл VM машины.

Есть возможность сделать бекап машины с веб морды. Но как я понял, бекапирование с морды делается vz_dump`ом. Вот лог бекапирования:

Процесс миграции

Из имеющихся возможных вариантов проведения перевода виртуальной машины из среды vSphere в среду Proxmox покажу простейший и как мне кажется наиболее прямолинейный способ.

Во-первых, с помощью веб интерфейса клиента vSphere проводим экспорт виртуальной машины в виде OVF темплейта. Для этого в контекстном меню данной виртуальной машины выбираем Template -> Export OVF Template. Перед выполнением данного действия необходимо убедиться, что сама ВМ находится в выключенном состоянии. В результате выполнения операции экспорта на рабочий компьютер загрузится несколько файлов данной ВМ (ovf, vmdk, nvram, mf).

Во-вторых, загружаем все файлы, полученные в результате предыдущей операции, на сервер Proxmox. Это можно сделать с помощью команды scp в Linux/MacOS или pscp в Windows.

В-третьих, когда все файлы будут загружены, можно начать импорт этих файлов в Proxmox-VE. Пример команды в CLI для импорта ВМ приведен ниже.

Установить в настройках жестких дисках параметр discard=on.
Добавить необходимые сетевые адаптеры.
Выставить параметр QEMU guest agent в Enabled.
Отредактировать название ВМ в случае необходимости.

В-четвертых, пришло время запускать импортированную нами виртуальную машину. Так как в средах vSphere и Proxmox наименование сетевых адаптеров различается, необходимо через VNC консоль гипервизора произвести их переконфигурацию. После этого должна появиться связь с виртуальной машиной из сети. Соответсвенно можно будет заходить на нее удаленно и выполнять дальнешие действия через SSH или RDP. В ряде случаев для нормального функционирования определенных сервисов потребуется перезагрузка гостевой машины.

В-пятых, нам необходимо отключить vmware-tools, и включить qemu agent. Так, например, в случае с использованием Ubuntu Linux в качестве гостевой ОС, нам нужно выполнить две команды в шелле виртуальной машины.

В-шестых, после процедуры импорта, все диски гостевой машины в Proxmox будут занимать полное место на датасторе, вне зависиомсти от использования функионала Thin Provisioning. Если мы используем данную технологию, то необходимо в шелле гостевой машины выполнить следующую команду, чтобы освободить на датасторе неиспользуемое место.

В-седьмых, после того, как все необходимые действия по переносу будут выполнены, рекомендую удалить полностью первоначальную ВМ из среды vSphere. Кроме этого удаляем все ненужные файлы, которые создавались или копировались в процессе проведения работ по миграции. На этом операцию по миграции можно считать успешно выполненной и полностью завершенной.

Резюме

Алогиртм, расписанный в этой статье, сам по себе не сложный и позволяет в случае необходимости плавно перенести нужное количество гостевых машин из среды VMware в среду Proxmox-VE. Однако, надо понимать, что большая часть задач требует ручного выполнения и отнимает определенное время. В остальном, процесс миграции не должен вызвать затруднений у читателей моего блога.

В статье «Магия виртуализации: вводный курс в Proxmox VE» мы успешно установили на сервер гипервизор, подключили к нему хранилище, позаботились об элементарной безопасности и даже создали первую виртуальную машину. Теперь разберем как реализовать самые базовые задачи, которые приходится выполнять, чтобы всегда иметь возможность восстановить работу сервисов в случае сбоя.

Штатные инструменты Proxmox позволяют не только выполнять резервное копирование данных, но и создавать наборы предварительно настроенных образов операционных систем для быстрого развертывания. Это не только помогает при необходимости создать новый сервер для любого сервиса за несколько секунд, но также и уменьшает время простоя до минимального.

Рассказывать о необходимости создания бэкапов мы не будем, поскольку это очевидно и уже давно является аксиомой. Остановимся на некоторых неочевидных вещах и особенностях.

Сначала рассмотрим каким образом сохраняются данные при процедуре резервного копирования.

Алгоритмы резервного копирования

Начнем с того, что Proxmox имеет неплохой штатный инструментарий для создания резервных копий виртуальных машин. Он позволяет легко сохранить все данные виртуальной машины и поддерживает два механизма сжатия, а также три метода создания этих копий.

Разберем вначале механизмы сжатия:

Сжатие LZO. Алгоритм сжатия данных без потерь, придуманный еще в середине 90-х годов. Код был написан Маркусом Оберхеймером (реализуется в Proxmox утилитой lzop). Основной особенностью этого алгоритма является очень скоростная распаковка. Следовательно, любая резервная копия, созданная с помощью этого алгоритма, может при необходимости быть развернута за минимальное время.
Сжатие GZIP. При использовании этого алгоритма резервная копия будет «на лету» сжиматься утилитой GNU Zip, использующей мощный алгоритм Deflate, созданный Филом Кацем. Основной упор делается на максимальное сжатие данных, что позволяет сократить место на диске, занимаемое резервными копиями. Главным отличием от LZO является то, что процедуры компрессии/декомпреcсии занимают достаточно большое количество времени.

Режимы архивирования

Proxmox предлагает на выбор системному администратору три метода резервного копирования. С помощью них можно решить требуемую задачу, определив приоритет между необходимостью простоя и надежностью сделанной резервной копии:

Режим Snapshot (Снимок). Этот режим можно еще назвать как Live backup, поскольку для его использования не требуется останавливать работу виртуальной машины. Использование этого механизма не прерывает работу VM, но имеет два очень серьезных недостатка — могут возникать проблемы из-за блокировок файлов операционной системой и самая низкая скорость создания. Резервные копии, созданные этим методом, надо всегда проверять в тестовой среде. В противном случае есть риск, что при необходимости экстренного восстановления, они могут дать сбой.
Режим Suspend (Приостановка). Виртуальная машина временно «замораживает» свое состояние, до окончания процесса резервного копирования. Содержимое оперативной памяти не стирается, что позволяет продолжить работу ровно с той точки, на которой работа была приостановлена. Разумеется, это вызывает простой сервера на время копирования информации, зато нет необходимости выключения/включения виртуальной машины, что достаточно критично для некоторых сервисов. Особенно, если запуск части сервисов не является автоматическим. Тем не менее такие резервные копии также следует разворачивать в тестовой среде для проверки.
Режим Stop (Остановка). Самый надежный способ резервного копирования, но требующий полного выключения виртуальной машины. Отправляется команда на штатное выключение, после остановки выполняется резервное копирование и затем отдается команда на включение виртуальной машины. Количество ошибок при таком подходе минимально и чаще всего сводится к нулю. Резервные копии, созданные таким способом, практически всегда разворачиваются корректно.

Выполнение процедуры резервирования

Для создания резервной копии:

Переходим на нужную виртуальную машину.
Выбираем пункт Резервирование.
Нажимаем кнопку Резервировать сейчас. Откроется окно, в котором можно будет выбрать параметры будущей резервной копии.

В поле Хост вводим IP-адрес нашего сервера виртуализации, в поле Имя пользователя вводим root, в поле Пароль — тот, который был выбран при установке, а в поле Порт указываем «22» (либо любой другой порт, который был задан для SSH-подключений).
Нажимаем кнопку Быстрое соединение и, если все данные были введены правильно, то в активной панели Вы увидите все файлы, расположенные на сервере.
Переходим в директорию /mnt/storage. Все создаваемые резервные копии будут лежать в поддиректории «dump». Они будут иметь вид:
- vzdump-qemu-номер_машины-дата-время.vma.gz в случае выбора метода GZIP;
- vzdump-qemu-номер_машины-дата-время.vma.lzo в случае выбора метода LZO.

raw — образ диска;
conf — конфигурация VM;
fw — настройки файервола.

Восстановление из резервной копии

Рассмотрим ситуацию, когда виртуальную машину случайно удалили и требуется ее экстренное восстановление из резервной копии:

Открываем хранилище, на котором лежит резервная копия.
Переходим на вкладку Содержимое.
Выбираем нужную копию и нажимаем кнопку Восстановление.

Клонирование виртуальной машины

Для примера, предположим, что в компании требуется внести изменения в какой-либо критичный сервис. Такое изменение реализуется через внесение множества правок в конфигурационные файлы. Результат при этом непредсказуем и любая ошибка способна вызвать сбой сервиса. Чтобы подобный эксперимент не затронул работающий сервер, рекомендуется выполнить клонирование виртуальной машины.

Механизм клонирования создаст точную копию виртуального сервера, с которой допустимо проводить любые изменения, при этом не затрагивая работу основного сервиса. Затем, если изменения будут успешно применены, новая VM запускается в работу, а старая выключается. В этом процессе есть особенность, о которой всегда следует помнить. На клонированной машине IP-адрес будет точно таким же, как и у исходной VM, то есть при ее запуске возникнет конфликт адресов.

Расскажем, как избежать такой ситуации. Непосредственно перед выполнением клонирования, следует внести изменения в конфигурацию сети. Для этого необходимо временно изменить IP-адрес, но не перезапускать сетевой сервис. После выполнения клонирования на основной машине следует вернуть настройки обратно, а на клонированной машине задать любой другой IP-адрес. Тем самым мы получим две копии одного и того же сервера на разных адресах. Это позволит быстро ввести новый сервис в работу.

Если этим сервисом является веб-сервер, то достаточно только изменить А-запись у Вашего DNS-провайдера, после чего запросы клиентов по этому доменному имени будут направляться уже на адрес клонированной виртуальной машины.

Кстати, Selectel предоставляет всем своим клиентам услугу размещения любого количества доменов на NS-серверах бесплатно. Управление записями осуществляется как с помощью нашей панели управления, так и с помощью специального API. Подробнее об этом читайте в нашей базе знаний.

Клонирование VM в Proxmox является очень простой задачей. Для ее выполнения необходимо выполнить следующие действия:

Перейти на нужную нам машину.
Выбрать из меню More пункт Clone.
В открывшемся окне заполнить параметр Имя.

Форматы виртуальных накопителей

Расскажем подробнее об используемых в Proxmox форматах накопителей:

Небольшим минусом работы с этим форматом является следующее: чтобы примонтировать такой образ в любой другой системе, потребуется вначале загрузить особый драйвер nbd, а также использовать утилиту qemu-nbd, которая позволит операционной системе обращаться к файлу как к обычному блочному устройству. После этого образ станет доступен для монтирования, разбиения на разделы, осуществления проверки файловой системы и прочих операций.

Работа с образами дисков

В комплекте c Proxmox есть очень удобная утилита, под названием qemu-img. Одной из ее функций является конвертирование образов виртуальных дисков. Чтобы воспользоваться им, достаточно открыть консоль гипервизора и выполнить команду в формате:

Благодаря этой же команде можно принудительно создать нужный образ, используя аргумент create:

Такая команда создаст образ test в формате RAW, размером 40 Гб. Теперь он годится для подключения к любой из виртуальных машин.

Изменение размера виртуального диска

И в заключение покажем как увеличить размер образа диска, если по каким-то причинам места на нем перестало хватать. Для этого воспользуемся аргументом resize:

Теперь наш образ стал размером 80 Гб. Посмотреть подробную информацию об образе можно с помощью аргумента info:

Не стоит забывать, что само расширение образа не увеличит размер раздела автоматически — просто добавит доступное свободное пространство. Для увеличения раздела воспользуйтесь командой:

где /dev/sda1 — нужный раздел.

Автоматизация создания резервных копий

Использование ручного способа создания резервных копий — задача весьма трудоемкая и занимает много времени. Поэтому Proxmox VE содержит в себе средство для автоматического резервного копирования по расписанию. Рассмотрим, как это сделать:

Используя веб-интерфейс гипервизора, открываем пункт Датацентр.
Выбираем пункт Резервирование.
Нажимаем кнопку Добавить.
Задаем параметры для планировщика.

Заключение

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

Конечно, это не единственный возможный способ сохранения важных данных. Существует множество инструментов, например, Duplicity, с помощью которых можно создавать полные и инкрементные копии содержимого виртуальных серверов на базе Linux.

При выполнении процедур резервного копирования всегда следует учитывать, что они активно нагружают дисковую подсистему. В связи с этим выполнять эти процедуры рекомендуется в моменты минимальной нагрузки, чтобы избежать задержек при выполнении операций ввода-вывода внутри машин. Следить за статусом задержек дисковых операций можно непосредственно из веб-интерфейса гипервизора (параметр IO delay).

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

среда, 11 марта 2020 г.

Руководство администратора Proxmox VE R 6.0 Глава 10.3-7.

Виртуальные машины Qemu/KVM

Миграция

Онлайн-миграция (она же живая миграция)
Offline Миграция

Онлайн-Миграция

Когда ваша виртуальная машина запущена и у нее нет определенных локальных ресурсов (таких как диски в локальном хранилище, передаваемые через устройства и т. д.) вы можете инициировать динамическую миграцию с флагом-online.

Как это работает

Это запускает процесс Qemu на целевом хосте с флагом incoming, что означает, что процесс запускается и ожидает данных памяти и состояний устройства от исходной виртуальной машины (так как все другие ресурсы, например диски, являются общими, содержимое памяти и состояние устройства-единственные вещи, оставшиеся для передачи).

Виртуальная машина не имеет локальных ресурсов (например, проброшенные устройства, локальные диски и т. д.).
Хосты находятся в одном кластере Proxmox VE.
Хосты имеют работающее (и стабильное) сетевое соединение.
Целевой хост должен иметь те же или более высокие версии пакетов Proxmox VE. (Это может работать и в другую сторону, но результат не гарантируется)

Offline Миграция

Копии и клоны

Установка виртуальной машины обычно выполняется с помощью установочного носителя (CD-ROM) от поставщика операционной системы. В зависимости от операционной системы, это может быть трудоемкой задачей, которую можно избежать.

Полный Клон

Результатом такой копии является независимая виртуальная машина. Новая виртуальная машина не имеет общих ресурсов хранения с исходной.

Связанный Клон

Современные драйверы хранения поддерживают способ генерирования быстро связанных клонов. Такой клон - это записываемая копия, исходное содержимое которой совпадает с исходными данными. Создание связанного клона происходит практически мгновенно и изначально не требует дополнительного пространства.

Они называются связанными, потому что новый образ все еще ссылается на оригинал. Немодифицированные блоки данных считываются из исходного изображения, но изменения записываются (а затем считываются) из нового места. Эта техника называется "Copy-on-write" (копирование на запись).

Для этого требуется, чтобы исходный том был доступен только для чтения. С помощью Proxmox VE можно преобразовать любую виртуальную машину в шаблон только для чтения). Такие шаблоны впоследствии могут быть использованы для эффективного создания связанных клонов. На заметку Вы не можете удалить исходный шаблон, пока существуют связанные клоны. Изменить целевое хранилище для связанных клонов невозможно, поскольку это внутренняя функция хранилища.

Параметр целевой узел позволяет создать новую виртуальную машину на другом узле. Единственное ограничение заключается в том, что виртуальная машина находится в общем хранилище, и это хранилище также доступно на целевом узле.

Шаблоны виртуальных машин

Идентификатор поколения виртуальной машины

Proxmox VE поддерживает Virtual Machine Generation ID (vmgenid) 15 для виртуальных машин. Он может быть использован гостевой операционной системой для обнаружения любого события, приводящего к событию сдвига времени, например, восстановления резервной копии или отката моментального снимка.

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

Импорт виртуальных машин и образов дисков

Экспорт виртуальной машины из внешнего гипервизора обычно выполняется в виде одного или нескольких образов диска с конфигурационным файлом, описывающим параметры виртуальной машины (ОЗУ, количество ядер).

Образы дисков могут быть в формате vmdk, если диски поступают из VMware или VirtualBox, или qcow2, если диски поступают из гипервизора KVM. Наиболее популярным форматом конфигурации для экспорта виртуальных машин является стандарт OVF, но на практике взаимодействие ограничено, поскольку многие настройки не реализованы в самом стандарте, а гипервизоры экспортируют дополнительную информацию в нестандартные расширения.

Помимо проблемы форматирования, импорт образов дисков из других гипервизоров может завершиться неудачей, если эмулируемое оборудование слишком сильно меняется от одного гипервизора к другому. Виртуальные машины Windows особенно чувствительны к этому, так как ОС очень придирчива к любым изменениям оборудования. Эта проблема может быть решена путем установки утилиты MergeIDE.zip доступной в интернете, перед экспортом и выбором типа жесткого диска IDE, перед загрузкой импортированной виртуальной машины Windows.

Наконец, возникает вопрос о паравиртуализированных драйверах, которые повышают скорость эмулируемой системы и специфичны для гипервизора. GNU/Linux и другие свободные ОС Unix имеют все необходимые драйверы, установленные по умолчанию, и вы можете переключиться на паравиртуализированные драйверы сразу после импорта виртуальной машины. Для виртуальных машин Windows вам необходимо самостоятельно установить паравиртуализированные драйверы Windows.

Пошаговый пример импорта Windows OVF

Microsoft предоставляет виртуальные машины для загрузки, для быстрого старта разработчиков Windows. Мы собираемся использовать один из них, чтобы продемонстрировать функцию импорта OVF.

После получения информации о пользовательском соглашении выберите Windows 10 Enterprise (Evaluation-Build) для платформы VMware и загрузите zip.

Извлеките образ диска из архива zip

Используя утилиту unzip или любой архиватор по вашему выбору, распакуйте zip и скопируйте через ssh/scp файлы ovf и vmdk на ваш хост Proxmox VE.

Импорт виртуальной машины

Добавление образа внешнего диска к виртуальной машине

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

Читайте также: