You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Dinu Arateanu <di...@gmail.com> on 2013/08/21 22:35:38 UTC
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,"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
答复: KVM/mem.overprovisioning.factor
Posted by Jerry Jiang <je...@sjcloud.cn>.
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
Re: KVM/mem.overprovisioning.factor
Posted by Bharat Kumar <bh...@citrix.com>.
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 <di...@gmail.com> 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 <bh...@citrix.com> 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 <di...@gmail.com>
>> 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
>>>
>>>
>>>
>>
>
Re: KVM/mem.overprovisioning.factor
Posted by Dinu Arateanu <di...@gmail.com>.
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 <bh...@citrix.com> 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 <di...@gmail.com>
> 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
>>
>>
>>
>
Re: KVM/mem.overprovisioning.factor
Posted by Nitin Mehta <Ni...@citrix.com>.
Thanks Bharat. It would be nice if you can add an example in the FS [1],
an example of calculation.
Say admin decides an overcommit ration for memory = 2. Similarly for cpu.
What does it mean for the capacity of his cluster ?
What does it mean when a vm gets deployed with service offering 1 gb
What would the dashboard look like after the vm is deployed in the cluster.
[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CPU+and+RAM+Overcomm
it
Thanks,
-Nitin
On 22/08/13 11:33 AM, "Bharat Kumar" <bh...@citrix.com> 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 <di...@gmail.com>
> 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,"mi
>>nRam":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":{"memoryOver
>>commitRatio":"4","cpuOvercommitRatio":"4"},"uuid":"52caa75a-5331-4979-945
>>6-18d1b743b7ad","disks":[{"data":{"org.apache.cloudstack.storage.to.
>>
>>VolumeObjectTO":{"uuid":"c84b6834-6bab-4087-a044-e61a1e3a391b","volumeTyp
>>e":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStore
>>TO":{"uuid":"c1ac7425-f6d2-3ada-b78a-b17faceb89ea","id":2,"poolType":"RBD
>>","host":"
>>
>>ceph.dev.int","path":"rbd1","port":6789}},"name":"ROOT-13","size":2729152
>>48,"path":"329df94f-4c30-4617-9fbd-440b76f08cde","volumeId":13,"vmName":"
>>r-13-VM","accountId":1,"format":"RAW","id":13,"hypervisorType":"KVM"}},"d
>>i
>>
>>skSeq":0,"type":"ROOT"}],"nics":[{"deviceId":0,"networkRateMbps":1000,"de
>>faultNic":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:0
>>0:01:74"
>>
>>,"dns1":"8.8.8.8","broadcastType":"Vlan","type":"Guest","broadcastUri":"v
>>lan://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":"Lin
>>kLocal","type":"Control","isSecurityGroupEnabled":false}]},"hostIp":"10.1
>>0.8.25","
>>
>>executeInSequence":false,"wait":0}},{"com.cloud.agent.api.check.CheckSshC
>>ommand":{"ip":"169.254.3.215","port":3922,"interval":6,"retries":100,"nam
>>e":"r-13-VM","wait":0}},{"com.cloud.agent.api.GetDomRVersionCmd":{"access
>>Details":{
>> "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
>>
>>
>>
>
Re: KVM/mem.overprovisioning.factor
Posted by Bharat Kumar <bh...@citrix.com>.
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 <di...@gmail.com>
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
>
>
>