Тормозит виртуальная машина kvm

Обновлено: 08.07.2024

Я заметил несколько статей, в которых утверждалось, что QEMU медленнее VirtualBox (без аппаратной помощи), но несколько лет, а новейший, похоже, был с прошлого года.

Это правда, что QEMU медленнее VirtualBox?
Если да, то почему?
есть ли какие-либо трюки, чтобы закрыть разрыв производительности?

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

Если вы говорите о x86-виртуализации на x86-хосте, имейте в виду, что kqemu (старый модуль ядра ускорения для qemu) устарел. Kernel Virtual Machine (KVM) - это "путь вперед", но он работает только на хостах Linux. Гостевая ОС может быть любой, если это архитектура x86.

Кросс-архитектура, qemu все еще очень медленный; только сегодня я пробовал последний qemu с Debian MIPS64 в гостевой системе. он был пригоден для использования с терминала, но ужасно медленный Файл xorg. насколько мне известно, вы не можете использовать инструкции по ускорению процессора, такие как расширенные таблицы страниц или VT-x, когда собираетесь использовать кросс-архитектуру. Все это эмулируется в программном обеспечении.

таким образом, для x86-x86 виртуализации" raw " qemu работает медленно, но KVM (which использует qemu) быстро. Достаточно быстрый. Настолько быстро, что это рекомендуемое решение виртуализации Red Hat для RHEL.

VirtualBox все еще сдувает все, что qemu / kvm может предложить с точки зрения производительность 2d/3d графики с аппаратным ускорением, поскольку kvm фокусируется на виртуализации серверов, а virtualbox - на виртуализации рабочих столов. Но я определенно рекомендую вам проверить kvm, если вы имеете дело с сервером.

Edit: для ваших хостов, у которых нет аппаратного ускорения, вы будете страдать от довольно больших накладных расходов, независимо от того, какое решение virt вы используете. Эмуляция аппаратных средств в программном обеспечении трудна и дорога.

предполагая, что хост с процессором, поддерживающим виртуализацию (Intel VT-x, AMD SVM), работает Qemu на ядре (Linux с KVM), это достаточно быстро.

технические причины медленной работы Qemu с 2D (youtube, spreadsheet, games) и 3D эмуляцией мне неизвестны. Тем не менее, я могу предположить, что "видеодрайверы" просто недостаточно хороши - графическое оборудование в оборудовании не используется оптимальным образом.

на яркой стороне, недавнее развитие ввел рамки специи к qemu. На самом деле это несколько лет и кажется достаточно зрелым. Преимущества видео-представления бежать с видео-водителем QXL огромны в моем опыте (2D веб-разработке). Я не знаю, насколько хорошо он сравнивается с Virtualbox, но это определенно улучшение. Я думаю, что SPICE является обязательным для тех, кто работает под управлением Windows в Qemu.

Это исключительно мое мнение, и следует отметить, что я никогда даже не пытался запустить воспроизведение 3D или видео в гость.

Примечание: Данная статья демонстрирует вариант оптимизации, который заметно увеличивает производительность в конкретном случае. Представленные результаты тестирования не претендуют на точность, их основная цель продемонстрировать наличие эффекта от применения описываемых оптимизаций.

Содержание.

Вступление.

Windows 10 чрезвычайно тяжёлая ОС с множеством активных служб, вызывающих пилообразную нагрузку и огромное количество прерываний, поэтому без оптимизации работы виртуальной машины не обойтись.

Программы для тестирования.

Данный нехитрый набор достаточен для оценки производительности гостевой ОС Windows.

— предназначена для измерения задержек прерываний. Чем выше задержки, тем сильнее проявляются «заикания», включая потрескивание звука. — тестирование производительности процессора. — тестирование 3D производительности. — тестирование 3D производительности.

Пример результатов тестирования без оптимизации.

Cinebench.

После оптимизации результат улучшится на

Unigine Superposition.

После оптимизации результат улучшится на

Unigine Valley.

После оптимизации результат улучшится на

Переключение процессора в режим производительности.

Зашкаливающие задержки прерываний выглядят подобным образом:

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

Настройка режима производительности процессора.

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

Вывести доступные режимы:

В выводе будет подобное:

Проверить режим работы процессора:

Скорее всего, в выводе будет ondemand — сбалансированный режим. Его необходимо переключить на режим performance.

