O Fedora VM perde a conexão de rede no host suspender? reconecta após o login do GNOME?

Question

Eu tenho uma VM do Fedora 26. Quando entro no GNOME, ele mostra uma conexão com a rede. O GNOME mostra o perfil de rede do dispositivo como "Conectar automaticamente" e "Compartilhado com todos os usuários" (na seção Identidade). E eu posso SSH para a VM ... Mas às vezes eu acho que não consigo SSH. Até que depois eu faça o login no gdm (GNOME) primeiro.

Isso não acontece se eu reiniciar a VM. Então eu acho que está acontecendo quando eu suspendo o host com a VM ainda em execução (mas não logado?).

O que está acontecendo na VM quando entro no GNOME, o que faz com que ele se reconecte? A perda de conexão é um bug que pode ser corrigido no software?

systemctl status mostra o NetworkManager e o network.service como estando no estado padrão fornecido pelo SO:

● network.service - LSB: Bring up/down networking
   Loaded: loaded (/etc/rc.d/init.d/network; generated; vendor preset: disabled)

● NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2017-09-17 17:43:48 BST; 1 day 15h ago

nmcli após o login:

$ nmcli con
NAME                UUID                                  TYPE            DEVICE 
Wired connection 1  937653fb-890f-3b19-97b8-b98c8eafcdc5  802-3-ethernet  ens3   
virbr0              6e568806-d720-42ed-a555-0a1c50f1a36c  bridge          virbr0 
ens3                afba101e-6470-3699-b87b-932ab4efe634  802-3-ethernet  --

Eu só consigo encontrar arquivos de configuração para a conexão não usada "ens3", que é para um dispositivo anterior com um endereço MAC diferente. A VM é um clone atualizado de uma VM Fedora 25; presumivelmente, o endereço MAC foi alterado quando clonado.

$ cd /etc/NetworkManager/system-connections/ && ls
$ cd /etc/sysconfig/network-scripts/ && ls ifcfg-*
ifcfg-ens3
ifcfg-lo
$ cat ifcfg-ens3
HWADDR=52:54:00:A7:3B:22
TYPE=Ethernet
BOOTPROTO=dhcp
...
NAME=ens3
UUID=afba101e-6470-3699-b87b-932ab4efe634
ONBOOT=yes
AUTOCONNECT_PRIORITY=-999
$ ip link show dev ens3
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:59:9b:47 brd ff:ff:ff:ff:ff:ff

    

Answer 1

O log do sistema mostra que ele não está efetuando login no GNOME que corrige o problema, mas apenas aguardando 2 minutos:).

$ journalctl -b -u NetworkManager
...
Sep 18 23:04:35 fedora26-vm dhclient[15040]: bound to 192.168.122.157 -- renewal in 1450 seconds.
Sep 19 08:45:51 fedora26-vm NetworkManager[656]: <info>  [1505807151.7261] dhcp4 (ens3): state changed bound -> expire
Sep 19 08:45:51 fedora26-vm NetworkManager[656]: <info>  [1505807151.7698] dhcp4 (ens3): canceled DHCP transaction, DHCP client pid 15040
Sep 19 08:45:51 fedora26-vm NetworkManager[656]: <info>  [1505807151.7699] dhcp4 (ens3): state changed expire -> done
Sep 19 08:45:51 fedora26-vm NetworkManager[656]: <info>  [1505807151.7701] device (ens3): scheduling DHCPv4 restart in 120 seconds, 3 tries left (reason: lease expired)
Sep 19 08:47:51 fedora26-vm NetworkManager[656]: <info>  [1505807271.7908] dhcp4 (ens3): activation: beginning transaction (timeout in 45 seconds)
Sep 19 08:47:51 fedora26-vm NetworkManager[656]: <info>  [1505807271.7972] dhcp4 (ens3): dhclient started with pid 15271
Sep 19 08:47:51 fedora26-vm dhclient[15271]: DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 5 (xid=0x37e5e131)
Sep 19 08:47:51 fedora26-vm dhclient[15271]: DHCPREQUEST on ens3 to 255.255.255.255 port 67 (xid=0x37e5e131)
Sep 19 08:47:51 fedora26-vm dhclient[15271]: DHCPOFFER from 192.168.122.1
Sep 19 08:47:51 fedora26-vm dhclient[15271]: DHCPACK from 192.168.122.1 (xid=0x37e5e131)
...

(08:45:51 é exatamente quando os registros do host mostram o sistema sendo ativado da suspensão).

A concessão do DHCP está sendo reconhecida corretamente como expirada. Mas o sistema não parece perceber que não tentou renovar o contrato antecipadamente; Ele supõe que ele já tenha tentado e falhado e, portanto, define um tempo limite antes de reiniciar novamente. Parece um bug para mim.