RE: vm-bhyve port upgrade
>> 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"
Re: vm-bhyve port upgrade
On Mon, Nov 16, 2015 at 9:34 AM, Matt Churchyard wrote: > > 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 ___ 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"
RE: vm-bhyve port upgrade
On Thu, Nov 12, 2015 at 4:37 AM, Matt Churchyard via freebsd-virtualization mailto:freebsd-virtualization@freebsd.org>> wrote: Hello, For anyone interested I have submitted a PR to update the version of vm-bhyve in the ports tree. Primarily this fixes the off-putting, but completely benign error printed when users run 'vm init' (the very first thing to run...) I've no idea if I've got the diff format right though. Also adds various small fixes, and the following changes since the last ports version: Command to rename a guest Configuration options for utctime, hostbridge, disk options, debug mode, custom grub commands, virtual random device Snapshot and rollback commands when using ZFS Allows use of custom bridges and/or tap devices in addition to the normal automated networking Ability to specify a custom path for disk devices Guests can now automatically attach correctly to virtual switches if the real interface(s) (and thus the bridge) are using jumbo frames Template options to specify zfs dataset/zvol properties to apply when creating a guest (most useful for zvol volblocksize) New 'info' commands showing detailed guest/switch details including disk & network usage No longer replaces dnsmasq.conf, just provides a sample config for the user to apply if they want dhcp on a nat-enabled virtual switch. > If I statically define MAC addresses, is there a possibility for collisions? > I think it would be better to default to an auto generated permanent MAC. > -- > Adam At the moment the default is to just let bhyve handle mac addresses as normal. I have considered assigning static addresses to guests, as the bhyve man page suggests their mac addresses are only unique based on slot/func & device name. This could mean guests on different hosts get the same mac at the same time, or guests on the same machine - if they are run at different times and use the same tap interface. The current bhyve code also means the mac could change if I assign a different slot/func or tap device for a guest. If a user manually specifies a mac address in the guest configuration then obviously it becomes the users responsibility to make sure it’s unique in their environment. 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. 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"
Re: vm-bhyve port upgrade
On Thu, Nov 12, 2015 at 4:37 AM, Matt Churchyard via freebsd-virtualization wrote: > Hello, > > For anyone interested I have submitted a PR to update the version of > vm-bhyve in the ports tree. > Primarily this fixes the off-putting, but completely benign error printed > when users run 'vm init' (the very first thing to run...) > I've no idea if I've got the diff format right though. > > Also adds various small fixes, and the following changes since the last > ports version: > > Command to rename a guest > Configuration options for utctime, hostbridge, disk options, debug mode, > custom grub commands, virtual random device > Snapshot and rollback commands when using ZFS > Allows use of custom bridges and/or tap devices in addition to the normal > automated networking > Ability to specify a custom path for disk devices > Guests can now automatically attach correctly to virtual switches if the > real interface(s) (and thus the bridge) are using jumbo frames > Template options to specify zfs dataset/zvol properties to apply when > creating a guest (most useful for zvol volblocksize) > New 'info' commands showing detailed guest/switch details including disk & > network usage > No longer replaces dnsmasq.conf, just provides a sample config for the > user to apply if they want dhcp on a nat-enabled virtual switch. > If I statically define MAC addresses, is there a possibility for collisions? I think it would be better to default to an auto generated permanent MAC. -- Adam ___ 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"
vm-bhyve port upgrade
Hello, For anyone interested I have submitted a PR to update the version of vm-bhyve in the ports tree. Primarily this fixes the off-putting, but completely benign error printed when users run 'vm init' (the very first thing to run...) I've no idea if I've got the diff format right though. Also adds various small fixes, and the following changes since the last ports version: Command to rename a guest Configuration options for utctime, hostbridge, disk options, debug mode, custom grub commands, virtual random device Snapshot and rollback commands when using ZFS Allows use of custom bridges and/or tap devices in addition to the normal automated networking Ability to specify a custom path for disk devices Guests can now automatically attach correctly to virtual switches if the real interface(s) (and thus the bridge) are using jumbo frames Template options to specify zfs dataset/zvol properties to apply when creating a guest (most useful for zvol volblocksize) New 'info' commands showing detailed guest/switch details including disk & network usage No longer replaces dnsmasq.conf, just provides a sample config for the user to apply if they want dhcp on a nat-enabled virtual switch. Matt (churchers) ___ 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"
