Как подключиться к виртуальной машине на KVM через VNC
Проверяю nmap с локальной сети 5900 порт — закрыт. И VNC не может подключиться к виртуалке. Подскажите, что я не так делаю?

manik207 ★
07.01.17 22:46:58 MSK

Ну так все правильно, слушает только локалхост. если очень хочется — как вариант — пробрасывайте порт с сетевого интерфейса на локалхост
Belen ★★
( 07.01.17 23:22:56 MSK )
int13h ★★★★★
( 08.01.17 01:15:41 MSK )

sudo dnf install virt-manager virt-manager -c qemu+ssh://user@host/system
В роли host — сервер виртуализации.
ArcFi ★
( 08.01.17 10:14:41 MSK )
Ответ на: комментарий от Belen 07.01.17 23:22:56 MSK

Спасибо за ответ.
Подключаться хочу по VNC-клиенту в винды, поэтому очень хочется)))
Пробросила порт в файрволе на локалхост
firewall-cmd --add-forward-port=port=5900:proto=tcp:toaddr=127.0.0.1 --permanent
Маскарадинг включила (не очень поняла тему, но может нужно, поправьте, если зря)
firewall-cmd --zone=public --add-masquerade --permanent
Если я правильно поняла, то файрволл пробросил порт 5900 на локалхост
firewall-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: eno1 sources: services: ssh ports: 5900/tcp protocols: masquerade: yes forward-ports: port=5900:proto=tcp:toport=:toaddr=127.0.0.1
Подключаюсь vnc-клиентом — Попытка подключения была безуспешной, не получен отклик от другого компа.
В клиенте vnc указываю хост для подключения и порт: 192.168.1.101:5900 (IP-адрес верный, сижу по нему в путти).
manik207 ★
( 08.01.17 12:32:31 MSK ) автор топика
Ответ на: комментарий от ArcFi 08.01.17 10:14:41 MSK

Спасибо за ответ
Сервер KVM стоит на хосте 192.168.1.101, virt-manager поставила из dnf, подключена к хосту по ssh, из него же запустила
virt-manager -c qemu+ssh://root@192.168.1.101/system ** (virt-manager:5717): WARNING **: Could not open X display (virt-manager:5717): Gtk-WARNING **: cannot open display: localhost:10.0
Ругается, что нет дисплея. Но ведь дисплея действительно нет, сентос еще устанавливать надо.
manik207 ★
( 08.01.17 13:03:06 MSK ) автор топика
Ответ на: Спасибо за ответ. от manik207 08.01.17 12:32:31 MSK
а сокет открыт и ждет соединения?
#netstat -tulpan | grep 5900
в конфиге вм нужно указать на каком адресе слушать. По умолчанию это 127.0.0.1 .
ving2 ★
( 08.01.17 13:10:44 MSK )
Ответ на: Спасибо за ответ от manik207 08.01.17 13:03:06 MSK

Подключаться хочу по VNC-клиенту в винды
Ругается, что нет дисплея
ArcFi ★
( 08.01.17 13:13:40 MSK )
Ответ на: комментарий от ving2 08.01.17 13:10:44 MSK
ving2 ★
( 08.01.17 13:17:33 MSK )
Ответ на: Спасибо за ответ. от manik207 08.01.17 12:32:31 MSK

И можно ничего не пробравсывать, а просто отредактировать конфиг виртуалки примерно так:
virsh edit vm1 . .
ArcFi ★
( 08.01.17 13:17:56 MSK )
Ответ на: комментарий от ArcFi 08.01.17 13:13:40 MSK

Спасибо! Получилось подключиться и установить ОС. Сделала фактически, копи-пастом, поняла мало.
Можете на пальцах пояснить?
Я понимаю, что есть хост-машина, которая у меня под IP 192.168.1.101, на ней я установила виртуальную машину, сейчас это ХР, еще будет Centos. На этих машинах открыт порт 5900 и далее +1 к каждой последующей. И запросы по этому порту виртуальная машина принимает только с локального хоста (это по дефолту). Через проброс портов в ssh с помощью VcXsrv и virt-manager, запускаю панель управления виртуальными машинами. При установке машины сразу указываю соединение Мост с действующим сетевым интерфейсом и после установки подключаюсь по RDP. Больше ничего не надо.
И если, создавать виртуалки из окна менеджера и прописывать Мостовое соединение, то конфиги править не нужно. А если создавать виртуалки из командной строки, то можно ли сразу указать порт подключения, и т.д. из параметров установки, дабы не править их потом?
manik207 ★
( 08.01.17 16:18:30 MSK ) автор топика
Ответ на: комментарий от manik207 08.01.17 16:18:30 MSK

