Виртуальные сети и виртуальные машины в azure

Настройка рабочих групп

После проведенных нами операций перезагружаем сначала виртуальную машину, а затем и host-машину. После того как наша реальная операционная система загрузилась, запускаем VirtualBox и включаем нашу виртуальную машину и на host-машине (Windows Vista) открываем «Карту сети»:

Рис.11: «Карта сети» после настроек виртуальной машины

Тут мы видим host-машину (HPPavilion-PC) и подключенную через два адаптера (Bridge Ethernet Adapter и Virtual Host-Only Ethernet Adapter) виртуальную машину (Virtual-PC). Для большей наглядности на изображении приведены краткие комментарии.

Самое главное – мы видим наши обе машины, то же самое можно определить, запустив сеанс командной строки на обеих машинах и выполнив в нем команду net view. На изображении ниже (рис.12) приведены результаты отработки данной команды – справа для Windows Vista, слева для Windows XP.

Рис.12: Результат выполнения команды net view

Теперь определимся с рабочими группами – в сети Интернет часто приводится некое требование, согласно которому обе машины должны находиться в одной рабочей группе, но это не так. В нашем случае рабочие группы разные, т.к. по умолчанию ОС Windows XP включена в Workgroup, а Windows Vista в MShome.

Чтобы увидеть, что это означает, перейдем в папку «Сетевое окружение» на нашей виртуальной машине. В данном расположении мы видим две рабочие группы — Workgroup и MShome:

Рис.13: Разные рабочие группы

Откроем рабочую группу MShome и увидим нашу host-машину (HPPavilion-PC).

Рис.14:  Рабочая группа MShome и host-машина (HPPavilion-PC).

Вернемся на шаг назад и откроем рабочую группу Workgroup, в ней мы увидим нашу виртуальную машину (Virtual-PC).

Рис.15:  Рабочая группа Workgroup и виртуальная машина (Virtual-PC).

Несмотря на то, что все работает, перенесем Virtual-PC, т.е. нашу виртуальную машину, в ту же рабочую группу, что и host-машина (HPPavilion-PC). Для этого откроем свойства Мой Компьютер, перейдем на вкладку «Имя компьютера» и нажмем кнопку «Изменить». В открывшемся окне в поле «Рабочая группа» введем имя рабочей группы, в которой состоит реальная машина (в нашем случае MShome), чтобы увидеть результат перейдем в папку «Сетевое окружение» обеих машин и убедимся, что обе станции находятся в одной рабочей группе.

Посмотрим, что у нас получилось сначала на нашей виртуальной машине Windows XP:

Рис.16:  Общая рабочая группа на виртуальной машине

А теперь на host-машине Windows Vista:

Рис.17:  Общая рабочая группа на host-машине

Отключение netfilter для моста

Чтобы разрешить пересылку всего трафика на мост и, следовательно, на подключенные к нему виртуальные машины, нам нужно отключить netfilter. Это необходимо, например, для работы разрешения DNS на гостевых машинах, подключенных к мосту. Для этого мы можем создать файл с расширение внутри каталог, назовем его . Внутри мы пишем следующий контент:

net.bridge.bridge-nf-call-ip6tables = 0. net.bridge.bridge-nf-call-iptables = 0. net.bridge.bridge-nf-call-arptables = 0. 

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

$ sudo modprobe br_netfilter. 

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

br_netfilter. 

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

$ sudo sysctl -p /etc/sysctl.d/99-netfilter-bridge.conf. 

Use virtio for Ubuntu or Windows guests

For Windows guests follow this instruction.

You may find the performances of the network relatively poor (approx. 100/120mbits on my servers, which are quite fast). Make sure that you enable virtio. Go to the definition file of your VM, and add the virtio line to the definition of your network interface:

    <interface type='bridge'>
      <mac address='52:54:00:a0:41:92'/>
      <source bridge='br0'/>
      <model type='virtio'/>   <-- add this line, leave the rest
    </interface>

Or, if you’re using KVM on the command line, add the options:

-net nic,model=virtio -net user

This improves the network performances by a lot (nearly a factor of 10) and corrects an issue some people reported with their network connections going away after a period of time or data transfer.

Multiple nics with multiple subnets (VLANs)

You may experience some KVM host connectivity issues when using multiple nics, each on their own subnet/vlan (multiple default routes?). In my case SSH logins (to the KVM host) would take a long time and connectivity would be cut when I restarted the network interfaces making ssh sessions and virt-manager connections crash.

I needed multiple nics, each to be on a separate subnet (vlan). Each nic is then dedicated to a specific VM on the KVM host. The VMs then connect directly to the network using a bridge device.

I never experienced problems with KVM guest connectivity. Only the KVM Host.

I fixed the problem using the following configuration in /etc/network/interfaces on the KVM host. Please note the use of «manual» and «metric». YMMV.

Note: first make sure that the guest OS loads the right network drivers. This worked for me: remove network modules 8139cp and 8139 too, then modprobe 8139cp

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp
        metric 0
###################

auto eth1
iface eth1 inet manual

auto br1
iface br1 inet dhcp
        bridge_ports eth1
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0
        metric 1
###################

auto eth2
iface eth2 inet manual
        
auto br2
iface br2 inet dhcp
        bridge_ports eth2
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0
        metric 1
###################

# add more ethN and brN as needed

IP Aliases

IP aliases provide a convenient way to give VM guests their own external IPs:

1. Set up bridged networking.

2. Create necessary IP aliases in the host as usual: put in /etc/network/interfaces, e.g.,

auto eth0:0
iface eth0:0 inet static
address 192.168.0.11
netmask 255.255.255.0

3. Hardwire the guest’s IP, either changing it to static, e.g., as 192.168.122.99, in /etc/network/interfaces in the guest or with a host entry in dhcp configuration (see below).

4. Enable routing in the host: uncomment net.ipv4.ip_forward=1 in /etc/sysctl.conf (/etc/ufw/sysctl.conf if using ufw), or temporarily with echo 1 >/proc/sys/net/ipv4/ip_forward.

5. Change virtlib forward from nat to route and adjust dhcp range to exclude the address used for guest (optionally, add host entry for it): virsh net-edit default and change the xml to something like this:

<network>
  <name>default</name>
  <uuid>12345678-1234-1234-1234-123456789abc</uuid>
  <forward mode='route'/>
  <bridge name='virbr0' stp='on' delay='0' />
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.100' end='192.168.122.254' />
      <host mac"=00:11:22:33:44:55" name="guest.example.com" ip="192.168.122.99" />
    </dhcp>
  </ip>
</network>

6. Direct traffic from external interface to internal and back:

iptables -t nat -A PREROUTING -d 192.168.0.11 -j DNAT --to-destination 192.168.122.99
iptables -t nat -A POSTROUTING -s 192.168.122.99 -j SNAT --to-source 192.168.0.11

Where to put those depends on your firewall setup; if you use ufw you might use /etc/ufw/before.rules. You might also need to adjust your firewall filtering rules.

Общая информация

Паравиртуализация — это популярный метод, имеющий сходство с полной виртуализацией. Гостевые ОС подготовливаются для исполнения в виртуализированной среде, для чего интегрируется код виртуализации в саму операционную систему. Этот подход позволяет избежать любой перекомпиляции или перехвата команд, поскольку операционная система сама участвует в процессе виртуализации. Цель изменения интерфейса — сокращение доли времени выполнения операций гостя, которые являются существенно более трудными для запуска в виртуальной среде. Подобно полной виртуализации множество различных операционных систем могут поддерживаться одновременно.

Паравиртуализацию используют SCSI, USB, VGA и PCI устройства.

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

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

Bridged networking (aka «shared physical device»)

Host configuration

The NAT based connectivity is useful for quick & easy deployments, or on machines with dynamic/sporadic networking connectivity. More advanced users will want to use full bridging, where the guest is connected directly to the LAN. The instructions for setting this up vary by distribution, and even by release.

Important Note: Unfortunately, wireless interfaces cannot be attached to a Linux host bridge, so if your connection to the external network is via a wireless interface («wlanX»), you will not be able to use this mode of networking for your guests.

Important Note: If, after trying to use the bridge interface, you find your network link becomes dead and refuses to work again, it might be that the router/switch upstream is blocking «unauthorized switches» in the network (for example, by detecting BPDU packets). You’ll have to change its configuration to explicitly allow the host machine/network port as a «switch».

Fedora/RHEL Bridging

This outlines how to setup briding using standard network initscripts and systemctl.

Using NetworkManager directly

If your distro was released some time after 2015 and uses NetworkManager, it likely supports bridging natively. See these instructions for creating a bridge directly with NetworkManager:

Disabling NetworkManager (for older distros)

If your distro was released before 2015, the NetworkManager version likely does not handle bridging, so it is necessary to use «classic» network initscripts for the bridge, and to explicitly mark them as independent from NetworkManager (the «NM_CONTROLLED=no» lines in the scripts below).

If desired, you can also completely disable NetworkManager:

# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network start
Creating network initscripts

In the /etc/sysconfig/network-scripts directory it is neccessary to create 2 config files. The first (ifcfg-eth0) defines your physical network interface, and says that it will be part of a bridge:

# cat > ifcfg-eth0 <<EOF
DEVICE=eth0
HWADDR=00:16:76:D6:C9:45
ONBOOT=yes
BRIDGE=br0
NM_CONTROLLED=no
EOF

Obviously change the HWADDR to match your actual NIC’s address. You may also wish to configure the device’s MTU here using e.g. MTU=9000.

The second config file (ifcfg-br0) defines the bridge device:

# cat > ifcfg-br0 <<EOF
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0
NM_CONTROLLED=no
EOF

WARNING: The line TYPE=Bridge is case-sensitive — it must have uppercase ‘B’ and lower case ‘ridge’

After changing this restart networking (or simply reboot)

 # service network restart

The final step is to disable netfilter on the bridge:

 # cat >> /etc/sysctl.conf <<EOF
 net.bridge.bridge-nf-call-ip6tables = 0
 net.bridge.bridge-nf-call-iptables = 0
 net.bridge.bridge-nf-call-arptables = 0
 EOF
 # sysctl -p /etc/sysctl.conf
# echo "-I FORWARD -m physdev --physdev-is-bridged -j ACCEPT" > /etc/sysconfig/iptables-forward-bridged
# lokkit --custom-rules=ipv4:filter:/etc/sysconfig/iptables-forward-bridged
# service libvirtd reload

You should now have a «shared physical device», to which guests can be attached and have full LAN access

 # brctl show
 bridge name     bridge id               STP enabled     interfaces
 virbr0          8000.000000000000       yes
 br0             8000.000e0cb30550       yes             eth0

Note how this bridge is completely independant of the virbr0. Do *NOT* attempt to attach a physical device to ‘virbr0’ — this is only for NAT connectivity

Debian/Ubuntu Bridging

Guest configuration

 <interface type='bridge'>
    <source bridge='br0'/>
    <mac address='00:16:3e:1a:b3:4a'/>
    <model type='virtio'/>   # try this if you experience problems with VLANs
 </interface>

NB, the mac address is optional and will be automatically generated if omitted.

To edit the virtual machine’s configuration, use:

virsh edit <VM name>

For more information, see the FAQ entry at:

Базовые команды управления ВМ

1. Получить список созданных машин:

virsh list —all

2. Включить / перезагрузить / выключить.

а) включить виртуальную машину можно командой:

virsh start FirstTest

* где FirstTest — имя созданной машины.

б) перезагрузить:

virsh reboot FirstTest

* посылает команду операционной системе на корректную перезагрузку.

в) выключить корректно:

virsh shutdown FirstTest

* посылает команду операционной системе на корректное выключение.

г) выключить принудительно:

virsh destroy FirstTest

* грубо выключает ВМ. Может привести к потере данных. Способ стоит применять при полном зависании виртуалки.

д) приостановить:

virsh suspend FirstTest

Для возобновления работы вводим команду:

virsh resume FirstTest

е) отправить команду всем гостевым операционным системам:

for i in $(virsh list —name —state-shutoff); do virsh start $i; done

for i in $(virsh list —name —state-running); do virsh shutdown $i; done

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

3. Разрешаем автостарт для созданной ВМ:

virsh autostart FirstTest

4. Удаление виртуальной машины:

Удаляем виртуальную машину:

virsh undefine FirstTest

Удаляем виртуальный жесткий диск:

\rm /kvm/images/FirstTest-disk1.img

* где /kvm/images — папка, где хранится диск; FirstTest-disk1.img — имя виртуальног диска для удаленной машины.

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

Открыть редактор для изменения конфигурации:

virsh edit FirstTest

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

а) изменить количество процессоров:

virsh setvcpus FirstTest 2 —config —maximum

virsh setvcpus FirstTest 2 —config

б) изменить объем оперативной памяти:

virsh setmaxmem FirstTest 2G —config

virsh setmem FirstTest 2G —config

6. Работа со снапшотами

а) Создать снимок виртуальной машины можно командой:

virsh snapshot-create-as —domain FirstTest —name FirstTest_snapshot_2020-03-21

* где FirstTest — название виртуальной машины; FirstTest_snapshot_2020-03-21 — название для снапшота.

б) Список снапшотов можно посмотреть командой:

virsh snapshot-list —domain FirstTest

* данной командой мы просмотрим список всех снапшотов для виртуальной машины FirstTest.

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

virsh shutdown FirstTest

После вводим:

virsh snapshot-revert —domain FirstTest —snapshotname FirstTest_snapshot_2020-03-21 —running

