Extend Device model with front_image and rear_image fields

[loubladi]

NetBox version

v4.2.6

Feature type

Data model extension

Proposed functionality

Extend the Device model with front_image and rear_image fields, similar to the DeviceType model. These fields should allow overriding the default DeviceType images for an individual Device.

Use case

The primary use case is for modular chassis-based devices. In scenarios where a single DeviceType represents a chassis (e.g., a DWDM chassis), the installed Modules may change over time. Overriding the DeviceType images at the Device level would allow accurate visual representation of the device in rack views, reflecting the current state.

Database changes

• Add front_image and rear_image fields to the Device model.
• Ensure these fields override the DeviceType images when set.

External dependencies

N/A

[jeremystretch]

While I get the proposed use case, it seems like it would require a ton of work for very little return. Are you intending to manually update & re-upload each image for each device every time a module is installed or removed?

[loubladi]

That was the idea. The intention is to manually update and upload the front and rear images for specific devices when their module layout changes. The module setup doesn’t change frequently, so I believe it’s manageable.

Here’s one particular use case we currently have:

We use devices like the Cisco ASR-9903, which have several modules. The RSP (Route Processor), power supplies, and fan trays are always present, but the line card slot can either be empty or populated with a module such as the A9903-20HG-PEC.

It would be helpful to have the option to distinguish these two hardware states visually by allowing a front image override—one image with the line card and one without. These images would be prepared in advance, and in the rare event that the line card is removed, we would simply reupload the correct image for that specific device.

The behavior would be that the DeviceType defines the default image (e.g., without the line card), while only specific Device instances would have an image override, which would then be used in the rack view.

With the growing adoption of modules and module bays in NetBox, this could offer users a simple way to visually differentiate devices based on their installed modules. For example, many patch panels in the Device Type Library now consist of modular frames where modules with specific front and rear ports are inserted. Also from

There may be better ways in the future to visualize differences in installed modules, but I thought this method would be the simplest to implement compared to more complex automatic options. Ideally, we’d love to have automatic image rendering based on installed modules—a feature found in many DWDM device management systems—but I understand that would be extremely difficult to implement in NetBox. Using image overrides would shift that complexity to the user while still enabling better visual accuracy.

[jeremystretch]

I suspect you'd find very quickly that this approach doesn't work well in the long term, as updating the images for individual devices to reflect their current state is extremely tedious and error-prone. And those images are typically displayed at a size where readily discerning such detail is impractical (if not impossible).

What is gained by attempting to reflect the installed modules in the device's image versus simply viewing the device's page in NetBox?

[loubladi]

The main benefit of this feature is the ability to visually see the module configuration of a device. I would expect that the front and rear images would also render on the device detail page (as mentioned in Slack: link).

I agree that this request leans more toward visual enhancement—some might even call it “eye candy”—but I believe it could still be quite valuable for onboarding and documentation, especially for new employees unfamiliar with a particular hardware platform.

Regarding concerns about manual updates being tedious or error-prone: I don’t think that argument should be a blocker. That line of reasoning could also apply to other parts of NetBox where manual user input are key aspects.

If this is considered not worth the development effort within core NetBox, we will explore using the netbox-device-view plugin as an alternative. However, native support would provide a much more streamlined and integrated experience.

[Ximalas]

In my case, I use Visio to create new images of modular equipment. It's not difficult at all. While my gear doesn't change much, it's nice having an image of an empty chassis in the DeviceType and an up to date image for each Device instance.