Sudden vtnet0 address reassignment hours later after boot: does note this describe a known bug?

Sometimes after the likes of booting and getting:

Feb 16 05:18:30 aarch64-main-pbase kernel: vtballoon0: <VirtIO Balloon Adapter> on virtio_mmio0
Feb 16 05:18:30 aarch64-main-pbase kernel: lo0: link state changed to UP
Feb 16 05:18:30 aarch64-main-pbase kernel: vtnet0: link state changed to UP

The FreeBSD (running under Parallels), seems to silently use the
prior network address for a time with no messages. Other times
it seems to do the normal additional things during the boot as well:

Feb 11 19:53:53 aarch64-main-pbase kernel: vtnet0: link state changed to DOWN
Feb 11 19:53:58 aarch64-main-pbase dhclient[2547]: New IP Address (vtnet0): 192.168.1.111
Feb 11 19:53:58 aarch64-main-pbase dhclient[2551]: New Subnet Mask (vtnet0): 255.255.255.0
Feb 11 19:53:58 aarch64-main-pbase dhclient[2555]: New Broadcast Address (vtnet0): 192.168.1.255
Feb 11 19:53:58 aarch64-main-pbase dhclient[2559]: New Routers (vtnet0): 192.168.1.1
Feb 11 19:53:58 aarch64-main-pbase kernel: vtnet0: link state changed to UP

When such does not happen, the system is subject to hours later ending
up with something like:

Feb 16 09:19:13 aarch64-main-pbase dhclient[75650]: New IP Address (vtnet0): 192.168.1.131
Feb 16 09:19:13 aarch64-main-pbase dhclient[75655]: New Subnet Mask (vtnet0): 255.255.255.0
Feb 16 09:19:13 aarch64-main-pbase dhclient[75660]: New Broadcast Address (vtnet0): 192.168.1.255
Feb 16 09:19:13 aarch64-main-pbase dhclient[75702]: New Routers (vtnet0): 192.168.1.1

happening in the middle of other activity. I'll note that 192.168.1.131
is a network address that the same boot media has had when used to boot
a different system (no virtual machine involved). I'll note that there
were no "link state changed to" notices around the dhclient "New . . ."
messages.

This activity of 192.168.1.131 coming into use interrupts existing ssh
connections that have been in use for those hours after the boot in
parallels.

I'll note that the system was still up and I could still use the efifb
based console session. I could ssh connect to the new address.

Given that the 192.168.1.131 would be something that FreeBSD likely has
records of from past activities (it is a well known address to me), it
would seem that FreeBSD initiated the involvement of 192.168.1.131 .

Prior to vtnet0 being involved in my recent experiments with Parallels on
a MacBook Pro M4 MAX, I've never had the type of problem before --but
also no use of any vtnet* .

Is there some sort of known bug in this area? Any suggestions on avoiding
the surprise change in the network address?

In the example at hand, it stopped a poudriere(-devel) bulk -ca test after
about 12 hours: it had been running in one of the ssh sessions that was
stopped by the activity.


For reference:

# uname -apKU
FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT #1 main-n275290-9ef38a01aea8-dirty: Thu Feb 13 14:18:57 PST 2025     root@aarch64-main-pbase:/usr/obj/BUILDs/main-CA76-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA76 arm64 aarch64 1500031 1500031


===
Mark Millard
marklmi at yahoo.com