Configurable disk size of systemvm

[ustcweizhou]

Currently we have systemvm template which has very small disk size.
Because of this, it is difficult to install new packages or upgrade existing packages.
Another issue is, if disk is full, virtual routers will not work because cloudstack will write some files to local disk when new configurations are applied to virtual routers.

Here is the partitions of a virtual router

root@r-220-VM:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 110M 0 110M 0% /dev
tmpfs 49M 25M 24M 52% /run
/dev/sda5 1.1G 714M 342M 68% /
tmpfs 121M 0 121M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 121M 0 121M 0% /sys/fs/cgroup
/dev/sda1 92M 35M 57M 39% /boot
/dev/sda6 435M 31M 400M 8% /var
/dev/sda7 75M 1.6M 72M 3% /tmp
tmpfs 121M 20K 121M 1% /ramdisk
tmpfs 25M 0 25M 0% /run/user/0

ISSUE TYPE

Improvement Request

COMPONENT NAME

SystemVM Template

CLOUDSTACK VERSION

4.14 (?)

SUMMARY

It would be nice to make disk size of systemvm configurable.
To archive it, we need to
(1) add global setting to indicate the disk size of systemvms and virtual routers
(2) allocate disk with new size when provision the systemvm and virtual routers
(3) install some packages/scripts in sysemvm template, so systemvm/vr can be auto-resized when systemvm/vr start.
some documents in openstack: https://docs.openstack.org/image-guide/openstack-images.html#disk-partitions-and-resize-root-partition-on-boot-cloud-init

We might need to change scripts to build the systemvm template (to have only one partition in systemvm ?)

this is related to #3426 @rhtyd

[onitake]

I think it would be much better to create a new template instead of modifying VRs in-place.
That way, you will always get a consistent setup whenever you create or recreate a new system VM.

[ustcweizhou]

@onitake do you mean create a new systemvm template with bigger disk size ? official release or by ourselves ?

If by ourselves, we need to
(1) create a vm from systemvm template
(2) resize disk
(3) resize partitions
(4) stop the vm
(5) create a template from the vm
(6) upload systemvm template
(7) set template type as SYSTEM in database
(8) change global settings

any other step I missed ?

We have used cloud-init to autoresize /autogrow on partitions for many vm templates without any issue.
The consistent or inconsistent on disk size of systemvm/virtual routers is not important for us.
systemvm/virtual routers can have different disk size, same user vm instances.
If disk of a virtual router is almost full, we can restart network with cleanup to create a new virtual router with bigger size, if disk size is configurable.

[richardlawley]

We create our own systemvm templates and have switched to just root/boot partitions as the many partitions approach just led to inefficient use of space.

[ustcweizhou]

@richardlawley yes, that's also what we did.

@rhtyd can we do in three steps ?
(1) only one partition in systemvm template
(2) a fixed bigger disk size (?)
(3) configurable disk size. this has low priority if the default size is increased.

[yadvr]

@ustcweizhou @richardlawley yes, we can consider that. The main reason to keep separate partitions was to ensure that filling of logs and process creates files in /var/cache/cloud doesn't kill the VM. Do note that the VR could be public facing and may be prone to attacks.

I would propose to keep at least the /var as a separate partition and to support pvgrub based boot on xenserver the /boot has to be an ext2 (separate) partition.

I think starting 4.11.2+, there is an option to pass and specify the root disk size we could (1) introduce a systemvm/vr specific global setting that is the root disk size, which is not defined/null by default, (2) when this global setting is defined it resizes the root disk before deployment, (3) during patching via bootstrap.sh the script can extend one or all the partitions to fill any empty space if necessary and if we move to something like cloud-init it can do that for us.

I've few other ideas around the new systemvmtemplate, where the whole root disk could be simply used as data disk while the appliance OS (a custom debian 10 or alpine based) boots via the systemvm.iso directly as a read-only system (no need to ship separate systemvmtemplate appliances and force users to go through the register/setup steps during install/upgrade). I also have some ideas that I'll document and propose after 4.13 around live patching (no need to reboot VRs during upgrade), runc/containerd inclusion for dnsmasq/nginx/strongswan/* services and a light-weight tls-secured VR agent than use the ssh-based programming model. More on that after 4.13. cc @PaulAngus

[ustcweizhou]

@rhtyd awesome !!

[andrijapanicsb]

@rhtyd linking this one with #3601 if you feel we have the bandwidth, otherwise let's move this one for 4.15?

[andrijapanicsb]

We are not doing debian10 for this releases systemvm template so moving this to 4.15 milestone