Proxmox virtio drivers linux

Запуск Windows под Linux KVM

Задача: запустить некоторое количество виртуальных машин с Windows на типовом Линукс-сервере.

Решение: любой современный Linux-дистрибутив, «родная» технология виртуализации KVM, Windows 2003 и настройки, описанные ниже.

Выбор гостевой ОС

Windows XP работает под Linux KVM неустойчиво. Основные ошибки — потребление 100% процессора процессом csrss.exe (вплоть до обрыва RDP-сессий) и BSOD с кодом IRQL_NOT_LESS_OR_EQUAL в HAL.DLL. Если удалось достичь стабильной работы, обязательно отключите автоматическую установку обновлений! По нашему опыту, для работы WinXP под KVM они стали главным источником проблем.

Windows 7 работает нормально, но согласно счётчикам Proxmox, требует для работы более 3 гигабайт ОЗУ.

Оптимальным вариантом оказалась 32-разрядная редакция Windows 2003 R2:

• работает надёжно, в т.ч. с virtio,
• проблем совместимости с XP не имеет (даже внешний вид может быть сделан таким же),
• занимает в ОЗУ менее 800 мегабайт.

Верхнего лимита в 4 гигабайта памяти (без PAE) оказалось достаточно для всех возникавших задач.

Для ознакомительных целей годится любой опубликованный на RuTracker дистрибутив.

Первый запуск и virtio

Параметр «-vnc . » имеет смысл только на сервере без GUI. По умолчанию KVM откроет окно через SDL. В обоих случаях Ctrl+Alt+Shift+1 и Ctrl+Alt+Shift+2 служат для переключения внутри окна между гостевой и управляющей консолью.

Параметр » -net nic,model=virtio. » создаст внутри ВМ сетевую карту неизвестного Windows типа, для которого мастер настройки оборудования предложит выбрать драйвер. Парный ему параметр » -net tap. » создаст в хост-ОС сетевой интерфейс для связи с ВМ. Назначение IP-адресов, настройка DHCP и выхода во внешний мир через ProxyARP, NAT или Bridge не имеют прямого отношения к Windows, поэтому здесь не рассматриваются.

Теперь про самое важное на данном этапе, т.е. про диски.

HDC — это ISO-образ с дистрибутивом Windows. Имя файла взято из торрента в предыдущем разделе. С него внутри ВМ произойдет первая загрузка системы (» -boot order=d «).

HDA — это пустой образ диска, на который будет устанавливаться система. Создан командой » kvm-img create -f qcow2 vm_10.img 50G «.

HDB — это пустой образ диска, созданный через » kvm-img create -f qcow2 temp.img 1G » с единственной целью — показать Windows устройство незнакомого типа, чтобы она затребовала драйвер для него. Установка в систему драйвера virtio для временного диска позволит переключить затем с IDE на virtio системный диск.

После того, как установка системы и драйверов будет полностью завершена, в команде запуска следует убрать «-boot» и все строки «-drive», кроме первой, т.к. временный диск и ISO-образы станут не нужны (обратите внимание на добавленный » if=virtio «!):

Про пользу virtio, варианты настройки сети и параметры командной строки kvm читайте в habrahabr.ru/post/167099

Рекомендуемые настройки Windows

Во-первых, по умолчанию Windows создаёт при BSOD’ах полный дамп памяти. В лучшем случае, это существенно замедлит перезагрузку. В худшем, приведёт к полному зависанию.

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

Поэтому после завершения инсталляции в самую первую очередь (до установки драйверов!) рекомендуется зайти в Панель управления => Система:

• Автоматическое обновление: Отключить
• Дополнительно => Отчет об ошибках => Отключить
• Дополнительно => Загрузка и восстановление => Параметры => Отказ системы => Запись отладочной информации => Малый дамп памяти (64КБ)