Переключение можно осуществить следующей командой:

Вот и всё. С performance в гостевой ОС не будет заиканий и треска при проигрывании звука.

Важный нюанс для Ubuntu.

На момент 2021 года в Ubuntu и её деривативах всё ещё присутствует демон ondemand, который не следует путать с режимом управления частотой процессора. В стародавние времена он служил для динамичного управления энергосбережением, а ныне в нём нет надобности. Если этот демон включён, то после перезагрузки хоста вновь будет включен режим ondemand, а не ранее включенный performance.

Стоит проверить активен ли демон ondemand:

Если выключен, то вывод будет таким:

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

После этого режим performance не будет переключаться на ondemand после перезагрузки.

Предварительный результат улучшения производительности.

Только за счёт переключения режима управления частотой процессора удалось получить более 15% к производительности ядер для виртуальной машины:

Для 3D графики результат скромнее, но эффект хорошо заметен.

Было: 8695 очков. Стало: 8776.

Было: 3457. Стало: 3790.

Пример настроенной конфигурации.

Отключение memballoon.

По конфигурации начнём с конца и по совместительству самого простого.

Memballoon — специальный драйвер, который обеспечивает подкачку памяти для гостевой ОС, если исчерпывается выделенная память.

Для поддержки memballoon в Win10 нужен специальный драйвер, который лишний раз укажет на факт виртуализации, который так старательно маскировали в предыдущей статье. Ко всему прочему драйвер ранее вызывал проблемы при совместном использовании с vfio, служащего для проброса видеокарты. Поэтому оптимальнее выключить.

Отключение осуществляется через редактирования конфигурации виртуальной машины. Конфигурация membaloon находится в блоке devices:

По умолчанию блок с memballoon выглядит подобным образом:

Блок с выключенным memballoon выглядит так:

На этом по memballoon всё.

Настройка дисковых устройств.

Конфигурация дисковых устройств находится в блоке devices.

Пример настроенной конфигурации:

Разбор первой строки:

Разбор второй строки:

Разбор третьей строки:

Разбор четвёртой строки:

В пятой строке оптимальны значения по умолчанию.

Настройка SPICE.

В предыдущей статье для управления виртуальной машиной был выбран протокол SPICE. В данном случае виртуальная машина запускается на локальном компьютере, а по умолчанию конфигурация SPICE больше рассчитана для удалённого доступа. Поэтому следует настроить для локального применения.

По умолчанию конфигурация выглядит подобным образом:

Отключение прослушки сети и сжатия пакетов заметно снижает уровень задержек. Оптимизированная конфигурация выглядит так:

CPU Pinning — vcpupin.

Это прикрепление (pinning) потоков физического процессора к логическим ядрам виртуальной машины (vcpu). Благодаря прикреплению, обработка процессов виртуальной машины будет иметь несколько более высокий приоритет, что заметно снизит задержки прерываний. По умолчанию нагрузка логических ядер виртуальной машины распределяется между всеми потоками физического процессора. В виду того, что системе необходимо налету балансировать распределение ресурсов процессора между хостом и виртуальной машиной, время задержек прерываний для ряда задач может быть не оптимальным. Если наблюдается недостаточная отзывчивость гостевой ОС и проявляется потрескивание (заикание) звука, то стоит попробовать прикрепить потоки к логическим ядрам виртуальной машины.

Структура потоков процессора.

Перед прикреплением потоков к виртуальной машине необходимо ознакомиться со структурой логических ядер (потоков) физического процессора. У Intel и AMD она различается. В данном примере будет рассмотрен вариант с Intel.

Со структурой можно ознакомиться при выводе возможностей хоста с помощью утилиты virsh:

Будет отображён большой вывод с xml-структурой. В нём показаны возможности хоста в той же компоновке, как в xml-конфигурации виртуальной машины. Пример части вывода для системы с процессором Intel i7 6800K (12 логических ядер):

Информация о структуре потоков находится в блоке <cpus>:

В современных процессорах используется технология гиперпоточности. Её особенностью является то, что одно физическое ядро предстаёт в виде двух логических ядер (потоков), что позволяет распределить вычислительную нагрузку более оптимально.

В данной статье в качестве примера рассматривается Intel i7 6800K с шестью физическими ядрами, что с гиперпоточностью даёт двенадцать логических ядер (потоков). Каждое логическое ядро относится к конкретному физическому ядру. Отсчёт логических ядер начинается от 0.

