>> I am now looking at actually implementing static macs for all interfaces, as >> I’d rather guests saw the same mac address every run just in case they tie >> configuration to the >> mac (important for vm-bhyve as simply starting >> guests in a different order will change what tap devices they get). Also >> tap/slot/func isn’t much of a uniqueness guarantee >> across multiple hosts.
> Yes, and udev treats MAC as ethX = MAC. So linux guests using static ip's > will be quite broken unless some more fiddling is done. Static MAC's aren't > the only way to handle > this, but it's the best IMO. > Adam I have thought about this briefly in the past but never really put much into it as I just do what every other bhyve manager does - which is let bhyve handle it. Looking into it more, when you create a vm-bhyve guest, it really should *just work* every time you run it, wherever you run it. It's not ideal to have your statically assigned interface disappear just because you've booted the guest with a different tap interface. As such I think the best option is to assign a mac that's fixed (which is effectively what happens with real hardware). As such I've updated the latest version on GitHub (0.9.16) to automatically assign a fixed mac to all interfaces if one isn't already set. The fixed mac is written to the config file just as if you'd set one manually - so you can also modify it if needed. It's not 100% perfect as I'm using the assigned bhyve prefix of 0x589cfc00 which only gives the last 4 bytes to play with. I use 4 bytes from a hash of the guest name, interface number and time which isn't quite as collision-safe as making the whole mac random but I think using the bhyve prefix makes sense (even though I think bhyve itself still uses NetApp macs...) I did consider not using a random mac and just using some stored configuration to keep track of what's assigned/next available but that's pretty much guaranteed to cause collisions if you have multiple hosts on the same network running independent copies of vm-bhyve. Matt _______________________________________________ firstname.lastname@example.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"