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

VM Resources Memory unit changed after 4.0 update #9920

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

Originally created by @yaiqsa on GitHub (Jul 1, 2024).

Deployment Type

Self-hosted

NetBox Version

v4.0.6

Python Version

3.10

Steps to Reproduce

  1. Create a VM in Netbox v3.7.6
  2. Set 'Memory' for this vm to 2048 MB
  3. This now shows as 2 GB in the web UI
  4. Upgrade to Netbox v4.0.6
  5. The web UI now shows 2.05 GB

Expected Behavior

I would expect that the interpretation of the Memory field, which used to be 'MiB', is still interpreted the same way in Netbox 4.0+

I would expect this because these 'binary' units like MiB are more common in the industry than 'metric' units like MB. I also couldn't find this change in the changelogs. Excuse me I missed something there.

Observed Behavior

The field is now interpreted differently than before the update.

Originally created by @yaiqsa on GitHub (Jul 1, 2024). ### Deployment Type Self-hosted ### NetBox Version v4.0.6 ### Python Version 3.10 ### Steps to Reproduce 1. Create a VM in Netbox v3.7.6 2. Set 'Memory' for this vm to `2048` MB 3. This now shows as `2 GB` in the web UI 4. Upgrade to Netbox v4.0.6 5. The web UI now shows `2.05 GB` ### Expected Behavior I would expect that the interpretation of the Memory field, which used to be 'MiB', is still interpreted the same way in Netbox 4.0+ I would expect this because these 'binary' units like MiB are more common in the industry than 'metric' units like MB. I also couldn't find this change in the changelogs. Excuse me I missed something there. ### Observed Behavior The field is now interpreted differently than before the update.
adam added the type: bug label 2025-12-29 21:24:24 +01:00
adam closed this issue 2025-12-29 21:24:24 +01:00
adam commented 2025-12-29 21:24:24 +01:00
Author
Owner
Copy Link

@yaiqsa commented on GitHub (Jul 1, 2024):

If this is the way forward, I'll have to update all my VMs & change the scripts that use the field. But I would like to be sure this is an aware & lasting change before I make those changes on my side.

@yaiqsa commented on GitHub (Jul 1, 2024): If this is the way forward, I'll have to update all my VMs & change the scripts that use the field. But I would like to be sure this is an aware & lasting change before I make those changes on my side.
adam commented 2025-12-29 21:24:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 4, 2024):

Prior to NetBox v4.0.0, gigabytes were incorrectly calculated as 1024 MB rather than 1000 MB when reporting values in the UI. (This bug was merely cosmetic in nature.) Going forward all byte units are based on powers of ten.

@jeremystretch commented on GitHub (Jul 4, 2024): Prior to NetBox v4.0.0, gigabytes were incorrectly calculated as 1024 MB rather than 1000 MB when reporting values in the UI. (This bug was merely cosmetic in nature.) Going forward all byte units are based on powers of ten.
adam commented 2025-12-29 21:24:26 +01:00
Author
Owner
Copy Link

@yaiqsa commented on GitHub (Jul 4, 2024):

Thank you for your response @jeremystretch

However, I think most people wouldn't expect this behaviour: RAM DIMMs always have a capacity in GiB, not GB. For disks this is not always the case, but then most OSes report the actual size in GiB/TiB, not GB/TB.

IBM seems to be with me in this regard

Binary units of measurement express the size of data more accurately. When you compare the size of 100 KB to 100 KiB, the difference is relatively small, 2.35%. However, this difference grows as the size of the data values increases. When you compare the size of 100 TB to 100 TiB, the difference is 9.06%.

Would it be possible to make this a (system-wide) configurable option?

@yaiqsa commented on GitHub (Jul 4, 2024): Thank you for your response @jeremystretch However, I think most people wouldn't expect this behaviour: RAM DIMMs always have a capacity in GiB, not GB. For disks this is not always the case, but then most OSes report the actual size in GiB/TiB, not GB/TB. [IBM seems to be with me in this regard](https://www.ibm.com/docs/en/storage-insights?topic=overview-units-measurement-storage-data) > Binary units of measurement express the size of data more accurately. When you compare the size of 100 KB to 100 KiB, the difference is relatively small, 2.35%. However, this difference grows as the size of the data values increases. When you compare the size of 100 TB to 100 TiB, the difference is 9.06%. Would it be possible to make this a (system-wide) configurable option?
adam commented 2025-12-29 21:24:26 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jul 4, 2024):

Wikipedia disagrees. Unfortunately there may be no clearly correct answer, but this is the approach we chose. And no, it cannot be made configurable.

