>> 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
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to 
"freebsd-virtualization-unsubscr...@freebsd.org"

Reply via email to