Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Instance V2P management functions should include the instance's current sled #3107

Closed
gjcolombo opened this issue May 12, 2023 · 1 comment · Fixed by #5568
Closed

Instance V2P management functions should include the instance's current sled #3107

gjcolombo opened this issue May 12, 2023 · 1 comment · Fixed by #5568

Comments

@gjcolombo
Copy link
Contributor

create_instance_v2p_mappings (and its delete counterpart) take an instance and propagate V2P mappings for that instance's NICs to every sled except the instance's current sled. Nexus ignores the current sled because incarnating an instance on a sled (or stopping an incarnation of an instance on a sled) creates (or destroys) XDE ports for that instance's NICs, and the XDE driver creates/destroys the relevant mappings on the local sled when it creates/destroys the port.

This behavior creates some tension for live migration, because Nexus has to worry about being undercut by XDE while applying mappings after a migration completes. The plan to resolve this tension is to have XDE stop manipulating mappings on port creation/deletion (oxidecomputer/opte#368) and let Nexus manage them all instead. Once that change lands and Nexus ingests it, Nexus's V2P mapping routines will need to stop skipping their subject instances' current sleds.

@internet-diglett
Copy link
Contributor

Marked this for resolution in #5568

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants