Динамическое выделение памяти для виртуальных машин

Данная небольшая заметка посвящена использованию virtio balloon драйвера для «горячего» изменения количества оперативной памяти в гостевых системах. Технология появилась достаточно давно, и использовать её довольно просто, но при этом возникает множество интересных вопросов.

Как это использовать?

Использование balloon драйвера — один из основных способов динамического изменения количества оперативной памяти, выделенной виртуальной машине. Необходимо отметить, рассматриваемый механизм не является аналогом memory hot plug, и требует поддержки со стороны ядра операционной системы; для этого для Linux и Windows систем разработаны соответсвующие драйверы. В подавляющем большинстве дистрибутивов Linux поддержка virtio-balloon включена по умолчанию. Скачивание и установка virtio balloon драйверов для Windows описано тут

Для включения ballooning необходимо запускать qemu с опцией -balloon virtio.

Узнать количетво памяти, выделенное для вирт машины можно при помощи команды info balloon в консоли qemu monitor

В гостевой системе (Linux) можно воспользоваться командой free для получения информации об использовании оперативной памяти

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

В гостевой системе

Аналогичным образом можно и увеличить размер памяти, но не превышая того предела, который установлен при запуске (параметр -m)

Для Windows систем процесс полностью аналогичен

После урезания памяти

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

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

Если необходимо уменьшить количество памяти выделяемое машине, то сначала balloon процесс «раздувается» до необходимого размера, а потом позволяет хосту освободить нужное количество памяти

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

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

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

Поэтому для эффективного использования balloon драйвера необходимо каким-то образом получать информацию об реальном использовании памяти в гостевой системе и на основе полученных данных принимать решение об ограничениях. Подобный механизм разрабатывается в настоящий момент. Адам Литке (Adam Litke) Разработал серию патчей для qemu и balloon драйвера, которые позволяют получать дополнительную информацию об использовании памяти. (Делается это при помощи команды info balloon в qemu мониторе.) Последние версии libvirt уже содержат код, который парсит обновленный вывод команды info balloon для получения информации об оперативной памяти гостевой системы. Но по словам Адама пока что эти патчи содержат некоторые проблемы связанные с взаимодействием с qemu, и в настоящее время идет активная работа по их доработке.

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

Получение информации от гостевой системы.

Для передачи информации из гостевой системы на хост можно воспользоваться virtio-serial механизмом. Подробней про него можно прочитать тут и тут. Для совсем тестового примера работы с памятью воспользуемся каналом (pipe) между гостем и хостом. Связь схематично показана на рисунке ниже.

Для создания подобного virtio интерфейса необходимо создать два fifo файла и прописать необходимые параметры qemu

Теперь qemu monitor доступен через файлы mon.in и mon_out, файлы mem_pipe.in и mem_pipe.out служат для сообщений с гостевой системой через созданный канал. На гостевой системе при этом создается устройство /dev/virtio-ports/mem, служащее для приема и передачи сообщений к хост системе.

Чтобы получать информацию о потреблении памяти виртуальной машины в гостевой системе будет работать следующий простейший скрипт (возможности которого можно неограничено расширять)

Скрипт выполняет простейшую задачу — при приеме сообщения mem, он отсылает хост системе количество свободной памяти (с учетом «условно свободных» кешей). Простестируем работу скрипта

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

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

Dynamic Memory Management

Contents

Introduction

Optimized and effective memory management is a key factor in virtualization environments. KSM and Auto-Ballooning enables sophisticated and economic configurations for physical RAM utilization.

KSM (Kernel Samepage Merging) is running in the Linux kernel and scans the memory of all the virtual machines running on a single host, looking for duplication and consolidating. With KSM we’re able to improve virtual machine density by as much as 300% without impacting performance. One of the great benefits of using Linux as the hypervisor means KSM is not limited to KVM and virtual machines, but can also reduce memory pressure with normal Linux applications.

It was integrated in PVE since version 1.5, and is implemented with the package «ksm-control-daemon» (check your version with the cli command «pveversion -v»).

KSM in action

Just install several KVM virtual machines with the same OS (using at least 80% of your physical memory on the host) and wait a few minutes. You will notice higher CPU activities on the host (ksm daemon) and the used memory on the host will be lowered significantly (see start page showing the overall memory usage).

Howto verify that KSM is working (how many pages are being shared between your KVM guests):

