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

Having 2 VMs with the same name in 2 different clusters #1621

New Issue
Closed
opened 2025-12-29 16:33:33 +01:00 by adam · 6 comments
adam commented 2025-12-29 16:33:33 +01:00
Owner
Copy Link

Originally created by @mabazyar on GitHub (Mar 9, 2018).

Issue type

[] Feature request
[X] Bug report
[ ] Documentation

Environment

  • Python version: 3.5.2
  • NetBox version: v2.3.1

Description

A possibility which should be in place is that representing 2 VMs with identical name in two different clusters.

  1. Go to Virtualization > Virtual Machines
  2. Create a VM as "test" in cluser "testcluster1"
  3. repeat step1
  4. Create a VM as "test" in cluster "testcluster2"

It returns:

Virtual machine with this Name already exists.
Originally created by @mabazyar on GitHub (Mar 9, 2018). ### Issue type [] Feature request [X] Bug report [ ] Documentation ### Environment * Python version: 3.5.2 * NetBox version: v2.3.1 ### Description A possibility which should be in place is that representing 2 VMs with identical name in two different clusters. 1) Go to Virtualization > Virtual Machines 2) Create a VM as "test" in cluser "testcluster1" 3) repeat step1 4) Create a VM as "test" in cluster "testcluster2" It returns: ``` Virtual machine with this Name already exists. ```
adam closed this issue 2025-12-29 16:33:33 +01:00
adam commented 2025-12-29 16:33:34 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 12, 2018):

Like devices, each virtual machine must have a unique name. Removing this constraint would make it very difficult to unique identify virtual machines with the same name from one another. For example, importing IP addresses to be assigned to virtual machines would require specifying the name of each cluster as well as the VM itself.

Edit: And if #1943 is implemented, it will require specifying both the site and cluster name in addition to the VM name.

@jeremystretch commented on GitHub (Mar 12, 2018): Like devices, each virtual machine must have a unique name. Removing this constraint would make it very difficult to unique identify virtual machines with the same name from one another. For example, importing IP addresses to be assigned to virtual machines would require specifying the name of each cluster as well as the VM itself. Edit: And if #1943 is implemented, it will require specifying both the site _and_ cluster name in addition to the VM name.
adam commented 2025-12-29 16:33:34 +01:00
Author
Owner
Copy Link

@mabazyar commented on GitHub (Mar 15, 2018):

Of use-cases is having a failover cluster contains idetntical VM instances to take over the traffic as needed. It can not be represented in Netbox.

@mabazyar commented on GitHub (Mar 15, 2018): Of use-cases is having a failover cluster contains idetntical VM instances to take over the traffic as needed. It can not be represented in Netbox.
adam commented 2025-12-29 16:33:34 +01:00
Author
Owner
Copy Link

@pm17788 commented on GitHub (Jun 12, 2018):

I'd like to second that - we run into this issue as well. Currently, I have to cheat a bit and append various things to the name of the VM to reconcile this, but that's clearly not a clean solution.

@pm17788 commented on GitHub (Jun 12, 2018): I'd like to second that - we run into this issue as well. Currently, I have to cheat a bit and append various things to the name of the VM to reconcile this, but that's clearly not a clean solution.
adam commented 2025-12-29 16:33:34 +01:00
Author
Owner
Copy Link

@mhmaw commented on GitHub (Sep 13, 2018):

We would like this functionality changed aswell. Both our hypervisor platforms allows duplicate names, as these are just labels. VMs are identified by GUIDs instead.
And when there's customer selfservice access to these environments, the chance for multiple VMs called fx. SQL01 increases.

@mhmaw commented on GitHub (Sep 13, 2018): We would like this functionality changed aswell. Both our hypervisor platforms allows duplicate names, as these are just labels. VMs are identified by GUIDs instead. And when there's customer selfservice access to these environments, the chance for multiple VMs called fx. SQL01 increases.
adam commented 2025-12-29 16:33:34 +01:00
Author
Owner
Copy Link

@Grokzen commented on GitHub (Dec 18, 2018):

We solved this issue internally by adding 2 custom fields, hostname and dnsname. Then we use the name field as more of an asset-tag with the unique name constraint and we can set the same hostname and dnsname for different machines that belongs to different cluters.

@Grokzen commented on GitHub (Dec 18, 2018): We solved this issue internally by adding 2 custom fields, hostname and dnsname. Then we use the name field as more of an asset-tag with the unique name constraint and we can set the same hostname and dnsname for different machines that belongs to different cluters.
adam commented 2025-12-29 16:33:35 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 3, 2019):

I'm going to wrap this into #2669, since I think it makes sense to ultimately ensure we have a consistent approach to both devices and VMs. I believe we're leaning toward simply removing the uniqueness constraints on device and VM names.

@jeremystretch commented on GitHub (May 3, 2019): I'm going to wrap this into #2669, since I think it makes sense to ultimately ensure we have a consistent approach to both devices and VMs. I believe we're leaning toward simply removing the uniqueness constraints on device and VM names.
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#1621
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?