Virtio balloon driver что это
Данная небольшая заметка посвящена использованию virtio balloon драйвера для "горячего" изменения количества оперативной памяти в гостевых системах. Технология появилась достаточно давно, и использовать её довольно просто, но при этом возникает множество интересных вопросов.
Драйвера и Службы
Чтобы установить все недостающие драйвера для корректной работы Windows на Proxmox, запустите virtio-win-gt-x64.msi в корне диска virtio. Можете убрать установку тех драйверов и служб, что вы точно не будете использовать. Например, Qxl и Spice. После этого не только ip адреса, но и использования оперативной памяти должны корректно отображаться в веб интерфейсе.
Рекомендуется посмотреть менеджер устройств, чтобы убедиться в том, что там нет неопределённого оборудования. Если все драйверы установились корректно, то всё оборудование будет с драйверами и определено. Если это не так, то попробуйте установить драйвер устройства вручную. Для этого укажите в качестве источника драйвера виртуальный диск с virtio.iso и обязательно укажите использовать для поиска драйвера подпапки. Если драйвер будет найдет, то выберите его и установите, подтвердив, что доверяете установке драйверов от указанного поставщика.
Подготовка к установке
Для того, чтобы получить хорошее быстродействие операционной системы Windows на хосте Proxmox, мы установим Windows VirtIO Drivers во время установки VM.
- Создайте новую виртуальную машину, выберите тип "Microsoft Windows 10/2016/2019" и активируйте функцию "Qemu Agent" на вкладке System. Далее укажите свой iso образ в качестве источника установки.
- В качестве Bus/Device для виртуального диска укажите SCSI, контроллер должен быть VirtIO SCSI. Можете указать опцию кэширования Write back. Это увеличит быстродействие, но есть некоторые риски потери данных. Подробно про варианты кэширования я писал отдельно. Укажите параметр Discard для более эффективного использования места на диске. Этот параметр работает примерно так же, как технология TRIM в SSD дисках. Подчищает реально удаленные данные с диска, уменьшая занимаемое место.
- Настройки памяти и процессора укажите в зависимости от потребностей виртуальной машины. Модель сетевой карты укажите VirtIO (paravirtualized).
- Для того, чтобы во время установки системы использовать драйверы virtio, загрузите iso образ с ними. Добавьте новый CD-ROM к VM и подключите этот образ.
- Теперь у вас всё готово для установки системы Windows.
В завершение
Трудно рассказать в одной статье обо всех аспектах Windows + QEMU/KVM, поэтому завершим в следующей. А там будет самый смак, командный интерфейс, разрешение экрана максимум 1024x768, Сцилла pulseaudio и Харибда сети, команда virsh и настройка ВМ из конфиг файла, фейл с tpm , двоичный синтаксис устройств и прочие тихие радости.
Формат диска raw vs qcow2
Историю с выбором типа диска в proxmox я разбирал подробно в отдельной заметке. В общем случае формат raw обеспечивает лучшее быстродействие, но у qcow2 есть дополнительный полезный функционал. Речь идёт о технологии copy on write и возможности делать Live Snapshots. В настоящий момент формат qcow2 выбирается по умолчанию.
VirtIO drivers
Make it really easy: Build your ISO with drivers already included:
Можно достаточно просто подготовить свой образ операционной системы Windows с интегрированными VirtIO драйверами. Для этого можно можно воспользоваться отдельной статьёй - Windows guests - build ISOs including VirtIO drivers.
Установка Qemu Guest Agent на Windows
Для того, чтобы корректно работал Guest Agent на Windows, необходимо его установить отдельно. Он находит в iso образе virtio в корне диска, в папке guest-agent. Для x64 архитектуры установочный файл будет называться qemu-ga-x86_64.msi. Просто запустите установку и дождитесь окончания. Больше ничего делать не надо, агент автоматически установится и запустится.
Если всё прошло успешно, то вы сразу же в веб интерфейсе Proxmox увидите ip адреса на сетевых интерфейсах Windows.
QEMU/KVM и установка Windows
Хотим мы того или нет, но программы, для которых необходима Windows, никуда из офисов не исчезли. В ситуации, когда их использование безальтернативно, лучше иметь виртуальную ОС, например для того, чтобы подключиться к аудио-конференции через Skype for Business.
В этой статье я расскажу, как можно с минимальными издержками установить гостевую ОС Windows на гипервизоре QEMU с помощью графического интерфейса virt-manager . Мы нанесем на карту все подводные камни и рифы, а жучков аккуратно посадим в банку.
Запуск и инсталляция
Запускаем virt-manager и создаем новую виртуальную машину из локального хранилища.
Указываем путь к установочному iso образу Windows.
Далее, на 3-м и 4-м шаге будет выбор количества CPU, объем RAM и размер дискового пространства, после чего на 5-м шаге следует выбрать дополнительные конфигурации перед настройкой.
Окно дополнительных настроек нужно для того, чтобы выполнить финт ушами. Его смысл в том, чтобы добавить виртуальный флопарь с драйверами из набора virtio-win . Это даст возможность изменить тип жесткого диска: удалить диск с шиной IDE и добавить его же, но с шиной VirtIO. Подробно, в доках RedHat.
Прописываем драйвер /usr/share/virtio-win/virtio-win.vfd и добавляем виртуальный флоппи-диск. Затем переходим на вкладку [Шина] Диск № и проделываем финт с заменой шины диска: удаляем с IDE и добавляем с VirtIO.
Чуть не забыл сказать, для чего нужен этот фокус. Специалисты утверждают, что с шиной VirtIO, производительность диска ощутимо выше.
В принципе, уже можно начинать инсталляцию, но мы забыли добавить CD-ROM с драйверами virtio-win , а они нам пригодятся, когда диспетчер устройств засверкает желтыми иконками вопросительного знака.
Ну вот теперь можно начать установку.
Ну хорошо, начали мы установку. А что, если установщик Windows попросит сменить диск? Мне из-за этого пришлось пару раз прервать и начать всю карусель заново, но с вами такого уже не случится.
Ускорение дисковой подсистемы Qemu KVM в Linux
Иногда я берусь за различные задачи по настройке серверов. Некоторое время назад ко мне обратился владелец небольшой хостинговой компании, с интересной проблемой. Он хотел бы на своих серверах, где уже стоял Ubuntu 18.04, запускать виртуальные машины с Windows под KVM.
Однако проведённое им тестирование показало, что дисковая система KVM прилично отставала от показателей, которые у него были под Hyper-V. Он хотел раскочегарить qemu на своих Ubuntu серверах, чтобы избежать закупок дорогих серверных лицензий Windows (бесплатная версия Microsoft Hyper-V Server не устраивала из-за своих ограничений).
0. Диспозиция
Для тестирования использовался SSD Samsung 970 Pro 1TB. Заказчик проверял результаты работы в CrystalDiskMark, поэтому далее в статье все графики из него.
Windows 10 LTSC | Hyper-V 2 CPU | KVM 2 CPU |
---|---|---|
Следовало в первую очередь улучшить производительность случайного ввода/вывода. Именно этот тип нагрузки характерен для виртуальных машин, в особенности тех из них, в которых используются различные БД.
В Ubuntu (16.04 LTS и 18.04) до сих пор используется qemu версии 2.11. Поэтому некоторые плюшки самых последних qemu в этой статье не рассмотрены.
Мы решили что нам нужно избежать привязывания железа к виртуальной машине, так как это осложняет переносимость виртуальных машин, поэтому варианты с прокидыванием SSD/физических дисков/разделов в виртуалки были признанны нежелательными.
Внимательный читатель может заметить, что использовались разные по размеру области для тестирования от 100МБ до 4ГБ. Дело в том, что размер области очень влияет на время выполнения теста: чем больше область, тем длиннее шёл тест.
Однако, так как каждый раз виртуальная машина запускалась заново, кеш Windows сбрасывался и не оказывал влияние на результаты. Результаты для области 100МБ и 4ГБ отличались в пределах погрешности, но время было в 40 раз больше.
Тестирований за время настройки было проведено огромное количество, чтобы задача не затянулась на месяцы, основная часть испытаний была проведена с областями размером 100МБ-1ГБ. И только решающие испытания были проведены с областями 4ГБ.
1. Используем LVM-тома, а не файлы для хранения дисков виртуальных машин.
Логика такая. Файл с виртуальным диском хранится в файловой системе Linux, внутри самого файла находится NTFS. Каждая файловая система потребляет ресурсы при дисковых операциях. Поэтому чем меньше глубина матрёшки, тем быстрее ввод/вывод.
Если же говорить о файлах qcow2, то их название расшифровывается как «Qemu Copy-On-Write» и, фактически, внутри них есть своя таблица трансляции, которая отвечает за то какие блоки заняты, какие нет и где что находится.
Слой LVM потребляет значительно меньше процессорных ресурсов, чем файловая система. Одна из причин этого то, что блоки в нём значительно больше, чем типичный блок файловой системы (4КБ). Чем больше блок (extent) на физическом устройстве LVM, тем более быстро происходит IO и тем меньше фрагментация.
А ведь даже для SSD случайный ввод/вывод значительно медленнее, чем последовательный. Поэтому при создании Volume Group мы укажем очень большую величину extent: 256MB.
Read ahead на логическом томе стоит отключить, так как он расходует IO без выигрыша, так как теперь никто не занимается дефрагментацией дисков в Windows на SSD.
LVM довольно удобно использовать для хостинга виртуальных машин. LVM-тома легко переносимы между физическими дисками, есть снимки (snapshot), изменение размера в режиме онлайн. Тем более, что virt-manager (libvirt) умеет из коробки создавать логические тома под диски виртуальных машин из Volume group (группы томов).
Привлекательной выглядит также возможность создать thin volumes («тонкие» тома), но если учесть, что тонкий том — это дополнительный слой абстракции, то, очевидно, что он будет ухудшать производительность IO. К тому же в libvirt нет элегантного пути автоматического создания дисков для виртуальных машин в «тонком» пуле.
1.1. Thin volume как диск и/или настройки логических томов для снимков
Если вы хотите использовать thin pool, в котором будете создавать тонкие тома, то имеет смысл установить размер чанка у пула в 4МБ, что значительно больше размера по-умолчанию в 64КБ.
Что повлечёт более быструю работу этого слоя абстракции.
Механизм снимков в LVM работает практически на том же самом коде, что и тонкие тома, поэтому для увеличения скорости снимков (snapshot) настройки будут теми же самыми.
Опция -Zn отключает перезапись чанка нулями при выделении, что повышает скорость работы.
Настройки для lvm.conf или подобного файла (например lvmlocal.conf):
Вы можете сами определить оптимальный размер чанка выполнив тестирование следующей командой, подобрав величину --blocksize :
Посмотреть текущий размер чанка можно командой:
2. Увеличение количества логических процессоров, выделяемых на каждую виртуальную машину KVM, улучшает дисковую производительность
10 CPU | 8 CPU | 4 CPU |
---|---|---|
Понятно, что вряд ли кто будет выделять на виртуалку 10 процессоров, но было интересно посмотреть на крайний случай.
Из чего можно сделать вывод, что хорошо иметь по одному логическому процессору на каждую задачу, активно использующую IO.
3. Используем огромные страницы оперативной памяти (hugepages), чтобы избежать снижения производительности из-за фрагментации RAM
Этот пакет может пригодиться, когда нам понадобится различная информация о hugepages в процессе эксплуатации.
В данном случае было выделено 64ГБ памяти для всех виртуальных машин в виде hugepages. В вашем случае может быть меньше/больше.
Применяем эти настройки для GRUB, чтобы при следующей загрузке системы они стали активны:
Редактируем конфиг виртуальной машины:
4. Добавляем в каждую виртуальную машину выделенный поток для обслуживания IO
Нужно добавить то, что выделено жирным. Используем virsh , как и в предыдущем пункте.
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none' io='threads' iothread='1'/>
<source dev='/dev/win/terminal'/>
<target dev='vda' bus='virtio'/>
<boot order='2'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</disk>
4.1. Для ускорения случайной записи используем кеширование writeback
Для ускорения случайной записи на диск, но с увеличением риска потери данных, можно использовать cache=writeback в предыдущем пункте. Можно использовать только если есть большая уверенность в качестве и резервировании питания и при наличии бэкапов.
5. Настройки дисковой подсистемы в В Virt Manager
Disk bus: VirtIO
Storage format: raw
Cache mode: writeback
IO mode: threads
5.1. Настройка дисковой подсистемы через конфигурационный файл
Qemu 2.11 (который сейчас используется в Ubuntu) поддерживает два типа дисковых виртуальных устройств: virtio-blk и virtio-scsi. Когда в Virt Manager указывается Disk bus: VirtIO — это означает использование устройства virtio-blk.
Во всех случаях по скорости лучше virtio-blk, несмотря на то что в тестируемой версии qemu он ещё не поддерживал TRIM в отличии от virtio-scsi (с версии 5.x уже поддерживает).
С точки зрения скорости дискового IO virtio-scsi имеет смысл использовать лишь в экзотических случаях, например, когда нужно подключать сотни дисков к виртуальной машине.
6. В процессе инсталляции Windows устанавливаем драйвер VirtIO
Иначе диск не будет доступен для ОС. Для этого используем образ с драйверами, который предварительно подключаем к виртуальной машине.
7. Результаты после применения всех твиков
На самом деле твик 4.1 не был применён, так как я не был уверен в надёжности питания у клиента.
Hyper-V 2 CPU | KVM 2 CPU | KVM 4 CPU |
---|---|---|
Нужно понимать, что эти результаты грешат некой условностью, так как при каждом запуске CrystalDiskMark значения немного отличаются.
KVM из коробки 2 CPU | KVM после твиков 2 CPU |
---|---|
Мы видим, что удалось существенно ускорить работу дисковой подсистемы в qemu (kvm) при одном и том же числе ядер. Запись была ускорена в среднем на 58%, а чтение на 25%.
Основные элементы успеха: использование LVM-томов вместо файлов qcow2, отдельный поток ввода/вывода и hugepages.
Замеченные ошибки направляйте в личку. Повышаю за это карму.
P.S. vhost-user-blk и vhost-user-nvme
В ходе экспериментов были также и скомпилированы Qemu 2.12 и 3-й версии. Тестировалась опция vhost-user-blk для диска.
В итоге она работала хуже, чем virtio-blk.
vhost-user-blk 4 CPU | virtio-blk 4 CPU |
---|---|
Для использования vhost-user-nvme нужно было патчить qemu, этот вариант усложнял автоматическое обновление серверов в продакшене, поэтому не был протестирован.
P.P.S. SPDK
Intel разработала этот фреймворк для достижения выдающихся показателей производительности у дисковых систем в виртуальных машинах, которые должны работать на её процессорах.
Чтобы заставить spdk хорошо работать идут на массу ухищрений — выделяют ему отдельные ядра, размещают ядра spdk и виртуальной машины в одном сокете. Загружают виртуальную машину в непрерывный кусок памяти. Если такие меры применять к обычному virtio-blk, то он тоже будет быстрее работать.
SPDK способен работать в 3-х режимах: vhost-user-scsi, vhost-user-blk и vhost-user-nvme. Второй режим доступен только в qemu от 2.12, который ещё не доступен в ubuntu. Режим vhost-user-nvme вообще мегаэкспериментальный — для него нужно патчить qemu. На текущий момент работает только эмуляция scsi и она медленная.
Есть ещё одно серьёзное ограничение для режима vhost-user-scsi — диск spdk не может быть загрузочным.
Make sure bootindex=2 Qemu option is given to vhost-user-scsi-pci device.
Рекорды ставятся, когда они с помощью своего драйвера разделяют SSD на несколько устройств и прокидывают их как vhost-user-nvme. Подход с прокидыванием железа нам не подходил.
Сложилось впечатление, что нормально использовать SPDK можно только с их реализацией логических дисков (которая совершенно отличается от стандартных lvm). Это такой самопальный велосипед со своими снимками и клонированием. Команды все отличаются от LVM.
Сложность в настройке SPDK, поддержке и переносимости виртуальных машин, а также привязанность к процессорам Intel отвернула от его использования.
Благодарности
За изображение спасибо TripletConcept. Его лучше смотреть в полном размере в отдельном окне.
За разрешение поделиться рабочими материалами — st_neon
Вы можете заказать виртуальную машину с SSD у RUVDS по купону ниже.
Замеченные ошибки направляйте в личку. Повышаю за это карму.
Драйвера и доводка
По окончанию процесса установки диспетчер устройств недосчитается некоторых драйверов. Предположительно, это могут быть:
Нужно скормить им драйвера из набора virtio-win , что подключены через IDE CD-ROM в предыдущем разделе.
Делается это стандартно: правой кнопкой на желтый знак вопроса, обновить драйвера, путь к файлам.
Вот весь список, а это соседняя страница RedHat доков, где установка драйверов показана подробнее.
- Balloon, the balloon driver, affects the PCI standard RAM Controller in the System devices group.
- vioserial, the serial driver, affects the PCI Simple Communication Controller in the System devices group.
- NetKVM, the network driver, affects the Network adapters group. This driver is only available if a virtio NIC is configured. Configurable parameters for this driver are documented in Appendix E, NetKVM Driver Parameters.
- viostor, the block driver, affects the Disk drives group. This driver is only available if a virtio disk is configured.
Оборудование
Тут постепенно начинается область безграничных возможностей и 101 способов сделать по-своему, поэтому я покажу, как это работает у меня, а вы можете настроить более точно под свои нужды.
У меня выбран дисплей Сервер Spice и звуковое устройство ich6 . Нет, конечно, если у вас уйма времени и желание во всем разобраться до самых тонкостей — дерзайте и пробуйте альтернативные подходы, но у меня звук взлетел, вернее завибрировал, только с такими настройками. Во второй части, посвященной прогулке по граблям и отлову багов, я расскажу об этом подробнее. В закладке видео я выставил QXL , ибо с этой опцией, благодаря волшебному драйверу, мне удалось добиться нормального разрешения экрана.
Подключаться к ВМ можно разнообразно.
- Через графический интерфейс virt-manager
- Выбрать дисплей VNC-сервер и подключаться через vnc-клиента
- Установить Spice-клиента и подключаться через него
- К Windows можно подключиться через rdp, если включен терминальный сервер
У меня вариант 3, для Gentoo это программа spice-gtk
Сеть для ВМ можно настроить по-разному, на Хабре умельцы уже об этом писали. Я перепробовал несколько способов, и в конце простота опять взяла вверх. Сама ВМ запускается из под рута [3] , но графический интерфейс spice-gtk — из под обычного непривилегированного пользователя. Это позволяет решить дилемму: для сетевых опций нужны права рута, а для звукового демона pulseaudio, рут запрещен. Я пробовал навешать все права на обычного пользователя, но ничего не получалось, то pulse не пульсирует, то сеть не создается, там много а тут мало. В итоге решил так и доволен. Буду рад, если в комментариях будет найден лучший способ.
Такой простой выбор сетевых опций дает результат превосходящий ожидания. Создаются 3 дополнительных сетевых интерфейса: virbr0, virbr0-nic, vnet0.
В iptables создается свод правил, вот основные:
Повторяю, все это libvirtd создает сам, ничего для этого делать не надо. В результате имеем нормальный роутинг между хостом и ВМ, можно обмениваться файлами по ssh / scp . Можно пойти дальше и создать шару на Windows, а на Linux хосте настроить samba, но мне это показалось избыточным.
Введение
В данной статье будут даны общие рекомендации, так называемые best practices на тему установки Windows 10 или 11 на гипервизор Proxmox. Данное руководство можно использовать как how to для проверки себя во время настройки виртуальных машин.
Как это работает?
Balloon драйвер создает в ядре специальный процесс, который по команде с хоста может изменять количество потребляемой им памяти. Оставшаяся память может быть использована всеми остальными процессами в гостевой системе для собственных нужд.
Если необходимо уменьшить количество памяти выделяемое машине, то сначала balloon процесс "раздувается" до необходимого размера, а потом позволяет хосту освободить нужное количество памяти
Увеличение количества памяти происходит аналогичным образом.
При таком методе работы количество памяти, используемое вирт машиной, ограничивается общим количеством памяти указанным в параметре -m.
Необходимо отметить, что в текущей реализации balloon драйвер не обращает никакого внимания на количество свободной памяти в системе, поэтому при чрезмерном ограничении в использовании памяти можно легко столкнуться с потерей производительности (хотя бы за счет дисковых кешей) или с полным зивисанием машины. При недостатке памяти операционная система начинает использовать swap, что приводит к активному использованию диска и значительно тормозит работу.
Поэтому для эффективного использования balloon драйвера необходимо каким-то образом получать информацию об реальном использовании памяти в гостевой системе и на основе полученных данных принимать решение об ограничениях. Подобный механизм разрабатывается в настоящий момент. Адам Литке (Adam Litke) Разработал серию патчей для qemu и balloon драйвера, которые позволяют получать дополнительную информацию об использовании памяти. (Делается это при помощи команды info balloon в qemu мониторе.) Последние версии libvirt уже содержат код, который парсит обновленный вывод команды info balloon для получения информации об оперативной памяти гостевой системы. Но по словам Адама пока что эти патчи содержат некоторые проблемы связанные с взаимодействием с qemu, и в настоящее время идет активная работа по их доработке.
Но уже сейчас есть несколько способов получения информации от гостевой системы. Например, можно передавать данные об использовании памяти по сети (разумеется в этом случае сеть должна быть настроена в виртуальной машине). Такой способ используется в проекте MoM. Далее я опишу немного другой способ связи между хост системой и виртуальной машиной, при помощи которого мы сможем управлять 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 систем процесс полностью аналогичен
После урезания памяти
Подготовка
Самый первый шаг — настройка параметров ядра. Обязательна поддержка KVM и vhost-net , желательна поддержка туннельных интерфейсов [1] и сетевого моста [2] . Полный список на Gentoo вики-странице QEMU.
Подготовьте дисковое пространство. Я выделил 70 GiB, и Windows 8.1 за пару месяцев использовала почти 50 GiB так, что для обновления до 10-й версии места на диске не хватило.
Далее, нам понадобится набор редхатовских драйверов virtio-win . Если у вас установлен RedHat, достаточно запустить
и образ iso будет записан в каталог /usr/share/virtio-win/ . Также можно его скачать с репозитариев Fedora.
Убедитесь, что поддержка аппаратной виртуализация включена в BIOS/UEFI. Без этого KVM не будет активирован, а virt-manager выдаст вот такую ошибку.
В качестве проверки можно прочитать файл устройства.
Если файл не обнаружен, а опции ядра выставлены верно, значит дело в настройках BIOS/UEFI .
Устанавливаем нужные пакеты.
Для RedHat 7 достаточно установить только virt-manager , так как QEMU устанавливается по умолчанию.
Дебианщикам надо установить пакет qemu .
Можно теперь переходить к установке.
Рекомендации (best practices) по установке Windows 10 и 11 на Proxmox
Я решил перевести заметку из proxmox wiki на тему рекомендаций по установке в качестве гостевой системы Windows 10. Там нет каких-то особых и критичных замечаний. Просто последовательно изложен порядок рекомендуемых действий и настроек для максимального быстродействия и стабильной работы системы.
Если у вас есть желание научиться работать с роутерами микротик и стать специалистом в этой области, рекомендую по программе, основанной на информации из официального курса MikroTik Certified Network Associate. Курс стоящий, все подробности читайте по ссылке. Есть бесплатные курсы.Получение информации от гостевой системы.
Для передачи информации из гостевой системы на хост можно воспользоваться virtio-serial механизмом. Подробней про него можно прочитать тут и тут. Для совсем тестового примера работы с памятью воспользуемся каналом (pipe) между гостем и хостом. Связь схематично показана на рисунке ниже.
Для создания подобного virtio интерфейса необходимо создать два fifo файла и прописать необходимые параметры qemu
Чтобы получать информацию о потреблении памяти виртуальной машины в гостевой системе будет работать следующий простейший скрипт (возможности которого можно неограничено расширять)
Полученное значение обозначает количество свободной памяти в Мб. Наконец, можно настроить автоматическую подстройку количества памяти для вирт машины в зависимости от использования. Приведенный ниже скрипт имеет огромное количество недостатков, он предназначен прежде всего для демонстрации возможностей.
Разумеется в реальных задачах логика управления памятью должна опираться на более подробные данные анализа, включая в себя оценки роста потребления памяти и прогнозы дальнейшего использования, но включение этих возможностей принципиально осуществимо уже с имеющимися механизмами. Надо отметить, что доработка патчей для balloon драйвера позволит получать данные о потреблении памяти не из гостевой системы, а напрямую из qemu monitor.
Запуск установки Windows в Proxmox
- После запуска установки системы, подключитесь к консоли виртуальной машины.
- Дойдите до этапа установки, где нужно выбрать жёсткий диск. Скорее всего список доступных дисков будет пуст.
- Нажмите "Загрузить драйвер" для того, чтобы установить драйвер жесткого диска и сетевой карты.
- Для установки драйвер диска перейдите в директорию vioscsi\w10\amd64 и подтвердите выбор. Выберите "Red Hat VirtIO SCSI pass-through controller". Ваш виртуальный жёсткий диск должен появиться в списке для установки на него системы.
- Повторите то же самое для выбора драйвера сетевой карты. Он находится в директории NetKVM\w10\amd64. Выберите "Redhat VirtIO Ethernet Adapter".
- Драйвер выделения динамической оперативной памяти находится в Balloon\w10\amd64. Перейдите в эту директорию и выберите драйвер "VirtIO Balloon Driver".
- Загрузка этих трёх драйверов позволит установщику Windows определить всё оборудование, так что можно продолжить установку системы в обычном режиме.
Подробно описанную процедуру можно лицезреть на видео на примере установки Windows Server 2016 на ProxMox. Установка Windows 10 или 11 будет проходить точно так же.
Читайте также: