Date: Mon, 16 Nov 2015 20:20:08 +0000 From: Matt Churchyard <matt.churchyard@userve.net> To: Adam Vande More <amvandemore@gmail.com> Cc: FreeBSD virtualization <freebsd-virtualization@freebsd.org> Subject: RE: vm-bhyve port upgrade Message-ID: <36cf827ce1cd40aabc97f5ae606da34f@SERVER.ad.usd-group.com> In-Reply-To: <CA%2BtpaK3nYRRSOoKcP7=S=S6zxNR-Kc7Wf8_=NDrvarMedDJpog@mail.gmail.com> References: <7ac3a4411ec04711bec75cab3a68ae81@SERVER.ad.usd-group.com> <CA%2BtpaK1SY%2B9HJx-yB2%2BSxWgp_T8ARO5a9R1v4MsLwqO7tTU=SQ@mail.gmail.com> <6a9f7105dedf4af79f2e8d02d36f3a6c@SERVER.ad.usd-group.com> <CA%2BtpaK3nYRRSOoKcP7=S=S6zxNR-Kc7Wf8_=NDrvarMedDJpog@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36cf827ce1cd40aabc97f5ae606da34f>