Kvm подключение физического диска

Обновлено: 06.07.2024

Для начала устанвки и настройки у вас уже должна быть готова ОС. Причем для установки гостевых ВМ разной разрядности (32 или 64), хост-сервер (физический сервер, на котором и будем устанавливать KVM вместе с ВМ) должен быть именно с 64-битной ОС.
Все действия выполняются из-под пользователя root.

Итак, приступим к руководству.

1. Шаг — Подготовка

Посмотрим информацию по процессору

1. HT — Hyper-Threading support
Реализация технологии одновременной мультипоточности. Технология увеличивает производительность процессора при определённых рабочих нагрузках. Если включена, то система определяет два логических процессора на один физический процессор (ядро). Присутствует исключительно в сериях процессоров Intel Xeon, Pentium 4, Atom, Core i3, Core i5, Core i7.
2. LM — Long Mode (x86-64 support)
Грубо говоря, если указана, процессор выполнен по 64-битной технологии (также имеет названия: x86-64, x64, AMD64, Intel64, EM64T). Это расширение архитектуры x86 с полной обратной совместимостью. В процессорах Intel поддержка появилась с поздних Pentium 4, у AMD — c Athlon64.
3. VMX (Intel), SVM (AMD) — Hardware virtualization support
Поддержка процессором технологий Intel VT-x или AMD-V означает наличие дополнительных инструкций для предоставления прямого доступа к ресурсам процессора из гостевых систем. Позволяет приблизить производительность гостевых систем к реальным и сократить затраты производительности на поддержание хостовой платформы. В настоящий момент Virtual Machine Extensions поддерживается во многих процессорах Intel & AMD, хотя подобные расширения имеют и другие процессорные архитектуры, например, Cell.
4. SSE*, SSSE*, XMM*, 3DNow!, MMX и пр.
Различные наборы инструкций для процессоров. Широко используются компиляторами в целях оптимизации кода под конкретную архитектуру.
5. AES — Intel Advanced Encryption Standard
Этот довольно спорный набор инструкций увеличивает производительность при кодировании/декодировании AES, присутствующий только у серии Intel Xeon. Часто используется фанатами Intel для подкрепления крутизны серверной линейки CPU, хотя довольно известен тот факт, что процессоры AMD более сильны в криптовании данных, например, в алгоритме SHA.

Проверяем, поддерживает ли CPU аппаратную виртуализацию:

Если вывод не пустой и искомые флаги подсвечены цветом, значит — процессор поддерживает аппаратную виртуализацию.

Кому интересно, все действия выполнялись на конфигурации Intel Xeon Quad Core E3-1230 3.20 GHz / 8GB / 2x 1TB.

Устанавливаем KVM и библиотеки виртуализации:

теперь нужно вклчючить возможность форвардинга и проксирования arp запросов

добавим в /etc/sysctl.conf

Запускаем сервис KVM

Смотрим, загружен ли модуль KVM

Должны получить вывод:

В данном случае видим, что загружен модуль kvm_intel, так как произволитель CPU — Intel.

Проверка подключения к KVM

Должны получить вывод:

2. Шаг — Создание хранилища для виртуальных машин (Storage Pool)

приводится описание, как настроить хранилище разных видов.
В рассматриваемом же примере описан простой тип хранилища — для каждой ВМ создается свой файл *.img под виртуальный жесткий диск (или диски — если добавить их несколько), размещены они будут в директории /guest_images.
Только у нас эта директория будет точкой монтирования отдельного жесткого диска хост-сервера, специально отведенного для этих нужд.
Безопасность сохранения данных и то, что нужно создавать как минимум зеркальный raid массив, чтобы не потерять данные ВМ в случае сбоя жесткого диска, мы не будем, так как это — отдельная тема.

Просмотрим список физических дисков на хост-сервере:

