vm-bhyve port upgrade
matt.churchyard at userve.net
Mon Nov 16 20:20:25 UTC 2015
>> 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.
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.
More information about the freebsd-virtualization