Anyone seen VM behaviour change since U2? - VMs are 'pausing' ?

[diskdiddler]

My UbuntuVM which is the lifeblood of my server, has been 'paused' or off lately, when I go to it in some (not all) mornings.
I ping, no response.
The docker containers, can't see the web interfaces.
I check running VMs in the TrueNAS core UI, it's on.
As soon as I connect via VNC to the UI, it feels like it wakes up.
(Note, the uptime is 20 hours after rebooting yesterday, so it's not a reboot and no, it's not "Delay VM Boot Until VNC Connects" that's also disabled)

Here's me pinging it, then it waking up

imgur.com

Discover the magic of the internet at Imgur, a community powered entertainment destination. Lift your spirits with funny jokes, trending memes, entertaining gifs, inspiring stories, viral videos, and so much more from users.

imgur.com

Anyone else seen this?

 

[Samuel Tai]

Please describe your hardware, per the Forum Rules. This is usually a problem with ARP timeouts in the host bridge.

 

[diskdiddler]

Look at my signature? I've been posting here for 7 years.

 

[Samuel Tai]

Not enough info. Are you using the em driver? Can you provide the output of ifconfig -a?

 

[diskdiddler]

What is an 'em' driver?

ifconfig from the linux VM or from TN?

 

[Samuel Tai]

From TN.

 

[diskdiddler]

Code:

ix0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

        description: ix0

        options=a538b9<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6>

        ether ac:1f:6b:48:76:f4

        inet 192.168.0.9 netmask 0xffffff00 broadcast 192.168.0.255

        media: Ethernet autoselect (1000baseT <full-duplex,rxpause,txpause>)

        status: active

        nd6 options=9<PERFORMNUD,IFDISABLED>

ix1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500

        options=e53fbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>

        ether ac:1f:6b:48:76:f5

        media: Ethernet autoselect

        status: no carrier

        nd6 options=1<PERFORMNUD>

ix2: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500

        options=e53fbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>

        ether ac:1f:6b:48:76:f6

        media: Ethernet autoselect

        status: no carrier

        nd6 options=1<PERFORMNUD>

ix3: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500

        options=e53fbb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_UCAST,WOL_MCAST,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>

        ether ac:1f:6b:48:76:f7

        media: Ethernet autoselect

        status: no carrier

        nd6 options=1<PERFORMNUD>

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384

        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>

        inet6 ::1 prefixlen 128

        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5

        inet 127.0.0.1 netmask 0xff000000

        groups: lo

        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

pflog0: flags=0<> metric 0 mtu 33160

        groups: pflog

bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500

        ether 02:cb:f6:ff:3c:00

        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15

        maxage 20 holdcnt 6 proto stp-rstp maxaddr 2000 timeout 1200

        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0

        member: vnet0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>

                ifmaxaddr 0 port 8 priority 128 path cost 2000000

        member: vnet1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>

                ifmaxaddr 0 port 9 priority 128 path cost 2000000

        member: ix0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>

                ifmaxaddr 0 port 1 priority 128 path cost 2000

        groups: bridge

        nd6 options=1<PERFORMNUD>

vnet1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

        options=80000<LINKSTATE>

        ether fe:a0:98:0e:06:db

        hwaddr 58:9c:fc:10:ff:a3

        groups: tap

        media: Ethernet autoselect

        status: active

        nd6 options=1<PERFORMNUD>

        Opened by PID 2418

vnet0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

        options=80000<LINKSTATE>

        ether fe:a0:98:59:f5:4a

        hwaddr 58:9c:fc:10:ff:b5

        groups: tap

        media: Ethernet autoselect

        status: active

        nd6 options=1<PERFORMNUD>

        Opened by PID 69446

 

[diskdiddler]

Nic is a VirtIO NIC - and (to my knowledge) I've changed nothing on the system at all, except updating to U2 the day it launched.
The system doesn't appear to have crashed / rebooted or anything. The VM simply isn't running. (despite the fact it's on, in the UI and can be 'woken' with a VNC connect)

EDIT: One more thing that might make it my fault (??) - my DietPi VM, is not exhibiting, the same behaviour. It continues to run indefinitely it seems.

 

[Samuel Tai]

OK, so the host side doesn't appear to have an issue, especially if the other VM is behaving properly. I suspect there's something going on with NetPlan inside the VM. How do you have the networking defined inside the VM?

 

[diskdiddler]

I believe it's a fixed ip set against the adaptor.

Shall I run the same command again within the Ubuntu VM?

Please bear in mind that it doesn't seem to be a networking issue. the system appears shutdown or powered off until I connect to the VNC module.

You can even see the black screen with a dos style cursor it in the VNC window it then suddenly comes alive and shows the graphical user interface as if it was in a low power mode or standby.

I'll be home in 4 hours to test.

 

[Samuel Tai]

This sounds like something in Ubuntu, specifically Netplan, isn't processing DHCP renews. I know Netplan needs to be told to use the MAC for the DHCP request; otherwise, it uses a goofy system ID that's not dependent on the MAC address.