Convert GiB to MiB

A gibibyte is 1,073,741,824 bytes — about 7% more than a gigabyte. Windows measures in gibibytes and labels them GB, which is the whole of the missing-space mystery.

A mebibyte is 1,024 kibibytes, or 1,048,576 bytes. Linux tools and memory sizes generally mean this even when they print "MB".

Going this way is a multiplication, and by a whole number: one gibibyte is 1,024 mebibytes, exactly, and 1,024 is the definition rather than a measurement that came close.

That makes it one of the few conversions worth doing in your head, and it makes the answer checkable: divide back and you must land on the number you started with, exactly, with no remainder to explain away.

One GiB is 1,024 of the unit below it; one GB is 1,000. On this page that is the difference between 1024 MiB and 953.6743 MiB — 7.4 % — and the gap grows at every step up the scale, which is why it is a rounding error on a photograph and a visible chunk of a hard disk.

This is the whole of the missing-storage mystery, and on this page it is worth 7.4 %. A drive sold in GB holds exactly what the label says; Windows divides by 1,024 instead of 1,000, keeps the decimal name, and reports 953.6743 MiB where the box said 1024. macOS has counted these in the decimal units since 10.6, which is why the same drive can look two sizes on two machines — nothing is missing and nobody is rounding, the same bytes have two names.

QEMU's -m is a bare mebibyte count. virt-install takes --memory in mebibytes. Most cloud and hypervisor APIs written before the IEC prefixes had names use a field called memoryMB, and the value is binary regardless of the label. Meanwhile every instance catalogue, capacity plan and procurement document is written in gibibytes, so the conversion happens at exactly the point where a size stops being a decision and becomes a configuration.

libvirt is the exception worth knowing about, because its domain XML defaults the memory element to kibibytes rather than mebibytes. An 8 GiB guest is <memory unit='KiB'>8388608</memory>, and a value that looks like it must be a typo is usually the other unit. The element accepts an explicit unit attribute, and writing unit='GiB' in a template that humans edit removes the question permanently.

A guest assigned 8,192 MiB costs the host that much for the guest's own pages plus a set of structures that exist only because the machine is virtual. Nested page tables map guest-physical to host-physical and grow with the guest's address space. The device model runs as a host process with its own heap. Emulated video memory is a real allocation. The hypervisor keeps per-page metadata for everything it hands out.

The total is usually a small percentage rather than a fixed number, which is why a host that comfortably ran eight 8 GiB guests may not run four 16 GiB ones despite the arithmetic being identical. Sizing a host by summing the assigned mebibytes and comparing to installed memory leaves nothing for the hypervisor itself, and the failure at the far end is the host swapping — which is far worse for a guest than being given less memory in the first place.

Guest memory is generally allocated on first touch, so a freshly booted guest with 16,384 MiB assigned may be consuming a tenth of that on the host. The balloon driver lets the hypervisor reclaim more: it inflates inside the guest, the guest kernel frees pages to satisfy it, and the hypervisor takes them back. Deflating returns them. The assigned figure becomes a ceiling rather than a reservation.

The consequence for capacity arithmetic is that there are three numbers per guest and only one of them is in the configuration file. Assigned is what you typed; the balloon target is what the hypervisor currently permits; resident is what the host has actually committed. A dashboard reporting any one of them in gibibytes against a plan built on another will be wrong by a factor that changes through the day.

Backing a guest with huge pages removes a level of page-table walk and is worth a measurable amount on memory-heavy workloads, but it changes the arithmetic. Pages become 2 MiB rather than 4 KiB, so the assignment must be a multiple of 2 MiB; the pool has to be reserved on the host up front and is not available for anything else; and lazy allocation stops, because a huge-page-backed guest takes its full assignment immediately.

That turns 8,192 MiB from a ceiling into a commitment of 4,096 huge pages, and it means overcommit is off for that guest. It also means the host's pool has to be sized in the same units: reserving 65,536 huge pages is 128 GiB, and a host that reserves more than its guests use has taken that memory away from everything else. Where a guest uses 1 GiB huge pages instead, the assignment must be a multiple of 1,024 MiB and the granularity of any mistake is a whole gibibyte.

On a host with more than one memory node, a guest larger than a node has to be split, and the split is far better made deliberately than left to the scheduler. A guest of 12,288 MiB across two nodes is 6,144 each, which is tidy; the same guest at 12,000 MiB is 6,000 each, which is fine arithmetically and awkward against huge pages and against any per-node reservation.

The failure when it is left implicit is remote memory access: a virtual CPU pinned to one node reading pages that live on the other pays a latency penalty on every access, and the effect is a workload that is slower than the same guest on a smaller host. virsh numatune and the guest's own NUMA topology both matter, and both are configured in mebibytes per node, so the gibibyte figure has to divide cleanly before any of it can be expressed.

Summing assigned mebibytes across guests and dividing by the host's memory gives an overcommit ratio, and ratios up to about 1.5 are routine on workloads with idle guests. The reason it works is that assigned is a ceiling and most guests never approach it. The reason it fails is that the guests that do approach it tend to do so at the same time, because they are usually responding to the same event.

The number worth tracking alongside the ratio is the host's free memory in mebibytes at peak rather than at average, and the thing to avoid is the host reaching for swap. A guest whose pages are swapped out by the host experiences it as memory that has become a thousand times slower with no indication why, and the guest's own memory management — which believes those pages are RAM — will make exactly the wrong decisions about them.

Memory hotplug does not add arbitrary amounts. The guest exposes a block size — commonly 128 MiB on x86-64 — and memory arrives in whole blocks, so a request for 1,000 MiB becomes eight blocks and 1,024 MiB. Removal is harder than addition, because the guest kernel has to vacate the block first and may not be able to if anything unmovable landed in it. A guest that grew from 4 GiB to 12 may not shrink back.

The practical approach is to size for the working set with the headroom the workload deserves and to treat downward resizing as a reboot rather than an online operation. Where a guest must genuinely vary, the balloon is the mechanism that handles it well and hotplug is the one that handles growth beyond the original ceiling — and the ceiling itself, the maxMemory figure, is another mebibyte field that has to be set before the guest starts.