starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

VLAN Group Scoping and Virtual Machines #7459

New Issue
Closed
opened 2025-12-29 20:23:40 +01:00 by adam · 3 comments
adam commented 2025-12-29 20:23:40 +01:00
Owner
Copy Link

Originally created by @adparis99 on GitHub (Jan 5, 2023).

NetBox version

v3.3 (Also Tested in v3.4.2 demo)

Python version

3.10

Steps to Reproduce

  1. Create a VLAN Group (Group X) scoped to Site X, Location X
  2. Create a VLAN (VLAN X) assigned to Group X
  3. Create a virtual host device (Device X) that is assigned to a cluster, site (Site X), and location (Location X)
  4. Create a virtual machine (VM X) assigned to Device X
  5. Add an interface to VM X
  6. Attempt to assign VLAN X to the newly created interface on VM X

Expected Behavior

I expected VLAN X to be available to be assigned to the new interface for VM X. It seems logical for a VM to have access to any VLANs that its host device has access to.

Observed Behavior

VLAN X doesn't show up in the list of VLANs available to be assigned to the virtual machine interface. Other VLANs that are in groups scoped directly to Site X as well as those not in groups show up as available, but not any VLANs scoped directly to Location X. My best guess is this has to do with the fact that both clusters and virtual machines can only be assigned to sites, while devices can be assigned to both sites and locations.

Originally created by @adparis99 on GitHub (Jan 5, 2023). ### NetBox version v3.3 (Also Tested in v3.4.2 demo) ### Python version 3.10 ### Steps to Reproduce 1. Create a VLAN Group (Group X) scoped to Site X, Location X 2. Create a VLAN (VLAN X) assigned to Group X 3. Create a virtual host device (Device X) that is assigned to a cluster, site (Site X), and location (Location X) 4. Create a virtual machine (VM X) assigned to Device X 5. Add an interface to VM X 6. Attempt to assign VLAN X to the newly created interface on VM X ### Expected Behavior I expected VLAN X to be available to be assigned to the new interface for VM X. It seems logical for a VM to have access to any VLANs that its host device has access to. ### Observed Behavior VLAN X doesn't show up in the list of VLANs available to be assigned to the virtual machine interface. Other VLANs that are in groups scoped directly to Site X as well as those not in groups show up as available, but not any VLANs scoped directly to Location X. My best guess is this has to do with the fact that both clusters and virtual machines can only be assigned to sites, while devices can be assigned to both sites and locations.
adam closed this issue 2025-12-29 20:23:40 +01:00
adam commented 2025-12-29 20:23:42 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jan 5, 2023):

I also ran into this issue back on v3.2 and completely forgot to re-test after upgrading. The issue does seem to be related to clusters and virtual machines not being able to be assigned to locations, because changing the scope for the VLAN Group to just the Site instead resolves the issue (which is what I ended up doing as a workaround). The correct solution to this would probably be to add support for clusters and virtual machines to be able to be assigned to a Location. It looks like that has already been proposed in #7699, but it is still marked as needing a milestone.

@sleepinggenius2 commented on GitHub (Jan 5, 2023): I also ran into this issue back on v3.2 and completely forgot to re-test after upgrading. The issue does seem to be related to clusters and virtual machines not being able to be assigned to locations, because changing the scope for the VLAN Group to just the Site instead resolves the issue (which is what I ended up doing as a workaround). The correct solution to this would probably be to add support for clusters and virtual machines to be able to be assigned to a Location. It looks like that has already been proposed in #7699, but it is still marked as needing a milestone.
adam commented 2025-12-29 20:23:42 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 6, 2023):

  1. Create a VLAN Group (Group X) scoped to Site X, Location X

You've limited the VLAN group to a specific location, whereas VMs must be assigned to sites and/or clusters. If you scope the group to the site, and then assign either the VM or its cluster to that site, the VLAN will be available.

It seems logical for a VM to have access to any VLANs that its host device has access to.

We can't make this assumption on behalf of the user. Physical and logical infrastructures often have very different topologies.

@jeremystretch commented on GitHub (Jan 6, 2023): > 1. Create a VLAN Group (Group X) scoped to Site X, Location X You've limited the VLAN group to a specific location, whereas VMs must be assigned to sites and/or clusters. If you scope the group to the site, and then assign either the VM or its cluster to that site, the VLAN will be available. > It seems logical for a VM to have access to any VLANs that its host device has access to. We can't make this assumption on behalf of the user. Physical and logical infrastructures often have very different topologies.
adam commented 2025-12-29 20:23:43 +01:00
Author
Owner
Copy Link

@adparis99 commented on GitHub (Jan 6, 2023):

  1. Create a VLAN Group (Group X) scoped to Site X, Location X

You've limited the VLAN group to a specific location, whereas VMs must be assigned to sites and/or clusters. If you scope the group to the site, and then assign either the VM or its cluster to that site, the VLAN will be available.

It seems logical for a VM to have access to any VLANs that its host device has access to.

We can't make this assumption on behalf of the user. Physical and logical infrastructures often have very different topologies.

With this being the case, is there still the intention to eventually allow clusters to be assigned to locations as @sleepinggenius2 mentioned? It seems like that would break down the proverbial wall I'm stuck at.

@adparis99 commented on GitHub (Jan 6, 2023): > > 1. Create a VLAN Group (Group X) scoped to Site X, Location X > > You've limited the VLAN group to a specific location, whereas VMs must be assigned to sites and/or clusters. If you scope the group to the site, and then assign either the VM or its cluster to that site, the VLAN will be available. > > > It seems logical for a VM to have access to any VLANs that its host device has access to. > > We can't make this assumption on behalf of the user. Physical and logical infrastructures often have very different topologies. With this being the case, is there still the intention to eventually allow clusters to be assigned to locations as @sleepinggenius2 mentioned? It seems like that would break down the proverbial wall I'm stuck at.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#7459
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?