* где FirstTest — имя виртуальной машины; FirstTest_snapshot_2020-03-21 — имя созданного снапшота.

г) Удалить снапшот можно так:

virsh snapshot-delete —domain FirstTest —snapshotname FirstTest_snapshot_2020-03-21

7. Клонирование виртуальных машин

Для примера, склонируем виртуальную машину FirstTest и создадим новую SecondTest.

Для начала, мы должны остановить виртуалку:

virsh suspend FirstTest

После можно клонировать:

virt-clone —original FirstTest —name SecondTest —file /kvm/images/SecondTest-disk1.img

* итого, мы склонируем виртуальную машину FirstTest. Новая машина будет иметь название SecondTest, а путь до диска будет /kvm/images/SecondTest-disk1.img.

Восстанавливаем работу FirstTest:

virsh resume FirstTest

Configuring ubuntu-vm-builder to create bridged guests by default

This is handled by giving ubuntu-vm-builder the —bridge=br0 flag starting in karmic.

Virtual machines are defined in XML files; ubuntu-vm-builder, the tool we will use to create VMs, bases them on the template file /etc/vmbuilder/libvirt/libvirtxml.tmpl (before Ubuntu 8.10 /usr/share/ubuntu-vm-builder/templates/libvirt.tmpl). In older versions of Ubuntu this file needed a hardcoded change to replace <source network=’default’/> with <source bridge=’br0’/>.

In Ubuntu 10.04 (Lucid and probably later versions) the libvirtxml.tmpl file uses variables so set bridge=br0 in /etc/vmbuilder.cfg or ~/.vmbuilder.cfg (for system-wide or per-user configuration).

Below is an example /etc/vmbuilder.cfg file. To use it change at least example.com to your domain:

# Default is 1G tmpfs; Uncomment this line if you've >=2G of free RAM.
#tmpfs = suid,dev,size=2G

#arch = amd64
arch = i386
domain = example.com
part = vmbuilder.partition
user = localadmin
name = LocalAdmin
pass = default


libvirt = qemu:///system
#network = br0
bridge = br0
virtio_net = true


#mirror = http://127.0.0.1:9999/ubuntu
# If using package cache software (apt-proxy), uncomment line below and set correct IP and Port:
#install-mirror = http://127.0.0.1:9999/ubuntu
suite = lucid
flavour = virtual
#components = main,universe,restricted,multiverse
components = main,universe
# Example adding PPA and installing extra software packages after base OS installation:
#ppa = bcfg2/lucidtesting
#addpkg = openssh-server, unattended-upgrades, bcfg2, acpid

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

Перед созданием виртуальной машины, я скачал образ CentOS 8 с официального зеркала в директорию /vz/iso:

# cd /vz/iso && wget

1 # cd /vz/iso && wget

Чтобы создать новую виртуалную машину KVM, выполните:

virt-install -n test-centos \
—noautoconsole \
—network=bridge:br0 \
—ram 2048 —arch=x86_64 \
—vcpus=4 —cpu host —check-cpu \
—disk path=/vz/disk/test-centos.img,size=32 \
—cdrom /vz/iso/CentOS-8.1.1911-x86_64-dvd1.iso \
—graphics vnc,listen=IP,password=123456789 \
—os-type linux —os-variant=rhel7 —boot cdrom,hd,menu=on

1
2
3
4
5
6
7
8
9

virt-install-ntest-centos\

—noautoconsole\

—network=bridgebr0\

—ram2048—arch=x86_64\

—vcpus=4—cpu host—check-cpu\

—disk path=vzdisktest-centos.img,size=32\

—cdromvzisoCentOS-8.1.1911-x86_64-dvd1.iso\

—graphics vnc,listen=IP,password=123456789\

—os-type linux—os-variant=rhel7—boot cdrom,hd,menu=on

  • test-centos — имя ВМ;
  • noautoconsole – после создания не нужно подключаться к консоли виртуальной машины автоматически;
  • network – тип сети(в нашем случае bridge);
  • ram — количество оперативной памяти в ВМ;
  • vcpus – количество ядер процессора (настройка vCPU в KVM);
  • disk – виртуальный диск, path – путь до диска. size – объем (в дальнейшем его можно расширить/уменьшить);
  • сdrom – виртуальный cdrom, в который монтируется iso образ для установки гостевой ОС;
  • graphics — параметры подключения к машине с помощью графической консоли. Мы подключаемся через VNC, поэтому в listen указывает IP сервера, где создали ВМ и пароль для подключения в консоли виртуальной машины (password).

Чтобы ВМ загружалась автоматически, выполните:

# virsh autostart test-centos

1 # virsh autostart test-centos

