mirror of
https://github.com/netbox-community/netbox.git
synced 2026-01-12 05:20:31 +01:00
Discrete resource tracking for VirtualMachines #5946
Closed
opened 2025-12-29 19:34:35 +01:00 by adam
·
17 comments
No Branch/Tag Specified
main
update-changelog-comments-docs
feature-removal-issue-type
20911-dropdown
20239-plugin-menu-classes-mutable-state
21097-graphql-id-lookups
feature
fix_module_substitution
20923-dcim-templates
20044-elevation-stuck-lightmode
feature-ip-prefix-link
v4.5-beta1-release
20068-import-moduletype-attrs
20766-fix-german-translation-code-literals
20378-del-script
7604-filter-modifiers-v3
circuit-swap
12318-case-insensitive-uniqueness
20637-improve-device-q-filter
20660-script-load
19724-graphql
20614-update-ruff
14884-script
02496-max-page
19720-macaddress-interface-generic-relation
19408-circuit-terminations-export-templates
20203-openapi-check
fix-19669-api-image-download
7604-filter-modifiers
19275-fixes-interface-bulk-edit
fix-17794-get_field_value_return_list
11507-show-aggregate-and-rir-on-api
9583-add_column_specific_search_field_to_tables
v4.5.0
v4.4.10
v4.4.9
v4.5.0-beta1
v4.4.8
v4.4.7
v4.4.6
v4.4.5
v4.4.4
v4.4.3
v4.4.2
v4.4.1
v4.4.0
v4.3.7
v4.4.0-beta1
v4.3.6
v4.3.5
v4.3.4
v4.3.3
v4.3.2
v4.3.1
v4.3.0
v4.2.9
v4.3.0-beta2
v4.2.8
v4.3.0-beta1
v4.2.7
v4.2.6
v4.2.5
v4.2.4
v4.2.3
v4.2.2
v4.2.1
v4.2.0
v4.1.11
v4.1.10
v4.1.9
v4.1.8
v4.2-beta1
v4.1.7
v4.1.6
v4.1.5
v4.1.4
v4.1.3
v4.1.2
v4.1.1
v4.1.0
v4.0.11
v4.0.10
v4.0.9
v4.1-beta1
v4.0.8
v4.0.7
v4.0.6
v4.0.5
v4.0.3
v4.0.2
v4.0.1
v4.0.0
v3.7.8
v3.7.7
v4.0-beta2
v3.7.6
v3.7.5
v4.0-beta1
v3.7.4
v3.7.3
v3.7.2
v3.7.1
v3.7.0
v3.6.9
v3.6.8
v3.6.7
v3.7-beta1
v3.6.6
v3.6.5
v3.6.4
v3.6.3
v3.6.2
v3.6.1
v3.6.0
v3.5.9
v3.6-beta2
v3.5.8
v3.6-beta1
v3.5.7
v3.5.6
v3.5.5
v3.5.4
v3.5.3
v3.5.2
v3.5.1
v3.5.0
v3.4.10
v3.4.9
v3.5-beta2
v3.4.8
v3.5-beta1
v3.4.7
v3.4.6
v3.4.5
v3.4.4
v3.4.3
v3.4.2
v3.4.1
v3.4.0
v3.3.10
v3.3.9
v3.4-beta1
v3.3.8
v3.3.7
v3.3.6
v3.3.5
v3.3.4
v3.3.3
v3.3.2
v3.3.1
v3.3.0
v3.2.9
v3.2.8
v3.3-beta2
v3.2.7
v3.3-beta1
v3.2.6
v3.2.5
v3.2.4
v3.2.3
v3.2.2
v3.2.1
v3.2.0
v3.1.11
v3.1.10
v3.2-beta2
v3.1.9
v3.2-beta1
v3.1.8
v3.1.7
v3.1.6
v3.1.5
v3.1.4
v3.1.3
v3.1.2
v3.1.1
v3.1.0
v3.0.12
v3.0.11
v3.0.10
v3.1-beta1
v3.0.9
v3.0.8
v3.0.7
v3.0.6
v3.0.5
v3.0.4
v3.0.3
v3.0.2
v3.0.1
v3.0.0
v2.11.12
v3.0-beta2
v2.11.11
v2.11.10
v3.0-beta1
v2.11.9
v2.11.8
v2.11.7
v2.11.6
v2.11.5
v2.11.4
v2.11.3
v2.11.2
v2.11.1
v2.11.0
v2.10.10
v2.10.9
v2.11-beta1
v2.10.8
v2.10.7
v2.10.6
v2.10.5
v2.10.4
v2.10.3
v2.10.2
v2.10.1
v2.10.0
v2.9.11
v2.10-beta2
v2.9.10
v2.10-beta1
v2.9.9
v2.9.8
v2.9.7
v2.9.6
v2.9.5
v2.9.4
v2.9.3
v2.9.2
v2.9.1
v2.9.0
v2.9-beta2
v2.8.9
v2.9-beta1
v2.8.8
v2.8.7
v2.8.6
v2.8.5
v2.8.4
v2.8.3
v2.8.2
v2.8.1
v2.8.0
v2.7.12
v2.7.11
v2.7.10
v2.7.9
v2.7.8
v2.7.7
v2.7.6
v2.7.5
v2.7.4
v2.7.3
v2.7.2
v2.7.1
v2.7.0
v2.6.12
v2.6.11
v2.6.10
v2.6.9
v2.7-beta1
Solcon-2020-01-06
v2.6.8
v2.6.7
v2.6.6
v2.6.5
v2.6.4
v2.6.3
v2.6.2
v2.6.1
v2.6.0
v2.5.13
v2.5.12
v2.6-beta1
v2.5.11
v2.5.10
v2.5.9
v2.5.8
v2.5.7
v2.5.6
v2.5.5
v2.5.4
v2.5.3
v2.5.2
v2.5.1
v2.5.0
v2.4.9
v2.5-beta2
v2.4.8
v2.5-beta1
v2.4.7
v2.4.6
v2.4.5
v2.4.4
v2.4.3
v2.4.2
v2.4.1
v2.4.0
v2.3.7
v2.4-beta1
v2.3.6
v2.3.5
v2.3.4
v2.3.3
v2.3.2
v2.3.1
v2.3.0
v2.2.10
v2.3-beta2
v2.2.9
v2.3-beta1
v2.2.8
v2.2.7
v2.2.6
v2.2.5
v2.2.4
v2.2.3
v2.2.2
v2.2.1
v2.2.0
v2.1.6
v2.2-beta2
v2.1.5
v2.2-beta1
v2.1.4
v2.1.3
v2.1.2
v2.1.1
v2.1.0
v2.0.10
v2.1-beta1
v2.0.9
v2.0.8
v2.0.7
v2.0.6
v2.0.5
v2.0.4
v2.0.3
v2.0.2
v2.0.1
v2.0.0
v2.0-beta3
v1.9.6
v1.9.5
v2.0-beta2
v1.9.4-r1
v1.9.3
v2.0-beta1
v1.9.2
v1.9.1
v1.9.0-r1
v1.8.4
v1.8.3
v1.8.2
v1.8.1
v1.8.0
v1.7.3
v1.7.2-r1
v1.7.1
v1.7.0
v1.6.3
v1.6.2-r1
v1.6.1-r1
1.6.1
v1.6.0
v1.5.2
v1.5.1
v1.5.0
v1.4.2
v1.4.1
v1.4.0
v1.3.2
v1.3.1
v1.3.0
v1.2.2
v1.2.1
v1.2.0
v1.1.0
v1.0.7-r1
v1.0.7
v1.0.6
v1.0.5
v1.0.4
v1.0.3-r1
v1.0.3
1.0.0
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
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
Mirrored from GitHub Pull Request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/netbox#5946
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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?
Originally created by @PieterL75 on GitHub (Jan 14, 2022).
Originally assigned to: @arthanson on GitHub.
NetBox version
v3.1.5
Feature type
Change to existing functionality
Proposed functionality
Device have the option to document inventory items. (cpu, disks, blades, modules, ...)
For virtual machines,this option is not available.
I would like to see the possibility to add inventory items to virtual-machines
Use case
VM can have additional 'hardware' like disks.
The inventory items on a VM will allow us to document how many disks and what size the disks has.
By default we have no CDROM attached to the VM. with the inventory we could add a CDROM to document that exception
Database changes
extend the dcim/inventory-items model to be attached to virtualization/virtual-machines
External dependencies
No response
@jk-onnet commented on GitHub (Jan 17, 2022):
#1887 #4783 and others have similar intend approach, according to NetBox maintainer, this might push NetBox to asset management tools or virtual orchestration tools. But I would like to have this feature to be accepted.
In v3.2 milestone, I think the inventory items in device has a huge change of core fields. As long as NetBox grows, the custom field (reference to object or to network interfaces) and potentially inventory item in virtualization will make this more friendly to users and a better source of truth for automation.
In our use case, we developed a custom script to provision our virtual machine to document the network. We would like to pass and document other possible proposed values of virtual machine. Our alternative approach is using custom field (json) but this is hard for our script users to audit or track the value based on the json field instead of object based field. A similar inventory item model as device to virtual machine can be introduced.
@PieterL75 commented on GitHub (Jan 17, 2022):
I see that the request were closed with the remarks 'NB primary function is to manage network infrastructure, not end hosts.'
I think that NB evolved and is more than that.
In my case, we try do document the physical world of our datacenter. That does not only include the network gear, but also all servers, appliances, etc.
If I have cable coming out of my switch, then I want it to go to a device that exists in Netbox, and not only a 'is connected' checkbox with some remarks on what other CMDB that owns the server.
And because the IPAM is 100% in Netbox, we have almost no other choice then to add the VM's to Netbox also.
I feel that Netbox was not intended to do that (Devices are mainly network focused and adding Servers quickly hits limitations), but step by step it could become a 100% physical world tool
@dkirhlarov commented on GitHub (Feb 8, 2022):
NetBox version 3.1.0
We are using VM's with CEPH store or local store in our own OpenNebula clouds. For now we have to use custom field for separate store types. We would like to use VM types or inventory items for VMs like as Device.
@jeremystretch commented on GitHub (Apr 6, 2022):
I appreciate the use case here, but I'm not sure it makes sense to repurpose the existing inventory item model, which supports fields like
part_idandmanufacturer, as well as component mapping. It might be better to introduce a separate model e.g. VMResource to model VM-specific items.@DanSheps commented on GitHub (Apr 8, 2022):
I think a new model would be appropriate.
I guess the question is what fields do we want to capture? The problem with VM resources is they are sometimes all over the map with what you might actually want to capture.
For example,
I think, if we wanted to get a decent model we might want to revisit the VM model all together and see if we want to do things like modelling vswitches/sans and stuff as well. In the meantime, perhaps a few freeform text fields would be all that is needed but that does make automatic migrations difficult.
@themurman commented on GitHub (May 16, 2022):
My specific use case is passing pcie nics through from the host to a vm running a software firewall/router appliance. If we are documenting the network, I would argue that we have to go inside the hosts to have complete documentation.
@MalfuncEddie commented on GitHub (Jun 17, 2022):
My use case is has 2 parts:
Vmware vm:
I would write a scritp that read out the API. For each disk on the vm create a Virtual disk with size and spec (HDD. SSD ...)
vmware vm with direct attache lun or physical server:
Well this is a bit more complex. I could read out the storage subsystem and gather all the disks and create them in a "virtual disk/lun device" The tricky part would be mapping it to the correct server (hate to do this manual)
There is also the question what "storage" you want?
What do you do with a LUN that is replicated? or thin provisioned or has a snapshot?
I would suggest splitting up storage into a backend layer and a front end layer
backend:
frontend:
The underlying use case is a question I got that mgmt wants to know how much storage/cpu/... a certain department (tenant) is using so a replicated LUN needs to have a checkmark "replicated" so it ha a factor times 2.
@jose-pr commented on GitHub (Aug 9, 2022):
Would like to be able to document passthrough devices, such as hddd, nic, gpu.
@github-actions[bot] commented on GitHub (Oct 8, 2022):
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.
@arjenvri commented on GitHub (Oct 21, 2022):
Could we possibly reduce the scope initially for this to being able to add multiple disks? The current field ‘disk space’ seems less useful as @PieterL75 outlined since many vms have multiple disks
@pycolas commented on GitHub (Dec 6, 2022):
I upvote this idea (possibility to add inventory items to virtual-machines).
I don't see why an inventory item shall be a physical object.
I was thinking of using inventory items to list certificates and licences attached to a device (physical or virtual), but it's not possible for VM.
Maybe it's not the perfect match, but here it would help removing spreadsheets completely.
@jeremystretch commented on GitHub (Jan 24, 2023):
@pycolas the InventoryItem model was constructed specifically to represent physical resources; hence the presence of e.g. the serial number and manufacturer fields. These wouldn't make sense in the context of a virtual resource, so we'd need to use a separate model, much like we do for interfaces belong to VMs vs. devices.
I'm tagging this as
needs milestonewith the understanding that it will entail the introduction of a new model suitable for representing virtual items.@AnythingOverIP commented on GitHub (Mar 7, 2023):
We use Inventory items to track individual Software license keys. Having this for VM would be much appreciated.
@pdenessen commented on GitHub (May 11, 2023):
Hi, I also go the question to add the used licenses to the system. Inventory items would indeed a nice solutions but it lacks, as already mentioned, the use of the VMs. Hope this feature can be added soon.
@stebr1 commented on GitHub (Aug 1, 2023):
I also will appreciate to have the disks details for each VMs
@jeremystretch commented on GitHub (Oct 18, 2023):
In an effort to progress work on this FR, I'm going to narrow its scope as suggested above to virtual disks. We can introduce a new
VirtualDiskmodel withnameandsizefields, instances of which must be assigned to a specific virtual machine. We'll retain the existingdiskfield on VirtualMachine for now for backward compatibility, however I'd expect it to be removed at some point in the future (possibly in v4.0).I'd be open to introducing a similar change for modeling discrete virtual CPUs as well, however there doesn't seem to be any demand for it, and it doesn't seem to me like it would bring much value.
@DanSheps commented on GitHub (Oct 18, 2023):
One other thing I am seeing demand for would be virtual switches/etc (including their relation to the specific host or cluster's uplinks).
We may want to look at that after this FR is completed (as a new FR of course).