Automatic resizing of partition (VMware)

Archive RancherOS
1

Hi there,

we are using RancherOS v0.5.0 with the new resize option (http://docs.rancher.com/os/configuration/resizing-device-partition/) in our cloud-config:

#cloud-config
ssh_authorized_keys:

  • ssh-rsa xxx
    hostname: xxx

rancher:
resize_device: /dev/sda
network:
dns:
nameservers:
- xxx
- xxx
interfaces:
eth*:
dhcp: false
eth0:
address: 172.16.16.10/22
gateway: 172.16.16.1
mtu: 1500

We have now resized the VMDK form 10GB to 40GB.
After a reboot, RancherOS still show us only 9.2 GB disk size:

df -h
Filesystem Size Used Available Use% Mounted on
overlay 9.2G 312.3M 8.4G 3% /

How does the automatic resizing of partition exactly work?

Thank you for your help.

Best regards
Reto

2

Did you install with the given cloud-config before resizing the VMDK? The resizing functionality is set to only resize once, so if you changed the disk size after the first install boot then it’ll not resize again.

You can test that this is the issue by removing /var/lib/rancher/resize.done and rebooting. If your disk isn’t properly resized afterwards then the issue is elsewhere.

3

Hi,
same issue here (OpenStack and 0.5.0)

in 0.4.5 i could do:
environment:
RESIZE_DEV: /dev/vda
FORCE: true
services_include:
resize-fs: true

But this does not work anymore.

Have the same config as @giezi

There is no resize.done in /var/lib/rancher directory.

I was hoping to get disk resized on initial boot (device: /dev/vda).

br hw

4

Resizing is basically done by running the following commands. Can you try running these manually (replacing the device as needed)?

growpart /dev/vda 1
partprobe
resize2fs /dev/vda1
5

OK,
made a machine with 20GB disk

[root@asdfasfd rancher]# df -h
Filesystem Size Used Available Use% Mounted on
overlay 7.4G 261.4M 6.7G 4% /
tmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
none 1.9G 532.0K 1.9G 0% /run
/dev/vda1 7.4G 261.4M 6.7G 4% /mnt
/dev/vda1 7.4G 261.4M 6.7G 4% /media
/dev/vda1 7.4G 261.4M 6.7G 4% /home
/dev/vda1 7.4G 261.4M 6.7G 4% /opt
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/sbin/halt
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/sbin/iptables
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/lib/firmware
devtmpfs 1.9G 0 1.9G 0% /host/dev
shm 64.0M 0 64.0M 0% /host/dev/shm
none 1.9G 532.0K 1.9G 0% /var/run
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/sbin/poweroff
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/sbin/reboot
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/lib/modules
/dev/vda1 7.4G 261.4M 6.7G 4% /etc/selinux
/dev/vda1 7.4G 261.4M 6.7G 4% /etc/docker
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/sbin/shutdown
/dev/vda1 7.4G 261.4M 6.7G 4% /var/log
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/bin/docker-containerd-shim.dist
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/share/ros
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/bin/cloud-init
/dev/vda1 7.4G 261.4M 6.7G 4% /var/lib/rancher
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/sbin/netconf
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/bin/docker-containerd.dist
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/bin/respawn
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/bin/dockerlaunch
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/bin/switch-console
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/bin/docker.dist
/dev/vda1 7.4G 261.4M 6.7G 4% /var/lib/docker
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/bin/user-docker
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/sbin/wait-for-docker
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/bin/ros
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/bin/system-docker
/dev/vda1 7.4G 261.4M 6.7G 4% /usr/bin/docker-runc.dist
/dev/vda1 7.4G 261.4M 6.7G 4% /var/lib/rancher/conf
/dev/vda1 7.4G 261.4M 6.7G 4% /var/lib/rancher/cache
/dev/vda1 7.4G 261.4M 6.7G 4% /etc/ssl/certs/ca-certificates.crt.rancher
/dev/vda1 7.4G 261.4M 6.7G 4% /etc/resolv.conf
/dev/vda1 7.4G 261.4M 6.7G 4% /etc/hostname
/dev/vda1 7.4G 261.4M 6.7G 4% /etc/hosts
shm 64.0M 0 64.0M 0% /dev/shm
devtmpfs 1.9G 0 1.9G 0% /dev
shm 64.0M 0 64.0M 0% /dev/shm

growpart /dev/vda 1
CHANGED: partition=1 start=2048 old: size=16775168 end=16777216 new: size=41940959,end=41943007
partprobe
Warning: Unable to open /dev/sr0 read-write (Read-only file system). /dev/sr0 has been opened read-only.
Error: Partition(s) 1 on /dev/vda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes.

Reboot

resize2fs /dev/vda1
resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/vda1 is mounted on /opt; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/vda1 is now 5242619 (4k) blocks long.

All is OK.

So,
It needs a reboot before resize.

running commands in the sequence you describe is not working:
growpart /dev/vda 1
CHANGED: partition=1 start=2048 old: size=16775168 end=16777216 new: size=41940959,end=41943007
partprobe
Warning: Unable to open /dev/sr0 read-write (Read-only file system). /dev/sr0 has been opened read-only.
Error: Partition(s) 1 on /dev/vda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes.
resize2fs /dev/vda1
resize2fs 1.42.13 (17-May-2015)
The filesystem is already 2096896 (4k) blocks long. Nothing to do!

However running:
docker run --privileged -i --rm ubuntu bash << EOF
apt-get update
apt-get install -y cloud-guest-utils parted
growpart /dev/xda 1
partprobe
resize2fs /dev/vda1
EOF

disk is grown without the need for rebooting.

So, what can be done fixing this?

/hw

6

Would you mind filing an issue for this? It does seem like there is something incorrect about the default console that’s causing this. Maybe a missing package or something like that.

7

Thank you for your answer!
Yes, we’ve installed the RancherOS with a cloud-config on a disk (10GB) with the resize option.
Afterwards, we have resized the 10GB disk to 40GB.

In my perspective, it would be very nice if there will be an “always-on” option for the resizing, like CoreOS:
If the disk will be extended on VM-Level, we just need to reboot the machine and the resize is done fully automatically.

What do you think about?

Best regards
Reto

8

I agree, this should be an option. Please fill an issue for this as well :slight_smile:

9

Hi Josh

Sure, I will do this - many thanks!

Best regards
Reto

10

did you create the issue already? i had the same issue on KVM.

rancher:
  resize_device: /dev/vda
  services_include:
    resize-fs: true

i could get it down manually by

growpart /dev/vda 1
probpart
resize2fs /dev/vda1

resizefs hints, that its a online-resize:

Filesystem at /dev/vda1 is mounted on /opt; on-line resizing required

But it all works out

update: found the issue https://github.com/rancher/os/issues/1131

11

Littel upate

Actually with the resize_fs setting, i did not need to call growpart, all you need is boot once, then reboot once again and then run resize2fs /dev/vda1

so at some degree growpart already works automated