На жестком диске sda установлена ОС, его не трогаем, а вот на sdb создаем раздел на все свободное место диска с файловой системой ext4:
(более подробно про следующие операции можно почитать

Выбираем диск для редактирования

Создаем новый раздел

Создаем файловую систему ext4 на всем свободном месте диска /dev/sdb

Создаем точку монтирования нашего жесткого диска для файлов виртуальных машин:

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

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

После этого снова:

Отредактируем файл /etc/fstab для того, чтобы при перезагрузке хост-сервера раздел с ВМ монтировался автоматически

Добавляем строку по примеру тех, что уже имеются в файле

Сохраняем файл и продолжаем создание хранилища:

Проверяем, создалось ли оно:

Добавляем в автозагрузку:

3. Шаг — Настройка сети на хост-сервере

. ВАЖНО.

Положим, что для выхода «в мир» использовался интерфейс eth0 и он был соответствующим образом настроен.
На нем настроен IP-адрес 10.110.10.15 из /24 сети, маска — 255.255.255.0, шлюз 10.110.10.1.
Продолжаем, создаем сетевой интерфейс типа «bridge» на хост-сервере

. Важно.
DEVICE=«eth0» Имя интерфейса должно остаться таким, как было в системе. Если у вас для выхода в Интернет использовался интерфейс eth1, тогда редактировать надо его.

Когда проверили все, перезагружаем сеть:

Проверяем состояние подключения типа «bridge»:

Получаем что-то вроде этого

Делаем настройки в iptables, чтобы трафик виртуалок «ходил» через соединение типа bridge

Опционально: можно улучшить быстродействие соединения bridge, поправив настройки в /etc/sysctl.conf

4. Шаг — Установка новой виртуальной машины

Установка CentOS на гостевую ВМ:

Примечание 1:
VMName_2 — имя новой виртуальной машины
–ram 1024 — кол-во виртуальной памяти
–arch=x86_64 — архитектура ОС виртуалки
–vcpus=1 — кол-во виртуальных процессоров
–os-type linux — тип ОС
–disk pool=guest_images_dir,size=50 — размещение хранилища, размер вирт. диска
–network=bridge:br0

Установка Windows на гостевую ВМ:

Примечание:
Параметры такие же, как и в примере с установкой CentOS. Но есть различия.
При установке ОС Windows не увидит виртуального жесткого диска, поэтому надо подгрузить дополнительный виртуальный cdrom с драйверами /iso/virtio-win.iso — расположение файла ISO с драйверами виртуального диска. Взять можно отсюда.

Выполняем команду на установку новой ВМ, затем подключаемся по

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

При установке новой ВМ, порт vnc-сервера увеличится на 1. При удалении ВМ, порт освобождается,
и затем выдается новой ВМ. То есть, номер порта последней ВМ не обязательно самый большой из 590…
Чтобы узнать, на каком порту vnc виртуалка с определенным названием, вводим:

где VMName_1 — имя ВМ, :3 — номер по порядку порта, начиная с 5900, то есть подключаться надо на порт 5903, но в программе UltraVNC сработает и так 10.110.10.15:3

Примечание
Если при создании ВМ вылетает ошибка Permission denied, kvm не может открыть файл диска ВМ *.img,
значит, надо разрешить выполнение действий qemu-kvm из-под root (предполагается, что управление
ВМ производится из-под специально созданного для этих целей пользователя, например, libvirt). Но мы обойдемся и пользователем root.

Находим и раскомментируем в нем строки:

Полезно знать:
Конфиги ВМ находятся здесь /etc/libvirt/qemu/
Для того, чтобы отредактировать параметры (добавить процессор, ОЗУ или еще что-то),
ищем конфиг ВМ с нужным названием, редактируем:

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

Теперь у этой ВМ порт vnc будет — 5914. Не забудьте перезагрузить libvirtd для применения изменений. Саму ВМ тоже следует перезагрузить. Поэтому изменяйте конфигурационный файл ВМ пока она выключена, далее выполняйте service libvirtd reload, затем стартуйте ВМ.

Команды для управления ВМ:

5. Шаг — Настройка сети в случае «серых» IP-адресов в ВМ

Здесь 10.110.10.15 — белый (внешний) IP хост-сервера. 192.168.122.170 — серый IP-адрес гостевой ОС.

На примере установки ОС CentOS на гостевой машине, когда установка перешла в графический режим, и предлагает подключиться на локальный порт 5901 гостевой ОС.
Подключаемся из ПК, за которым сидите, по vnc к 10.110.10.15:5910 или 10.110.10.15:10 тоже сработает в UltraVNC.

По такому же принципу можно прокинуть порт (стандартный) RDP 3389 или SSH 22 в гостевую ОС.

6. Шаг — Подготовка к управлению виртуальными машинами удаленного сервера с удобным графическим интерфейсом (используя virt-manager)

Есть много способов «прокинуть» графику удаленного сервера на ПК, за которым выполняете действия администрирования. Мы остановимся на ssh-туннелировании.
Положим, что вы выполняете действия с локального ПК под управлением Windows (в операционных системах под управлением Linux сделать это куда легче :), нужно выполнить всего одну команду ssh -X username@12.34.56.78, конечно, с оговоркой, что на удаленном сервере X11 forwarding разрешен и вы сидите за локальным Linux ПК c графической оболочкой), тогда нам необходимо

