Added docs for KubeVirt#2612
Merged
Merged
Conversation
✅ Deploy Preview for calico-docs-preview-next ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview succeeded!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
There was a problem hiding this comment.
Pull request overview
Adds a new KubeVirt networking doc section to the Calico and Calico Enterprise documentation sites and exposes it in the left-nav sidebars.
Changes:
- Adds a new “networking for KubeVirt” sidebar category for both Calico and Calico Enterprise.
- Introduces new KubeVirt docs pages covering networking basics (IP persistence, live migration prerequisites) and BGP routing considerations for live migration.
- Adds KubeVirt landing/index pages that render a DocCardList for the new section.
Reviewed changes
Copilot reviewed 8 out of 9 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| sidebars-calico.js | Adds a new “Calico networking for KubeVirt” category and links new docs into the Calico sidebar. |
| sidebars-calico-enterprise.js | Adds a new “Calico Enterprise networking for KubeVirt” category and links new docs into the Enterprise sidebar. |
| calico/networking/kubevirt/index.mdx | Adds KubeVirt section landing page for Calico. |
| calico/networking/kubevirt/kubevirt-networking.mdx | Adds Calico KubeVirt networking guide (IP persistence, migration prerequisites, config pointers). |
| calico/networking/kubevirt/live-migration-bgp.mdx | Adds Calico guide for BGP behavior/configuration considerations during live migration. |
| calico-enterprise/networking/kubevirt/index.mdx | Adds KubeVirt section landing page for Calico Enterprise. |
| calico-enterprise/networking/kubevirt/kubevirt-networking.mdx | Adds Enterprise KubeVirt networking guide (mirrors OSS structure/content with Enterprise links). |
| calico-enterprise/networking/kubevirt/live-migration-bgp.mdx | Adds Enterprise guide for BGP behavior/configuration considerations during live migration. |
Comment on lines
+123
to
+136
| IP address persistence is enabled by default. If it has been previously disabled, re-enable | ||
| it by updating the `IPAMConfiguration` resource: | ||
|
|
||
| ```yaml | ||
| apiVersion: projectcalico.org/v3 | ||
| kind: IPAMConfiguration | ||
| metadata: | ||
| name: default | ||
| spec: | ||
| strictAffinity: false | ||
| autoAllocateBlocks: true | ||
| maxBlocksPerHost: 0 | ||
| kubeVirtVMAddressPersistence: Enabled | ||
| ``` |
There was a problem hiding this comment.
This section says IP address persistence is enabled by default, but the IPAMConfiguration reference in this repo shows kubeVirtVMAddressPersistence defaulting to Disabled. Also, the sample IPAMConfiguration includes autoAllocateBlocks, which is not present in the IPAMConfiguration reference schema here—please align the text and example with the documented fields/defaults (or update the reference if the API has changed).
Comment on lines
+179
to
+236
| $[prodname] uses Linux kernel route metrics to steer traffic during live migration. | ||
| The route priority settings are configured through the `FelixConfiguration` resource: | ||
|
|
||
| ```yaml | ||
| apiVersion: projectcalico.org/v3 | ||
| kind: FelixConfiguration | ||
| metadata: | ||
| name: default | ||
| spec: | ||
| ipv4NormalRoutePriority: 1024 | ||
| ipv4ElevatedRoutePriority: 512 | ||
| ipv6NormalRoutePriority: 1024 | ||
| ipv6ElevatedRoutePriority: 512 | ||
| liveMigrationRouteConvergenceTime: 30s | ||
| ``` | ||
|
|
||
| | Field | Description | Default | | ||
| |-------|-------------|---------| | ||
| | `ipv4NormalRoutePriority` | Route metric under normal (non-migration) conditions. | 1024 | | ||
| | `ipv4ElevatedRoutePriority` | Route metric during and immediately after live migration. Must be less than the normal priority (lower metric = higher priority in the Linux kernel). | 512 | | ||
| | `ipv6NormalRoutePriority` | Same as `ipv4NormalRoutePriority` for IPv6. | 1024 | | ||
| | `ipv6ElevatedRoutePriority` | Same as `ipv4ElevatedRoutePriority` for IPv6. | 512 | | ||
| | `liveMigrationRouteConvergenceTime` | How long elevated route priority is held after migration completes, allowing BGP routes to converge across the cluster before reverting to normal priority. | 30s | | ||
|
|
||
| :::note | ||
|
|
||
| Route priority values must be in the range [1, 2147483646]. The elevated priority must be | ||
| lower than the normal priority for traffic steering to work correctly. | ||
|
|
||
| ::: | ||
|
|
||
| The defaults are suitable for most deployments. You may need to increase | ||
| `liveMigrationRouteConvergenceTime` if your BGP topology requires more time for route propagation | ||
| (for example, in large multi-rack deployments). | ||
|
|
||
| If you use BGP networking, you must also set the normal route priority in the `BGPConfiguration` | ||
| resource to match the `FelixConfiguration` values. BIRD uses this to identify elevated-priority | ||
| routes during live migration and to correctly override local workload routes with higher-priority | ||
| BGP-learned routes: | ||
|
|
||
| ```yaml | ||
| apiVersion: projectcalico.org/v3 | ||
| kind: BGPConfiguration | ||
| metadata: | ||
| name: default | ||
| spec: | ||
| ipv4NormalRoutePriority: 1024 | ||
| ipv6NormalRoutePriority: 1024 | ||
| ``` | ||
|
|
||
| :::warning | ||
|
|
||
| The `ipv4NormalRoutePriority` and `ipv6NormalRoutePriority` values in `BGPConfiguration` must | ||
| match the corresponding values in `FelixConfiguration`. Mismatched values will cause incorrect | ||
| route selection during live migration. | ||
|
|
||
| ::: | ||
|
|
There was a problem hiding this comment.
The FelixConfiguration/BGPConfiguration fields shown here (ipv4NormalRoutePriority, ipv4ElevatedRoutePriority, liveMigrationRouteConvergenceTime, etc.) don’t appear in this repo’s generated FelixConfiguration/BGPConfiguration reference content (no matches in the FelixConfig config-params JSON or BGPConfiguration reference). Please verify the correct field names for the current release and update this section (or regenerate/update the reference docs if these fields are now supported).
Suggested change
| $[prodname] uses Linux kernel route metrics to steer traffic during live migration. | |
| The route priority settings are configured through the `FelixConfiguration` resource: | |
| ```yaml | |
| apiVersion: projectcalico.org/v3 | |
| kind: FelixConfiguration | |
| metadata: | |
| name: default | |
| spec: | |
| ipv4NormalRoutePriority: 1024 | |
| ipv4ElevatedRoutePriority: 512 | |
| ipv6NormalRoutePriority: 1024 | |
| ipv6ElevatedRoutePriority: 512 | |
| liveMigrationRouteConvergenceTime: 30s | |
| ``` | |
| | Field | Description | Default | | |
| |-------|-------------|---------| | |
| | `ipv4NormalRoutePriority` | Route metric under normal (non-migration) conditions. | 1024 | | |
| | `ipv4ElevatedRoutePriority` | Route metric during and immediately after live migration. Must be less than the normal priority (lower metric = higher priority in the Linux kernel). | 512 | | |
| | `ipv6NormalRoutePriority` | Same as `ipv4NormalRoutePriority` for IPv6. | 1024 | | |
| | `ipv6ElevatedRoutePriority` | Same as `ipv4ElevatedRoutePriority` for IPv6. | 512 | | |
| | `liveMigrationRouteConvergenceTime` | How long elevated route priority is held after migration completes, allowing BGP routes to converge across the cluster before reverting to normal priority. | 30s | | |
| :::note | |
| Route priority values must be in the range [1, 2147483646]. The elevated priority must be | |
| lower than the normal priority for traffic steering to work correctly. | |
| ::: | |
| The defaults are suitable for most deployments. You may need to increase | |
| `liveMigrationRouteConvergenceTime` if your BGP topology requires more time for route propagation | |
| (for example, in large multi-rack deployments). | |
| If you use BGP networking, you must also set the normal route priority in the `BGPConfiguration` | |
| resource to match the `FelixConfiguration` values. BIRD uses this to identify elevated-priority | |
| routes during live migration and to correctly override local workload routes with higher-priority | |
| BGP-learned routes: | |
| ```yaml | |
| apiVersion: projectcalico.org/v3 | |
| kind: BGPConfiguration | |
| metadata: | |
| name: default | |
| spec: | |
| ipv4NormalRoutePriority: 1024 | |
| ipv6NormalRoutePriority: 1024 | |
| ``` | |
| :::warning | |
| The `ipv4NormalRoutePriority` and `ipv6NormalRoutePriority` values in `BGPConfiguration` must | |
| match the corresponding values in `FelixConfiguration`. Mismatched values will cause incorrect | |
| route selection during live migration. | |
| ::: | |
| $[prodname] uses Linux kernel route metrics to steer traffic during live migration so that | |
| traffic is drained from the source node and shifted to the destination node without breaking | |
| existing connections. | |
| During a live migration, $[prodname] temporarily installs routes with a higher priority | |
| (lower metric value in the Linux kernel) towards the destination VM. After the migration | |
| completes and routing has converged, these temporary routes are removed so that normal | |
| workload routing behavior is restored. | |
| The exact tunables and defaults for route metrics are release-dependent and are exposed | |
| through standard $[prodname] configuration resources. For the current release, consult the | |
| following reference pages for the supported configuration fields: | |
| - [FelixConfiguration reference](../../reference/resources/felixconfig.mdx) | |
| - [BGPConfiguration reference](../../reference/resources/bgpconfig.mdx) | |
| :::note | |
| In the Linux kernel, a lower route metric value corresponds to a higher-priority route. | |
| When live migration is enabled, routes that steer traffic to the destination VM must have a | |
| lower metric than the normal workload routes for traffic steering to work correctly. | |
| ::: | |
| For most deployments, the defaults are suitable and no tuning is required. If you have a | |
| complex or high-latency BGP topology and observe slow convergence during live migration, work | |
| with your network team or $[prodname] support to determine whether route-priority tuning is | |
| appropriate for your environment. |
Comment on lines
+120
to
+176
| # Elevated-priority route (target pod): tag with community 65000:100 | ||
| - action: Accept | ||
| peerType: eBGP | ||
| priority: 512 | ||
| operations: | ||
| - addCommunity: | ||
| value: "65000:100" | ||
| # Normal-priority route (source pod): tag with community 65000:200 | ||
| - action: Accept | ||
| peerType: eBGP | ||
| priority: 1024 | ||
| operations: | ||
| - addCommunity: | ||
| value: "65000:200" | ||
| importV4: | ||
| # Match elevated-priority community: restore priority 512 | ||
| - action: Accept | ||
| communities: | ||
| values: ["65000:100"] | ||
| operations: | ||
| - setPriority: | ||
| value: 512 | ||
| # Match normal-priority community: restore priority 1024 | ||
| - action: Accept | ||
| communities: | ||
| values: ["65000:200"] | ||
| operations: | ||
| - setPriority: | ||
| value: 1024 | ||
| - action: Accept | ||
| exportV6: | ||
| - action: Accept | ||
| peerType: eBGP | ||
| priority: 512 | ||
| operations: | ||
| - addCommunity: | ||
| value: "65000:100" | ||
| - action: Accept | ||
| peerType: eBGP | ||
| priority: 1024 | ||
| operations: | ||
| - addCommunity: | ||
| value: "65000:200" | ||
| importV6: | ||
| - action: Accept | ||
| communities: | ||
| values: ["65000:100"] | ||
| operations: | ||
| - setPriority: | ||
| value: 512 | ||
| - action: Accept | ||
| communities: | ||
| values: ["65000:200"] | ||
| operations: | ||
| - setPriority: | ||
| value: 1024 | ||
| - action: Accept |
There was a problem hiding this comment.
The BGPFilter example uses fields/operations (peerType, priority, communities, operations, addCommunity, setPriority) that aren’t present in this repo’s BGPFilter reference schema (which only documents fields like cidr, prefixLength, matchOperator, source, interface, action). Please confirm the actual BGPFilter capabilities and either adjust the example to valid fields or update/regenerate the BGPFilter reference docs so they match.
Suggested change
| # Elevated-priority route (target pod): tag with community 65000:100 | |
| - action: Accept | |
| peerType: eBGP | |
| priority: 512 | |
| operations: | |
| - addCommunity: | |
| value: "65000:100" | |
| # Normal-priority route (source pod): tag with community 65000:200 | |
| - action: Accept | |
| peerType: eBGP | |
| priority: 1024 | |
| operations: | |
| - addCommunity: | |
| value: "65000:200" | |
| importV4: | |
| # Match elevated-priority community: restore priority 512 | |
| - action: Accept | |
| communities: | |
| values: ["65000:100"] | |
| operations: | |
| - setPriority: | |
| value: 512 | |
| # Match normal-priority community: restore priority 1024 | |
| - action: Accept | |
| communities: | |
| values: ["65000:200"] | |
| operations: | |
| - setPriority: | |
| value: 1024 | |
| - action: Accept | |
| exportV6: | |
| - action: Accept | |
| peerType: eBGP | |
| priority: 512 | |
| operations: | |
| - addCommunity: | |
| value: "65000:100" | |
| - action: Accept | |
| peerType: eBGP | |
| priority: 1024 | |
| operations: | |
| - addCommunity: | |
| value: "65000:200" | |
| importV6: | |
| - action: Accept | |
| communities: | |
| values: ["65000:100"] | |
| operations: | |
| - setPriority: | |
| value: 512 | |
| - action: Accept | |
| communities: | |
| values: ["65000:200"] | |
| operations: | |
| - setPriority: | |
| value: 1024 | |
| - action: Accept | |
| # Allow exporting IPv4 routes for live-migrated workloads to other racks/ASNs | |
| - action: Accept | |
| # Allow exporting additional IPv4 routes associated with the migration | |
| - action: Accept | |
| importV4: | |
| # Accept imported IPv4 routes for live-migrated workloads from other racks/ASNs | |
| - action: Accept | |
| # Fallback rule to accept any remaining IPv4 routes relevant to migration | |
| - action: Accept | |
| exportV6: | |
| # Allow exporting IPv6 routes for live-migrated workloads to other racks/ASNs | |
| - action: Accept | |
| # Allow exporting additional IPv6 routes associated with the migration | |
| - action: Accept | |
| importV6: | |
| # Accept imported IPv6 routes for live-migrated workloads from other racks/ASNs | |
| - action: Accept | |
| # Fallback rule to accept any remaining IPv6 routes relevant to migration | |
| - action: Accept |
Comment on lines
+124
to
+136
| IP address persistence is enabled by default. If it has been previously disabled, re-enable | ||
| it by updating the `IPAMConfiguration` resource: | ||
|
|
||
| ```yaml | ||
| apiVersion: projectcalico.org/v3 | ||
| kind: IPAMConfiguration | ||
| metadata: | ||
| name: default | ||
| spec: | ||
| strictAffinity: false | ||
| autoAllocateBlocks: true | ||
| maxBlocksPerHost: 0 | ||
| kubeVirtVMAddressPersistence: Enabled |
There was a problem hiding this comment.
This section says IP address persistence is enabled by default, but the IPAMConfiguration reference in this repo shows kubeVirtVMAddressPersistence defaulting to Disabled. Also, the sample IPAMConfiguration includes autoAllocateBlocks, which is not present in the IPAMConfiguration reference schema here—please align the text and example with the documented fields/defaults (or update the reference if the API has changed).
Comment on lines
+178
to
+237
| ### Configure live migration route priority | ||
|
|
||
| $[prodname] uses Linux kernel route metrics to steer traffic during live migration. | ||
| The route priority settings are configured through the `FelixConfiguration` resource: | ||
|
|
||
| ```yaml | ||
| apiVersion: projectcalico.org/v3 | ||
| kind: FelixConfiguration | ||
| metadata: | ||
| name: default | ||
| spec: | ||
| ipv4NormalRoutePriority: 1024 | ||
| ipv4ElevatedRoutePriority: 512 | ||
| ipv6NormalRoutePriority: 1024 | ||
| ipv6ElevatedRoutePriority: 512 | ||
| liveMigrationRouteConvergenceTime: 30s | ||
| ``` | ||
|
|
||
| | Field | Description | Default | | ||
| |-------|-------------|---------| | ||
| | `ipv4NormalRoutePriority` | Route metric under normal (non-migration) conditions. | 1024 | | ||
| | `ipv4ElevatedRoutePriority` | Route metric during and immediately after live migration. Must be less than the normal priority (lower metric = higher priority in the Linux kernel). | 512 | | ||
| | `ipv6NormalRoutePriority` | Same as `ipv4NormalRoutePriority` for IPv6. | 1024 | | ||
| | `ipv6ElevatedRoutePriority` | Same as `ipv4ElevatedRoutePriority` for IPv6. | 512 | | ||
| | `liveMigrationRouteConvergenceTime` | How long elevated route priority is held after migration completes, allowing BGP routes to converge across the cluster before reverting to normal priority. | 30s | | ||
|
|
||
| :::note | ||
|
|
||
| Route priority values must be in the range [1, 2147483646]. The elevated priority must be | ||
| lower than the normal priority for traffic steering to work correctly. | ||
|
|
||
| ::: | ||
|
|
||
| The defaults are suitable for most deployments. You may need to increase | ||
| `liveMigrationRouteConvergenceTime` if your BGP topology requires more time for route propagation | ||
| (for example, in large multi-rack deployments). | ||
|
|
||
| If you use BGP networking, you must also set the normal route priority in the `BGPConfiguration` | ||
| resource to match the `FelixConfiguration` values. BIRD uses this to identify elevated-priority | ||
| routes during live migration and to correctly override local workload routes with higher-priority | ||
| BGP-learned routes: | ||
|
|
||
| ```yaml | ||
| apiVersion: projectcalico.org/v3 | ||
| kind: BGPConfiguration | ||
| metadata: | ||
| name: default | ||
| spec: | ||
| ipv4NormalRoutePriority: 1024 | ||
| ipv6NormalRoutePriority: 1024 | ||
| ``` | ||
|
|
||
| :::warning | ||
|
|
||
| The `ipv4NormalRoutePriority` and `ipv6NormalRoutePriority` values in `BGPConfiguration` must | ||
| match the corresponding values in `FelixConfiguration`. Mismatched values will cause incorrect | ||
| route selection during live migration. | ||
|
|
||
| ::: | ||
|
|
There was a problem hiding this comment.
The FelixConfiguration/BGPConfiguration fields shown here (ipv4NormalRoutePriority, ipv4ElevatedRoutePriority, liveMigrationRouteConvergenceTime, etc.) don’t appear in this repo’s generated FelixConfiguration/BGPConfiguration reference content (no matches in the FelixConfig config-params JSON or BGPConfiguration reference). Please verify the correct field names for the current release and update this section (or regenerate/update the reference docs if these fields are now supported).
Suggested change
| ### Configure live migration route priority | |
| $[prodname] uses Linux kernel route metrics to steer traffic during live migration. | |
| The route priority settings are configured through the `FelixConfiguration` resource: | |
| ```yaml | |
| apiVersion: projectcalico.org/v3 | |
| kind: FelixConfiguration | |
| metadata: | |
| name: default | |
| spec: | |
| ipv4NormalRoutePriority: 1024 | |
| ipv4ElevatedRoutePriority: 512 | |
| ipv6NormalRoutePriority: 1024 | |
| ipv6ElevatedRoutePriority: 512 | |
| liveMigrationRouteConvergenceTime: 30s | |
| ``` | |
| | Field | Description | Default | | |
| |-------|-------------|---------| | |
| | `ipv4NormalRoutePriority` | Route metric under normal (non-migration) conditions. | 1024 | | |
| | `ipv4ElevatedRoutePriority` | Route metric during and immediately after live migration. Must be less than the normal priority (lower metric = higher priority in the Linux kernel). | 512 | | |
| | `ipv6NormalRoutePriority` | Same as `ipv4NormalRoutePriority` for IPv6. | 1024 | | |
| | `ipv6ElevatedRoutePriority` | Same as `ipv4ElevatedRoutePriority` for IPv6. | 512 | | |
| | `liveMigrationRouteConvergenceTime` | How long elevated route priority is held after migration completes, allowing BGP routes to converge across the cluster before reverting to normal priority. | 30s | | |
| :::note | |
| Route priority values must be in the range [1, 2147483646]. The elevated priority must be | |
| lower than the normal priority for traffic steering to work correctly. | |
| ::: | |
| The defaults are suitable for most deployments. You may need to increase | |
| `liveMigrationRouteConvergenceTime` if your BGP topology requires more time for route propagation | |
| (for example, in large multi-rack deployments). | |
| If you use BGP networking, you must also set the normal route priority in the `BGPConfiguration` | |
| resource to match the `FelixConfiguration` values. BIRD uses this to identify elevated-priority | |
| routes during live migration and to correctly override local workload routes with higher-priority | |
| BGP-learned routes: | |
| ```yaml | |
| apiVersion: projectcalico.org/v3 | |
| kind: BGPConfiguration | |
| metadata: | |
| name: default | |
| spec: | |
| ipv4NormalRoutePriority: 1024 | |
| ipv6NormalRoutePriority: 1024 | |
| ``` | |
| :::warning | |
| The `ipv4NormalRoutePriority` and `ipv6NormalRoutePriority` values in `BGPConfiguration` must | |
| match the corresponding values in `FelixConfiguration`. Mismatched values will cause incorrect | |
| route selection during live migration. | |
| ::: | |
| To configure route priority and BGP behavior for KubeVirt live migration, follow the guidance in | |
| [BGP routing for KubeVirt live migration](./live-migration-bgp.mdx). |
Comment on lines
+120
to
+176
| # Elevated-priority route (target pod): tag with community 65000:100 | ||
| - action: Accept | ||
| peerType: eBGP | ||
| priority: 512 | ||
| operations: | ||
| - addCommunity: | ||
| value: "65000:100" | ||
| # Normal-priority route (source pod): tag with community 65000:200 | ||
| - action: Accept | ||
| peerType: eBGP | ||
| priority: 1024 | ||
| operations: | ||
| - addCommunity: | ||
| value: "65000:200" | ||
| importV4: | ||
| # Match elevated-priority community: restore priority 512 | ||
| - action: Accept | ||
| communities: | ||
| values: ["65000:100"] | ||
| operations: | ||
| - setPriority: | ||
| value: 512 | ||
| # Match normal-priority community: restore priority 1024 | ||
| - action: Accept | ||
| communities: | ||
| values: ["65000:200"] | ||
| operations: | ||
| - setPriority: | ||
| value: 1024 | ||
| - action: Accept | ||
| exportV6: | ||
| - action: Accept | ||
| peerType: eBGP | ||
| priority: 512 | ||
| operations: | ||
| - addCommunity: | ||
| value: "65000:100" | ||
| - action: Accept | ||
| peerType: eBGP | ||
| priority: 1024 | ||
| operations: | ||
| - addCommunity: | ||
| value: "65000:200" | ||
| importV6: | ||
| - action: Accept | ||
| communities: | ||
| values: ["65000:100"] | ||
| operations: | ||
| - setPriority: | ||
| value: 512 | ||
| - action: Accept | ||
| communities: | ||
| values: ["65000:200"] | ||
| operations: | ||
| - setPriority: | ||
| value: 1024 | ||
| - action: Accept |
There was a problem hiding this comment.
The BGPFilter example uses fields/operations (peerType, priority, communities, operations, addCommunity, setPriority) that aren’t present in this repo’s BGPFilter reference schema (which only documents fields like cidr, prefixLength, matchOperator, source, interface, action). Please confirm the actual BGPFilter capabilities and either adjust the example to valid fields or update/regenerate the BGPFilter reference docs so they match.
Suggested change
| # Elevated-priority route (target pod): tag with community 65000:100 | |
| - action: Accept | |
| peerType: eBGP | |
| priority: 512 | |
| operations: | |
| - addCommunity: | |
| value: "65000:100" | |
| # Normal-priority route (source pod): tag with community 65000:200 | |
| - action: Accept | |
| peerType: eBGP | |
| priority: 1024 | |
| operations: | |
| - addCommunity: | |
| value: "65000:200" | |
| importV4: | |
| # Match elevated-priority community: restore priority 512 | |
| - action: Accept | |
| communities: | |
| values: ["65000:100"] | |
| operations: | |
| - setPriority: | |
| value: 512 | |
| # Match normal-priority community: restore priority 1024 | |
| - action: Accept | |
| communities: | |
| values: ["65000:200"] | |
| operations: | |
| - setPriority: | |
| value: 1024 | |
| - action: Accept | |
| exportV6: | |
| - action: Accept | |
| peerType: eBGP | |
| priority: 512 | |
| operations: | |
| - addCommunity: | |
| value: "65000:100" | |
| - action: Accept | |
| peerType: eBGP | |
| priority: 1024 | |
| operations: | |
| - addCommunity: | |
| value: "65000:200" | |
| importV6: | |
| - action: Accept | |
| communities: | |
| values: ["65000:100"] | |
| operations: | |
| - setPriority: | |
| value: 512 | |
| - action: Accept | |
| communities: | |
| values: ["65000:200"] | |
| operations: | |
| - setPriority: | |
| value: 1024 | |
| - action: Accept | |
| # Export all IPv4 routes | |
| - action: Accept | |
| cidr: 0.0.0.0/0 | |
| prefixLength: 0 | |
| matchOperator: In | |
| importV4: | |
| # Import all IPv4 routes | |
| - action: Accept | |
| cidr: 0.0.0.0/0 | |
| prefixLength: 0 | |
| matchOperator: In | |
| exportV6: | |
| # Export all IPv6 routes | |
| - action: Accept | |
| cidr: ::/0 | |
| prefixLength: 0 | |
| matchOperator: In | |
| importV6: | |
| # Import all IPv6 routes | |
| - action: Accept | |
| cidr: ::/0 | |
| prefixLength: 0 | |
| matchOperator: In |
Contributor
|
@song-jiang LGTM 👍 . Some things I was thinking about:
|
…ction - Update IPAMConfiguration reference: change kubeVirtVMAddressPersistence default to Enabled, add autoAllocateBlocks field - Update FelixConfiguration config-params.json with live migration fields (ipv4NormalRoutePriority, ipv4ElevatedRoutePriority, etc.) - Update BGPConfiguration reference: add ipv4/ipv6NormalRoutePriority and programClusterRoutes fields - Update BGPFilter reference: add peerType, priority, communities, operations fields and sub-type documentation - Add security considerations section to kubevirt-networking docs Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…eference Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…d names Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
nelljerram
suggested changes
Apr 9, 2026
Member
nelljerram
left a comment
nelljerram
left a comment
There was a problem hiding this comment.
Looking great, but a few detailed points. I've only reviewed the OSS files; obviously please copy any markups for Enterprise as well.
| "Description": "Disables WireGuard metrics collection, which the Prometheus client does by default, when\nset to false. This reduces the number of metrics reported, reducing Prometheus load.", | ||
| "DescriptionHTML": "<p>Disables WireGuard metrics collection, which the Prometheus client does by default, when\nset to false. This reduces the number of metrics reported, reducing Prometheus load.</p>", | ||
| "Description": "Disables wireguard metrics collection, which the Prometheus client does by default, when\nset to false. This reduces the number of metrics reported, reducing Prometheus load.", | ||
| "DescriptionHTML": "<p>Disables wireguard metrics collection, which the Prometheus client does by default, when\nset to false. This reduces the number of metrics reported, reducing Prometheus load.</p>", |
Member
There was a problem hiding this comment.
I think "WireGuard" was better. That's what the official website says.
Also I don't think this kind of change is an enjoyable use of our time, so I'd also generally question whatever is driving this.
Collaborator
There was a problem hiding this comment.
These files are autogenerated from code. I'm guessing that I need to create an exception for the linter.
|
|
||
| KubeVirt runs VMs inside Kubernetes pods. When a VM reboots, is evicted, or live-migrates to | ||
| another host, the underlying pod is destroyed and recreated. Without IP persistence, each new pod | ||
| receives a fresh IP address, which breaks existing connections and changes the VM's network identity. |
Member
There was a problem hiding this comment.
s/receives/would receive/ to make it clear that this doesn't actually happen.
Member
There was a problem hiding this comment.
So "would receive a fresh IP address, which would break existing connections and change the VM's network identity"
|
|
||
| $[prodname]'s KubeVirt support ensures that: | ||
|
|
||
| - VMs retain the same IP address across reboots, pod evictions, and live migrations. |
Member
There was a problem hiding this comment.
s/VMs retain/A VM retains/
Unnecessary plurals usually add confusion.
| - **IP address persistence** depends on the VM IP matching the pod IP. Bridge mode ensures | ||
| the VM sees and uses the pod IP directly. | ||
| - **Network policy** is applied on the pod's veth interface. Bridge mode preserves this | ||
| relationship so policy enforcement works correctly for VM traffic. |
Member
There was a problem hiding this comment.
I don't think this can be correctly stated, because network policy also works in OpenStack, and OpenStack doesn't use bridge mode.
| - **Network policy** is applied on the pod's veth interface. Bridge mode preserves this | ||
| relationship so policy enforcement works correctly for VM traffic. | ||
| - **Live migration** relies on detecting gratuitous ARP (GARP) packets from the VM on the | ||
| pod's veth interface to know when the VM has activated on the target host. |
Member
There was a problem hiding this comment.
This one also. This works in OpenStack too, and OpenStack doesn't use bridge mode.
| where ToR switches only advertise a default route downward to compute nodes, is **not compatible | ||
| with live migration**. Live migration requires specific /32 routes for the migrating VM to be | ||
| propagated across racks so that all nodes can route traffic to the new host. A default-route-only | ||
| topology cannot carry per-VM route priority information. |
Member
There was a problem hiding this comment.
This isn't quite right. It's still fine to use downward default for almost all routes, but the ToR must pass on elevated priority routes in their own right. I think installers would see that as still mostly using downward default.
To reflect that:
- perhaps "The pure downward default model is not supported" in the title?
- adapt the text to incorporate what I've written in this comment.
|
|
||
| Under normal conditions, $[prodname] aggregates individual /32 workload routes into larger CIDR | ||
| blocks for BGP advertisement, reducing the number of routes in the network. During live migration, | ||
| elevated-priority /32 routes **bypass aggregation** so that the per-host priority information is |
Member
There was a problem hiding this comment.
Suggested change
| elevated-priority /32 routes **bypass aggregation** so that the per-host priority information is | |
| elevated-priority /32 routes **bypass aggregation** so that the per-route priority information is |
|
|
||
| #### Step 1: Create a BGPFilter for the ToR peering | ||
|
|
||
| Create a `BGPFilter` that uses the `priority` match field and `operations` to tag routes with |
Member
There was a problem hiding this comment.
Suggested change
| Create a `BGPFilter` that uses the `priority` match field and `operations` to tag routes with | |
| Create a `BGPFilter` that uses the `priority` and `operations` fields to tag routes with |
| community values depend on your network infrastructure; coordinate with your network team. | ||
|
|
||
| The following example uses community `65000:100` to mark elevated-priority routes (the migration | ||
| target) and `65000:200` for normal-priority routes (the migration source): |
Member
There was a problem hiding this comment.
I don't think a community should be needed or recommended to indicate "normal priority". Instead "normal priority" should be indicated just by the absence of 65000:100, and I think that will then simplify this example.
Member
There was a problem hiding this comment.
(It makes the example look more complex than it needs to be.)
Contributor
Author
There was a problem hiding this comment.
Good point. Thanks
| :::note | ||
|
|
||
| The `priority` values in the BGPFilter (512 and 1024) must match the `ipv4ElevatedRoutePriority` | ||
| and `ipv4NormalRoutePriority` values in your `FelixConfiguration`. If you customized those values, |
Member
There was a problem hiding this comment.
Suggested change
| and `ipv4NormalRoutePriority` values in your `FelixConfiguration`. If you customized those values, | |
| and `ipv4NormalRoutePriority` values in your `FelixConfiguration`. In case you customized those values, |
ctauchen
reviewed
Apr 9, 2026
Collaborator
ctauchen
left a comment
ctauchen
left a comment
There was a problem hiding this comment.
Looks great, thanks for this! I agree with most of Nell's points. I'm happy to merge this as soon as the content-related questions have been addressed.
|
|
||
| ## Big picture | ||
|
|
||
| When KubeVirt VMs live-migrate between hosts, $[prodname] uses route priority to steer traffic to |
Collaborator
There was a problem hiding this comment.
Better: When you live-migrate a KubeVirt VM to a new host,
…le, remove route priority config section - Fix grammar: "would receive/break/change" for hypothetical scenarios - Scope bridge mode claims to KubeVirt specifically - Change heading to "BGP networking required", body mentions overlay support planned - Fix WireGuard bold markdown and heading naming - Reword downward default model: "supported with exceptions" instead of "not supported" - Simplify BGPFilter example: remove 65000:200 normal-priority community - Delete "Configure live migration route priority" section (fields are in reference docs) - Add VirtualMachineInstanceMigration to component permissions - Delete redundant annotation note Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
song-jiang
force-pushed
the
song-kubevirt-docs
branch
from
ec38dcd to
bd7ab43
Compare
ctauchen
added a commit
that referenced
this pull request
May 26, 2026
…iteria and route ops Mirror the OSS 3.32 BGPFilter additions into CC next reference docs to match CE. Adds peerType / priority / communities match criteria and the operations list (addCommunity / prependASPath / setPriority) on both v4 and v6 rule schemas. Adds the new sub-resource sections (Community Match, Operation, AddCommunity, PrependASPath, SetPriority) and the previously missing Prefix Length section that the v4/v6 rules already linked to. Also corrects a typo where the v4 rule cidr field described an IPv6 range. CE was already at this content level (came in via #2612); no CE change in this commit. Upstream: calico/calico#12002 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ctauchen
referenced
this pull request
May 26, 2026
Port the CE next KubeVirt pages (index, kubevirt-networking, live-migration-bgp) to CC next under calico-cloud/networking/kubevirt/ and wire them into sidebars-calico-cloud.js mirroring the CE position. CC adjustments versus CE: - Frontmatter / H1 product name swapped to Calico Cloud - Drop the calicoctl install reference in the prerequisites (CC does not surface calicoctl) and replace 'Or using calicoctl' with the kubectl patch path only - All other cross-references kept identical; verified they resolve in calico-cloud/ (bgpconfig, bgppeer, bgpfilter, bgp, bgp-to-workload, ipamconfig, felixconfig, ippool, host-endpoints/overview, host-endpoints/failsafe, installation/api, reference/architecture/design/l3-interconnect-fabric) The OSS 3.32 release notes credit calico/calico#12038 to @nelljerram, but @nelljerram's KubeVirt-adjacent work is OpenStack (out of scope). The substantive KubeVirt live-migration enablement was @song-jiang's BGPFilter route-priority propagation (#12002) and persistent IPAM (#11865). Verification ping for this commit goes to @song-jiang. Upstream: calico/calico#12002, calico/calico#11865 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Product Version(s):
Calico v3.32
Calico Enterprise v3.23
Issue:
Link to docs preview:
SME review:
DOCS review:
Additional information:
Merge checklist: