Increase the Maximum Length of VirtualMachine Names

[cnravin]

Background

We are planning to use NetBox to maintain and manage our virtual machine inventory.

While importing our existing virtual machines, we found that NetBox currently limits the Virtual Machine name field to 64 characters.

The Problem

This is a problem for our environment because our VM naming convention encodes several pieces of information in a single name, including:

• Environment — e.g. pro / test
• IPv4 / IPv6 address — the VM's assigned IP
• Username — the owner / responsible user
• Department name — the owning department
• Date / time — creation timestamp
• Server description — a human-readable node description

With this convention, 64 characters are generally not enough to represent the full VM name.

Our Naming Convention

<environment>_<ipv4|ipv6>_<username>_<deptName>_<YYYY-MM-DD>_<server-description>

Examples

pro_100.100.100.100_usernameAAA_deptName_2026-08-25_xxx-node-01
test_100.100.200.200_usernameBBB_deptName_2026-08-25_xxx-test-node-01
pro_2001:aaaa:bbbb:cccc::1_usernameCCC_deptName_2026-08-25_public-printer-server

Request

Since we would like to keep the original VM names in NetBox rather than truncate them during synchronization, I would like to ask whether the NetBox developers would consider increasing the maximum length of the Virtual Machine name field in a future release.

For example, would increasing the limit to 128 characters be considered?

Thanks!

[tigran-sargsyan-w]

At the moment this does not appear to be configurable through a NetBox setting.

VirtualMachine.name is currently defined directly in the Django model with:

name = models.CharField(
    verbose_name=_('name'),
    max_length=64,
    db_collation="natural_sort"
)

so changing only the PostgreSQL column would not be a complete/supported solution — the application model and validation would still expect a maximum of 64 characters.

If preserving the exact external VM name is required today, I would avoid maintaining a local patch to the NetBox model.

A safer approach would be:

• keep a shorter canonical value in the normal name field;
• create a custom field such as source_name or original_name containing the complete external VM name;
• move metadata such as environment, owner, department, date, etc. into native NetBox attributes/custom fields where possible instead of encoding all of it into a single hostname.

That has another advantage: the metadata becomes independently searchable/filterable through the UI and API instead of needing to parse the VM name.

If the requirement really is specifically:

VirtualMachine.name > 64 characters

then I think the clean solution would be an upstream NetBox schema/model change (with the corresponding migration and validation changes), rather than modifying the database manually.

So currently: there isn't a configuration option to change it to 128; a custom field is probably the least invasive workaround unless the field length is changed upstream.

[cnravin]

Thanks for the clarification.

We have also tested this locally and confirmed that the 64-character limit is enforced by the NetBox model and validation, so I agree with your explanation that changing only the PostgreSQL column would not be a complete solution.

We are already working on separating and migrating the information encoded in our existing VM names into appropriate NetBox fields.

Our original intention was simply to keep the VM names in NetBox as consistent as possible with the names in our existing virtualization platforms, so that names in both systems could be easily correlated.

However, given the 64-character limit and the way NetBox models this information, we have decided not to work around the limit by modifying the NetBox model.

Instead, we will keep a suitable canonical name in the name field and use custom fields to retain the complete original VM name and other relevant metadata.

[jeremystretch]

NetBox enforces a limit of 64 characters for device and VM names in accordance with both the maximum length of a Linux hostname and with RFC 1035 section 2.3.4, which enforces a maximum of 63 characters per DNS label.

<environment>_<ipv4|ipv6>_<username>_<deptName>_<YYYY-MM-DD>_<server-description>

I wouldn't presume to tell you how to run your network, but I would strongly suggest reconsidering this approach. You've encoded far too much variable and extraneous data in the name of an individual VM. Consider:

• What if its IP address changes? Or it has more than one IP assigned?
• Do you want to advertise an authentication credential in the name?
• Is there any real value in embedding the installation date?
• What if the description is no longer accurate e.g. due to a software upgrade?

The great thing about documenting VMs in NetBox is that you can easily document each of these attributes as independently mutable fields on the primary object, requiring only a brief unique name to identify the VM itself. IP addresses don't need to manually recorded, for instance: They can be referred from the IP addresses actually assigned to the VM's interface(s). And if you want to retain a reference to the original name, you have the option of creating a custom field to record it.

[cnravin]

Thanks for the detailed explanation. That makes sense, and I agree that NetBox's data model provides a more flexible way to represent these attributes independently.

Just to clarify a few points about our naming convention:

• username in our naming convention refers to the person responsible for or maintaining the VM. It is not an authentication username or credential.
• The original intention of this naming convention was quite simple: visibility and convenience. We wanted important information about a VM to be immediately visible from its name, without having to look up another system or field. It also helps distinguish similarly named servers at a glance because the environment, maintainer, department, and other identifying information are included in the name.
• We are not necessarily insisting that NetBox support the complete name within the 64-character limit.In fact, We have already considered retaining the full original VM name in a description or custom field when necessary.

In our current NetBox design, information such as IP addresses, disks, CPUs, and memory is already being represented using the corresponding NetBox objects and native VM attributes, with the appropriate relationships to the VM.

Thanks again for the explanation. It helps clarify how we should model our existing VM information in NetBox rather than trying to reproduce our legacy naming convention entirely in the name field.