В момент подключения к удаленному серверу Xming должен быть уже запущен.
На хост-сервере с CentOS для SSH включить X11 Forwarding, для этого отредактируйте файл sshd_config:

Устанавливаем virt-manager на хост-сервере:

Еще один компонент

7. Шаг — Непосредственный запуск virt-manager

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

KVM (или Kernel-based Virtual Machine) — это программное решение, обеспечивающее виртуализацию в среде Linux на платформе x86, которая поддерживает аппаратную виртуализацию на базе Intel VT (Virtualization Technology) либо AMD SVM (Secure Virtual Machine).

Устанока и настройка (qemu-kvm libvirt-bin)

Установка

Проверяем, поддерживает ли CPU аппаратную виртуализацию:

Если вывод не пустой, значит — процессор поддерживает аппаратную виртуализацию. Кому интересно, все действия выполнялись на конфигурации Intel Xeon Quad Core E3-1230 3.20 GHz / 8GB / 2x 1TB.

Устанавливаем KVM и библиотеки виртуализации:

Запускаем сервис KVM

Смотрим, загружен ли модуль KVM

Должны получить вывод:

В данном случае видим, что загружен модуль kvm_intel, так как произволитель CPU — Intel.

Проверка подключения к KVM

Должны получить вывод:

Настройка

Просмотрим список физических дисков на хост-сервере:

На жестком диске sda установлена ОС, его не трогаем, а вот на sdb создаем раздел на все свободное место диска с файловой системой ext4: (более подробно про следующие операции можно почитать здесь)

Выбираем диск для редактирования

Создаем новый раздел

Создаем файловую систему ext4 на всем свободном месте диска /dev/sdb

Создаем точку монтирования нашего жесткого диска для файлов виртуальных машин:

Многие советуют отключить вообще Selinux, однако мы выберем иной путь. Мы настроим его правильно.

После этого снова:

Смонтируем раздел /dev/sdb1 в /guest_images

Как добавить дополнительное дисковое хранилище в гостевую ОС на виртуальную машину KVM с командой virsh в операционной системе Linux?

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

Ниже приведены шаги по добавлению файлового хранилища (образа диска) в виртуальную машину с помощью команды virsh в Linux:

Шаг 1 – Создайте новый образ диска

Введите следующую команду на хосте KVM для создания нового образа диска под названием ubuntu-box1-vm-disk1-5G с размером 5G:

Или вы можете использовать команду dd для создания предварительно выделенного файла, для этого выполните:

Вы только что создали команду qemu-img или dd для создания нового необработанного образа диска размером 5 ГБ. Образ диска называется ubuntu-box1-vm-disk1-5G :

Примеры возможных выводов данных:

Некоторые замечания относительно формата qcow2

Шаг 2 – Прикрепите диск к виртуальной машине

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

Примеры возможных выводов данных:

Таким образом, моя виртуальная машина имеет /dev/vda с размером 40 ГБ. Чтобы подключить вновь созданный образ ubuntu-box1-vm-disk1-5G , вы должны использовать /dev/vdb . Если у вас уже есть диск /dev/vdb , вам нужно изменить vdb на свободное устройство, например /dev vdc , и так далее. Чтобы прикрепить диск к виртуальной машине, под названием ubuntu-box1 используйте следующий синтаксис.

Примеры возможных выводов данных:

Будьте Осторожны : С помощью всего нескольких нажатий клавиш fdisk может уничтожить часть или весь ваш жесткий диск или рабочий раздел. Убедитесь, что вы используете правильные имена устройств с помощью команды fdisk.

Шаг 3 – Разбиение диска на виртуальной машине

Теперь у гостя с именем «ubuntu-box1» есть устройство на жестком диске, называемое /dev/vdb . Зайдите в вашу виртуальную машину и введите следующую команду для проверки того же самого:

Примеры возможных выводов данных:

Затем запустите fdisk для нового устройства:

Введите n для нового раздела. Введите p для основного раздела. Выберите номер доступного раздела 1. Введите первый цилиндр по умолчанию, нажав Enter. Выбрать весь диск можно, нажав Enter. Наконец, введите p для проверки нового раздела. Введите w, чтобы записать изменения и выйти. Пример сеанса из команды fdisk.