Из иллюстрации следует, что для шести физических ядер (core_id) используется двенадцать логических ядер (cpu id), тем самым каждому физическому ядру родственны по два потока:

Логическое ядро cpu относится к первому физическому ядру core_id=0, которому принадлежат потоки 0 и 6.
Второе логическое cpu к физическому core_id=1 с потоками 1 и 7.
Третье cpu — core_id=2 с потоками 2 и 8.
Четвёртое cpu — core_id=3 с потоками 3 и 9.
Пятое cpu — core_id=4 с потоками 4 и 10.
Шестое core_id=05 — core_id=5 с потоками 5 и 11.
Седьмое логическое ядро cpu снова относится к первому физическому ядру core_id=0 с теми же родственными потоками —0 и 6. Далее аналогично.
Восьмое core_id=7 — ко второму core_id=1.
Девятое core_id=8 — к третьему core_id=2.
Десятое core_id=9 — к четвёртому core_id=3.
Одинадцатое core_id=10 — к пятому core_id=4.
Двенадцатое core_id=11 — к шестому core_id=5.

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

Примечание: Структура потоков у Intel и AMD отличается. У AMD они идут один за другим. Пример: первое физическое ядро — потоки 0 и 1; второе ядро — 2 и 3 и так далее.

Так же структуру потоков можно вывести следующей командой:

Столбец CPU— перечислены номера (id) логических ядер. Отсчёт от 0.
CORE— номера физических ядер, к которым относятся логические ядра. В виду того, что на одно физическое ядро приходится два логических ядра (потока), номер (id) в столбце повторяется.

Субъективно, такой вывод существенно менее очевиден, поэтому рекомендую первый метод.

Прикрепление потоков к виртуальным логическим ядрам виртуальной машины.

Прикреплённые потоки процессора не становятся изолированными для использования хост-системой. По умолчанию для логических ядер виртуальной машины (vcpu) задействованы все потоки хоста.

Для 8 логических ядер виртуальной машины это выглядит так:

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

Примечание: В старых версиях qemu-kvm для Windows-гостей рекомендовалось обратное — прикреплять потоки от начала. Это было связано с программными недоработками, приводившими к сильному падению производительности виртуальной машины с Windows. Но в поздних версиях qemu-kvm эта проблема устранена.

В данном случае рассмотрен вариант, в котором для хост-системы оставлено четыре потока:

Первое физическое ядро: 0 и 6.
Второе физическое ядро: 1 и 7.

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

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

Прикрепление осуществляется в блоке cputune. Настроенная конфигурация выглядит так:

В данном примере для виртуальной машины выделено 8 потоков из 12.

Далее по аналогии.

На этом заканчивается самое соновное о прикреплении потоков физического процессора к логическим ядрам виртуальной машины.

Аппендикс об iothread.

В ряде публикаций можно увидеть прикрепление потоков для iothread. Это обработчик ввода-вывода для накопителей. В данном случае используется драйвер SATA, а iothread работает только с драйверами virtio-scsi и virtio-blk, поэтому в нём нет нужды.

Настройка планировщика.

Предпочтительным является режим FIFO (First In-First Out). Сразу стоит оговориться, что для ряда задач это может наоборот ухудшить время задержек прерываний, поэтому следует применять с осторожностью.

Настроенный вариант выглядит так:

Настройка таймеров.

Ознакомительный материал:

По умолчанию блок с таймерами имеет подобный вид:

Настройка.

Вывести доступные для использования системные таймеры:

В выводе будет подобное: tsc hpet acpi_pm

Проверить какой таймер используется хостом:

В выводе будет tsc.

Настроенный вариант имеет следующий вид:

Добавлены следующие строки:

По таймерам почти всё, остаётся ещё один момент.

Настройка hugepages.

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

Перед началом настройки стоит убедиться, что выделение больших страниц включено на уровне ядра:

Настройка конфигурации.

nosharepages — не распределять выделенные страницы в пользу других запущенных виртуальных машин.

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

Динамичное выделение больших страниц.

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

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

Проблема может проявляться с выделением страниц объёмом на половину и более доступной памяти. Пример: всего 32 Гб, требуется выделить 8192 страницы по 2 Мб, но по факту система сможет выделить немногим более 6000.

