Proxmox как подключить hdd к виртуальной машине

Очередная миграция PROXMOX в softRAID1, но теперь уже 3.2 и на GPT-разделах, установка FreeNAS 9.2 на виртуальную машину и проброс в него физического диска

В очередной раз мне понадобился сервер Proxmox. Железо следующее: AMD FX-4300, 4Gb, два диска 500Gb для самого proxmox и еще два для хранилища. Задачи слоял следующие: одна из машин FreeNAS, в нее хотелось пробросить несколько дисков (желательно физических), что бы на них разместить хранилище, и еще несколько ВМ не относящихся к статье.

У меня есть фишечка всегда пытаться ставить самые последнии версии, а не проверенные старые. Так произошло и в этот раз.
Скачал Proxmox VE 3.2 и FreeNAS 9.2. А вот что из этого получилось под катом.

Установив в очередной раз Proxmox (последнюю на данный момент версию 3.2) решил перевести его на SoftRAID1. Но обнаружил, что в отличии от 3.0, он (proxmox) преобразовал диск в GPT. Соответственно рекомендации в статье на которую я ориентировался не совсем актуальны. К тому же во всех статьях о переводе Proxmox в SoftRAID речь идет только о двух разделах (boot и LVM). В моем же случае разделов на диске было 3. Первый GRUB, а затем уже стандартные boot и LVM.

Это не должно нас остановить.

Перевод proxmox на softRAID на GPT разделах

Идем стандартным путем и ставим все необходимое ПО. И тут нас ждет еще один сюрприз связанный с тем, что с версии 3.1 репозиторий у Proxmox стал платным. Поэтому перед установкой нужных пакетов его нужно отключить (возможно, правильнее указать вместо него бесплатный тестовый репозитарий, но у меня получилось и просто закомментировать платный). Откройте его в любом редакторе

и закомментируйте единственную строку.

Если вы все же хотите добавить бесплатный репозитарий, то выполните команду:
Спасибо heathen за его комментарий.

Теперь ставим необходимые пакеты:

последний нужен если вы проделываете это удаленно. Перенос LVM в RAID длится долго и желательно это делать через screen.

Проверяем что создание массивов теперь доступно:

Далее мы копируем разделы с sda на sdb. Вот тут то и начинаются отличия в MBR и GPT. Для GPT это делается так:
Присвоим новому жесткому диску случайный UUID.

Проверим что разделы созданы так как мы хотели:

Меняем флаги разделов sdb2 и sdb3 на raid:

Все получилось правильно.

Идем дальше и на всякий случай очищаем суперблоки:

Вывод «mdadm: Unrecognised md component device — /dev/sdb3» означает, что диск не участвовал в RAID.
Собственно, пора создавать массивы:

На вопрос «Продолжить создание массива?» отвечаем утвердительно.

Посмотрим, что у нас получилось:

В выводе видно состояние массивов — [_U]. Это обозначает, что в массиве есть лишь один диск. Так и должно быть, ведь второй (первый) мы в массив еще не включили. (missing).

Добавляем информацию о массивах в конфигурационный файл:

Скопируем раздел boot на соответствующий массив. (Добавил здесь команды отмонтирования раздела. Спасибо за информацию пользователю skazkin. Его опыт показал, что в некоторых случаях без этих действий может раздел boot оказаться пустым после перезагрузки):

Далее нам нужно закоментировать в /etc/fstab строку описывающую монтирование boot-раздела с UUID и пропишем монтирование соответствующего массива:

Должно получиться примерно так.
Перезагружаемся:

Настраиваем GRUB (делаем это абсолютно так же как и в оригинальной статье):

Теперь добавим раздел boot с первого (sda) диска в массив. Сначала пометим его флагом «raid»:

Если посмотреть теперь состояние массивов:

то мы увидим, что md1 стал «двухдисковым» — [UU]

Теперь нужно перенести основной раздел — LVM. Тут нет никаких отличий от «оригинала», за исключением другой нумерации разделов и:

Здесь, так же по рекомендации skazkin добавил команду pvremove. Без нее (опять таки не всегда) может появиться другая проблема:

система не поймет что произошло с дисками и не загрузится дальше initramfs-консоли

Добавляем раздел sda3 в массив:

и видим, что он добавляется.

Так как я действую по оригинальной статье, то я пошел наливать кофе.

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

Для тех, кто как и я не понял почему на этом все, объясняю. Т.к. LVM том мы фактически перенесли с одного блочного устройства на другое, то и прописывать его не требуется (как это было с boot). Я на какое-то время застопорился на этом месте.

FreeNAS 9.2 на процессорах AMD

Следующим моим шагом была установка FreeNAS версии 9.2 на proxmox. Долго мучался. Пока не попробовал поставить из того же образа (FreeNAS 9.2) на другом proxmox-сервере. Он немного отличается от описываемого в статье: во-первых он на Core i7, во-вторых proxmox 3.1. И там это естественно встало на счет раз. Т.е. проблема либо в AMD (нет такого точно не может быть), либо в том, что в proxmox 3.2 поломали поддержку FreeBSD9 (бррр). Долго копал. Потом начал экспериментировать сам. В итоге все таки AMD. Что уж у них там за проблема, но как только я выставил в свойствах ВМ тип процессора Core 2 Duo FreeNAS 9.2 установился без проблем.

