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 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 

----------------------------------------------------------------
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:
[email protected]


With regards,
Apache Git Services

Reply via email to