Note: a page is 4096 bytes

The file /etc/ksmtuned.conf allows for some customization of its behaviour.

Disable KSM

If you don’t care about memory optimization but care about save CPU overhead produced by KSM, in Proxmox >= 4.x you can disable it with:

Ballooning

Memory ballooning (KVM only) allows you to have your guest dynamically change it’s memory usage by evicting unused memory during run time. It reduces the impact your guest can have on memory usage of your host by giving up unused memory back to the host.

The Proxmox VE host can loan ballooned memory to a busy VM. The VM decides which processes or cache pages to swap out to free up memory for the balloon. The VM (Windows or Linux) knows best which memory regions it can give up without impacting performance of the VM.

Requirements for Windows VM

Installation

• You need to install the VirtIO Balloon Driver and the management service (blnsvr.exe -i).
• Notice: there is a small blnsvr.exe bug on 32bit systems with RAM more than 2GB: https://github.com/YanVugenfirer/kvm-guest-drivers-windows/issues/11

See Windows VirtIO Drivers to get info about

• downloading VirtIO drivers
• changelog and guest OS compatibility
• other kind of guest devices supported

Download

Download the latest drivers (ISO) as suggested by the page Windows_VirtIO_Drivers to your desktop.

Then upload the ISO to your Proxmox VE server:

• logon to the Proxmox VE web interface
• select a ISO-enabled storage (see Storage_Model#Storage_type_Content)
• switch to «content» tab
• just use the «upload» button on the menu bar.

Choose the right driver

Enable Auto-Ballooning on Windows Server 2012 / Windows 8.1 or newer

Starting with virtio-win-0.1.173-2 the driver ISO provides an installer located at » :\virtio-win-gt-x64.msi» that can, besides other things, install the ballooning service.

If it does not work you can follow the manual way which is described below for Windows 2008r2.

Enable Auto-Ballooning on Windows 2008r2

1. Set the VM memory to «Automatically allocate memory within this range» — I choose 4096/2048 as example (see screenshot)
2. Start the VM and install all virtio drivers, including the balloon driver (see screenshot)
3. Copy and rename as Administrator the WIN7\AMD64 directory from the virtio.iso to «c:/Program files/Balloon»
4. Open a CMD as Administrator and cd into «c:/Program Files/Balloon»
5. Install the BLNSVR with «BLNSVR.exe -i»

As soon as the service is started, also the memory information displayed on the Proxmox VE GUI is identical to the value shown in the windows task manager (see screenshot).

If you need details about ballooning stats for this VM, go to the KVM monitor and enter ‘info balloon’

Proxmox and incorrect Windows RAM reporting

by joel · May 30, 2018

When Windows Server 2016 is first installed in a Proxmox virtual machine (or any version of Windows, actually), RAM usage is reported incorrectly. Very incorrectly, in fact; the Proxmox web GUI makes it look as if Windows Server is using nearly all the RAM available to it. Never fear though — Windows is actually not using that much memory, and fixing the issue is trivially easy and only takes a few minutes.

Note the high RAM usage reported in Proxmox. This server has just booted and is running no software or services other than Windows itself. Why would it be using nearly 8 GB of RAM just running idle? Turns out, it’s not…

So Proxmox thinks our Windows Server VM is hogging nearly all the available memory. A quick peek at the Windows Task Manager reveals another story:

Windows reports 1.1 GB used, not 7.

So Windows is actually using 1.1 GB of RAM, or 14% used, while the Proxmox interface reports 7 GB, or 88%. The fix to this lies in installing the Balloon driver, which runs as a Windows service and reports correct RAM usage information to the Proxmox host. To install the Balloon driver, we’ll need to mount the “virt-io” drivers ISO image as a CD drive. The following two articles have some help on how and where to find this ISO image, how to mount it as a CD drive, and so on.

With the VirtIO driver ISO loaded as a CD drive, open Windows Explorer, click on This PC, and double-click the virtio CD drive; open the Balloon directory, and choose the correct subdirectory for the version of Windows you are running. Select the “amd64” directory and hit Ctrl + C to copy it to the clipboard (or right-click and hit Copy if you like your mouse more than I do).

Note the path. Choose the appropriate folder according to your version of Windows (here, I’ve chosen the “2k16” directory for Server 2016).

Now navigate to C:\Program Files and paste in the “amd64” directory.

Paste the amd64 directory into Program Files.

Rename the directory; call it “Balloon.”

Rename the directory.

Now open a command prompt as administrator. (click Start; type “cmd” (minus the quotes); right-click on “Command Prompt” and click “Run As Administrator.”) At the elevated command line, change directories to C:\Program Files\Balloon and run “blnsvr.exe -i” as shown below. This installs the balloon service.

Success. Balloon service installed and running.

Verify that the balloon service is indeed running by opening Services (run services.msc).

And now, back over to Proxmox. RAM usage reporting is now accurate!

This looks much better and is now in line with what Windows Task Manager told us.

Further steps for Windows guests

In the VirtIO CD drive within Windows, navigate to the “guest-agent” directory and run the file appropriate to your architecture to install the KVM guest agent. (Pick the x64 file if on a 64-bit machine; x86 if 32-bit.) And within the Proxmox web interface, go to the Options page for the virtual machine in question and enable the QEMU Agent.

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

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

Страницы

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

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

Виртуальные машины 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 устройствам

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

Аппаратное обеспечение 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

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

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

Настройки ОС

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

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

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

Жесткий диск

К каждому контроллеру вы подключаете несколько эмулированных жестких дисков, которые представлены файлом или блочным устройством, находящимся в настроенном хранилище. Выбор типа хранилища будет определять формат образа жесткого диска. Хранилища, которые предоставляют блочные устройства (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 и поддержкой гостевой ОС TRIM 3 , когда файловая система виртуальной машины помечает блоки как неиспользуемые после удаления файлов, контроллер передает эту информацию в хранилище, которое затем сжимает образ диска соответствующим образом. Чтобы гость мог выдавать команды TRIM, необходимо включить опцию Discard на диске. Некоторые гостевые операционные системы могут также требовать установки флага эмуляции SSD. Обратите внимание, что Discard на дисках VirtIO Block поддерживается только на гостях, использующих ядро Linux версии 5.0 или выше.

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

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

Сокет процессора-это физический слот на материнской плате ПК, куда можно подключить процессор. Этот процессор может содержать одно или несколько ядер, которые являются независимыми процессорами. Есть ли у вас один сокет процессора с 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 и Spectre 4 , которые необходимо установить вручную, если только выбранный тип процессора вашей виртуальной машины уже не включает их по умолчанию.

Есть два требования, которые должны быть выполнены, чтобы использовать эти флаги процессора:

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

В противном случае вам необходимо установить нужный флаг процессора для виртуального процессора, либо путем редактирования параметров процессора в WebUI, либо путем установки свойства flags параметра cpu в файле конфигурации виртуальной машины.

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

Чтобы проверить, уязвим ли хост Proxmox VE, выполните следующую команду от имени root: Также доступен скрипт сообщества для обнаружения, является ли хост все еще уязвимым. 6

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

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

Требуется, включить чтобы исправить 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

Требуется, включить чтобы исправить 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

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

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

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

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

Вы можете использовать правило udev следующим образом, чтобы автоматически устанавливать новые процессоры как гостевые: Сохраните это в файле /etc/udev/rules.d/ как файл, заканчивающийся на .rules.

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

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

Память

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

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

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

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

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

При установке минимальной памяти ниже, чем память, 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/

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

Каждая виртуальная машина может иметь много контроллеров сетевого интерфейса (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.

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

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

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

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

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

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

Дисплей

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 и перенаправляет веб-консоль на выбранный последовательный порт. Настроенный параметр памяти дисплея в этом случае будет проигнорирован.

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

Проброс 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, непосредственно в виртуальную машину (например, устройство ввода или аппаратный ключ).

BIOS и UEFI

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

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

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

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

Такой диск можно создать с помощью следующей команды: Где — это хранилище, в котором вы хотите иметь диск, а — это формат, который поддерживает хранилище. Кроме того, вы можете создать такой диск через веб-интерфейс с помощью команды Add → EFI Disk в разделе аппаратного обеспечения виртуальной машины.

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

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

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

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

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

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

Дополнения SPICE

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

Чтобы включить их через графический интерфейс, перейдите на панель параметров виртуальной машины. Выполните следующую команду, чтобы включить их через CLI: На заметку Для использования этих функций Дисплей виртуальной машины должен быть настроен как 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, но может отличаться в зависимости от дистрибутива.