Да, примерно так.
QEMU/KVM биндит порт на самом сервере виртуализации, поэтому доступ через SPICE/VNC не зависит от статуса загрузки виртуалки и наличия средств удалённого доступа на ней.
Мостовое сетевое подключение довольно удобно для интеграции виртуалок в существующую инфраструктуру.
Порт, доступ к нему и иные парраметры можно задать сразу при создании виртуалки:
virt-install . --graphics vnc,listen=0.0.0.0,port=5905 man virt-install
Настройка сети в KVM
Настройка сети для виртуальных машин в kvm очень похожа на настройку в qemu, поэтому любая документация к qemu подходит и для kvm. В этой статье описывается как настроить наиболее часто используемые типы подключения виртуальной машины к сети. Эта статья основана на Networking — KVM.
Пользовательская сеть
Варианты использования:
- Вам нужен простой способ дать виртуальной машине доступ в Интернет и в вашу локальную сеть;
- Вам не нужен доступ к виртуальной машине из сети или из других виртуальных машины;
- Вы готовы пожертвовать производительностью;
- Внимание: пользовательская сеть не поддерживает некоторые возможности сетей, например ICMP, поэтому некоторые приложения (такие как ping) могут работать неправильно.
- Настроенная и запущенная виртуальная машина;
- Если вы не хотите запускать её из под root-а, то для вашего пользователя понадобятся права на чтение/запись в /dev/kvm;
- Если виртуальной машине нужен доступ в Интернет или в локальную сеть, то у хост-системы должен быть доступ в эти сети.
- Просто запустите виртуальную машину с параметрами «-net nic -net user», например:
qemu-system-x86_64 -hda /path/to/hda.img -net nic -net user
- IP-адрес может быть назначен автоматически DHCP-сервером, встроенным в QEMU;
- Если вы хотите запустить несколько виртуальных машин, то вам не понадобится назначать для них различные MAC-адреса;
- Используя опцию «hostfwd» вы можете получить доступ к одном порту на виртуальной машине. Например, если вы хотите передать файл из хост-системы на виртуальную машину, то запустите машину с параметрами «-net nic -net user,hostfwd=tcp::5555-:22». В данном случае вы перенаправить порт 5555 из хост-системы на порт 22 виртуальной машины. Команда «scp -P 5555 file.txt root@localhost:/tmp», выполненная на хост-системе, скопирует файл в виртуальную машину. Также вы можете использовать другой адрес хост-системы для подключения.
Внутренний виртуальный мост
Варианты использования:
- Организация сети между двумя или более виртуальными машинами. Эта сеть не будет доступна ни другим виртуальным машинам, ни из реальной сети.
- Организация сети между виртуальными машинами и хост-системой. От первого варианта отличается только добавлением адреса на мостовой интерфейс хоста. Если возникнет потребность, можно добавить реальный интерфейс в мост, тогда виртуальные машины будут подключены к реальной LAN.
- Настроенная и запущенная виртуальная машина;
- Если вы не хотите запускать её из под root-а, то для вашего пользователя понадобятся права на чтение/запись в /dev/kvm;
- Вам понадобятся следующие программы:
Если вы не хотите запускать их из под root-a, то вам понадобится настроить sudo для их запуска.
Решение:
Подготовка
В Седьмой платформе
- Во-первых, можно стартовать виртуальные машины с помощью libvirtd и управлять ими посредством virsh, при этом всё будет сделано автоматически. Нужно только правильно указать интерфейс (опция --network bridge).
- Во-вторых, можно использовать мостовой интерфейс virbr0, который появляется в системе после установки пакета kvm. Интерфейсу уже назначен IP 192.168.122.1/24 (см. конфигурация ю файле /etc/libvirt/qemu/networks/default.xml).
Перед запуском виртуальной машины создайте tap-интерфейс, добавьте его мост и потом используйте его при запуске kvm:
sudo tunctl -u $USERNAME -t tap11 sudo brctl addif virbr0 tap11 sudo ip link set tap11 up kvm -m 1024 -no-fd-bootchk -localtime -show-cursor -hda w40G.img -net nic,vlan=0,macaddr=00:e0:4c:4f:35:82,model=rtl8139 -net tap,vlan=0,ifname=tap11,script=no
Создать tap-интерфейсы и добавить их в мост можно и с помощью скриптов /etc/net (см. man etcnet).
- В-третьих, можно использовать системный скрипт для запуска мостового интерфейса: /etc/init.d/bridge, достаточно создать нужное количество виртуальных интерфейсов, добавить их в /etc/sysconfig/bridge и запустить «службу» bridge:
ip link | grep -q tap100: || tunctl -u $USERNAME -t tap100 INTERFACES="tap100" BRIDGE_INTERFACE="br0"
Скрипт /etc/init.d/bridge при этом нельзя запускать автоматически при старте системы, но запускайте только вручную от пользователя с помощью sudo:
sudo service bridge start
В дальнейшем виртуальные машины нужно запускать с использованием этих готовых интерфейсов, например:
kvm -m 1024 -no-fd-bootchk -localtime -show-cursor -hda w40G.img -net nic,vlan=0,macaddr=00:e0:4c:4f:35:81,model=rtl8139 -net tap,vlan=0,ifname=tap100,script=no
В старых дистрибутивах
- Нужно создать и сконфигурировать мост, например:
sudo brctl addbr br1 sudo ip link set br1 up
- Для связи по сети между виртуальной машиной и хост-системой нужно задать адрес IP мосту, например:
sudo ip addr add 192.168.100.1/24 dev br1
или, чтобы не задавать адрес вручную, создайте файл /etc/net/ifaces/br1/ipv4address, содержащий единственную строку «192.168.100.1/2» (Это не обязательно, если доступ по сети в/из виртуальную машину не нужен.)
Также можно сконфигурировать сервер DHCP, чтобы он выдавал адреса в подсети интерфейса br1 (см. man dhcpd).
Включение виртуальной машины в мост
- Необходимо (стандартный вариант)
— наличие двух сетевых карт на хосте eth0 и eth1 подключенных к локальной сети, — интерфейс eth0 настроен и работает в сети, eth1 включен настройки не обязательны
- Создать мост br0 (некоторые разработчики считают, что команды tunctl и brctl устарели)
- создаем мост br0 штатными средствами ip link add br0 type bridge - добавляем физический итерфейс eth1 в мост ip link set eth1 master br0 - поднимаем мостовой интерфейс br0 ip link set up dev br0
-- вышеприведенных трех команд достаточно, чтобы при использовании virt-manager, поднять машину работающую в локальной сети -- указать в virt-manager (создать сеть на базе 'Общее устройство' и указать имя моста 'br0')
- Создать скрипт qemu-ifup следующего содержания без sudo и «устаревших» утилит:
- скрипт необходим для запуска qemu-system-x86_64 c параметрами в консоли - мост должен быть создан ip link add br0 type bridge; ip link set eth1 master br0; ip link set up dev br0 - вносим и сохраняем в файл mcedit /etc/qemu-ifup и делаем его исполняемым chmod +x /etc/qemu-ifup следующий код: #!/bin/sh set -x switch=br0 if [ -n "$1" ];then ip tuntap add $1 mode tap user `whoami` ip link set $1 up sleep 0.5s ip link set $1 master $switch exit 0 else echo "Error: no interface specified" exit 1 fi - команда настройки сети для qemu-system-x86_64 -device e1000,netdev=net0,mac='DE:AD:BE:EF:87:0D' -netdev tap,id=net0,script=/etc/qemu-ifup
- Общая команда запуска виртуальной машины может выглядеть так
qemu-system-x86_64 -enable-kvm -accel accel=kvm,thread=multi \ -vga qxl \ -cpu core2duo \ -m 2048 \ -drive format=qcow2,file=/var/lib/libvirt/images/korpus_bs1.qcow2 \ -device e1000,netdev=net0,mac='DE:AD:BE:EF:87:0D' -netdev tap,id=net0,script=/etc/qemu-ifup
- Создать скрипт qemu-ifup следующего содержания (c использованием sudo, возможно необходимы предварительные настройки):
#!/bin/sh set -x switch=br0 if [ -n "$1" ];then /usr/bin/sudo /sbin/tunctl -u `whoami` -t $1 /usr/bin/sudo /sbin/ip link set $1 up sleep 0.5s /usr/bin/sudo /sbin/brctl addif $switch $1 exit 0 else echo "Error: no interface specified" exit 1 fi
- Сгенерировать MAC-адрес вручную или автоматически, используя скрипт:
#!/bin/bash # generate a random mac address for the qemu nic printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256))
- Запустить каждую виртуальную машину, заменяя $macaddress значением, полученным на предыдущем шаге:
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap
- Внутри каждой виртуальной машины нужно сконфигурировать уникальный адрес IP из одной и той же подсети.
Работа с предварительно созданными иинтерфейсами
Можно заранее (в стартовом скрипте) настроить все интерфейсы и затем использовать их в виртуальных машинах. При этом обязательно нужно указывать опцию script=no:
kvm . -net nic,vlan=0,macaddr=00:e0:4c:4f:35:81,model=rtl8139 -net tap,vlan=0,ifname=tap11,script=no
- Если вы не хотите запускать машину от root-а, то скрипт qemu-ifup должен корректно работать от вашего пользователя;
- Вы можете создать общесистемный скрипт, назвав его в /etc/qemu-ifup или же спользовать любое другое имя, указав его при запуске машины:
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap,script=/path/to/qemu-ifup
- Каждая виртуальная машина подключенная к внутреннему виртуальному мосту должна иметь свой собственный MAC-адрес, отличный от адресов других машин.
- Для включения в мост необходимо использовать интерфейсы tap, но не tun. Дело в том, что у интерфейсов tun нет заголовков ethernet, которые требуются для работы моста.
Публичный мост
Предупреждение: Данный метод может не работать с большинством беспроводных устройств.
Варианты использования:
- Вы хотите назначать IP-адреса виртуальным машинам и сделать их доступными из локальной сети;
- Вы хотите большой производительности от виртуальной машины.
- Настроенная и запущенная виртуальная машина;
- Если вы не хотите запускать её из под root-а, то для вашего пользователя понадобятся права на чтение/запись в /dev/kvm;
- Вам понадобятся следующие программы. Если вы не хотите запускать их из под root-a, по вам понадобится настроить sudo для их запуска:
/sbin/ip /usr/sbin/brctl /usr/sbin/tunctl
- Хост-система должна иметь доступ в интернет и в локальную сеть.
Вариант №1: Использование средств дистрибутива
- Создать файл /etc/net/ifaces/breth0/options следующего содержания:
TYPE=bri BOOTPROTO=dhcp HOST=eth0 DISABLED=no NM_CONTROLLED=no
- Применить новые настройки сети командой:
/etc/init.d/network restart
- Интерфейс моста breth0 должен получить IP-адрес, а интерфейс eth0 должен быть без адреса.
Особенности VLANов
Если вы используете VLANы но до виртуальной машины трафик не доходит, выполните команды:
# cd /proc/sys/net/bridge # ls bridge-nf-call-arptables bridge-nf-call-iptables bridge-nf-call-ip6tables bridge-nf-filter-vlan-tagged # for f in bridge-nf-*; do echo 0 > $f; done
Варинат №2: «Ручной»
- Создать мост командой:
sudo /usr/sbin/brctl addbr br0
- Добавить физический интерфейс в этот мост, например eth0:
sudo /usr/sbin/brctl addif br0 eth0
- Создать скрипт qemu-ifup следующего содержания:
#!/bin/sh set -x switch=br0 if [ -n "$1" ];then /usr/bin/sudo /usr/sbin/tunctl -u `whoami` -t $1 /usr/bin/sudo /sbin/ip link set $1 up sleep 0.5s /usr/bin/sudo /usr/sbin/brctl addif $switch $1 exit 0 else echo "Error: no interface specified" exit 1 fi
- Сгенерировать MAC-адрес вручную или автоматически, используя скрипт:
#!/bin/bash # generate a random mac address for the qemu nic printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256))
- Запустить каждую виртуальную машину, заменяя $macaddress значением, полученным на предыдущем шаге:
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap
- Если вы не хотите запускать машину от root-а, то скрипт qemu-ifup должен корректно работать от вашего пользователя;
- Вы можете создать общесистемный скрипт, назвав его в /etc/qemu-ifup или же спользовать любое другое имя, указав его при запуске машины:
qemu-system-x86_64 -hda /path/to/hda.img -net nic,macaddr=$macaddress -net tap,script=/path/to/qemu-ifup
- Каждая виртуальная машина подключенная к внутреннему виртуальному мосту должна иметь свой собственный MAC-адрес, отличный от адресов других машин.
Маршрутизация/iptables
Также вы можете объединить виртуальные машины tap-интерфесом в хост-системе и настроить правила iptables в хост-система, чтобы она была маршутизатором и сетевым экраном для виртуальных машин.
Настройки маршрутизации сводятся к созданию маршрута по умолчанию в виртуальной машине, указывающего на хост-систему, разрешение пересылки пакетов (IP forwarding) и настройки маршрута на tap-интерфейс виртуальной машины в хост-системе.
Заблаговременно проверьте настройки:
- Хост-система: Разрешить пересылку пакетов и добавить маршрут до виртуальной машины (должно быть помещено в скрипт — маршрут необходимо добавить после запуска виртуальной машины):
sysctl -w net.ipv4.ip_forward=1 # разрешить пересылку пакетов IPv4 route add -host dev # добавить маршрут до виртуальной машины
- Виртуальная машина: маршрут по умолчанию указывает на хост-систему ( должен быть в одной сети с ):
route add default gw
- Виртуальная машина v2: если IP-адрес хост-системы не в одной сети с , тогда надо вручную добавить маршрут до хост-системы перед добавлением маршрута по умолчанию:
route add -host dev route add default gw
VDE
Другой способ настройки сети это VDE (Virtual Distributed Ethernet).
Известные баги
Отказы сети в гостевых Windows
Под большой нагрузкой сетевой интерфейс в гостевой машине с ОС Windows перестаёт принимать и отправлять пакеты в хост-машину. Такое поведение характерно для любой модели виртуального интерфейса и для любой версии Windows в QEMU-KVM как минимум до версии 1.4.
Существует обходное решение: нужно заново проинициализировать сетевой интерфейс гостевой машины. Либо это можно сделать из гостевой ОС, либо из хост-машины парой команд virsh detach-interface и atttach-interface (и это надёжнее). Проверяем работоспособность при этом, очевидно, командой ping. Варианты скриптов для гостевой машины: [1], [2]. В скрипте для хоста перед проверкой пинга требуется проверить, работает ли гостевая ОС.
Управление виртуальными машинами KVM из консоли

