Arch Linux - não receba nenhum ipv4 em vm's

1

Eu tenho desde alguns dias um problema com a minha conexão de rede em cada vm. Não importa se o Windows ou o Linux.

Meu sistema host baseado no Arch Linux com interfaces configuradas por systemd-networkd. Aqui estão meus arquivos de configuração para todas as interfaces.

/etc/systemd/network/10-bo0.netdev

[NetDev]
Name=bo0
Kind=bond

[Bond]
Mode=802.3ad
TransmitHashPolicy=layer3+4
MIIMonitorSec=1s
LACPTransmitRate=fast

/etc/systemd/network/10-br0.netdev

[NetDev]
Name=br0
Kind=bridge

/etc/systemd/network/eno1.network

[Match]
Name=eno1

[Network]
Bond=bo0

/etc/systemd/network/enp14s0.network

[Match]
Name=enp14s0

[Network]
Bond=bo0

/etc/systemd/network/20-bo0.network

[Match]
Name=bo0

[Network]
Bridge=br0
BindCarrier=eno1 enp14s0

/etc/systemd/network/25-br0.network

[Match]
Name=br0

[Network]
DHCP=yes
BindCarrier=bo0

[DHCP]
RouteMetric=10

Minha conexão no sistema host é estabelecida corretamente.

markus@markus-pc:~$ ip a | awk '{ print "    " $0 }'
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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: enp14s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bo0 state UP group default qlen 1000
    link/ether d6:58:88:05:c9:60 brd ff:ff:ff:ff:ff:ff
3: eno1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bo0 state UP group default qlen 1000
    link/ether d6:58:88:05:c9:60 brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether f6:11:0f:03:bf:b1 brd ff:ff:ff:ff:ff:ff
    inet 192.168.179.20/24 brd 192.168.179.255 scope global dynamic br0
       valid_lft 854751sec preferred_lft 854751sec
    inet6 2001:16b8:2efc:3900:f411:fff:fe03:bfb1/64 scope global dynamic noprefixroute 
       valid_lft 6755sec preferred_lft 3155sec
    inet6 fe80::f411:fff:fe03:bfb1/64 scope link 
       valid_lft forever preferred_lft forever
5: bo0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
    link/ether d6:58:88:05:c9:60 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::d458:88ff:fe05:c960/64 scope link 
       valid_lft forever preferred_lft forever
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:aa:68:d9:a1 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
7: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:17:2b:75 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe17:2b75/64 scope link 
       valid_lft forever preferred_lft forever

Eu não sei se desde a atualização do Arch Linux algo foi alterado nas configurações padrão do firewall ou simplesmente meus vm não recebem ofertas DHCP do meu roteador.

Como posso verificar se minha máquina virtual recebe uma oferta de DHCP ou algo assim, então resolva meu problema de IPv4.

Algumas outras informações:

  • Kernel Linux: Linux 4.18.6-arch1-1-ARCH
  • qemu 3.0.0
por Volker Raschek 14.09.2018 / 18:02

1 resposta

0

Então, depois de algumas escavações eu encontrei algo.

Primeiro eu fiz alguns downgrade sistemáticos da maioria dos pacotes envolvidos para ver se havia algo errado. Então eu fiz com libvirt, virt-manager, qemu, iptables, ebtables, dnsmasq mas não encontrei nada de impacto. Ainda não há ip em uma vm.

Eu costumo usar o pacaur para compilar o kernel linux-vfio do aur. Depois de um SSD Failure recente, eu não tinha nenhum pacaur-cache, então fazer downgrade para um kernel mais antigo (im at 4.18.9-vfio atm) não era uma opção. Então eu tentei alguns dos kernels tradicionais que eu tinha em / var / cache / pacman / pkg. Os últimos 4,18,9 nada fizeram para melhorar a situação. Mas 4.16.8-1 fez. Começando com ele eu recebo ip na vms novamente. Em alguns dias eu vou afundar mais um pouco e identificar onde está o problema.

Felizmente, não preciso das VMs com frequência.

edite: por estranho que pareça, o kernel de 4.14.71 lts também não fornece o endereço ip. Portanto, deve haver um patch um pouco recente que está em falta aqui.

    
por 25.09.2018 / 22:10