You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Actually we have two way to manage memory size of instance:
fixed size: gnt-instance add -B mem=4G my.instance
=> Instance minmem and maxmem will be set to mem value
=> it's not possible to use memory ballooning without reconfiguring memory parameter and restart instance
limited size: gnt-instance add -B minmem=1G,maxmem=16G my.instance
=> Instance will start with mem=maxmem
=> usage of memory ballooning with --runtime-memory will permit only to reduce temporary instance live memory
So instance startup memory is maxmem in any case and it's only possible to shrink memory at runtime and lost it on restart. It's possible to change maxmem to have the new size at restart but it won't be possible to grow up later runtime memory.
Memory ballooning works perfectly but instance memory design don't permit to use it fully.
It need parameters manipulation and many instance restart.
Actually on our cluster we use a global maxmem and we manage an external memory parameter for each instance to be able to start the machine with maxmem and shrink the runtime memory right after boot to the external memory parameter.
We use an instance image hook to do it. It works but we still need instance maxmem available at instance boot time.
I think it would be really more usefull to do not have mem=maxmem and have separate parameter:
minmem - minimum instance memory size
mem - instance memory size used at start time and to change runtime memory
maxmem - maximum instance memory size
Like it minmem and maxmem will be limit of memory ballooning while mem will be the effective instance memory size.
That will permit to shrink or grow up easily mem online while respecting minmem/maxmem.
I think actual design is related to node allocation and to be sure that we can always migrate an instance on another node with enough memory. But that brings a really strong limitation about memory ballooning usage.
maxmem have to be an isntance memory limit not a cluster allocation one.
We can still use mem for cluster allocation issues to be sure that we can migrate instance on another node.
We can add a warning in case memory ballooning can prevent future instance migration because there is not enough memory for migration.
In addition that can permit to have real on demand memory instances by monitoring running instance usage and control ganeti with an external tool.
On production, we need often to be able to grow up instance memory temporary or simply to resize memory instance.
Actually the first is not possible (only shrinking) and the second need an instance restart.
Online resources (CPU/memory/disk) resizing is the key of soft cluster management.
I wish ganeti will manage in a near future online resources resizing as easily as we can actually manage instances location.
The text was updated successfully, but these errors were encountered:
Actually we have two way to manage memory size of instance:
fixed size:
gnt-instance add -B mem=4G my.instance
=> Instance minmem and maxmem will be set to mem value
=> it's not possible to use memory ballooning without reconfiguring memory parameter and restart instance
limited size:
gnt-instance add -B minmem=1G,maxmem=16G my.instance
=> Instance will start with mem=maxmem
=> usage of memory ballooning with
--runtime-memory
will permit only to reduce temporary instance live memorySo instance startup memory is maxmem in any case and it's only possible to shrink memory at runtime and lost it on restart. It's possible to change maxmem to have the new size at restart but it won't be possible to grow up later runtime memory.
Memory ballooning works perfectly but instance memory design don't permit to use it fully.
It need parameters manipulation and many instance restart.
Actually on our cluster we use a global maxmem and we manage an external memory parameter for each instance to be able to start the machine with maxmem and shrink the runtime memory right after boot to the external memory parameter.
We use an instance image hook to do it. It works but we still need instance maxmem available at instance boot time.
I think it would be really more usefull to do not have mem=maxmem and have separate parameter:
Like it minmem and maxmem will be limit of memory ballooning while mem will be the effective instance memory size.
That will permit to shrink or grow up easily mem online while respecting minmem/maxmem.
I think actual design is related to node allocation and to be sure that we can always migrate an instance on another node with enough memory. But that brings a really strong limitation about memory ballooning usage.
maxmem have to be an isntance memory limit not a cluster allocation one.
We can still use mem for cluster allocation issues to be sure that we can migrate instance on another node.
We can add a warning in case memory ballooning can prevent future instance migration because there is not enough memory for migration.
In addition that can permit to have real on demand memory instances by monitoring running instance usage and control ganeti with an external tool.
On production, we need often to be able to grow up instance memory temporary or simply to resize memory instance.
Actually the first is not possible (only shrinking) and the second need an instance restart.
Online resources (CPU/memory/disk) resizing is the key of soft cluster management.
I wish ganeti will manage in a near future online resources resizing as easily as we can actually manage instances location.
The text was updated successfully, but these errors were encountered: