Com o Ubuntu 16.04 e o KVM, não consigo fazer a vms fazer a rede sem usar o NAT

Question

Estou tentando obter uma VM em execução no KVM que age como se tivesse sua própria interface de rede física na rede local. Eu acredito que isso é chamado de ponte, e eu tentei seguir um número de guias diferentes on-line, sem sorte. Toda vez que acabo com uma VM que tem um adaptador de rede virtual que não pode falar com minha rede local.

Meu anfitrião e convidados estão todos executando o servidor Ubuntu 16.04.

Comecei adicionando um br0 ao meu arquivo /etc/network/interfaces , que agora é assim:

~$ cat /etc/network/interfaces
source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

iface enp2s0 inet manual

auto br0
iface br0 inet dhcp
  bridge_ports enp2s0
  bridge_stp off
  bridge_fd 0
  bridge_maxwait 0

Após a reinicialização, meu ifconfig se parece com isto:

~$ ifconfig
br0       Link encap:Ethernet  HWaddr d0:50:99:c0:25:fb
          inet addr:192.168.113.2  Bcast:192.168.113.255  Mask:255.255.255.0
          ...

docker0   Link encap:Ethernet  HWaddr 02:42:dc:4f:96:9e
          ...

enp2s0    Link encap:Ethernet  HWaddr d0:50:99:c0:25:fb
          inet6 addr: fe80::d250:99ff:fec0:25fb/64 Scope:Link
          ...

lo        Link encap:Local Loopback
          ...

veth009cb0a Link encap:Ethernet  HWaddr 66:d6:6c:e7:80:cb
          inet6 addr: fe80::64d6:6cff:fee7:80cb/64 Scope:Link
          ...

virbr0    Link encap:Ethernet  HWaddr 52:54:00:1a:56:65
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          ...

O host tem uma entrada estática no meu servidor DHCP, de modo que sempre obtém 192.168.113.2, de modo que o IP na br0 esteja correto. Pelo que entendi, tudo que eu preciso fazer agora é iniciar uma nova vm usando a interface br0. Então eu corro isso:

sudo virt-install --virt-type=kvm --name myvm \
--hvm --ram 4096 --vcpus=2 --graphics vnc \
--network bridge=br0 \
--os-type=linux --os-variant=ubuntu16.04 \
--cdrom=/var/lib/libvirt/boot/ubuntu-16.04.2-server-amd64.iso \
--disk path=/var/lib/libvirt/images/myvm.qcow2,size=16,bus=virtio,format=qcow2

Eu posso VNC para a vm e progredir até a instalação neste momento, até chegar à fase "Configurando a rede com DHCP", no qual o tempo limite e nunca obterá um IP.

Se eu usar a interface NAT padrão, ela funciona bem, obtém um IP no intervalo 192.168.112.xxx e pode acessar a rede local e a Internet maior, sem problemas. Se eu alterar a configuração do virsh nessa vm de trabalho para fazer a ponte com br0, não posso falar com nenhuma rede, local ou de outra forma. O DHCP não consegue obter um IP e definir um IP estático não gera tráfego no exterior.

Caso seja útil, enquanto o instalador estava em execução, abri outro terminal e obtive mais informações do host:

~$ brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.d05099c025fb       no              enp2s0
                                                        vnet0
docker0         8000.0242dc4f969e       no              veth009cb0a
virbr0          8000.5254001a5665       yes             virbr0-nic

~$ brctl showmacs br0
port no mac addr                is local?       ageing timer
  1     00:04:20:eb:7e:96       no                 3.90
  1     00:11:32:63:9c:cf       no                 1.86
  1     30:46:9a:0f:81:cd       no                 3.39
  1     44:8a:5b:9e:d1:90       no                 0.00
  1     88:de:a9:13:86:48       no                 0.29
  1     b8:ae:ed:73:3e:ca       no                 3.89
  1     d0:50:99:c0:25:fb       yes                0.00
  1     d0:50:99:c0:25:fb       yes                0.00
  1     d0:50:99:e0:21:46       no                 2.90
  1     f0:f6:1c:e3:7f:be       no               173.56
  2     fe:54:00:6f:b8:64       yes                0.00
  2     fe:54:00:6f:b8:64       yes                0.00

~$ ip route
default via 192.168.113.1 dev br0
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1
192.168.113.0/24 dev br0  proto kernel  scope link  src 192.168.113.2
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 linkdown

Estou disposto a jogar o dumpxml inteiro aqui se alguém quiser, mas aqui está apenas a seção de rede:

<interface type='bridge'>
  <mac address='52:54:00:6f:b8:64'/>
  <source bridge='br0'/>
  <model type='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

ATUALIZAÇÃO 2017-03-25 : Alterando o seguinte:

    <interface type='network'>
      <mac address='52:54:00:6f:b8:64'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

Então o NAT funciona e eu recebo o IP 192.168.122.xxx, e posso falar com serviços externos, etc. Então ... há algo errado com meus hosts br0? Em caso afirmativo, por que o host obtém um IP muito bem? Existem alguns dispositivos ethernet que simplesmente não suportam bridge? Aqui está o resultado do lspci no host:

~$ lspci | grep Ethernet
02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
03:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)

Eu não configurei o segundo controlador de ethernet, talvez eu o configure e tente conectá-lo.

UPDATE 2017-03-25 b : A segunda interface não pareceu alterar os resultados. Aqui está o / etc / network / interfaces resultante:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto enp2s0
iface enp2s0 inet dhcp

auto enp3s0
iface enp3s0 inet manual

auto br0
iface br0 inet dhcp
  bridge_ports enp3s0
  bridge_stp off
  bridge_fd 0
  bridge_maxwait 0

Que, quando eu ip a , resulta em:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d0:50:99:c0:25:fb brd ff:ff:ff:ff:ff:ff
    inet 192.168.113.2/24 brd 192.168.113.255 scope global enp2s0
      valid_lft forever preferred_lft forever
    inet6 fe80::d250:99ff:fec0:25fb/64 scope link
      valid_lft forever preferred_lft forever
3: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether d0:50:99:c0:25:fa brd ff:ff:ff:ff:ff:ff
    inet6 fe80::d250:99ff:fec0:25fa/64 scope link
      valid_lft forever preferred_lft forever
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether d0:50:99:c0:25:fa brd ff:ff:ff:ff:ff:ff
    inet 192.168.113.100/24 brd 192.168.113.255 scope global br0
      valid_lft forever preferred_lft forever
    inet6 fe80::d250:99ff:fec0:25fa/64 scope link
      valid_lft forever preferred_lft forever
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:1a:56:65 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
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:1a:56:65 brd ff:ff:ff:ff:ff:ff
7: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:18:2c:73:bb brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
      valid_lft forever preferred_lft forever
    inet6 fe80::42:18ff:fe2c:73bb/64 scope link
      valid_lft forever preferred_lft forever
9: vethaa3cd40@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
    link/ether ae:05:f7:1b:f9:9e brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::ac05:f7ff:fe1b:f99e/64 scope link
      valid_lft forever preferred_lft forever
10: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:3a:54:b3 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe3a:54b3/64 scope link
      valid_lft forever preferred_lft forever

A VM continua a ter exatamente os mesmos problemas quando solicitada a usar br0.

    

Answer 1

Resolvido.

O problema foram as configurações padrão no módulo br_netfilter, que envia pacotes em ponte para o iptables. Os documentos da libvirt mencionam isso na página de rede deles , mas a maioria dos tutoriais que eu tinha seguinte não cobri-lo.

Por alguma razão, o iptables estava comendo esses pacotes (talvez algo docker foi adicionado?), mas enviar esses pacotes para o iptables é aparentemente ineficiente, então a correção é ignorar o iptables alterando essas configurações.

Observe que o método que delineio aqui é, na verdade, um exemplo na página do sysctl.d .

Crie um /etc/udev/rules.d/99-bridge.rules e insira esta linha:

ACTION=="add", SUBSYSTEM=="module", KERNEL=="br_netfilter", RUN+="/lib/systemd/systemd-sysctl --prefix=/net/bridge"

Em seguida, crie um /etc/sysctl.d/bridge.conf e insira essas três linhas:

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

Então eu tive que reverter para minha configuração de bridge original, que envolve um /etc/network/interfaces que se parece com isso:

source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto enp2s0
iface enp2s0 inet manual
auto br0
iface br0 inet dhcp
  bridge_ports enp2s0
  bridge_stp off
  bridge_fd 0
  bridge_maxwait 0

E uma definição de interface de rede virsh que se parece com isso:

<interface type='bridge'>
  <mac address='52:54:00:37:e1:55'/>
  <source bridge='br0'/>
  <model type='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

Com tudo isso no lugar, minha VM inicializa, obtém um IP e posso falar livremente com meu host, a rede local e a Internet.

    

Answer 2

Eu consegui que funcionasse, usando direto ao invés de bridge:

Usando este /etc/network/interfaces

source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto enp2s0
iface enp2s0 inet dhcp
auto enp3s0
iface enp3s0 inet manual

E esta configuração virsh:

<interface type='direct'>
  <mac address='52:54:00:37:e1:55'/>
  <source dev='enp3s0' mode='vepa'/>
  <target dev='macvtap0'/>
  <model type='rtl8139'/>
  <alias name='net0'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

Minha rede local vê o endereço mac 52: 54: 00: 37: e1: 55, e o servidor DHCP fornece um IP, e eu posso enviar ssh para esta máquina através desse IP, então tudo parece bom. Eu posso executar uma segunda VM simultaneamente, seu MAC também obtém um IP, então eu pareço ter a solução que queria.

Talvez no próximo eu tente fazer tudo isso na porta ethernet original. Também estou curioso para saber o que realmente é a ponte, e o que resolve isso direto não, se alguém ler isso tiver uma resposta. Obrigado!

UPDATE : O problema dessa solução é que as VMs que compartilham uma única interface física não conseguem falar umas com as outras. O mesmo acontece com o host, quando o host e as VMs compartilham a mesma interface física.

Eu suspeito que esse seja o problema que a ponte deveria resolver, mas eu realmente poderia usar alguma orientação de alguém com alguma experiência com essas coisas.