[jira] [Assigned] (CLOUDSTACK-7989) [Automation]:test_ldap script execution is failing with cloudstackapi exception "
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rohit Yadav reassigned CLOUDSTACK-7989:
---
Assignee: Rohit Yadav
> [Automation]:test_ldap script execution is failing with cloudstackapi
> exception "
> -
>
> Key: CLOUDSTACK-7989
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7989
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.5.0
>Reporter: sadhu suresh
>Assignee: Rohit Yadav
>
> 1.configure the ldap values(AD based) in test_data.py
> 2.run the ldap sscript
> nosetests --with-marvin --marvin-config=sadhu_auto.cfg
> sadhu-git/cloudstack/test/integration/component/test_l
> dap.py
> actual result:
> testcase failed with below exception:
> Exception:
> ['Traceback (most recent call last):\n', ' File
> "C:\\Python27\\lib\\site-packages\\marvin\\cloudstackConnection.py", line
> 374, in marvinRequest\nraise self.__lastError\n',
> 'CloudstackAPIException: Execute cmd: login failed, due to: errorCode: 405,
> errorText:This is an authentication api, cannot be used directly\n']
> Traceback (most recent call last):
> File "C:\Python27\lib\site-packages\marvin\cloudstackConnection.py", line
> 374, in marvinRequest
> raise self.__lastError
> CloudstackAPIException: Execute cmd: login failed, due to: errorCode: 405,
> errorText:This is an authentication api, cannot be used directly
> est_01_addLdapConfiguration (integration.component.test_ldap.TestLdap):
> DEBUG: Sending GET Cmd : createAccount===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): localhost
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?username=test&account=test&domainid=1&firstname=test&lastname=t&email=sadhu%40sadhu.com&command=createAccount&accounttype=0&password=password&response=json
> HTTP/1.1" 200 None
> test_01_addLdapConfiguration (integration.component.test_ldap.TestLdap):
> DEBUG: Response : {primarystorageavailable : u'Unlimited', domain : u'ROOT',
> domainid : u'93519224-73d3-11e4-ae98-06f83c36', vpclimit : u'Unlimited',
> iplimit : u'Unlimited', volumelimit : u'Unlimited', memorytotal : 0,
> secondarystorageavailable : u'Unlimited', vmtotal : 0, cputotal : 0, vpctotal
> : 0, id : u'73826d47-afb2-449c-8cbb-d3fdf970e824', cpuavailable :
> u'Unlimited', snapshotlimit : u'Unlimited', networklimit : u'Unlimited',
> iptotal : 0, volumetotal : 0, projectlimit : u'Unlimited', state :
> u'enabled', networktotal : 0, accounttype : 0, networkavailable :
> u'Unlimited', primarystoragetotal : 0, templatelimit : u'Unlimited',
> snapshottotal : 0, templateavailable : u'Unlimited', vmlimit : u'Unlimited',
> vpcavailable : u'Unlimited', memoryavailable : u'Unlimited',
> secondarystoragetotal : 0, templatetotal : 0, projecttotal : 0, user :
> [{username : u'test', account : u'test', domainid :
> u'93519224-73d3-11e4-ae98-06f83c36', firstname : u'test', created :
> u'2014-11-28T03:33:36-0500', lastname : u't', domain : u'ROOT', id :
> u'd945726c-17ef-432e-a862-f3fa38910a04', iscallerchilddomain : False, state :
> u'enabled', accounttype : 0, email : u'sa...@sadhu.com', isdefault : False,
> accountid : u'73826d47-afb2-449c-8cbb-d3fdf970e824'}], groups : [],
> projectavailable : u'Unlimited', isdefault : False, primarystoragelimit :
> u'Unlimited', secondarystoragelimit : u'Unlimited', volumeavailable :
> u'Unlimited', name : u'test', vmavailable : u'Unlimited', ipavailable : u'8',
> memorylimit : u'Unlimited', cpulimit : u'Unlimited', snapshotavailable :
> u'Unlimited'}
> test_01_addLdapConfiguration (integration.component.test_ldap.TestLdap):
> DEBUG: start test
> test_01_addLdapConfiguration (integration.component.test_ldap.TestLdap):
> DEBUG: Payload: {'name': 'ldap.basedn', 'value': 'CN=Users,DC=hyd-qa,DC=com',
> 'command': 'updateConfiguration', 'response': 'json'}
> test_01_addLdapConfiguration (integration.component.test_ldap.TestLdap):
> DEBUG: Sending GET Cmd : updateConfiguration===
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): localhost
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?command=updateConfiguration&name=ldap.basedn&value=CN%3DUsers%2CDC%3Dhyd-qa%2CDC%3Dcom&response=json
> HTTP/1.1" 200 None
> test_01_addLdapConfiguration (integration.component.test_ldap.TestLdap):
> DEBUG: Response : {category : u'Secure', name : u'ldap.basedn', value :
> u'CN=Users,DC=hyd-qa,DC=com', description : u'Sets the basedn for LDAP'}
> test_01_addLdapConfiguration (integration.component.test_ldap.TestLdap):
> DEBUG: update
[jira] [Created] (CLOUDSTACK-7989) [Automation]:test_ldap script execution is failing with cloudstackapi exception "
sadhu suresh created CLOUDSTACK-7989:
Summary: [Automation]:test_ldap script execution is failing with
cloudstackapi exception "
Key: CLOUDSTACK-7989
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7989
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.5.0
Reporter: sadhu suresh
1.configure the ldap values(AD based) in test_data.py
2.run the ldap sscript
nosetests --with-marvin --marvin-config=sadhu_auto.cfg
sadhu-git/cloudstack/test/integration/component/test_l
dap.py
actual result:
testcase failed with below exception:
Exception:
['Traceback (most recent call last):\n', ' File
"C:\\Python27\\lib\\site-packages\\marvin\\cloudstackConnection.py", line 374,
in marvinRequest\nraise self.__lastError\n', 'CloudstackAPIException:
Execute cmd: login failed, due to: errorCode: 405, errorText:This is an
authentication api, cannot be used directly\n']
Traceback (most recent call last):
File "C:\Python27\lib\site-packages\marvin\cloudstackConnection.py", line
374, in marvinRequest
raise self.__lastError
CloudstackAPIException: Execute cmd: login failed, due to: errorCode: 405,
errorText:This is an authentication api, cannot be used directly
est_01_addLdapConfiguration (integration.component.test_ldap.TestLdap): DEBUG:
Sending GET Cmd : createAccount===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): localhost
requests.packages.urllib3.connectionpool: DEBUG: "GET
/client/api?username=test&account=test&domainid=1&firstname=test&lastname=t&email=sadhu%40sadhu.com&command=createAccount&accounttype=0&password=password&response=json
HTTP/1.1" 200 None
test_01_addLdapConfiguration (integration.component.test_ldap.TestLdap): DEBUG:
Response : {primarystorageavailable : u'Unlimited', domain : u'ROOT', domainid
: u'93519224-73d3-11e4-ae98-06f83c36', vpclimit : u'Unlimited', iplimit :
u'Unlimited', volumelimit : u'Unlimited', memorytotal : 0,
secondarystorageavailable : u'Unlimited', vmtotal : 0, cputotal : 0, vpctotal :
0, id : u'73826d47-afb2-449c-8cbb-d3fdf970e824', cpuavailable : u'Unlimited',
snapshotlimit : u'Unlimited', networklimit : u'Unlimited', iptotal : 0,
volumetotal : 0, projectlimit : u'Unlimited', state : u'enabled', networktotal
: 0, accounttype : 0, networkavailable : u'Unlimited', primarystoragetotal : 0,
templatelimit : u'Unlimited', snapshottotal : 0, templateavailable :
u'Unlimited', vmlimit : u'Unlimited', vpcavailable : u'Unlimited',
memoryavailable : u'Unlimited', secondarystoragetotal : 0, templatetotal : 0,
projecttotal : 0, user : [{username : u'test', account : u'test', domainid :
u'93519224-73d3-11e4-ae98-06f83c36', firstname : u'test', created :
u'2014-11-28T03:33:36-0500', lastname : u't', domain : u'ROOT', id :
u'd945726c-17ef-432e-a862-f3fa38910a04', iscallerchilddomain : False, state :
u'enabled', accounttype : 0, email : u'sa...@sadhu.com', isdefault : False,
accountid : u'73826d47-afb2-449c-8cbb-d3fdf970e824'}], groups : [],
projectavailable : u'Unlimited', isdefault : False, primarystoragelimit :
u'Unlimited', secondarystoragelimit : u'Unlimited', volumeavailable :
u'Unlimited', name : u'test', vmavailable : u'Unlimited', ipavailable : u'8',
memorylimit : u'Unlimited', cpulimit : u'Unlimited', snapshotavailable :
u'Unlimited'}
test_01_addLdapConfiguration (integration.component.test_ldap.TestLdap): DEBUG:
start test
test_01_addLdapConfiguration (integration.component.test_ldap.TestLdap): DEBUG:
Payload: {'name': 'ldap.basedn', 'value': 'CN=Users,DC=hyd-qa,DC=com',
'command': 'updateConfiguration', 'response': 'json'}
test_01_addLdapConfiguration (integration.component.test_ldap.TestLdap): DEBUG:
Sending GET Cmd : updateConfiguration===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): localhost
requests.packages.urllib3.connectionpool: DEBUG: "GET
/client/api?command=updateConfiguration&name=ldap.basedn&value=CN%3DUsers%2CDC%3Dhyd-qa%2CDC%3Dcom&response=json
HTTP/1.1" 200 None
test_01_addLdapConfiguration (integration.component.test_ldap.TestLdap): DEBUG:
Response : {category : u'Secure', name : u'ldap.basedn', value :
u'CN=Users,DC=hyd-qa,DC=com', description : u'Sets the basedn for LDAP'}
test_01_addLdapConfiguration (integration.component.test_ldap.TestLdap): DEBUG:
updated the parameter ldap.basedn with value CN=Users,DC=hyd-qa,DC=com
test_01_addLdapConfiguration (integration.component.test_ldap.TestLdap): DEBUG:
Payload: {'name': 'ldap.email.attribute', 'value': 'mail', 'command':
'updateConfiguration', 'response': 'json'}
test_01_addLdapConfiguration (integration.component.test_ldap.TestLdap): DEBUG:
Sending GET Cmd : updateConfiguration===
requests.pa
[jira] [Commented] (CLOUDSTACK-7988) Template status is empty while the template is creating.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14228050#comment-14228050 ] Pierre-Luc Dion commented on CLOUDSTACK-7988: - Work fine when template is from URL, look like it append when creating template from snapshot or root disk. > Template status is empty while the template is creating. > > > Key: CLOUDSTACK-7988 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7988 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.1, 4.4.2 >Reporter: Pierre-Luc Dion >Priority: Minor > > Once the Template is created and is downloading, the status attribute of the > template is empty until the template is ready. usually the status indicate > the "% downloaded" or "Installing template". > the status was working in 4.4.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7988) Template status is empty while the template is creating.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14228045#comment-14228045 ] Pierre-Luc Dion commented on CLOUDSTACK-7988: - also observed on 4.4.2 while running SSVM at 4.4.0 and 4.4.1 version. > Template status is empty while the template is creating. > > > Key: CLOUDSTACK-7988 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7988 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.1, 4.4.2 >Reporter: Pierre-Luc Dion >Priority: Minor > > Once the Template is created and is downloading, the status attribute of the > template is empty until the template is ready. usually the status indicate > the "% downloaded" or "Installing template". > the status was working in 4.4.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7988) Template status is empty while the template is creating.
Pierre-Luc Dion created CLOUDSTACK-7988: --- Summary: Template status is empty while the template is creating. Key: CLOUDSTACK-7988 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7988 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.1, 4.4.2 Reporter: Pierre-Luc Dion Priority: Minor Once the Template is created and is downloading, the status attribute of the template is empty until the template is ready. usually the status indicate the % downloaded or "Installing template". the status was working in 4.4.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7988) Template status is empty while the template is creating.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14228044#comment-14228044 ] Pierre-Luc Dion commented on CLOUDSTACK-7988: - This is observed in the UI and API. > Template status is empty while the template is creating. > > > Key: CLOUDSTACK-7988 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7988 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.1, 4.4.2 >Reporter: Pierre-Luc Dion >Priority: Minor > > Once the Template is created and is downloading, the status attribute of the > template is empty until the template is ready. usually the status indicate > the % downloaded or "Installing template". > the status was working in 4.4.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7988) Template status is empty while the template is creating.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7988: Description: Once the Template is created and is downloading, the status attribute of the template is empty until the template is ready. usually the status indicate the "% downloaded" or "Installing template". the status was working in 4.4.0. was: Once the Template is created and is downloading, the status attribute of the template is empty until the template is ready. usually the status indicate the % downloaded or "Installing template". the status was working in 4.4.0. > Template status is empty while the template is creating. > > > Key: CLOUDSTACK-7988 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7988 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.1, 4.4.2 >Reporter: Pierre-Luc Dion >Priority: Minor > > Once the Template is created and is downloading, the status attribute of the > template is empty until the template is ready. usually the status indicate > the "% downloaded" or "Installing template". > the status was working in 4.4.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6893) systemvms can not start on KVM host
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227778#comment-14227778
]
ASF subversion and git services commented on CLOUDSTACK-6893:
-
Commit 9928d66fdaf71b43412e20b129975c42e0552d6f in cloudstack's branch
refs/heads/4.5 from [~weizhou]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9928d66 ]
CLOUDSTACK-6893: fix enum ValueOf issue which causes systemvm fail to start
(cherry picked from commit 63ff5a7cbc3341809884e47796476d47ace03961)
(cherry picked from commit d0e0edca111feb71e7cd8267d9c28820d85b12f9)
> systemvms can not start on KVM host
> ---
>
> Key: CLOUDSTACK-6893
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6893
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> After upgrading from 4.3 to 4.4, the systemvms can not start with the
> following error logs:
> 2014-06-11 13:39:42,119 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-4:null) Request:Seq 2-8064539557737005074: { Cmd ,
> MgmtId: 345051514000, via: 2, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.StartCommand":{"vm":{"id":216,"name":"s-216-VM","type":"SecondaryStorageVm","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"arch":"x86_64","os":"Debian
> GNU/Linux 5.0 (64-bit)","platformEmulator":"Debian GNU/Linux 5","bootArgs":"
> template=domP type=secstorage host=172.16.15.10 port=8250 name=s-216-VM
> zone=1 pod=1 guid=s-216-VM
> resource=org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource
> instance=SecStorage sslcopy=false role=templateProcessor mtu=1500
> eth2ip=10.11.115.115 eth2mask=255.255.255.0 gateway=10.11.115.254
> public.network.device=eth2 eth0ip=169.254.1.127 eth0mask=255.255.0.0
> eth1ip=172.16.15.38 eth1mask=255.255.255.0 mgmtcidr=10.11.115.0/24
> localgw=172.16.15.254 private.network.device=eth1 eth3ip=172.16.15.41
> eth3mask=255.255.255.0 storageip=172.16.15.41 storagenetmask=255.255.255.0
> storagegateway=172.16.15.254 internaldns1=8.8.8.8 internaldns2=8.8.4.4
> dns1=8.8.8.8
> dns2=8.8.4.4","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"3bbd718218d5602b","params":{},"uuid":"198324f1-aeba-4fae-adad-4ffc087b2f3a","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"0d65d238-a753-48da-b1d6-638fa533eb67","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e","id":2,"poolType":"NetworkFilesystem","host":"172.16.15.254","path":"/storage/cs-115-pri","port":2049,"url":"NetworkFilesystem://172.16.15.254/storage/cs-115-pri/?ROLE=Primary&STOREUUID=1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e"}},"name":"ROOT-216","size":297230848,"path":"0d65d238-a753-48da-b1d6-638fa533eb67","volumeId":214,"vmName":"s-216-VM","accountId":1,"format":"QCOW2","id":214,"deviceId":0,"cacheMode":"NONE","hypervisorType":"KVM"}},"diskSeq":0,"path":"0d65d238-a753-48da-b1d6-638fa533eb67","type":"ROOT","_details":{"managed":"false","storagePort":"2049","storageHost":"172.16.15.254","volumeSize":"297230848"}}],"nics":[{"deviceId":2,"networkRateMbps":-1,"defaultNic":true,"uuid":"765b43a0-43f7-4b23-abcc-86ccc6197a0e","ip":"10.11.115.115","netmask":"255.255.255.0","gateway":"10.11.115.254","mac":"06:78:16:00:00:1a","dns1":"8.8.8.8","dns2":"8.8.4.4","broadcastType":"Vlan","type":"Public","broadcastUri":"vlan://115","isolationUri":"vlan://115","isSecurityGroupEnabled":false,"name":"cloudbr0"},{"deviceId":0,"networkRateMbps":-1,"defaultNic":false,"uuid":"dc8a1a58-e581-49a2-8377-dc4fba1dfa57","ip":"169.254.1.127","netmask":"255.255.0.0","gateway":"169.254.0.1","mac":"0e:00:a9:fe:01:7f","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false},{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"uuid":"81b10433-e67c-4052-8664-3bfccdb1c9cf","ip":"172.16.15.38","netmask":"255.255.255.0","gateway":"172.16.15.254","mac":"06:11:c4:00:00:09","broadcastType":"Native","type":"Management","isSecurityGroupEnabled":false,"name":"cloudbr1"},{"deviceId":3,"networkRateMbps":-1,"defaultNic":false,"uuid":"cdcd5757-04df-4b19-a314-f73b314778b2","ip":"172.16.15.41","netmask":"255.255.255.0","gateway":"172.16.15.254","mac":"06:ee:96:00:00:70","broadcastType":"Storage","type":"Storage","isSecurityGroupEnabled":false,"name":"cloudbr1"}]},"hostIp":"172.16.15.15","executeInSequence":false,"wait":0}},{"com.cloud.agent.api.check.CheckSshCommand":{"ip":"169.254.1.127","port":3922,"interval":6,"retries":100,"name":"s-216-VM","wait":0}}]
> }
> 2014-06-11 13:39:42,119 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-4:null) Processing command:
[jira] [Commented] (CLOUDSTACK-6893) systemvms can not start on KVM host
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227775#comment-14227775
]
ASF subversion and git services commented on CLOUDSTACK-6893:
-
Commit daa57f67d63050202487ca672b230713fc2f0bcc in cloudstack's branch
refs/heads/master from [~weizhou]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=daa57f6 ]
CLOUDSTACK-6893: fix enum ValueOf issue which causes systemvm fail to start
(cherry picked from commit 63ff5a7cbc3341809884e47796476d47ace03961)
(cherry picked from commit d0e0edca111feb71e7cd8267d9c28820d85b12f9)
> systemvms can not start on KVM host
> ---
>
> Key: CLOUDSTACK-6893
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6893
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>
> After upgrading from 4.3 to 4.4, the systemvms can not start with the
> following error logs:
> 2014-06-11 13:39:42,119 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-4:null) Request:Seq 2-8064539557737005074: { Cmd ,
> MgmtId: 345051514000, via: 2, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.StartCommand":{"vm":{"id":216,"name":"s-216-VM","type":"SecondaryStorageVm","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"arch":"x86_64","os":"Debian
> GNU/Linux 5.0 (64-bit)","platformEmulator":"Debian GNU/Linux 5","bootArgs":"
> template=domP type=secstorage host=172.16.15.10 port=8250 name=s-216-VM
> zone=1 pod=1 guid=s-216-VM
> resource=org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource
> instance=SecStorage sslcopy=false role=templateProcessor mtu=1500
> eth2ip=10.11.115.115 eth2mask=255.255.255.0 gateway=10.11.115.254
> public.network.device=eth2 eth0ip=169.254.1.127 eth0mask=255.255.0.0
> eth1ip=172.16.15.38 eth1mask=255.255.255.0 mgmtcidr=10.11.115.0/24
> localgw=172.16.15.254 private.network.device=eth1 eth3ip=172.16.15.41
> eth3mask=255.255.255.0 storageip=172.16.15.41 storagenetmask=255.255.255.0
> storagegateway=172.16.15.254 internaldns1=8.8.8.8 internaldns2=8.8.4.4
> dns1=8.8.8.8
> dns2=8.8.4.4","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"3bbd718218d5602b","params":{},"uuid":"198324f1-aeba-4fae-adad-4ffc087b2f3a","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"0d65d238-a753-48da-b1d6-638fa533eb67","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e","id":2,"poolType":"NetworkFilesystem","host":"172.16.15.254","path":"/storage/cs-115-pri","port":2049,"url":"NetworkFilesystem://172.16.15.254/storage/cs-115-pri/?ROLE=Primary&STOREUUID=1dcbc42c-99bc-3276-9d86-4ad81ef1ad8e"}},"name":"ROOT-216","size":297230848,"path":"0d65d238-a753-48da-b1d6-638fa533eb67","volumeId":214,"vmName":"s-216-VM","accountId":1,"format":"QCOW2","id":214,"deviceId":0,"cacheMode":"NONE","hypervisorType":"KVM"}},"diskSeq":0,"path":"0d65d238-a753-48da-b1d6-638fa533eb67","type":"ROOT","_details":{"managed":"false","storagePort":"2049","storageHost":"172.16.15.254","volumeSize":"297230848"}}],"nics":[{"deviceId":2,"networkRateMbps":-1,"defaultNic":true,"uuid":"765b43a0-43f7-4b23-abcc-86ccc6197a0e","ip":"10.11.115.115","netmask":"255.255.255.0","gateway":"10.11.115.254","mac":"06:78:16:00:00:1a","dns1":"8.8.8.8","dns2":"8.8.4.4","broadcastType":"Vlan","type":"Public","broadcastUri":"vlan://115","isolationUri":"vlan://115","isSecurityGroupEnabled":false,"name":"cloudbr0"},{"deviceId":0,"networkRateMbps":-1,"defaultNic":false,"uuid":"dc8a1a58-e581-49a2-8377-dc4fba1dfa57","ip":"169.254.1.127","netmask":"255.255.0.0","gateway":"169.254.0.1","mac":"0e:00:a9:fe:01:7f","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false},{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"uuid":"81b10433-e67c-4052-8664-3bfccdb1c9cf","ip":"172.16.15.38","netmask":"255.255.255.0","gateway":"172.16.15.254","mac":"06:11:c4:00:00:09","broadcastType":"Native","type":"Management","isSecurityGroupEnabled":false,"name":"cloudbr1"},{"deviceId":3,"networkRateMbps":-1,"defaultNic":false,"uuid":"cdcd5757-04df-4b19-a314-f73b314778b2","ip":"172.16.15.41","netmask":"255.255.255.0","gateway":"172.16.15.254","mac":"06:ee:96:00:00:70","broadcastType":"Storage","type":"Storage","isSecurityGroupEnabled":false,"name":"cloudbr1"}]},"hostIp":"172.16.15.15","executeInSequence":false,"wait":0}},{"com.cloud.agent.api.check.CheckSshCommand":{"ip":"169.254.1.127","port":3922,"interval":6,"retries":100,"name":"s-216-VM","wait":0}}]
> }
> 2014-06-11 13:39:42,119 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-4:null) Processing command
[jira] [Created] (CLOUDSTACK-7987) tpaidasta
jani hynninen created CLOUDSTACK-7987: - Summary: tpaidasta Key: CLOUDSTACK-7987 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7987 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Reporter: jani hynninen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5863) Restore volume snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227633#comment-14227633 ] Nux commented on CLOUDSTACK-5863: - Awesome, I'll be waiting, ready to test! > Restore volume snapshot > --- > > Key: CLOUDSTACK-5863 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5863 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot > Environment: KVM, EL6, QCOW2 >Reporter: Nux >Assignee: Wei Zhou > Labels: backup, kvm, restore, snapshot, volumes > Fix For: 4.6.0 > > > Hello, > Just as users can create backups of volumes, they should be able to restore > said volumes from them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5863) Restore volume snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227626#comment-14227626 ] Wei Zhou commented on CLOUDSTACK-5863: -- Nux, I will made it work in upstream at first, then let's see if it is working in 4.5 as well. > Restore volume snapshot > --- > > Key: CLOUDSTACK-5863 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5863 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot > Environment: KVM, EL6, QCOW2 >Reporter: Nux >Assignee: Wei Zhou > Labels: backup, kvm, restore, snapshot, volumes > Fix For: 4.6.0 > > > Hello, > Just as users can create backups of volumes, they should be able to restore > said volumes from them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5863) Restore volume snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227621#comment-14227621 ] Nux commented on CLOUDSTACK-5863: - Wei, No way to sneak this in 4.5? > Restore volume snapshot > --- > > Key: CLOUDSTACK-5863 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5863 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot > Environment: KVM, EL6, QCOW2 >Reporter: Nux >Assignee: Wei Zhou > Labels: backup, kvm, restore, snapshot, volumes > Fix For: 4.6.0 > > > Hello, > Just as users can create backups of volumes, they should be able to restore > said volumes from them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7320) [LXC] Provide default centos template for lxc
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227607#comment-14227607 ] ASF subversion and git services commented on CLOUDSTACK-7320: - Commit 807bfb03e78205088fc77abdff2edbe6922a724d in cloudstack's branch refs/heads/4.5 from [~kishan] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=807bfb0 ] CLOUDSTACK-7320: Added default CentOS 7 template for LXC Conflicts: setup/db/db/schema-442to450.sql > [LXC] Provide default centos template for lxc > -- > > Key: CLOUDSTACK-7320 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7320 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala > Fix For: 4.5.0 > > > We generally provide default template with all our hypervisor support . > similarly we need to provide a default template for LXC as well -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7986) [F5 LB] Failed to execute IPAssocCommand due to com.cloud.utils.exception.ExecutionException: Exception caught in Networking::urn:iControl:Networking/VLAN::create(
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227594#comment-14227594
]
Sudhansu Sahu commented on CLOUDSTACK-7986:
---
Seems like the list VLAN api response has been modified in 11.x.
After analyzing the logs, I found that the VLAN creation is succesful, but
there is a logic which verifies the VLAN creation (see the code snippet below).
_vlanApi.create(vlanNames, vlanTags, vlanMemberEntries,
commonEnabledState, new long[]{10L}, new String[]{"00:00:00:00:00:00"});
if (!getVlans().contains(vlanName)) {
throw new ExecutionException("Failed to create vlan
with tag " + vlanTag);
}
SOAP result for getVlans() is:
{noformat}
/Common/vlan-902
/Common/vlan-905
/Common/vlan-906
/Common/vlan-904
/Common/vlan-903
/Common/vlan44
/Common/vlan-908
/Common/vlan-910
/Common/vlan-900
{noformat}
we are looking for vlanName: vlan-906 in this list. which is not in the list
(valan is prefixed with the partion name "/Common/")
As it was working 10.x so the list VLAN response might have been modified in
11.x. Now all VLANs are prefixed with the partition / path info.
> [F5 LB] Failed to execute IPAssocCommand due to
> com.cloud.utils.exception.ExecutionException: Exception caught in
> Networking::urn:iControl:Networking/VLAN::create()
>
>
> Key: CLOUDSTACK-7986
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7986
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Devices
>Affects Versions: 4.3.0, 4.4.0, 4.5.0
> Environment: Red Hat Enterprise Linux Server release 6.3 (Santiago)
> IG-IP 11.3.0 Build 39.0 VE Trial 11.3.0-HF1 (based on BIGIP 11.3.0HF6)
>Reporter: Sudhansu Sahu
>
> When trying to launch a VM on a network that uses the network offering (with
> LB provided by the F5) the following errors are observed in the logs and the
> creation ultimately fails:
> {noformat}
> 71831 2014-11-26 12:19:34,403 DEBUG
> [c.c.n.ExternalLoadBalancerDeviceManagerImpl]
> (Work-Job-Executor-133:ctx-434a0b57 job-269/job-270 ctx-cd8df97f) Allocated
> external load balancer device:1 for the network: 205
> 71832 2014-11-26 12:19:34,428 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-133:ctx-434a0b57 job-269/job-270 ctx-cd8df97f) Seq
> 4-5343239482898383377: Sending { Cmd , MgmtId: 7407677735140, via:
> 4(200-F5BigIpLoadBalancer-10.147.60.5 1), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.routing.IpAssocCommand":{"ipAddresses":[{"accountId":2,"sourceNat":true,"add":true,"oneToOneNat":false,"firstIP":false,"broadcastUri":"910","vlanGateway":"10.0.160.37","vla
>
> nNetmask":"255.255.240.0","networkRate":200,"newNic":false}],"accessDetails":{},"wait":0}}]
> }
> 71833 2014-11-26 12:19:34,429 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-133:ctx-434a0b57 job-269/job-270 ctx-cd8df97f) Seq
> 4-5343239482898383377: Executing: { Cmd , MgmtId: 7407677735140, via:
> 4(200-F5BigIpLoadBalancer-10.147.6 0.51), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.routing.IpAssocCommand":{"ipAddresses":[{"accountId":2,"sourceNat":true,"add":true,"oneToOneNat":false,"firstIP":false,"broadcastUri":"910","vlanGateway":"10.0.160.37","
>
> vlanNetmask":"255.255.240.0","networkRate":200,"newNic":false}],"accessDetails":{},"wait":0}}]
> }
> 71834 2014-11-26 12:19:34,429 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-217:ctx-40025c4d) Seq 4-5343239482898383377: Executing request
> 71835 2014-11-26 12:19:34,731 DEBUG [c.c.n.r.F5BigIpResource]
> (DirectAgent-217:ctx-40025c4d) Creating a guest VLAN with tag 910
> 71836 2014-11-26 12:19:35,616 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-19:ctx-6bfff176) ===START=== 10.252.192.47 -- GET
> command=queryAsyncJobResult&jobId=33e182fe-ab28-470c-a483-a16bd40e05d9&response=json&sessionkey=cUbJKOPdiHo
>sLJ06cqS8y66FEMU%3D&_=1416984574574
> 71837 2014-11-26 12:19:35,711 ERROR [c.c.n.r.F5BigIpResource]
> (DirectAgent-217:ctx-40025c4d) Failed to execute IPAssocCommand due to
> com.cloud.utils.exception.ExecutionException: Failed to create vlan with tag
> 910
> 71838 2014-11-26 12:19:35,734 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-19:ctx-6bfff176 ctx-f76b168b) ===END=== 10.252.192.47 -- GET
> command=queryAsyncJobResult&jobId=33e182fe-ab28-470c-a483-a16bd40e05d9&response=json&sessionkey=
>cUbJKOPdiHosLJ06cqS8y66FEMU%3D&_=1416984574574
> 71839 2014-11-26 12:19:35,842 ERROR [c.c.n.r.F5BigIpResource]
> (DirectAgent-217:ctx-40025c4d) Retrying IpAs
[jira] [Created] (CLOUDSTACK-7986) [F5 LB] Failed to execute IPAssocCommand due to com.cloud.utils.exception.ExecutionException: Exception caught in Networking::urn:iControl:Networking/VLAN::create()
Sudhansu Sahu created CLOUDSTACK-7986:
-
Summary: [F5 LB] Failed to execute IPAssocCommand due to
com.cloud.utils.exception.ExecutionException: Exception caught in
Networking::urn:iControl:Networking/VLAN::create()
Key: CLOUDSTACK-7986
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7986
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Network Devices
Affects Versions: 4.4.0, 4.3.0, 4.5.0
Environment: Red Hat Enterprise Linux Server release 6.3 (Santiago)
IG-IP 11.3.0 Build 39.0 VE Trial 11.3.0-HF1 (based on BIGIP 11.3.0HF6)
Reporter: Sudhansu Sahu
When trying to launch a VM on a network that uses the network offering (with LB
provided by the F5) the following errors are observed in the logs and the
creation ultimately fails:
{noformat}
71831 2014-11-26 12:19:34,403 DEBUG
[c.c.n.ExternalLoadBalancerDeviceManagerImpl]
(Work-Job-Executor-133:ctx-434a0b57 job-269/job-270 ctx-cd8df97f) Allocated
external load balancer device:1 for the network: 205
71832 2014-11-26 12:19:34,428 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-133:ctx-434a0b57 job-269/job-270 ctx-cd8df97f) Seq
4-5343239482898383377: Sending { Cmd , MgmtId: 7407677735140, via:
4(200-F5BigIpLoadBalancer-10.147.60.5 1), Ver: v1, Flags: 100011,
[{"com.cloud.agent.api.routing.IpAssocCommand":{"ipAddresses":[{"accountId":2,"sourceNat":true,"add":true,"oneToOneNat":false,"firstIP":false,"broadcastUri":"910","vlanGateway":"10.0.160.37","vla
nNetmask":"255.255.240.0","networkRate":200,"newNic":false}],"accessDetails":{},"wait":0}}]
}
71833 2014-11-26 12:19:34,429 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-133:ctx-434a0b57 job-269/job-270 ctx-cd8df97f) Seq
4-5343239482898383377: Executing: { Cmd , MgmtId: 7407677735140, via:
4(200-F5BigIpLoadBalancer-10.147.6 0.51), Ver: v1, Flags: 100011,
[{"com.cloud.agent.api.routing.IpAssocCommand":{"ipAddresses":[{"accountId":2,"sourceNat":true,"add":true,"oneToOneNat":false,"firstIP":false,"broadcastUri":"910","vlanGateway":"10.0.160.37","
vlanNetmask":"255.255.240.0","networkRate":200,"newNic":false}],"accessDetails":{},"wait":0}}]
}
71834 2014-11-26 12:19:34,429 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-217:ctx-40025c4d) Seq 4-5343239482898383377: Executing request
71835 2014-11-26 12:19:34,731 DEBUG [c.c.n.r.F5BigIpResource]
(DirectAgent-217:ctx-40025c4d) Creating a guest VLAN with tag 910
71836 2014-11-26 12:19:35,616 DEBUG [c.c.a.ApiServlet]
(catalina-exec-19:ctx-6bfff176) ===START=== 10.252.192.47 -- GET
command=queryAsyncJobResult&jobId=33e182fe-ab28-470c-a483-a16bd40e05d9&response=json&sessionkey=cUbJKOPdiHo
sLJ06cqS8y66FEMU%3D&_=1416984574574
71837 2014-11-26 12:19:35,711 ERROR [c.c.n.r.F5BigIpResource]
(DirectAgent-217:ctx-40025c4d) Failed to execute IPAssocCommand due to
com.cloud.utils.exception.ExecutionException: Failed to create vlan with tag 910
71838 2014-11-26 12:19:35,734 DEBUG [c.c.a.ApiServlet]
(catalina-exec-19:ctx-6bfff176 ctx-f76b168b) ===END=== 10.252.192.47 -- GET
command=queryAsyncJobResult&jobId=33e182fe-ab28-470c-a483-a16bd40e05d9&response=json&sessionkey=
cUbJKOPdiHosLJ06cqS8y66FEMU%3D&_=1416984574574
71839 2014-11-26 12:19:35,842 ERROR [c.c.n.r.F5BigIpResource]
(DirectAgent-217:ctx-40025c4d) Retrying IpAssocCommand. Number of retries
remaining: 1
71840 2014-11-26 12:19:36,053 DEBUG [c.c.n.r.F5BigIpResource]
(DirectAgent-217:ctx-40025c4d) Creating a guest VLAN with tag 910
71841 2014-11-26 12:19:36,233 ERROR [c.c.n.r.F5BigIpResource]
(DirectAgent-217:ctx-40025c4d) Exception caught in
Networking::urn:iControl:Networking/VLAN::create()
71842 Exception: Common::OperationFailed
71843 primary_error_code : 16908390 (0x01020066)
71844 secondary_error_code : 0
71845 error_string : 01020066:3: The requested VLAN
(/Common/vlan-910) already exists in partition Common.
71846 2014-11-26 12:19:36,234 ERROR [c.c.n.r.F5BigIpResource]
(DirectAgent-217:ctx-40025c4d) Failed to execute IPAssocCommand due to
com.cloud.utils.exception.ExecutionException: Exception caught in
Networking::urn:iControl:Netwo rking/VLAN::create()
71847 Exception: Common::OperationFailed
71848 primary_error_code : 16908390 (0x01020066)
71849 secondary_error_code : 0
71850 error_string : 01020066:3: The requested VLAN
(/Common/vlan-910) already exists in partition Common.
71851 2014-11-26 12:19:36,318 ERROR [c.c.n.r.F5BigIpResource]
(DirectAgent-217:ctx-40025c4d) Retrying IpAssocCommand. Number of retries
remaining: 0
71852 2014-11-26 12:19:36,529 DEBUG [c.c.n.r.F5BigIpResource]
(DirectAgent-217:ctx-40025c4d) Creating a guest VLAN with tag 910
71853 2014-11-26 12:19:36,562 ERROR [c.c.n.r.F5BigIpResource]
(DirectAgent-21
[jira] [Updated] (CLOUDSTACK-7412) Can't create proper template from VM on S3 secondary storage environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-7412: Affects Version/s: (was: Future) > Can't create proper template from VM on S3 secondary storage environment > > > Key: CLOUDSTACK-7412 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Template >Affects Versions: 4.2.1, 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3.0 on CentOS 6.5. > KVM Hypervisor. > using S3 provider as socondary storage. The storage system is using RADOS. > using local storage as primary storage. >Reporter: Akihiko Ota >Assignee: Akihiko Ota > Fix For: 4.5.0, 4.6.0, 4.4.3, 4.3.2 > > > When I create more than one templates from an existing virtual machine, the > second and the subsequent template is created the same as first one. > It doesn't occur in the case of using NFS secondary storage. So I guess this > is the S3 provider specific issue. > This could reproduce as following procedure. > (1) create a virtual machine (name "foo" tentatively), and modify some files > on ROOT volume of "foo". > (2) stop "foo". and create template "template-foo.1" from ROOT volume of > "foo". > (3) reboot (not re-create) "foo", and modify some files on ROOT volume again. > (4) stop "foo". and create template "template-foo.2" from ROOT volume of > "foo". > I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the > same as template-foo.1. (3)'s changes are not recorded. > As of (4), CloudStack outputs the following DEBUG message to > cloudstack-management.log. > 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl] > (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache > store > When creating templates on NFS secondary storage environment, this message is > not output. > This issue also exists on CloudStack 4.2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7412) Can't create proper template from VM on S3 secondary storage environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi resolved CLOUDSTACK-7412. - Resolution: Fixed > Can't create proper template from VM on S3 secondary storage environment > > > Key: CLOUDSTACK-7412 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Template >Affects Versions: Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3.0 on CentOS 6.5. > KVM Hypervisor. > using S3 provider as socondary storage. The storage system is using RADOS. > using local storage as primary storage. >Reporter: Akihiko Ota >Assignee: Akihiko Ota > Fix For: 4.5.0, 4.6.0, 4.4.3, 4.3.2 > > > When I create more than one templates from an existing virtual machine, the > second and the subsequent template is created the same as first one. > It doesn't occur in the case of using NFS secondary storage. So I guess this > is the S3 provider specific issue. > This could reproduce as following procedure. > (1) create a virtual machine (name "foo" tentatively), and modify some files > on ROOT volume of "foo". > (2) stop "foo". and create template "template-foo.1" from ROOT volume of > "foo". > (3) reboot (not re-create) "foo", and modify some files on ROOT volume again. > (4) stop "foo". and create template "template-foo.2" from ROOT volume of > "foo". > I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the > same as template-foo.1. (3)'s changes are not recorded. > As of (4), CloudStack outputs the following DEBUG message to > cloudstack-management.log. > 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl] > (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache > store > When creating templates on NFS secondary storage environment, this message is > not output. > This issue also exists on CloudStack 4.2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7981) listVirtualMachine is too slow in case of duplicate resource tags due to joining user_vm_details to user_vm_view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227555#comment-14227555 ] Rohit Yadav commented on CLOUDSTACK-7981: - Hi [~minchen07], does this need to be backported to 4.2, 4.3, 4.4 branches? We can simply add an idempotent upgrade path in the java upgrade class. > listVirtualMachine is too slow in case of duplicate resource tags due to > joining user_vm_details to user_vm_view > > > Key: CLOUDSTACK-7981 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7981 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.2.1 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.5.0 > > > Deploy 40 to 50 VMs, each one has 3-4 resource tags, and each one also add > about 10 details, then do a listVMCmd, the performance is very slow. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7412) Can't create proper template from VM on S3 secondary storage environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227551#comment-14227551 ] ASF subversion and git services commented on CLOUDSTACK-7412: - Commit 9d31e59d5b54ef64475e6e8ea36c3e2fc2e7f379 in cloudstack's branch refs/heads/master from [~hiroki-o] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9d31e59 ] CLOUDSTACK-7412: Can't create proper template from VM on S3 secondary storage environment Signed-off-by: Rajani Karuturi > Can't create proper template from VM on S3 secondary storage environment > > > Key: CLOUDSTACK-7412 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Template >Affects Versions: Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3.0 on CentOS 6.5. > KVM Hypervisor. > using S3 provider as socondary storage. The storage system is using RADOS. > using local storage as primary storage. >Reporter: Akihiko Ota >Assignee: Akihiko Ota > Fix For: 4.5.0, 4.6.0, 4.4.3, 4.3.2 > > > When I create more than one templates from an existing virtual machine, the > second and the subsequent template is created the same as first one. > It doesn't occur in the case of using NFS secondary storage. So I guess this > is the S3 provider specific issue. > This could reproduce as following procedure. > (1) create a virtual machine (name "foo" tentatively), and modify some files > on ROOT volume of "foo". > (2) stop "foo". and create template "template-foo.1" from ROOT volume of > "foo". > (3) reboot (not re-create) "foo", and modify some files on ROOT volume again. > (4) stop "foo". and create template "template-foo.2" from ROOT volume of > "foo". > I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the > same as template-foo.1. (3)'s changes are not recorded. > As of (4), CloudStack outputs the following DEBUG message to > cloudstack-management.log. > 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl] > (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache > store > When creating templates on NFS secondary storage environment, this message is > not output. > This issue also exists on CloudStack 4.2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7412) Can't create proper template from VM on S3 secondary storage environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227549#comment-14227549 ] ASF subversion and git services commented on CLOUDSTACK-7412: - Commit 0f8f6eff2c6e17594d042a3b9009e1c3a0c56aa6 in cloudstack's branch refs/heads/4.5 from [~hiroki-o] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0f8f6ef ] CLOUDSTACK-7412: Can't create proper template from VM on S3 secondary storage environment Signed-off-by: Rajani Karuturi > Can't create proper template from VM on S3 secondary storage environment > > > Key: CLOUDSTACK-7412 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Template >Affects Versions: Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3.0 on CentOS 6.5. > KVM Hypervisor. > using S3 provider as socondary storage. The storage system is using RADOS. > using local storage as primary storage. >Reporter: Akihiko Ota >Assignee: Akihiko Ota > Fix For: 4.5.0, 4.6.0, 4.4.3, 4.3.2 > > > When I create more than one templates from an existing virtual machine, the > second and the subsequent template is created the same as first one. > It doesn't occur in the case of using NFS secondary storage. So I guess this > is the S3 provider specific issue. > This could reproduce as following procedure. > (1) create a virtual machine (name "foo" tentatively), and modify some files > on ROOT volume of "foo". > (2) stop "foo". and create template "template-foo.1" from ROOT volume of > "foo". > (3) reboot (not re-create) "foo", and modify some files on ROOT volume again. > (4) stop "foo". and create template "template-foo.2" from ROOT volume of > "foo". > I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the > same as template-foo.1. (3)'s changes are not recorded. > As of (4), CloudStack outputs the following DEBUG message to > cloudstack-management.log. > 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl] > (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache > store > When creating templates on NFS secondary storage environment, this message is > not output. > This issue also exists on CloudStack 4.2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7412) Can't create proper template from VM on S3 secondary storage environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227547#comment-14227547 ] ASF subversion and git services commented on CLOUDSTACK-7412: - Commit d15033675b05a116905d5b19c697a1ef7bf52aaf in cloudstack's branch refs/heads/4.4 from [~hiroki-o] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d150336 ] CLOUDSTACK-7412: Can't create proper template from VM on S3 secondary storage environment Signed-off-by: Rajani Karuturi > Can't create proper template from VM on S3 secondary storage environment > > > Key: CLOUDSTACK-7412 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Template >Affects Versions: Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3.0 on CentOS 6.5. > KVM Hypervisor. > using S3 provider as socondary storage. The storage system is using RADOS. > using local storage as primary storage. >Reporter: Akihiko Ota >Assignee: Akihiko Ota > Fix For: 4.5.0, 4.6.0, 4.4.3, 4.3.2 > > > When I create more than one templates from an existing virtual machine, the > second and the subsequent template is created the same as first one. > It doesn't occur in the case of using NFS secondary storage. So I guess this > is the S3 provider specific issue. > This could reproduce as following procedure. > (1) create a virtual machine (name "foo" tentatively), and modify some files > on ROOT volume of "foo". > (2) stop "foo". and create template "template-foo.1" from ROOT volume of > "foo". > (3) reboot (not re-create) "foo", and modify some files on ROOT volume again. > (4) stop "foo". and create template "template-foo.2" from ROOT volume of > "foo". > I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the > same as template-foo.1. (3)'s changes are not recorded. > As of (4), CloudStack outputs the following DEBUG message to > cloudstack-management.log. > 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl] > (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache > store > When creating templates on NFS secondary storage environment, this message is > not output. > This issue also exists on CloudStack 4.2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7412) Can't create proper template from VM on S3 secondary storage environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227544#comment-14227544 ] ASF subversion and git services commented on CLOUDSTACK-7412: - Commit 0e0827f07c47289dc210dd50551c4c6df26d0573 in cloudstack's branch refs/heads/4.3 from [~hiroki-o] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0e0827f ] CLOUDSTACK-7412: Can't create proper template from VM on S3 secondary storage environment Signed-off-by: Rajani Karuturi > Can't create proper template from VM on S3 secondary storage environment > > > Key: CLOUDSTACK-7412 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Template >Affects Versions: Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3.0 on CentOS 6.5. > KVM Hypervisor. > using S3 provider as socondary storage. The storage system is using RADOS. > using local storage as primary storage. >Reporter: Akihiko Ota >Assignee: Akihiko Ota > Fix For: 4.5.0, 4.6.0, 4.4.3, 4.3.2 > > > When I create more than one templates from an existing virtual machine, the > second and the subsequent template is created the same as first one. > It doesn't occur in the case of using NFS secondary storage. So I guess this > is the S3 provider specific issue. > This could reproduce as following procedure. > (1) create a virtual machine (name "foo" tentatively), and modify some files > on ROOT volume of "foo". > (2) stop "foo". and create template "template-foo.1" from ROOT volume of > "foo". > (3) reboot (not re-create) "foo", and modify some files on ROOT volume again. > (4) stop "foo". and create template "template-foo.2" from ROOT volume of > "foo". > I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the > same as template-foo.1. (3)'s changes are not recorded. > As of (4), CloudStack outputs the following DEBUG message to > cloudstack-management.log. > 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl] > (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache > store > When creating templates on NFS secondary storage environment, this message is > not output. > This issue also exists on CloudStack 4.2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6254) Template disappears when download cleanedup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227541#comment-14227541 ] ASF subversion and git services commented on CLOUDSTACK-6254: - Commit 7edde4a5c7d849f5c9184972f8d4bc1f79770f65 in cloudstack's branch refs/heads/4.2 from [~dbierce] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7edde4a ] PATCH: CLOUDSTACK-6254 Fixes the cleanup process to only remove the Template symlink, instead of delete the template from Secondary Storage. Signed-off-by: Rohit Yadav > Template disappears when download cleanedup > --- > > Key: CLOUDSTACK-6254 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6254 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.1, 4.3.0 >Reporter: Alex Hitchins >Assignee: Alex Hitchins > Attachments: 2014-03-18 16_32_58-gitk_ cloudstack.png > > > In 4.2.1, the template VHD file gets removed from the template directory > after it has been downloaded. This issue occurs when the secondary storage > server is cleaning up the symlink in /var/www/html/. > Along with removing the symlink, the actual vhd is also removed. > It looks like maybe the SSVM is seeing the template as a volume and thinks > that it is removing a hard link. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-2823) SystemVMs start fail on CentOS 6.4
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227538#comment-14227538 ] ASF subversion and git services commented on CLOUDSTACK-2823: - Commit 0a935a336ebf9dcc1c3b25a56f629bb9a217b56f in cloudstack's branch refs/heads/4.3 from [~dbierce] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0a935a3 ] CLOUDSTACK-2823: Loop through cmdline when patching routers Backported from https://reviews.apache.org/r/25585/diff which did not merge this fix on 4.3 branch. Occasionally the while loop can exit with no data (Probably recieving an EOF) before receiveing CMDline data from the certial port. Continue looping until cmdline is populated Signed-off-by: Rohit Yadav > SystemVMs start fail on CentOS 6.4 > -- > > Key: CLOUDSTACK-2823 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2823 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 > Environment: CentOS 6.4, KVM > CloudStack master >Reporter: Wei Zhou >Assignee: Wei Zhou >Priority: Blocker > > Host: > [root@cs-kvm015 ~]# virsh version > Compiled against library: libvirt 0.10.2 > Using library: libvirt 0.10.2 > Using API: QEMU 0.10.2 > Running hypervisor: QEMU 0.12.1 > Network: > em0 -> cloudbr0 (Guest, Public), Guest: 172.16.61.0/24, Public: 10.11.11.0/24 > (Can not connect outside) > em1.103 -> cloudbr1 (Management, Storage) , IP: 192.168.103.* > Issue descripion > (1) SystemVMs (SSVM, CPVM) start fails , and have no IP (Public, guest, > management) > (2) After I destroyed SystemVM, no new SystemVM will be created automatically. > This issue only exists on master branch > Deploy 4.1 successfully, and SystemVms work well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6465) vmware.reserve.mem is missing from cluster level settings
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227531#comment-14227531 ] Rohit Yadav commented on CLOUDSTACK-6465: - [~harikrishna.patnala] - do you think we should backport this to 4.3? > vmware.reserve.mem is missing from cluster level settings > -- > > Key: CLOUDSTACK-6465 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6465 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0 >Reporter: Harikrishna Patnala >Assignee: Harikrishna Patnala >Priority: Critical > Fix For: 4.5.0, 4.4.3 > > > vmware.reserve.mem is missing from cluster level settings > steps > === > infrastructure->cluster->select a cluster->setting you should > vmware.reserver.mem > DB: > === > mysql> select name from configuration where scope ="cluster"; > +--+ > | name | > +--+ > | cluster.cpu.allocated.capacity.disablethreshold | > | cluster.cpu.allocated.capacity.notificationthreshold | > | cluster.memory.allocated.capacity.disablethreshold | > | cluster.memory.allocated.capacity.notificationthreshold | > | cluster.storage.allocated.capacity.notificationthreshold | > | cluster.storage.capacity.notificationthreshold | > | cpu.overprovisioning.factor | > | mem.overprovisioning.factor | > | vmware.reserve.cpu | > | xen.vm.vcpu.max | > +--+ > 10 rows in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7412) Can't create proper template from VM on S3 secondary storage environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-7412: Fix Version/s: (was: Future) > Can't create proper template from VM on S3 secondary storage environment > > > Key: CLOUDSTACK-7412 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Template >Affects Versions: Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3.0 on CentOS 6.5. > KVM Hypervisor. > using S3 provider as socondary storage. The storage system is using RADOS. > using local storage as primary storage. >Reporter: Akihiko Ota >Assignee: Akihiko Ota > Fix For: 4.5.0, 4.6.0, 4.4.3, 4.3.2 > > > When I create more than one templates from an existing virtual machine, the > second and the subsequent template is created the same as first one. > It doesn't occur in the case of using NFS secondary storage. So I guess this > is the S3 provider specific issue. > This could reproduce as following procedure. > (1) create a virtual machine (name "foo" tentatively), and modify some files > on ROOT volume of "foo". > (2) stop "foo". and create template "template-foo.1" from ROOT volume of > "foo". > (3) reboot (not re-create) "foo", and modify some files on ROOT volume again. > (4) stop "foo". and create template "template-foo.2" from ROOT volume of > "foo". > I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the > same as template-foo.1. (3)'s changes are not recorded. > As of (4), CloudStack outputs the following DEBUG message to > cloudstack-management.log. > 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl] > (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache > store > When creating templates on NFS secondary storage environment, this message is > not output. > This issue also exists on CloudStack 4.2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7412) Can't create proper template from VM on S3 secondary storage environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-7412: Assignee: Akihiko Ota > Can't create proper template from VM on S3 secondary storage environment > > > Key: CLOUDSTACK-7412 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Template >Affects Versions: Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3.0 on CentOS 6.5. > KVM Hypervisor. > using S3 provider as socondary storage. The storage system is using RADOS. > using local storage as primary storage. >Reporter: Akihiko Ota >Assignee: Akihiko Ota > Fix For: Future, 4.5.0, 4.6.0, 4.4.3, 4.3.2 > > > When I create more than one templates from an existing virtual machine, the > second and the subsequent template is created the same as first one. > It doesn't occur in the case of using NFS secondary storage. So I guess this > is the S3 provider specific issue. > This could reproduce as following procedure. > (1) create a virtual machine (name "foo" tentatively), and modify some files > on ROOT volume of "foo". > (2) stop "foo". and create template "template-foo.1" from ROOT volume of > "foo". > (3) reboot (not re-create) "foo", and modify some files on ROOT volume again. > (4) stop "foo". and create template "template-foo.2" from ROOT volume of > "foo". > I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the > same as template-foo.1. (3)'s changes are not recorded. > As of (4), CloudStack outputs the following DEBUG message to > cloudstack-management.log. > 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl] > (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache > store > When creating templates on NFS secondary storage environment, this message is > not output. > This issue also exists on CloudStack 4.2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7847) API: listDomains should display the domain resources, similar to listAccounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou updated CLOUDSTACK-7847: - Fix Version/s: (was: 4.5.0) 4.6.0 > API: listDomains should display the domain resources, similar to listAccounts > - > > Key: CLOUDSTACK-7847 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7847 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.4.0 > Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS >Reporter: Logan B >Assignee: Wei Zhou > Fix For: 4.6.0 > > > Currently the "listDomains" call does not display any resource statistics. > Since resources can be limited at the Domain level, it would make sense to > have the "listDomains" call return the resource limit & usage details the > same way "listAccounts" does. > I would suggest having it return the following details for the domain: > - Max/Used IPs > - Max/Used Templates > - Max/Used Snapshots > - Max/Used VPC > - Max/Used Networks > - Max/Used Memory > - Max/Used Projects > - Max/Used vCPU Count > - Max/Used CPU Mhz (This may not actually be tracked by CloudStack) > - Max/Used Primary Storage > - Max/Used Secondary Storage > - I may have missed some. > This would make it much easier to pull statistics information for a domain, > instead of having to use multiple other calls. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7847) API: listDomains should display the domain resources, similar to listAccounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227513#comment-14227513 ] Wei Zhou commented on CLOUDSTACK-7847: -- We need to add the max.domain.* parameters in global setting at first. I will do it. > API: listDomains should display the domain resources, similar to listAccounts > - > > Key: CLOUDSTACK-7847 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7847 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.4.0 > Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS >Reporter: Logan B > Fix For: 4.6.0 > > > Currently the "listDomains" call does not display any resource statistics. > Since resources can be limited at the Domain level, it would make sense to > have the "listDomains" call return the resource limit & usage details the > same way "listAccounts" does. > I would suggest having it return the following details for the domain: > - Max/Used IPs > - Max/Used Templates > - Max/Used Snapshots > - Max/Used VPC > - Max/Used Networks > - Max/Used Memory > - Max/Used Projects > - Max/Used vCPU Count > - Max/Used CPU Mhz (This may not actually be tracked by CloudStack) > - Max/Used Primary Storage > - Max/Used Secondary Storage > - I may have missed some. > This would make it much easier to pull statistics information for a domain, > instead of having to use multiple other calls. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7847) API: listDomains should display the domain resources, similar to listAccounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou reassigned CLOUDSTACK-7847: Assignee: Wei Zhou > API: listDomains should display the domain resources, similar to listAccounts > - > > Key: CLOUDSTACK-7847 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7847 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.4.0 > Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS >Reporter: Logan B >Assignee: Wei Zhou > Fix For: 4.6.0 > > > Currently the "listDomains" call does not display any resource statistics. > Since resources can be limited at the Domain level, it would make sense to > have the "listDomains" call return the resource limit & usage details the > same way "listAccounts" does. > I would suggest having it return the following details for the domain: > - Max/Used IPs > - Max/Used Templates > - Max/Used Snapshots > - Max/Used VPC > - Max/Used Networks > - Max/Used Memory > - Max/Used Projects > - Max/Used vCPU Count > - Max/Used CPU Mhz (This may not actually be tracked by CloudStack) > - Max/Used Primary Storage > - Max/Used Secondary Storage > - I may have missed some. > This would make it much easier to pull statistics information for a domain, > instead of having to use multiple other calls. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7985) assignVM in Advanced zone with Security Groups
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou reassigned CLOUDSTACK-7985: Assignee: Wei Zhou > assignVM in Advanced zone with Security Groups > -- > > Key: CLOUDSTACK-7985 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7985 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Wei Zhou >Assignee: Wei Zhou > > now it is not supported -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7412) Can't create proper template from VM on S3 secondary storage environment
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227503#comment-14227503 ] Hiroki Ohashi commented on CLOUDSTACK-7412: --- Patch url is below. https://reviews.apache.org/r/28511/ > Can't create proper template from VM on S3 secondary storage environment > > > Key: CLOUDSTACK-7412 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller, Template >Affects Versions: Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0 > Environment: CloudStack 4.3.0 on CentOS 6.5. > KVM Hypervisor. > using S3 provider as socondary storage. The storage system is using RADOS. > using local storage as primary storage. >Reporter: Akihiko Ota > Fix For: Future, 4.5.0, 4.6.0, 4.4.3, 4.3.2 > > > When I create more than one templates from an existing virtual machine, the > second and the subsequent template is created the same as first one. > It doesn't occur in the case of using NFS secondary storage. So I guess this > is the S3 provider specific issue. > This could reproduce as following procedure. > (1) create a virtual machine (name "foo" tentatively), and modify some files > on ROOT volume of "foo". > (2) stop "foo". and create template "template-foo.1" from ROOT volume of > "foo". > (3) reboot (not re-create) "foo", and modify some files on ROOT volume again. > (4) stop "foo". and create template "template-foo.2" from ROOT volume of > "foo". > I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the > same as template-foo.1. (3)'s changes are not recorded. > As of (4), CloudStack outputs the following DEBUG message to > cloudstack-management.log. > 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl] > (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache > store > When creating templates on NFS secondary storage environment, this message is > not output. > This issue also exists on CloudStack 4.2.1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7985) assignVM in Advanced zone with Security Groups
Wei Zhou created CLOUDSTACK-7985: Summary: assignVM in Advanced zone with Security Groups Key: CLOUDSTACK-7985 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7985 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Wei Zhou now it is not supported -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7412) Can't create proper template from VM on S3 secondary storage environment
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227502#comment-14227502
]
Hiroki Ohashi commented on CLOUDSTACK-7412:
---
{noformat}
[Abstract]
Root cause of this issue is a way to handle cache using S3 as
Secondary Storage.
When CloudStack uploads a disk image on Primary Storage(PS) to
Secondary Storage(SS), it caches the disk image on Secondary Staging
Store(SSS). This is a bug.
CloudStack uses disk image cache every time if the cache exists. For
this behavior, the old cache on SSS will be uploaded as a template
though a CloudStack user creates the template from a newer disk image
on PS than the cache.
So, we fixed this issue in a way that CloudStack deletes the cache on
SSS after CloudStack uploads disk image to SS.
[Details]
Process of handling cache is different between copy from SS to
PS(download) and copy from PS to SS(upload).
* Downloading a disk image from SS to PS
This is the case that a CloudStack user creates an instance from a
template. CloudStack caches the image on SSS.
* Uploading a disk image from PS to SS
This is the case that a CloudStack user creates a template from a disk
image of an instance. CloudStack shouldn't cache a disk image because
it usually happens that a cache image is older than a volume of an
instance.
However, there is a bug in branch condition about post process of
uploading a disk image. Then CloudStack doesn't delete the disk image
on SSS.
CloudStack uses a common method to copy a disk image between PS and SS
for upload and download. The method includes post process of disk
image cache.
As a part of post process, it is judged whether a disk image on SSS is
used as cache or not in this method:
a. Delete a disk image as upload procedure
b. Delete a disk image to handle errors
c. Cache a disk image as download procedure
In case of uploading a disk image, branch-a should be selected. But
branch-c is always selected by the condition bug. As a result, a disk
image is left on SSS and used as cache next time a CloudStack user
creates a template from an instance.
{noformat}
> Can't create proper template from VM on S3 secondary storage environment
>
>
> Key: CLOUDSTACK-7412
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Template
>Affects Versions: Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0
> Environment: CloudStack 4.3.0 on CentOS 6.5.
> KVM Hypervisor.
> using S3 provider as socondary storage. The storage system is using RADOS.
> using local storage as primary storage.
>Reporter: Akihiko Ota
> Fix For: Future, 4.5.0, 4.6.0, 4.4.3, 4.3.2
>
>
> When I create more than one templates from an existing virtual machine, the
> second and the subsequent template is created the same as first one.
> It doesn't occur in the case of using NFS secondary storage. So I guess this
> is the S3 provider specific issue.
> This could reproduce as following procedure.
> (1) create a virtual machine (name "foo" tentatively), and modify some files
> on ROOT volume of "foo".
> (2) stop "foo". and create template "template-foo.1" from ROOT volume of
> "foo".
> (3) reboot (not re-create) "foo", and modify some files on ROOT volume again.
> (4) stop "foo". and create template "template-foo.2" from ROOT volume of
> "foo".
> I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the
> same as template-foo.1. (3)'s changes are not recorded.
> As of (4), CloudStack outputs the following DEBUG message to
> cloudstack-management.log.
> 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl]
> (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache
> store
> When creating templates on NFS secondary storage environment, this message is
> not output.
> This issue also exists on CloudStack 4.2.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7984) Collect network statistics for VMs on shared network
Wei Zhou created CLOUDSTACK-7984: Summary: Collect network statistics for VMs on shared network Key: CLOUDSTACK-7984 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7984 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Environment: KVM Reporter: Wei Zhou Assignee: Wei Zhou Fix For: 4.6.0 now we get the network usage from virtual router which is only applied on isolated network. We need to collect the network statistics for VM nics on shared network. The data can be fetched from the hypervisor. Similar to vm disk statistics, I will implement it for KVM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6075) Increase the ram size for router service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227492#comment-14227492 ] ASF subversion and git services commented on CLOUDSTACK-6075: - Commit cdfdda205126bce86a4411264aca4347cfb6e254 in cloudstack's branch refs/heads/4.5 from [~harikrishna.patnala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cdfdda2 ] CLOUDSTACK-6075: Increase the ram size for router service offering Signed-off-by: Rohit Yadav (cherry picked from commit 488c17858f17f548d907cd72df54e0abdfd439b2) Signed-off-by: Rohit Yadav > Increase the ram size for router service offering > -- > > Key: CLOUDSTACK-6075 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6075 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Harikrishna Patnala >Assignee: Harikrishna Patnala > Fix For: 4.5.0, 4.4.3, 4.3.2 > > > Increase the RAM size to 256 for router system vm(Internal load balancer vm > also) service offering because 128MB will have very poor performance. Minimum > should be 256. Simply because all pointers/data structures are now 64-bit -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6075) Increase the ram size for router service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227491#comment-14227491 ] ASF subversion and git services commented on CLOUDSTACK-6075: - Commit 488c17858f17f548d907cd72df54e0abdfd439b2 in cloudstack's branch refs/heads/master from [~harikrishna.patnala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=488c178 ] CLOUDSTACK-6075: Increase the ram size for router service offering Signed-off-by: Rohit Yadav > Increase the ram size for router service offering > -- > > Key: CLOUDSTACK-6075 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6075 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Harikrishna Patnala >Assignee: Harikrishna Patnala > Fix For: 4.5.0, 4.4.3, 4.3.2 > > > Increase the RAM size to 256 for router system vm(Internal load balancer vm > also) service offering because 128MB will have very poor performance. Minimum > should be 256. Simply because all pointers/data structures are now 64-bit -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7983) Create Disk/Service Offering for Domain Admin
Wei Zhou created CLOUDSTACK-7983: Summary: Create Disk/Service Offering for Domain Admin Key: CLOUDSTACK-7983 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7983 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Wei Zhou Assignee: Wei Zhou now the offerings can only be created by admin, it is better to allow the domain admins to create the offerings which can be used in the domain. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-4827) Build failed on 4.2/4.3
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou resolved CLOUDSTACK-4827. -- Resolution: Fixed close it as this does not appear in the last months > Build failed on 4.2/4.3 > --- > > Key: CLOUDSTACK-4827 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4827 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Wei Zhou >Assignee: Wei Zhou > Fix For: 4.3.2 > > > Some guys [1][2] build cloudstack 4.2 source code failed for the following > error: > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 13:26.004s > [INFO] Finished at: Thu Oct 03 10:07:41 CEST 2013 > [INFO] Final Memory: 37M/146M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile > (default-compile) on project cloud-plugin-hypervisor-xen: Compilation > failure: Compilation failure: > [ERROR] > /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[890,16] > cannot find symbol > [ERROR] symbol : variable lockingMode > [ERROR] location: class com.xensource.xenapi.VIF.Record > [ERROR] > /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[890,36] > cannot find symbol > [ERROR] symbol : variable VifLockingMode > [ERROR] location: class com.xensource.xenapi.Types > [ERROR] > /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[1099,12] > cannot find symbol > [ERROR] symbol : variable lockingMode > [ERROR] location: class com.xensource.xenapi.VIF.Record > [ERROR] > /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[1099,32] > cannot find symbol > [ERROR] symbol : variable VifLockingMode > [ERROR] location: class com.xensource.xenapi.Types > [ERROR] > /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[4869,20] > cannot find symbol > [ERROR] symbol : variable lockingMode > [ERROR] location: class com.xensource.xenapi.VIF.Record > [ERROR] > /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java:[4869,40] > cannot find symbol > [ERROR] symbol : variable VifLockingMode > [ERROR] location: class com.xensource.xenapi.Types > [ERROR] > /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer610Resource.java:[160,43] > cannot find symbol > [ERROR] symbol : method > migrateReceive(com.xensource.xenapi.Connection,com.xensource.xenapi.Network,java.util.Map) > [ERROR] location: class com.xensource.xenapi.Host > [ERROR] > /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer610Resource.java:[175,30] > cannot find symbol > [ERROR] symbol : method > assertCanMigrateAsync(com.xensource.xenapi.Connection,java.util.Map,boolean,java.util.Map com.xensource.xenapi.SR > ,java.util.Map,java.util.Map) > [ERROR] location: class com.xensource.xenapi.VM > [ERROR] > /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer610Resource.java:[189,30] > cannot find symbol > [ERROR] symbol : method > migrateSendAsync(com.xensource.xenapi.Connection,java.util.Map,boolean,java.util.Map com.xensource.xenapi.SR > ,java.util.Map,java.util.Map) > [ERROR] location: class com.xensource.xenapi.VM > [ERROR] > /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer610Resource.java:[251,43] > cannot find symbol > [ERROR] symbol : method > migrateReceive(com.xensource.xenapi.Connection,com.xensource.xenapi.Network,java.util.Map) > [ERROR] location: class com.xensource.xenapi.Host > [ERROR] > /root/repository/apache-cloudstack-4.2.0-src/dist/rpmbuild/BUILD/cloudstack-4.2.0/plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer610Resource.java:[310,30] > ca
[jira] [Created] (CLOUDSTACK-7982) Storage live migration support for KVM
Wei Zhou created CLOUDSTACK-7982: Summary: Storage live migration support for KVM Key: CLOUDSTACK-7982 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7982 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: Wei Zhou Assignee: Wei Zhou Fix For: 4.6.0 Currently it supports Xenserver, Vmware, Hyper-V, but not KVM. We need to add the implementation for KVM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5863) Restore volume snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou updated CLOUDSTACK-5863: - Fix Version/s: 4.6.0 > Restore volume snapshot > --- > > Key: CLOUDSTACK-5863 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5863 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot > Environment: KVM, EL6, QCOW2 >Reporter: Nux > Labels: backup, kvm, restore, snapshot, volumes > Fix For: 4.6.0 > > > Hello, > Just as users can create backups of volumes, they should be able to restore > said volumes from them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-5863) Restore volume snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wei Zhou reassigned CLOUDSTACK-5863: Assignee: Wei Zhou > Restore volume snapshot > --- > > Key: CLOUDSTACK-5863 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5863 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot > Environment: KVM, EL6, QCOW2 >Reporter: Nux >Assignee: Wei Zhou > Labels: backup, kvm, restore, snapshot, volumes > Fix For: 4.6.0 > > > Hello, > Just as users can create backups of volumes, they should be able to restore > said volumes from them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