Настройки TCP/IP не являются обязательными, но немного повысят производительность, т.к. в виртуальной среде отсутствуют некоторые проблемы, которые нужно учитывать при передаче по физической сети.

После этого можете приступать к установке драйверов для диска (virt-stor) и сетевой карты (virt-net). После их установки в Диспетчере оборудования появятся «Red Hat VirtIO SCSI Controller», «Red Hat VirtIO SCSI Disk Device» и «Red Hat VirtIO Ethernet Adapter».

Ballooning

Традиционный подход — сразу при запуске виртуальной машины (ВМ) выделять ей блок ОЗУ заданного размера, например, 512 мегабайт. Его недостаток — в те моменты, когда в памяти ВМ есть неиспользуемое пространство, в других ВМ и хост-системе её может не хватать.

Memory ballooning — это механизм динамического (а) выделения хост-ОЗУ для ВМ по мере необходимости и (б) возвращения неиспользуемых блоков по мере освобождения. Благодаря ему становится возможным одновременно запускать множество ВМ, суммарный объём виртуального ОЗУ в которых больше объёма физического ОЗУ в хост-системе, при условии, что они не станут использовать максимально разрешённый объём все сразу. Благодаря этому память хост-системы распределяется между ВМ так же гибко, как между обычными процессами.

Создание виртуальных ресурсов, превышающих физические по объёму, обозначается любимыми для многих хостеров терминами «overcommit» и «overselling».

Для работы баллонинга требуется согласованная работа двух программных компонентов:

• MOM (memory overcommitment manager) в хост-системе, меняющего объём ОЗУ для ВМ на основании запросов из неё,
• VMM (менеджера виртуальной памяти) в гостевой ОС, взаимодействующего с MOM через виртуальный PCI-контроллер.

MOM в последних версиях KVM включается автоматически, старые требовали включать его с помощью «kvm… -balloon virtio» в командной строке.

Гостевое устройство для связи с MOM диспетчер оборудования (devmgmt.msc) Windows увидит как «PCI standard RAM controller» неизвестного типа. В отличие от virt-stor и virt-net, драйвер к нему не будет предложено установить автоматически. Вместо этого, следует зайти в свойства устройства, на вкладке «Драйвер» выбрать обновление и вручную указать путь к balloon.inf на VirtIO CD (пруф). После этого устройство переименуется в «VirtIO Balloon Driver».

По умолчанию Windows 2003 разрешает выключать себя единственным способом — ввести логин-пароль, выбрать Пуск => «Завершение работы», ввести примечание, нажать «OK». Разумеется, на VDS-ферме такой подход неприемлем. KVM (и QEMU) умеет эмулировать ACPI. Команда «system_powerdown» аналогична нажатию кнопки питания на физическом компьютере, но Windows её проигнорирует. Лечится следующим REG-файлом:

Кэширование

Если образ гостевого диска хранится на VDS-ферме в виде файла, кэширование гостевых файлов может оказаться двойным — сначала их кэширует гостевая ОС при обращениях к виртуальному диску, затем ОС фермы при обращениях к физическому.

Всего возможны 3 основных режима:

• none — хост-система не кэширует файл-образ ни на чтение, ни на запись
• writeback — запись выполняется немедленно, чтение кэшируется
• writethrough — чтение и запись кэшируются

В разных версиях qemu/kvm и в разных ОС по умолчанию могут использоваться разные режимы. Например, Qemu до версии 1.2 использует writethrough, 1.2 перешёл на writeback, в Proxmox выбран cache=none.

Все без исключения источники в Сети советуют не использовать writethrough как наиболее медленный. По субъективной оценке, для ВМ с Windows оптимален writeback, для ВМ с Linux и FreeBSD — none.

Зависания сети

Единственной серьёзной проблемой, которую однозначно вызывает ошибка в KVM, являются подвисания гостевой сети при интенсивном трафике: bugs.centos.org/view.php?id=5526 (кроме собственно описания ошибки, там же есть важные ссылки на другие багтрекеры).

Рекомендации, предлагаемые участниками обсуждений (обновление qemu-kvm и ядра, изменение параметров командной строки, использование vhost-net), к сожалению, пока не сумели её решить.

При каждом подвисании приходится заходить на консоль ВМ по VNC и выполнять сброс сетевого интерфейса, после чего трафик снова начинает ходить нормально.

Автоматизировать данное действие в Windows можно с помощью AutoIt, если создать файл PingFailed_ResetNic.au3 и вызывать его Диспетчером заданий каждые несколько минут:

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

Источник

Qemu-guest-agent

Contents

Introduction — What is qemu-guest-agent

The qemu-guest-agent is a helper daemon, which is installed in the guest. It is used to exchange information between the host and guest, and to execute command in the guest.

In Proxmox VE, the qemu-guest-agent is used for mainly two things:

1. To properly shutdown the guest, instead of relying on ACPI commands or windows policies
2. To freeze the guest file system when making a backup (on windows, use the volume shadow copy service VSS).

Installation

You have to install guest-agent in each VM and then enable it, you can do that in the Proxmox VE Webinterface (GUI)

or via CLI: qm set VMID —agent 1

Guest

Linux

On Linux you have to simply install the qemu-guest-agent, please refer to the documentation of your system.

We show here the commands for Debian/Ubuntu and Redhat based systems:

on Debian/Ubuntu based systems (with apt-get) run:

and on Redhat based systems (with yum):

Depending on the distribution, the guest agent might not start automatically after the installation.

Start it either directly with

(should work for most distributions) or reboot the guest.

Windows

First you have to download the virtio-win driver iso (see Windows VirtIO Drivers).

Then install the virtio-serial driver:

1. Attach the ISO to your windows VM (virtio-*.iso)
2. Go to the windows Device Manager
3. Look for «PCI Simple Communications Controller»
4. Right Click -> Update Driver and select on the mounted iso in DRIVE:\vioserial\ \ where is your Windows Version (e.g. 2k12R2 for Windows 2012 R2)

After that, you have to install the qemu-guest-agent:

