Aha, I found the machine in question... And I'm kicking myself in the head for not figuring this one out before. The guest connects to the local network with a macvtap interface on the host. The host (also registered in Foreman) reported a new macvtap interface with this MAC address to Foreman. When the guest wants to get autoprovisioned, Foreman says the MAC is already taken because the host reported this new interface. Is there any way around this? As it is now, this would mean macvtap adapters are a no go because both host and guest will always have some interface with identical MAC.

I deleted the interface on the host, and then I could provision the guest but on a next puppet run, the host will report the interface again.

And no, no organizations or locations in use on my setup. Thank you for the "has_mac" tip by the way, it led me to find the culprit :)

You're second user that reported this, is there some reason to use macvtap interfaces instead of other types? Unfortunately we don't have better solution right now than disabling importing interfaces based on puppet facts upload, to do it navigate to Administer -> Settings -> Provisioning and set "Ignore Puppet facts for provisioning" to true. This will disable any updates to network interfaces based on incoming data from puppet.

I think we could consider all macvtap interfaces as virtual (which do not enforce MAC address uniqueness), is it reasonable to rely on interface name being always in form of /macvtap.*/? On VM I suppose it's something like eth0 which would correctly be recognized as physical interface.

The reason behind using direct interfaces is to not have another NAT and to be able to manage the network using the same network infrastructure used for physical machines. It also allows me to provision a VM from the Foreman managed TFTP server just like the physical machines.

This is the interface on the host:

4: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/ether 52:54:00:e8:62:b9 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5054:ff:fee8:62b9/64 scope link 
       valid_lft forever preferred_lft forever

This is the interface on the vm:

4: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/ether 52:54:00:e8:62:b9 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5054:ff:fee8:62b9/64 scope link 
       valid_lft forever preferred_lft forever

Good to know virtual interfaces do not require uniqueness. I will also try the "ignore puppet facts" setting.

Sorry, I made a copy/paste error, this is the interface on the vm:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:e8:62:b9 brd ff:ff:ff:ff:ff:ff
inet 10.30.202.49/22 brd 10.30.203.255 scope global dynamic eth0
valid_lft 3506sec preferred_lft 3506sec
inet6 fe80::5054:ff:fee8:62b9/64 scope link
valid_lft forever preferred_lft forever

So a 'physical' interface just like you said.

Ah nevermind, it's not gonna work this way. Our virtual interfaces requires attached_to value, so the best we can do is to skip all interfaces with such identifier.

Okay Marek, I have little knowledge of Foreman's internals so just let me know if you still want that facter output! Thanks for your help.

Facter output is not needed, thanks. If you wish you can test the patch from https://github.com/theforeman/foreman/pull/2774 or wait until it gets merged and released, there's a chance it gets into upcoming 1.10.