cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jerry Jiang" <jerry.ji...@sjcloud.cn>
Subject 答复: KVM/mem.overprovisioning.factor
Date Thu, 22 Aug 2013 01:59:51 GMT
Hi Dinu,

I agree that overprovisioning factors should not affect system VMs

Jerry

-----邮件原件-----
发件人: Dinu Arateanu [mailto:dinu.arateanu@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





Mime
View raw message