Windows VirtIO Drivers

Contents

Introduction

VirtIO Drivers are paravirtualized drivers for kvm/Linux (see http://www.linux-kvm.org/page/Virtio). In short, they enable direct (paravirtualized) access to devices and peripherals for virtual machines using them, instead of slower, emulated, ones.
A quite extended explanation about VirtIO drivers can be found here http://www.ibm.com/developerworks/library/l-virtio.

At the moment these kind of devices are supported:

You can maximize performances by using VirtIO drivers. The availability and status of the VirtIO drivers depends on the guest OS and platform.

Windows OS Support

Windows does not have native support for VirtIO devices included. But, there is excellent external support through opensource drivers, which are available compiled and signed for Windows:

Note that this repository provides not only the most recent, but also many older versions. Those older versions can still be useful when a Windows VM shows instability or incompatibility with a newer driver version.

The binary drivers are digitally signed by Red Hat, and will work on 32-bit and 64-bit versions of Windows

Installation

Using the ISO

You can download the latest stable or you can download the most recent build of the ISO. Normally the drivers are pretty stable, so one should try out the most recent release first.

You can access the ISO can in a VM by mounting the ISO with a virtual CD-ROM/DVD drive on that VM.

Wizard Installation

You can use an easy wizard to install all, or a selection, of VirtIO drivers.

1. Open the Windows Explorer and navigate to the CD-ROM drive.
2. Simply execute (double-click on) virtio-win-gt-x64
3. Follow its instructions.
4. (Optional) use the virtio-win-guest-tools wizard to install the QEMU Guest Agent and the SPICE agent for an improved remote-viewer experience.
5. Reboot VM

Manual Installation

1. Open the Windows Explorer and navigate to the CD-ROM drive. There you can see that the ISO consists of several directories, each having sub-directories for supported OS version (for example, 2k19, 2k12R2, w7, w8.1, w10, . ).
   • Balloon
   • guest-agent
   • NetKVM
   • qxl
   • vioscsi
   • .

Downloading the Wizard in the VM

You can also just download the most recent virtio-win-gt-x64.msi or virtio-win-gt-x86.msi from inside the VM, if you have already network access.

Then just execute it and follow the installation process.

Установка Windows XP с VirtIO драйверами на KVM

Подскажите как это правильно делать и как вообще пользоваться kvm если на сервере нет иксов и соответственно и virt-manager’а. В разной документации предлагают различные варианты и общего понимания как это все должно работать у меня пока нет

нет иксов и соответственно и virt-manager’а

virt-install и vnc.

virt-install. если в лок. сети сервер — как вывод графики юзай spice.

Берешь линукс с иксами и коннектишься с него virt-manager’ом по ssh.

Подскажите как это правильно делать и как вообще пользоваться kvm если на сервере нет иксов и соответственно и virt-manager’а.

virt-manager и не должен быть на сервере. На сервере должен быть libvirt. А virt-manager ты ставишь на клиенте и подключаешься к серверу через ssh (например). Для установки windows сразу на устройства virtio где-то был образ флопика с драйверами, погугли.

у меня на рабочем месте ШИНДОШЗ, поэтому virt-manager можно только с сервера запустить

ну это понятно 🙂 Я просто хочу какое нибудь пошаговое руководство хотя бы. Сейчас я поставил венду так:

В итоге I/O и сеть виртуализированные, VGA не распозналось. В virsh edit нифига не понятно как поменять vga с std на vmware. Ну и с паравиртуализированными драйверами тоже не понятно как теперь поступать

Перестань извращениями заниматься и используй virt-manager так, как мы с mironov_ivan советуем. И да, поставить можно на IDE, а затем поменять его на virtio. Для этого после установки системы надо в нее добавить еще один диск, на этот раз virtio, поставить на него драйверы, потушить оффтопик, удалить диск добавленный и переключить основной с IDE на virtio. Так сложно, потому что оффтопик не умеет ставить дрова на отсутствующие в системе устройства.

у меня на рабочем месте ШИНДОШЗ, поэтому virt-manager можно только с сервера запустить

Хороший повод как минимум завести виртуалку с линуксом, а как максимум — снести нахрен это непригодное для администрирования чего-либо поделие и поставить нормальную ОС.

ребята, что нужно сделать я знаю, у меня другой вопрос — как это сделать. В интернетах предлагается тысяча и одна рекомендация по этому поводу и одна другой противоречит либо просто не подходят. Для начала я хочу что бы кто нибудь рассказал как правильно ставить через virt-install и как потом править конфиг виртуалки. Неужели ни у кого нет историй успеха?

у нас тут так нельзя, к сожалению

Ну тогда остается извращаться с ssh -X

получается все поголовно пользуются virt-manager’ом и руками не настраивают? Мельчают линупсисты 🙂

получается все поголовно пользуются virt-manager’ом и руками не настраивают? Мельчают линупсисты 🙂

Глупости. Ручной труд — признаком «крупного специалиста» не был никогда. Нормальный айтишник стремится все по максимуму автоматизировать.

никакого хардкора и красноглазия

Историю успеха могу подсказать, правда, она для винфака.
Нужно собрать образ оффтопика с unattended setup, впиленными внутрь дровами virtio и скриптом автоподнятия RDP или VNC, тогда можно и virt-install’ом. А ванильный инсталлер оффтопика не подразумевает неинтерактивной работы.

Да, еще можно просунуть наружу VNC виртуалки на внешний адрес сервера и подконнектиться к нему с оффтопика. Либвирт по дефолту их биндит к локалхосту, можно ли заставить слушать на всех интерфейсах, никогда не задумывался, но в качестве говна и палок вполне сойдет ssh-туннель в putty.

Для начала я хочу что бы кто нибудь рассказал как правильно ставить через virt-install

Твой вариант вполне рабочий. Ну, то есть, я ставлю также и всё нормально.

как потом править конфиг виртуалки.

И снова да, virsh edit. Хотя я пользую dumpxml, но разницы быть не должно. И тоже всё работает. Просто не понятно, в чём проблема-то, собственно.

у меня на рабочем месте ШИНДОШЗ, поэтому virt-manager можно только с сервера запустить

Поставь X-сервер на винду [. пока это возможно. А вот как придет сделанная через жопу мечта хомячков на букву «W» — возможности не станет].

Ну и с паравиртуализированными драйверами тоже не понятно как теперь поступать

1. Ставишь на IDE

2. Добавляешь второй диск virtio

3. доставляешь дарйверы

4. меняешь первый диск на virtio

Или — ставишь два виртуальных CD, в один дистрибутив, во второй — драйверы virtio. Их в инсталлере указываешь.

ты вообще в курсе каким образом устанавливается winxp?

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

ок, это понятно. Как это сделать без virt-manager’а?

И снова да, virsh edit. Хотя я пользую dumpxml, но разницы быть не должно. И тоже всё работает. Просто не понятно, в чём проблема-то, собственно.

я так и не раскурил как в virsh edit поменять vga std на vga vmware например

1. Собрать с помощью nlite winxp и интегрировать дрова.
Взять оттуда http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/
2. WinXP может подгрузить дрова только с floppy, тогда скачать vfd образ https://launchpad.net/kvm-guest-drivers-windows/ download
подключить vfd (https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6. ), как floppy и в процессе установки нажать f6 и выбрать драйвер.
Лень сделать вариант 1, поэтому использую вариант 2.

Создать машину virsh’ем, просунуть VNC наружу и дальше все как в virt-manager’е.

Пробовал — выглядит страшно.
Я просто виртуалку поднял в virtualbox с debian minimal с xfce и там уже virt-manager установил, хоть выглядит не как говно.

Ну ТСу запретили видимо в конторе так делать, иначе бы точно не искал приключений на свою пятую точку

Виртуализацией по тарифам. Настраиваем Windows в KVM

Содержание статьи

Плюсы и минусы KVM

Проект KVM (Kernel-based Virtual Machine) в этом году празднует десятилетие. Официально он включен в ядро с версии 2.6.20, выложенное на kernel.org 4 февраля 2007 года. Изначально разрабатывался компанией Qumranet, выкупленной Red Hat в 2008 году. После сделки KVM и библиотека управления виртуализацией oVirt стала основой платформы виртуализации RHEV, поэтому Red Hat на сегодня ключевой разработчик KVM.

Технология предоставляет полную виртуализацию на аппаратном уровне. Поэтому, в отличие от популярных LXC и OpenVZ, KVM может запускать в принципе любую ОС, не только Linux (Windows, FreeBSD. ), и Linux, отличающийся от конфигурации основной системы. Если нужна виртуальная машина, не совпадающая параметрами с основным хостом, то выбора особо нет. Включение в ядро было большим прорывом. Теперь поддержка виртуализации в ОС не требовала установки гипервизора (как Xen) и могла быть реализована в любом дистрибутиве, включая настольный. Из коробки доступен VNC, дающий возможность управлять виртуальным сервером с момента загрузки (то есть когда еще не работает SSH), как будто из локальной консоли. Проект активно сотрудничает с другим подобным решением QEMU, задействованы некоторые утилиты и общий формат файла образа Qcow2.

Минусы, конечно, тоже есть. Куда же без них. Главный — процессор должен иметь аппаратную поддержку виртуализации Intel VT-x или AMD-V. Проверить их наличие можно вручную или при помощи утилит:

Также о поддержке технологий говорят флаги в CPU:

В зависимости от производителя процессора будет загружен свой модуль ядра (kvm-amd.ko либо kvm-intel.ko).

Проверяем поддержку KVM

Xakep #216. Копаем BitLocker

Накладные расходы чуть выше, чем при использовании LXC и OpenVZ. Причин тому две.

KVM-контейнер запускает свою копию ядра и окружения, и под них требуется память. LXC и OpenVZ же используют ядро и системные вызовы сервера. Поэтому при одинаковых характеристиках на хостинге у них совершенно разные возможности. При создании KVM-контейнера под него сразу резервируются все ресурсы согласно установкам. Это хорошо видно в htop. Стоит добавить ОЗУ в KVM, как сразу на это значение увеличивается объем занятой памяти. Выйти за лимиты VM не может, они устанавливаются жестко. В этом даже и плюс, можно сразу рассчитать будущую нагрузку на своем сервере, а ресурсы никто не позаимствует.

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

Администрировать KVM сложнее, так как прозрачный доступ к файлам, процессам, консолям и сети контейнеров отсутствует, это приходится настраивать самостоятельно. Перестройка параметров VM в KVM (CPU, RAM, HDD) не очень удобна и требует дополнительных действий, включающих перезагрузку ОС. В том же OpenVZ это можно сделать на лету. Сам проект не предлагает удобных графических инструментов для управления виртуальными машинами, только утилиту virsh, реализующую все необходимые функции. Но, поискав в Сети, можно найти несколько интерфейсов, хотя для индивидуального использования одной или нескольких VM их обычно ставить нет смысла. К тому же много open source проектов, активно развивавшихся во время большого интереса к виртуальным машинам, сегодня стали коммерческими, хотя некоторые по-прежнему предлагают обрезанную free-версию. В репозитории пакетов есть virt-manager, предлагающий графический интерфейс для управления KVM и другими типами VM, поддерживающими virtlib, как установленных локально, так и удаленно через SSH.

В качестве веб-интерфейсов можно порекомендовать старенький, но еще рабочий WebVirtMgr, бесплатный UVMM UCS Core Edition, openQRM Free Community Edition и другие. Кроме того, существуют специальные дистрибутивы вроде Proxmox VE, в котором все необходимые инструменты для создания и управления VM на базе KVM и LXC уже есть (правда, он подходит для bare metal установки, а не на удаленный VDS).

Установка KVM

Плюсы KVM в том, что она работает из коробки и что процессоры серверов хостеров однозначно поддерживают эту технологию. Поэтому вполне реально при наличии свободных ресурсов подгрузить в VDS еще одну виртуальную машину (или несколько). Конечно, под фактически двойной виртуализацией они будут работать не так быстро, как на железе, но если большая нагрузка не планируется, то этого вполне должно хватить. Более того, у некоторых хостингов есть rescue-инструменты, дающие возможность подмонтировать другую файловую систему (в hetzner это rescue/LARA ), подменить имеющуюся и даже установить свою ОС. При некотором умении можно по тарифам Linux абсолютно легально использовать Windows.

Наша задача — установить под KVM Win и настроить доступ. KVM работает со всеми версиями Win, включая и последние. Но Win капризней к ресурсам, поэтому тариф следует подбирать с учетом минимальных системных требований и накладных расходов на ОС и виртуализацию. На Digital Ocean, например, Win2012R2 при 4 Гбайт ОЗУ сильно тормозит, а если выделить 6+ Гбайт, то уже вполне нормальный отклик. В различных дистрибутивах и даже версиях процесс немного отличается, но в основном это касается названий пакетов. Мы будем использовать Ubuntu 16.06. Ставим пакеты.

Проверяем поддержку KVM.

Если такой ответ получен, значит, все нормально. Список поддерживаемых ОС и их правильное название можно получить при помощи osinfo-query .

Список поддерживаемых ОС и их названия

Конфигурационные файлы libvirt находятся в каталоге /etc/libvirt , журналы, в которых нужно искать ответы на проблемы, размещаются в /var/log/libvirt . В /var/lib/libvirt несколько каталогов: в boot система, если не указан путь, будет искать образ для установки гостевой системы, а в images размещать жесткие диски.

Управление виртуальными машинами из консоли производится при помощи утилиты virsh . Параметров много, их все можно узнать, введя:

Вначале просто стоит пройтись и познакомиться, чтобы понять суть. Список ОС пока пуст:

Проверяем, что сеть настроена. По умолчанию используется default (подробнее дальше по тексту).

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

И перезагружаем модули:

Еще один момент. Для работы Win потребуются паравиртуальные драйверы virtio, которые реализуют работу основных устройств в виртуальном окружении. Они не обязательны, но их использование позволяет достичь большей производительности и отзывчивости в работе виртуальных окружений. Они должны поддерживаться как хостом, так и гостевой ОС. В ядре Linux драйвер поддерживается с 2.6.25, но модуль по умолчанию не ставится. Если вызов /sbin/lsmod | grep virtio и cat «/boot/config- uname -r » | grep -i virtio ничего не показал, следует установить пакет qemu-guest-agent. Для гостевой ОС ISO-образ доступен на fedoraproject.org.

Далее два варианта. Можно самостоятельно установить операционную систему или взять уже готовый образ с установленной ОС. Первый шаг в общем отличается тем, что нужно подготовить диск, запустить VM и установить ОС стандартным способом. Создадим диск размером 25 Гбайт.

Если в будущем нужно изменить размер диска, то используется команда resize:

Некоторые параметры очевидны, поэтому кратко:

• name — имя, по которому можно обращаться к VM;
• ram и vcpus — количество памяти и vCPU, выделяемых VM;
• disk — имя диска, формат и драйвер;
• cdrom — виртуальный CD-ROM, здесь указан ISO-образ, с которого будет загружаться система;
• network — сетевое подключение, тип и модель (можно использовать virtio, но бывают проблемы, потом можно сменить);
• os-type и os-variant — тип ОС.

Параметр —vnc имеет смысл только на сервере без GUI, при наличии интерфейса KVM сразу откроет окно через SDL. Также можно подключиться локально при помощи virsh:

Удаленно также можно зайти с использованием любого VNC-клиента, при необходимости используя port forwarding (см. ниже).

Коннектимся к Windows, запущенной под KVM

После установки ОС можно приступать к работе. Второй вариант позволяет использовать уже готовый диск с установленной ОС. Его можно скопировать с готовой системы, сконвертировать при помощи qemu-img convert, которая поддерживает форматы дисков практически всех систем виртуализации. Или взять с сайта проекта Cloudbase.

Запуск почти не отличается от предыдущего, убираем, если не нужен, cdrom и добавляем —import .

В дальнейшем можно управлять поведением VM при помощи virsh start|reboot|shutdown|suspend|resume|destroy|undefine|edit|autostart|info и так далее.

Настройки VM хранятся в отдельных XML-файлах в каталоге /etc/libvirt/qemu , имя соответствует параметру —name . Можно их просмотреть, отредактировать при необходимости, скопировать при помощи virsh. Например, нужно изменить настройки сетевого адаптера.

Скопируем настройки в файл.

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

Настройки виртуальной машины

Сеть в KVM

Настройка сети — самый важный момент при работе с KVM. По умолчанию используется Usermode или default, когда базовая система работает как маршрутизатор между внешней и гостевой сетью. Гостевая ОС может получать доступ к внешним сетевым сервисам, но не видна из сети. IP выбирается автоматически при помощи DHCP из диапазона 192.168.122.0/24 , интерфейс основной ОС всегда имеет IP 192.168.122.1 . Для доступа к сервисам нужно самостоятельно настроить маршрутизацию. После установки libvirtd должен создать ряд NAT-правил iptables .

Правила iptables после установки KVM

Второй вариант — Bridged, когда интерфейс гостевой ОС привязывается к физическому интерфейсу и VM доступна извне без допнастроек. Этот вариант чуть сложнее в настройках, так как из-за перестроек можно потерять SSH-подключение. Поэтому при отсутствии локальной консоли (Java/веб-аплета у провайдера) пользоваться им нужно только после тщательного тестирования, и мы его рассматривать не будем.

В первом варианте удобнее настроить KVM так, чтобы она назначала гостевой системе один и тот же IP-адрес. Это можно сделать прямо в конфигурационном файле /etc/libvirt/qemu/networks/default.xml или вызвав

Далее добавляем параметр host в секции dhcp :

Редактируем сетевые настройки для виртуального хоста

И так для каждого узла. После чего перезапускаем сеть.

Теперь можем указать маршрут к сервису в основной системе:

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

Изменить эту ситуацию можно несколькими способами: добавив параметр —vnc,listen=0.0.0.0 и при необходимости указав другой порт —vncport 5901 .

Аналогичные настройки есть в сетевых установках хоста.

Чтобы не менять установки для каждой VM, проще изменить это поведение глобально:

Заключение

Ну вот, собственно, мы имеем Windows, запущенную внутри Linux. Конечно, рассматривать KVM для локальной установки, где сильны позиции у VirtualBox и VMware Workstation, не стоит, но при наличии свободных ресурсов на VDS можно быстро развернуть еще одну машину. Скорость, конечно, будет невелика, но для небольших тестов вполне достаточная.