Рисунок 01: Разделение диска с помощью команды fdisk на виртуальной машине.

Чтобы отформатировать новый раздел с файловой системой ext4, введите:

Примеры возможных выводов данных:

Рисунок 02: Форматирование /dev/vdb1 как ext4

Наконец, вам нужно создать монтируемую директорию:

И смонтируйте диск для гостя:

Отредактируйте файл /etc/fstab

И обновите его следующим образом, чтобы /dev/vdb1 постоянно монтировались после перезагрузки:

Сохраните и закройте файл. Теперь у вас есть гостевая виртуальная машина, которая имеет дополнительное виртуализированное файловое хранилище в системе на базе KVM Linux.

Иногда я берусь за различные задачи по настройке серверов. Некоторое время назад ко мне обратился владелец небольшой хостинговой компании, с интересной проблемой. Он хотел бы на своих серверах, где уже стоял Ubuntu 18.04, запускать виртуальные машины с Windows под KVM.

Однако проведённое им тестирование показало, что дисковая система KVM прилично отставала от показателей, которые у него были под Hyper-V. Он хотел раскочегарить qemu на своих Ubuntu серверах, чтобы избежать закупок дорогих серверных лицензий Windows (бесплатная версия Microsoft Hyper-V Server не устраивала из-за своих ограничений).

0. Диспозиция

Для тестирования использовался SSD Samsung 970 Pro 1TB. Заказчик проверял результаты работы в CrystalDiskMark, поэтому далее в статье все графики из него.

Windows 10 LTSC	Hyper-V 2 CPU	KVM 2 CPU

Следовало в первую очередь улучшить производительность случайного ввода/вывода. Именно этот тип нагрузки характерен для виртуальных машин, в особенности тех из них, в которых используются различные БД.

В Ubuntu (16.04 LTS и 18.04) до сих пор используется qemu версии 2.11. Поэтому некоторые плюшки самых последних qemu в этой статье не рассмотрены.

Мы решили что нам нужно избежать привязывания железа к виртуальной машине, так как это осложняет переносимость виртуальных машин, поэтому варианты с прокидыванием SSD/физических дисков/разделов в виртуалки были признанны нежелательными.

Внимательный читатель может заметить, что использовались разные по размеру области для тестирования от 100МБ до 4ГБ. Дело в том, что размер области очень влияет на время выполнения теста: чем больше область, тем длиннее шёл тест.

Однако, так как каждый раз виртуальная машина запускалась заново, кеш Windows сбрасывался и не оказывал влияние на результаты. Результаты для области 100МБ и 4ГБ отличались в пределах погрешности, но время было в 40 раз больше.

Тестирований за время настройки было проведено огромное количество, чтобы задача не затянулась на месяцы, основная часть испытаний была проведена с областями размером 100МБ-1ГБ. И только решающие испытания были проведены с областями 4ГБ.

1. Используем LVM-тома, а не файлы для хранения дисков виртуальных машин.

Логика такая. Файл с виртуальным диском хранится в файловой системе Linux, внутри самого файла находится NTFS. Каждая файловая система потребляет ресурсы при дисковых операциях. Поэтому чем меньше глубина матрёшки, тем быстрее ввод/вывод.

Если же говорить о файлах qcow2, то их название расшифровывается как «Qemu Copy-On-Write» и, фактически, внутри них есть своя таблица трансляции, которая отвечает за то какие блоки заняты, какие нет и где что находится.

Слой LVM потребляет значительно меньше процессорных ресурсов, чем файловая система. Одна из причин этого то, что блоки в нём значительно больше, чем типичный блок файловой системы (4КБ). Чем больше блок (extent) на физическом устройстве LVM, тем более быстро происходит IO и тем меньше фрагментация.

А ведь даже для SSD случайный ввод/вывод значительно медленнее, чем последовательный. Поэтому при создании Volume Group мы укажем очень большую величину extent: 256MB.

Read ahead на логическом томе стоит отключить, так как он расходует IO без выигрыша, так как теперь никто не занимается дефрагментацией дисков в Windows на SSD.

LVM довольно удобно использовать для хостинга виртуальных машин. LVM-тома легко переносимы между физическими дисками, есть снимки (snapshot), изменение размера в режиме онлайн. Тем более, что virt-manager (libvirt) умеет из коробки создавать логические тома под диски виртуальных машин из Volume group (группы томов).

