Hi Dinu, you can change the system service offering in 4.2. refer to this link http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.1.1/html/Admin_Guide/system-service-offerings.html
This is for 4.1 but will work with 4.2 as well. As per the overcommit settings getting applied to the routervm, it might be useful if you want to optimize the resource usage based on the usage pattern. say if do not know the amount of memory required during peak usage, but you know the minimum memory required. you can use this info to launch a router vm which uses the minimum memory most of the time under normal usage but can also scale its memory when required during the peak usage without the need to stop the router VM. Regards, Bharat. On Aug 22, 2013, at 8:45 PM, Dinu Arateanu <[email protected]> wrote: > 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 :) > > Regards, > Dinu > > > > On Aug 22, 2013, at 8:55 AM, Bharat Kumar <[email protected]> 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 factor. >> >> On Aug 22, 2013, at 2:05 AM, Dinu Arateanu <[email protected]> >> 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, >>> [{"com.cloud.agent.api.StartCommand":{"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=10.10.40.10 eth0mask= >>> 255.255.255.0 gateway=10.10.40.1 domain=dev.int dhcprange=10.10.40.1 >>> eth1ip=169.254.3.215 eth1mask=255.255.0.0 type=dhcpsrvr >>> disable_rp_filter=true >>> dns1=8.8.8.8","rebootOnCrash":false,"enableHA":true,"limitCpuUse":false >>> ,"enableDynamicallyScaleVm":false,"vncPassword":"*","params":{"memoryOvercommitRatio":"4","cpuOvercommitRatio":"4"},"uuid":"52caa75a-5331-4979-9456-18d1b743b7ad","disks":[{"data":{"org.apache.cloudstack.storage.to. >>> VolumeObjectTO":{"uuid":"c84b6834-6bab-4087-a044-e61a1e3a391b","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"c1ac7425-f6d2-3ada-b78a-b17faceb89ea","id":2,"poolType":"RBD","host":" >>> ceph.dev.int","path":"rbd1","port":6789}},"name":"ROOT-13","size":272915248,"path":"329df94f-4c30-4617-9fbd-440b76f08cde","volumeId":13,"vmName":"r-13-VM","accountId":1,"format":"RAW","id":13,"hypervisorType":"KVM"}},"di >>> skSeq":0,"type":"ROOT"}],"nics":[{"deviceId":0,"networkRateMbps":1000,"defaultNic":true,"uuid":"c68fdd00-68e0-4755-b6e1-c07c4d122040","ip":"10.10.40.10","netmask":"255.255.255.0","gateway":"10.10.40.1","mac":"06:f2:0e:00:01:74" >>> ,"dns1":"8.8.8.8","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":"169.254.3.215","netmask":"255.255.0.0","gateway":"169.254.0.1","mac":"0e:00:a9:fe:03:d7","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false}]},"hostIp":"10.10.8.25"," >>> executeInSequence":false,"wait":0}},{"com.cloud.agent.api.check.CheckSshCommand":{"ip":"169.254.3.215","port":3922,"interval":6,"retries":100,"name":"r-13-VM","wait":0}},{"com.cloud.agent.api.GetDomRVersionCmd":{"accessDetails":{ >>> "router.name":"r-13-VM","router.ip":"169.254.3.215"},"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 >>> >>> >>> >> >
