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

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

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. Блокировки
Qemu (сокращенно от Quick Emulator) - это гипервизор с открытым исходным кодом, эмулирующий физический компьютер. С точки зрения хост-системы, где работает Qemu, Qemu - это пользовательская программа, которая имеет доступ к ряду локальных ресурсов, таких как разделы, файлы, сетевые карты, которые затем передаются на эмулируемый компьютер, который видит их, как если бы они были реальными устройствами.

Гостевая операционная система, работающая на эмулируемом компьютере, обращается к этим устройствам и работает так, как она работает на реальном оборудовании. Например, вы можете передать образ iso в качестве параметра Qemu, и операционная система, работающая на эмулируемом компьютере, увидит реальный CDROM, вставленный в привод компакт-дисков.

Qemu может эмулировать большое разнообразие аппаратных средств от ARM до Sparc, но Proxmox VE занимается только 32-и 64-битной эмуляцией клонов PC, поскольку она представляет собой подавляющее большинство серверного оборудования. Эмуляция клонов PC также является одной из самых быстрых из-за наличия процессорных расширений, которые значительно ускоряют Qemu, когда эмулируемая архитектура совпадает с архитектурой хоста.
На заметку
Иногда вы можете столкнуться с термином KVM (Kernel-based Virtual Machine). Это означает, что Qemu работает с поддержкой расширений процессора виртуализации, через модуль ядра Linux kvm. В контексте Proxmox VE термины Qemu и KVM могут использоваться взаимозаменяемо, так как Qemu в Proxmox VE всегда будет пытаться загрузить модуль kvm.
Qemu внутри Proxmox VE работает как корневой процесс, так как это необходимо для доступа к блочным и PCI устройствам

  1. Эмулированные устройства и паравиртуализированные устройства

    Аппаратное обеспечение PC, эмулируемое Qemu, включает в себя материнскую плату, сетевые контроллеры, контроллеры SCSI, IDE и SATA, последовательные порты (полный список можно увидеть на man странице KVM(1)), все они эмулируются программно. Все эти устройства являются точным программным эквивалентом существующих аппаратных устройств, и если операционная система, работающая в гостевой системе, имеет соответствующие драйверы, она будет использовать устройства, как если бы она работала на реальном оборудовании. Это позволяет Qemu запускать немодифицированные операционные системы.

    Это, однако, влияет на производительность, так как запуск в программном обеспечении того, что должно было выполняться в аппаратном обеспечении, требует дополнительной нагрузки на центральный процессор. Чтобы сгладить это, Qemu может представить гостевой операционной системе паравиртуализированные устройства, где гостевая ОС распознает, что она работает внутри Qemu и взаимодействует с гипервизором.

    Qemu опирается на стандарт виртуализации virtio и, таким образом, может представлять паравиртуализированные устройства virtio, которые включают в себя паравиртуализированный универсальный дисковый контроллер, паравиртуализированную сетевую карту, паравиртуализированный последовательный порт, паравиртуализированный SCSI-контроллер и т. д …

    Настоятельно рекомендуется использовать устройства virtio при любой возможности, так как они обеспечивают значительное улучшение производительности. Использование virtio generic disk controller по сравнению с эмулируемым IDE-контроллером удвоит пропускную способность последовательной записи, как это было измерено с помощью bonnie++(8). Использование сетевого интерфейса virtio может обеспечить до трех раз большую пропускную способность эмулируемой сетевой карты Intel E1000, измеренную с помощью iperf(1). 1

    1 Смотри этот бэнчмарк на KVM wiki

  2. Параметры Виртуальных Машин

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

    1. Общие параметры

      Общие настройки виртуальной машины включают:
      • Узел: физический сервер, на котором будет работать виртуальная машина.
      • VM ID: уникальный номер в этой установке Proxmox VE, используемый для идентификации виртуальной машины.
      • Имя: текстовая строка свободной формы, которую можно использовать для описания виртуальной машины.
      • Пул ресурсов: логическая группа виртуальных машин

    2. Настройки ОС

      При создании виртуальной машины (VM) выбор соответствующей операционной системы (OS) позволяет Proxmox VE оптимизировать некоторые низкоуровневые параметры. Например, ОС Windows ожидает, что часы BIOS будут использовать местное время, в то время как ОС на базе Unix ожидает, что часы BIOS будут иметь время UTC.

    3. Параметры системы

      При создании виртуальной машины можно изменить некоторые основные компоненты системы новой виртуальной машины. Вы можете указать, какой тип дисплея вы хотите использовать. Кроме того, может быть изменен контроллер SCSI. Если вы планируете установить гостевой агент QEMU, или если выбранный образ ISO уже поставляется и устанавливается автоматически, вы можете поставить галочку в поле агент Qemu, что позволит Proxmox VE использовать его функции для отображения дополнительной информации и выполнения некоторых действий (например, завершение работы или создание моментальных снимков) более оптимально.

      Proxmox VE позволяет загружать виртуальные машины с различными типами прошивок и машин, а именно SeaBIOS и OVMF. В большинстве случаев вы хотите переключиться с seabbios по умолчанию на OVMF только в том случае, если вы планируете использовать проброс устройств PCIe. Тип машины VMs определяет аппаратную компоновку виртуальной материнской платы виртуальной машины. Вы можете выбрать между стандартным Intel 440FX или чипсетом Q35, который также предоставляет виртуальную шину PCIe, и, таким образом, может быть предпочтительным, если вы планируете использовать проброс аппаратного обеспечения PCIe.

    4. Жесткий диск

      Qemu может эмулировать несколько контроллеров дисков:
      • IDE контроллер, имеет конструкцию, которая восходит к 1984 PC/AT disk controller. Несмотря на то, что этот контроллер был заменен современными разработками, любая ОС поддерживает его, что делает его отличным выбором, если вы хотите запустить ОС, выпущенную до 2003 года. На этом контроллере можно подключить до 4 устройств.
      • Контроллер SATA (Serial ATA), датируемый 2003 годом, имеет более современную конструкцию, позволяющую увеличить пропускную способность и подключить большее количество устройств. На этом контроллере можно подключить до 6 устройств.
      • Контроллер SCSI, разработанный в 1985 году, обычно используется на серверном оборудовании и может подключать до 14 устройств хранения данных. Proxmox VE эмулирует по умолчанию контроллер LSI 53C895A.
        Контроллер SCSI типа VirtIO SCSI является рекомендуемой настройкой, если вас интересует производительность и автоматически выбирается для вновь созданных виртуальных машин Linux начиная с Proxmox VE 4.3. Дистрибутивы Linux поддерживают этот контроллер с 2012 года, а FreeBSD-с 2014 года. Для операционных систем Windows необходимо предоставить дополнительный iso, содержащий его драйверы, во время установки. Если вы нацелены на максимальную производительность, вы можете выбрать SCSI контроллер типа VirtIO SCSI single, который позволит вам выбрать опцию потока ввода-вывода. При выборе VirtIO SCSI single Qemu создаст новый контроллер для каждого диска, вместо добавления всех дисков к одному контроллеру.
      • Контроллер VirtIO Block, часто просто называемый VirtIO или virtio-blk, является более старым типом паравиртуализированного контроллера. Он был заменен более функциональным контроллером VirtIO SCSI.
      К каждому контроллеру вы подключаете несколько эмулированных жестких дисков, которые представлены файлом или блочным устройством, находящимся в настроенном хранилище. Выбор типа хранилища будет определять формат образа жесткого диска. Хранилища, которые предоставляют блочные устройства (LVM, ZFS, Ceph) потребуют выбора диска в формате RAW, а файловые хранилища (ext4, NFS и CIFS, GlusterFS) позволят вам выбрать либо формат RAW либо формат QEMU.
      • Формат образа QEMU-это формат копирования при записи, который позволяет создавать моментальные снимки и тонкую настройку образа диска.
      • Образ диска RAW - это битовый образ жесткого диска, подобный тому, что вы получите при выполнении команды dd на блочном устройстве в Linux. Этот формат не поддерживает тонкую настройку или моментальные снимки сам по себе, требуя для этих задач сотрудничества со стороны слоя хранения. Однако он может быть до 10% быстрее, чем формат образа QEMU. 2
      • Формат образа VMware имеет смысл только в том случае, если вы собираетесь импортировать/экспортировать образ диска в другие гипервизоры.
      Установка режима кэширования жесткого диска повлияет на то, как хост-система будет уведомлять гостевые системы о завершении записи блоков. No cache по умолчанию означает, что гостевая система будет уведомлена о завершении записи, когда каждый блок достигнет очереди записи физического хранилища, игнорируя игнорируя кэш хоста. Это обеспечивает хороший баланс между безопасностью и скоростью.

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

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

      Если ваше хранилище поддерживает тонкую настройку (см. раздел хранилища в руководстве Proxmox VE), вы можете активировать опцию Discard на диске. С установленным Discard и поддержкой гостевой ОС TRIM3, когда файловая система виртуальной машины помечает блоки как неиспользуемые после удаления файлов, контроллер передает эту информацию в хранилище, которое затем сжимает образ диска соответствующим образом. Чтобы гость мог выдавать команды TRIM, необходимо включить опцию Discard на диске. Некоторые гостевые операционные системы могут также требовать установки флага эмуляции SSD. Обратите внимание, что Discard на дисках VirtIO Block поддерживается только на гостях, использующих ядро Linux версии 5.0 или выше.

      Если вы хотите, чтобы диск был представлен гостю как твердотельный диск, а не вращающийся жесткий диск, вы можете установить опцию эмуляции SSD на этом диске. Нет никакого требования, чтобы базовое хранилище фактически поддерживалось твердотельными накопителями; эта функция может использоваться с физическими носителями любого типа. Обратите внимание, что эмуляция SSD не поддерживается на дисках VirtIO Block.

      Опция IO Thread может использоваться только при использовании диска с контроллером VirtIO или с контроллером SCSI, когда эмулируемый тип контроллера - VirtIO SCSI single. Если этот параметр включен, Qemu создает один поток ввода-вывода для каждого контроллера хранения, а не один поток для всех операций ввода-вывода, что позволяет повысить производительность при использовании нескольких дисков, а каждый диск имеет свой собственный контроллер.

      2 Для подробностей смотри этот бэнчмарк
      3 TRIM, UNMAP, и discard https://en.wikipedia.org/wiki/Trim_(computing)

    5. CPU

      Сокет процессора-это физический слот на материнской плате ПК, куда можно подключить процессор. Этот процессор может содержать одно или несколько ядер, которые являются независимыми процессорами. Есть ли у вас один сокет процессора с 4 ядрами или два сокета процессора с двумя ядрами, в основном не имеет значения с точки зрения производительности. Однако некоторые лицензии на программное обеспечение зависят от количества сокетов на машине, в этом случае имеет смысл установить количество сокетов на то, что позволяет лицензия.

      Увеличение числа виртуальных процессоров (ядер и сокетов) обычно обеспечивает повышение производительности, хотя это сильно зависит от использования виртуальной машины. Многопоточные приложения, конечно, выиграют от большого количества виртуальных процессоров, так как для каждого добавляемого виртуального процессора Qemu создаст новый поток выполнения на хост-системе. Если вы не уверены в рабочей нагрузке вашей виртуальной машины, обычно безопасно установить общее число ядер равным 2.
      Примечание
      Совершенно безопасно, если общее число ядер всех ваших виртуальных машин больше, чем число ядер на сервере (например, 4 виртуальных машины с 4 ядрами у каждой на машине только с 8 ядрами). В этом случае хост-система будет балансировать потоки выполнения Qemu между ядрами вашего сервера, как если бы вы запускали стандартное многопоточное приложение. Однако Proxmox VE не позволит запускать виртуальные машины с большим количеством виртуальных процессорных ядер, чем физически доступно, так как это приведет только к снижению производительности из-за стоимости контекстных переключателей.
      Ограничение ресурсов

      Помимо количества виртуальных ядер, можно настроить, какую часть от процессорного времени узла может получить виртуальная машина, а также в зависимости от других виртуальных машин. С помощью параметра cpulimit (“Host CPU Time”) можно ограничить количество процессорного времени, которое вся виртуальная машина может использовать на хосте. Это значение с плавающей запятой, представляющее процессорное время в процентах, поэтому 1.0 равно 100%, 2.5-250% и так далее. Если один процесс будет полностью использовать одно ядро, он будет использовать 100% процессорного времени. Если виртуальная машина с четырьмя ядрами использует все свои ядра полностью, теоретически она будет использовать 400%. На самом деле использование может быть даже немного выше, так как Qemu может иметь дополнительные потоки для периферийных устройств VM помимо основных потоков vCPU. Этот параметр может быть полезен, если виртуальная машина должна иметь несколько vcpu, так как она выполняет несколько процессов параллельно, но виртуальная машина в целом не должна быть в состоянии выполнять все vcpu на 100% одновременно. Используя конкретный пример: Предположим, у нас есть виртуальная машина, которая выиграет от наличия 8 vcpu, но ни в коем случае все эти 8 ядер не должны работать при полной загрузке - так как это сделает сервер настолько перегруженным, что другие виртуальные машины и CTs получат меньше процессора. Итак, мы установили предел cpulimit до 4.0 (=400%). Если бы все ядра выполняли одну и ту же тяжелую работу, они бы все получали 50% реального времени процессора ядра хоста. Но, если бы только 4 делали работу, они все еще могли бы получить почти 100% реального ядра каждый.
      На заметку
      Виртуальные машины могут, в зависимости от их конфигурации, использовать дополнительные потоки, например, для сетевых операций или операций ввода-вывода, но также и для динамической миграции. Таким образом, виртуальная машина может использовать больше процессорного времени, чем только ее виртуальные процессоры. Чтобы гарантировать, что виртуальная машина никогда не использует больше времени процессора, чем назначенные виртуальные процессоры, установите параметр cpulimit в то же значение, что и общее количество ядер.
      Второй параметр ограничения ресурсов процессора, cpuunits (в настоящее время часто называемый CPU shares или CPU weight), определяет, сколько процессорного времени получает виртуальная машина в отношении других работающих виртуальных машин. Это относительный вес, который по умолчанию равен 1024, если вы увеличите его для виртуальной машины, она будет иметь приоритет для планировщика по сравнению с другими виртуальными машинами с меньшим весом. Например, если VM 100 установила значение по умолчанию 1024, а VM 200 была изменена на 2048, то последняя VM 200 получит вдвое большую пропускную способность процессора, чем первая VM 100.

      Дополнительные сведения см. В разделе man systemd.resource-control, здесь CPUQuota соответствует cpulimit, а CPUShares соответствует нашей настройке cpuunits, посетите его раздел Notes для ссылок и деталей реализации.

      Тип процессора

      Qemu может эмулировать ряд различных типов процессоров от 486 до новейших процессоров Xeon. Каждое новое поколение процессоров добавляет новые функции, такие как аппаратный 3D-рендеринг, генерация случайных чисел, защита памяти и т. д. Обычно вы должны выбрать для своей виртуальной машины Тип процессора, который близко соответствует ЦП хост-системы, поскольку это означает, что функции ЦП хоста (также называемые флагами ЦП ) будут доступны в вашей виртуальной машине. Если требуется точное совпадение, можно установить тип процессора host, и в этом случае виртуальная машина будет иметь точно такие же флаги процессора, как и ваша хост-система.

      Но у этого есть и обратная сторона. Если вы хотите выполнить динамическую миграцию виртуальных машин между различными хостами, ваша виртуальная машина может оказаться на новой системе с другим типом процессора. Если флаги процессора, переданные гостю, отсутствуют, процесс qemu остановится. Для исправления этого Qemu имеет также свой собственный процессор типа kvm64, который Proxmox VE использует по умолчанию. kvm64-это Pentium 4 подобный тип процессора, который имеет уменьшенный набор флагов процессора, но гарантированно работает везде.

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

      Флаги процессора, связанные с Meltdown/Spectre

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

      Есть два требования, которые должны быть выполнены, чтобы использовать эти флаги процессора:
      • Host процессор(Ы) должен поддерживать эту функцию и распространять ее на виртуальный процессор(Ы) гостя.)
      • Гостевая операционная система должна быть обновлена до версии, которая смягчает атаки и может использовать функцию процессора.
      В противном случае вам необходимо установить нужный флаг процессора для виртуального процессора, либо путем редактирования параметров процессора в WebUI, либо путем установки свойства flags параметра cpu в файле конфигурации виртуальной машины.

      Для исправлений Spectre v1,v2,v4 ваш поставщик процессора или системы также должен предоставить так называемое “обновление микрокода”5 для вашего процессора.

      Чтобы проверить, уязвим ли хост Proxmox VE, выполните следующую команду от имени root: 
      for f in /sys/devices/system/cpu/vulnerabilities/*; do echo "${f##*/} -" $(cat "$f"); done
      Также доступен скрипт сообщества для обнаружения, является ли хост все еще уязвимым.6

      4Meltdown Attack https://meltdownattack.com/
      5 Вы можете использовать 'intel-microcode'/'amd-microcode' из Debian бесплатно, если ваш поставщик не предоставляет такого обновления. Обратите внимание, что не все затронутые процессоры могут быть обновлены для поддержки spec-ctrl.
      6spectre-meltdown-checker https://meltdown.ovh/

      Процессоры Intel

      • pcid

        Это снижает влияние на производительность программы Meltdown (CVE-2017-5754), называемой Kernel Page-Table Isolation (KPTI), которая эффективно скрывает память ядра от пространства пользователя. Без PCID KPTI является довольно дорогостоящим механизмом7. Чтобы проверить, уязвим ли хост Proxmox VE, выполните следующую команду от имени root: 
        # grep ' pcid ' /proc/cpuinfo
        Если вывод не пустой, процессор вашего хоста имеет поддержку pcid.

      • spec-ctrl

        Требуется, включить чтобы исправить Spectre v1 (CVE-2017-5753) и Spectre v2 (CVE-2017-5715), в случаях, когда retpoline не достаточно. Входит по умолчанию в модели процессоров Intel с суффиксом-IBRS. Должен быть явно включен для моделей процессоров Intel без суффикса-IBRS. Требуется обновленный микрокод центрального процессора (intel-microcode >= 20180425).
      • ssbd

        Необходим для того, чтобы исправить Spectre В4 (ПНЭ-2018-3639). Не входит по умолчанию ни в одну модель процессора Intel. Должен быть явно включен для всех моделей процессоров Intel. Требуется обновленный микрокод центрального процессора (intel-microcode >= 20180425).
      7 PCID теперь является критической функцией производительности/безопасности на x86 https://groups.google.com/forum/m/#!topic/mechanical-sympathy/L9mHTbeQLNU

      Процессоры AMD

      • ibpb

        Требуется, включить чтобы исправить Spectre v1 (CVE-2017-5753) и Spectre v2 (CVE-2017-5715), в случаях, когда retpoline не достаточно. Входит по умолчанию в модели процессоров AMD с суффиксом-IBPB. Должен быть явно включен для моделей процессоров AMD без суффикса-IBPB. Требуется, чтобы микрокод центрального процессора поддерживал эту функцию, прежде чем его можно будет использовать для гостевых процессоров.
      • virt-ssbd

        Необходим для того, чтобы исправить Spectre В4 (ПНЭ-2018-3639). Не входит по умолчанию ни в одну модель процессора AMD. Должен быть явно включен для всех моделей процессоров AMD. Должен быть предоставлен гостям, даже если amd-ssbd также предоставляется, для максимальной совместимости гостя. Обратите внимание, что это должно быть явно включено при использовании модели ЦП "хост", поскольку это виртуальная функция, которая не существует в физических процессорах.
      • amd-ssbd

        Необходим для того, чтобы исправить Spectre В4 (ПНЭ-2018-3639). Не входит по умолчанию ни в одну модель процессора AMD. Должен быть явно включен для всех моделей процессоров AMD. Это обеспечивает более высокую производительность, чем virt-ssbd, поэтому хост, поддерживающий его, должен всегда предоставлять этот флаг гостям, если это возможно. virt-ssbd также должен быть открыт для максимальной гостевой совместимости, так как некоторые ядра знают только о virt-ssbd.
      • amd-no-ssb

        Рекомендуется указать, что хост не уязвим для Spectre V4 (CVE-2018-3639). Не входит по умолчанию ни в одну модель процессора AMD. Будущие аппаратные поколения CPU не будут уязвимы для CVE-2018-3639, и поэтому гостю следует сказать, чтобы он не включал свои средства защиты, выставляя amd-no-ssb. Это взаимоисключает Virtus-ssbd и amd-ssbd.

      NUMA

      Вы также можете дополнительно эмулировать архитектуру NUMA8 в ваших виртуальных машинах. Основы архитектуры NUMA означают, что вместо глобального пула памяти, доступного для всех ядер, Память распределяется по локальным банкам, расположенным рядом с каждым сокетом. Это может привести к повышению скорости, поскольку шина памяти больше не является узким местом. Если ваша система имеет архитектуру NUMA9, мы рекомендуем активировать эту опцию, так как это позволит правильно распределить ресурсы виртуальной машины на хост-системе. Этот параметр также необходим для горячего подключения ядер или оперативной памяти в виртуальной машине.

      Если используется опция NUMA, рекомендуется установить число сокетов равным числу сокетов хост-системы.

      vCPU hot-plug

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

      В Proxmox VE максимальное количество подключаемых процессоров всегда равно количество ядер * количество сокетов. Чтобы запустить виртуальную машину с меньшим, чем это общее количество ядер процессоров, можно использовать параметр vpus, он указывает, сколько vcpu должно быть подключено при запуске виртуальной машины. В настоящее время эта функция поддерживается только на Linux, требуется ядро ​​новее, чем 3.10, рекомендуется ядро ​​новее, чем 4.7.

      Вы можете использовать правило udev следующим образом, чтобы автоматически устанавливать новые процессоры как гостевые: 
      SUBSYSTEM=="cpu", ACTION=="add", TEST=="online", ATTR{online}=="0", ATTR{online}="1"
      Сохраните это в файле /etc/udev/rules.d/ как файл, заканчивающийся на  .rules.

      Примечание Горячее удаление CPU зависит от компьютера и требует поддержки гостевой ОС. Команда удаления не гарантирует, что удаление процессора действительно произойдет, обычно это запрос, направляется гостю с использованием механизма, зависимого от цели например, ACPI на x86/amd64.

      8https://en.wikipedia.org/wiki/Non-uniform_memory_access
      9если команда numactl --hardware | grep available возвращает более одного узла, тогда ваша хост-система поддерживает архитектуру NUMA

    6. Память

      Для каждой виртуальной машины вы можете установить память фиксированного размера или попросить Proxmox VE динамически выделять память в зависимости от текущего использования оперативной памяти хоста.

      Фиксированное Выделение Памяти
      При установке памяти и минимальной памяти на одинаковый объем Proxmox VE просто выделит то, что вы укажете для вашей виртуальной машины.

      Даже при использовании фиксированного объема памяти, устройство ballooning добавляется к виртуальной машине, потому что оно предоставляет полезную информацию, например, сколько памяти действительно использует гость. В общем, вы должны оставить ballooning включенным, но если вы хотите отключить его (например, для отладки), просто снимите флажок ballooning устройства или установите 
      balloon: 0
      в конфигурации.

      Автоматическое Выделение Памяти

      При установке минимальной памяти ниже, чем память, Proxmox VE будет следить за тем, чтобы указанный вами минимальный объем всегда был доступен виртуальной машине, и если использование оперативной памяти на хосте ниже 80%, будет динамически добавлять память гостю до указанного максимального объема памяти.

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

      Когда несколько виртуальных машин используют функцию автоматического распределения, можно установить коэффициент общих ресурсов, который указывает относительный объем свободной памяти хоста, которую должна занять каждая виртуальная машина. Предположим, например, что у вас есть четыре виртуальные машины, на трех из которых работает HTTP-сервер, а на последней сервер баз данных. Чтобы кэшировать больше блоков базы данных в оперативной памяти сервера баз данных, необходимо установить приоритет виртуальной машины базы данных при наличии свободной оперативной памяти. Для этого вы назначаете свойство Shares 3000 виртуальной машине базы данных, а другим виртуальным машинам присваивается значение по умолчанию Shares 1000. Хост-сервер имеет 32 ГБ оперативной памяти и в настоящее время использует 16 ГБ, оставляя 32 * 80/100 - 16 = 9 ГБ оперативной памяти, выделяемой для виртуальных машин. VM баз данных получит 9 * 3000/(3000+1000+1000+1000) = 4.5 Гб дополнительной оперативной памяти и каждый HTTP-сервер получит 1,5 ГБ.

      Все дистрибутивы Linux, выпущенные после 2010 года, имеют драйвер ядра balloon. Для операционных систем Windows драйвер balloon должен быть установлен вручную и может вызвать замедление гостя, поэтому мы не рекомендуем использовать его на критических системах.

      При выделении оперативной памяти для ваших виртуальных машин, хорошее эмпирическое правило-всегда оставлять 1 ГБ оперативной памяти доступной для хоста.

      10Хорошее объяснение внутренней работы balloon драйвера можно найти здесь: https://rwmj.wordpress.com/2010/07/17/-virtio-balloon/

    7. Сетевое устройство

      Каждая виртуальная машина может иметь много контроллеров сетевого интерфейса (NIC) четырех различных типов:
      • По умолчанию используется Intel E1000, который эмулирует гигабитную сетевую карту Intel.
      • Virtio - паравиртуализированный NIC следует использовать , если вы нацелены на максимальную производительность. Как и на всех устройствах VirtIO, на гостевой ОС должен быть установлен соответствующий драйвер. Как и на всех устройствах VirtIO, в гостевой ОС должен быть установлен соответствующий драйвер.
      • Realtek 8139 эмулирует старую сетевую карту со скоростью 100 Мбит/с и должен использоваться только при эмуляции старых операционных систем (выпущенных до 2002 года)
      • vmxnet3-это еще одно паравиртуализированное устройство, которое следует использовать только при импорте виртуальной машины из другого гипервизора.
      Proxmox VE генерирует для каждой сетевой карты случайный MAC-адрес, чтобы ваша виртуальная машина была адресуемой в сетях Ethernet.

      Сетевой адаптер, добавленный в виртуальную машину, может следовать одной из двух различных моделей:
      • в Bridged режиме по умолчанию каждый виртуальный сетевой адаптер поддерживается на хосте устройством tap (программным устройством loopback, имитирующим сетевой адаптер Ethernet). Это устройство tap добавляется к мосту, по умолчанию vmbr0 в Proxmox VE. В этом режиме виртуальные машины имеют прямой доступ к локальной сети Ethernet, на которой расположен хост.
      • в альтернативном режиме NAT каждый виртуальный сетевой адаптер будет взаимодействовать только с пользовательским сетевым стеком Qemu, где встроенный маршрутизатор и DHCP-сервер могут обеспечить доступ к сети. Этот встроенный DHCP будет обслуживать адреса в частном диапазоне 10.0.2.0/24. Режим NAT намного медленнее, чем мостовой режим, и должен использоваться только для тестирования. Этот режим доступен только через CLI или API, но не через WebUI.
      Вы также можете пропустить добавление сетевого устройства при создании виртуальной машины, выбрав нет сетевого устройства.

      Multiqueue

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

      При использовании драйвера VirtIO с Proxmox VE каждая сетевая очередь NIC передается ядру хоста, где очередь обрабатывается потоком ядра, порожденным драйвером vhost.  Если эта опция активирована, можно передать несколько сетевых очередей ядру хоста для каждой сетевой карты.

      При использовании Multiqueue рекомендуется установить для него значение, равное общему числу ядер вашего гостя. Кроме того, необходимо задать в виртуальной машине количество многоцелевых каналов на каждой виртуальной машине с помощью команды ethtool: 
      ethtool -L ens1 combined X


      где X-номер числа vCPU виртуальной машины.

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

    8. Дисплей

      QEMU может виртуализировать несколько типов VGA-оборудования. Вот некоторые примеры:
      • По умолчанию std эмулирует карту с расширениями Bochs VBE.
      • cirrus, использовался когда-то по умолчанию, он эмулирует очень старый аппаратный модуль со всеми его проблемами. Этот тип дисплея следует использовать только в случае реальной необходимости11, например, при использовании Windows XP или более ранних версий
      • vmware - это VMWare SVGA-II совместимый адаптер.
      • qxl - это паравиртуализированная видеокарта QXL Выбор этого параметра также включает SPICE (протокол удаленного просмотра) для виртуальной машины.

        Вы можете изменить объем памяти, предоставленной виртуальному графическому процессору, установив опцию memory. Это позволит включить более высокое разрешение внутри виртуальной машины, особенно с SPICE/QXL.


      Поскольку память резервируется устройством дисплея, выбор режима Multi-Monitor для SPICE (например, qxl2 для двух мониторов) имеет некоторые последствия:
      • Windows требуется устройство для каждого монитора, поэтому, если ваш ostype-это какая-то версия Windows, Proxmox VE предоставляет виртуальной машине дополнительное устройство для каждого монитора. Каждое устройство получает заданный объем памяти.
      • Виртуальные машины Linux, всегда могут включить больше виртуальных мониторов, но выбор режима Multi-Monitor умножает память, предоставленную устройству с количеством мониторов.

        Выбор serialX в качестве типа дисплея отключает выход VGA и перенаправляет веб-консоль на выбранный последовательный порт. Настроенный параметр памяти дисплея в этом случае будет проигнорирован.

      11qemu: использование цирруса не рекомендуется https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/

    9. Проброс USB

      Есть два различных типоа проброса устройств USB:
      • Проброс Host USB
      • Проброс SPICE USB

      Проброс Host USB работает, предоставляя виртуальной машине USB-устройство хоста. Это можно сделать либо используя vendor/product-id пробрасываемого устройства, либо используя номер порта хост машины.

      vendor/product-id выглядит следующим образом: 0123:abcd, где 0123-идентификатор поставщика, а abcd-идентификатор продукта, то есть два одинаковых usb-устройства имеют один и тот же идентификатор.

      Шина/порт выглядит следующим образом: 1-2.3.4, где 1 - шина, а 2.3.4-путь к порту. Это означает физические порты вашего хоста (в зависимости от внутреннего порядка контроллеров usb). Если устройство присутствует в конфигурации виртуальной машины при запуске виртуальной машины, но не подключен к узлу(хосту), виртуальная машина сможет загрузиться без проблем. Как только устройство/порт становится доступным на хосте, оно будет проброшено.
      Внимание
      Использование этого вида проброса USB означает, что вы не сможете переместить ВМ онлайн на другой хост, так как оборудование доступно только на хосте, где виртуальная машина в настоящее время находится.
      Второй тип проброса - проброс SPICE USB. Это полезно, если вы используете клиент SPICE, который его поддерживает. Если вы добавляете USB-порт SPICE в свою виртуальную машину, вы можете вставить USB-устройство из того места, где находится ваш клиент SPICE, непосредственно в виртуальную машину (например, устройство ввода или аппаратный ключ).

    10. BIOS и UEFI

      Чтобы правильно эмулировать компьютер, QEMU должен использовать firmware(прошивку). Который на обычных PC (известен как BIOS или (U)EFI), выполняется как один из первых шагов при загрузке виртуальной машины. Он отвечает за выполнение базовой аппаратной инициализации и за обеспечение интерфейса к микропрограммному обеспечению и аппаратному обеспечению для операционной системы. По умолчанию QEMU использует для этого SeaBIOS, который является реализацией BIOS x86 с открытым исходным кодом. SeaBIOS-хороший выбор для большинства стандартных установок.

      Есть, однако, некоторые сценарии, в которых BIOS не является хорошей прошивкой для загрузки, например, если вы хотите сделать проброс VGA. [12] в таких случаях лучше использовать OVMF, который является реализацией UEFI с открытым исходным кодом. [13]

      Если вы хотите использовать OVMF, необходимо учитывать следующие факторы:

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

      Такой диск можно создать с помощью следующей команды: 
      qm set <vmid> -efidisk0 <storage>:1,format=<format>
      Где <storage> - это хранилище, в котором вы хотите иметь диск, а <format> - это формат, который поддерживает хранилище. Кроме того, вы можете создать такой диск через веб-интерфейс с помощью команды Add → EFI Disk в разделе аппаратного обеспечения виртуальной машины.

      При использовании OVMF с виртуальным дисплеем (без VGA passthrough), вам нужно установить разрешение клиента в меню OVMF(в которое вы можете попасть нажав кнопку ESC во время загрузки), или вы должны выбрать SPICE в качестве типа дисплея.

      12в блоге Алекса Уильямсона есть очень хорошая запись об этом: http://vfio.blogspot.co.at/2014/08/primary-graphics-assignment-без-vga.html 13См. Проект OVMF http://www.tianocore.org/ovmf/

    11. Inter-VM разделяемая память

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

      Чтобы добавить такое устройство, вы можете использовать qm: 
      qm set <vmid> -ivshmem size=32,name=foo
      Где size в Мб. файл будет расположен под именем /dev/shm/pve-shm - $name (по умолчанию используется vmid).
      На заметку
      В настоящее время устройство будет удалено, как только любая виртуальная машина, использующая его, будет выключена или остановлена. Открытые соединения будут по-прежнему сохраняться, но новые соединения с тем же самым устройством больше не могут быть установлены.
      Примером использования такого устройства является проект Looking Glass14, который обеспечивает высокопроизводительный зеркальный дисплей с малой задержкой между хостом и гостем.

      14Looking Glass: https://looking-glass.hostfission.com/

    12. Аудио-устройство

      Примечание
      Раздел отсутствует а исходном руководстве, добавлен из Proxmox WiKi
      Чтобы добавить аудио-устройство, выполните следующую команду: 
      qm set <vmid> -audio0 device=<device>
      Поддерживаются следующие аудио-устройства:
      • ich9-intel-hda: Intel HD Audio Controller, эмулирует ICH9
      • intel-hda: Intel HD Audio Controller, эмулирует ICH6
      • AC97: Audio Codec '97, полезен для более старых операционных систем, таких как Windows XP
      На заметку
      Аудио-устройство работает только в сочетании с SPICE. Удаленные протоколы, такие как Microsoft RDP, имеют возможность воспроизводить звук. Для использования физического аудиоустройства хоста используйте устройство passthrough (см. PCI Passthrough и USB Passthrough).

    13. Автоматический запуск и выключение виртуальных машин

      После создания виртуальных машин вы, вероятно, захотите, чтобы они запускались автоматически при загрузке хост-системы. Для этого необходимо выбрать опцию Start at boot на вкладке Options виртуальной машины в веб-интерфейсе или задать ее с помощью следующей команды: 
      qm set <vmid> -onboot 1
      Порядок запуска и выключения
      В некоторых случаях вы хотите иметь возможность точно настроить порядок загрузки ваших виртуальных машин, например, если одна из ваших виртуальных машин предоставляет брандмауэр или DHCP другим гостевым системам. Для этого можно использовать следующие параметры:
      • Порядок запуска/выключения: определяет приоритет порядка запуска. Например, установите значение 1, Если вы хотите, чтобы виртуальная машина была запущена первой. (Мы используем обратный порядок запуска для завершения работы, поэтому машина с порядком запуска 1 будет закрыта последней). Если несколько виртуальных машин имеют одинаковый порядок, определенный на узле, они будут дополнительно упорядочены по VMID в порядке возрастания.
      • Задержка запуска: Определяет интервал между запуском этой виртуальной машины и последующими запусками виртуальных машин . Например, установите его на 240, если вы хотите подождать 240 секунд перед запуском других виртуальных машин.
      • Задержка выключения: Определяет длительность в секундах, в течение которой Proxmox VE должен ожидать отключения виртуальной машины после выполнения команды shutdown. По умолчанию это значение равно 180,что означает, что Proxmox VE выдаст запрос на завершение работы и будет ждать 180 секунд, пока машина не отключится. Если машина все еще находится в сети после тайм-аута, она будет остановлена принудительно.
      На заметку
      Виртуальные машины, управляемые стеком HA, в настоящее время не следуют параметрам start on boot и boot order. Эти виртуальные машины будут пропущены алгоритмом запуска и завершения работы, поскольку сам диспетчер HA гарантирует, что виртуальные машины будут запущены и остановлены.
      Обратите внимание, что машины без параметра Start/Shutdown order всегда будут запускаться после тех, где этот параметр установлен. Кроме того, этот параметр может применяться только между виртуальными машинами, работающими на одном хосте, а не на уровне кластера.

    14. Дополнения SPICE

      Примечание
      Раздел отсутствует а исходном руководстве, добавлен из Proxmox WiKi
      Дополнения SPICE-это дополнительные функции, которые могут улучшить возможности удаленного просмотра.

      Чтобы включить их через графический интерфейс, перейдите на панель параметров виртуальной машины. Выполните следующую команду, чтобы включить их через CLI: 
      qm set  -spice_enhancements foldersharing=1,videostreaming=all
      На заметку
      Для использования этих функций Дисплей виртуальной машины должен быть настроен как SPICE (qxl).
      Общий Доступ К Папкам

      Поделитесь локальной папкой с гостем. Демон spice-webdavd должен быть установлен в гостевой системе. Он делает общую папку доступной через локальный сервер WebDAV, расположенный по адресу http://localhost:9843.

      Для гостей Windows установщик демона Spice WebDAV можно загрузить с официального сайта SPICE.

      В большинстве дистрибутивов Linux есть пакет под названием  spice-webdavd, которые могут быть установлены.

      Чтобы открыть общий доступ к папке в Virtu-Viewer (Remote Viewer), перейдите в меню Файл -> Настройки. Выберите папку для общего доступа и установите флажок.

      На заметку
      Общий доступ к папкам в настоящее время работает только в Linux-версии Virt-Viewer.
      Внимание
      Экспериментально! В настоящее время эта функция не работает стабильно.
      Потоковое видео

      Быстро обновляющиеся области кодируются в видеопоток. Существует два варианта:
      • all: Любая быстро обновляющаяся область будет закодирована в видеопоток.
      • filter: Дополнительные фильтры используются, чтобы решить, следует ли использовать потоковое видео (в настоящее время пропускаются только небольшие поверхности окон).

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

      Решение проблем
      Общая папка не отображается

      Убедитесь, что Служба WebDAV включена и запущена в гостевой системе. В Windows он называется Spice webdav proxy. В Linux имя spice-webdavd, но может отличаться в зависимости от дистрибутива.

      Если служба запущена, проверьте сервер WebDAV, открыв http://localhost:9843 в браузере в гостевой системе.

      Это может помочь перезапустить сеанс SPICE.
Автор: на
Ярлыки: , ,

1 комментарий:

  1. Павел М.7 марта 2020 г. в 09:22

    Александр, спасибо за продолжение перевода руководства администратора Proxmox - наконец-то можно понять для чего некоторые параметры и как именно они влияют на настройку ВМ а не просто повторять настройки с картинок примеров.

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

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