Instance disk size is used for accounting but not exposed to the guest

[tabdon]

Hi! I’m trying to understand the intended semantics of Hyper.Vm.Instance.Spec.disk.

I created a :deci VM, whose instance spec declares 16 GiB of disk, but the guest received a 1.9 GiB /dev/vda:

  $ df -h /
  Filesystem  Size  Used  Avail  Use%
  /dev/root   1.9G  570M  1.2G   32%

  $ df -i /
  Filesystem  Inodes  IUsed  IFree  IUse%
  /dev/root    15872  14210   1662    90%

I was trying to simply install a specific version of Python and this disk issue caused the install to fail with ENOSPC due to inode exhaustion despite 1.2 GiB of free space.

From the current implementation:

• :deci declares disk: Information.gib(16).
• OCI loading creates a content-sized ext4 filesystem and explicitly sets its inode count.
• Mutable-volume creation reads the immutable origin’s sector count and creates the dm-thin device with that same size.
• The instance disk value therefore appears to affect scheduler accounting, but not the guest-visible block device or filesystem.

Is this behavior intentional? If so:

1. What is Spec.disk intended to represent?
2. Why does the mutable volume inherit the OCI image size rather than the selected instance size?
3. Is growing the thin device and ext4 filesystem to Spec.disk planned, including forked and derived images?

Thanks!

p.s. I'm learning on the fly here. I don't have experience working with VM systems like this, and I'm working to wrap my head around how this is supposed to work.

[markovejnovic]

Hey, thanks for opening the issue. You're correct, the OCI image controls the disk size, while the Spec.disk is used for accounting. The OCI image controls the size. You're right, that's an oversight on my part. I never ran into this workload, coincidentally. Totally my bad, will fix this Saturday.