Lan

cc @tnqn @antoninbas @jianjuns

Hi @antoninbas thanks for the info. I will check and create a sub-issue for it. btw, I checked the doc, looks like we also need to promote AntreaIPAM as well...

@tnqn I think we need a follow up document PR for SR-IOV support in #6881.

> @luolanzone a few high level questions: > > 1. What we lose if we do not persist SR-IOV interfaces? > > > * after restart agent wont know an...

Hi @jianjuns "cniCache is restored with the primary interface store", this is actually only true when there is a secondary OVS bridge. https://github.com/antrea-io/antrea/blob/main/pkg/agent/secondarynetwork/podwatch/controller.go#L139-L147. So the cnicahe is not restored when...

> You comments in [#7240 (comment)](https://github.com/antrea-io/antrea/pull/7240#discussion_r2163551711) seem imply the major problem of not restoring SR-IOV interfaces is just that VF will not be renamed back to their original name after...

Hi @jianjuns regarding this "Could you also let me know what are the problems of restoring SR-IOV interfaces from the Pod status annotation (so far your explanation is all about...

> @luolanzone containerNS is indeed saved in cniCache and can be recovered from the primary interface store. Do you need other info other than containerNS and interface name? For new...

> @luolanzone if you do not need more information, could we restore SR-IOV interfaces from the network status annotation? I forgot to mention the new coming codes for SR-IOV device...

@jianjuns I think one case we need to handle is that a Pod is deleted while the agent is restarting, it will miss the Pod deletion and not able to...