Hi!
I am using Proxmox v. 3.0 and i would like you to confirm that one can generally safely increase these resources for a _running_ OpenVZ container (thru web gui) assuming there are enough so to say spare physical resourses on the host available (my containers run Debian v. 7 and Debian v. 6 64 bit operating systems)?
And also decrease same resources for a _running_ OpenVZ container?
I believe that since web gui permits those changes both ways while container is running it must be ok doing so, also i saw some of them clearly mentioned in forum posts as possible, and actually i tried to increase and decrease and everything seems to work, too (experimented only with Debian v. 7 32 bit). Just to be safe, please confirm its ok and if there are some obvious or less obvious considerations to take into account while making those changes, please comment on them. (Or there are more changes possible with running container, i didnt try to add network interface).And one more question not about container but about Proxmox host and all containers and file based storage KVM machines. Say i have containers and file based KVM machines as they are by default under /var/lib/vz (and on /dev/pve/data LVM volume) running and i have unallocated resources in pve volume group. Is it safe to increase /dev/pve/data volume and /var/lib/vz filesystem online i.e. while containers and KVM machines are running? And and as a result i expect to have
And also, if there are a catch somewhere doing these changes, please point me to it, too.
Many thanks for awsome software!
Imre
PS Sorry, I accidentally posted it into wrong sub-forum first time.
I am using Proxmox v. 3.0 and i would like you to confirm that one can generally safely increase these resources for a _running_ OpenVZ container (thru web gui) assuming there are enough so to say spare physical resourses on the host available (my containers run Debian v. 7 and Debian v. 6 64 bit operating systems)?
- cpu count for openvz container
- memory size for openvz container
- disk size for openvz container
And also decrease same resources for a _running_ OpenVZ container?
- decreasing cpu count will probably increase load in the container?
- with decreasing memory one must be probably most careful or container starts oom'ing i.e. killing running processes? (thus better check beforehand with free that in the container is unused memory available)
- as long as container has unused space in filesystem (size-wise and inode-wise) it is safe to decrease online? (it seems that by default there is 200 000 inodes per 1 G space)
I believe that since web gui permits those changes both ways while container is running it must be ok doing so, also i saw some of them clearly mentioned in forum posts as possible, and actually i tried to increase and decrease and everything seems to work, too (experimented only with Debian v. 7 32 bit). Just to be safe, please confirm its ok and if there are some obvious or less obvious considerations to take into account while making those changes, please comment on them. (Or there are more changes possible with running container, i didnt try to add network interface).And one more question not about container but about Proxmox host and all containers and file based storage KVM machines. Say i have containers and file based KVM machines as they are by default under /var/lib/vz (and on /dev/pve/data LVM volume) running and i have unallocated resources in pve volume group. Is it safe to increase /dev/pve/data volume and /var/lib/vz filesystem online i.e. while containers and KVM machines are running? And and as a result i expect to have
- more filesystem resources for making new containers or increasing disk size on existing ones
- more filesystem resources for making new KVM under /var/lib/vz/images
- at the moment i am not asking about resize'ing KVM storage online since there isnt practical need for that for me now
And also, if there are a catch somewhere doing these changes, please point me to it, too.
Many thanks for awsome software!
Imre
PS Sorry, I accidentally posted it into wrong sub-forum first time.