Привлекательной выглядит также возможность создать thin volumes («тонкие» тома), но если учесть, что тонкий том — это дополнительный слой абстракции, то, очевидно, что он будет ухудшать производительность IO. К тому же в libvirt нет элегантного пути автоматического создания дисков для виртуальных машин в «тонком» пуле.

1.1. Thin volume как диск и/или настройки логических томов для снимков

Если вы хотите использовать thin pool, в котором будете создавать тонкие тома, то имеет смысл установить размер чанка у пула в 4МБ, что значительно больше размера по-умолчанию в 64КБ.
Что повлечёт более быструю работу этого слоя абстракции.

Механизм снимков в LVM работает практически на том же самом коде, что и тонкие тома, поэтому для увеличения скорости снимков (snapshot) настройки будут теми же самыми.

Опция -Zn отключает перезапись чанка нулями при выделении, что повышает скорость работы.

Настройки для lvm.conf или подобного файла (например lvmlocal.conf):

Вы можете сами определить оптимальный размер чанка выполнив тестирование следующей командой, подобрав величину --blocksize :

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

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

10 CPU	8 CPU	4 CPU

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

Из чего можно сделать вывод, что хорошо иметь по одному логическому процессору на каждую задачу, активно использующую IO.

3. Используем огромные страницы оперативной памяти (hugepages), чтобы избежать снижения производительности из-за фрагментации RAM

Этот пакет может пригодиться, когда нам понадобится различная информация о hugepages в процессе эксплуатации.

В данном случае было выделено 64ГБ памяти для всех виртуальных машин в виде hugepages. В вашем случае может быть меньше/больше.

Применяем эти настройки для GRUB, чтобы при следующей загрузке системы они стали активны:

Редактируем конфиг виртуальной машины:

4. Добавляем в каждую виртуальную машину выделенный поток для обслуживания IO

Нужно добавить то, что выделено жирным. Используем virsh , как и в предыдущем пункте.

4.1. Для ускорения случайной записи используем кеширование writeback

Для ускорения случайной записи на диск, но с увеличением риска потери данных, можно использовать cache=writeback в предыдущем пункте. Можно использовать только если есть большая уверенность в качестве и резервировании питания и при наличии бэкапов.

5. Настройки дисковой подсистемы в В Virt Manager

Disk bus: VirtIO
Storage format: raw
Cache mode: writeback
IO mode: threads

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

Qemu 2.11 (который сейчас используется в Ubuntu) поддерживает два типа дисковых виртуальных устройств: virtio-blk и virtio-scsi. Когда в Virt Manager указывается Disk bus: VirtIO — это означает использование устройства virtio-blk.

Во всех случаях по скорости лучше virtio-blk, несмотря на то что в тестируемой версии qemu он ещё не поддерживал TRIM в отличии от virtio-scsi (с версии 5.x уже поддерживает).

С точки зрения скорости дискового IO virtio-scsi имеет смысл использовать лишь в экзотических случаях, например, когда нужно подключать сотни дисков к виртуальной машине.

6. В процессе инсталляции Windows устанавливаем драйвер VirtIO

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

7. Результаты после применения всех твиков

На самом деле твик 4.1 не был применён, так как я не был уверен в надёжности питания у клиента.

Hyper-V 2 CPU	KVM 2 CPU	KVM 4 CPU

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

KVM из коробки 2 CPU	KVM после твиков 2 CPU

Мы видим, что удалось существенно ускорить работу дисковой подсистемы в qemu (kvm) при одном и том же числе ядер. Запись была ускорена в среднем на 58%, а чтение на 25%.

Основные элементы успеха: использование LVM-томов вместо файлов qcow2, отдельный поток ввода/вывода и hugepages.

Замеченные ошибки направляйте в личку. Повышаю за это карму.

P.S. vhost-user-blk и vhost-user-nvme

В ходе экспериментов были также и скомпилированы Qemu 2.12 и 3-й версии. Тестировалась опция vhost-user-blk для диска.

В итоге она работала хуже, чем virtio-blk.

vhost-user-blk 4 CPU	virtio-blk 4 CPU

Для использования vhost-user-nvme нужно было патчить qemu, этот вариант усложнял автоматическое обновление серверов в продакшене, поэтому не был протестирован.

P.P.S. SPDK

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

Чтобы заставить spdk хорошо работать идут на массу ухищрений — выделяют ему отдельные ядра, размещают ядра spdk и виртуальной машины в одном сокете. Загружают виртуальную машину в непрерывный кусок памяти. Если такие меры применять к обычному virtio-blk, то он тоже будет быстрее работать.

