Hello,
I’ve just switched to running Rocky for some of my Openstack workloads (From CentOS 7). I’m having trouble finding any information on the expected (automatic) disk layout. I was expecting the root partition to be grown to fill the disk allocated to the VM - that’s what pretty much all the other images I use do.
I am running Rocky-8-GenericCloud-LVM.latest.x86_64.qcow2 image and booting with the automatic disk partition option and an 80GB volume.
What I get is a is pv created on the last partition of the disk which was created as 9G partition with the rest of the disk free. The vg and lv correctly fill the pv.
lsblk -o name,type,fstype,size,mountpoint
NAME TYPE FSTYPE SIZE MOUNTPOINT
sr0 rom iso9660 506K
vda disk 80G
├─vda1 part vfat 99M /boot/efi
├─vda2 part xfs 1000M /boot
├─vda3 part 4M
├─vda4 part 1M
└─vda5 part LVM2_member 8.9G
└─rocky-root lvm xfs 8.9G /
I can manually use growpart to grow the patition and then extend the vg and lv and resize the filesystem, and I’m sure I can add manual partition to cloud-init and get it to work on first boot that way. But it doesn’t feel like this is how it’s supposed to be working!
Am I missing something (very possible!) or can I help diagnose the issue any futher?
You chose the image with LVM which is why it’s different to what you were expecting. There should also be a generic cloudimage without LVM, so similar to what you expect, a standard partition at the end of the disk that can be resized with growpart and without having to extend the vg/lv.
Thanks for the response…I guess I’m missing something on the difference between the images with and without LVM…Is there a page explaning it - I didn’t find one on a quick scan.
I guess the intention here is to allow the user to allocate the rest of the disk to their own scheme?
I like using LVM, as it make life easier on longer running vms if I need to resize (although I can obvously handle that in other ways too!).
Apprechiate the response - I’ll give the non-lvm image a spin and see if that works better for me than expanding the partition myself!
I think you’re saying the “disk” called ‘vda’ is 80G, but the five partitions added together are less that 80G?
But surely that’s good news.
You can now create a big new partition for stuff like websites and databases, instead of having them all jumbled up in ‘/’ root? Plus if you’re database explodes it won’t take down the o/s.
The images to concentrate on are the ones “GenericCloud”. There are GenericCloud-Base, and also the GenericCloud-LVM. The base one will be the standard partitions without LVM. Also, on the downloads page here: Download - Rocky Linux you will see for the cloud image that the QCOW2 image is linked to the GenericCloud-Base image as well.
The LVM variant that we issue is something that was requested early on in the project. Obviously that’s the difference between the two, and not much else. What should be noted is that resizing is not automatic because the utilities (cloud-init, which calls up growpart) doesn’t work with LVM properly.
Yeah I agree, but if I wanted an explicit layout I would set up the partitioning manualy at first boot using cloud-init.
I was thinking more about the default behaviour, when no partition layout is provided. I just think a 9GB root partition with nothing else created is probebly going to cause more issue than it solves to the unaware user just creating a VM. They specified a large disk in their virtulisation manager of choice and ended up with a small disk.
It’s fine though as there are tools (and another image) to deal with it.
TBH, when you have cloud images that use cloud-init and growpart, LVM at this point is pointless and causes more problems than it solves. I guess it comes from people using LVM on VM’s/servers they’ve created themselves, and thus expect cloud images to have the same. The fact that cloud images generally are managed differently and resized accordingly as per the instance chosen, there is really no need for LVM. Also, if you attach data disks anyway, your have it separate from your instance disk. At which point if you wanted, you could create LVM on the additionally attached disk.
No problem in offering it obviously, I would never use an LVM cloud image anyway because it causes more problems than it solves (at least not until cloud-init starts supporting and dealing with LVM automatically). If I resize my instance with standard partitions, cloud-init resizes it automatically including the filesystem. And I sit back and enjoy my beer
I’m not sure why I had the LVM instance, other than I was just messing with thin provisioning on my Openstack volume storage so it was in my head at the time. I can’t think of a good reason to use it…I’m going to switch.
This was a useful thread for me though to understand the decisions you made in making the images available.
I sometimes roll my own images for OpenStack. On my laptop with KVM, I create say a Rocky 8 or 9 machine. I then remove stuff I may not need, eg: sssd* packages to save on memory usage, perhaps even disable crashkernel. Once done, run virt-sysprep, use qemu-img to compress the qcow2 into a smaller image size and upload it to OpenStack and set the appropriate required sizes for minimum disk/ram, etc.
