DOCS-2997: Write the guide for preserving a VM IP and MAC address - #2948
Open
ctauchen wants to merge 1 commit into
Open
DOCS-2997: Write the guide for preserving a VM IP and MAC address#2948ctauchen wants to merge 1 commit into
ctauchen wants to merge 1 commit into
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 complete Calico Enterprise “next” documentation guide for onboarding a KubeVirt VM onto an L2 bridge network while preserving its original IP and MAC identity, emphasizing the correct (non-destructive) configuration order and verification steps.
Changes:
- Expands the VM identity page with explicit “configure before start” ordering guidance to avoid connection-breaking renumbering.
- Documents MAC and IP preservation mechanisms (KubeVirt
macAddressvshwAddr,ipAddrsvsipAddrsNoIpam) including common pitfalls and security/policy implications. - Adds verification steps (status write-back lookup, network-level checks), migration expectations, and supporting resource links.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
ctauchen
force-pushed
the
DOCS-2997-6-vm-identity
branch
from
August 21, 2026 11:08
ed76935 to
e2282a6
Compare
Fill in the guide for bringing a VM onto an L2 network holding its original IP address and MAC address. The guide states the order plainly, because getting it wrong is destructive. The values are declared on the VM before it starts, so the VM comes up already holding them. Starting the VM and renumbering it afterwards breaks every connection made in between. KubeVirt's own MAC address field is now honored alongside the annotation, so the guide presents both and warns that setting the two to conflicting values is rejected rather than resolved. OpenShift fills that field in automatically on new VMs, which makes the conflict easy to hit by accident. The section on what to expect during migration describes what the release implements rather than what a reader will experience, and says that it has not been through a full test cycle. Forklift carries a warning that Calico support for L2 networks is not in a released version. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ctauchen
force-pushed
the
DOCS-2997-6-vm-identity
branch
from
August 21, 2026 11:10
e2282a6 to
2f66490
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.
Suppressed comments (1)
calico-enterprise/networking/l2-bridge/vm-identity.mdx:176
- The "L2 bridge support and limitations" link currently points to
calico-enterprise/reference/l2-bridge-support.mdx, which is effectively empty (only section headings). This makes the additional-resource link misleading until that page has content.
## Additional resources
- [Connect workloads to an existing VLAN](connect-vlan.mdx)
- [About L2 bridge networking](about-l2-bridge.mdx)
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.
Suppressed comments (1)
calico-enterprise/networking/l2-bridge/vm-identity.mdx:119
- The
kubectl ... -o jsonpath=...expression is using dot-notation for an annotation key that contains a/(and-), which won’t be parsed as a valid JSONPath field name. Use bracket notation to access thecni.projectcalico.org/vlan10.network-statusannotation key so readers can copy/paste the command successfully.
-o jsonpath='{.items[0].metadata.annotations.cni\.projectcalico\.org/vlan10\.network-status}'
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.
Fills in the guide for bringing a VM onto an L2 network with its original IP address and MAC address. Sixth in the DOCS-2997 sequence, and it depends on an L2 network already existing.
The guide states the order plainly, because getting it wrong is destructive. The address and MAC address are declared on the VM before it starts, so the VM comes up already holding them. The review of the plan flagged that an earlier outline read as though you would start the VM and then move it to its old address, which breaks every connection made in between. The page now rules that out explicitly.
Other points:
Two things to check:
Changed page: https://deploy-preview-2948--calico-docs-preview-next.netlify.app/calico-enterprise/next/networking/l2-bridge/vm-identity