cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dinu Arateanu <>
Subject Re: KVM/mem.overprovisioning.factor
Date Thu, 22 Aug 2013 15:14:56 GMT
Thanks Bharat,

As far as I'm aware, the only way to change the default system VM offering for a domain router
can be done by modifying the database (altering the disk_offerings table). One can change
it when a router is not running, but with multiple routers in a cloud it may become tedious.

Concerning the secondary storage, there is a global setting, but last time I checked it's
undocumented (one needs to fill in the service offering database ID, which isn't visible through
Cloud UI). 

I'd rather see a more straightforward approach. Ideally, system VMs should not be affected
by overprovisioning settings. Less ideally, one should more easily change the settings for
(default) system service offerings. A "Default" checkbox in the edit form would be nice :)


On Aug 22, 2013, at 8:55 AM, Bharat Kumar <> wrote:

> Hi Dinu,
> you can modify the system service offering for the systems vms and change it to 512MB
so that when using overcommit (of 4 ) its memory is set to 128 MB.
> you are right the current memory is set to system offering divided by the over provisioning
> On Aug 22, 2013, at 2:05 AM, Dinu Arateanu <>
> wrote:
>> Hello,
>> I'm testing ACS 4.2 with kvm. I noticed that when one configures mem.overprovisioning.factor
Global/Cluster setting, chances are that the System VMs configured with an offer of 128 MB
RAM will never start (namely the Domain Router and the SSVM). 
>> According to the agent.log, ACS sends libvirt the request to start the VM with a
"currentMemory" parameter equal to the System Offering RAM divided by mem.overprovisioning.factor:
>> 2013-08-21 11:02:34,824 DEBUG [cloud.agent.Agent] (agentRequest-Handler-1:null) Request:Seq
1-1537935677:  { Cmd , MgmtId: 117981950658, via: 1, Ver: v1, Flags: 100011, [{"":{"vm":{"id":13,"name":"
>> r-13-VM","type":"DomainRouter","cpus":1,"minSpeed":125,"maxSpeed":500,"minRam":33554432,"maxRam":134217728,"arch":"x86_64","os":"Debian
GNU/Linux 5.0 (32-bit)","bootArgs":" template=domP name=r-13-VM eth0ip= eth0mask=
>> gateway= dhcprange= eth1ip=
eth1mask= type=dhcpsrvr disable_rp_filter=true dns1=","rebootOnCrash":false,"enableHA":true,"limitCpuUse":false
>> ,"enableDynamicallyScaleVm":false,"vncPassword":"*","params":{"memoryOvercommitRatio":"4","cpuOvercommitRatio":"4"},"uuid":"52caa75a-5331-4979-9456-18d1b743b7ad","disks":[{"data":{"
>> VolumeObjectTO":{"uuid":"c84b6834-6bab-4087-a044-e61a1e3a391b","volumeType":"ROOT","dataStore":{"":{"uuid":"c1ac7425-f6d2-3ada-b78a-b17faceb89ea","id":2,"poolType":"RBD","host":"
>> skSeq":0,"type":"ROOT"}],"nics":[{"deviceId":0,"networkRateMbps":1000,"defaultNic":true,"uuid":"c68fdd00-68e0-4755-b6e1-c07c4d122040","ip":"","netmask":"","gateway":"","mac":"06:f2:0e:00:01:74"
>> ,"dns1":"","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://40","isolationUri":"vlan://40","isSecurityGroupEnabled":false,"name":"vswitch0"},{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"uuid":"1778dbb
>> d-7d27-481a-96ad-99c9aac36e8f","ip":"","netmask":"","gateway":"","mac":"0e:00:a9:fe:03:d7","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false}]},"hostIp":"","
>> executeInSequence":false,"wait":0}},{"":{"ip":"","port":3922,"interval":6,"retries":100,"name":"r-13-VM","wait":0}},{"":{"accessDetails":{
>> "":"r-13-VM","router.ip":""},"wait":0}},{}] }
>> [...]
>> <name>r-13-VM</name>
>> <uuid>52caa75a-5331-4979-9456-18d1b743b7ad</uuid>
>> <description>Debian GNU/Linux 5.0 (32-bit)</description>
>> [...]
>> <memory>131072</memory>
>> <currentMemory>32768</currentMemory>
>> <devices>
>> <memballoon model='virtio'/>
>> </devices>
>> <vcpu>1</vcpu>
>> <os>
>> <type  arch='x86_64' machine='pc'>hvm</type>
>> <boot dev='cdrom'/>
>> <boot dev='hd'/>
>> </os>
>> <cputune>
>> <shares>125</shares>
>> </cputune>
>> <on_reboot>restart</on_reboot>
>> <on_poweroff>destroy</on_poweroff>
>> <on_crash>destroy</on_crash>
>> </domain>
>> As a result, the System VM will be created, but will never run - 32 MB RAM is too
low. I'm not arguing about how recommended it is to set a factor of 4 for memory ballooning
(outside testing environments), but rather that ACS should start (at least the System) VMs
with a minimum RAM. The virtio_balloon module seems to be loaded within the SVM template,
but it does not work. 
>> Is there any way to control how much minimum RAM ACS allocates based on the service
offering and the overprovisioning factor? 
>> Thanks,
>> Dinu

View raw message