Поэтому, если требуется гарантированное выделение страниц, его нужно осуществлять при старте системы, когда ещё нет фрагментации памяти. Такое выделение называется статичным, но о нём позже.

Проблему динамичного выделения больших страниц можно снизить следующими способами:

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

Пример выделения динамичных больших страниц с синхронизацией и сбросом кэша.

Синхронизировать и сбросить кэшированные записи на накопитель:

Сбросить Page Cache, Dentry и Inode cache, что позволит выделить больше оперативной памяти в виде больших страниц:

Это не деструктивная операция. Будет сброшено лишь то, что не используется.

Скомпоновать память таким образом, чтобы свободная память была в смежных блоках, что снижает фрагментацию и позволяет выделить больше страниц:

Выделить 8192 страницы по 2 Мб, чтобы задействовать 16 Гб ОЗУ в пользу виртуальной машины:

Проверить сколько страниц было выделено фактически:

Статичное выделение больших страниц.

Чтобы избежать проблемы с не выделением всех запрашиваемых больших страниц из-за фрагментации памяти, их можно гарантированно выделить при старте хост-системы.

Выделение осуществляется через передачу значения специальному параметру ядра. Передать значение на старте системы можно посредством Grub. Для этого потребуется внести изменения в файл /etc/default/grub.

Необходимо добавить в строку GRUB_CMDLINE_LINUX_DEFAULT параметр hugepages=8192. Пример:

Затем обновить конфигурацию Grub:

Тем самым после перезагрузки системы будет выделено 8192 страницы по 2 Мб, что по итогу зарезервирует 16384 Мб оперативной памяти, но для использования хост-системой эта память будет недоступна, её сможет использовать только виртуальная машина.

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

На этом завершается разбор основных вариантов оптимизации работы виртуальных машин с упором на виртуализацию ОС Windows 10.

Основная система KDE Neon 5.18.
Виртуальная машина Win 7 х64 на KVM (QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.22))
Машину запускаю через virt-manager на основной машине, ВМ физически находится здесь же.
На ВМ выделено 4 Гб ОЗУ, 40 Гб ПЗУ, 2 ядра.
Проблема в том, что курсор двигатся с тормозами с самого момента установки системы. Сама винда работает нормально, без подвисаний, клавиатура тоже.
В реале мышь USB, а в виртуалке определяется как PS/2.

На ВМ выделено 4 Гб ОЗУ, 40 Гб ПЗУ, 2 ядра.

А по графону? Или как там в QUEMU с графикой?
Была такая фигня в коробке, когда видеопамяти мало задал.

Гостевые дрова поставил?

Win7 как раз последняя версия, которая в KVM должна нормально работать. Если бы это была 10ка или 8ка, то ответом было бы: «так и должно быть». Вин10 в kvm работает хуже, чем в виртуалбоксе.

Midael ★★★★★ ( 21.02.20 21:49:24 )
Последнее исправление: Midael 21.02.20 21:49:57 (всего исправлений: 1)

Какой видео контроллер выбран?

Выбери qxl и установи драйверы.

Видео стоит QXL. Я не пока не понял, в этой вкладке «Видео» в настройках ВМ, пишет ОЗУ: 16 MiB, наверное, подразумевается видео-память. Хотя при запуске «virsh edit» пишет:

vram=‘131072’ это уже я прописал со значения ‘65536’, правда, не помогло. А драйвера гостевые пока не ставил. Только разбираюсь, как это делается.

Устройство ввода поставьте USB Graphics Tablet.

Лучше выкладывать сразу весь конфиг в первом посте.

i586 ★★ ( 22.02.20 06:12:19 )
Последнее исправление: i586 22.02.20 06:19:18 (всего исправлений: 1)

Устройство ввода поставьте USB Graphics Tablet.

Технология предоставляет полную виртуализацию на аппаратном уровне. Поэтому, в отличие от популярных 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

Накладные расходы чуть выше, чем при использовании 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 (подробнее дальше по тексту).

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

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

Далее два варианта. Можно самостоятельно установить операционную систему или взять уже готовый образ с установленной ОС. Первый шаг в общем отличается тем, что нужно подготовить диск, запустить 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 хранятся в отдельных 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 можно быстро развернуть еще одну машину. Скорость, конечно, будет невелика, но для небольших тестов вполне достаточная.

Читайте также: