oem-azure: add hyperv daemons

[t-lo]

This change adds hyperv daemons hv_fcopy, hv_kvp, and hv_vss to the Azure OEM sysext. hv_kvp specifically is needed to submit OS version information to the Azure hypervisor.

The daemons, tough userspace programs, are built from the kernel sources as they are included in the Linux kernel.

Implements flatcar/Flatcar#1540.

How to use

Build azure vendor image from this branch

./run_sdk_container -t
    ./build_packages
    ./build_image
    ./image_to_vm.sh --from=../build/images/amd64-usr/latest --board=amd64-usr --format=azure --image_compression_formats none

Deploy with kola

AZURE_SUBSCRIPTION_ID=<your-id> \
  kola spawn --keys --key ~/.ssh/id_rsa.pub --azure-vnet-subnet-name <your-subnet> \
        --azure-location westeurope --azure-use-private-ips --azure-image-file [...]/flatcar_production_azure_image.vhd \
        --platform=azure -v

Testing done

Built and deployed as shown above, verified hv_kvp_daemon was running after boot. The other two daemons did not run in my testing as the respective /dev/vmbus/... device files were missing from my instance.

Cherry-Pick

Cherry-pick this change to all active maintenance branches that support Azure OEM sysext (flatcar-3975, flatcar-4054, flatcar-4081).

[github-actions]

Build action triggered: https://github.com/flatcar/scripts/actions/runs/10849089302

[jepio]

is the version number on the ebuild important? if it is then we'd need to add bumping the version to the kernel update GHA.

[t-lo]

is the version number on the ebuild important? if it is then we'd need to add bumping the version to the kernel update GHA.

It actually is not. It's misleading. The ebuild uses whatever kernel version is current. I'll rename it, good catch.

EDIT: OH WAIT NO - coreos-kernel eclass uses ${PV} to determine the kernel version to build against. I'll add hv-daemons to the automation.

[t-lo]

Moving this out of "draft" as it solidifies for Flatcar. We can do a generalised Gentoo implementation for upstreaming in a follow-up PR.

[t-lo]

I wonder - how do folks feel about cherry-picking this to maintenance branches? It's a well-understood change and The Azure OEM sysext update would provide instant telemetry for instances on Alpha, Beta, and Stable.

[ader1990]

Can you also add the

scripts/sdk_container/src/third_party/coreos-overlay/coreos-base/oem-azure/oem-azure-2.9.1.1-r3.ebuild

Line 20 in 05f6ed4

app-emulation/hv-daemons

in

scripts/sdk_container/src/third_party/coreos-overlay/coreos-base/oem-hyperv/oem-hyperv-0.1.0-r1.ebuild

Line 17 in 05f6ed4

?

I can give it a test locally if you think it is a good idea.

Hyper-V OEM would benefit from the daemons too.

[t-lo]

Can you also add the

scripts/sdk_container/src/third_party/coreos-overlay/coreos-base/oem-azure/oem-azure-2.9.1.1-r3.ebuild

Line 20 in 05f6ed4

app-emulation/hv-daemons

in

scripts/sdk_container/src/third_party/coreos-overlay/coreos-base/oem-hyperv/oem-hyperv-0.1.0-r1.ebuild

Line 17 in 05f6ed4

?
I can give it a test locally if you think it is a good idea.

Hyper-V OEM would benefit from the daemons too.

Makes a lot of sense, will add and do a OEM image build smoke-test.

[jepio]

There's more that can be done for a full integration btw: the kvp daemon expects to find helpers in /usr/libexec/hypervkvpd/ called hv_get_dhcp_info, hv_get_dns_info, hv_set_ifconfig that the distro can provide with distro specific implementations.

[t-lo]

@ader1990 I've added hv-daemons to oem-hyperv and did a test build (both VHD and VHDX), both built fine.

[Jeremi]

There's more that can be done for a full integration btw: the kvp daemon expects to find helpers in /usr/libexec/hypervkvpd/ called hv_get_dhcp_info, hv_get_dns_info, hv_set_ifconfig that the distro can provide with distro specific implementations.

Yes, example scripts are actually shipped with the hyperv daemon sources. I'm on the edge whether to add these with this PR or a follow-up one. My main objective was to give Azure users (and Azure support) better insight into their instances' OS versions...

[t-lo]

Removed the TODO:, added documentation, and added my intend to cherry-pick this to all maintenance branches (I'm willing to discuss this).

Please let me know what you think.

[ader1990]

@ader1990 I've added hv-daemons to oem-hyperv and did a test build (both VHD and VHDX), both built fine.

[Jeremi]

There's more that can be done for a full integration btw: the kvp daemon expects to find helpers in /usr/libexec/hypervkvpd/ called hv_get_dhcp_info, hv_get_dns_info, hv_set_ifconfig that the distro can provide with distro specific implementations.

Yes, example scripts are actually shipped with the hyperv daemon sources. I'm on the edge whether to add these with this PR or a follow-up one. My main objective was to give Azure users (and Azure support) better insight into their instances' OS versions...

I suppose this can be done at a later time, as it requires more testing and making sure everything works as expected.

[t-lo]

@tormath1 @jepio @ader1990 thoughts / feelings on cherry-picking this to maintenance branches?

[tormath1]

I'm fine with backporting on Alpha, Beta and Stable: it's telemetry. In the worst case, those services are failing.
Something we can do before merging would be to run Jenkins CI to test on Azure platform to inspect journal logs.

[ader1990]

I'm fine with backporting on Alpha, Beta and Stable: it's telemetry. In the worst case, those services are failing. Something we can do before merging would be to run Jenkins CI to test on Azure platform to inspect journal logs.

Another perspective - all the other OSes on Azure have these daemons, so it should be okay.

[t-lo]

All checks passed - see test run. The final merge was @tormath1 's changelog improvement - no need to re-run CI.
Looking for a LGTM now 🙏

[tormath1]

As suggested, we could run a Jenkins CI with Azure testing but this will be tested eventually in the nightly.

[t-lo]

Merged and cherry-picked for flatcar-3975, flatcar-4054, and flatcar-4081. (all are on the same kernel version fortunately)

[tormath1]

As suggested, we could run a Jenkins CI with Azure testing but this will be tested eventually in the nightly.

Nightlies have failed I guess we missed to add the hv-daemons to coreos depencies.