Вопросы Теги

KVM с общедоступным статический IP-адрес требует перезапуска сети каждый раз

Я установил kvm vm с общедоступным статическим IP, и все работает нормально, но только после перезапуска сети на хосте. Я имею в виду, что каждый раз после включения хоста я должен запускать «перезапуск сервисной сети» и только после этого виртуальная машина KVM получает IP. Без перезапуска ip принадлежит хосту.

Хост - centos 7, гость - ubuntu 12.04

Пожалуйста, посоветуйте мне, как сделать IP принадлежащим только ВМ, без перезагрузки сети? Спасибо!

Мои настройки на хосте:

/ etc / sysconfig / network-scripts / ifcfg-enp1s0f1: 

DEVICE="enp1s0f1"
ONBOOT=yes
HWADDR="xx:xx:xx:xx:xx:xx"
BRIDGE=br0

/ etc / sysconfig / network-scripts / ifcfg-br0: 

DEVICE="br0"
TYPE=BRIDGE
ONBOOT=yes
BOOTPROTO=static
IPADDR="host.ip.adress"
NETMASK="255.255.252.0"
GATEWAY="host.gateway"
DNS1=11.11.11.11
DNS2=11.11.11.11

/ etc / sysconfig / network-scripts / ifcfg-br0: 1 

DEVICE="br0:1"
TYPE=BRIDGE
ONBOOT=yes
BOOTPROTO=static
IPADDR="ip.for.kvm.vm"
NETMASK="255.255.252.0"
GATEWAY="host.gateway"
DNS1=11.11.11.11
DNS2=11.11.11.11

vm bridge section 

 <interface type='bridge'>
      <mac address='yy.yy.yy.yy.yy.yy'/>
      <source bridge='br0:1'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </interface>

my 'ip a' 

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: enp1s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP qlen 1000
    link/ether xx:xx:xx:xx:xx:75 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
    link/ether zz:zz:zz:zz:zz:zz brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000
    link/ether 52...4:98 brd ff:ff:ff:ff:ff:ff
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether xx:xx:xx:xx:xx:75 brd ff:ff:ff:ff:ff:ff
    inet host.ip.adress/22 brd ...3.255 scope global br0
       valid_lft forever preferred_lft forever
    inet ip.for.kvm.vm/22 brd ...3.255 scope global secondary br0:1
       valid_lft forever preferred_lft forever
    inet6 fe8...5/64 scope link 
       valid_lft forever preferred_lft forever
7: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN qlen 1000
    link/ether fe:5...1:6a brd ff:ff:ff:ff:ff:ff
    inet6 fe80...:516a/64 scope link 
       valid_lft forever preferred_lft forever

Мои настройки на гостевой системе: 

auto eth0
iface eth0 inet static
    address ip.for.kvm.vm
    netmask 255.255.255.0
    gateway host.gateway
    broadcast 
    hwaddress ether 52:54:00:2f:21:8b
    dns-nameservers 11.11.11.11 8.8.8.8 11.11.11.11

ip route show (на хосте) 

default via host.gateway dev br0  proto static  metric 425 
89.108.120.0/22 dev br0  proto kernel  scope link  src host.ip.adress  metric 425 
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1

route -n (on хост) 

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         host.gateway    0.0.0.0         UG    425    0        0 br0
89.108.120.0    0.0.0.0         255.255.252.0   U     425    0        0 br0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
0
задан 15 October 2017 в 11:54
1 ответ

Вы запутали адреса вашего хоста и гостя, поэтому мне придется использовать другие данные, которые вы предоставили, чтобы сделать утверждение, а также предположить, что "ip.for.kvm .vm "соответствует всем вашим примерам. Пожалуйста, дайте мне знать, если это неправильно.

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

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

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

0
ответ дан 5 December 2019 в 07:18

Теги

Похожие вопросы