You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by GitBox <gi...@apache.org> on 2019/07/03 09:27:42 UTC

[GitHub] [cloudstack] rhtyd edited a comment on issue #3455: Configurable disk size of systemvm

rhtyd edited a comment on issue #3455: Configurable disk size of systemvm
URL: https://github.com/apache/cloudstack/issues/3455#issuecomment-508016526
 
 
   @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). 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.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services