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

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

Proxmox VE Administration Guide

Виртуальные машины 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. Миграция

    Если у вас есть кластер, вы можете перенести свою виртуальную машину на другой хост с помощью

    qm migrate <vmid> <target>
    Обычно для этого существует два механизма
    1. Онлайн-миграция (она же живая миграция)
    2. Offline Миграция

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

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

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

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

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

      Требования

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

    2. Offline Миграция

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

  2. Копии и клоны

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

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

    1. Полный Клон

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    15Официальная спецификация vmgenid https://docs.microsoft.com/en-us/windows/desktop/hyperv_v2/virtual-machine-generation-identifier
    16Онлайн генератор GUID http://guid.one/
    17https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/virtualized-domain-controller-architecture

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

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

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

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

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

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

    1. Пошаговый пример импорта 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 хранилище. Вы должны настроить сеть вручную. 
      qm importovf 999 WinDev1709Eval.ovf local-lvm
      Виртуальная машина готова к запуску.

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

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

      Предположим, вы создали образ диска Debian/Ubuntu с помощью инструмента vmdebootstrap: 
      vmdebootstrap --verbose \
 --size 10GiB --serial-console \
 --grub --no-extlinux \
 --package openssh-server \
 --package avahi-daemon \
 --package qemu-guest-agent \
 --hostname vm600 --enable-dhcp \
 --customize=./copy_pub_ssh.sh \
 --sparse --image vm600.raw
      Теперь можно создать новую целевую виртуальную машину для этого образа. 
      qm create 600 --net0 virtio,bridge=vmbr0 --name vm600 --serial0 socket \
  --bootdisk scsi0 --scsihw virtio-scsi-pci --ostype l26
      Добавьте образ диска как unused0 к виртуальной машине, используя хранилище pvedir: 
      qm importdisk 600 vm600.raw pvedir
      Наконец, подключите неиспользуемый диск к контроллеру SCSI виртуальной машины: 
      qm set 600 --scsi0 pvedir:600/vm-600-disk-1.raw
      Виртуальная машина готова к запуску.

Автор: на
Ярлыки: , ,

2 комментария:

  1. Павел М.11 марта 2020 г. в 06:57

    Александр, спасибо за упорство, жду следующей части - наконец-то будет давно ожидаемая часть про PCI(e) Passthrough!!!!

    ОтветитьУдалить

Подписаться на: Комментарии к сообщению (Atom)