[править] Создание сетевого интерфейса

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

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

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

Не путайте интерфейсы и
устройства системы. Интерфейсам не соответствуют
никакие специальные файлы в каталоге /dev

Вновь созданный интерфейс является ненастроенным: он выключен и к нему не
привязан никакой IP-адрес. Для того чтобы ввести интерфейс в работу, нужно
провести его настройку и включить (поднять) его при помощи команды
ifconfig.

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

  • IP-адрес должен быть указан обязательно, поскольку без него использование интерфейса неосуществимо;
  • Сетевая маска должна указываться в том случае, если она отличается от той, которая соответствует классу IP-адреса;
  • Широковещательный адрес указывается в том случае, если он отличается от широковещательного адреса, вычисляемого на основе значений IP-адреса и сетевой маски.

Эти параметры задаются одной командой, которая при этом, как правило, сразу и включает интерфейс.

# ifconfig eth0 192.168.1.1 up
# ifconfig eth1 10.0.0.1 netmask 255.255.255.0 up

NAT (Network Adress Translation)

Система трансляции адресов, весьма удобный способ раздачи сети между виртуальными машинами. Принцип действия такой, что в реальной системе создается виртуальный интерфейс (NAT), со своим собственным сетевым адресом (IP 1), в своей сети.

Все виртуальные машины, клиенты NAT, берут адреса из этой виртуальной сети с адресом шлюза IP 1. Этот NAT-адрес реальной машины может быть привязан к реальному интерфейсу, и все клиенты могут получить доступ к внешней сети. Их адреса будут подменяться на адрес интерфейса и обратно, таким образом происходит трансляция целой подсети в IP адрес. Для меня этот способ был наиболее удобным в VMWare, чтобы доставить Интернет на виртуальную машину. При этом в сети заводил ещё DHCP сервер и стоило только установить любой виртуальный интерфейс в NAT, как ему тут же назначался адрес и он мог выходить в Internet. Удобно. В чем отличие от Bridge? Виртуальных интерфейсов может быть много, все они привязываются (транслируются) через один реальный. В Bridge происходит привязка 1 к 1, т.е. на каждую виртуальную машину потребовался бы свой физический интерфейс, что весьма накладно.

NAT

Пример. определяемая пользователем маршрутизация

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

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

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

Подсети используют системные маршруты, пока таблица маршрутизации не будет связана с подсетью. После существования ассоциации Маршрутизация выполняется на основе наибольшего соответствия префиксов (LPM) как для определяемых пользователем маршрутов, так и для системных маршрутов. Если существует несколько маршрутов с одинаковым совпадением LPM, то определяемый пользователем маршрут выбирается первым перед системным маршрутом.

PROCEDURE

Установка KVM в CentOS

При настройке KVM на сервере, нужно начать с проверки вашего процессора. Нужно узнать, поддерживает ли аппаратную виртуализацию CPU, установленный на вашем сервере. Из консоли сервера, выполните команду:

# cat /proc/cpuinfo | egrep «(vmx|svm)»

1 # cat /proc/cpuinfo | egrep «(vmx|svm)»

Если ваш процессор поддерживает технологию VT-x, у вас должен быть примерно такой вывод:

Если же команда ничего не выдала, но ваш процессор точно поддерживает виртуализацию, проверьте, вохможно данная опция отключена в BIOS сервера. Ищите параметры “Intel Virtualization Technology” или “SVM MODE”.

На моем сервере поддержка данной технологии включена, поэтому можно приступать к установке необходимых компонентов в CentOS через пакетный менеджер yum/dnf:

# yum install libvirt libvirt-python libguestfs-tools qemu-kvm virt-install –y

1 # yum install libvirt libvirt-python libguestfs-tools qemu-kvm virt-install –y
  • qemu-kvm – сам гипервизор KVM;
  • libvirt – библиотеки управления вирилизацией;
  • virt-install – команды для управления виртуальными машинами KVM.

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

Теперь нужно добавить сервис libvirtd в автозагрузку и запустить его:

# systemctl enable libvirtd
# systemctl start libvirtd

1
2

# systemctl enable libvirtd
# systemctl start libvirtd

Проверьте, загрузились ли модули ядра kvm_intel и kvm:

# lsmod | grep kvm

1 root@localhost# lsmod | grep kvm

kvm_intel 188688 0
kvm 636931 1 kvm_intel
irqbypass 13503 1 kvm

1
2
3

kvm_intel188688

kvm6369311kvm_intel

irqbypass135031kvm

Если у вас ничего не выводится, перезагрузите сервер и проверьте повторно.

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Все про сервера
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: