How does the root storage works?

Hello, can someone explain to me how does the root storage works in simple terms?

When I deploy a VM, the dialog allows me to select how many root storage do I want:
Screenshot 2022-09-27 at 7.03.48 PM

But when I log in to the machine the it always (regardless of what size did I choose on the deployment stage) says to me that I have only 2MB:

root@VMb40508dc:~# lsblk
vda  253:0    0   2M  1 disk 

Can someone explain to me who I do not see the space I’ve allocated for my VM, how does it affect my VM, can I access it somehow, etc, how does it affect such apps as apt-get that install use root storage by default.

Hi Nickolay,

Great question here. It looks like you deployed a micro VM (the current default in the mainnet playground). Micro VMs get their root filesystem added in such a way that it doesn’t show up as a block device, and thus doesn’t appear in the lsblk output. What you’re seeing there is the configuration disk which is mounted temporarily when the VM starts up to inject your SSH key.

Instead, try df to see file systems and their usage, with the -h flag for “human readable” quantity labels. Here’s an example from one of my micro VMs:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
dev             229M     0  229M   0% /dev
run             235M  152K  235M   1% /run
tmpfs           235M     0  235M   0% /dev/shm
/dev/root       477G  284M  476G   1% /

Now, I only allocated 500mb for the root file system, but it shows an available space of 476gb. The reason for this is that we’re actually seeing the full size of the underlying drive in the 3Node, rather than our disk quota for this particular VM. It’s just a limitation of micro VMs for now. I have an open issue to show the quota size instead, but devs aren’t prioritizing it at this time. Anyway, I can compare the used figure from df to the amount I specified at deployment and know that I have about 215mb of free space.

When it comes to full VMs, this is not an issue, since they use an attached virtual disk for the root file system which is seen properly both by lsblk and df. Full VMs also come with features like systemd and a full kernel, which make them more compatible with workflows intended for a VPS or bare metal Linux installation.

Micro VMs can still do a lot, but if you want test a full VM, they are available in the testnet playground or can be deployed through the mainnet playground with a few extra steps.


What are these steps.?

Use a full VM flist as a custom image and attach a disk.

1 Like

Cool, thank you! @scott

I’ve searched in the hub and cannot find full VM image except something from you.
Did you mean this image?

They are under tf-official vms

Ok, for others -
Ive used this flist:
It worked well:

root@VM6cdc8488:~# lsblk
loop0     7:0    0 61.9M  1 loop /snap/core20/1376
loop1     7:1    0 43.6M  1 loop /snap/snapd/15177
loop2     7:2    0 67.9M  1 loop /snap/lxd/22526
loop3     7:3    0 63.2M  1 loop /snap/core20/1623
loop4     7:4    0   48M  1 loop /snap/snapd/17029
loop5     7:5    0 67.8M  1 loop /snap/lxd/22753
vda     252:0    0   50G  0 disk 
├─vda1  252:1    0 49.9G  0 part /
├─vda14 252:14   0    4M  0 part 
└─vda15 252:15   0  106M  0 part /boot/efi
vdb     252:16   0    2M  1 disk 

root@VM6cdc8488:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            2.0G     0  2.0G   0% /dev
tmpfs           394M  876K  393M   1% /run
/dev/vda1        49G  2.2G   47G   5% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/loop1       44M   44M     0 100% /snap/snapd/15177
/dev/vda15      105M  5.2M  100M   5% /boot/efi
/dev/loop2       68M   68M     0 100% /snap/lxd/22526
/dev/loop0       62M   62M     0 100% /snap/core20/1376
tmpfs           394M     0  394M   0% /run/user/0
/dev/loop3       64M   64M     0 100% /snap/core20/1623
/dev/loop4       48M   48M     0 100% /snap/snapd/17029
/dev/loop5       68M   68M     0 100% /snap/lxd/22753
1 Like