1. Go to the mounted ISO in explorer
2. The guest agent installer is in the directory guest-agent
3. Execute the installer with double click (either qemu-ga-x86_64.msi (64-bit) or qemu-ga-i386.msi (32-bit)

After that the qemu-guest-agent should be up and running. You can validate this in the list of Window Services, or in a PowerShell with:

If it is not running, you can use the Services control panel to start it and make sure that it will start automatically on the next boot.

Testing that the communication with the guest agent is working

The communication with the guest agent takes place over a unix socket located in /var/run/qemu-server/ .qga You can test the communication qm agent:

if the qemu-guest-agent is correctly runnning in the VM, it will return without an error message.

Источник

VirtualBox и virtio-scsi для win10 guest

Подскажите, будьте добры, как правильно установить драйвер для virtio-scsi в win10 для паравиртуализации при установке в virtualbox на Ubuntu 20.10. Я пробовал создавать раздел для установки win10 в виде virtio-scsi контроллера, дополнительно монтировал образы в с установщиком win10 и драйвером virtio-scsi (брал отсюда https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/) в виде SATA (AHCI). Пробовал и стабильную версию (virtio-win-0.1.185.iso), и свежую (virtio-win-0.1.190.iso).

Проблема возникает тогда, когда драйвер установлен (во время установки win10), но установщик всё так же не видит раздел virtio-scsi.

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

Proxmox 5.3-11 проблема с производительностью сети

Доброго времени суток, имеется Proxmox 5.3-11 на обычном десктопном железе, висят 2 виртуалки. Проблема с сетью, входящий трафик без проблем, а вот исходящий ведет себя странно: стоит какой либо файл побольше 50гб например поставить на скачивание в какой то момент сеть отключается на виртуалках и на proxmox на несколько сек. соединение сбрасывается. Сеть обычная локалка 1Gb. На виртуалках сетевая Virtio, пробовал срезать скорость 512kb результат тот же. Обе гостевые системы лежат на разных массивах, одна лежит на zfs вторая на mdraid. Есть идеи?

Нумерация версий VirtIO

Не пойму, по какой схеме определяется стабильность/нестабильность версий VirtIO.

• Стабильная версия:
  • virtio-win-0.1.171-1
• Непонятно какие версии:
  • virtio-win-0.1.172-1
  • virtio-win-0.1.173-1
  • virtio-win-0.1.173-2
  • virtio-win-0.1.173-3
  • virtio-win-0.1.173-4
  • virtio-win-0.1.173-5
  • virtio-win-0.1.173-6
  • virtio-win-0.1.173-7
  • virtio-win-0.1.173-8
  • virtio-win-0.1.173-9
• Последняя версия:
  • virtio-win-0.1.185-1

Почему у них стабильной версией называется .171-1 а не .173-9 или хотя бы не .172-1?

Или они просто забыли обновить ссылку в документации?

Не возможно установить win7 в качестве гостевой ОС

Создаю виртуальную машину virt-install -n win7
–network=bridge:br0
–ram 4096 –arch=x86_64
–vcpus=2 –cpu host –check-cpu
–disk path=/dev/virt_hdd/win7,format=raw,bus=virtio,cache=none
–cdrom /mnt/Data-1/kvm/iso/‘RUS_Windows_7_Ultimate_64bit_activat_free(3,47Gb)_v2.iso’
–graphics vnc,listen=0.0.0.0,password=123
–boot cdrom,hd,menu=on
–hvm
–accelerate

Процесс установки win7 начинается, диск не виден. Устанавливаю драйвера virtio, далее установщик widows видит диск, делаю его разметку, но установку не могу продолжить т.к. выдается ошибка о не возможности установить windows в данный раздел. Код ошибки 0x803000001. Что я делаю не так?

Не работает alt+ЛКМ в virt-manager, spice, virtio

Всем привет. В прошлом своём треде спрашивал, как можно получше изолировать рабочие и нерабочие приложения друг от друга, спрашивал про видео в виртуалках — и решился поставить себе debian buster в qemu.

Видео настроил virtio, в настройках spice включил поддержку opengl, всё на виртуальной машине подцепилось, с этим всё ок.

Проблема в другом — не могу использовать привычный для меня жест для переноса окон в кедах — когда зажимаешь альт, нажимаешь на окне ЛКМ — и окно начинает передвигаться вместе с курсором, в виртуалке это просто не работает, ничего не происходит. Похоже что основная система перехватывает это действие, хотя экран виртуальной машины развёрнут в virt-manager на полный экран, все клавиши перехватываются.

Как быть и что делать?

red hat virtio scsi disk device windows guest

Привет ЛОР! Прошу поделитесь опытом, как у вас работает Windows 10 в quemu/kvm.
Есть у меня lvm том. Устанавливаю туда Windows 10. Драйвер диска выбираю virtio. Windows устанавливается, драйвер работает, диск работает.
Но по впечатлениям, работает медленнее, чем драйвер sata.
Том lvm на ssd диске.

Стоит доверять жёсткие диски windows?

Добрый вечер.
Поясняю.
Вопрос по производительности.
Есть KVM-виртуалка. Надо решить, какой вариант будет быстрее работать.
1. Самый очевидный и вроде бы быстрый вариант: я отдаю весь новый диск, как устройство целиком, в гостевую виндовс. Сырой, без ФС.

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

2. Форматнуть этот новый винт в ext4, и создать файл-образ диска. Добавив его в virt-manager, c virtio-драйвером и режимом кеширования по умолчанию.

Так стоит ли доверить винт виндовс или всёж создать файл-образ с ФС?

KVM Проблема с дисками

Имеем Ubuntu 14 и KVM 1.3.2

Гостевые машины под WIN 2008R2 диски в формате qcow2 работают под родным драйвером virtio.

У ВМ с большими дисками (более 1ТБ) и активным дисковым обменом наблюдается непонятный глюк. KVM регулярно ставит такую машин на паузу со статусом I/O Error. Сначала помогает простая перезагрузка ВМ, но вскоре ситуация повторяется до тех пор пока машина сразу же начинает падает в паузу на этапе загрузке ОС и всё. Если проблемный раздел перевести в read only ВМ стартует и работает. Данные можно качнуть но раздел приходится грохать и пересоздавать.

Что было предпринято: 1.Заменены все диски, заменены целиком платформы. Проблема продолжает воспроизводится на разных площадках и серверах. 2.Идеальные показатели в тестах SMART 3.badblocks по проблемным физическим дискам — 0 ошибок 4.qemu-img check 0 ошибок 5.В логах qemu 0 ошибок 6.На физическом диске места более чем достаточно

Я не понимаю что еще можно посмотреть и предпринять. Похоже это какой то глубинный глюк в KVM ?

qemu virtio (win guest)

Ubuntu 16.04 — хост. Ставлю на qemu win7:

UPD. Не знаю почему, на выбрав x86 вместо amd64 драйвер vertio, все завелось сразу.

SAMBA прячет файлы

На гипервизор(Gentoo), посредством libvirtd работает виртуальная машина KVM(Gentoo + Samba). ВМ запускается через virt-install с опцией —filesystem /mnt/data. Таким образом с помощью virtio(9p)-драйверов данные с папки /mnt/data гипервизора видны в /mnt/data в гостевой ВМ. ВМ держит только сервис Samba и SSH. Такая связка проработала 1,5 месяца. Теперь начинаются чудеса — Заходим в шару через проводник Windows — видим 439 файлов, через Total Commander на примонтированном диске — 107 файлов, Консоль Windows на примонтированном диске — 693 файла. Идем в shell ВМ или гипервизора — видим порядка 750 файлов.

Еще есть такой эффект: заходим в проблемную шару через проводник и создаем 10 новых папок, жмем F5 и новая папка (2) куда-то исчезла.Но если указать полный путь: //share/новая папка(2) — в папку мы попадем. В это же время через shell ВМ будут видны все созданные папки и файлы. Такое поведение наблюдается только у 2-х расшаренных папок из 10. Настройки идентичны для всех шар, права и владелец идентичны.

В качестве клиентов WinXp, Win7. Делал в linux-клиенте mount -t cifs . и видел порядка 100 файлов.

tcpdump отлавливает много таких вещей :

15:52:23.284757 IP (tos 0x0, ttl 64, id 50856, offset 0, flags [DF], proto TCP (6), length 117) 10.10.10.18.445 > 10.10.10.31.50102: Flags [P.], cksum 0xcc9c (incorrect -> 0x1b4e), seq 178031:178108, ack 5174, win 8196, length 77 SMB-over-TCP packet:(raw data or continuation?)

smb.conf
workgroup = BLABLA
server string = data
server role = member server
hosts allow = 10.10.10. 10.10.11.
log file = /var/log/samba/log.%m
log level = 2
max log size = 50
interfaces = 10.10.10.18/24
dns proxy = no
Machine -d /dev/null -s /bin/false %u

security = user
map to guest = Bad Password
map to guest = Bad User
guest account = nobody
netbios aliases = server1 server2

printcap name = /dev/null
load printers = no
printing = bsd

kernel oplocks = no
nt acl support = no
strict locking = no
acl map full control = yes
os level = 255

name resolve order = lmhosts bcast host
kernel change notify = yes

Шара
path = /mnt/data/folder/share
csc policy = disable
valid users = nobody
public = yes
guest ok = yes
writable = yes
create mask = 0664
directory mask = 0775
level2 oplocks = no
locking = no
strict locking = no
oplocks = no

Источник