Онлайн миграция виртуальных машин между локальными хранилищами Proxmox

Я же указываю альтернативное хранилище, почему он мне по прежнему пишет про исходное?

Вообще возможен вариант сабжевой миграции?

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

надо на лету, руками я уже что только не переносил. надо без простоя

ты шо там кластер мутишь?

6 pve из интерфейса мигрирует

убери отсюда true «—with-local-disks true»

Это работает начиная с 5.3 но хранилише точнее имя должны быть одинаковые. Если нет возможности с одинаковыми именами. То поднимаеш одно общие типа NFS и переносиш диск туда, ну а дальше все просто. И да это команда в 5 версии тестовая, в 6 вроде как внедрили в web интерфейс

Если хранилища одинаковые, говорит что по назначению нет файла диска

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

в смысле мечты ? на 5 я мигрировал с помощью команд

qm migrate 117 HOSTNAME -online -targetstorage vm1 -with-local-disk

в 6 я из веб интерфейса это делаю. У тебя кластер собран ?

Да, кластер поднят

Собран кластер, я так понял что миграция предполагается с применением глобального хранилища, сейчас же разбираюсь с миграцией из/на локальное хранилище.

Можете помочь, хотя бы наводящие вопросы по задавать, что может быть не так…

Народ, я что понял, оно не хочет мигрировать диски формата raw, так как они не поддерживают снапшоты.

я создал машину с qсow2, и у меня все из интерфейса отработало

А теперь я ничего не понял, я решил вернуть машину на исходный хост, а интерфейс не дает выбрать хранилище и ругается по старому

Ну так я про локальное и говорю, у меня нет шаред стореджа

ну с подключением, прежде чем пост создавать надо документацию почитать, в проксе она довольно хорошая

Вот моя картина хранилищь

Ответ из службы поддержки:

The shared 1 line does not make sense for storages that are only available on one node, and this is likely the reason PVE becomes confused. Please unset the shared flag for your local storages and try again.

я убрал метку «shared» c хранилищ которые не доступны физически на других устройствах.

Конвертация дисков qcow2 -> lvm в KVM (Proxmox)

Занимался на днях переносом виртуальных машин с обычного kvm гипервизора на proxmox. На исходном гипервизоре диски виртуальных машин были в формате qcow2. Я решил заодно сконвертировать диски из qcow2 в lvm и написать заметку об этом, чтобы не забыть.

Для тех, кто не знает, в чем разница между разными форматами дисков в гипервизоре KVM, предлагаю почитать об этом в моей статье на тему бэкапа виртуальных машин kvm. В общем случае, сконвертировать диски qcow2 в lvm можно следующим образом. Сначала преобразуем их в raw формат с помощью qemu-img.

Далее raw образ переносим на новый сервер. На нем же к виртуальной машине подключаем новый диск из lvm хранилища такого же размера, как raw образ. Далее в консоли proxmox выполняем конвертацию в lvm с помощью обычного dd.

Все то же самое можно сделать одной командой на новом сервере, перенеся туда диск в формате qcow2.

Последняя команда qemu-img будет работать медленнее, чем dd из предыдущего примера. Каким способом конвертировать — решать вам. Не забудьте изменить путь к lvm разделу. В моем случае он /dev/pve/vm-102-disk-0, у вас имя группы томов может быть другим, не pve.

Я описал общий случай для любого гипервизора KVM. Но конкретно в proxmox это можно сделать проще. Если вам нужно конвертировать qcow2 в lvm на этом же хосте, то достаточно просто через web интерфейс выбрать Move disk и указать в качестве storage хранилище с LVM. Proxmox сам конвертирует диск с помощью того же qemu-img.

Если вы выполняете, как и я, перенос виртуальной машины с одного сервера на другой, то действуйте так:

1. Переносим qcow2 диск со старого гипервизора на новый.
2. На новом создаем виртуальную машину, подключаем к ней диск любого размера на обычном хранилище в виде директории.
3. Запоминаем имя этого диска и удаляем его. Вместо него переносим диск со старого гипервизора и указываем ему такое же имя.
4. Запускаем виртуалку на новом сервере, убеждаемся, что она работает, выключаем.
5. Через web интерфейс proxmox переносим диск на storage с lvm. Proxmox сам выполнит конвертацию.

Я по такой схеме переносил как linux машины, так и windows. Проблем не было. Единственное, надо не забыть зайти через консоль в windows машину и проверить сетевые настройки. Нужно будет заново настроить сеть, иначе по rdp не подключиться. После переноса сетевой адаптер поменяется.

Администрирование и не только

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

Страницы

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

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

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

1. Эмулированные устройства и паравиртуализированные устройства
2. Параметры Виртуальных Машин
3. Миграция
4. Копии и клоны
5. Шаблоны виртуальных машин
6. Generation ID виртуальной машины
7. Импорт виртуальных машин и образов дисков
8. Поддержка Cloud-Init
9. Проброс PCI(e)
10. Hookscripts
11. Гибернация
12. Управление VM с помощью qm
13. Конфигурация
14. Блокировки

1. Миграция

   

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

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

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

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

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

   Для того, чтобы живая миграция работала, есть некоторые требования:

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

   Offline Миграция

   Копии и клоны

   

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

   Простой способ развернуть множество виртуальных машин одного типа-скопировать существующую виртуальную машину. Мы используем термин «Клон» для таких копий и различаем связанные и полные клоны.

   Полный Клон

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

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

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

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

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

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

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

   Чтобы избежать конфликтов ресурсов, все MAC-адреса сетевого интерфейса рандомизируются, и мы генерируем новый UUID для настройки VM BIOS (smbios1).

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

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

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

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

Чтобы создать и добавить vmgenid к уже существующей виртуальной машине, можно передать специальное значение ‘1’, чтобы позволить Proxmox VE автоматически сгенерировать vmgenid или вручную установить UUID 16 , используя его в качестве значения, например: На заметку Первоначальное добавление устройства vmgenid к существующей виртуальной машине может привести к тем же последствиям, что и изменение отката моментального снимка, восстановления резервной копии и т. д., поскольку ВМ может интерпретировать это как изменение поколения. В редких случаях, когда механизм vmgenid не требуется, можно передать ‘0’ для его значения при создании виртуальной машины или удалить задним числом свойство в конфигурации с помощью: Наиболее распространенным вариантом использования vmgenid являются более новые операционные системы Microsoft Windows, которые используют его, чтобы избежать проблем с чувствительными ко времени или реплицируеми службами (например, базы данных, контроллер домена 17 ) при откате моментального снимка, восстановлении резервной копии или всей операции клонирования виртуальной машины.

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

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

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

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

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

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

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

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

Скачать виртуальную машину zip

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

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

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

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

Это позволит создать новую виртуальную машину, используя ядра, память и имя виртуальной машины, считанные из манифеста OVF и импортировать диски в local-lvm хранилище. Вы должны настроить сеть вручную. Виртуальная машина готова к запуску.

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

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

Предположим, вы создали образ диска Debian/Ubuntu с помощью инструмента vmdebootstrap: Теперь можно создать новую целевую виртуальную машину для этого образа. Добавьте образ диска как unused0 к виртуальной машине, используя хранилище pvedir: Наконец, подключите неиспользуемый диск к контроллеру SCSI виртуальной машины: Виртуальная машина готова к запуску.

• Параметры VM
• Оглавление
• Поддержка Cloud-Init