@jeremystretch commented on GitHub (Jul 4, 2024): [Wikipedia disagrees.](https://en.wikipedia.org/wiki/Gigabyte#Definition) Unfortunately there may be no clearly correct answer, but this is the approach we chose. And no, it cannot be made configurable.
adam commented 2025-12-29 21:24:27 +01:00
Author
Owner
Copy Link

@PhilKet commented on GitHub (Aug 20, 2024):

Hi @jeremystretch ,
I am sorry that I have to comment on an already closed issue, but I have to say this doesn't seem resolved in my opinion. I am actually pretty surprised that not more people complain about this. Right now I would have to edit all of my devices and virtual machines in Netbox, so it doesn't show strange Memroy sizes like 4,1GB. If I did that though, the size in MB would be wrong again.
Even the Wikipedia page you mention clearly states that GB and GiB are both valid but distinct standards! And that memory sizes are typically measured in GiB as it is more accurate.

Because of their physical design, the capacity of modern computer random-access memory devices, such as DIMM modules, is always a multiple of a power of 1024. It is thus convenient to use prefixes denoting powers of 1024, known as binary prefixes, in describing them. For example, a memory capacity of 1073741824bytes (10243 B) is conveniently expressed as 1 GiB rather than as 1.074 GB. The former specification is, however, often quoted as "1 GB" when applied to random-access memory.

Also, I might have overlooked it, but I also didn't see any information about this change in any release notes.

I think at least for memory sizes Gib/MiB is the correct way to go and I don't quite understand why this was changed.

@PhilKet commented on GitHub (Aug 20, 2024): Hi @jeremystretch , I am sorry that I have to comment on an already closed issue, but I have to say this doesn't seem resolved in my opinion. I am actually pretty surprised that not more people complain about this. Right now I would have to edit all of my devices and virtual machines in Netbox, so it doesn't show strange Memroy sizes like 4,1GB. If I did that though, the size in MB would be wrong again. Even the Wikipedia page you mention clearly states that GB and GiB are both valid but distinct standards! And that memory sizes are typically measured in GiB as it is more accurate. > Because of their physical design, the capacity of modern computer random-access memory devices, such as DIMM modules, is always a multiple of a power of 1024. It is thus convenient to use prefixes denoting powers of 1024, known as binary prefixes, in describing them. For example, a memory capacity of 1073741824bytes (10243 B) is conveniently expressed as 1 GiB rather than as 1.074 GB. The former specification is, however, often quoted as "1 GB" when applied to random-access memory. Also, I might have overlooked it, but I also didn't see any information about this change in any release notes. I think at least for memory sizes Gib/MiB is the correct way to go and I don't quite understand why this was changed.
adam commented 2025-12-29 21:24:27 +01:00
Author
Owner
Copy Link

@stavr666 commented on GitHub (Aug 20, 2024):

I am actually pretty surprised that not more people complain about this.

Most big clients change and use values by scripts, api and graphql. So, most users that have will to complain against change not affected my this.

Also, reopening same issues, closed by developers before, against rules, afaik.

My team affected, so I'd like if this change will be reverted.

@stavr666 commented on GitHub (Aug 20, 2024): > I am actually pretty surprised that not more people complain about this. Most big clients change and use values by scripts, api and graphql. So, most users that have will to complain against change not affected my this. Also, reopening same issues, closed by developers before, against rules, afaik. My team affected, so I'd like if this change will be reverted.
adam commented 2025-12-29 21:24:27 +01:00
Author
Owner
Copy Link

@dritier commented on GitHub (Sep 24, 2024):

I have the same "problem". As already outlined there is a wikipedia article about, but even there it assumes base 2 for memory for Windows at least, but I think it's common in all operating systems

@dritier commented on GitHub (Sep 24, 2024): I have the same "problem". As already outlined there is a wikipedia article about, but even there it assumes base 2 for memory for Windows at least, but I think it's common in all operating systems
adam commented 2025-12-29 21:24:27 +01:00
Author
Owner
Copy Link

@PhilKet commented on GitHub (Sep 24, 2024):

@jeremystretch
So is there any plan to do something about this or will this be ignored because the issue is already closed?

@PhilKet commented on GitHub (Sep 24, 2024): @jeremystretch So is there any plan to do something about this or will this be ignored because the issue is already closed?
adam commented 2025-12-29 21:24:28 +01:00
Author
Owner
Copy Link

@yaiqsa commented on GitHub (Sep 24, 2024):

I have the same "problem". As already outlined there is a wikipedia article about, but even there it assumes base 2 for memory for Windows at least, but I think it's common in all operating systems

It depends on how you read the article.. What I think the wiki page is saying is: The word gigabyte should mean 1000^3 B, not 1024^3 B. (For the latter, instead use gibibyte). With which I think we can all agree.

It's not so clear on which unit you should actually use, just about what the definition of the word gigabyte should be.

@yaiqsa commented on GitHub (Sep 24, 2024): > I have the same "problem". As already outlined there is a wikipedia article about, but even there it assumes base 2 for memory for Windows at least, but I think it's common in all operating systems It depends on how you read the article.. What I think the wiki page is saying is: The word `gigabyte` should mean 1000^3 B, not 1024^3 B. (For the latter, instead use `gibibyte`). With which I think we can all agree. It's not so clear on which unit you should actually use, just about what the definition of the word gigabyte should be.
adam commented 2025-12-29 21:24:28 +01:00
Author
Owner
Copy Link

@PhilKet commented on GitHub (Sep 24, 2024):

Well, it does clearly state that

random-access memory devices, such as DIMM modules, is always a multiple of a power of 1024

And that's just a fact of how systems work. I honestly don't really care about if you end up calling it GB or GiB. The important part is if you use a power of 1024 or 1000. That completely changes the values

@PhilKet commented on GitHub (Sep 24, 2024): Well, it does clearly state that > random-access memory devices, such as DIMM modules, is always a multiple of a power of 1024 And that's just a fact of how systems work. I honestly don't really care about if you end up calling it GB or GiB. The important part is if you use a power of 1024 or 1000. That completely changes the values
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 type: bug
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#9920
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?