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

Virtual Machine - Boot Order #11305

New Issue
Closed
opened 2025-12-29 21:43:20 +01:00 by adam · 5 comments
adam commented 2025-12-29 21:43:20 +01:00
Owner
Copy Link

Originally created by @vincemulhollon on GitHub (Jun 22, 2025).

NetBox version

4.0.11

Feature type

Data model extension

Proposed functionality

Add something very similar to how prefixes are handled, but for VM boot order.
This is different from existing feature request #18658 on the topic of "start at boot" this setting the order.

Use case

Some virtualization systems like Proxmox have a VM boot (and shutdown) ordering system. In Proxmox Web UI go to a VM, select "Options" select "Start/Shutdown Order" click edit and you get a page of options including numeric "Start/Shutdown Order". As I understand it the cluster will start VMs in order (with optional delay) from 1 to 99, then blank/default as last., and shutdown order is reverse. This is explained in Proxmox admin manual.

If netbox handles it like prefixes, a user could define "order 10" for the name "DHCP servers" and "order 20" for the name "Samba DCs" and when later wondering what number to assign to resolving DNS servers, a list of boot orders could be examined to determine a really great time to start the resolving DNS servers might be "boot order 15" or at least any number smaller than 20 (because Samba needs a resolving DNS it can forward to) and larger than 10 (although technically if your DHCP server has FQDNs in its config maybe it needs to be smaller than 10). Anyway then individual VMs could have a "boot order" assigned to them.

Its a long story but I have a script that could be extended to compare the numeric Netbox boot order column, if it existed, with the proxmox boot order to output a discrepancy list etc. Much like you can currently compare/audit memory allocations in Netbox with the current config in Proxmox.

Database changes

In virtualization, add a "boot order" similar to the IPAM/Prefixes system.
In each virtual machine, add a "boot order" pointing to one of the boot orders configured above.

External dependencies

No response

Originally created by @vincemulhollon on GitHub (Jun 22, 2025). ### NetBox version 4.0.11 ### Feature type Data model extension ### Proposed functionality Add something very similar to how prefixes are handled, but for VM boot order. This is different from existing feature request #18658 on the topic of "start at boot" this setting the order. ### Use case Some virtualization systems like Proxmox have a VM boot (and shutdown) ordering system. In Proxmox Web UI go to a VM, select "Options" select "Start/Shutdown Order" click edit and you get a page of options including numeric "Start/Shutdown Order". As I understand it the cluster will start VMs in order (with optional delay) from 1 to 99, then blank/default as last., and shutdown order is reverse. This is explained in Proxmox admin manual. If netbox handles it like prefixes, a user could define "order 10" for the name "DHCP servers" and "order 20" for the name "Samba DCs" and when later wondering what number to assign to resolving DNS servers, a list of boot orders could be examined to determine a really great time to start the resolving DNS servers might be "boot order 15" or at least any number smaller than 20 (because Samba needs a resolving DNS it can forward to) and larger than 10 (although technically if your DHCP server has FQDNs in its config maybe it needs to be smaller than 10). Anyway then individual VMs could have a "boot order" assigned to them. Its a long story but I have a script that could be extended to compare the numeric Netbox boot order column, if it existed, with the proxmox boot order to output a discrepancy list etc. Much like you can currently compare/audit memory allocations in Netbox with the current config in Proxmox. ### Database changes In virtualization, add a "boot order" similar to the IPAM/Prefixes system. In each virtual machine, add a "boot order" pointing to one of the boot orders configured above. ### External dependencies _No response_
adam added the type: featurepending closurestatus: revisions needed labels 2025-12-29 21:43:20 +01:00
adam closed this issue 2025-12-29 21:43:21 +01:00
adam commented 2025-12-29 21:43:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 26, 2025):

@vincemulhollon could you please expand on the above to describe the specific data model change(s) and workflow you envision? How specifically are you proposing this change be implemented?

In virtualization, add a "boot order" similar to the IPAM/Prefixes system.

This is especially confusing. Are you referring to the hierarchical arrangement of prefixes?

@jeremystretch commented on GitHub (Jun 26, 2025): @vincemulhollon could you please expand on the above to describe the specific data model change(s) and workflow you envision? How _specifically_ are you proposing this change be implemented? > In virtualization, add a "boot order" similar to the IPAM/Prefixes system. This is especially confusing. Are you referring to the hierarchical arrangement of prefixes?
adam commented 2025-12-29 21:43:22 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Jul 4, 2025):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (Jul 4, 2025): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.
adam commented 2025-12-29 21:43:22 +01:00
Author
Owner
Copy Link

@vincemulhollon commented on GitHub (Jul 4, 2025):

