A bug was found with the vmxnet3 driver, after changing the MAC address
and rebooting, it falls into the category of a permanent address until
the VM is turned off. Here is log output:

-bash-4.4# ip a
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
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

-bash-4.4# ip link set dev ens3 address 33:33:33:33:33:33
-bash-4.4# ip a
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
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
    link/ether 33:33:33:33:33:33 brd ff:ff:ff:ff:ff:ff
-bash-4.4# ethtool -P ens3
Permanent address: 52:54:00:12:34:56
-bash-4.4# reboot

//rebooting


-bash-4.4# ip a
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
2: ens3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
    link/ether 33:33:33:33:33:33 brd ff:ff:ff:ff:ff:ff
-bash-4.4# ethtool -P ens3
Permanent address: 33:33:33:33:33:33
-bash-4.4#

Vlao Mao (1):
  vmxnet3: add mac address restore upon reset

 hw/net/vmxnet3.c | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.35.1

On Tue, 31 Jan 2023 at 18:22, Vlao Mao <vlaomao@gmail.com> wrote:
>
> A bug was found with the vmxnet3 driver, after changing the MAC address
> and rebooting, it falls into the category of a permanent address until
> the VM is turned off.

For some network device models (those where the hardware has an
EEPROM and we're modelling "guest programmed a new MAC address
into the EEPROM") that is the correct behaviour. Is the vmxnet3
definitely one of the kind which is not supposed to have a
permanent MAC address backing storage ? (It's paravirtual, so
this would hopefully be indicated in the specs for it.)

thanks
-- PMM

I cannot say for sure, but e1000 does not have this behavior, vmxnet3
in vmware also does not behave this way.
In addition, the address gets there only after a reboot, it does not
get there during normal operation, as you can see from logs i
attached. It seems to me that this is not quite the expected behavior,
isn't it?

вт, 31 янв. 2023 г. в 21:48, Peter Maydell <peter.maydell@linaro.org>:
>
> On Tue, 31 Jan 2023 at 18:22, Vlao Mao <vlaomao@gmail.com> wrote:
> >
> > A bug was found with the vmxnet3 driver, after changing the MAC address
> > and rebooting, it falls into the category of a permanent address until
> > the VM is turned off.
>
> For some network device models (those where the hardware has an
> EEPROM and we're modelling "guest programmed a new MAC address
> into the EEPROM") that is the correct behaviour. Is the vmxnet3
> definitely one of the kind which is not supposed to have a
> permanent MAC address backing storage ? (It's paravirtual, so
> this would hopefully be indicated in the specs for it.)
>
> thanks
> -- PMM