@daniel.arconada are you able to test it with the next rolling release? Those options will be included.

@daniel.arconada are you able to test it with the next rolling release? Those options will be included.

PR https://github.com/vyos/vyos-build/pull/916

Both kernel and user-space support are needed. On the kernel side, you must enable vDPA-related options (e.g., CONFIG_VDPA and/or CONFIG_VHOST_VDPA) to provide the necessary infrastructure. On the user-space side, binaries that interact with VirtIO devices must be updated to take advantage of this support. For example, QEMU needs to be built with vDPA support so that virtual machines can offload packet processing to the hardware accelerator. Additionally, tools like libvirt or other management utilities might require adjustments to properly configure and utilize vDPA-enabled devices.

Is there any kernel option that should be enabled, or just some binaries or both of them?

I’d expect the behavior is correct now. There shouldn't be empty nodes. As some of them uses “default values” and system can see it as partly configured,
In any case the check is here https://github.com/vyos/vyos-1x/blob/ec18cc393591052fd1f021c4a62220ab2e537a2e/src/conf_mode/service_ntp.py#L68

FTR --ncp-disable was only supposed to disable the cipher negotiation. It was not meant to disable encryption entirely. --data-ciphers none is the way to go, but it seems you've already figure this out.

@n.fort what is the status of this?

also save information about the temporary package version: https://github.com/vyos/vyos-build/pull/820#event-14849025089

@marekm: Bugfixes will be towards current (aka 1.5-rolling as of writing) which then is being cherrypicked and backported by VyOS Networks to whatever older releases that needs that and are compatible with the change/fix/added feature.

That looks like a very much breaking change to me, not perfectly compatible. No more access to source code for LTS branches means it may not be possible to work on bug fixes (not just new functionality) anymore. So, to submit three PRs with bug fixes in the LTS branch to qualify for a subscription, one first needs to have a subscription. I don't think this will encourage more contributors to help the project. Is this intentional?