QEMU auto config dhcp-client on ether1

Hi Guys, I have the latest version 6 of Pnet Lab installed and I encountered a feature that I don’t know how to get around (on version 5.3.13, this will also happen again). I added the Mikrotik 7.19rc1 router image, created a new lab work, added the Mikrotik device to it (I leave all the default settings when adding), there is nothing in the lab except the router, I start the router, it starts successfully, I connect via telnet to the console and expect to see a clean configuration … but I find that dhcp-client has been added to the ether1 interface. If I delete it, turn the router off / on, it will be added again. Question: is it possible to do something so that dhcp client is not added automatically to the interface? For me this is a problem, because I am testing the automatic router configuration script and the script contains a command to add a dhcp client to the ether1 interface and when I execute it I get an error, because the dhcp client has already been added to this interface automatically after turning on the router. I have conducted several experiments and came to the conclusion that this is a feature of the Qemu emulator, because the problem is reproduced on all software products that work with Qemu (Pnet Lab, Eve-NG, GNS3). If I deploy the same Mikrotik image in a clean VM ESXI, nothing is added, the router boots with a clean configuration. Please tell me where to look and is it possible to change this?
Скриншот 10-05-2025 044203.png

As far as I am aware. It always assigns a dhcp client to ether1.
Which can be annoying when creating an instance on live internet, where it very quickly gets hacked…

I don’t know why your esxi one didn’t.
Perhaps it didn’t have any interfaces to assign the ether1.

Probably best to assume it is there and disable or remove it.

Maybe (sorry not tested)

/ip dhcp-client
remove [find]

Isn’t this issue the same of this (old) one?
http://forum.mikrotik.com/t/chr-problem-with-dhcp-client-after-reboot/116337/1

The workaround of putting ether1 into a bridge (by itself) should still be working.