Disk re-size not working

Community Support
1

Any help on this would be appreciated I believe I have followed everything correctly.

I have created my own template from an ISO and installed this all is working fine I can deploy this.
As part of the install I installed the opennebula contextulization deb package and this allows the VM to gain an IP address from Opennebula which is great.

However if I deploy from this template and increase the disk size it is not reflected in df -h or fdisk -l

Is there something that needs to be done manually to modify the context scripts specific to the system?

If so how would I go about that.

Ideally it would be good if when we increased the VM’s disk size it was reflected in the VM.

2

Hi,

Could you elaborate a bit on your setup?

OpenNebula version, front-end host OS and version, Hypervisor OS and version, addon-context-linux version, guest OS is debian but… version :wink:, what datastore drivers (TM_MADs) are in use, etc?

There are a lot of places where the resize procedure could brake - libvirt incompatibility, datastore driver incompatibility, contextualization incompatibility with the guest OS, bugs, etc…

Also, does the images from the OpenNebula marketplace do resize properly on same setup/datastore?

Best Regards
Anton Todorov

3

Hello thanks for the response , of course here is the info.

I am running a lab setup 2 x kvm nodes built on Ubuntu 16.04.
Sunstone is installed on one of the nodes.
Opennebula version is 5.4

Guest os is Debian 7

I have a couple of datastores setup for testing, local storage on each node using ssh transfer mode and an nfs datastores.

The marketplace images work correctly so I think all pre requosists etc. Are in place and it’s probably something I am missing on the guest VM

The context packages have been installed via apt-get and have pulled the latest version

The network context and other contexts (e.g. I can set the root password on boot) all work fine it’s just the disk re-size which isn’t working, I can see errors on the console when it boots however they go way to quick for me to see what they are.

4

I think that in your case you should try running the resize script /etc/one-context.d/loc-05-grow-rootfs manually (as root) and see where it breaks. Hopefully there is a missing package dependency or something like that.

Hope this helps.

Best Regards,
Anton Todorov

5

Thanks Anton,

Looks like the script is failing as it cannot locate the device:

However its looking for the wrong device:

root@observium ~# bash /etc/one-context.d/loc-05-grow-rootfs
FAILED: /dev/dm-: does not exist
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 4456448 (4k) blocks long. Nothing to do!

root@observium ~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/dm-0 17G 1.9G 14G 12% /
udev 10M 0 10M 0% /dev
tmpfs 201M 8.4M 192M 5% /run
tmpfs 501M 0 501M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 501M 0 501M 0% /sys/fs/cgroup
tmpfs 101M 0 101M 0% /run/user/0

root@observium ~# ls -l /dev/ | grep dm-
brw-rw---- 1 root disk 253, 0 May 14 12:39 dm-0
brw-rw---- 1 root disk 253, 1 May 14 10:36 dm-1

Looks like its failing on this part of the script:

root@observium ~# DEVICE=$(readlink -f “$DEVICE”)
root@observium ~# (readlink -f "DEVICE") /dev/dm-0 root@observium ~# DISK=(echo "DEVICE" | sed 's/.//’)
root@observium ~# (echo "DEVICE" | sed 's/.//’)
/dev/dm-
root@observium ~#

However I think there is a lot more to this than simply modifying this script:

root@observium ~# fdisk -l

Disk /dev/vda: 50 GiB, 53687091200 bytes, 104857600 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x2f250c11

Device Boot Start End Sectors Size Id Type
/dev/vda1 * 123046 39062500 38939455 18.6G 8e Linux LVM

Disk /dev/mapper/turnkey-root: 17 GiB, 18253611008 bytes, 35651584 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/turnkey-swap_1: 512 MiB, 536870912 bytes, 1048576 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

6

I was also setup openenbula 5.4.XX version with centos then faced issues with disk resize. found that its a bug in opennebula please go through on below link

#1585 Resize disk leads to qcow2 corruption:

https://github.com/OpenNebula/one/issues/1585

7

Definitely you are hitting a bug.

Could you provide the output of mount, cat /etc/mtab, cat /proc/mountsand cat /etc/fstab?
It looks like that LVM is not properly detected and it is branching to a wrong code path.

Also, which version/archive/package of one-context you are using?

BR,
Anton