Проброс физического диска в KVM (proxmox)

Долго искал ответ на это вопрос на просторах Сети, но находил лишь обрывки. Может кто-то и по ним может сразу понять, что и как, но не я.
В общем делается это так (с консоли):

и добавляете в конце строку:

где sdc — это ваше устройство. Далее можно через запятую указать прочие параметры (их можно посмотреть в wiki proxmox’а).

Вот и все. Правда не знаю насколько такое подключение поднимает (или опускает) скорость дисковых операций. Тесты у меня еще впереди.

Источник

Добавляем жесткий диск в Proxmox

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

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

Подключаем диск в системе

Устанавливаем жесткий диск в корпус нашего сервера. Подключаем шлейфы (если сервер не поддерживает горячую замену дисков, то лучше его остановить ), переходим к терминальной строке или подключаемся по ssh.

2. Создаем разметку для подключенного жесткого диска (в случае, если на нем хранятся важные данные, то пропускаем 2 и 3 шаг):

Необходимые команды для fdisk:

m — Помощь
p — Показать разделы жесткого диска
n — Создать новый раздел
d — Удалить раздел
q — Выйти без сохранения
w — Записать изменения и выйти

3. Форматируем новый диск при помощи команды mkfs.ext4:

4. Создаем директорию, куда будем монтировать новый диск:

5. Монтируем диск и добавляем его в файл fstab:

6. Перезагружаем систему и проверяем — монтируется ли новый диск автоматически.

Если все прошло удачно, то переходим к панели управления Proxmox.

Добавляем новый каталог в панели управления Proxmox

1. Входим в панель управления нашего сервера, набрав в адресной строке https://[ip-адрес сервера]:8006

2. Выбираем пункт «Датацентр» — «Хранилище» — «Добавить» — «Каталог»:

3. Указываем параметры добавленного хранилища:

Хранилище добавлено. Продолжаем работу

Источник

Proxmox. Подключить существующие разделы к «новой VM»

Коллеги, прошу помочь с вопросом. Умер HDD с Proxmox. Остался SSD, на котором есть 2 раздела. vm-100-disk-1 и vm-101-disk-1

ну если по тупому, то перенеси файлы vm-100-disk-1 и vm-101-disk-1 куда-нибудь в /root

затем создай виртуалку с номером 101, соответственно создастся файл vm-101-disk-1. замени его своим изначальным файлом и запускай.

или у тебя там LVM-thin и имиджи виртуалок не в виде файлов?

Это физически 2 раздела на SSD-ке и нужен 2-й из них. На счет LVM не уверен, вроде просто LVM. И если не сложно, напиши с командами как это сделать, я с виндой больше дружу, а тут прижало, приходится учиться на ходу.

а я вот не уверен, что это физические разделы. на практике, конечно, можно отдавать виртуалкам диски разделами, но это невозможно сделать из ГУИ и вообще это это не практикуется.твоя проблема решается в дюбом случае, но

учитывая, что ты написал, что в линуксе не очень, давай сначала убедимся, что это точно разделы.

Установил новый Proxmox 4.4, но при попытке создания VM он сразу пытается стереть разделы

Создавай VM с другим ID (102, например), а потом:

Могу подключить SSD как хранилище

Потому и предлагает почистить.

т.е. можно удалить первый раздел с SSD vm-100-disk-1 (он не нужен) и на его место создать VM? А затем затереть его старым (нужный чуть больше по размеру)? Сейчас картинка такая:

Источник

Как подключить файловое хранилище к Proxmox

Файловое хранилище можно использовать для расширения возможностей хостов виртуализации Proxmox.

Proxmox актуальной версии базируется на Debian, то штатная команда по добавлению статического маршрута route add не сработает без дополнительных действий. Чтобы пользоваться основными командами установите пакет net-tools :

Для добавления маршрута введите:

Новый статический маршрут отобразится в таблице маршрутизации:

Обратите внимание, штатные функции по монтированию NFS- и CIFS-хранилищ не всегда работают правильно. При попытке смонтировать хранилище через Web-интерфейс высока вероятность появления ошибки вида «storage is not online»:

В случае появления этой ошибки используйте workaround-решение по монтированию NFS-хранилищ, как в случае Ubuntu. Затем добавьте хранилище как обычную директорию.

После добавления директории, куда смонтировано хранилище, можно будет использовать его для хранения ISO-образов и для бэкапов.

Хранилище позволяет использовать общее дисковое пространство для нескольких одиночных серверов или хостов виртуализации, а также позволяет мигрировать с одной системы виртуализации на другую. Например, с Proxmox на VMware ESXi, используя утилиту конвертирования образов дисков qemu-img:

Источник

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

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

Страницы

среда, 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, но может отличаться в зависимости от дистрибутива.

Источник