Could you confirm the following:

• you have enabled test-signed drivers with Bcdedit.exe -set TESTSIGNING ON
• you have enabled the Hyper-V feature (or alternatively used the workaround in https://github.com/antrea-io/antrea/blob/main/docs/windows.md#known-issues)

Also, could you share the log files which are under C:\openvswitch\var\log\openvswitch?

I am also experiencing a similar issue with Windows Server 2022, so I have asked @wenyingd for some info.
Edit: I had a misconfiguration in my test environment. Things are working as expected.

Accessing the information directly using ovs-vsctl seems to be difficult with OpenSwitch running inside a container.

You could try with this powershell command to ensure the OVS utilities path are added into the current shell,

$env:PATH=[System.Environment]::GetEnvironmentVariable("PATH", "Machine")

Then you can try to run OVS commands like ovs-vsctl.exe show or ovs-ofctl.exe -OOpenFlow15 dump-flows br-int

@antoninbas

• Test signing: I did not enable this. The documentation gave me the impression that this is not required when running the the fully containerized version.
• Hyper-V: Is fully installed and confirmed working.

Logs: C:\openvswitch\var\logs does not exist. var\ only contains run as subdirectory.

@wenyingd

The command is in the path. The idea you mentioned in Slack is the reason. The command does not work over a powershell remoting connection. It works fine using an RDP connection.

> ovs-vsctl.exe show
0416ab53-99a7-4ac0-b537-ae62ec5bf25e
    Bridge br-int
        datapath_type: system
    ovs_version: "3.0.5"

> ovs-ofctl.exe -OOpenFlow15 dump-flows br-int
ovs-ofctl: br-int is not a bridge or a socket

I'm not sure about the second message. I can see the br-int interface in the adapter overview of windows, also in the Hyper-V manager.

@mkaring as long as you are using the OVS driver provided by Antrea (hosted at https://downloads.antrea.io), you will need to enable test-signed drivers. We do not provide a driver signed with a certificate from a trusted root authority.
This could explain why initialization is failing.

@mkaring as long as you are using the OVS driver provided by Antrea (hosted at https://downloads.antrea.io), you will need to enable test-signed drivers. We do not provide a driver signed with a certificate from a trusted root authority. This could explain why initialization is failing.

@wenyingd is there a way to confirm that this is causing the issue? I was assuming that Install-OVS.ps1 would fail in that case (causing the initContainer to fail), but maybe that's not the case.

This is going to be a real problem. Are there any known providers for OVS that provide WHQL signed drivers? My server is set to boot using secure boot and that is something I can't change. Test-signed drivers and secure boot do not like each other.

@wenyingd is there a way to confirm that this is causing the issue? I was assuming that Install-OVS.ps1 would fail in that case (causing the initContainer to fail), but maybe that's not the case.

If my memory is correct, the step to install OVS driver can succeed, but the workload is impacted when antrea tries to enable the Extension (ovsext) on a VMSwitch on the host. I could have some try.

This is going to be a real problem. Are there any known providers for OVS that provide WHQL signed drivers? My server is set to boot using secure boot and that is something I can't change. Test-signed drivers and secure boot do not like each other.

AFAIK, not for free / with an open license. VMware provides one for customers.
Antrea also expects a specific driver version for OVS, which we test with (and sometimes includes some necessary patches).
You can also get your own release signature.

@wenyingd it would be good to fail early or at least have a way to clearly identify that it is the issue

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment, or this will be closed in 90 days