Re: setting VNET tunables in a new jail

> On Dec 18, 2024, at 11:05 AM, Zhenlei Huang <zlei@FreeBSD.org> wrote:
> 
> 
> 
>> On Dec 18, 2024, at 5:19 AM, Mark Johnston <markj@freebsd.org <mailto:markj@freebsd.org>> wrote:
>> 
>> We have a number of sysctls which are defined as tunables, whose values
>> cannot be changed after boot.  Some of these sysctls, such as net.fibs,
>> are per-VNET so could in principle be changed at jail creation time.
> 
> For current/15, it is actually doable since my previous work [1] and [2].

Sorry I forgot to mention the commits:

1. 110113bc086f sysctl(9): Enable vnet sysctl variables to be loader tunable
2. cf7974fd9e55 sysctl: Update 'master' copy of vnet SYSCTLs on kernel environment variables change

> 
> A usage example is the test plan in https://reviews.freebsd.org/D41825 <https://reviews.freebsd.org/D41825> .
> 
> For short, `kenv some.kenv=foo`, and then create vnet jail, `jail -c xxx persist` .
> 
> Those commits are not MFCed to stable/14 and stable/13, as I'm not satisfied
> with the implementation. The current implementation is somewhat hacky
> and I planed to re-work it.
> 
>> I'd find it useful to be able to pass a set of tunables to jail_set(2),
>> so that corresponding VNET jail has tunables set to the specified
>> values.  For instance, it'd be useful in test suites where I want to
>> exercise the network stack with different VNET sysctl settings, without
>> having to configure the test runner at boot time.
>> 
>> I think the implementation would involve passing an environment to
>> vnet_alloc(), which would copy the parent VNET context and then iterate
>> over all VNET tunables in the system, invoking
>> sysctl_load_tunable_by_oid_locked() in such a way that the custom
>> environment is used to update the tunable's value.
> 
> That is per-jail kenv, quite close to my working copy.
> 
>> 
>> Is there already some way to do what I want?  If not, is there some
>> reason we shouldn't implement this feature?  Are there examples of VNET
>> tunables for which it'd be unsafe to have values differing from the
>> parent VNET?  One can print a list of such variables with "sysctl
>> -aVNT"; the list is pretty short and I don't see many obvious problems
>> with allowing them to be modified.
>> 
> 
> Best regards,
> Zhenlei
>