SPDK способен работать в 3-х режимах: vhost-user-scsi, vhost-user-blk и vhost-user-nvme. Второй режим доступен только в qemu от 2.12, который ещё не доступен в ubuntu. Режим vhost-user-nvme вообще мегаэкспериментальный — для него нужно патчить qemu. На текущий момент работает только эмуляция scsi и она медленная.

Есть ещё одно серьёзное ограничение для режима vhost-user-scsi — диск spdk не может быть загрузочным.

Make sure bootindex=2 Qemu option is given to vhost-user-scsi-pci device.

Рекорды ставятся, когда они с помощью своего драйвера разделяют SSD на несколько устройств и прокидывают их как vhost-user-nvme. Подход с прокидыванием железа нам не подходил.

Сложилось впечатление, что нормально использовать SPDK можно только с их реализацией логических дисков (которая совершенно отличается от стандартных lvm). Это такой самопальный велосипед со своими снимками и клонированием. Команды все отличаются от LVM.

Сложность в настройке SPDK, поддержке и переносимости виртуальных машин, а также привязанность к процессорам Intel отвернула от его использования.

Благодарности

За изображение спасибо TripletConcept. Его лучше смотреть в полном размере в отдельном окне.

За разрешение поделиться рабочими материалами — st_neon

Вы можете заказать виртуальную машину с SSD у RUVDS по купону ниже.

Замеченные ошибки направляйте в личку. Повышаю за это карму.

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

Virsh: команды управления виртуальной машиной KVM

Первый вопрос, который возникает у начинающего администратора KVM: как увидеть созданные виртуальные машины, как остановить, запустить и удалить их. Для управления ВМ в KVM из консоли можно использовать утилиту virsh (использует libvirt API). С помощью утилиты virsh можно выполнить практически все операции с виртуальными машинами KVM.

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

Еще несколько команд по получению различной информации о виртуальной машине:

Добавление памяти и vCPU виртуальной машине KVM

В консоли KVM вы можете добавить или уменьшить ресурсы процессора и памяти, выделенные для ВМ двумя способами:

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

Теперь с помощью virsh изменим количество виртуальных процессоров до 6 (vCPU):

— количество ядер процессора

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

Мы не можем установить количество ядер процессора, больше, чем максимальное количество. Чтобы увеличить максимальное количество ядер ВМ, выполните команду:

Повторите первую команду и запустите виртуальную машину:

Проверим количество процессоров в настройках ВМ: овленное количество процессоров:

Аналогичным образом добавим память виртуальной машине:

Все по той же причине, сразу же вышла ошибка:

Увеличим максимальное значение памяти::

Теперь можно увеличить память ВМ.

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

Также вы можете изменить ресурсы ВМ KVM через ее конфигурационный XML файл. Можно изменить файл в режиме онлайн или же сделав бэкап XML файла ВМ, изменить его и применить к виртуальной машине.

Отредактируем XML файл ВМ в онлайн режиме:

В открывшемся редакторе vi внесите изменения, нажав кнопку “Insert”.

Например, зададим для ВМ 2 ядра и 1Гб памяти:

Сохраните изменения в файле и перезапустите ВМ:

Проверьте настройки ВМ:

Тоже самое можно сделать, сделав бэкап XML файла:

Измените нужные вам параметры, сохраните файл и примените к виртуальной машине:

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

KVM: добавление диска в виртуальную машину

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

Сначала нужно создать дополнительный файл диска для виртуальной машины:

Вместо qcow2 вы можете указать нужный формат диска, так же нужно указать путь до файла. У меня хранилище для дисков /vz/disk/.

После этого, можно добавить устройство виртуального диска к самой ВМ:

Остановите и запустите ВМ, проверьте что получилось:

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

KVM: добавление сетевой карты для виртуальной машины

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

У меня на KVM сервере создана одна виртуальная машина, с одним сетевым интерфейсом. К br0 нам нужно прикрепить еще один виртуальный сетевой интерфейс. Выполните команды:

Проверьте, что у ВМ появился дополнительный сетевой интерфейс:

После первого сетевого интерфейса добавьте следующие строки:

Сохраните файл и запустите ВМ. Остальную конфигурацию, KVM добавит сам (mac address и тд).

В данной статье мы затронули основные моменты, которые могут вам понадобиться при управлении виртуальными машинами KVM из консоли Linux сервера. В следующей статье мы рассмотрим управление виртуальными машинами через графический менеджер virt-manager

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