Laine Stump wrote: > On 12/15/25 12:00 PM, Roman Bogorodskiy wrote: > > Laine Stump wrote: > > > > > On 12/8/25 1:02 PM, Roman Bogorodskiy wrote: > > > > Michal Prívozník wrote: > > > > > > > > > On 11/26/25 18:03, Roman Bogorodskiy wrote: > > > > > > SLIRP networking in bhyve doesn't support MAC and IP addresses > > > > > > configuration, so update the validation code to check that these > > > > > > options > > > > > > are not specified. > > > > > > > > > > > > Signed-off-by: Roman Bogorodskiy <[email protected]> > > > > > > --- > > > > > > src/bhyve/bhyve_domain.c | 17 +++++++++++++- > > > > > > .../bhyvexml2argv-slirp-ip.xml | 22 > > > > > > +++++++++++++++++++ > > > > > > .../bhyvexml2argv-slirp-mac-addr.xml | 22 > > > > > > +++++++++++++++++++ > > > > > > tests/bhyvexml2argvtest.c | 2 ++ > > > > > > 4 files changed, 62 insertions(+), 1 deletion(-) > > > > > > create mode 100644 > > > > > > tests/bhyvexml2argvdata/bhyvexml2argv-slirp-ip.xml > > > > > > create mode 100644 > > > > > > tests/bhyvexml2argvdata/bhyvexml2argv-slirp-mac-addr.xml > > > > > > > > > > > > diff --git a/src/bhyve/bhyve_domain.c b/src/bhyve/bhyve_domain.c > > > > > > index 4c9ed29333..5c1ed86df6 100644 > > > > > > --- a/src/bhyve/bhyve_domain.c > > > > > > +++ b/src/bhyve/bhyve_domain.c > > > > > > @@ -325,6 +325,22 @@ bhyveDomainDeviceDefValidate(const > > > > > > virDomainDeviceDef *dev, > > > > > > break; > > > > > > } > > > > > > + case VIR_DOMAIN_DEVICE_NET: { > > > > > > + virDomainNetDef *net = dev->data.net; > > > > > > + > > > > > > + if (net->type == VIR_DOMAIN_NET_TYPE_USER) { > > > > > > + if (!net->mac_generated) { > > > > > > + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", > > > > > > + _("setting MAC address for SLIRP > > > > > > networking is not supported")); > > > > > > + return -1; > > > > > > > > > > This is a bit unfortunate as many of our public APIs (e.g. > > > > > virDomainDetachDevice()) try to match <interface/> using its MAC > > > > > address > > > > > first. OTOH, they can find a match using other values specific to > > > > > individual device and we specifically document that device XML should > > > > > be > > > > > passed full. > > > > > > > > Thanks for taking time to point that out. I looked to check how hard > > > > would that be to support that, but apparently, it's already there, > > > > just not mentioned in the manual page [1]. > > > > > > > > I'll push the series with this chunk removed after one more round of > > > > testing. > > > > > > > > 1: https://reviews.freebsd.org/D54133 > > > > > > (just now noticed this - I haven't been paying attention :-/) > > > > > > Whether or not the user provides a MAC address, the config that's stored > > > on > > > disk will contain one (either user-supplied or auto-generated), and that > > > MAC > > > address won't be honored, which could be confusing to users. > > > > > > When a MAC address isn't specified for <interface> we will always generate > > > one prior to saving the config, so that the same MAC setting will persist > > > across restarts of the guest; doing otherwise wreaks havoc in the guest > > > OS - > > > any time the MAC address changes, it will think there is a new network > > > device and want to configure it (MS Windows does this even if the MAC > > > address of the default router changes). (Of course I'm assuming that bhyve > > > makes the guest NIC appear with a random MAC; does it instead always use > > > the > > > same hard-coded MAC address? What if someone puts two slirp-backed > > > interfaces in the config?) > > > > Could you please take a look at the v2 version of this series? I think it > > has > > these issues addressed. > > Ah, sorry - I hadn't gotten that far yet :-). So did you just add the mac > address option to bhyve, or was it always there and you just weren't using > it before? (I just added my r-b to the revised patch, with a note that the > bhyve commandline example should have "mac=blah" added).
The option for mac was already there, but not documented. What's needed on bhyve side now is to document that and to allow MTU configuration, which is not directly related to this series, I believe. Thanks, Roman