04.03.2020

VyacheslavK

CentOS, KVM, Linux

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

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

# virsh suspend — приостановить виртуальную машину
# virsh resume — запустить приостановленную виртуальную машину
# virsh reboot — перезапустить виртуальную машину
# virsh destroy — уничтожить виртуальную машину
# virsh undefine — удалить машину из списка и удалить все файлы, принадлежащие ей (обычно применяется после выполнения команды virsh destroy).
# virsh vcpuinfo — информация о процессоре на виртуальной машине (информацию о железе физического Linux сервера можно получить так)

Еще несколько команд по получению различной информации о виртуальной машине:
# virsh domid — получить идентификатор виртуальной машины
# virsh domuuid — получить UUID виртуальной машины
# virsh dominfo — получить сведения о виртуальной машине
# virsh domstate — просмотр состояния виртуальной машины

# virsh dumpxml — вывести файл конфигурации указанной виртуальной машины в XML формате
Добавление памяти и vCPU виртуальной машине KVM
В консоли KVM вы можете добавить или уменьшить ресурсы процессора и памяти, выделенные для ВМ двумя способами:
Если виртуальная машина запущена, ее нужно остановить:
# virsh shutdown test-centos
Domain test-centos is being shutdown
Теперь с помощью virsh изменим количество виртуальных процессоров до 6 (vCPU):
— количество ядер процессора
# virsh setvcpus test-centos 6 —config
Но при применении этой команды, у меня сразу же появилась ошибка:
“error: invalid argument: requested vcpus is greater than max allowable vcpus for the persistent domain: 6 > 4”
Мы не можем установить количество ядер процессора, больше, чем максимальное количество. Чтобы увеличить максимальное количество ядер ВМ, выполните команду:
# virsh setvcpus test-centos 6 —config —maximum
Повторите первую команду и запустите виртуальную машину:

