The cleanest technical path is not<\/strong> to bolt a foreign The reason this matters is that XCP-ng\u2019s own documentation says almost all network configuration is handled through XAPI, with only a few explicit exceptions, notably the Xen Orchestra SDN features. OVN, on the other hand, expects a chassis-local integration bridge, VIFs attached to that bridge, and There is also a supportability caveat. XCP-ng\u2019s public \u201cextra installable\u201d package list for 8.3 contains XCP-ng\u2019s current architecture is straightforward: Xen Orchestra and OVN\u2019s local model is equally explicit. Each chassis must have an integration bridge<\/strong> dedicated to OVN. On hypervisors, the VIFs that participate in logical networks are supposed to be plugged into that integration bridge, and OVN relies on the normal OVS integration convention where the interface carries That leads to the central design tension. XAPI naturally creates one OVS bridge per XAPI Network object, while OVN naturally wants one dedicated integration bridge per chassis. If you add a separate A useful precedent comes from the old XAPI tunnel design itself. The XAPI tunnelling design creates the network object and tunnel access bridge first through XAPI, then leaves the controller responsible for establishing the actual GRE links. If the controller is absent, the network simply degrades into an internal network. That separation\u2014XAPI owns objects, controller owns dynamic connectivity\u2014is exactly the separation that makes OVN coexistence plausible here. <\/p>\n\n\n\n The required OVN host keys<\/strong> live in the The XenServer\/XCP-ng bridge identity keys<\/strong> live in the The VIF identity keys<\/strong> live in the A concrete coexistence configuration therefore looks like this:<\/p>\n\n\n\n The important part is that The strongest public template I found is what Vates already built for Xen Orchestra\u2019s SDN features. The official Xen Orchestra SDN documentation and the XCP-ng networking docs describe a plugin that creates pool-wide and cross-pool private networks, initially via direct OpenFlow and OVSDB interaction, then later via a newer XAPI-side plugin approach. The docs are explicit that the SDN controller is the exception to the usual XAPI-only networking model, and that the newer direction is to move the OVS logic into XAPI plugins instead of having Xen Orchestra talk directly to host OVS components forever.<\/p>\n\n\n\n The old SDN devblogs are also informative. In the 2019 SDN controller devblog, the authors explain that they built their own lightweight controller instead of using broader SDN projects; they also call out that their design uses a passive SSL connection on OVSDB port 6640<\/strong>, allowing multiple controllers to share pool control as long as they trust the same CA. In the 2020 VIF traffic-control devblog, they document that the plugin \u201cbecomes the SDN controller \u2026 thanks to XAPI\u201d and then uses OVSDB to become the bridge manager and OpenFlow to install traffic rules. That is not OVN, but it is a very relevant proof that the XCP-ng\/XO ecosystem can layer an SDN control plane over XAPI-owned OVS state when the responsibilities are kept separate.<\/p>\n\n\n\n The XCP-ng forum threads show the same pattern in the field. A 2025 thread explains that when an SDN network creation fails, the XAPI pool network can already exist even though the OVSDB-controlled tunnels do not; the suggested validation is Other forum replies give useful operational constraints. One forum answer enumerates the SDN network The historical XenServer\/Open vSwitch mailing-list material also supports preserving Xen\u2019s external IDs instead of fighting them. The OVS XenServer integration work documents that The recommended design is:<\/p>\n\n\n\n Create one XAPI-managed internal network whose bridge is dedicated to OVN, and configure that bridge as This is better than introducing a separate classic There is one important architectural consequence: the dedicated XAPI network used as OVN\u2019s bridge should be treated as an OVN access network<\/strong>, not as a normal standalone L2 domain. The real tenant segmentation, routing, ACLs, and distributed forwarding happen in OVN\u2019s northbound and southbound databases. The XAPI network exists mainly so that XAPI has a supported place to plug VIFs and so that For connectivity to existing underlay or external networks, use OVN First, create a dedicated internal XAPI network<\/strong> for OVN. XenServer\u2019s networking guide states that Next, set the OVN chassis keys<\/strong> in the local Then start Now attach VM networking through XAPI, not through A workable script sequence is:<\/p>\n\n\n\n The crucial detail is that the OVN logical switch port name should match the value OVN will see in For north-south or provider connectivity, add a Operationally, I would also keep the transport choices conservative. Use a real host IP for If you absolutely must keep a classic separate If you prototype that fallback anyway, the reconciliation loop should be idempotent and keyed only on Xen metadata that XAPI already writes: br-int<\/code> onto a host that already has its networking lifecycle owned by XAPI. The safer pattern is to let XAPI create and own a dedicated internal network bridge<\/strong>, then point ovn-controller<\/code> at that existing XAPI bridge by setting external_ids:ovn-bridge=<xapi bridge name><\/code>. In other words: reuse an XAPI-created bridge as<\/strong> the OVN integration bridge, instead of trying to move XAPI-owned VIFs onto a separately created br-int<\/code>. That matches OVN\u2019s model that VM VIFs should be plugged into the integration bridge, and it matches XCP-ng\u2019s model that network objects, bridges, and VIF lifecycle are normally controlled through XAPI and xcp-networkd<\/code>. <\/p>\n\n\n\nexternal_ids:iface-id<\/code> on those interfaces so ovn-controller<\/code> can bind them to logical switch ports. That is why a naive \u201covs-vsctl add-port br-int vifX.Y<\/code>\u201d approach clashes with the toolstack: both systems think they own the same port lifecycle.<\/p>\n\n\n\nopenvswitch-ipsec<\/code>, but not ovn<\/code> or ovn-controller<\/code>; and XCP-ng explicitly warns that installing packages outside its supported set, or from extra repositories, is at your own risk and can complicate updates and upgrades. That does not make an OVN host-agent prototype impossible, but it does mean this should be treated as an experimental integration<\/strong> unless you have a controlled packaging path. <\/p>\n\n\n\nSources of conflict<\/h2>\n\n\n\n
xe<\/code> talk to XAPI, XAPI dispatches network work to xcp-networkd<\/code>, and xcp-networkd<\/code> applies the required state into Open vSwitch. The XCP-ng architecture documentation is explicit that \u201calmost all configuration is handled through XAPI,\u201d and that Xen Orchestra\u2019s SDN controller is one of the rare cases that interacts directly with ovsdb-server<\/code> or ovs-vswitchd<\/code>. <\/p>\n\n\n\nexternal_ids:iface-id<\/code>. When a VM powers on, the hypervisor integration code adds the VIF to the integration bridge and stores the VIF identifier in external_ids:iface-id<\/code>; ovn-controller<\/code> then notices that interface and binds the corresponding logical port to the local chassis. <\/p>\n\n\n\nbr-int<\/code> and then manually re-home Xen VIFs onto it, you are stepping outside the model where XAPI is the system of record for the VM-to-network attachment. If instead you make one XAPI-created internal bridge serve as the integration bridge, the two models line up far better: XAPI still owns VM\/VIF\/network lifecycle, and OVN owns logical forwarding and overlays. <\/p>\n\n\n\nConfiguration keys<\/h2>\n\n\n\n
Open_vSwitch<\/code> table. OVN\u2019s own documentation lists these as the required chassis-side keys: external_ids:system-id<\/code>, external_ids:ovn-remote<\/code>, external_ids:ovn-encap-type<\/code>, and external_ids:ovn-encap-ip<\/code>. The ovn-controller<\/code> man page also documents external_ids:ovn-bridge<\/code>, which selects the integration bridge name and defaults to br-int<\/code>, and external_ids:ovn-bridge-mappings<\/code>, which maps provider or physical network names to local OVS bridges. external_ids:ovn-bridge-datapath-type<\/code> is optional. For hypervisor overlays, Geneve is the normal encapsulation choice; OVN\u2019s docs note that hypervisors support geneve<\/code> and stt<\/code>, while gateways may also use vxlan<\/code>. <\/p>\n\n\n\nBridge<\/code> table and should be preserved on any XAPI-owned bridge. Open vSwitch\u2019s schema documentation for XenServer states that external_ids:bridge-id<\/code> uniquely identifies the bridge and, on XenServer, commonly matches external_ids:xs-network-uuids<\/code>. It also documents external_ids:xs-network-uuids<\/code> itself as the semicolon-delimited set of Xen network UUIDs associated with that bridge. In practice, those are the bridge identity markers that XAPI and the XenServer-style integration expect to exist. <\/p>\n\n\n\nInterface<\/code> table and are the ones OVN most benefits from inheriting instead of reinventing. The XenServer schema and the integration guide document external_ids:attached-mac<\/code>, external_ids:iface-id<\/code>, external_ids:iface-status<\/code>, external_ids:xs-vif-uuid<\/code>, external_ids:xs-network-uuid<\/code>, external_ids:vm-id<\/code>, and external_ids:xs-vm-uuid<\/code>. The same documentation notes that on XenServer the default iface-id<\/code> is commonly the Xen VIF UUID, and vm-id<\/code> commonly matches the Xen VM UUID. That is the key insight that makes the reuse-of-XAPI-bridge design attractive: if XAPI plugs the VIF into the bridge that OVN treats as its integration bridge, the identifiers OVN wants are already the identifiers Xen\u2019s OVS integration knows how to populate.<\/p>\n\n\n\novs-vsctl set Open_vSwitch . \\
external_ids:system-id=\"$HOST_UUID\" \\
external_ids:ovn-remote=\"ssl:10.0.0.10:6642,ssl:10.0.0.11:6642,ssl:10.0.0.12:6642\" \\
external_ids:ovn-encap-type=\"geneve\" \\
external_ids:ovn-encap-ip=\"$TUNNEL_IP\" \\
external_ids:ovn-bridge=\"$XAPI_OVN_BRIDGE\" \\
external_ids:ovn-bridge-mappings=\"physnet-mgmt:$UPLINK_BRIDGE\"<\/pre>\n\n\n\nexternal_ids:ovn-bridge<\/code> points at the XAPI-created internal bridge<\/strong> you dedicate to OVN, while external_ids:ovn-bridge-mappings<\/code> points at one or more other<\/strong> bridges that XAPI already uses for provider or uplink connectivity. OVN\u2019s architecture documentation is explicit that underlay physical ports should not be attached to the integration bridge, and that patching from the integration bridge to another bridge is the right way to implement localnet or gateway connectivity.<\/p>\n\n\n\nCommunity evidence<\/h2>\n\n\n\n
ovs-vsctl show<\/code>, where a healthy result is a normal XAPI bridge such as xapi6<\/code> plus a controller entry and a GRE\/VXLAN port. That is a strong practical hint that XAPI-created bridges are the right substrate and the controller\u2019s job is to add extra ports or flows\u2014not to replace the bridge lifecycle.<\/p>\n\n\n\nother_config<\/code> fields, including xo:sdn-controller:pif-device<\/code>, and states that the selected PIF must be physical, VLAN-backed, or a bond master and<\/strong> must have an IP configuration. Another issue report shows what happens when the chosen transport PIF is ambiguous or lacks IP configuration: XAPI returns TRANSPORT_PIF_NOT_CONFIGURED<\/code>, exactly as the old XAPI tunnel design describes. Those are not OVN-specific, but they tell you what kind of host-side interface selection logic survives XAPI scrutiny.<\/p>\n\n\n\niface-id<\/code> should mirror the Xen VIF UUID and that vm-id<\/code> should mirror the Xen VM UUID, and one XenServer-specific OVS fix explicitly says that getting bridge-id<\/code> wrong broke controller integration. There is also historical evidence that XenServer-specific tooling reset OVS manager_options<\/code>, which is another reason not to base a coexistence design on ad hoc bridge-manager state that XAPI does not know about.<\/p>\n\n\n\nRecommended design<\/h2>\n\n\n\n
ovn-controller<\/code>\u2019s integration bridge.<\/strong> Then attach every VM VIF that should be OVN-managed to that XAPI network through normal XAPI\/XO\/xe<\/code> operations. Use ovn-bridge-mappings<\/code> only for provider uplinks or external connectivity to other XAPI-managed bridges. This gives OVN exactly what it wants\u2014a dedicated integration bridge carrying VM VIFs\u2014without taking bridge or VIF ownership away from XAPI.<\/p>\n\n\n\nbr-int<\/code> for three reasons. First, OVN explicitly allows the integration bridge to have a name other than br-int<\/code>; br-int<\/code> is only the default. Second, XenServer\/XCP-ng already knows how to create and maintain internal bridges that have no physical uplink, which fits OVN\u2019s own rule that underlay physical ports should not be attached directly to the integration bridge. Third, Xen\u2019s existing OVS integration already populates the VIF-facing external IDs that OVN uses to correlate local interfaces with logical switch ports.<\/p>\n\n\n\novn-controller<\/code> can see them.<\/p>\n\n\n\nlocalnet<\/code> ports and external_ids:ovn-bridge-mappings<\/code>. OVN documents that a localnet<\/code> port is the way to model \u201cdirect connectivity to an existing network,\u201d and that ovn-controller<\/code> implements it as a pair of patch ports between the integration bridge and another bridge. That is exactly the right place to map into an existing XAPI uplink bridge such as the management bridge, a VLAN bridge, or a bond-backed bridge.<\/p>\n\n\n\nImplementation guide<\/h2>\n\n\n\n
xe network-create name-label=<name><\/code> creates a network, and if it is not connected to a PIF it is internal. After creating it, query the network\u2019s bridge<\/code> field; that bridge name is what you will hand to OVN. In a pool, create it once on the coordinator in the normal XAPI way so the network object is consistent pool-wide.<\/p>\n\n\n\nOVN_NET_UUID=$(xe network-create name-label=ovn-int)\nXAPI_OVN_BRIDGE=$(xe network-list uuid=\"$OVN_NET_UUID\" params=bridge --minimal)\necho \"$OVN_NET_UUID $XAPI_OVN_BRIDGE\"<\/code><\/pre>\n\n\n\nOpen_vSwitch<\/code> record on each host. The minimum set is system-id<\/code>, ovn-remote<\/code>, ovn-encap-type<\/code>, and ovn-encap-ip<\/code>. For coexistence, also set ovn-bridge=$XAPI_OVN_BRIDGE<\/code>; that is the key that tells ovn-controller<\/code> to use an existing bridge other than the default br-int<\/code>. If the host must reach provider or external networks, also set ovn-bridge-mappings<\/code> to one or more existing XAPI uplink bridges.<\/p>\n\n\n\nHOST_UUID=$(xe host-list --minimal | cut -d, -f1)\novs-vsctl set Open_vSwitch . \\\n external_ids:system-id=\"$HOST_UUID\" \\\n external_ids:ovn-remote=\"ssl:10.0.0.10:6642,ssl:10.0.0.11:6642,ssl:10.0.0.12:6642\" \\\n external_ids:ovn-encap-type=\"geneve\" \\\n external_ids:ovn-encap-ip=\"$TUNNEL_IP\" \\\n external_ids:ovn-bridge=\"$XAPI_OVN_BRIDGE\" \\\n external_ids:ovn-bridge-mappings=\"physnet-mgmt:$UPLINK_BRIDGE\"<\/code><\/pre>\n\n\n\novn-controller<\/code> and verify that it adopts the XAPI bridge rather than auto-creating a new br-int<\/code>. OVN\u2019s architecture documentation says that if the integration bridge does not exist, ovn-controller<\/code> will create one automatically; the whole point here is to make sure the bridge already exists<\/strong> and is the XAPI-owned internal bridge you chose. At that point, any VIF that XAPI plugs into that dedicated network should appear on the integration bridge in the ordinary Xen\/OVS way, with the relevant external IDs populated.<\/p>\n\n\n\novs-vsctl<\/code><\/strong>. XAPI\u2019s API model is that a VIF is the attachment between a VM and a Network object, and plug<\/code>\/unplug<\/code> are the lifecycle operations for a running VM. In practice, create a new VIF or reattach an existing one so that its network<\/code> is the dedicated ovn-int<\/code> network. If you do this through XAPI\/XO\/xe<\/code>, XAPI remains the source of truth and live migration, unplug, and host restart semantics stay aligned with the rest of the toolstack.<\/p>\n\n\n\n# Pseudocode \/ shell logic\n# 1. Create or move a VM VIF onto the dedicated OVN XAPI network.\nVIF_UUID=<create via XAPI or discover existing VIF now attached to OVN_NET_UUID>\nMAC=<read from XAPI VIF record>\n\n# 2. Create the matching OVN logical switch port.\novn-nbctl --may-exist ls-add tenant-a\novn-nbctl --may-exist lsp-add tenant-a \"$VIF_UUID\"\novn-nbctl lsp-set-addresses \"$VIF_UUID\" \"$MAC 192.0.2.10\"<\/code><\/pre>\n\n\n\nexternal_ids:iface-id<\/code>. On XenServer-style OVS integration, the default iface-id<\/code> is commonly the Xen VIF UUID, so using the VIF UUID as the logical port name is the least-friction mapping. Once the VM is plugged and ovn-controller<\/code> sees the interface on the integration bridge, OVN should bind the corresponding Port_Binding<\/code> row to the local chassis. \ue200cite\ue202turn11view3\ue202turn21view0\ue201<\/p>\n\n\n\nlocalnet<\/code> port in OVN and map it to an existing XAPI-owned uplink bridge. OVN\u2019s NB and controller docs explicitly describe localnet<\/code> as the mechanism for direct connectivity to an existing network, and describe the implementation as a pair of patch ports between the integration bridge and the other local bridge. That lets you keep physical\/VLAN\/bond topology fully under XAPI while still giving OVN a way out to the underlay.<\/p>\n\n\n\novn-nbctl --may-exist lsp-add tenant-a provnet\novn-nbctl lsp-set-type provnet localnet\novn-nbctl lsp-set-options provnet network_name=physnet-mgmt<\/code><\/pre>\n\n\n\novn-encap-ip<\/code>, prefer geneve<\/code>, and keep management traffic, provider uplinks, and the OVN access bridge separate. That lines up both with OVN\u2019s own bridge layout guidance and with the constraints the Xen Orchestra SDN work has already surfaced around transport PIF selection and IP-configured uplinks.<\/p>\n\n\n\nExperimental fallback<\/h2>\n\n\n\n
br-int<\/code><\/strong> instead of reusing an XAPI bridge as ovn-bridge<\/code>, the only plausible pattern I found is an event-driven reconciliation layer<\/strong>: let XAPI create and plug the VIF onto its normal XAPI bridge, then immediately move the resulting OVS port to br-int<\/code> in a host-local script or daemon, preserving the Xen external IDs and making sure external_ids:iface-id<\/code> remains the VIF UUID. Inference-wise, the logic is sound because OVN only needs the VIF on the integration bridge with the right iface-id<\/code>, and the world already contains XCP-ng SDN examples that add extra GRE\/VXLAN ports to XAPI bridges without breaking XAPI. But I did not<\/strong> find public evidence that permanently re-homing Xen VIF ports away from their XAPI-selected bridge is a supported configuration, so this should be treated as a high-risk lab technique rather than the recommended design.<\/p>\n\n\n\nxs-vif-uuid<\/code>, xs-network-uuid<\/code>, xs-vm-uuid<\/code>, attached-mac<\/code>, iface-id<\/code>, and iface-status<\/code>. It must run after every VIF plug, VM power-on, migration, and potentially after host-side network reconciliation. That is exactly the sort of long-term complexity the newer Xen Orchestra work is trying to eliminate by moving SDN logic closer to XAPI rather than relying on persistent ad hoc host-side OVS manipulations.<\/p>\n\n\n\n