Hi Dinu, I agree that overprovisioning factors should not affect system VMs
Jerry -----邮件原件----- 发件人: Dinu Arateanu [mailto:dinu.arate...@gmail.com] 发送时间: 2013年8月22日 星期四 4:36 收件人: users@cloudstack.apache.org 主题: KVM/mem.overprovisioning.factor 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,"minRa m":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":{"memoryOvercom mitRatio":"4","cpuOvercommitRatio":"4"},"uuid":"52caa75a-5331-4979-9456-18d1 b743b7ad","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-V M","accountId":1,"format":"RAW","id":13,"hypervisorType":"KVM"}},"di skSeq":0,"type":"ROOT"}],"nics":[{"deviceId":0,"networkRateMbps":1000,"defau ltNic":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":"vsw itch0"},{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"uuid":"1778db b 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.CheckSshComm and":{"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