Проверим количество процессоров в настройках ВМ: овленное количество процессоров:
# virsh dumpxml test-centos
test-centos 5c7eabea-a180-4f74-af9f-c4c2d3b7f70f 2097152 2097152 6
Аналогичным образом добавим память виртуальной машине:
# virsh setmem test-centos 4G —config
Все по той же причине, сразу же вышла ошибка:
“error: invalid argument: cannot set memory higher than max memory.”
Увеличим максимальное значение памяти::
# virsh setmaxmem test-centos 6G —config
Теперь можно увеличить память ВМ.
Перед всеми изменениями не забывайте останавливать ВМ, а после запускать ее.
Также вы можете изменить ресурсы ВМ KVM через ее конфигурационный XML файл. Можно изменить файл в режиме онлайн или же сделав бэкап XML файла ВМ, изменить его и применить к виртуальной машине.
Отредактируем XML файл ВМ в онлайн режиме:
В открывшемся редакторе vi внесите изменения, нажав кнопку “Insert”.
Например, зададим для ВМ 2 ядра и 1Гб памяти:

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

Тоже самое можно сделать, сделав бэкап XML файла:
# virsh dumpxml > /root/test.xml
# vi /root/test.xml
Измените нужные вам параметры, сохраните файл и примените к виртуальной машине:
# virsh shutdown test-centos
Domain test-centos is being shutdown
# virsh define /root/test.xml
Domain test-centos defined from /root/test.xml
# virsh start test-centos
Domain test-centos started
Иногда при изменении конфигурационного файла ВМ в онлайн режиме назначенные ресурсы сбрасываются после перезагрузки. В этом случае выполните остановку виртуальной машины и после этого просто запустите ее.
KVM: добавление диска в виртуальную машину
В одной из наших статей, мы описывали процесс расширения и уменьшения дисков виртуальных машин в KVM. Но мы не описывали вариант по добавлению дополнительного диска.
Сначала нужно создать дополнительный файл диска для виртуальной машины:
# qemu-img create -f qcow2 -o size=20G /vz/disk/test.img
Вместо qcow2 вы можете указать нужный формат диска, так же нужно указать путь до файла. У меня хранилище для дисков /vz/disk/.
После этого, можно добавить устройство виртуального диска к самой ВМ:
# virsh attach-disk /vz/disk/test.img vdb —type disk —persistent
Остановите и запустите ВМ, проверьте что получилось:
# virsh shutdown test-centos
Domain test-centos is being shutdown
# virsh start test-centos
Domain test-centos started
# virsh dumpxml test-centos
test-centos 5c7eabea-a180-4f74-af9f-c4c2d3b7f70f 2097152 2097152 6 /machine ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ hvm
Как видим, диск добавлен. После данных манипуляций, на виртуальной машине нужно разметить этот диск под ваши нужды.
KVM: добавление сетевой карты для виртуальной машины
Попрьуем добавить дополнительный сетевой интерфейс для ВМ. Сначала проверим, какие сетевые интерфейсы созданы на хосте:

У меня на KVM сервере создана одна виртуальная машина, с одним сетевым интерфейсом. К br0 нам нужно прикрепить еще один виртуальный сетевой интерфейс. Выполните команды:
# virsh shutdown test-centos
# virsh attach-interface test-centos —type bridge —source br0 —persistent
# virsh start test-centos
Проверьте, что у ВМ появился дополнительный сетевой интерфейс:

Также вы можете изменить сетевые настройки виртуальной машины напрямую через XML файл: # virsh edit test-centos
После первого сетевого интерфейса добавьте следующие строки:
Сохраните файл и запустите ВМ. Остальную конфигурацию, KVM добавит сам (mac address и тд).
В данной статье мы затронули основные моменты, которые могут вам понадобиться при управлении виртуальными машинами KVM из консоли Linux сервера. В следующей статье мы рассмотрим управление виртуальными машинами через графический менеджер virt-manager.
Предыдущая статья Следующая статья
Настройка KVM на CentOS 7
Настройку KVM будем проводить на CentOS 7, minimal, x64. Выбор KVM при использовании CentOS был для меня достаточно очевиден — он поддерживается и продвигается Red Hat.
Итак, в локальной сети 192.168.88.0/24 есть хост (CentOS 7, имя SERVER.LOCAL и IP 192.168.88.2, сетевой адаптер enp1s0). На этом хосте мы хотим запустить несколько виртуальных машин, доступных из локальной сети. Технология виртуализации: KVM.
Подготовительные работы
Для начала вообще проверим, наш хост поддерживает виртуализацию или нет:
# egrep ‘(vmx|svm)’ /proc/cpuinfo
Если ок (еще бы нет. ), готовим сеть для роутинга трафика между виртуальными машинами и внешней сетью:
# echo "net.ipv4.ip_forward = 1" | tee /etc/sysctl.d/99-ipforward.conf net.ipv4.ip_forward = 1 # sysctl -p /etc/sysctl.d/99-ipforward.conf
Ок. Дальше выберем тип виртуальной сети.
Bridge или nat?
Есть два варианта работы виртуальных машин в сети:
1) Виртуальные машины будут за nat, недоступные из внешней сети.
Создаваемые виртуальные машины по-умолчанию будут принадлежать внутренней виртуальной сети хоста (по-умолчанию 192.168.122.0/24) и будут иметь доступ во внешнюю сеть хоста (т.е. в сеть 192.168.88.0/24), а если маршрутизация на хосте настроена, то и в интернет тоже. Из локальной сети виртуальные машины будут недоступны до тех пор, пока вы не настроите проброс портов (forwarding) на хосте из сети хоста в виртуальную сеть.
+ Этот способ проще, т.к. не потребует создания дополнительного сетевого интерфейса — bridge.
+ Если внешний IP один, то может быть невозможным иной сценарий, как только пробрасывать порты.
+ Возможно, вам вообще необходимо создать закрытую сеть для виртуальных машин и вам уж точно не нужно публиковать их в сети хоста. Кто знает? Хозяин — барин!
2) Bridge — виртуальные машины будут видны в сети так же, как и обычные компьютеры, без всяких там nat и forwarding.
В этом случае виртуальные машины будут получать IP по DHCP от вашего обычного сервера, будут видны в сетевом окружении другими компьютерами и прочее.
+ Клиенты в сети не увидят разницу между виртуальным сервером и реальным.
— В случае с внешним IP для каждой виртуальной машины нужен будет свой IP, а это не всегда возможно.
— Надо немного потрудиться и подготовить сеть хоста для создания бриджа (bridge), на котором и будет висеть сеть виртуальных машин.
После установки kvm у вас уже будет готовая внутренняя сеть (вариант 1), вполне себе работоспособная, позволяющая гостевым виртуалкам выходить в интернет. Для простоты предлагаю использовать эту сеть, почувствовать, что к чему и потом, при желании, создать bridge для реализации второго варианта.
Устанавливаем KVM
Собственно, мы дорвались до установки виртуализации KVM, эмулятора QEMU и сопутствующих инструментов.
Устанавливаем необходимые пакеты:
# yum install qemu-kvm libvirt libvirt-python libguestfs-tools virt-install
# systemctl enable libvirtd && systemctl start libvirtd
Хранить образы виртуальных машин мы будем в новой папке /vms
Добавляем соответствующий контекст для нашей папки, чтобы SELinux не возмущалась:
# semanage fcontext —add -t virt_image_t ‘/vms(/.*)?’
# semanage fcontext -l | grep virt_image_t /var/lib/imagefactory/images(/.*)? all files system_u:object_r:virt_image_t:s0 /var/lib/libvirt/images(/.*)? all files system_u:object_r:virt_image_t:s0 /vms(/.*)? all files system_u:object_r:virt_image_t:s0
# restorecon -R -v /vms
и проверяем, применились ли они:
# ls -aZ /vms
drwxr-xr-x. root root unconfined_u:object_r:virt_image_t:s0 .
dr-xr-xr-x. root root system_u:object_r:root_t:s0 ..
Ок, скачиваем из сети образ iso для той ОС, которая будет установлена на вирт. машине, например, тот же CentOS 7 minimal для будущего веб-сервера? Или Tails? Кто знает 🙂
Создаем первую виртуальную машину
После вышеперечисленных действий для виртуальных машин на хосте создан сетевой интерфейс virbr0 с IP 192.168.122.1:
Также создана виртуальная сеть default:
# virsh net-list Name State Autostart Persistent ---------------------------------------------------------- default active yes yes
Сеть можно редактировать:
# virsh net-edit defaultdefault 745f121b-3c89-1281-a19a-aa62808c4241
Пока давайте не будем ничего менять и создадим виртуальную машину, подключенную с сети default:
# virt-install --network network=default --name vm1 --ram=2048 --vcpus=1 --disk path=/vms/vm1.img,size=30,format=qcow2 --graphics vnc,password=vm1password --cdrom /vms-iso/CentOS-7-x86_64-Minimal-1503-01.iso --boot cdrom,hd,menu=on
—graphics vnc,password=vm1password
Здесь мы указываем пароль и возможность подключиться к терминалу виртуальной машины с через VNC. Пароль может засветиться в логах, так что не пишите сюда что-то важное.
—network network=default — подключаем нашу виртуальную машину к виртуальной сети с именем default (с ней мы уже знакомы).
М.б. —network bridge:br0, например, если бы мы создали bridge с именем br0 для варианта номер 2.
Указанная выше команда может быть введена сразу, одной строкой, тут уж как удобнее:
virt-install —network network=default —name vm1 —ram=2048 —vcpus=1 —disk path=/vms/vm1.img,size=30,format=qcow2 —graphics vnc,password=vm1password —cdrom /vms-iso/CentOS-7-x86_64-Minimal-1503-01.iso —boot cdrom,hd,menu=on
После выполнения команды можете увидеть сообщение:
WARNING Unable to connect to graphical console: virt-viewer not installed. Please install the ‘virt-viewer’ package.
WARNING No console to launch for the guest, defaulting to —wait -1
Нам и не надо, ведь у нас все равно хост виртуальных машин не имеет оконного менеджера. У меня так, во всяком случае.
Starting install. Allocating 'vm1.img' | 30 GB 00:00:00 Creating domain. | 0 B 00:00:00 Domain installation still in progress. Waiting for installation to complete.
Мужественно ждем. Процесс займет какое-то время.
После завершения команды посмотрим список виртуальных машин:
# virsh list Id Name State ---------------------------------------------------- 2 vm1 running
Вирт. машины можно запускать ( virsh start vm1 ), приостанавливать ( virsh suspend vm1 ), возобновлять ( virsh resume vm1 ), выключать ( virsh shutdown vm1 ) и много чего еще с ними делать. Итак, машина vm1 запущена (проверить можно командой virsh domstate vm1 ). Как к ней подключиться?
Подключаемся к виртуальной машине по VNC
На предыдущем этапе вы создали виртуальную машину, указали ей CDROM с операционной системой, а дальше что? Как вы планируете установить и настроить ОС? Да, есть варианты. Можно подготовить инфраструктуру и заливать готовые образы и др. Но мы с вами учимся и у нас нет ничего, кроме недавно скачанного с интернета файла образа диска iso. На самом деле все не сложно. Мы указали на предыдущем шаге параметр «—graphics vnc,password=vm1password». Он означает, что мы можем подключиться к терминалу (читай — экрану) виртуальной машины через VNC, например, программой TightVNC, указав IP хоста виртуальных машин и порт для подключения.
Нашей виртуальной машине был назначен порт VNC, подключившись к которому мы увидим «экран» виртуальной машины. Узнать, какой порт назначен конкретной vm1, можно командой:
# virsh vncdisplay vm1
127.0.0.1:0
Это означает, что порт VNC 5900+0=5900. Если бы результат был «127.0.0.1:1», порт VNC был бы 5901. И т.д.
Подключаться к порту 5900 надо к хосту виртуальных машин. Это на нем открыт этот порт, а не на виртуальной машине vm1.
По умолчанию, хост виртуальных машин (у нас это CentOS 7 minimal) не должен позволять подключение к любому порту кроме ssh (22/tcp). Не советую вам открывать доступ к портам VNC из-вне. Это небезопасно. Для того, чтобы получить доступ к экрану виртуальной машины с рабочей станции Windows, с которой я все настраиваю, я сделал туннелирование порта в Putty: 5900 -> 127.0.0.1:5900.

После успешного логина по ssh, можно запустить TightVNC и указать порт 127.0.0.1::5900 (обратите внимание на двойное двоеточие).
Если после перезагрузки машины потребуется снова подключить к ней образ iso, это можно сделать командой:
# virsh attach-disk vm1 /vms-iso/CentOS-7-x86_64-Minimal-1503-01.iso hdb —type cdrom —mode readonly
где hdb — имя блочного устройства CDROM. Это имя можно узнать просмотрев конфиг вирт. машины ( virsh edit vm1 ).
Управлять виртуальными машинами с хоста можно консольным набором virsh. С некоторыми командами вы уже познакомились. Наберите в консоли:
и вы увидите, сколько всего можно сделать.
Включение/выключение виртуальных машин
Если вы создадите виртуальную машину и попытаетесь ее выключить, то несмотря на рапорт о выполнении, машина может не выключиться:
# virsh domstate vm1 running # virsh shutdown vm1 Domain vm1 is being shutdown # virsh domstate vm1 running
Здесь дело в поддержке acpi со стороны виртуальной машины. Не во всех случаях вирт. машина обработает сигнал о выключении или перегагрузки (virsh shutdown/restart vm1). В этой ситуации могут быть следующие варианты:
Выдергивание кабеля питания:
# virsh destroy vm1 Domain vm1 destroyed
Вы прекрасно понимаете, к чему это может привести. Хотя на начальном этапе, пока ОС не установлена, появление ошибок
Приостановка работы вирт. машины:
virsh suspend vm1
Не всегда бывает необходимо выключать или перезагружать машину извне. Для обслуживания может быть достаточно приостановки. Не факт, но все же.
Включение поддержки acpi в виртуальной машине.
Тут могут быть разные рецепты, например так (выполнить в вирт. машине, а не на хосте):
yum install acpid
chkconfig acpid on
service acpid start
Автостарт виртуальных машин
Для того, чтобы при перезапуске хоста виртуальная машина vm1 запускалась автоматически:
# virsh autostart vm1
Domain vm1 marked as autostarted
Выключить автостарт для vm1:
# virsh autostart vm1 —disable Domain vm1 unmarked as autostarted
Контроль сетевой активности виртуальной машины KVM
Может быть полезным оценивать сетевую активность виртуальной машины — например, сколько трафика она потребила. Также это может помочь при отладке сети или поиске утечек трафика. Например:
# virsh domifstat vm1 vnet0 vnet0 rx_bytes 3063962 vnet0 rx_packets 3412 vnet0 rx_errs 0 vnet0 rx_drop 0 vnet0 tx_bytes 591996 vnet0 tx_packets 1731 vnet0 tx_errs 0 vnet0 tx_drop 0
Тут все понятно, кроме откуда взять название адаптера vnet0. Можно в дампе конфигурации вирт. машины (virsh dumpxml vm1) найти секцию network и в ней параметр dev:
Подключение и отключение привода cdrom
Подключить к vm3 iso-образ в качестве cdrom:
# virsh attach-disk vm3 /data/vms-iso/CentOS-7-x86_64-Minimal-1511.iso hda —type cdrom —mode readonly
Disk attached successfully
Здесь надо быть внимательным, т.к. после пути до iso-файла на хосте идет указание имени устройства cdrom у виртуальной машины vm3. Если вы не уверены, какое имя устройства надо указать (hda, hdb или др.), сверьтесь с конфигурацией виртуальной машины:
Отключить iso-образ (не удалить устройство из гостя, а просто «извлечь cd-диск из привода»):
# virsh attach-disk vm5 «» hda —type cdrom —mode readonly
А еще созданные виртуальные машины можно клонировать. Удачи!
08.07.2017 04:51 korshuhn999
Процесс ступорится после запуска virt-install. Стоит на Waiting for installation to complete. В чем может быть пролема?
10.07.2017 11:38 bzzz
Не факт, что это проблема. Попробуйте открыть вторую терминальную сессию, скорее всего vm готова. Было такое пару раз. Не дождался, убедился, что все ок и в первой сессии просто Ctrl-C.
Авторизуйтесь для добавления комментариев!

Почтовый сервер Mikrotik VPN 3proxy Шифрование Squid Резервное копирование Защита почты Виртуальные машины Настройка сервера java kvm Групповые политики SELinux OpenVPN IPFW WDS Lightsquid Samba firewalld systemd Mobile libvirt Remote desktop WiFi Iptables NAT Postfix Dovecot Удаление данных Софт Безопасность Winbox User agent Хостинг Передача данных Онлайн сервисы Privacy LetsEncrypt VPN сервер Настройка прокси RRDTool sendmail Rsync Linux SSH Система Windows Синхронизация Облако fail2ban FreeBSD