Создание хостинга сайтов на базе Proxmox + HP ProLiant
Доброе время суток.
Итак, обратились ко мне с задачей переезда на собственный сервер с трех VPS около 100 сайтов, в том числе новостей с базой данных MySQL размером около 20 Гб, и общим весом мелких (в основном) файлов на хостинге около 500 Гб.
Сам сервер был установлен без моего участия в стойку провайдера, даны два IP адреса — доступ к админке сервера и IP адрес хостинга.
Картинки для привлечения внимания: 
Конфигурация сервера:
Proc 1: 2267 MHz
Execution technology: 6/6 cores; 12 maximum threads
Memory technology: 64-bit capable
Processor 1 Internal L1 Cache: 192 KB
Processor 1 Internal L2 Cache: 1536 KB
Processor 1 Internal L3 Cache: 12288 KB
Proc 2: 2267 MHz
Execution technology: 6/6 cores; 12 maximum threads
Memory technology: 64-bit capable
Processor 2 Internal L1 Cache: 192 KB
Processor 2 Internal L2 Cache: 1536 KB
Processor 2 Internal L3 Cache: 12288 KB
HDD:
1 PLEXTOR PX-256M
2 WDC WD1000DHTZ
ОЗУ
PROC 1 DIMM 4B: 16384 MB 1333 MHz
PROC 1 DIMM 6C: 16384 MB 1333 MHz
PROC 2 DIMM 4B: 16384 MB 1333 MHz
PROC 2 DIMM 6C: 16384 MB 1333 MHz
По желаемому на сервере:
1. Windows 2012 Server для каких-то целей, связанных с 1С.
2. Основной хостинг (высоконагруженный).
3. Машина для тестов
В процессе настройки убедил хозяев приобрести еще один IP — адрес для тестовой машины
Приобретены две лицензии ISP Panel для основного хостинга и тестового хостинга.
Собственно с выбором *nix ОС вариантов не было, настаивали на CentOS 6.
Заливаем в машину образ CentOS. Тут было некое неудобство от ProxMox — можно качнуть образ не по ссылке, а только имеющийся у себя на харде. Так что пришлось сначала лить к себе, потом выливать на сервер.
С WD (/dev/sdb), который должен быть основным хранилищем поступил следующим в консоли Proxmox образом по статье отсюда:
Таким образом я получил дополнительное хранилище для виртуальных дисков машин.
А вот swap файлы было решено размещать на ssd. Про это ниже.
Про настройки прав доступа. Так как пользователь будет не root, то заводим его и даем права доступа на хранилище и машины. Для этого зашел в датацентр, закладка группы, создал группу «users». Ввел пользователя в группу «users», в закладке пользователи.
Надо отметить, что если мы заходим рутом, то в форме авторизации Proxmox необходимо выбрать авторизацию ОС — «pam», пользователя я же завел уже с авторизацией непосредственно из базы пользователей proxmox, поэтому при входе необходимо выбирать тип авторизации «pve».
Так же очередной «ЗЮ» в сторону создателей Proxmox — прикрутить бы генерацию паролей в админку, неудобно заводить пользователей количеством более одного.
Идем в Датацентр, закладка Разрешения и добавляем группе «users» админские права (ну хозяева же) на доступ к хранилищу ws, и на создание виртуальных машин. Пока достаточно.
Сначала решил создать машину для тестового хостинга. Создаем VM «tests» (машина 100) со следующими характеристиками:
ОЗУ 4 Гб; процессор «по умолчанию kvm64», СД — привод образ CentOS, HDD — образ диска от vmvare (vmdk), кэширование write back, 120 Gb на хранилище ws, сетевая Intel на бридже vmbr0. Про сетевые функции расскажу чуть ниже, когда будем делать хостинг для рабочих сайтов.
Ставим centos, цепляем репозитории, обновляемся, ставим mc. atop, настраиваем resolv.conf и прочее прочее. На этом остановил виртуальную машину подумал.
Так как я потратил на установку образа ОС час, то я решил оптимизировать этот процесс для следующих n-машин. Поэтому в консоли зашел /var/lib/ws/images/100, и скопировал образ диска vmdk в папку /home
Устанавливаем ip адрес интерфейса eth0 виртуальной машины (пока из консоли proxmox).
Далее с сайта ISPmanager раздел установка разворачиваем необходимые сервисы. Некоторое время прошло, машина взлетела, заработала. Ничего не стал трогать в конфах, оставил все по-умолчанию.
Надо сказать для каждой созданной машины так и сделал — CPU Units = 45000.
Что делать с высоко нагруженным хостингом мысль зрела давно:
Создать виртуалок по принципу один сервер — один сервис. Кроме того, раз у нас proxmox имеет внешний IP хостинга, то будем ipfirewall разводить подключения в нужные нам машины. Так же создаем «внутреннюю» сетку, например 192.168.12.0/24.
В Proxmox для этого решил поднять интерфейс dummy:
Далее в админке Proxmox, Датацентр — Сеть создаем vmbr1 (бридж) на базе интерфейса dummy.
Задаем ip адрес proxmox 192.168.12.1. Подготовка сделана.
Поехали.
1 машина: mysql (vm101). Опытным путем было выяснено, что база такого объема данных (20Гб) хорошо существует на 27 Гб ОЗУ. Процессор 4 сокета по 3 ядра. А вот хард цепляем как и машина №1. Когда Proxmox создает машину, копирую из /home образ hdd первого CentOS (если Вы помните, там не настроена сеть и hostname, но все уже обновлено и готово к запуску). Сетевая карта на бридже vmbr1
Настраиваем сетевой интерфейс. Так как eth0 у нас остался на машине для тестов, то нужно создать в /etc/sysconfig/network-scripts файл ifcfg-eth1 следующего содержания:
Что касается установки nginx как proxy к apache, то на эту тему куча статей. Плюс в той же виртуалке завожу exim + dovecot с базой в MySQL.
Виртуальная машина nginx (vm102). Образ диска взят так же копированием после создания виртуальной машины. CPU 3 сокета, 3 ядра; ОЗУ 4 Гб. Сетевая карта на бридже vmbr1.
Создаем apache (vm103). CPU 4 сокета по 2 ядра, ОЗУ 16 Гб, 1-ый HDD 120 Gb для готового образа, второй HDD 500Gb для сайтов, Сетевая карта на бридже vmbr1. Переливаем образ уже установленного CentOS, настраиваем:
Как нам установить ISPManager на хостинг, расположенный внутри локальной сети? Ничего более умного в голову не пришло, кроме как задать ProxMox другой доступный нам IP адрес — от машины tests, машине tests отключить автозапуск, и на время перевести сетевой интерфейс в бридж vmbr0. После ребута Proxmox, внутри машины apache(vm103):
Цепляем HDD 500 GB на /var/www:
Далее с сайта ISPmanager раздел установка разворачиваем необходимые сервисы.
Отключаем Posfix, courier (у нас же почтовик не тут), прочие ненужные сервисы по вкусу. Выключаем mysql, говорим ISPmanager-у что сервер mysql находится на другой машине. Это делается из ISPManager-а в разделе MySQL.
Возвращаем настройки как было (apache vmbr1, 192.168.12.20; tests автозапуск при загрузке; proxmox ip — адрес хостинга).
В proxmox (192.168.12.1; ) добавляю в rc.local проброс порта 1500 (админка ISPManager) на apache (192.168.12.20), проброс ssh к виртуалкам, проброс портов на nginx:
Что касается запуска IPSManager, который требует на локальной машине ip, к которому привязана лицензия, то решил так же через интерфейс dummy. Ему выдаю необходимый ip адрес, потом делаю ifconfig dummy down. Раньше этого не делал, но сайты настроены так, что берут картинки для отображения по адресу вида имя сайта/images/. /. /. jpg.
Поэтому если интерфейс не гасить, то получается так:
Обещал рассказать про swap раздел на SSD-диске. Тут все достаточно просто, создаем образ диска в хранилище default, собственно куда и ставили Proxmox. Задаем необходимый размер образа. Затем подключаем разделы так:
Напоследок приведу fstab машины с apache (там виртуальных дисков больше всего).
Обратите внимание на последнюю строку файла fstab. Значительно ускорил работу файловой системы установкой после 1 2. До этого долго рыл всевозможные форумы и слепил такую строку из того, что накопал. Сборная солянка, так сказать.
В принципе так или иначе все работает и летает уже 2 недели, то есть тестовый период прошел.
Что касается бекапа (BACKUP), то предложил пойти очень простым путем — взять WD Live Book гига этак на 3, включить на нем ftp и лить туда снапшоты виртуальных машин, которые успешно создает ProxMox.
Что касается проброса пассивного FTP, я его еще не сделал. Смысл в том, что необходимо пробросить на apache порты 20, 21 и некое количество портов для пассивного соединения, а у меня этот проброс не получается. Ну не цепляется фтп из вне к моему серверу никак. Пока не горит, так что решаю по мере прихода вдохновения. Буду признателен за подсказку. Стоит сервер proftpd. Идея была следующая — жестко в конфиге прописать пул портов для пассивного режима FTP, и пробросить его внутрь из ProxMox. Пока не докопался как это делается.
Поясните за выделение CPU Proxmox
Было бы что раздавать, хех. Чего именно ты хочешь добиться?
Понятно, что ты хочешь «эффективно». Но придётся выбирать между изоляцией, квотами для каждой виртуалки, оверхедом, отзвычивостью виртуальных ядер. Причём даже если ты определишься с желаниями, настройки всё равно будут зависеть от характера нагрузки.
В ситуации «2 ядра или 2 сокета» разницы в производительности KVM практически нет.
По крайней мере, разработчики proxmox так считают 🙂
Топик этот видел, но не верю, что никакой разницы.
Весь интернет пишет, что в общем случае разницы нет. Если ты такой неверующий, запусти бенчмарк.
Пойду раскопаю ненужный сервачек.
И насколько быстрее?
Где-то полторы секунды разницы от первого места до последнего. Если кто-то предложит правильный бенч, я всё померяю и поделюсь результатами.
Что с результатами в итоге?
Завёл оба на Proxmox 5, распределили 10гб под винду 4 под астериск 2 оставил в резерве, 6 ядер под винду 2 под астериск
Сейчас тестирую Hyper-V Server 2016 на предмет увеличения производительности в винде,т.к. основным всё-же является сервер на винде, астериску много не нужно.
(предварительное тестирование роли Hyper-V на Windows 10 Pro и процессоре Pentium G4600 с включённой виртуализацией показали потери 1-2% в гостевой ОС)
если основные виртуалки виндовые (вин 2012 и выше) ставь гиперв.
Администрирование и не только
Не вполне стандартные задачи, с которыми мне приходится сталкиваться по работе и способы их решения.
Страницы
среда, 4 марта 2020 г.
Руководство администратора Proxmox VE R 6.0 Глава 10.
Виртуальные машины Qemu/KVM
Гостевая операционная система, работающая на эмулируемом компьютере, обращается к этим устройствам и работает так, как она работает на реальном оборудовании. Например, вы можете передать образ 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.
Жесткий диск
Если вы хотите, чтобы диспетчер резервного копирования Proxmox VE пропускал диск при резервном копировании виртуальной машины, вы можете установить параметр нет резервного копирования на этом диске.
Если вы хотите, чтобы механизм репликации хранилища Proxmox VE пропускал диск при запуске задания репликации, вы можете установить параметр Пропустить репликацию на этом диске. Начиная с версии Proxmox VE 5.0, репликация требует, чтобы образы дисков находились в хранилище типа zfspool, поэтому добавление образа диска в другие типы хранилищ, когда для виртуальной машины настроена репликация, требуется опция пропустить репликацию для этого образа диска.
Если вы хотите, чтобы диск был представлен гостю как твердотельный диск, а не вращающийся жесткий диск, вы можете установить опцию эмуляции SSD на этом диске. Нет никакого требования, чтобы базовое хранилище фактически поддерживалось твердотельными накопителями; эта функция может использоваться с физическими носителями любого типа. Обратите внимание, что эмуляция SSD не поддерживается на дисках VirtIO Block.
Сокет процессора-это физический слот на материнской плате ПК, куда можно подключить процессор. Этот процессор может содержать одно или несколько ядер, которые являются независимыми процессорами. Есть ли у вас один сокет процессора с 4 ядрами или два сокета процессора с двумя ядрами, в основном не имеет значения с точки зрения производительности. Однако некоторые лицензии на программное обеспечение зависят от количества сокетов на машине, в этом случае имеет смысл установить количество сокетов на то, что позволяет лицензия.
Увеличение числа виртуальных процессоров (ядер и сокетов) обычно обеспечивает повышение производительности, хотя это сильно зависит от использования виртуальной машины. Многопоточные приложения, конечно, выиграют от большого количества виртуальных процессоров, так как для каждого добавляемого виртуального процессора Qemu создаст новый поток выполнения на хост-системе. Если вы не уверены в рабочей нагрузке вашей виртуальной машины, обычно безопасно установить общее число ядер равным 2. Примечание Совершенно безопасно, если общее число ядер всех ваших виртуальных машин больше, чем число ядер на сервере (например, 4 виртуальных машины с 4 ядрами у каждой на машине только с 8 ядрами). В этом случае хост-система будет балансировать потоки выполнения Qemu между ядрами вашего сервера, как если бы вы запускали стандартное многопоточное приложение. Однако Proxmox VE не позволит запускать виртуальные машины с большим количеством виртуальных процессорных ядер, чем физически доступно, так как это приведет только к снижению производительности из-за стоимости контекстных переключателей. Ограничение ресурсов
Qemu может эмулировать ряд различных типов процессоров от 486 до новейших процессоров Xeon. Каждое новое поколение процессоров добавляет новые функции, такие как аппаратный 3D-рендеринг, генерация случайных чисел, защита памяти и т. д. Обычно вы должны выбрать для своей виртуальной машины Тип процессора, который близко соответствует ЦП хост-системы, поскольку это означает, что функции ЦП хоста (также называемые флагами ЦП ) будут доступны в вашей виртуальной машине. Если требуется точное совпадение, можно установить тип процессора host, и в этом случае виртуальная машина будет иметь точно такие же флаги процессора, как и ваша хост-система.
Но у этого есть и обратная сторона. Если вы хотите выполнить динамическую миграцию виртуальных машин между различными хостами, ваша виртуальная машина может оказаться на новой системе с другим типом процессора. Если флаги процессора, переданные гостю, отсутствуют, процесс qemu остановится. Для исправления этого Qemu имеет также свой собственный процессор типа kvm64, который Proxmox VE использует по умолчанию. kvm64-это Pentium 4 подобный тип процессора, который имеет уменьшенный набор флагов процессора, но гарантированно работает везде.
Короче говоря, если вы заботитесь о динамической миграции и перемещении виртуальных машин между узлами, оставьте kvm64 по умолчанию. Если вы не заботитесь о динамической миграции или имеете однородный кластер, где все узлы имеют один и тот же процессор, Установите тип процессора на хост, так как теоретически это даст вашим гостям максимальную производительность.
Флаги процессора, связанные с Meltdown/Spectre
Для исправлений 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/
Необходим для того, чтобы исправить Spectre В4 (ПНЭ-2018-3639). Не входит по умолчанию ни в одну модель процессора Intel. Должен быть явно включен для всех моделей процессоров Intel. Требуется обновленный микрокод центрального процессора (intel-microcode >= 20180425).
7 PCID теперь является критической функцией производительности/безопасности на x86 https://groups.google.com/forum/m/#!topic/mechanical-sympathy/L9mHTbeQLNU
Рекомендуется указать, что хост не уязвим для Spectre V4 (CVE-2018-3639). Не входит по умолчанию ни в одну модель процессора AMD. Будущие аппаратные поколения CPU не будут уязвимы для CVE-2018-3639, и поэтому гостю следует сказать, чтобы он не включал свои средства защиты, выставляя amd-no-ssb. Это взаимоисключает Virtus-ssbd и amd-ssbd.
NUMA
Если используется опция NUMA, рекомендуется установить число сокетов равным числу сокетов хост-системы.
Современные операционные системы ввели возможность горячего подключения и, в определенной степени, горячего отключения процессоров в работающих системах. Виртуализация позволяет нам избежать многих (физических) проблем, которые может вызвать реальное оборудование в таких сценариях. Тем не менее, это довольно новая и сложная функция, поэтому ее использование должно быть ограничено случаями, когда она абсолютно необходима. Большая часть функциональности может быть реализована с другими, хорошо протестированными и менее сложными функциями, см. Ограничения ресурсов.
В Proxmox VE максимальное количество подключаемых процессоров всегда равно количество ядер * количество сокетов. Чтобы запустить виртуальную машину с меньшим, чем это общее количество ядер процессоров, можно использовать параметр vpus, он указывает, сколько vcpu должно быть подключено при запуске виртуальной машины. В настоящее время эта функция поддерживается только на Linux, требуется ядро новее, чем 3.10, рекомендуется ядро новее, чем 4.7.
Примечание Горячее удаление CPU зависит от компьютера и требует поддержки гостевой ОС. Команда удаления не гарантирует, что удаление процессора действительно произойдет, обычно это запрос, направляется гостю с использованием механизма, зависимого от цели например, ACPI на x86/amd64.
Память
Для каждой виртуальной машины вы можете установить память фиксированного размера или попросить Proxmox VE динамически выделять память в зависимости от текущего использования оперативной памяти хоста.
Фиксированное Выделение Памяти
При установке памяти и минимальной памяти на одинаковый объем Proxmox VE просто выделит то, что вы укажете для вашей виртуальной машины.
Даже при использовании фиксированного объема памяти, устройство ballooning добавляется к виртуальной машине, потому что оно предоставляет полезную информацию, например, сколько памяти действительно использует гость. В общем, вы должны оставить ballooning включенным, но если вы хотите отключить его (например, для отладки), просто снимите флажок ballooning устройства или установите в конфигурации.
Автоматическое Выделение Памяти
При установке минимальной памяти ниже, чем память, Proxmox VE будет следить за тем, чтобы указанный вами минимальный объем всегда был доступен виртуальной машине, и если использование оперативной памяти на хосте ниже 80%, будет динамически добавлять память гостю до указанного максимального объема памяти.
Когда хосту не хватает оперативной памяти, виртуальная машина затем высвобождает некоторую память обратно на хост, заменяя запущенные процессы, если это необходимо, и запуская oom killer в крайнем случае. Передача памяти между хостом и гостем осуществляется через специальный драйвер ядра balloon, работающий внутри гостя, который захватывает или освобождает страницы памяти от хоста. 10
Все дистрибутивы Linux, выпущенные после 2010 года, имеют драйвер ядра balloon. Для операционных систем Windows драйвер balloon должен быть установлен вручную и может вызвать замедление гостя, поэтому мы не рекомендуем использовать его на критических системах.
При выделении оперативной памяти для ваших виртуальных машин, хорошее эмпирическое правило-всегда оставлять 1 ГБ оперативной памяти доступной для хоста.
10 Хорошее объяснение внутренней работы balloon драйвера можно найти здесь: https://rwmj.wordpress.com/2010/07/17/-virtio-balloon/
Сетевое устройство
Если вы используете драйвер VirtIO, вы можете дополнительно активировать опцию Multiqueue. Эта опция позволяет гостевой ОС обрабатывать сетевые пакеты с использованием нескольких виртуальных процессоров, обеспечивая увеличение общего количества передаваемых пакетов.
При использовании драйвера VirtIO с Proxmox VE каждая сетевая очередь NIC передается ядру хоста, где очередь обрабатывается потоком ядра, порожденным драйвером vhost. Если эта опция активирована, можно передать несколько сетевых очередей ядру хоста для каждой сетевой карты.
При использовании Multiqueue рекомендуется установить для него значение, равное общему числу ядер вашего гостя. Кроме того, необходимо задать в виртуальной машине количество многоцелевых каналов на каждой виртуальной машине с помощью команды ethtool:
где X-номер числа vCPU виртуальной машины.
Следует отметить, что установка параметра Multiqueue в значение, превышающее единицу, приведет к увеличению нагрузки ЦП на хост-и гостевые системы по мере увеличения трафика. Мы рекомендуем устанавливать этот параметр только тогда, когда виртуальная машина должна обрабатывать большое количество входящих подключений, например, когда виртуальная машина работает как маршрутизатор, обратный прокси-сервер или нагруженный HTTP-сервер, выполняющий длительный опрос.
Дисплей
Вы можете изменить объем памяти, предоставленной виртуальному графическому процессору, установив опцию memory. Это позволит включить более высокое разрешение внутри виртуальной машины, особенно с SPICE/QXL.
Выбор serialX в качестве типа дисплея отключает выход VGA и перенаправляет веб-консоль на выбранный последовательный порт. Настроенный параметр памяти дисплея в этом случае будет проигнорирован.
11 qemu: использование цирруса не рекомендуется https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/
Проброс USB
vendor/product-id выглядит следующим образом: 0123:abcd, где 0123-идентификатор поставщика, а abcd-идентификатор продукта, то есть два одинаковых usb-устройства имеют один и тот же идентификатор.
BIOS и UEFI
Чтобы правильно эмулировать компьютер, QEMU должен использовать firmware(прошивку). Который на обычных PC (известен как BIOS или (U)EFI), выполняется как один из первых шагов при загрузке виртуальной машины. Он отвечает за выполнение базовой аппаратной инициализации и за обеспечение интерфейса к микропрограммному обеспечению и аппаратному обеспечению для операционной системы. По умолчанию QEMU использует для этого SeaBIOS, который является реализацией BIOS x86 с открытым исходным кодом. SeaBIOS-хороший выбор для большинства стандартных установок.
Есть, однако, некоторые сценарии, в которых BIOS не является хорошей прошивкой для загрузки, например, если вы хотите сделать проброс VGA. [12] в таких случаях лучше использовать OVMF, который является реализацией UEFI с открытым исходным кодом. [13]
Если вы хотите использовать OVMF, необходимо учитывать следующие факторы:
Для сохранения таких вещей, как порядок загрузки, необходим диск EFI. Этот диск будет включен в резервные копии и моментальные снимки, и может быть только один.
При использовании OVMF с виртуальным дисплеем (без VGA passthrough), вам нужно установить разрешение клиента в меню OVMF(в которое вы можете попасть нажав кнопку ESC во время загрузки), или вы должны выбрать SPICE в качестве типа дисплея.
Inter-VM разделяемая память
Вы можете добавить устройство общей памяти между виртуальными машинами (ivshmem), которое позволяет обмениваться памятью между хостом и гостем, а также между несколькими гостями.
Аудио-устройство
Автоматический запуск и выключение виртуальных машин
Дополнения SPICE
Примечание Раздел отсутствует а исходном руководстве, добавлен из Proxmox WiKi Дополнения SPICE-это дополнительные функции, которые могут улучшить возможности удаленного просмотра.
Чтобы включить их через графический интерфейс, перейдите на панель параметров виртуальной машины. Выполните следующую команду, чтобы включить их через CLI: На заметку Для использования этих функций Дисплей виртуальной машины должен быть настроен как SPICE (qxl). Общий Доступ К Папкам
Для гостей Windows установщик демона Spice WebDAV можно загрузить с официального сайта SPICE.
В большинстве дистрибутивов Linux есть пакет под названием spice-webdavd, которые могут быть установлены.
На заметку Общий доступ к папкам в настоящее время работает только в Linux-версии Virt-Viewer. Внимание Экспериментально! В настоящее время эта функция не работает стабильно. Потоковое видео
Решение проблем
Общая папка не отображается
Убедитесь, что Служба WebDAV включена и запущена в гостевой системе. В Windows он называется Spice webdav proxy. В Linux имя spice-webdavd, но может отличаться в зависимости от дистрибутива.