OK I can provide something like a data model change and specific workflow for two different possible designs.

The simpler design workflow:

Click on "Virtualization", "Virtual Machines", select any VM, theres a field named "boot order" containing an alphanumeric.

Naming convention: On Proxmox, its named "Start/Shutdown Order". In VMware ESX its named "Start Order" but I don't recall if thats the API name or the GUI name. Openstack does not seem to have a non-scripted way to start VMs in the proper order. It seems naming it "boot order" would be reasonably vendor neutral. In Proxmox its a two digit integer, but I'd suggest making it a simple alphanumeric string to be maximally compatible with all vendors.

A more complex design workflow:

Click on "Virtualization", click on "Boot Order" in the "Virtual Machines" subheader, there's an ordered list of boot order numbers and names. My cluster's "boot order" hypothetical list would look, in very small part, like:

15 DNS Resolver Cluster

50 File Servers

60 Enduser hosts

Each boot order entry in the list has an alphanumeric string name "DNS Resolver Cluster", a alphanumeric string for automation purposes "15" I can and do have Ansible read some values out of Netbox to directly manipulate the Proxmox API, and a sort order "15" (which on proxmox is boring, VMs are booted in strict numeric integer order, but other virtualization systems may vary)

Then in "Virtualization", "Virtual Machines", select any VM, there's a field named "boot order" containing a drop down list of the "Boot Orders" listed above. All my DNS resolver VMs would have the dropdown selection "15 DNS Resolver Cluster" and presumably none of my enduser hosts would have that dropdown value.

The dropdown would reduce or eliminate an entire class of hypothetical data entry errors, it would be much less likely to assign a boot order of "55" or "5" to a DNS resolver VM. Or for planning purposes if one were to create a new class of boot order priorities for infrastructure servers that can't start until after the fileservers it would be "easy" to see a number like 55 would be an obvious location.

Anything would be better than nothing, although the latter would be better than the former.

@vincemulhollon commented on GitHub (Jul 4, 2025): OK I can provide something like a data model change and specific workflow for two different possible designs. The simpler design workflow: Click on "Virtualization", "Virtual Machines", select any VM, theres a field named "boot order" containing an alphanumeric. Naming convention: On Proxmox, its named "Start/Shutdown Order". In VMware ESX its named "Start Order" but I don't recall if thats the API name or the GUI name. Openstack does not seem to have a non-scripted way to start VMs in the proper order. It seems naming it "boot order" would be reasonably vendor neutral. In Proxmox its a two digit integer, but I'd suggest making it a simple alphanumeric string to be maximally compatible with all vendors. A more complex design workflow: Click on "Virtualization", click on "Boot Order" in the "Virtual Machines" subheader, there's an ordered list of boot order numbers and names. My cluster's "boot order" hypothetical list would look, in very small part, like: 15 DNS Resolver Cluster 50 File Servers 60 Enduser hosts Each boot order entry in the list has an alphanumeric string name "DNS Resolver Cluster", a alphanumeric string for automation purposes "15" I can and do have Ansible read some values out of Netbox to directly manipulate the Proxmox API, and a sort order "15" (which on proxmox is boring, VMs are booted in strict numeric integer order, but other virtualization systems may vary) Then in "Virtualization", "Virtual Machines", select any VM, there's a field named "boot order" containing a drop down list of the "Boot Orders" listed above. All my DNS resolver VMs would have the dropdown selection "15 DNS Resolver Cluster" and presumably none of my enduser hosts would have that dropdown value. The dropdown would reduce or eliminate an entire class of hypothetical data entry errors, it would be much less likely to assign a boot order of "55" or "5" to a DNS resolver VM. Or for planning purposes if one were to create a new class of boot order priorities for infrastructure servers that can't start until after the fileservers it would be "easy" to see a number like 55 would be an obvious location. Anything would be better than nothing, although the latter would be better than the former.
adam commented 2025-12-29 21:43:22 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 10, 2025):

It seems like you might have a fairly niche use case. Is there some reason a custom field on the VirtualMachine model would not work for this?

@jeremystretch commented on GitHub (Jul 10, 2025): It seems like you might have a fairly niche use case. Is there some reason a custom field on the VirtualMachine model would not work for this?
adam commented 2025-12-29 21:43:23 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 6, 2025):

This issue is being closed as no further information has been provided. If you would like to revisit this topic, please first modify your original post to include all the requested detail, and then ask that the issue be reopened.

@jeremystretch commented on GitHub (Aug 6, 2025): This issue is being closed as no further information has been provided. If you would like to revisit this topic, please first modify your original post to include all the requested detail, and then ask that the issue be reopened.
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 pending closure status: revisions needed type: feature
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#11305
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?