[jira] [Closed] (CLOUDSTACK-5345) dont show upgrade router to new template if the router is already upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] manasaveloori closed CLOUDSTACK-5345. - Verified the issue .There is no option "Upgrade Router" action button if the router is already upgraded. > dont show upgrade router to new template if the router is already upgraded > -- > > Key: CLOUDSTACK-5345 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5345 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: shweta agarwal >Assignee: Jessica Wang > Fix For: 4.3.0 > > Attachments: upgrade router.jpg > > > Repro steps : > if routers are already upgraded to new system VM template don't show upgrade > router to new template action item. > Applicable for group by zone/pod cluster also. > i.e if all the VRs in a pod/cluster/zone are upgraded and requires upgrade > comes is no t hen don't show upgrade router to new template action button. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-5586) [Hyper-v] Failed to deploy vm with user account
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reassigned CLOUDSTACK-5586: -- Assignee: Rajesh Battala > [Hyper-v] Failed to deploy vm with user account > --- > > Key: CLOUDSTACK-5586 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5586 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server >Affects Versions: 4.3.0 > Environment: Latest build from 4.3 with commit : > 197ef921f7b3c80998359f376fe045b13558633c > Storage: CIFS for both primary and secondary storage > Hypervisor= Hyper-v >Reporter: Sanjeev N >Assignee: Rajesh Battala >Priority: Critical > Labels: hyper-V, > Fix For: 4.3.0 > > Attachments: management-server.rar > > > [Hyper-v] Failed to deploy vm with user account > Failed to bring up VR hence failure in vm deployment > Steps to Reproduce: > = > 1.Bring up CS in advanced zone with hyper-v using cifs for both primary and > secondary storage > 2.Create an account with role user under Root domain. > 3.Login with the user account. > 4.Try to deploy a vm with the user account. > Actual Result: > === > VR failed to come up hence vm deployment failed. > Observations: > === > During VR boot up observed that boot parameters were not configured on the > VR. Hence management server was not able to reach the VR and stopped it. > But with the default admin account started the VR(it was in stopped state due > to above failure) from CS UI and it came up without any issues and all the > boot parameters were configured properly. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5467) While Listing snapshots for volumes getting error as "Unable to find info for image store snapshot with uuid '99c70ee3-76ad-4a59-aaa1-59f0943a5f06'"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Harikrishna Patnala resolved CLOUDSTACK-5467.
-
Resolution: Fixed
Commit 67785c2ad683342ebe0622db955db505b499a6c7 in branch refs/heads/4.3
Commit b084cc469a0b394178c33a8b1621a97879cc9f53 in branch refs/heads/master
> While Listing snapshots for volumes getting error as "Unable to find info for
> image store snapshot with uuid '99c70ee3-76ad-4a59-aaa1-59f0943a5f06'"
>
>
> Key: CLOUDSTACK-5467
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5467
> 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
> Environment: volume Snapshot,
>Reporter: rashid
>Assignee: Harikrishna Patnala
> Fix For: 4.3.0
>
>
> iddata_center_id account_id domain_id volume_id
> disk_offering_idstatus pathnameuuidsnapshot_type
> type_descriptionsizecreated
> 1 1 2 1 3 4 BackingUp
> win2012_ROOT-3_2013121819 3d0ecb42-5c94-4cc7-bcd5-ccbea71133490
> MANUAL 21474836480 2013-12-11 11:18:19
> 2 1 2 1 3 4 CreatedOnPrimary
> win2012_ROOT-3_20131211122200 99c70ee3-76ad-4a59-aaa1-59f0943a5f060
> MANUAL 21474836480 2013-12-11 12:22:00
> If the status is "CreatedOnPrimary" in DB, volume snapshot throws error as
> "Unable to find info for image store snapshot with uuid
> '99c70ee3-76ad-4a59-aaa1-59f0943a5f06"
> logs pasted below
> 2013-12-11 07:32:33,356 DEBUG [c.c.h.d.HostDaoImpl] (ClusteredAgentManager
> Timer:ctx-e4753f05) Completed acquiring hosts for clusters not owned by any
> management server
> 2013-12-11 07:32:37,023 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-64:ctx-fe4c4c2e) Ping from 1(rx200rcu2)
> 2013-12-11 07:32:37,460 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-3:null) SeqA 2-1937: Processing Seq 2-1937: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2013-12-11 07:32:37,466 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-3:null) SeqA 2-1937: Sending Seq 2-1937: { Ans: ,
> MgmtId: 345052565034, via: 2, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2013-12-11 07:32:39,491 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-65:ctx-9d51ce5c) Seq 1-851902471: Executing request
> 2013-12-11 07:32:39,796 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-65:ctx-9d51ce5c) Seq 1-851902471: Response Received:
> 2013-12-11 07:32:39,797 DEBUG [c.c.a.t.Request] (DirectAgent-65:ctx-9d51ce5c)
> Seq 1-851902471: Processing: { Ans: , MgmtId: 345052565034, via: 1, Ver: v1,
> Flags: 10,
> [{"com.cloud.agent.api.ClusterSyncAnswer":{"_clusterId":1,"_newStates":{},"_isExecuted":false,"result":true,"wait":0}}]
> }
> 2013-12-11 07:32:41,465 DEBUG [c.c.a.ApiServlet]
> (638730887@qtp-534514750-5:ctx-f872c255) ===START=== 10.74.231.16 -- GET
> command=listSnapshots&response=json&sessionkey=JQoMUbWafpqxm%2BE%2BNlbqad7g3EY%3D&listAll=true&page=1&pagesize=20&_=1386764508251
> 2013-12-11 07:32:41,482 ERROR [c.c.a.ApiServer]
> (638730887@qtp-534514750-5:ctx-f872c255 ctx-c1f292cf) unhandled exception
> executing api command: listSnapshots
> com.cloud.utils.exception.CloudRuntimeException: Unable to find info for
> image store snapshot with uuid '99c70ee3-76ad-4a59-aaa1-59f0943a5f06'
> at
> com.cloud.api.ApiResponseHelper.createSnapshotResponse(ApiResponseHelper.java:465)
> at
> org.apache.cloudstack.api.command.user.snapshot.ListSnapshotsCmd.execute(ListSnapshotsCmd.java:114)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:530)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:373)
> at
> com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322)
> at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultM
[jira] [Closed] (CLOUDSTACK-5476) [UI] zone level settings are missing from UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra closed CLOUDSTACK-5476. - clearing cached worked ; passed > [UI] zone level settings are missing from UI > - > > Key: CLOUDSTACK-5476 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5476 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: prashant kumar mishra >Assignee: Brian Federle >Priority: Critical > Fix For: 4.3.0 > > Attachments: 4.3 screenshot.jpg > > > steps to repro > -- > 1-prepare a cs setup > 2- goto zone > 3-there should be a setting tab > actual > - > zone level setting tab is missing ;please check scareen shot -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5250) [Automation] integration.smoke.test_network.TestReleaseIP.test_releaseIP failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Murali Reddy resolved CLOUDSTACK-5250.
--
Resolution: Won't Fix
this is not happening now. Please narrow down the issue or analysis before
reopening the bug.
> [Automation] integration.smoke.test_network.TestReleaseIP.test_releaseIP
> failing
> --
>
> Key: CLOUDSTACK-5250
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5250
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller
>Affects Versions: 4.3.0
> Environment: VMware
> automation
>Reporter: Rayees Namathponnan
>Assignee: Murali Reddy
> Labels: automation
> Fix For: 4.3.0
>
>
> [Automation] integration.smoke.test_network.TestReleaseIP.test_releaseIP
> failing after fixing CLOUDSTACK-4344
> heck if disassociated IP Address is no longer available
> >> begin captured logging <<
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG:
> Deleting Public IP : 2c0e1ad7-639b-4564-ba82-d44a41740c34
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG: List
> Public IP response[{networkid : u'04c5487a-5754-432f-81cd-d52738c1eb9c',
> physicalnetworkid : u'ddf995ff-4f12-4cae-9729-5b763a1e1170', account :
> u'test-TestReleaseIP-test_releaseIP-RTK06M', domainid :
> u'5f0d3956-531c-11e3-a447-1a6f7bb0d0a8', issourcenat : True, isstaticnat :
> False, tags : [], associatednetworkname :
> u'test-TestReleaseIP-test_releaseIP-RTK06M-network', domain : u'ROOT', vlanid
> : u'7746889d-db42-41c2-90d1-1876847c2377', zoneid :
> u'9338ab1f-fee3-43dc-98cc-9aa2839b0d19', vlanname : u'vlan://1221', state :
> u'Allocated', associatednetworkid : u'823a5c6c-53d4-4dc0-8672-a3daeb9ff6ff',
> zonename : u'Adv-KVM-Zone1', forvirtualnetwork : True, allocated :
> u'2013-11-21T20:11:44-0800', issystem : False, ipaddress : u'10.223.122.74',
> id : u'2c0e1ad7-639b-4564-ba82-d44a41740c34', isportable : False}]
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File "/Repo_30X/ipcl/cloudstack/test/integration/smoke/test_network.py",
> line 859, in test_releaseIP
> "Check if disassociated IP Address is no longer available"
> File "/usr/local/lib/python2.7/unittest/case.py", line 494, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/local/lib/python2.7/unittest/case.py", line 487, in
> _baseAssertEqual
> raise self.failureException(msg)
> Check if disassociated IP Address is no longer available
> >> begin captured logging <<
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG:
> Deleting Public IP : 2c0e1ad7-639b-4564-ba82-d44a41740c34
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG: List
> Public IP response[{networkid : u'04c5487a-5754-432f-81cd-d52738c1eb9c',
> physicalnetworkid : u'ddf995ff-4f12-4cae-9729-5b763a1e1170', account :
> u'test-TestReleaseIP-test_releaseIP-RTK06M', domainid :
> u'5f0d3956-531c-11e3-a447-1a6f7bb0d0a8', issourcenat : True, isstaticnat :
> False, tags : [], associatednetworkname :
> u'test-TestReleaseIP-test_releaseIP-RTK06M-network', domain : u'ROOT', vlanid
> : u'7746889d-db42-41c2-90d1-1876847c2377', zoneid :
> u'9338ab1f-fee3-43dc-98cc-9aa2839b0d19', vlanname : u'vlan://1221', state :
> u'Allocated', associatednetworkid : u'823a5c6c-53d4-4dc0-8672-a3daeb9ff6ff',
> zonename : u'Adv-KVM-Zone1', forvirtualnetwork : True, allocated :
> u'2013-11-21T20:11:44-0800', issystem : False, ipaddress : u'10.223.122.74',
> id : u'2c0e1ad7-639b-4564-ba82-d44a41740c34', isportable : False}]
> - >> end captured logging << -
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-4406) Remove cleanString() call for every API to improve performance - especially of the list APIs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mandar Barve reassigned CLOUDSTACK-4406: Assignee: Mandar Barve > Remove cleanString() call for every API to improve performance - especially > of the list APIs > > > Key: CLOUDSTACK-4406 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4406 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.2.0 >Reporter: Nitin Mehta >Assignee: Mandar Barve >Priority: Critical > Fix For: Future > > > The cleanString() method is invoked for every API call to remove sensitive > data, but this is invoked for every api even though it might or might not > have it. This is not optimal as CS scales. We need a more optimized approach > to remove such data -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5591) Public network is not reachable by the System Vm's.
Kiran Koneti created CLOUDSTACK-5591: Summary: Public network is not reachable by the System Vm's. Key: CLOUDSTACK-5591 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5591 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.3.0 Reporter: Kiran Koneti Priority: Blocker Fix For: 4.3.0 The setup details are as follows: 1)Installed the CS setup and changed the global setting to allow the download from the internal sites. 2)Created a Advanced Zone setup with Vmware 5.5 where the system Vm's came up. 3)Then added one more cluster for the KVm and added a KVM host. 4)After adding the KVM ost the system Vm template for the KVM was not ready and it shows as connection timed out. 5)Then logged into the SSVM and tried to ping the public network then the network was not reachable,even the default gateway was not pingable. 6)When stopped the IP tables the gateway was pingable. 7)When tried to check the arp of the gw using "arping the gatewayIP" it says the eth0 is down and when eth0 is made up the ping was successful and the public network was reachable. 8)Then tried to restart the SSVM again the situation is same that the public network is not reachable. 9)If we leave the stup for longer time without making any changes the Public network will be reachable and when rebooted again the network will not be reached again. The Iptables details are as below: "iptables -L -nv Chain INPUT (policy DROP 4 packets, 312 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- eth2 * 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:443 0 0 ACCEPT tcp -- eth2 * 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:80 160 ACCEPT tcp -- eth1 * 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:3922 0 0 ACCEPT all -- eth0 * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 547 95190 ACCEPT all -- eth1 * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 2 262 ACCEPT all -- eth2 * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- eth3 * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 10 588 ACCEPT all -- lo * 0.0.0.0/00.0.0.0/0 0 0 DROP icmp -- * * 0.0.0.0/00.0.0.0/0 icmptype 13 0 0 ACCEPT icmp -- * * 0.0.0.0/00.0.0.0/0 0 0 ACCEPT tcp -- eth1 * 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:3922 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 493 packets, 76135 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * eth10.0.0.0/0 10.147.28.0/24 state NEW tcp 0 0 REJECT tcp -- * eth10.0.0.0/00.0.0.0/0 state NEW tcp dpt:80 reject-with icmp-port-unreachable 0 0 REJECT tcp -- * eth10.0.0.0/00.0.0.0/0 state NEW tcp dpt:443 reject-with icmp-port-unreachable Chain HTTP (0 references) pkts bytes target prot opt in out source destination" The arping request is as below: arping 10.147.X.X Interface "eth0" is down -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5591) Public network is not reachable by the System Vm's.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853856#comment-13853856 ] Kiran Koneti commented on CLOUDSTACK-5591: -- Used 64 bit systemVM template for the VMware while creating the Zone. > Public network is not reachable by the System Vm's. > --- > > Key: CLOUDSTACK-5591 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5591 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.3.0 >Reporter: Kiran Koneti >Priority: Blocker > Fix For: 4.3.0 > > > The setup details are as follows: > 1)Installed the CS setup and changed the global setting to allow the download > from the internal sites. > 2)Created a Advanced Zone setup with Vmware 5.5 where the system Vm's came up. > 3)Then added one more cluster for the KVm and added a KVM host. > 4)After adding the KVM ost the system Vm template for the KVM was not ready > and it shows as connection timed out. > 5)Then logged into the SSVM and tried to ping the public network then the > network was not reachable,even the default gateway was not pingable. > 6)When stopped the IP tables the gateway was pingable. > 7)When tried to check the arp of the gw using "arping the gatewayIP" it says > the eth0 is down and when eth0 is made up the ping was successful and the > public network was reachable. > 8)Then tried to restart the SSVM again the situation is same that the public > network is not reachable. > 9)If we leave the stup for longer time without making any changes the Public > network will be reachable and when rebooted again the network will not be > reached again. > The Iptables details are as below: > "iptables -L -nv > Chain INPUT (policy DROP 4 packets, 312 bytes) > pkts bytes target prot opt in out source > destination > 0 0 ACCEPT tcp -- eth2 * 0.0.0.0/00.0.0.0/0 >state NEW tcp dpt:443 > 0 0 ACCEPT tcp -- eth2 * 0.0.0.0/00.0.0.0/0 >state NEW tcp dpt:80 > 160 ACCEPT tcp -- eth1 * 0.0.0.0/00.0.0.0/0 >state NEW tcp dpt:3922 > 0 0 ACCEPT all -- eth0 * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 547 95190 ACCEPT all -- eth1 * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 2 262 ACCEPT all -- eth2 * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED > 0 0 ACCEPT all -- eth3 * 0.0.0.0/00.0.0.0/0 >state RELATED,ESTABLISHED >10 588 ACCEPT all -- lo * 0.0.0.0/00.0.0.0/0 > 0 0 DROP icmp -- * * 0.0.0.0/00.0.0.0/0 >icmptype 13 > 0 0 ACCEPT icmp -- * * 0.0.0.0/00.0.0.0/0 > 0 0 ACCEPT tcp -- eth1 * 0.0.0.0/00.0.0.0/0 >state NEW tcp dpt:3922 > Chain FORWARD (policy DROP 0 packets, 0 bytes) > pkts bytes target prot opt in out source > destination > Chain OUTPUT (policy ACCEPT 493 packets, 76135 bytes) > pkts bytes target prot opt in out source > destination > 0 0 ACCEPT tcp -- * eth10.0.0.0/0 > 10.147.28.0/24 state NEW tcp > 0 0 REJECT tcp -- * eth10.0.0.0/00.0.0.0/0 >state NEW tcp dpt:80 reject-with icmp-port-unreachable > 0 0 REJECT tcp -- * eth10.0.0.0/00.0.0.0/0 >state NEW tcp dpt:443 reject-with icmp-port-unreachable > Chain HTTP (0 references) > pkts bytes target prot opt in out source > destination" > The arping request is as below: > arping 10.147.X.X > Interface "eth0" is down -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-4886) cloud-setup-databases not escaping password in shell commands
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853866#comment-13853866
]
Rajani Karuturi commented on CLOUDSTACK-4886:
-
patch is on review board https://reviews.apache.org/r/16417/
> cloud-setup-databases not escaping password in shell commands
> -
>
> Key: CLOUDSTACK-4886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4886
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.0
>Reporter: John Kinsella
>Assignee: Rajani Karuturi
> Fix For: 4.3.0
>
>
> When initializing a new ACS database, the database key is not being properly
> escaped when passed back to shell commands. I haven't tested the other keys
> passed into this command, yet.
> (Passwords below are not real, but the < character and resulting error is
> what was encountered)
> root@acsmgmt01 ACS# cloudstack-setup-databases
> cloud:jpiasfadf324234jcW@localhost --deploy-as=root:lkjeroiuwer -e file -m
> 'asdflkjasdflkjwer' -k 'sfsd Mysql user name:cloud [ OK ]
> Mysql user password:jpiasfadf324234jcW [ OK ]
> Mysql server ip:localhost [ OK ]
> Mysql server port:3306 [ OK ]
> Mysql root user name:root [ OK ]
> Mysql root user password:lkjeroiuwer [ OK ]
> Using specified cluster management server node IP 10.100.10.10 [ OK ]
> Checking Cloud database files ... [ OK ]
> Checking local machine hostname ... [ OK ]
> Checking SELinux setup ... WARNING: We detected that your SELinux is not
> configured in permissive. to make sure cloudstack won't block by SELinux
> after system reboot, we strongly suggest you setting it in permissive in
> /etc/selinux/config, then reboot the machine.
> [ OK ]
> Preparing /etc/cloudstack/management/db.properties [ OK ]
> Applying /usr/share/cloudstack-management/setup/create-database.sql [ OK ]
> Applying /usr/share/cloudstack-management/setup/create-schema.sql [ OK ]
> Applying /usr/share/cloudstack-management/setup/create-database-premium.sql [
> OK ]
> Applying /usr/share/cloudstack-management/setup/create-schema-premium.sql [
> OK ]
> Applying /usr/share/cloudstack-management/setup/server-setup.sql [ OK ]
> Applying /usr/share/cloudstack-management/setup/templates.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_db.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_schema.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_multipart.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_index.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_multipart_alter.sql [
> OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_bucketpolicy.sql [ OK
> ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_policy_alter.sql [ OK
> ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_offering.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_offering_alter.sql [
> OK ]
> Processing encryption ... Traceback (most recent call last):
> File "/usr/bin/cloudstack-setup-databases", line 607, in
> o.run()
> File "/usr/bin/cloudstack-setup-databases", line 596, in run
> self.processEncryptionStuff()
> File "/usr/bin/cloudstack-setup-databases", line 433, in
> processEncryptionStuff
> encryptDBSecretKey()
> File "/usr/bin/cloudstack-setup-databases", line 417, in encryptDBSecretKey
> self.putDbProperty('db.cloud.encrypt.secret',
> formatEncryptResult(encrypt(self.dbsecretkey)))
> File "/usr/bin/cloudstack-setup-databases", line 407, in encrypt
> return runCmd(cmd).strip('\n')
> File "/usr/bin/cloudstack-setup-databases", line 51, in runCmd
> raise Exception(stderr)
> Exception: /bin/sh: Cugasdfsdf: No such file or directory
> Looks like this is caused by no escaping at line 406 in
> cloudstack-setup-databases.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-4886) cloud-setup-databases not escaping password in shell commands
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi updated CLOUDSTACK-4886:
Status: Ready To Review (was: In Progress)
> cloud-setup-databases not escaping password in shell commands
> -
>
> Key: CLOUDSTACK-4886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4886
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.0
>Reporter: John Kinsella
>Assignee: Rajani Karuturi
> Fix For: 4.3.0
>
>
> When initializing a new ACS database, the database key is not being properly
> escaped when passed back to shell commands. I haven't tested the other keys
> passed into this command, yet.
> (Passwords below are not real, but the < character and resulting error is
> what was encountered)
> root@acsmgmt01 ACS# cloudstack-setup-databases
> cloud:jpiasfadf324234jcW@localhost --deploy-as=root:lkjeroiuwer -e file -m
> 'asdflkjasdflkjwer' -k 'sfsd Mysql user name:cloud [ OK ]
> Mysql user password:jpiasfadf324234jcW [ OK ]
> Mysql server ip:localhost [ OK ]
> Mysql server port:3306 [ OK ]
> Mysql root user name:root [ OK ]
> Mysql root user password:lkjeroiuwer [ OK ]
> Using specified cluster management server node IP 10.100.10.10 [ OK ]
> Checking Cloud database files ... [ OK ]
> Checking local machine hostname ... [ OK ]
> Checking SELinux setup ... WARNING: We detected that your SELinux is not
> configured in permissive. to make sure cloudstack won't block by SELinux
> after system reboot, we strongly suggest you setting it in permissive in
> /etc/selinux/config, then reboot the machine.
> [ OK ]
> Preparing /etc/cloudstack/management/db.properties [ OK ]
> Applying /usr/share/cloudstack-management/setup/create-database.sql [ OK ]
> Applying /usr/share/cloudstack-management/setup/create-schema.sql [ OK ]
> Applying /usr/share/cloudstack-management/setup/create-database-premium.sql [
> OK ]
> Applying /usr/share/cloudstack-management/setup/create-schema-premium.sql [
> OK ]
> Applying /usr/share/cloudstack-management/setup/server-setup.sql [ OK ]
> Applying /usr/share/cloudstack-management/setup/templates.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_db.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_schema.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_multipart.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_index.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_multipart_alter.sql [
> OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_bucketpolicy.sql [ OK
> ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_policy_alter.sql [ OK
> ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_offering.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_offering_alter.sql [
> OK ]
> Processing encryption ... Traceback (most recent call last):
> File "/usr/bin/cloudstack-setup-databases", line 607, in
> o.run()
> File "/usr/bin/cloudstack-setup-databases", line 596, in run
> self.processEncryptionStuff()
> File "/usr/bin/cloudstack-setup-databases", line 433, in
> processEncryptionStuff
> encryptDBSecretKey()
> File "/usr/bin/cloudstack-setup-databases", line 417, in encryptDBSecretKey
> self.putDbProperty('db.cloud.encrypt.secret',
> formatEncryptResult(encrypt(self.dbsecretkey)))
> File "/usr/bin/cloudstack-setup-databases", line 407, in encrypt
> return runCmd(cmd).strip('\n')
> File "/usr/bin/cloudstack-setup-databases", line 51, in runCmd
> raise Exception(stderr)
> Exception: /bin/sh: Cugasdfsdf: No such file or directory
> Looks like this is caused by no escaping at line 406 in
> cloudstack-setup-databases.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-5502) [Automation] createVlanIpRange API failing, if you pass VLAN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daan Hoogland reassigned CLOUDSTACK-5502:
-
Assignee: Daan Hoogland (was: Bharat Kumar)
> [Automation] createVlanIpRange API failing, if you pass VLAN
> -
>
> Key: CLOUDSTACK-5502
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5502
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
> Environment: KVM Basic Zone with SG
>Reporter: Rayees Namathponnan
>Assignee: Daan Hoogland
>Priority: Blocker
> Fix For: 4.3.0
>
>
> This issue found in KVM basic zone with SG automation run; test cases from
> below suite filed
> integration.component.test_multiple_ip_ranges.
> Steps to reproduce
> Step 1 : Create basic zone with SG
> Step 2 : Crete IP VLAN Range with below command (pass vlan=untagged)
> http://xxx..xxx.xxx:8096/?command=createVlanIpRange&gateway=10.223.251.1&forvirtualnetwork=false&startip=10.223.251.3&podid=0253bcbf-e636-4776-9e8c-216b70d195a2&zoneid=a9912aa8-a231-44d9-a70b-9d53e6db2d27&netmask=255.255.255.192&vlan=untagged
> Result;
> API command failed with error
> { "createvlaniprangeresponse" :
> {"uuidList":[],"errorcode":431,"cserrorcode":4350,"errortext":"Vlan doesn't
> match vlan of the network"} }
> this API command works only, if you are not passing any VLAN
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5558) Delete Snapshot throws an exception with S3 store
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853878#comment-13853878
]
Pavan Kumar Bandarupally commented on CLOUDSTACK-5558:
--
Tested on Latest build that has CLOUDSTACK-5541 fix and didn't see the issue.
Closing the issue .
> Delete Snapshot throws an exception with S3 store
> -
>
> Key: CLOUDSTACK-5558
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5558
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot
>Affects Versions: 4.3.0
> Environment: Xenserver host
> 4.3 MS
>Reporter: Pavan Kumar Bandarupally
>Assignee: Min Chen
> Fix For: 4.3.0
>
>
> A snapshot of the root volume is taken and is backed up to S3 Image Store.
> Another snapshot of the same root volume is taken at a later point of time
> and this will be an incremental snapshot having a child relationship to the
> earlier one.
> Now delete the first snapshot (parent) and the operation completes
> successfully. The actual snapshot will not be deleted from the storage as it
> has children remaining. The same will be reflected in the traces.
> Now delete the child snapshot and it will succesfully be deleted from UI and
> Storage but an exception is thrown in the traces.
> DB snapshot_store_ref table before deletion of snapshot:
> --
> mysql> select snapshot_id, store_id, store_role, state, install_path from
> snapshot_store_ref;
> +-+--++---++
> | snapshot_id | store_id | store_role | state | install_path
> |
> +-+--++---++
> | 2 |2 | Image | Ready |
> snapshots/2/3/d57dc76a-fa1d-474c-9da6-463d69932917.vhd |
> | 2 |1 | ImageCache | Ready | snapshots/2/3
> |
> | 2 |1 | ImageCache | Allocated |
> snapshots/2/3/d57dc76a-fa1d-474c-9da6-463d69932917.vhd |
> | 3 |1 | Primary| Ready |
> 9ff92074-7876-40c7-baf4-6b354907220a |
> | 3 |2 | Image | Ready |
> snapshots/2/3/d57dc76a-fa1d-474c-9da6-463d69932917.vhd |
> +-+--++---++
> 5 rows in set (0.00 sec)
> DB snapshot_store_ref table after deletion of snapshot:
> --
> mysql> select snapshot_id, store_id, store_role, state, install_path from
> snapshot_store_ref;
> +-+--++---++
> | snapshot_id | store_id | store_role | state | install_path
> |
> +-+--++---++
> | 2 |2 | Image | Destroyed |
> snapshots/2/3/d57dc76a-fa1d-474c-9da6-463d69932917.vhd |
> | 2 |1 | ImageCache | Ready | snapshots/2/3
> |
> | 2 |1 | ImageCache | Allocated |
> snapshots/2/3/d57dc76a-fa1d-474c-9da6-463d69932917.vhd |
> | 3 |1 | Primary| Destroyed |
> 9ff92074-7876-40c7-baf4-6b354907220a |
> | 3 |2 | Image | Destroyed |
> snapshots/2/3/d57dc76a-fa1d-474c-9da6-463d69932917.vhd |
> +-+--++---++
> 5 rows in set (0.00 sec)
> Job Trace:
> -
> 2013-12-19 17:34:36,793 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-14:ctx-a5653e88) ===START=== 10.146.0.11 -- GET
> command=deleteSnapshot&id=2bf17c10-57e7-4a49-a3a9-d5dae78e9b06&response=json&sessionkey=zZJPWieCtGbQWU4g65spOrFYwCA%3D&_=1387435473150
> 2013-12-19 17:34:36,850 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-14:ctx-a5653e88 ctx-3d52ff98) submit async job-36, details:
> AsyncJobVO {id:36, userId: 2, accountId: 2, instanceType: Snapshot,
> instanceId: 3, cmd:
> org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd, cmdInfo:
> {"response":"json","id":"2bf17c10-57e7-4a49-a3a9-d5dae78e9b06","sessionkey":"zZJPWieCtGbQWU4g65spOrFYwCA\u003d","cmdEventType":"SNAPSHOT.DELETE","ctxUserId":"2","httpmethod":"GET","_":"1387435473150","ctxAccountId":"2","ctxStartEventId":"103"},
>
[jira] [Closed] (CLOUDSTACK-5558) Delete Snapshot throws an exception with S3 store
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavan Kumar Bandarupally closed CLOUDSTACK-5558.
> Delete Snapshot throws an exception with S3 store
> -
>
> Key: CLOUDSTACK-5558
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5558
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot
>Affects Versions: 4.3.0
> Environment: Xenserver host
> 4.3 MS
>Reporter: Pavan Kumar Bandarupally
>Assignee: Min Chen
> Fix For: 4.3.0
>
>
> A snapshot of the root volume is taken and is backed up to S3 Image Store.
> Another snapshot of the same root volume is taken at a later point of time
> and this will be an incremental snapshot having a child relationship to the
> earlier one.
> Now delete the first snapshot (parent) and the operation completes
> successfully. The actual snapshot will not be deleted from the storage as it
> has children remaining. The same will be reflected in the traces.
> Now delete the child snapshot and it will succesfully be deleted from UI and
> Storage but an exception is thrown in the traces.
> DB snapshot_store_ref table before deletion of snapshot:
> --
> mysql> select snapshot_id, store_id, store_role, state, install_path from
> snapshot_store_ref;
> +-+--++---++
> | snapshot_id | store_id | store_role | state | install_path
> |
> +-+--++---++
> | 2 |2 | Image | Ready |
> snapshots/2/3/d57dc76a-fa1d-474c-9da6-463d69932917.vhd |
> | 2 |1 | ImageCache | Ready | snapshots/2/3
> |
> | 2 |1 | ImageCache | Allocated |
> snapshots/2/3/d57dc76a-fa1d-474c-9da6-463d69932917.vhd |
> | 3 |1 | Primary| Ready |
> 9ff92074-7876-40c7-baf4-6b354907220a |
> | 3 |2 | Image | Ready |
> snapshots/2/3/d57dc76a-fa1d-474c-9da6-463d69932917.vhd |
> +-+--++---++
> 5 rows in set (0.00 sec)
> DB snapshot_store_ref table after deletion of snapshot:
> --
> mysql> select snapshot_id, store_id, store_role, state, install_path from
> snapshot_store_ref;
> +-+--++---++
> | snapshot_id | store_id | store_role | state | install_path
> |
> +-+--++---++
> | 2 |2 | Image | Destroyed |
> snapshots/2/3/d57dc76a-fa1d-474c-9da6-463d69932917.vhd |
> | 2 |1 | ImageCache | Ready | snapshots/2/3
> |
> | 2 |1 | ImageCache | Allocated |
> snapshots/2/3/d57dc76a-fa1d-474c-9da6-463d69932917.vhd |
> | 3 |1 | Primary| Destroyed |
> 9ff92074-7876-40c7-baf4-6b354907220a |
> | 3 |2 | Image | Destroyed |
> snapshots/2/3/d57dc76a-fa1d-474c-9da6-463d69932917.vhd |
> +-+--++---++
> 5 rows in set (0.00 sec)
> Job Trace:
> -
> 2013-12-19 17:34:36,793 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-14:ctx-a5653e88) ===START=== 10.146.0.11 -- GET
> command=deleteSnapshot&id=2bf17c10-57e7-4a49-a3a9-d5dae78e9b06&response=json&sessionkey=zZJPWieCtGbQWU4g65spOrFYwCA%3D&_=1387435473150
> 2013-12-19 17:34:36,850 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-14:ctx-a5653e88 ctx-3d52ff98) submit async job-36, details:
> AsyncJobVO {id:36, userId: 2, accountId: 2, instanceType: Snapshot,
> instanceId: 3, cmd:
> org.apache.cloudstack.api.command.user.snapshot.DeleteSnapshotCmd, cmdInfo:
> {"response":"json","id":"2bf17c10-57e7-4a49-a3a9-d5dae78e9b06","sessionkey":"zZJPWieCtGbQWU4g65spOrFYwCA\u003d","cmdEventType":"SNAPSHOT.DELETE","ctxUserId":"2","httpmethod":"GET","_":"1387435473150","ctxAccountId":"2","ctxStartEventId":"103"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 6915098673184, completeMsid: null, lastUpdated: null,
> las
[jira] [Resolved] (CLOUDSTACK-2562) [VMWARE] As per the code, currently CloudStack fails to program PF/NAT/LB rules when VR is restarted by VMWARE HA
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damodar Reddy T resolved CLOUDSTACK-2562.
-
Resolution: Cannot Reproduce
As it is fixed by Sateesh as part of another fix.
> [VMWARE] As per the code, currently CloudStack fails to program PF/NAT/LB
> rules when VR is restarted by VMWARE HA
> -
>
> Key: CLOUDSTACK-2562
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2562
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0
> Environment: commit # b3e9b2a5dc0439cad60058d693cba9d3c714af70
>Reporter: venkata swamybabu budumuru
>Assignee: Damodar Reddy T
>Priority: Critical
> Fix For: 4.3.0
>
>
> When VR is restarted out-of-band by VMware HA then there is no way currently
> CloudStack can reprogram PF/NAT/LB rules.
> Here is the code snippet from
> .//server/src/com/cloud/vm/VirtualMachineManagerImpl.java
> if (trackExternalChange) {
> if (serverState == State.Starting) {
> if (vm.getHostId() != null && vm.getHostId() != hostId) {
> s_logger.info("CloudStack is starting VM on host " +
> vm.getHostId() + ", but status report comes from a different host " + hostId
> + ", skip status sync for vm: "
> + vm.getInstanceName());
> return null;
> }
> }
> if (serverState == State.Running) {
> try {
> //
> // we had a bug that sometimes VM may be at Running State
> // but host_id is null, we will cover it here.
> // means that when CloudStack DB lost of host information,
> // we will heal it with the info reported from host
> //
> if (vm.getHostId() == null || hostId != vm.getHostId()) {
> if (s_logger.isDebugEnabled()) {
> s_logger.debug("detected host change when VM " +
> vm + " is at running state, VM could be live-migrated externally from host "
> + vm.getHostId() + " to host " + hostId);
> }
> stateTransitTo(vm,
> VirtualMachine.Event.AgentReportMigrated, hostId);
> }
> } catch (NoTransitionException e) {
> s_logger.warn(e.getMessage());
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-4740) Some vSphere VMs are shutdown when ACS is restarted
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damodar Reddy T resolved CLOUDSTACK-4740.
-
Resolution: Cannot Reproduce
Not able to reproduce in 4.3
> Some vSphere VMs are shutdown when ACS is restarted
> ---
>
> Key: CLOUDSTACK-4740
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4740
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.1.0, 4.1.1, 4.2.0, Future
> Environment: I'm running ACS 4.1.1 with vSphere 5.1
>Reporter: ilya musayev
>Assignee: Damodar Reddy T
>Priority: Critical
> Labels: management, poweroff
> Fix For: 4.3.0
>
>
> If management server is restarted, when management server starts - it checks
> whether the agentState for vSphere VMs and if it does not get a proper
> response, it marks them as stopped.
> As the result, some of my virtual instances would shutdown.
> Attempting to analyze this issue further, here are my findings and errors
> seen in the log.
> 2013-09-25 14:35:49,928 DEBUG [vmware.resource.VmwareResource]
> (AgentTaskPool-1:null) Detecting a new state but couldn't find a old state so
> adding it to the changes: i-2-262-acs-docs-fc17
> 2013-09-25 14:35:51,213 DEBUG [agent.transport.Request]
> (AgentTaskPool-1:null) Seq -1--1: Startup request from directly connected
> host: { Cmd , MgmtId: -1, via: -1, Ver: v1, Flags: 11,
> [{"cpus":16,"speed":2199,"memory":68683468800,"dom0MinMemory":0,"poolSync":false,"vms":{"i-8-270-CLOUD411":{"state":"Running"},"r-15-CLOUD41-OLD":{"state":"Stopped"},"v-260-CLOUD411":{"state":"Running"},"i-2-283-vmbld01l-ops-08":{"state":"Running"},"i-2-104-ACS41VM":{"state":"Running"},"--s-1-CLOUD41-OLD":{"state":"Running"},"i-27-280-CLOUD411":{"state":"Running"},"i-2-285-ossec01l-ops-08":{"state":"Running"},"i-2-262-acs-docs-fc17":{"state":"Stopped"},"i-24-265-test3":{"state":"Running"},"cloud01l-ops-08.portal.webmd.com":{"state":"Running"},"i-2-278-demo01t-ops-08":{"state":"Running"},"s-63-CLOUD411":{"state":"Running"},"r-66-CLOUD411":{"state":"Running"},"i-2-281-acs-appliance":{"state":"Running"}},"caps":"hvm","hypervisorType":"VMware","hostDetails":{"com.cloud.network.Networks.RouterPrivateIpStrategy":"DcGlobal","NativeHA":"true"},"hypervisorVersion":"5.0","type":"Routing","dataCenter":"2","pod":"2","cluster":"3","guid":"HostSystem:host-19...@vc00q-ops-08.portal.webmd.com","name":"vmha62d-ops-08.portal.webmd.com","version":"4.1.1-SNAPSHOT","privateIpAddress":"172.25.243.31","privateMacAddress":"68:b5:99:73:0b:c2","privateNetmask":"255.255.255.0","storageIpAddress":"172.25.243.31","storageNetmask":"255.255.255.0","storageMacAddress":"68:b5:99:73:0b:c2","wait":0},{"totalSize":0,"poolInfo":{"uuid":"72c8aedb-58c4-4569-ac51-adc5af770bf6","host":"vmha62d-ops-08.portal.webmd.com","localPath":"","hostPath":"datastore-19718","poolType":"LVM","capacityBytes":141465485312,"availableBytes":140383354880},"resourceType":"STORAGE_POOL","hostDetails":{},"type":"Storage","dataCenter":"2","pod":"2","cluster":"3","guid":"72c8aedb-58c4-4569-ac51-adc5af770bf6","name":"72c8aedb-58c4-4569-ac51-adc5af770bf6","wait":0}]
> }
> 2013-09-25 14:35:53,614 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (AgentTaskPool-1:null) VM i-2-262-acs-docs-fc17: cs state = Running and
> realState = Stopped
> 2013-09-25 14:35:53,614 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (AgentTaskPool-1:null) VM i-2-262-acs-docs-fc17: cs state = Running and
> realState = Stopped
> 2013-09-25 14:35:53,614 INFO [cloud.ha.HighAvailabilityManagerImpl]
> (AgentTaskPool-1:null) Skip HA for VMware VM i-2-262-acs-docs-fc17
> 2013-09-25 14:35:53,694 DEBUG [agent.transport.Request]
> (AgentTaskPool-1:null) Seq 11-1418264581: Sending { Cmd , MgmtId:
> 345049078181, via: 11, Ver: v1, Flags: 100101,
> [{"StopCommand":{"isProxy":false,"vmName":"i-2-262-acs-docs-fc17","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-278-demo01t-ops-08","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-281-acs-appliance","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-283-vmbld01l-ops-08","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-285-ossec01l-ops-08","wait":0}}]
> }
> 2013-09-25 14:35:53,695 DEBUG [agent.transport.Request]
> (AgentTaskPool-1:null) Seq 11-1418264581: Executing: { Cmd , MgmtId:
> 345049078181, via: 11, Ver: v1, Flags: 100101,
> [{"StopCommand":{"isProxy":false,"vmName":"i-2-262-acs-docs-fc17","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-278-demo01t-ops-08","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-281-acs-appliance","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-283-vmbld01l-ops-08"
[jira] [Commented] (CLOUDSTACK-5555) [Hyper-V] Deployment of VM with a Data Disk is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853885#comment-13853885
]
ASF subversion and git services commented on CLOUDSTACK-:
-
Commit c5e95be7ef2f07a76bddf3315a323e0c5c653344 in branch refs/heads/4.3 from
[~devdeep]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c5e95be ]
CLOUDSTACK-: Fixing booting a vm on hyperv with data disk. Made
changes to attach a data disk on scsi controller when a vm is being
created.
> [Hyper-V] Deployment of VM with a Data Disk is failing
> ---
>
> Key: CLOUDSTACK-
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Hypervisor Controller, Management Server
>Affects Versions: 4.3.0
> Environment: 4.3, Hyper-V
>Reporter: Abhinav Roy
>Assignee: Devdeep Singh
>Priority: Blocker
> Labels: hyper-V,, hyper-v, hyperv
> Fix For: 4.3.0
>
>
> Steps :-
> 1. Create an advanced zone setup with hyper-v as the host hypervisor type.
> 2. While deploying a VM select a data disk offering and create the VM.
> Expected behaviour :
> =
> 1. VM creation should be successful
> Observed behaviour :
> =
> VM creation with a data disk offering is failing with
> 2013-12-19 11:21:45,930 INFO [c.c.v.VirtualMachineManagerImpl]
> (Job-Executor-14:ctx-6285db7d ctx-89e5ca8f) Unable to start VM on
> Host[-1-Routing] due to com.cloud.agent.api.StartCommand fail on
> exceptionUnknown disk type DATADISK for disk DATA-13, vm named i-2-13-VM
> 2013-12-19 11:21:45,937 DEBUG [c.c.v.VirtualMachineManagerImpl]
> (Job-Executor-14:ctx-6285db7d ctx-89e5ca8f) Cleaning up resources for the vm
> VM[User|v7] in Starting state
> 2013-12-19 11:21:45,939 DEBUG [c.c.a.t.Request] (Job-Executor-14:ctx-6285db7d
> ctx-89e5ca8f) Seq 1-562367613: Sending { Cmd , MgmtId: 280320865129348, via:
> 1(10.102.192.14), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-13-VM","wait":0}}]
> }
> 2013-12-19 11:21:45,939 DEBUG [c.c.a.t.Request] (Job-Executor-14:ctx-6285db7d
> ctx-89e5ca8f) Seq 1-562367613: Executing: { Cmd , MgmtId: 280320865129348,
> via: 1(10.102.192.14), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-13-VM","wait":0}}]
> }
> 2013-12-19 11:21:45,940 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-303:ctx-fb4d1b3c) Seq 1-562367613: Executing request
> 2013-12-19 11:21:45,940 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-303:ctx-fb4d1b3c) POST request
> tohttp://10.102.192.14:8250/api/HypervResource/com.cloud.agent.api.StopCommand
> with
> contents{"isProxy":false,"executeInSequence":false,"vmName":"i-2-13-VM","contextMap":{},"wait":0}
> 2013-12-19 11:21:45,940 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-303:ctx-fb4d1b3c) Sending cmd to
> http://10.102.192.14:8250/api/HypervResource/com.cloud.agent.api.StopCommand
> cmd
> data:{"isProxy":false,"executeInSequence":false,"vmName":"i-2-13-VM","contextMap":{},"wait":0}
> 2013-12-19 11:21:46,177 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-7:null) SeqA 3-14064: Processing Seq 3-14064: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":3,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2013-12-19 11:21:46,180 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-7:null) SeqA 3-14064: Sending Seq 3-14064: { Ans: ,
> MgmtId: 280320865129348, via: 3, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2013-12-19 11:21:46,491 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-8:ctx-3b06c603) ===START=== 10.144.7.10 -- GET
> command=queryAsyncJobResult&jobId=a0ed9b36-ac87-4583-9213-c90285655c52&response=json&sessionkey=6bIWbcVBGNYGRf4pXkSyH9yjpx0%3D&_=1387432317177
> 2013-12-19 11:21:46,503 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-8:ctx-3b06c603 ctx-119ff428) ===END=== 10.144.7.10 -- GET
> command=queryAsyncJobResult&jobId=a0ed9b36-ac87-4583-9213-c90285655c52&response=json&sessionkey=6bIWbcVBGNYGRf4pXkSyH9yjpx0%3D&_=1387432317177
> 2013-12-19 11:21:47,087 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-303:ctx-fb4d1b3c) POST response
> is[{"com.cloud.agent.api.StopAnswer":{"result":true,"details":null,"vm":null,"contextMap":{}}}]
> 2013-12-19 11:21:47,087 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-303:ctx-fb4d1b3c) executeRequest received
[jira] [Resolved] (CLOUDSTACK-5555) [Hyper-V] Deployment of VM with a Data Disk is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Devdeep Singh resolved CLOUDSTACK-.
---
Resolution: Fixed
> [Hyper-V] Deployment of VM with a Data Disk is failing
> ---
>
> Key: CLOUDSTACK-
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Hypervisor Controller, Management Server
>Affects Versions: 4.3.0
> Environment: 4.3, Hyper-V
>Reporter: Abhinav Roy
>Assignee: Devdeep Singh
>Priority: Blocker
> Labels: hyper-V,, hyper-v, hyperv
> Fix For: 4.3.0
>
>
> Steps :-
> 1. Create an advanced zone setup with hyper-v as the host hypervisor type.
> 2. While deploying a VM select a data disk offering and create the VM.
> Expected behaviour :
> =
> 1. VM creation should be successful
> Observed behaviour :
> =
> VM creation with a data disk offering is failing with
> 2013-12-19 11:21:45,930 INFO [c.c.v.VirtualMachineManagerImpl]
> (Job-Executor-14:ctx-6285db7d ctx-89e5ca8f) Unable to start VM on
> Host[-1-Routing] due to com.cloud.agent.api.StartCommand fail on
> exceptionUnknown disk type DATADISK for disk DATA-13, vm named i-2-13-VM
> 2013-12-19 11:21:45,937 DEBUG [c.c.v.VirtualMachineManagerImpl]
> (Job-Executor-14:ctx-6285db7d ctx-89e5ca8f) Cleaning up resources for the vm
> VM[User|v7] in Starting state
> 2013-12-19 11:21:45,939 DEBUG [c.c.a.t.Request] (Job-Executor-14:ctx-6285db7d
> ctx-89e5ca8f) Seq 1-562367613: Sending { Cmd , MgmtId: 280320865129348, via:
> 1(10.102.192.14), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-13-VM","wait":0}}]
> }
> 2013-12-19 11:21:45,939 DEBUG [c.c.a.t.Request] (Job-Executor-14:ctx-6285db7d
> ctx-89e5ca8f) Seq 1-562367613: Executing: { Cmd , MgmtId: 280320865129348,
> via: 1(10.102.192.14), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-13-VM","wait":0}}]
> }
> 2013-12-19 11:21:45,940 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-303:ctx-fb4d1b3c) Seq 1-562367613: Executing request
> 2013-12-19 11:21:45,940 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-303:ctx-fb4d1b3c) POST request
> tohttp://10.102.192.14:8250/api/HypervResource/com.cloud.agent.api.StopCommand
> with
> contents{"isProxy":false,"executeInSequence":false,"vmName":"i-2-13-VM","contextMap":{},"wait":0}
> 2013-12-19 11:21:45,940 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-303:ctx-fb4d1b3c) Sending cmd to
> http://10.102.192.14:8250/api/HypervResource/com.cloud.agent.api.StopCommand
> cmd
> data:{"isProxy":false,"executeInSequence":false,"vmName":"i-2-13-VM","contextMap":{},"wait":0}
> 2013-12-19 11:21:46,177 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-7:null) SeqA 3-14064: Processing Seq 3-14064: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":3,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2013-12-19 11:21:46,180 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-7:null) SeqA 3-14064: Sending Seq 3-14064: { Ans: ,
> MgmtId: 280320865129348, via: 3, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2013-12-19 11:21:46,491 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-8:ctx-3b06c603) ===START=== 10.144.7.10 -- GET
> command=queryAsyncJobResult&jobId=a0ed9b36-ac87-4583-9213-c90285655c52&response=json&sessionkey=6bIWbcVBGNYGRf4pXkSyH9yjpx0%3D&_=1387432317177
> 2013-12-19 11:21:46,503 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-8:ctx-3b06c603 ctx-119ff428) ===END=== 10.144.7.10 -- GET
> command=queryAsyncJobResult&jobId=a0ed9b36-ac87-4583-9213-c90285655c52&response=json&sessionkey=6bIWbcVBGNYGRf4pXkSyH9yjpx0%3D&_=1387432317177
> 2013-12-19 11:21:47,087 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-303:ctx-fb4d1b3c) POST response
> is[{"com.cloud.agent.api.StopAnswer":{"result":true,"details":null,"vm":null,"contextMap":{}}}]
> 2013-12-19 11:21:47,087 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-303:ctx-fb4d1b3c) executeRequest received response
> [{"com.cloud.agent.api.StopAnswer":{"result":true,"contextMap":{},"wait":0}}]
> 2013-12-19 11:21:47,087 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-303:ctx-fb4d1b3c) Seq 1-562367613: Response Received:
> 2013-12-19 11:21:47,087 DEBUG [c.c.a.t.Request]
> (DirectAgent-303:ctx-fb4d1b3c) Seq 1-562367613: Processing: { Ans: , MgmtId:
> 280320865129348, via:
[jira] [Commented] (CLOUDSTACK-5555) [Hyper-V] Deployment of VM with a Data Disk is failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853886#comment-13853886
]
ASF subversion and git services commented on CLOUDSTACK-:
-
Commit 74cb4b1c5ae0ff9f93387b30111301307779f24d in branch refs/heads/master
from [~devdeep]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=74cb4b1 ]
CLOUDSTACK-: Fixing booting a vm on hyperv with data disk. Made
changes to attach a data disk on scsi controller when a vm is being
created.
> [Hyper-V] Deployment of VM with a Data Disk is failing
> ---
>
> Key: CLOUDSTACK-
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Hypervisor Controller, Management Server
>Affects Versions: 4.3.0
> Environment: 4.3, Hyper-V
>Reporter: Abhinav Roy
>Assignee: Devdeep Singh
>Priority: Blocker
> Labels: hyper-V,, hyper-v, hyperv
> Fix For: 4.3.0
>
>
> Steps :-
> 1. Create an advanced zone setup with hyper-v as the host hypervisor type.
> 2. While deploying a VM select a data disk offering and create the VM.
> Expected behaviour :
> =
> 1. VM creation should be successful
> Observed behaviour :
> =
> VM creation with a data disk offering is failing with
> 2013-12-19 11:21:45,930 INFO [c.c.v.VirtualMachineManagerImpl]
> (Job-Executor-14:ctx-6285db7d ctx-89e5ca8f) Unable to start VM on
> Host[-1-Routing] due to com.cloud.agent.api.StartCommand fail on
> exceptionUnknown disk type DATADISK for disk DATA-13, vm named i-2-13-VM
> 2013-12-19 11:21:45,937 DEBUG [c.c.v.VirtualMachineManagerImpl]
> (Job-Executor-14:ctx-6285db7d ctx-89e5ca8f) Cleaning up resources for the vm
> VM[User|v7] in Starting state
> 2013-12-19 11:21:45,939 DEBUG [c.c.a.t.Request] (Job-Executor-14:ctx-6285db7d
> ctx-89e5ca8f) Seq 1-562367613: Sending { Cmd , MgmtId: 280320865129348, via:
> 1(10.102.192.14), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-13-VM","wait":0}}]
> }
> 2013-12-19 11:21:45,939 DEBUG [c.c.a.t.Request] (Job-Executor-14:ctx-6285db7d
> ctx-89e5ca8f) Seq 1-562367613: Executing: { Cmd , MgmtId: 280320865129348,
> via: 1(10.102.192.14), Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-13-VM","wait":0}}]
> }
> 2013-12-19 11:21:45,940 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-303:ctx-fb4d1b3c) Seq 1-562367613: Executing request
> 2013-12-19 11:21:45,940 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-303:ctx-fb4d1b3c) POST request
> tohttp://10.102.192.14:8250/api/HypervResource/com.cloud.agent.api.StopCommand
> with
> contents{"isProxy":false,"executeInSequence":false,"vmName":"i-2-13-VM","contextMap":{},"wait":0}
> 2013-12-19 11:21:45,940 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-303:ctx-fb4d1b3c) Sending cmd to
> http://10.102.192.14:8250/api/HypervResource/com.cloud.agent.api.StopCommand
> cmd
> data:{"isProxy":false,"executeInSequence":false,"vmName":"i-2-13-VM","contextMap":{},"wait":0}
> 2013-12-19 11:21:46,177 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-7:null) SeqA 3-14064: Processing Seq 3-14064: { Cmd ,
> MgmtId: -1, via: 3, Ver: v1, Flags: 11,
> [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":3,"_loadInfo":"{\n
> \"connections\": []\n}","wait":0}}] }
> 2013-12-19 11:21:46,180 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-7:null) SeqA 3-14064: Sending Seq 3-14064: { Ans: ,
> MgmtId: 280320865129348, via: 3, Ver: v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2013-12-19 11:21:46,491 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-8:ctx-3b06c603) ===START=== 10.144.7.10 -- GET
> command=queryAsyncJobResult&jobId=a0ed9b36-ac87-4583-9213-c90285655c52&response=json&sessionkey=6bIWbcVBGNYGRf4pXkSyH9yjpx0%3D&_=1387432317177
> 2013-12-19 11:21:46,503 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-8:ctx-3b06c603 ctx-119ff428) ===END=== 10.144.7.10 -- GET
> command=queryAsyncJobResult&jobId=a0ed9b36-ac87-4583-9213-c90285655c52&response=json&sessionkey=6bIWbcVBGNYGRf4pXkSyH9yjpx0%3D&_=1387432317177
> 2013-12-19 11:21:47,087 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-303:ctx-fb4d1b3c) POST response
> is[{"com.cloud.agent.api.StopAnswer":{"result":true,"details":null,"vm":null,"contextMap":{}}}]
> 2013-12-19 11:21:47,087 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-303:ctx-fb4d1b3c) executeRequest receiv
[jira] [Commented] (CLOUDSTACK-4886) cloud-setup-databases not escaping password in shell commands
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853893#comment-13853893
]
ASF subversion and git services commented on CLOUDSTACK-4886:
-
Commit 8f9396b36b0cbf35de7929f1b6b3905fd84b3723 in branch refs/heads/4.3 from
[~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8f9396b ]
CLOUDSTACK-4886: printing ** to stdout instead of db users password
> cloud-setup-databases not escaping password in shell commands
> -
>
> Key: CLOUDSTACK-4886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4886
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.0
>Reporter: John Kinsella
>Assignee: Rajani Karuturi
> Fix For: 4.3.0
>
>
> When initializing a new ACS database, the database key is not being properly
> escaped when passed back to shell commands. I haven't tested the other keys
> passed into this command, yet.
> (Passwords below are not real, but the < character and resulting error is
> what was encountered)
> root@acsmgmt01 ACS# cloudstack-setup-databases
> cloud:jpiasfadf324234jcW@localhost --deploy-as=root:lkjeroiuwer -e file -m
> 'asdflkjasdflkjwer' -k 'sfsd Mysql user name:cloud [ OK ]
> Mysql user password:jpiasfadf324234jcW [ OK ]
> Mysql server ip:localhost [ OK ]
> Mysql server port:3306 [ OK ]
> Mysql root user name:root [ OK ]
> Mysql root user password:lkjeroiuwer [ OK ]
> Using specified cluster management server node IP 10.100.10.10 [ OK ]
> Checking Cloud database files ... [ OK ]
> Checking local machine hostname ... [ OK ]
> Checking SELinux setup ... WARNING: We detected that your SELinux is not
> configured in permissive. to make sure cloudstack won't block by SELinux
> after system reboot, we strongly suggest you setting it in permissive in
> /etc/selinux/config, then reboot the machine.
> [ OK ]
> Preparing /etc/cloudstack/management/db.properties [ OK ]
> Applying /usr/share/cloudstack-management/setup/create-database.sql [ OK ]
> Applying /usr/share/cloudstack-management/setup/create-schema.sql [ OK ]
> Applying /usr/share/cloudstack-management/setup/create-database-premium.sql [
> OK ]
> Applying /usr/share/cloudstack-management/setup/create-schema-premium.sql [
> OK ]
> Applying /usr/share/cloudstack-management/setup/server-setup.sql [ OK ]
> Applying /usr/share/cloudstack-management/setup/templates.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_db.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_schema.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_multipart.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_index.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_multipart_alter.sql [
> OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_bucketpolicy.sql [ OK
> ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_policy_alter.sql [ OK
> ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_offering.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_offering_alter.sql [
> OK ]
> Processing encryption ... Traceback (most recent call last):
> File "/usr/bin/cloudstack-setup-databases", line 607, in
> o.run()
> File "/usr/bin/cloudstack-setup-databases", line 596, in run
> self.processEncryptionStuff()
> File "/usr/bin/cloudstack-setup-databases", line 433, in
> processEncryptionStuff
> encryptDBSecretKey()
> File "/usr/bin/cloudstack-setup-databases", line 417, in encryptDBSecretKey
> self.putDbProperty('db.cloud.encrypt.secret',
> formatEncryptResult(encrypt(self.dbsecretkey)))
> File "/usr/bin/cloudstack-setup-databases", line 407, in encrypt
> return runCmd(cmd).strip('\n')
> File "/usr/bin/cloudstack-setup-databases", line 51, in runCmd
> raise Exception(stderr)
> Exception: /bin/sh: Cugasdfsdf: No such file or directory
> Looks like this is caused by no escaping at line 406 in
> cloudstack-setup-databases.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5592) ssh should run on eth1 interface in ssvm/cpvm running in HyperV
Rajesh Battala created CLOUDSTACK-5592: -- Summary: ssh should run on eth1 interface in ssvm/cpvm running in HyperV Key: CLOUDSTACK-5592 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5592 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Rajesh Battala Priority: Critical Fix For: 4.3.0 currently ssh is getting configured to run on local link ip in ssvm/console proxy. Admin won't be able to login to the consoles and ssvm startup will fail. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-4886) cloud-setup-databases not escaping password in shell commands
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853894#comment-13853894
]
ASF subversion and git services commented on CLOUDSTACK-4886:
-
Commit 50a428c3aa15e9ff509c11fadddc31a767abb5b7 in branch refs/heads/master
from [~rajanik]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=50a428c ]
CLOUDSTACK-4886: printing ** to stdout instead of db users password
> cloud-setup-databases not escaping password in shell commands
> -
>
> Key: CLOUDSTACK-4886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4886
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.0
>Reporter: John Kinsella
>Assignee: Rajani Karuturi
> Fix For: 4.3.0
>
>
> When initializing a new ACS database, the database key is not being properly
> escaped when passed back to shell commands. I haven't tested the other keys
> passed into this command, yet.
> (Passwords below are not real, but the < character and resulting error is
> what was encountered)
> root@acsmgmt01 ACS# cloudstack-setup-databases
> cloud:jpiasfadf324234jcW@localhost --deploy-as=root:lkjeroiuwer -e file -m
> 'asdflkjasdflkjwer' -k 'sfsd Mysql user name:cloud [ OK ]
> Mysql user password:jpiasfadf324234jcW [ OK ]
> Mysql server ip:localhost [ OK ]
> Mysql server port:3306 [ OK ]
> Mysql root user name:root [ OK ]
> Mysql root user password:lkjeroiuwer [ OK ]
> Using specified cluster management server node IP 10.100.10.10 [ OK ]
> Checking Cloud database files ... [ OK ]
> Checking local machine hostname ... [ OK ]
> Checking SELinux setup ... WARNING: We detected that your SELinux is not
> configured in permissive. to make sure cloudstack won't block by SELinux
> after system reboot, we strongly suggest you setting it in permissive in
> /etc/selinux/config, then reboot the machine.
> [ OK ]
> Preparing /etc/cloudstack/management/db.properties [ OK ]
> Applying /usr/share/cloudstack-management/setup/create-database.sql [ OK ]
> Applying /usr/share/cloudstack-management/setup/create-schema.sql [ OK ]
> Applying /usr/share/cloudstack-management/setup/create-database-premium.sql [
> OK ]
> Applying /usr/share/cloudstack-management/setup/create-schema-premium.sql [
> OK ]
> Applying /usr/share/cloudstack-management/setup/server-setup.sql [ OK ]
> Applying /usr/share/cloudstack-management/setup/templates.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_db.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_schema.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_multipart.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_index.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_multipart_alter.sql [
> OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_bucketpolicy.sql [ OK
> ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_policy_alter.sql [ OK
> ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_offering.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_offering_alter.sql [
> OK ]
> Processing encryption ... Traceback (most recent call last):
> File "/usr/bin/cloudstack-setup-databases", line 607, in
> o.run()
> File "/usr/bin/cloudstack-setup-databases", line 596, in run
> self.processEncryptionStuff()
> File "/usr/bin/cloudstack-setup-databases", line 433, in
> processEncryptionStuff
> encryptDBSecretKey()
> File "/usr/bin/cloudstack-setup-databases", line 417, in encryptDBSecretKey
> self.putDbProperty('db.cloud.encrypt.secret',
> formatEncryptResult(encrypt(self.dbsecretkey)))
> File "/usr/bin/cloudstack-setup-databases", line 407, in encrypt
> return runCmd(cmd).strip('\n')
> File "/usr/bin/cloudstack-setup-databases", line 51, in runCmd
> raise Exception(stderr)
> Exception: /bin/sh: Cugasdfsdf: No such file or directory
> Looks like this is caused by no escaping at line 406 in
> cloudstack-setup-databases.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-5144) [Automation]: Basic Zone Security Groups - SSH to VM is allowed even when there is no ingress rule defined for the security group
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy reassigned CLOUDSTACK-5144: - Assignee: Gaurav Aradhye (was: Jayapal Reddy) Please attach MS, agent logs and host iptables rules (iptables -L -nv) output. > [Automation]: Basic Zone Security Groups - SSH to VM is allowed even when > there is no ingress rule defined for the security group > - > > Key: CLOUDSTACK-5144 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5144 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.3.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye >Priority: Critical > Labels: automation > Fix For: 4.3.0 > > > In Basic Zone Setup: > 1. Create an account > 2. Deploy a VM in that account > 3. Verify that any ingress rule is not defined for the security group > belonging to the account > 4. Try SSH to VM using the nic ipaddress from external client > SSH is successful to the VM where as it should fail when the ingress rule is > not defined. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5502) [Automation] createVlanIpRange API failing, if you pass VLAN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853905#comment-13853905
]
Daan Hoogland commented on CLOUDSTACK-5502:
---
It seems by the description of the api "untagged" never was a valid value to
submit.
@Parameter(name=ApiConstants.VLAN, type=CommandType.STRING,
description="the ID or VID of the VLAN. If not specified," +
" will be defaulted to the vlan of the network or if vlan of the
network is null - to Untagged")
it is misleading though, as it states that null will be treated as "untagged"
I will implement the lenient behavior of interpreting "untagged" as null, which
will then lead to setting it to either the network-vlan or "untagged" again.
Hopefully this will suit all scenario's that where not foreseen.
> [Automation] createVlanIpRange API failing, if you pass VLAN
> -
>
> Key: CLOUDSTACK-5502
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5502
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
> Environment: KVM Basic Zone with SG
>Reporter: Rayees Namathponnan
>Assignee: Daan Hoogland
>Priority: Blocker
> Fix For: 4.3.0
>
>
> This issue found in KVM basic zone with SG automation run; test cases from
> below suite filed
> integration.component.test_multiple_ip_ranges.
> Steps to reproduce
> Step 1 : Create basic zone with SG
> Step 2 : Crete IP VLAN Range with below command (pass vlan=untagged)
> http://xxx..xxx.xxx:8096/?command=createVlanIpRange&gateway=10.223.251.1&forvirtualnetwork=false&startip=10.223.251.3&podid=0253bcbf-e636-4776-9e8c-216b70d195a2&zoneid=a9912aa8-a231-44d9-a70b-9d53e6db2d27&netmask=255.255.255.192&vlan=untagged
> Result;
> API command failed with error
> { "createvlaniprangeresponse" :
> {"uuidList":[],"errorcode":431,"cserrorcode":4350,"errortext":"Vlan doesn't
> match vlan of the network"} }
> this API command works only, if you are not passing any VLAN
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5314) [Hyper-V] Negative (-ve) values for primary storage and volumes are shown in the resource count table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-5314: --- Assignee: Sanjay Tripathi (was: Rajesh Battala) > [Hyper-V] Negative (-ve) values for primary storage and volumes are shown in > the resource count table > - > > Key: CLOUDSTACK-5314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5314 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup, Management Server >Affects Versions: 4.3.0 > Environment: Hyper-V >Reporter: Abhinav Roy >Assignee: Sanjay Tripathi >Priority: Critical > Labels: hyper-V, > Fix For: 4.3.0 > > > Description : > > The resource count value for primary storage and volumes in the > cloud.resource_count table is shown as negative (-ve) > mysql> select * from resource_count; > +++---+---+---+ > | id | account_id | domain_id | type | count | > +++---+---+---+ > | 1 | NULL | 1 | cpu | 6 | > | 2 | NULL | 1 | memory| 3072 | > | 3 | NULL | 1 | primary_storage | -103079215104 | > | 4 | NULL | 1 | secondary_storage | 56863775232 | > | 9 | NULL | 1 | user_vm | 6 | > | 10 | NULL | 1 | public_ip | 2 | > | 11 | NULL | 1 | volume|-5 | > | 12 | NULL | 1 | snapshot | 0 | > | 13 | NULL | 1 | template | 4 | > | 14 | NULL | 1 | project | 0 | > | 15 | NULL | 1 | network | 1 | > | 16 | NULL | 1 | vpc | 0 | > | 17 | 1 | NULL | user_vm | 0 | > | 18 | 1 | NULL | public_ip | 0 | > | 19 | 1 | NULL | volume| 0 | > | 20 | 1 | NULL | snapshot | 0 | > | 21 | 1 | NULL | template | 0 | > | 22 | 1 | NULL | project | 0 | > | 23 | 1 | NULL | network | 0 | > | 24 | 1 | NULL | vpc | 0 | > | 25 | 1 | NULL | cpu | 0 | > | 26 | 1 | NULL | memory| 0 | > | 27 | 1 | NULL | primary_storage | 0 | > | 28 | 1 | NULL | secondary_storage | 0 | > | 29 | 2 | NULL | user_vm | 6 | > | 30 | 2 | NULL | public_ip | 2 | > | 31 | 2 | NULL | volume|-5 | > | 32 | 2 | NULL | snapshot | 0 | > | 33 | 2 | NULL | template | 4 | > | 34 | 2 | NULL | project | 0 | > | 35 | 2 | NULL | network | 1 | > | 36 | 2 | NULL | vpc | 0 | > | 37 | 2 | NULL | cpu | 6 | > | 38 | 2 | NULL | memory| 3072 | > | 39 | 2 | NULL | primary_storage | -103079215104 | > | 40 | 2 | NULL | secondary_storage | 163220937216 | > +++---+---+---+ > 36 rows in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-5314) [Hyper-V] Negative (-ve) values for primary storage and volumes are shown in the resource count table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reassigned CLOUDSTACK-5314: -- Assignee: Rajesh Battala (was: Devdeep Singh) > [Hyper-V] Negative (-ve) values for primary storage and volumes are shown in > the resource count table > - > > Key: CLOUDSTACK-5314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5314 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup, Management Server >Affects Versions: 4.3.0 > Environment: Hyper-V >Reporter: Abhinav Roy >Assignee: Rajesh Battala >Priority: Critical > Labels: hyper-V, > Fix For: 4.3.0 > > > Description : > > The resource count value for primary storage and volumes in the > cloud.resource_count table is shown as negative (-ve) > mysql> select * from resource_count; > +++---+---+---+ > | id | account_id | domain_id | type | count | > +++---+---+---+ > | 1 | NULL | 1 | cpu | 6 | > | 2 | NULL | 1 | memory| 3072 | > | 3 | NULL | 1 | primary_storage | -103079215104 | > | 4 | NULL | 1 | secondary_storage | 56863775232 | > | 9 | NULL | 1 | user_vm | 6 | > | 10 | NULL | 1 | public_ip | 2 | > | 11 | NULL | 1 | volume|-5 | > | 12 | NULL | 1 | snapshot | 0 | > | 13 | NULL | 1 | template | 4 | > | 14 | NULL | 1 | project | 0 | > | 15 | NULL | 1 | network | 1 | > | 16 | NULL | 1 | vpc | 0 | > | 17 | 1 | NULL | user_vm | 0 | > | 18 | 1 | NULL | public_ip | 0 | > | 19 | 1 | NULL | volume| 0 | > | 20 | 1 | NULL | snapshot | 0 | > | 21 | 1 | NULL | template | 0 | > | 22 | 1 | NULL | project | 0 | > | 23 | 1 | NULL | network | 0 | > | 24 | 1 | NULL | vpc | 0 | > | 25 | 1 | NULL | cpu | 0 | > | 26 | 1 | NULL | memory| 0 | > | 27 | 1 | NULL | primary_storage | 0 | > | 28 | 1 | NULL | secondary_storage | 0 | > | 29 | 2 | NULL | user_vm | 6 | > | 30 | 2 | NULL | public_ip | 2 | > | 31 | 2 | NULL | volume|-5 | > | 32 | 2 | NULL | snapshot | 0 | > | 33 | 2 | NULL | template | 4 | > | 34 | 2 | NULL | project | 0 | > | 35 | 2 | NULL | network | 1 | > | 36 | 2 | NULL | vpc | 0 | > | 37 | 2 | NULL | cpu | 6 | > | 38 | 2 | NULL | memory| 3072 | > | 39 | 2 | NULL | primary_storage | -103079215104 | > | 40 | 2 | NULL | secondary_storage | 163220937216 | > +++---+---+---+ > 36 rows in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Closed] (CLOUDSTACK-4820) TestVPCNetworkGc.test_01_wait_network_gc netacls are not cleared
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye closed CLOUDSTACK-4820. -- Passed in recent build. > TestVPCNetworkGc.test_01_wait_network_gc netacls are not cleared > > > Key: CLOUDSTACK-4820 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4820 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.1 >Reporter: Girish Shilamkar >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.3.0 > > Attachments: management-server.tgz > > > While updating the testcase TestVPCNetworkGc.test_01_wait_network_gc > it was found that even after waiting for network garbage collector to run, > the netacls are not cleared. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Closed] (CLOUDSTACK-5135) [Automation] install_path column in snapshot_store_ref table does not have the extension of the file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye closed CLOUDSTACK-5135. -- Not an issue > [Automation] install_path column in snapshot_store_ref table does not have > the extension of the file > > > Key: CLOUDSTACK-5135 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5135 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.3.0 > Environment: All 3 hypervisors >Reporter: Gaurav Aradhye >Assignee: Harikrishna Patnala >Priority: Blocker > Labels: automation > Fix For: 4.3.0 > > > login to mysql > fire command select * from snapshot_store_ref where store_role='Image' > Check the install_path column. > This does not have the extension for the file but if you check the same > snapshot on the nfs server, the same file will have the extension based on > from which hypervisor the snapshot is created. > This mismatch creates trouble while checking if the snapshot exists on the > nfs by mounting the nfs using the path obtained from the database. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-4886) cloud-setup-databases not escaping password in shell commands
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi resolved CLOUDSTACK-4886.
-
Resolution: Fixed
review request is pushed
> cloud-setup-databases not escaping password in shell commands
> -
>
> Key: CLOUDSTACK-4886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4886
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.0
>Reporter: John Kinsella
>Assignee: Rajani Karuturi
> Fix For: 4.3.0
>
>
> When initializing a new ACS database, the database key is not being properly
> escaped when passed back to shell commands. I haven't tested the other keys
> passed into this command, yet.
> (Passwords below are not real, but the < character and resulting error is
> what was encountered)
> root@acsmgmt01 ACS# cloudstack-setup-databases
> cloud:jpiasfadf324234jcW@localhost --deploy-as=root:lkjeroiuwer -e file -m
> 'asdflkjasdflkjwer' -k 'sfsd Mysql user name:cloud [ OK ]
> Mysql user password:jpiasfadf324234jcW [ OK ]
> Mysql server ip:localhost [ OK ]
> Mysql server port:3306 [ OK ]
> Mysql root user name:root [ OK ]
> Mysql root user password:lkjeroiuwer [ OK ]
> Using specified cluster management server node IP 10.100.10.10 [ OK ]
> Checking Cloud database files ... [ OK ]
> Checking local machine hostname ... [ OK ]
> Checking SELinux setup ... WARNING: We detected that your SELinux is not
> configured in permissive. to make sure cloudstack won't block by SELinux
> after system reboot, we strongly suggest you setting it in permissive in
> /etc/selinux/config, then reboot the machine.
> [ OK ]
> Preparing /etc/cloudstack/management/db.properties [ OK ]
> Applying /usr/share/cloudstack-management/setup/create-database.sql [ OK ]
> Applying /usr/share/cloudstack-management/setup/create-schema.sql [ OK ]
> Applying /usr/share/cloudstack-management/setup/create-database-premium.sql [
> OK ]
> Applying /usr/share/cloudstack-management/setup/create-schema-premium.sql [
> OK ]
> Applying /usr/share/cloudstack-management/setup/server-setup.sql [ OK ]
> Applying /usr/share/cloudstack-management/setup/templates.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_db.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_schema.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_multipart.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_index.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_multipart_alter.sql [
> OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_bucketpolicy.sql [ OK
> ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_policy_alter.sql [ OK
> ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_offering.sql [ OK ]
> Applying /usr/share/cloudstack-bridge/setup/cloudbridge_offering_alter.sql [
> OK ]
> Processing encryption ... Traceback (most recent call last):
> File "/usr/bin/cloudstack-setup-databases", line 607, in
> o.run()
> File "/usr/bin/cloudstack-setup-databases", line 596, in run
> self.processEncryptionStuff()
> File "/usr/bin/cloudstack-setup-databases", line 433, in
> processEncryptionStuff
> encryptDBSecretKey()
> File "/usr/bin/cloudstack-setup-databases", line 417, in encryptDBSecretKey
> self.putDbProperty('db.cloud.encrypt.secret',
> formatEncryptResult(encrypt(self.dbsecretkey)))
> File "/usr/bin/cloudstack-setup-databases", line 407, in encrypt
> return runCmd(cmd).strip('\n')
> File "/usr/bin/cloudstack-setup-databases", line 51, in runCmd
> raise Exception(stderr)
> Exception: /bin/sh: Cugasdfsdf: No such file or directory
> Looks like this is caused by no escaping at line 406 in
> cloudstack-setup-databases.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5527) [UI] : No option to create non-Ldap users through the UI when the LDAP integration is done.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853914#comment-13853914 ] Rajani Karuturi commented on CLOUDSTACK-5527: - Hi Jessica, Can you add the cloudstack create account button as well before the ldap add accounts button? > [UI] : No option to create non-Ldap users through the UI when the LDAP > integration is done. > --- > > Key: CLOUDSTACK-5527 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5527 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Kiran Koneti >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.3.0 > > > Created a CS setup and integrated the same with an Ldap server and tried to > import some users from the Ldapthe users in the Ldap are imported > successfully,but there is no option to create non-ldap users in the UI. > Eg: if i want to create a User/account in the CS which is non Ldap user then > there is no option for that through the UI i can do it through the API call. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5527) [UI] : No option to create non-Ldap users through the UI when the LDAP integration is done.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-5527: Assignee: Jessica Wang (was: Rajani Karuturi) > [UI] : No option to create non-Ldap users through the UI when the LDAP > integration is done. > --- > > Key: CLOUDSTACK-5527 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5527 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Kiran Koneti >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.3.0 > > > Created a CS setup and integrated the same with an Ldap server and tried to > import some users from the Ldapthe users in the Ldap are imported > successfully,but there is no option to create non-ldap users in the UI. > Eg: if i want to create a User/account in the CS which is non Ldap user then > there is no option for that through the UI i can do it through the API call. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5502) [Automation] createVlanIpRange API failing, if you pass VLAN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853918#comment-13853918
]
ASF subversion and git services commented on CLOUDSTACK-5502:
-
Commit aaf3979cf92518d3dc5587ea0192f4b3ce1e7866 in branch refs/heads/4.3 from
[~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aaf3979 ]
CLOUDSTACK-5502: interpret vlan='untagged' as vlan == null
> [Automation] createVlanIpRange API failing, if you pass VLAN
> -
>
> Key: CLOUDSTACK-5502
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5502
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
> Environment: KVM Basic Zone with SG
>Reporter: Rayees Namathponnan
>Assignee: Daan Hoogland
>Priority: Blocker
> Fix For: 4.3.0
>
>
> This issue found in KVM basic zone with SG automation run; test cases from
> below suite filed
> integration.component.test_multiple_ip_ranges.
> Steps to reproduce
> Step 1 : Create basic zone with SG
> Step 2 : Crete IP VLAN Range with below command (pass vlan=untagged)
> http://xxx..xxx.xxx:8096/?command=createVlanIpRange&gateway=10.223.251.1&forvirtualnetwork=false&startip=10.223.251.3&podid=0253bcbf-e636-4776-9e8c-216b70d195a2&zoneid=a9912aa8-a231-44d9-a70b-9d53e6db2d27&netmask=255.255.255.192&vlan=untagged
> Result;
> API command failed with error
> { "createvlaniprangeresponse" :
> {"uuidList":[],"errorcode":431,"cserrorcode":4350,"errortext":"Vlan doesn't
> match vlan of the network"} }
> this API command works only, if you are not passing any VLAN
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5502) [Automation] createVlanIpRange API failing, if you pass VLAN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daan Hoogland resolved CLOUDSTACK-5502.
---
Resolution: Fixed
commited aaf3979cf92518d3dc5587ea0192f4b3ce1e7866
> [Automation] createVlanIpRange API failing, if you pass VLAN
> -
>
> Key: CLOUDSTACK-5502
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5502
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
> Environment: KVM Basic Zone with SG
>Reporter: Rayees Namathponnan
>Assignee: Daan Hoogland
>Priority: Blocker
> Fix For: 4.3.0
>
>
> This issue found in KVM basic zone with SG automation run; test cases from
> below suite filed
> integration.component.test_multiple_ip_ranges.
> Steps to reproduce
> Step 1 : Create basic zone with SG
> Step 2 : Crete IP VLAN Range with below command (pass vlan=untagged)
> http://xxx..xxx.xxx:8096/?command=createVlanIpRange&gateway=10.223.251.1&forvirtualnetwork=false&startip=10.223.251.3&podid=0253bcbf-e636-4776-9e8c-216b70d195a2&zoneid=a9912aa8-a231-44d9-a70b-9d53e6db2d27&netmask=255.255.255.192&vlan=untagged
> Result;
> API command failed with error
> { "createvlaniprangeresponse" :
> {"uuidList":[],"errorcode":431,"cserrorcode":4350,"errortext":"Vlan doesn't
> match vlan of the network"} }
> this API command works only, if you are not passing any VLAN
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5502) [Automation] createVlanIpRange API failing, if you pass VLAN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853930#comment-13853930
]
ASF subversion and git services commented on CLOUDSTACK-5502:
-
Commit 7b0c85da3c30c3111f55cda0582e1e2e3ab7a86e in branch refs/heads/master
from [~dahn]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7b0c85d ]
CLOUDSTACK-5502: interpret vlan='untagged' as vlan == null
> [Automation] createVlanIpRange API failing, if you pass VLAN
> -
>
> Key: CLOUDSTACK-5502
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5502
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
> Environment: KVM Basic Zone with SG
>Reporter: Rayees Namathponnan
>Assignee: Daan Hoogland
>Priority: Blocker
> Fix For: 4.3.0
>
>
> This issue found in KVM basic zone with SG automation run; test cases from
> below suite filed
> integration.component.test_multiple_ip_ranges.
> Steps to reproduce
> Step 1 : Create basic zone with SG
> Step 2 : Crete IP VLAN Range with below command (pass vlan=untagged)
> http://xxx..xxx.xxx:8096/?command=createVlanIpRange&gateway=10.223.251.1&forvirtualnetwork=false&startip=10.223.251.3&podid=0253bcbf-e636-4776-9e8c-216b70d195a2&zoneid=a9912aa8-a231-44d9-a70b-9d53e6db2d27&netmask=255.255.255.192&vlan=untagged
> Result;
> API command failed with error
> { "createvlaniprangeresponse" :
> {"uuidList":[],"errorcode":431,"cserrorcode":4350,"errortext":"Vlan doesn't
> match vlan of the network"} }
> this API command works only, if you are not passing any VLAN
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5592) ssh should run on eth1 interface in ssvm/cpvm running in HyperV
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ram Ganesh updated CLOUDSTACK-5592: --- Assignee: Rajesh Battala > ssh should run on eth1 interface in ssvm/cpvm running in HyperV > --- > > Key: CLOUDSTACK-5592 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5592 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Rajesh Battala >Assignee: Rajesh Battala >Priority: Critical > Labels: hyper-V, > Fix For: 4.3.0 > > > currently ssh is getting configured to run on local link ip in ssvm/console > proxy. > Admin won't be able to login to the consoles and ssvm startup will fail. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Closed] (CLOUDSTACK-5423) [Automation] : deployAndRun and TestCaseExecuteEngine needs modification
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla closed CLOUDSTACK-5423. --- > [Automation] : deployAndRun and TestCaseExecuteEngine needs modification > > > Key: CLOUDSTACK-5423 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5423 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, marvin >Reporter: Santhosh Kumar Edukulla >Assignee: Santhosh Kumar Edukulla > > 1. As part of recent changes to marvin, mentioned files requires some > changes. > 2. Some cleaning is as well required for these two files. Did clean up. > 3. Did cleanup in deployAndRun and added proper flow for ease of > understanding. > 4. Removed unwanted logging and used MarvinInit for initialization of Marvin. > 5. Removed few unwanted loops and redundant code. > 6. Renamed TestCaseExecuteEngine.py -> tcExecuteEngine.py inline with other > naming convention for modules in Marvin > 7. Added few codes and doc strings. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5423) [Automation] : deployAndRun and TestCaseExecuteEngine needs modification
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla resolved CLOUDSTACK-5423. - Resolution: Fixed > [Automation] : deployAndRun and TestCaseExecuteEngine needs modification > > > Key: CLOUDSTACK-5423 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5423 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, marvin >Reporter: Santhosh Kumar Edukulla >Assignee: Santhosh Kumar Edukulla > > 1. As part of recent changes to marvin, mentioned files requires some > changes. > 2. Some cleaning is as well required for these two files. Did clean up. > 3. Did cleanup in deployAndRun and added proper flow for ease of > understanding. > 4. Removed unwanted logging and used MarvinInit for initialization of Marvin. > 5. Removed few unwanted loops and redundant code. > 6. Renamed TestCaseExecuteEngine.py -> tcExecuteEngine.py inline with other > naming convention for modules in Marvin > 7. Added few codes and doc strings. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Closed] (CLOUDSTACK-5413) [Automation]: Misc Changes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla closed CLOUDSTACK-5413. --- > [Automation]: Misc Changes > -- > > Key: CLOUDSTACK-5413 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5413 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, marvin >Reporter: Santhosh Kumar Edukulla >Assignee: Santhosh Kumar Edukulla > > 1. Currently, there was an issue with logging formatter under marvin. Proper > format messages are not getting printed. Fixed that. > 2. There were few references in existing cfg files for earlier used logger > node. Removed them and added new logger node as part of pending clean up. > 3. Added TC information started, flow and the result accordingly to runlog. > This will simplify to see the test case starting , sequence of steps and > final result including timestamps for test case run while debugging. > 4. Added few changes to dump the exception throwing tc's to the explicit > exception file. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5413) [Automation]: Misc Changes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla resolved CLOUDSTACK-5413. - Resolution: Fixed > [Automation]: Misc Changes > -- > > Key: CLOUDSTACK-5413 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5413 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, marvin >Reporter: Santhosh Kumar Edukulla >Assignee: Santhosh Kumar Edukulla > > 1. Currently, there was an issue with logging formatter under marvin. Proper > format messages are not getting printed. Fixed that. > 2. There were few references in existing cfg files for earlier used logger > node. Removed them and added new logger node as part of pending clean up. > 3. Added TC information started, flow and the result accordingly to runlog. > This will simplify to see the test case starting , sequence of steps and > final result including timestamps for test case run while debugging. > 4. Added few changes to dump the exception throwing tc's to the explicit > exception file. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5378) nose failure sequence item 0: expected string, NoneType found
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla resolved CLOUDSTACK-5378. - Resolution: Fixed > nose failure sequence item 0: expected string, NoneType found > - > > Key: CLOUDSTACK-5378 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5378 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Affects Versions: 4.3.0 >Reporter: Girish Shilamkar >Assignee: Santhosh Kumar Edukulla >Priority: Critical > > Error Message > sequence item 0: expected string, NoneType found > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 132, in run > self.beforeTest(result) > File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 74, in > beforeTest > beforeTest(self.test) > File "/usr/local/lib/python2.7/site-packages/nose/proxy.py", line 117, in > beforeTest > self.plugins.beforeTest(self.test) > File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line > 99, in __call__ > return self.call(*arg, **kw) > File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line > 167, in simple > result = meth(*arg, **kw) > File "/usr/local/lib/python2.7/site-packages/marvin/marvinPlugin.py", line > 131, in beforeTest > self.testclient.identifier = '-'.join([self.identifier, self.testName]) > TypeError: sequence item 0: expected string, NoneType found -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5378) nose failure sequence item 0: expected string, NoneType found
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853953#comment-13853953 ] Santhosh Kumar Edukulla commented on CLOUDSTACK-5378: - 1. When ever we see an issue during Automation Run as reported in the bugs, please check the validness of the test scripts by running with python command as below "python test_cpu_limits.py". Most probably its the test script issue. 2. The reported issue happens when NosePlugin was not able to load the relevant test script, following are few of the examples when it misses to load : 2. 1. Test module has an indentation error 2. 2. Not able to import a given module 2. 3. Undefined variable or improper operation on a type etc. 2. 4Any other Misc Script Issues i.e., there was an issue with the test script. 3. In the mentioned cases on the particular setup when i ran it with python command, below are script errors it reported. python /Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_fw_rules.py ' Traceback (most recent call last): File "/Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_fw_rules.py", line 31, in from marvin.integration.lib.common import (get_domain, ImportError: cannot import name rebootRouter ' python /Repo_30X/ipcl/cloudstack/test/integration/component/test_cpu_limits.py Traceback (most recent call last): File "/Repo_30X/ipcl/cloudstack/test/integration/component/test_cpu_limits.py", line 30, in from marvin.integration.lib.common import (get_domain, ImportError: cannot import name cleanup_resources 4. So, in above cases the relevant import of "cleanup_resources" was failed for one of the above case. It happened because on your local marvin installation, there was no API by that name under integration/lib/common.py. 5. If there was no error reported when you run as mentioned in step1, it could be a marvin issue. Raise the issue and assign to me. Let me know. Closing the bug for now. > nose failure sequence item 0: expected string, NoneType found > - > > Key: CLOUDSTACK-5378 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5378 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Affects Versions: 4.3.0 >Reporter: Girish Shilamkar >Assignee: Santhosh Kumar Edukulla >Priority: Critical > > Error Message > sequence item 0: expected string, NoneType found > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 132, in run > self.beforeTest(result) > File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 74, in > beforeTest > beforeTest(self.test) > File "/usr/local/lib/python2.7/site-packages/nose/proxy.py", line 117, in > beforeTest > self.plugins.beforeTest(self.test) > File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line > 99, in __call__ > return self.call(*arg, **kw) > File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line > 167, in simple > result = meth(*arg, **kw) > File "/usr/local/lib/python2.7/site-packages/marvin/marvinPlugin.py", line > 131, in beforeTest > self.testclient.identifier = '-'.join([self.identifier, self.testName]) > TypeError: sequence item 0: expected string, NoneType found -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Closed] (CLOUDSTACK-5378) nose failure sequence item 0: expected string, NoneType found
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla closed CLOUDSTACK-5378. --- > nose failure sequence item 0: expected string, NoneType found > - > > Key: CLOUDSTACK-5378 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5378 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Affects Versions: 4.3.0 >Reporter: Girish Shilamkar >Assignee: Santhosh Kumar Edukulla >Priority: Critical > > Error Message > sequence item 0: expected string, NoneType found > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 132, in run > self.beforeTest(result) > File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 74, in > beforeTest > beforeTest(self.test) > File "/usr/local/lib/python2.7/site-packages/nose/proxy.py", line 117, in > beforeTest > self.plugins.beforeTest(self.test) > File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line > 99, in __call__ > return self.call(*arg, **kw) > File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line > 167, in simple > result = meth(*arg, **kw) > File "/usr/local/lib/python2.7/site-packages/marvin/marvinPlugin.py", line > 131, in beforeTest > self.testclient.identifier = '-'.join([self.identifier, self.testName]) > TypeError: sequence item 0: expected string, NoneType found -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5269) [Automation] test_shared_networks failed to import "get_free_vlan" and failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853954#comment-13853954 ] Santhosh Kumar Edukulla commented on CLOUDSTACK-5269: - 1. When ever we see an issue during Automation Run as reported in the bugs, please check the validness of the test scripts by running with python command as below "python test_cpu_limits.py". Most probably its the test script issue. 2. The reported issue happens when NosePlugin was not able to load the relevant test script, following are few of the examples when it misses to load : 2. 1. Test module has an indentation error 2. 2. Not able to import a given module 2. 3. Undefined variable or improper operation on a type etc. 2. 4Any other Misc Script Issues 2.5Import an invalid non python file. (We added fix for this as not to import non python files) i.e., there was an issue with the test script. 3. In the mentioned cases on the particular setup when i ran it with python command, below are script errors it reported. python /Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_fw_rules.py ' Traceback (most recent call last): File "/Repo_30X/ipcl/cloudstack/test/integration/component/test_egress_fw_rules.py", line 31, in from marvin.integration.lib.common import (get_domain, ImportError: cannot import name rebootRouter ' python /Repo_30X/ipcl/cloudstack/test/integration/component/test_cpu_limits.py Traceback (most recent call last): File "/Repo_30X/ipcl/cloudstack/test/integration/component/test_cpu_limits.py", line 30, in from marvin.integration.lib.common import (get_domain, ImportError: cannot import name cleanup_resources 4. So, in above cases the relevant import of "cleanup_resources" was failed for one of the above case. It happened because on your local marvin installation, there was no API by that name under integration/lib/common.py. 5. If there was no error reported when you run as mentioned in step1, it could be a marvin issue. Raise the issue and assign to me. > [Automation] test_shared_networks failed to import "get_free_vlan" and failed > -- > > Key: CLOUDSTACK-5269 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5269 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.3.0 > Environment: Basic zone > Automation >Reporter: Rayees Namathponnan >Assignee: Santhosh Kumar Edukulla > Fix For: 4.3.0 > > > Steps to reproduce > execute test_shared_networks.py in basic zone; test case failed to execute > with below error > + nosetests --with-xunit --xunit-file=test_shared_networks.xml --with-marvin > --marvin-config=/hudson/scripts/bvt_basic_sg_kvm.cfg > /Repo_30X/ipcl/cloudstack/test//integration/component/test_shared_networks.py > --load -a tags=sg -a tags=basic > ERROR > == > ERROR: Failure: ImportError (cannot import name get_free_vlan) > -- > Traceback (most recent call last): > File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 132, in run > self.beforeTest(result) > File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 74, in > beforeTest > beforeTest(self.test) > File "/usr/local/lib/python2.7/site-packages/nose/proxy.py", line 117, in > beforeTest > self.plugins.beforeTest(self.test) > File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line > 99, in __call__ > return self.call(*arg, **kw) > File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line > 167, in simple > result = meth(*arg, **kw) > File "/usr/local/lib/python2.7/site-packages/marvin/marvinPlugin.py", line > 130, in beforeTest > self.testclient.identifier = '-'.join([self.identifier, self.testName]) > TypeError: sequence item 0: expected string, NoneType found > -- > Ran 0 tests in 0.023s > FAILED (errors=1) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Closed] (CLOUDSTACK-5269) [Automation] test_shared_networks failed to import "get_free_vlan" and failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla closed CLOUDSTACK-5269. --- > [Automation] test_shared_networks failed to import "get_free_vlan" and failed > -- > > Key: CLOUDSTACK-5269 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5269 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.3.0 > Environment: Basic zone > Automation >Reporter: Rayees Namathponnan >Assignee: Santhosh Kumar Edukulla > Fix For: 4.3.0 > > > Steps to reproduce > execute test_shared_networks.py in basic zone; test case failed to execute > with below error > + nosetests --with-xunit --xunit-file=test_shared_networks.xml --with-marvin > --marvin-config=/hudson/scripts/bvt_basic_sg_kvm.cfg > /Repo_30X/ipcl/cloudstack/test//integration/component/test_shared_networks.py > --load -a tags=sg -a tags=basic > ERROR > == > ERROR: Failure: ImportError (cannot import name get_free_vlan) > -- > Traceback (most recent call last): > File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 132, in run > self.beforeTest(result) > File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 74, in > beforeTest > beforeTest(self.test) > File "/usr/local/lib/python2.7/site-packages/nose/proxy.py", line 117, in > beforeTest > self.plugins.beforeTest(self.test) > File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line > 99, in __call__ > return self.call(*arg, **kw) > File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line > 167, in simple > result = meth(*arg, **kw) > File "/usr/local/lib/python2.7/site-packages/marvin/marvinPlugin.py", line > 130, in beforeTest > self.testclient.identifier = '-'.join([self.identifier, self.testName]) > TypeError: sequence item 0: expected string, NoneType found > -- > Ran 0 tests in 0.023s > FAILED (errors=1) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5269) [Automation] test_shared_networks failed to import "get_free_vlan" and failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla resolved CLOUDSTACK-5269. - Resolution: Fixed > [Automation] test_shared_networks failed to import "get_free_vlan" and failed > -- > > Key: CLOUDSTACK-5269 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5269 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.3.0 > Environment: Basic zone > Automation >Reporter: Rayees Namathponnan >Assignee: Santhosh Kumar Edukulla > Fix For: 4.3.0 > > > Steps to reproduce > execute test_shared_networks.py in basic zone; test case failed to execute > with below error > + nosetests --with-xunit --xunit-file=test_shared_networks.xml --with-marvin > --marvin-config=/hudson/scripts/bvt_basic_sg_kvm.cfg > /Repo_30X/ipcl/cloudstack/test//integration/component/test_shared_networks.py > --load -a tags=sg -a tags=basic > ERROR > == > ERROR: Failure: ImportError (cannot import name get_free_vlan) > -- > Traceback (most recent call last): > File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 132, in run > self.beforeTest(result) > File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 74, in > beforeTest > beforeTest(self.test) > File "/usr/local/lib/python2.7/site-packages/nose/proxy.py", line 117, in > beforeTest > self.plugins.beforeTest(self.test) > File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line > 99, in __call__ > return self.call(*arg, **kw) > File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line > 167, in simple > result = meth(*arg, **kw) > File "/usr/local/lib/python2.7/site-packages/marvin/marvinPlugin.py", line > 130, in beforeTest > self.testclient.identifier = '-'.join([self.identifier, self.testName]) > TypeError: sequence item 0: expected string, NoneType found > -- > Ran 0 tests in 0.023s > FAILED (errors=1) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5593) VMware ISCSI Controller type
Alex Rybchenko created CLOUDSTACK-5593: -- Summary: VMware ISCSI Controller type Key: CLOUDSTACK-5593 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5593 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.0 Environment: vCenter Standrad 5, vSphere 5.1 Hypervisor. Reporter: Alex Rybchenko Provide ability to select type of iscsi controller for VMware hypervisor. It is selecting LSI Logic Parallel only and there is no way to change it to LSI Logic SAS. When trying to change it in VMware directly, after next instance start up cloudstack bringing it back to LSI Logic Parallel. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5594) Ability to dedicate zones, clusters, hosts, storages to projects
Alex Rybchenko created CLOUDSTACK-5594: -- Summary: Ability to dedicate zones, clusters, hosts, storages to projects Key: CLOUDSTACK-5594 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5594 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Reporter: Alex Rybchenko It would be great to have ability dedicate hosts, clusters, storages, zones etc to projects as well. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5595) [Hyper-V] Template download is not starting
Abhinav Roy created CLOUDSTACK-5595:
---
Summary: [Hyper-V] Template download is not starting
Key: CLOUDSTACK-5595
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5595
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Hypervisor Controller, Install and Setup
Affects Versions: 4.3.0
Reporter: Abhinav Roy
Priority: Blocker
Fix For: 4.3.0
The template download is not starting after the SSVM is up and running. This
error is seen :
2013-12-20 21:10:47,317 DEBUG [c.c.a.t.Request] (AgentManager-Handler-11:null)
Seq 2-670695437: Processing: { Ans: , MgmtId: 280320865129348, via: 2, Ver:
v1, Flags: 10,
[{"com.cloud.agent.api.Answer":{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
GetRootDir for
cifs://10.102.192.19/HYPERV-SMB/abhinav-hyperv-ss1?user=abhinav&password=freebsd@123&domain=BLR
failed due to com.cloud.utils.exception.CloudRuntimeException: Unable to mount
//10.102.192.19/HYPERV-SMB/abhinav-hyperv-ss1 at
/mnt/SecStorage/0067e4ff-f654-330b-89e0-013feca7f709 due to Unable to find
suitable address.\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getRootDir(NfsSecondaryStorageResource.java:1943)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:1692)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:216)\n\tat
com.cloud.storage.resource.PremiumSecondaryStorageResource.defaultAction(PremiumSecondaryStorageResource.java:63)\n\tat
com.cloud.storage.resource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:59)\n\tat
com.cloud.agent.Agent.processRequest(Agent.java:498)\n\tat
com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:806)\n\tat
com.cloud.utils.nio.Task.run(Task.java:83)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)\n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
java.lang.Thread.run(Thread.java:679)\n","wait":0}}] }
2013-12-20 21:10:47,317 DEBUG [c.c.a.t.Request] (StatsCollector-1:ctx-891d1e57)
Seq 2-670695437: Received: { Ans: , MgmtId: 280320865129348, via: 2, Ver: v1,
Flags: 10, { Answer } }
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-5527) [UI] : No option to create non-Ldap users through the UI when the LDAP integration is done.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang reassigned CLOUDSTACK-5527: Assignee: Kiran Koneti (was: Jessica Wang) Kiran, > there is no option to create non-ldap users in the UI. What does it mean? Does it mean that there is no "Add Account" button in Accounts page as my attachment "jessica_2013_12_20_AccountsPage_AddAccountButton"? If yes, please provide a screenshot. I don't have environment of Ldap server. So, please provide: (1) database dump (which has Ldap data imported like what you described in this bug) OR (2) your URL, username, password (if username/password is not "admin"/"password") thanks. Jessica > [UI] : No option to create non-Ldap users through the UI when the LDAP > integration is done. > --- > > Key: CLOUDSTACK-5527 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5527 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Kiran Koneti >Assignee: Kiran Koneti >Priority: Critical > Fix For: 4.3.0 > > > Created a CS setup and integrated the same with an Ldap server and tried to > import some users from the Ldapthe users in the Ldap are imported > successfully,but there is no option to create non-ldap users in the UI. > Eg: if i want to create a User/account in the CS which is non Ldap user then > there is no option for that through the UI i can do it through the API call. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5582) kvm - HA is not triggered when host is powered down since the host gets into "Disconnected" state.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854433#comment-13854433
]
edison su commented on CLOUDSTACK-5582:
---
The ha manager has bug which introduced by Alex's commit:
5297a071d2c20040878950172b8d0211ac7cb436
HaManagerImpl->scheduleRestart, if investigate is passed as "false", which is
the case when kvm agent connecting back to mgt server, the code will stop the
vm, but didn't reload the vm object, so this line of code:
HaWorkVO work = new HaWorkVO(vm.getId(), vm.getType(), WorkType.HA, investigate
? Step.Investigating : Step.Scheduled, hostId, vm.getState(), maxRetries + 1,
vm.getUpdated());
will store vm state as running in haworkvo.
Then this line of code will be reached:
s_logger.info("HA on " + vm);
if (vm.getState() != work.getPreviousState() || vm.getUpdated() !=
work.getUpdateTime()) {
s_logger.info("VM " + vm + " has been changed. Current State = " +
vm.getState() + " Previous State = " + work.getPreviousState() + " last updated
= " + vm.getUpdated()
+ " previous updated = " + work.getUpdateTime());
return null;
}
Then HA won't be triggered.
The fix will be reload vm state, in scheduleRestart, after
_itMgr.advanceStop(vm.getUuid(), true); is called.
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> ---
>
> Key: CLOUDSTACK-5582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5582
> 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
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: edison su
>Priority: Critical
> Fix For: 4.3.0
>
>
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> Advanced zone with 2 KVM (RHEL 6.3) hosts.
> Steps to reproduce the problem:
> Deploy few Vms in each of the hosts .
> Power down one of the hosts ( using IPMI).
> We see that the host gets into "Disconnected" state.
> All the Vms that are running in this host continue to be in "Up" state.
> This happens because of management server receiving a explicit shutdown
> request from the agent:
> 2013-12-19 21:06:37,262 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) SeqA 2--1: Processing Seq 2--1: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 111,
> [{"com.cloud.agent.api.ShutdownCommand":{"reason":"sig.kill","wait":0}}] }
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) Host 2 has informed us that it is shutting
> down with reason sig.kill and detail null
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Host 2 is disconnecting with event
> ShutdownRequested
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) The next status of agent 2is Disconnected,
> current status is Up
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Deregistering link for 2 with state
> Disconnected
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Remove Agent : 2
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.ConnectedAgentAttache]
> (AgentTaskPool-1:ctx-a32ed8e2) Processing Disconnect.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5527) [UI] : No option to create non-Ldap users through the UI when the LDAP integration is done.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-5527: - Attachment: jessica_2013_12_20_AccountsPage_AddAccountButton.PNG > [UI] : No option to create non-Ldap users through the UI when the LDAP > integration is done. > --- > > Key: CLOUDSTACK-5527 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5527 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Kiran Koneti >Assignee: Kiran Koneti >Priority: Critical > Fix For: 4.3.0 > > Attachments: jessica_2013_12_20_AccountsPage_AddAccountButton.PNG > > > Created a CS setup and integrated the same with an Ldap server and tried to > import some users from the Ldapthe users in the Ldap are imported > successfully,but there is no option to create non-ldap users in the UI. > Eg: if i want to create a User/account in the CS which is non Ldap user then > there is no option for that through the UI i can do it through the API call. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5596) KVM - HA - When host is powered down and the back up again , HA enabled user Vms on this host remain in "Stopped" state .
Sangeetha Hariharan created CLOUDSTACK-5596: --- Summary: KVM - HA - When host is powered down and the back up again , HA enabled user Vms on this host remain in "Stopped" state . Key: CLOUDSTACK-5596 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5596 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 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Priority: Critical Fix For: 4.3.0 KVM - HA - When host is powered down and the back up again , HA enabled user Vms on this host remain in "Stopped" state . Set up: Advanced zone with 2 KVM (RHEL 6.3) hosts. Steps to reproduce the problem: Deploy few HA enabled Vms in each of the hosts . Power down one of the hosts ( using IPMI).This results in the agent being shutdown gracefully. We see that the host gets into "Disconnected" state. All the Vms that are running in this host continue to be in "Up" state. After few minutes , power on the host. All the Vms that are running in this host get marked as "Down" state. At this point , we would expect HA to be triggered for all the HA enabled Vms. This is not happening and the Vms continue to be in "Down" state. host - "Rack3Host14.lab.vmops.com" was down at ~21:06 and was brought up at ~ 21:17. Following logs seen when trying to HA the user Vms: 2013-12-19 21:17:17,624 INFO [c.c.h.HighAvailabilityManagerImpl] (AgentConnectTaskPool-27:ctx-3c1b3422) Schedule vm for HA: VM[User|newvm-123] 2013-12-19 21:17:17,629 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-0:ctx-c0f1d6be work-105) Processing HAWork[105-HA-63-Running-Scheduled] 2013-12-19 21:17:17,633 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-0:ctx-c0f1d6be work-105) HA on VM[User|newvm-123] 2013-12-19 21:17:17,633 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-0:ctx-c0f1d6be work-105) VM VM[User|newvm-123] has been changed. Current State = Stopped Prev ious State = Running last updated = 10 previous updated = 8 2013-12-19 21:17:17,633 INFO [c.c.h.HighAvailabilityManagerImpl] (HA-Worker-0:ctx-c0f1d6be work-105) Completed HAWork[105-HA-63-Running-Scheduled] -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Comment Edited] (CLOUDSTACK-5527) [UI] : No option to create non-Ldap users through the UI when the LDAP integration is done.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854431#comment-13854431 ] Jessica Wang edited comment on CLOUDSTACK-5527 at 12/20/13 7:13 PM: Kiran, > there is no option to create non-ldap users in the UI. What does it mean? Does it mean that there is no "Add Account" button in Accounts page as my attachment "jessica_2013_12_20_AccountsPage_AddAccountButton"? If yes, please provide a screenshot. I don't have environment of Ldap server. So, please provide: (1) database dump (which has Ldap data imported like what you described in this bug) OR (2) your URL, username, password (if username/password is not "admin"/"password") Rajani, > Can you add the cloudstack create account button as well before "the ldap add > accounts button"? What is "the ldap add accounts button"? Where is it? Sorry, I've never had ldap environment, so I've never seen "the ldap add accounts button". I presume I'll see "the ldap add accounts button" after I restore database dump Kiran will provide. Or I'll see "the ldap add accounts button" in the URL Kiran will provide. thank you. Jessica was (Author: jessicawang): Kiran, > there is no option to create non-ldap users in the UI. What does it mean? Does it mean that there is no "Add Account" button in Accounts page as my attachment "jessica_2013_12_20_AccountsPage_AddAccountButton"? If yes, please provide a screenshot. I don't have environment of Ldap server. So, please provide: (1) database dump (which has Ldap data imported like what you described in this bug) OR (2) your URL, username, password (if username/password is not "admin"/"password") thanks. Jessica > [UI] : No option to create non-Ldap users through the UI when the LDAP > integration is done. > --- > > Key: CLOUDSTACK-5527 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5527 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Kiran Koneti >Assignee: Kiran Koneti >Priority: Critical > Fix For: 4.3.0 > > Attachments: jessica_2013_12_20_AccountsPage_AddAccountButton.PNG > > > Created a CS setup and integrated the same with an Ldap server and tried to > import some users from the Ldapthe users in the Ldap are imported > successfully,but there is no option to create non-ldap users in the UI. > Eg: if i want to create a User/account in the CS which is non Ldap user then > there is no option for that through the UI i can do it through the API call. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Comment Edited] (CLOUDSTACK-5527) [UI] : No option to create non-Ldap users through the UI when the LDAP integration is done.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854431#comment-13854431 ] Jessica Wang edited comment on CLOUDSTACK-5527 at 12/20/13 7:14 PM: Kiran, > there is no option to create non-ldap users in the UI. What does it mean? Does it mean that there is no "Add Account" button in Accounts page as my attachment "jessica_2013_12_20_AccountsPage_AddAccountButton"? If yes, please provide a screenshot. I don't have environment of Ldap server. So, please provide: (1) database dump (which has Ldap data imported like what you described in this bug) OR (2) your URL, username, password (if username/password is not "admin"/"password") Rajani, > Can you add the cloudstack create account button as well before "the ldap add > accounts button"? What is "the ldap add accounts button"? Where is it? Sorry, I've never had ldap environment, so I've never seen "the ldap add accounts button". I presume I'll see "the ldap add accounts button" after I restore database dump Kiran will provide. Or I'll see "the ldap add accounts button" in the URL Kiran will provide. thank you. Jessica was (Author: jessicawang): Kiran, > there is no option to create non-ldap users in the UI. What does it mean? Does it mean that there is no "Add Account" button in Accounts page as my attachment "jessica_2013_12_20_AccountsPage_AddAccountButton"? If yes, please provide a screenshot. I don't have environment of Ldap server. So, please provide: (1) database dump (which has Ldap data imported like what you described in this bug) OR (2) your URL, username, password (if username/password is not "admin"/"password") Rajani, > Can you add the cloudstack create account button as well before "the ldap add > accounts button"? What is "the ldap add accounts button"? Where is it? Sorry, I've never had ldap environment, so I've never seen "the ldap add accounts button". I presume I'll see "the ldap add accounts button" after I restore database dump Kiran will provide. Or I'll see "the ldap add accounts button" in the URL Kiran will provide. thank you. Jessica > [UI] : No option to create non-Ldap users through the UI when the LDAP > integration is done. > --- > > Key: CLOUDSTACK-5527 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5527 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Kiran Koneti >Assignee: Kiran Koneti >Priority: Critical > Fix For: 4.3.0 > > Attachments: jessica_2013_12_20_AccountsPage_AddAccountButton.PNG > > > Created a CS setup and integrated the same with an Ldap server and tried to > import some users from the Ldapthe users in the Ldap are imported > successfully,but there is no option to create non-ldap users in the UI. > Eg: if i want to create a User/account in the CS which is non Ldap user then > there is no option for that through the UI i can do it through the API call. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-5596) KVM - HA - When host is powered down and the back up again , HA enabled user Vms on this host remain in "Stopped" state .
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan reassigned CLOUDSTACK-5596: --- Assignee: edison su > KVM - HA - When host is powered down and the back up again , HA enabled user > Vms on this host remain in "Stopped" state . > -- > > Key: CLOUDSTACK-5596 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5596 > 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 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: edison su >Priority: Critical > Fix For: 4.3.0 > > > KVM - HA - When host is powered down and the back up again , HA enabled user > Vms on this host remain in "Stopped" state . > Set up: > Advanced zone with 2 KVM (RHEL 6.3) hosts. > Steps to reproduce the problem: > Deploy few HA enabled Vms in each of the hosts . > Power down one of the hosts ( using IPMI).This results in the agent being > shutdown gracefully. > We see that the host gets into "Disconnected" state. > All the Vms that are running in this host continue to be in "Up" state. > After few minutes , power on the host. > All the Vms that are running in this host get marked as "Down" state. > At this point , we would expect HA to be triggered for all the HA enabled > Vms. This is not happening and the Vms continue to be in "Down" state. > host - "Rack3Host14.lab.vmops.com" was down at ~21:06 and was brought up at ~ > 21:17. > Following logs seen when trying to HA the user Vms: > 2013-12-19 21:17:17,624 INFO [c.c.h.HighAvailabilityManagerImpl] > (AgentConnectTaskPool-27:ctx-3c1b3422) Schedule vm for HA: VM[User|newvm-123] > 2013-12-19 21:17:17,629 INFO [c.c.h.HighAvailabilityManagerImpl] > (HA-Worker-0:ctx-c0f1d6be work-105) Processing > HAWork[105-HA-63-Running-Scheduled] > 2013-12-19 21:17:17,633 INFO [c.c.h.HighAvailabilityManagerImpl] > (HA-Worker-0:ctx-c0f1d6be work-105) HA on VM[User|newvm-123] > 2013-12-19 21:17:17,633 INFO [c.c.h.HighAvailabilityManagerImpl] > (HA-Worker-0:ctx-c0f1d6be work-105) VM VM[User|newvm-123] has been changed. > Current State = Stopped Prev > ious State = Running last updated = 10 previous updated = 8 > 2013-12-19 21:17:17,633 INFO [c.c.h.HighAvailabilityManagerImpl] > (HA-Worker-0:ctx-c0f1d6be work-105) Completed > HAWork[105-HA-63-Running-Scheduled] -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5582) kvm - HA is not triggered when host is powered down since the host gets into "Disconnected" state.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su resolved CLOUDSTACK-5582.
---
Resolution: Fixed
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> ---
>
> Key: CLOUDSTACK-5582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5582
> 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
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: edison su
>Priority: Critical
> Fix For: 4.3.0
>
>
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> Advanced zone with 2 KVM (RHEL 6.3) hosts.
> Steps to reproduce the problem:
> Deploy few Vms in each of the hosts .
> Power down one of the hosts ( using IPMI).
> We see that the host gets into "Disconnected" state.
> All the Vms that are running in this host continue to be in "Up" state.
> This happens because of management server receiving a explicit shutdown
> request from the agent:
> 2013-12-19 21:06:37,262 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) SeqA 2--1: Processing Seq 2--1: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 111,
> [{"com.cloud.agent.api.ShutdownCommand":{"reason":"sig.kill","wait":0}}] }
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) Host 2 has informed us that it is shutting
> down with reason sig.kill and detail null
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Host 2 is disconnecting with event
> ShutdownRequested
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) The next status of agent 2is Disconnected,
> current status is Up
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Deregistering link for 2 with state
> Disconnected
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Remove Agent : 2
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.ConnectedAgentAttache]
> (AgentTaskPool-1:ctx-a32ed8e2) Processing Disconnect.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5582) kvm - HA is not triggered when host is powered down since the host gets into "Disconnected" state.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854453#comment-13854453
]
ASF subversion and git services commented on CLOUDSTACK-5582:
-
Commit e51892abd5d11ee1f11cf3d21233133c9ecc54a4 in branch refs/heads/4.3 from
[~edison]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e51892a ]
CLOUDSTACK-5582: reload vm state after vm been force stopped
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> ---
>
> Key: CLOUDSTACK-5582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5582
> 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
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: edison su
>Priority: Critical
> Fix For: 4.3.0
>
>
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> Advanced zone with 2 KVM (RHEL 6.3) hosts.
> Steps to reproduce the problem:
> Deploy few Vms in each of the hosts .
> Power down one of the hosts ( using IPMI).
> We see that the host gets into "Disconnected" state.
> All the Vms that are running in this host continue to be in "Up" state.
> This happens because of management server receiving a explicit shutdown
> request from the agent:
> 2013-12-19 21:06:37,262 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) SeqA 2--1: Processing Seq 2--1: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 111,
> [{"com.cloud.agent.api.ShutdownCommand":{"reason":"sig.kill","wait":0}}] }
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) Host 2 has informed us that it is shutting
> down with reason sig.kill and detail null
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Host 2 is disconnecting with event
> ShutdownRequested
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) The next status of agent 2is Disconnected,
> current status is Up
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Deregistering link for 2 with state
> Disconnected
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Remove Agent : 2
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.ConnectedAgentAttache]
> (AgentTaskPool-1:ctx-a32ed8e2) Processing Disconnect.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5596) KVM - HA - When host is powered down and the back up again , HA enabled user Vms on this host remain in "Stopped" state .
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-5596. --- Resolution: Fixed fixed by e51892abd5d11ee1f11cf3d21233133c9ecc54a4 on 4.3 > KVM - HA - When host is powered down and the back up again , HA enabled user > Vms on this host remain in "Stopped" state . > -- > > Key: CLOUDSTACK-5596 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5596 > 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 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: edison su >Priority: Critical > Fix For: 4.3.0 > > > KVM - HA - When host is powered down and the back up again , HA enabled user > Vms on this host remain in "Stopped" state . > Set up: > Advanced zone with 2 KVM (RHEL 6.3) hosts. > Steps to reproduce the problem: > Deploy few HA enabled Vms in each of the hosts . > Power down one of the hosts ( using IPMI).This results in the agent being > shutdown gracefully. > We see that the host gets into "Disconnected" state. > All the Vms that are running in this host continue to be in "Up" state. > After few minutes , power on the host. > All the Vms that are running in this host get marked as "Down" state. > At this point , we would expect HA to be triggered for all the HA enabled > Vms. This is not happening and the Vms continue to be in "Down" state. > host - "Rack3Host14.lab.vmops.com" was down at ~21:06 and was brought up at ~ > 21:17. > Following logs seen when trying to HA the user Vms: > 2013-12-19 21:17:17,624 INFO [c.c.h.HighAvailabilityManagerImpl] > (AgentConnectTaskPool-27:ctx-3c1b3422) Schedule vm for HA: VM[User|newvm-123] > 2013-12-19 21:17:17,629 INFO [c.c.h.HighAvailabilityManagerImpl] > (HA-Worker-0:ctx-c0f1d6be work-105) Processing > HAWork[105-HA-63-Running-Scheduled] > 2013-12-19 21:17:17,633 INFO [c.c.h.HighAvailabilityManagerImpl] > (HA-Worker-0:ctx-c0f1d6be work-105) HA on VM[User|newvm-123] > 2013-12-19 21:17:17,633 INFO [c.c.h.HighAvailabilityManagerImpl] > (HA-Worker-0:ctx-c0f1d6be work-105) VM VM[User|newvm-123] has been changed. > Current State = Stopped Prev > ious State = Running last updated = 10 previous updated = 8 > 2013-12-19 21:17:17,633 INFO [c.c.h.HighAvailabilityManagerImpl] > (HA-Worker-0:ctx-c0f1d6be work-105) Completed > HAWork[105-HA-63-Running-Scheduled] -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Reopened] (CLOUDSTACK-5582) kvm - HA is not triggered when host is powered down since the host gets into "Disconnected" state.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su reopened CLOUDSTACK-5582:
---
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> ---
>
> Key: CLOUDSTACK-5582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5582
> 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
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: edison su
>Priority: Critical
> Fix For: 4.3.0
>
>
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> Advanced zone with 2 KVM (RHEL 6.3) hosts.
> Steps to reproduce the problem:
> Deploy few Vms in each of the hosts .
> Power down one of the hosts ( using IPMI).
> We see that the host gets into "Disconnected" state.
> All the Vms that are running in this host continue to be in "Up" state.
> This happens because of management server receiving a explicit shutdown
> request from the agent:
> 2013-12-19 21:06:37,262 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) SeqA 2--1: Processing Seq 2--1: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 111,
> [{"com.cloud.agent.api.ShutdownCommand":{"reason":"sig.kill","wait":0}}] }
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) Host 2 has informed us that it is shutting
> down with reason sig.kill and detail null
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Host 2 is disconnecting with event
> ShutdownRequested
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) The next status of agent 2is Disconnected,
> current status is Up
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Deregistering link for 2 with state
> Disconnected
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Remove Agent : 2
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.ConnectedAgentAttache]
> (AgentTaskPool-1:ctx-a32ed8e2) Processing Disconnect.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5596) KVM - HA - When host is powered down and the back up again , HA enabled user Vms on this host remain in "Stopped" state .
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854465#comment-13854465 ] ASF subversion and git services commented on CLOUDSTACK-5596: - Commit 179cdea8e905182a640f020eeaad4c4f464bfa60 in branch refs/heads/master from [~edison] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=179cdea ] CLOUDSTACK-5596: reload vm state after vm been force stopped Conflicts: server/src/com/cloud/ha/HighAvailabilityManagerImpl.java > KVM - HA - When host is powered down and the back up again , HA enabled user > Vms on this host remain in "Stopped" state . > -- > > Key: CLOUDSTACK-5596 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5596 > 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 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: edison su >Priority: Critical > Fix For: 4.3.0 > > > KVM - HA - When host is powered down and the back up again , HA enabled user > Vms on this host remain in "Stopped" state . > Set up: > Advanced zone with 2 KVM (RHEL 6.3) hosts. > Steps to reproduce the problem: > Deploy few HA enabled Vms in each of the hosts . > Power down one of the hosts ( using IPMI).This results in the agent being > shutdown gracefully. > We see that the host gets into "Disconnected" state. > All the Vms that are running in this host continue to be in "Up" state. > After few minutes , power on the host. > All the Vms that are running in this host get marked as "Down" state. > At this point , we would expect HA to be triggered for all the HA enabled > Vms. This is not happening and the Vms continue to be in "Down" state. > host - "Rack3Host14.lab.vmops.com" was down at ~21:06 and was brought up at ~ > 21:17. > Following logs seen when trying to HA the user Vms: > 2013-12-19 21:17:17,624 INFO [c.c.h.HighAvailabilityManagerImpl] > (AgentConnectTaskPool-27:ctx-3c1b3422) Schedule vm for HA: VM[User|newvm-123] > 2013-12-19 21:17:17,629 INFO [c.c.h.HighAvailabilityManagerImpl] > (HA-Worker-0:ctx-c0f1d6be work-105) Processing > HAWork[105-HA-63-Running-Scheduled] > 2013-12-19 21:17:17,633 INFO [c.c.h.HighAvailabilityManagerImpl] > (HA-Worker-0:ctx-c0f1d6be work-105) HA on VM[User|newvm-123] > 2013-12-19 21:17:17,633 INFO [c.c.h.HighAvailabilityManagerImpl] > (HA-Worker-0:ctx-c0f1d6be work-105) VM VM[User|newvm-123] has been changed. > Current State = Stopped Prev > ious State = Running last updated = 10 previous updated = 8 > 2013-12-19 21:17:17,633 INFO [c.c.h.HighAvailabilityManagerImpl] > (HA-Worker-0:ctx-c0f1d6be work-105) Completed > HAWork[105-HA-63-Running-Scheduled] -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5582) kvm - HA is not triggered when host is powered down since the host gets into "Disconnected" state.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-5582:
Attachment: kvmhost-down-up.rar
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> ---
>
> Key: CLOUDSTACK-5582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5582
> 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
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: edison su
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: kvmhost-down-up.rar, kvmhost-down-up.rar
>
>
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> Advanced zone with 2 KVM (RHEL 6.3) hosts.
> Steps to reproduce the problem:
> Deploy few Vms in each of the hosts .
> Power down one of the hosts ( using IPMI).
> We see that the host gets into "Disconnected" state.
> All the Vms that are running in this host continue to be in "Up" state.
> This happens because of management server receiving a explicit shutdown
> request from the agent:
> 2013-12-19 21:06:37,262 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) SeqA 2--1: Processing Seq 2--1: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 111,
> [{"com.cloud.agent.api.ShutdownCommand":{"reason":"sig.kill","wait":0}}] }
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) Host 2 has informed us that it is shutting
> down with reason sig.kill and detail null
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Host 2 is disconnecting with event
> ShutdownRequested
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) The next status of agent 2is Disconnected,
> current status is Up
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Deregistering link for 2 with state
> Disconnected
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Remove Agent : 2
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.ConnectedAgentAttache]
> (AgentTaskPool-1:ctx-a32ed8e2) Processing Disconnect.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5582) kvm - HA is not triggered when host is powered down since the host gets into "Disconnected" state.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su updated CLOUDSTACK-5582:
--
Fix Version/s: (was: 4.3.0)
4.4.0
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> ---
>
> Key: CLOUDSTACK-5582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5582
> 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
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: edison su
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: kvmhost-down-up.rar, kvmhost-down-up.rar
>
>
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> Advanced zone with 2 KVM (RHEL 6.3) hosts.
> Steps to reproduce the problem:
> Deploy few Vms in each of the hosts .
> Power down one of the hosts ( using IPMI).
> We see that the host gets into "Disconnected" state.
> All the Vms that are running in this host continue to be in "Up" state.
> This happens because of management server receiving a explicit shutdown
> request from the agent:
> 2013-12-19 21:06:37,262 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) SeqA 2--1: Processing Seq 2--1: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 111,
> [{"com.cloud.agent.api.ShutdownCommand":{"reason":"sig.kill","wait":0}}] }
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) Host 2 has informed us that it is shutting
> down with reason sig.kill and detail null
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Host 2 is disconnecting with event
> ShutdownRequested
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) The next status of agent 2is Disconnected,
> current status is Up
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Deregistering link for 2 with state
> Disconnected
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Remove Agent : 2
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.ConnectedAgentAttache]
> (AgentTaskPool-1:ctx-a32ed8e2) Processing Disconnect.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5582) kvm - HA is not triggered when host is powered down since the host gets into "Disconnected" state.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-5582:
Attachment: kvmhost-down-up.rar
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> ---
>
> Key: CLOUDSTACK-5582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5582
> 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
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: edison su
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: kvmhost-down-up.rar, kvmhost-down-up.rar
>
>
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> Advanced zone with 2 KVM (RHEL 6.3) hosts.
> Steps to reproduce the problem:
> Deploy few Vms in each of the hosts .
> Power down one of the hosts ( using IPMI).
> We see that the host gets into "Disconnected" state.
> All the Vms that are running in this host continue to be in "Up" state.
> This happens because of management server receiving a explicit shutdown
> request from the agent:
> 2013-12-19 21:06:37,262 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) SeqA 2--1: Processing Seq 2--1: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 111,
> [{"com.cloud.agent.api.ShutdownCommand":{"reason":"sig.kill","wait":0}}] }
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) Host 2 has informed us that it is shutting
> down with reason sig.kill and detail null
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Host 2 is disconnecting with event
> ShutdownRequested
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) The next status of agent 2is Disconnected,
> current status is Up
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Deregistering link for 2 with state
> Disconnected
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Remove Agent : 2
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.ConnectedAgentAttache]
> (AgentTaskPool-1:ctx-a32ed8e2) Processing Disconnect.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5582) kvm - HA is not triggered when host is powered down since the host gets into "Disconnected" state.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854470#comment-13854470
]
edison su commented on CLOUDSTACK-5582:
---
Currently, it's by design. If the host is gracefully shut down, kvm agent will
be stopped by OS, before agent is stopped, it will send a shutdown command to
mgt server, then mgt server won't trigger HA.
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> ---
>
> Key: CLOUDSTACK-5582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5582
> 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
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: edison su
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: kvmhost-down-up.rar, kvmhost-down-up.rar
>
>
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> Advanced zone with 2 KVM (RHEL 6.3) hosts.
> Steps to reproduce the problem:
> Deploy few Vms in each of the hosts .
> Power down one of the hosts ( using IPMI).
> We see that the host gets into "Disconnected" state.
> All the Vms that are running in this host continue to be in "Up" state.
> This happens because of management server receiving a explicit shutdown
> request from the agent:
> 2013-12-19 21:06:37,262 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) SeqA 2--1: Processing Seq 2--1: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 111,
> [{"com.cloud.agent.api.ShutdownCommand":{"reason":"sig.kill","wait":0}}] }
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) Host 2 has informed us that it is shutting
> down with reason sig.kill and detail null
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Host 2 is disconnecting with event
> ShutdownRequested
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) The next status of agent 2is Disconnected,
> current status is Up
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Deregistering link for 2 with state
> Disconnected
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Remove Agent : 2
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.ConnectedAgentAttache]
> (AgentTaskPool-1:ctx-a32ed8e2) Processing Disconnect.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5264) Xenserver - Full Snapshots are not being created even after snapshot.delta.max is exceeded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854477#comment-13854477 ] edison su commented on CLOUDSTACK-5264: --- Oh, Harikrishna, don't know you already have fix. I made a similar change in 15403a1f294bec2f47bd44549594215074fb6c86. > Xenserver - Full Snapshots are not being created even after > snapshot.delta.max is exceeded > -- > > Key: CLOUDSTACK-5264 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5264 > 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 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: edison su >Priority: Blocker > Fix For: 4.3.0 > > Attachments: management-server.rar > > > Snapshots are not being created even after snapshot.delta.max is exceeded. > Set up - Advanced zone with 2 Xenserver 6.2 hosts > Deploy 10 Vms in each of the hosts , so we start with 20 Vms. > We are constantly writing to the ROOT volume ( print timestamp every 1 > minute). > Start concurrent snapshots for ROOT volumes for all the Vms. > Even after 16 snapshots have been created for the ROOT volumes , subsequent > snapshot is still not a FULL snapshot. They continue to be delta snapshot. > mysql> select snapshot_id, > parent_snapshot_id,install_path,store_id,store_role from snapshot_store_ref > where volume_id=89; > +-++-+--++ > | snapshot_id | parent_snapshot_id | install_path >| store_id | store_role | > +-++-+--++ > | 23 | 0 | > snapshots/9/89/8546a63f-dc01-4348-babc-c34c138579c7 |1 | Image | > | 45 | 23 | > snapshots/9/89/9d1404ca-c97e-4f6b-a1a4-3bb5fb1d3900 |1 | Image | > | 105 | 45 | > snapshots/9/89/0323b0cb-446e-4550-a443-d135c4a960b8 |1 | Image | > | 126 |105 | > snapshots/9/89/e440d533-c5cf-464c-940a-505d5b0108c4 |1 | Image | > | 148 |126 | > snapshots/9/89/53f884fb-cd9c-4c35-bcf1-b90f3ce0ea5f |1 | Image | > | 170 |148 | > snapshots/9/89/8ad156ad-e63f-44e1-a8ad-7bcc8acd0b26 |1 | Image | > | 192 |170 | > snapshots/9/89/2781b5af-7c92-482c-8775-f331c7df9b2b |1 | Image | > | 214 |192 | > snapshots/9/89/a2c06f0c-92e4-41b2-a4cb-7d1675146111 |1 | Image | > | 236 |214 | > snapshots/9/89/3bd9fe33-ce59-4148-825f-f9e75e56d088 |1 | Image | > | 258 |236 | > snapshots/9/89/ab414c2b-ed16-4ee2-b3f8-d17b5075fe8d |1 | Image | > | 280 |258 | > snapshots/9/89/cdd97481-d32d-4350-aaae-0a2132c2d934 |1 | Image | > | 302 |280 | > snapshots/9/89/1d82a5a0-1a75-44f3-8a27-dffcf1127b62 |1 | Image | > | 324 |302 | > snapshots/9/89/061043e7-9c22-404c-88e5-183ab4590f5e |1 | Image | > | 346 |324 | > snapshots/9/89/f82e0d43-e83b-493b-b953-6f06a94a369b |1 | Image | > | 368 |346 | > snapshots/9/89/6c0065ad-9fc0-4ce6-957c-0475153c2ed4 |1 | Image | > | 390 |368 | > snapshots/9/89/4399cb51-78a0-4e95-8fc5-8fe2e9e3aa9a |1 | Image | > | 412 |390 | > snapshots/9/89/dd295bd3-1fab-44ad-820e-67a037c828c7 |1 | Image | > | 434 |412 | > snapshots/9/89/afc0ed83-24d5-4373-8e0d-2047d965f1b2 |1 | Image | > | 456 |434 | > snapshots/9/89/88ffc423-a8c6-49c1-8eba-5a91e80c |1 | Image | > | 478 | 0 | 513340d8-d788-4f80-99d4-e8331ce97818 >|1 | Primary| > | 478 |456 | > snapshots/9/89/53d67b21-e6b9-4382-a41e-7c18a7605af0 |1 | Image | > +-++-+--++ > 21 rows in set (0.00 sec) > In secondary store: > -rw-r--r-- 1 root root 7186309632 Nov 22 15:42 > 8546a63f-dc01-4348-babc-c34c138579c7.vhd > -rw-r--r-- 1 root root 155537920 Nov 22 16:36 > 9d1404ca-c97e-4f6b-a1a4-3bb5fb1d3900.vhd > -rw-r--r-- 1
[jira] [Commented] (CLOUDSTACK-5582) kvm - HA is not triggered when host is powered down since the host gets into "Disconnected" state.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854476#comment-13854476
]
Sangeetha Hariharan commented on CLOUDSTACK-5582:
-
Edison,
What is the use case for having the agent being shutdown gracefully ? Admin has
the ability to put hosts in "Maintenance state" , if he needs to do some
maintenance on this host , correct ?
-Thanks
Sangeetha
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> ---
>
> Key: CLOUDSTACK-5582
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5582
> 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
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: edison su
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: kvmhost-down-up.rar, kvmhost-down-up.rar
>
>
> kvm - HA is not triggered when host is powered down since the host gets into
> "Disconnected" state.
> Advanced zone with 2 KVM (RHEL 6.3) hosts.
> Steps to reproduce the problem:
> Deploy few Vms in each of the hosts .
> Power down one of the hosts ( using IPMI).
> We see that the host gets into "Disconnected" state.
> All the Vms that are running in this host continue to be in "Up" state.
> This happens because of management server receiving a explicit shutdown
> request from the agent:
> 2013-12-19 21:06:37,262 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) SeqA 2--1: Processing Seq 2--1: { Cmd ,
> MgmtId: -1, via: 2, Ver: v1, Flags: 111,
> [{"com.cloud.agent.api.ShutdownCommand":{"reason":"sig.kill","wait":0}}] }
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentManager-Handler-15:null) Host 2 has informed us that it is shutting
> down with reason sig.kill and detail null
> 2013-12-19 21:06:37,263 INFO [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Host 2 is disconnecting with event
> ShutdownRequested
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) The next status of agent 2is Disconnected,
> current status is Up
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Deregistering link for 2 with state
> Disconnected
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.AgentManagerImpl]
> (AgentTaskPool-1:ctx-a32ed8e2) Remove Agent : 2
> 2013-12-19 21:06:37,264 DEBUG [c.c.a.m.ConnectedAgentAttache]
> (AgentTaskPool-1:ctx-a32ed8e2) Processing Disconnect.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5264) Xenserver - Full Snapshots are not being created even after snapshot.delta.max is exceeded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-5264. --- Resolution: Fixed fixed in 15403a1f294bec2f47bd44549594215074fb6c86 > Xenserver - Full Snapshots are not being created even after > snapshot.delta.max is exceeded > -- > > Key: CLOUDSTACK-5264 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5264 > 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 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: edison su >Priority: Blocker > Fix For: 4.3.0 > > Attachments: management-server.rar > > > Snapshots are not being created even after snapshot.delta.max is exceeded. > Set up - Advanced zone with 2 Xenserver 6.2 hosts > Deploy 10 Vms in each of the hosts , so we start with 20 Vms. > We are constantly writing to the ROOT volume ( print timestamp every 1 > minute). > Start concurrent snapshots for ROOT volumes for all the Vms. > Even after 16 snapshots have been created for the ROOT volumes , subsequent > snapshot is still not a FULL snapshot. They continue to be delta snapshot. > mysql> select snapshot_id, > parent_snapshot_id,install_path,store_id,store_role from snapshot_store_ref > where volume_id=89; > +-++-+--++ > | snapshot_id | parent_snapshot_id | install_path >| store_id | store_role | > +-++-+--++ > | 23 | 0 | > snapshots/9/89/8546a63f-dc01-4348-babc-c34c138579c7 |1 | Image | > | 45 | 23 | > snapshots/9/89/9d1404ca-c97e-4f6b-a1a4-3bb5fb1d3900 |1 | Image | > | 105 | 45 | > snapshots/9/89/0323b0cb-446e-4550-a443-d135c4a960b8 |1 | Image | > | 126 |105 | > snapshots/9/89/e440d533-c5cf-464c-940a-505d5b0108c4 |1 | Image | > | 148 |126 | > snapshots/9/89/53f884fb-cd9c-4c35-bcf1-b90f3ce0ea5f |1 | Image | > | 170 |148 | > snapshots/9/89/8ad156ad-e63f-44e1-a8ad-7bcc8acd0b26 |1 | Image | > | 192 |170 | > snapshots/9/89/2781b5af-7c92-482c-8775-f331c7df9b2b |1 | Image | > | 214 |192 | > snapshots/9/89/a2c06f0c-92e4-41b2-a4cb-7d1675146111 |1 | Image | > | 236 |214 | > snapshots/9/89/3bd9fe33-ce59-4148-825f-f9e75e56d088 |1 | Image | > | 258 |236 | > snapshots/9/89/ab414c2b-ed16-4ee2-b3f8-d17b5075fe8d |1 | Image | > | 280 |258 | > snapshots/9/89/cdd97481-d32d-4350-aaae-0a2132c2d934 |1 | Image | > | 302 |280 | > snapshots/9/89/1d82a5a0-1a75-44f3-8a27-dffcf1127b62 |1 | Image | > | 324 |302 | > snapshots/9/89/061043e7-9c22-404c-88e5-183ab4590f5e |1 | Image | > | 346 |324 | > snapshots/9/89/f82e0d43-e83b-493b-b953-6f06a94a369b |1 | Image | > | 368 |346 | > snapshots/9/89/6c0065ad-9fc0-4ce6-957c-0475153c2ed4 |1 | Image | > | 390 |368 | > snapshots/9/89/4399cb51-78a0-4e95-8fc5-8fe2e9e3aa9a |1 | Image | > | 412 |390 | > snapshots/9/89/dd295bd3-1fab-44ad-820e-67a037c828c7 |1 | Image | > | 434 |412 | > snapshots/9/89/afc0ed83-24d5-4373-8e0d-2047d965f1b2 |1 | Image | > | 456 |434 | > snapshots/9/89/88ffc423-a8c6-49c1-8eba-5a91e80c |1 | Image | > | 478 | 0 | 513340d8-d788-4f80-99d4-e8331ce97818 >|1 | Primary| > | 478 |456 | > snapshots/9/89/53d67b21-e6b9-4382-a41e-7c18a7605af0 |1 | Image | > +-++-+--++ > 21 rows in set (0.00 sec) > In secondary store: > -rw-r--r-- 1 root root 7186309632 Nov 22 15:42 > 8546a63f-dc01-4348-babc-c34c138579c7.vhd > -rw-r--r-- 1 root root 155537920 Nov 22 16:36 > 9d1404ca-c97e-4f6b-a1a4-3bb5fb1d3900.vhd > -rw-r--r-- 1 root root 229081600 Nov 24 18:52 > 0323b0cb-446e-4550-a443-d135c4a960b8.vhd > -rw-r--r-- 1 root roo
[jira] [Updated] (CLOUDSTACK-5573) KVM- SSVM/CPVM stuck in "Starting" state Caused by: java.lang.NullPointerException.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-5573:
Summary: KVM- SSVM/CPVM stuck in "Starting" state Caused by:
java.lang.NullPointerException. (was: KVM- SSVM stuck in "Starting" state
Caused by: java.lang.NullPointerException.)
> KVM- SSVM/CPVM stuck in "Starting" state Caused by:
> java.lang.NullPointerException.
> ---
>
> Key: CLOUDSTACK-5573
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5573
> 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
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: kvm-ssvm.rar
>
>
> Set up:
> Advanced zone set up with 2 KVM (rhel 6.3) hosts.
> Few Vms running on both hosts.
> I was testing use cases of bringing down hosts and brings them back up again .
> During this testing , SSVM got stuck in "Starting" state for ever.
> Following exception seen in agent log:
> 2013-12-19 10:28:08,616 ERROR [agent.transport.Request]
> (agentRequest-Handler-5:null) Caught problem with
> [{"com.cloud.agent.api.StartCommand":{"vm":{"id":35,"name":"s-35-MyTestVM","type":"SecondaryStorageVm","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":268435456,"maxRam":268435456,"arch":"x86_64","os":"Debian
> GNU/Linux 5.0 (32-bit)","bootArgs":" template\u003ddomP type\u003dsecstorage
> host\u003d10.223.49.6 port\u003d8250 name\u003ds-35-MyTestVM zone\u003d1
> pod\u003d1 guid\u003ds-35-MyTestVM
> resource\u003dcom.cloud.storage.resource.PremiumSecondaryStorageResource
> instance\u003dSecStorage sslcopy\u003dtrue role\u003dtemplateProcessor
> mtu\u003d1500 eth2ip\u003d10.223.138.133 eth2mask\u003d255.255.255.192
> gateway\u003d10.223.138.129 public.network.device\u003deth2
> eth0ip\u003d169.254.0.251 eth0mask\u003d255.255.0.0 eth1ip\u003d10.223.58.137
> eth1mask\u003d255.255.255.192 mgmtcidr\u003d10.223.49.0/26
> localgw\u003d10.223.58.129 private.network.device\u003deth1
> eth3ip\u003d10.223.58.147 eth3mask\u003d255.255.255.192
> storageip\u003d10.223.58.147 storagenetmask\u003d255.255.255.192
> storagegateway\u003d10.223.58.129 internaldns1\u003d10.223.240.234
> dns1\u003d10.223.240.232","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"6e5928251a8718f6","params":{},"uuid":"db3f9893-d98e-4fb4-a6a4-95f2c95ce407","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"488b20bf-e706-46b9-9039-4dd407aa23ba","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"4aedbaff-1e54-37a2-a150-0b67dbe58ed5","id":3,"poolType":"NetworkFilesystem","host":"10.223.57.195","path":"/export/home/kvm/primary1","port":2049,"url":"NetworkFilesystem://10.223.57.195//export/home/kvm/primary1/?ROLE\u003dPrimary\u0026STOREUUID\u003d4aedbaff-1e54-37a2-a150-0b67dbe58ed5"}},"name":"ROOT-35","size":0,"path":"488b20bf-e706-46b9-9039-4dd407aa23ba","volumeId":35,"vmName":"s-35-MyTestVM","accountId":1,"format":"QCOW2","id":35,"deviceId":0,"hypervisorType":"KVM"}},"diskSeq":0,"path":"488b20bf-e706-46b9-9039-4dd407aa23ba","type":"ROOT","_details":{"managed":"false","storagePort":"2049","storageHost":"10.223.57.195","volumeSize":"0"}}],"nics":[{"deviceId":2,"networkRateMbps":-1,"defaultNic":true,"uuid":"35eb2804-514b-40d5-8e20-a2f423ca2625","ip":"10.223.138.133","netmask":"255.255.255.192","gateway":"10.223.138.129","mac":"06:66:22:00:00:15","dns1":"10.223.240.232","broadcastType":"Vlan","type":"Public","broadcastUri":"vlan://1382","isolationUri":"vlan://1382","isSecurityGroupEnabled":false},{"deviceId":0,"networkRateMbps":-1,"defaultNic":false,"uuid":"ea38c96f-cc88-463b-812e-a4a69b59d7f7","ip":"169.254.0.251","netmask":"255.255.0.0","gateway":"169.254.0.1","mac":"0e:00:a9:fe:00:fb","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false},{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"uuid":"aa865f74-1add-476c-ad0f-86aed6b84155","ip":"10.223.58.137","netmask":"255.255.255.192","gateway":"10.223.58.129","mac":"06:10:f0:00:00:06","broadcastType":"Native","type":"Management","isSecurityGroupEnabled":false},{"deviceId":3,"networkRateMbps":-1,"defaultNic":false,"uuid":"032a8d30-fdf9-493d-ad2c-e3c2627e1869","ip":"10.223.58.147","netmask":"255.255.255.192","gateway":"10.223.58.129","mac":"06:40:ce:00:00:10","broadcastType":"Native","type":"Storage","isSecurityGroupEnabled":false}]},"hostIp":"10.223.58.131","executeInSequence":false,"contextMap":{},"wait":0}},{"com.cloud.agent.api.check.CheckSshCommand":{"ip":"169.25
[jira] [Resolved] (CLOUDSTACK-5370) Xenserver - Snapshots - vhd entries get accumulated on the primary store when snapshot creation fails becasue of not being able to reach the secondary store.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-5370. --- Resolution: Fixed when error happened during snapshot, we need to delete the snapshot on primary storage and also in db. > Xenserver - Snapshots - vhd entries get accumulated on the primary store when > snapshot creation fails becasue of not being able to reach the secondary > store. > - > > Key: CLOUDSTACK-5370 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5370 > 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 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: edison su >Priority: Critical > Fix For: 4.3.0 > > > Set up: > Advanced Zone with 2 Xenserver 6.2 hosts: > 1. Deploy 5 Vms in each of the hosts with 10 GB ROOT volume size , so we > start with 10 Vms. > 2. Start concurrent snapshots for ROOT volumes of all the Vms. > 3. Shutdown the Secondary storage server when the snapshots are in the > progress. ( In my case i stopped the nfs server) > 4. Bring the Secondary storage server up after 12 hours. ( In my case started > the nfs server). > When secondary server was down (NFS server down) for about 12 hours , I see > that hourly snapshots get attempted every hour and fail with > “CreatedOnPrimary" state . I see many entries being created on the primary > store ( I see 120 entries , but I have only 14 vms). > We accumulate 2 vhd files on the primary store for every snapshot that is > attempted. > When secondary store is brought up , and when another snapshot is attempted > and it succeeds, we see the vhd files are all being cleared out. > This is a problem that we accumulate so many vhd files ( In case of vmware > and kvm where there are no delta snapshots this size would be significantly > higher) on primary store. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5573) KVM- SSVM/CPVM stuck in "Starting" state Caused by: java.lang.NullPointerException.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan updated CLOUDSTACK-5573:
Attachment: kvmhost-down-up.rar
> KVM- SSVM/CPVM stuck in "Starting" state Caused by:
> java.lang.NullPointerException.
> ---
>
> Key: CLOUDSTACK-5573
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5573
> 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
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: kvm-ssvm.rar, kvmhost-down-up.rar
>
>
> Set up:
> Advanced zone set up with 2 KVM (rhel 6.3) hosts.
> Few Vms running on both hosts.
> I was testing use cases of bringing down hosts and brings them back up again .
> During this testing , SSVM got stuck in "Starting" state for ever.
> Following exception seen in agent log:
> 2013-12-19 10:28:08,616 ERROR [agent.transport.Request]
> (agentRequest-Handler-5:null) Caught problem with
> [{"com.cloud.agent.api.StartCommand":{"vm":{"id":35,"name":"s-35-MyTestVM","type":"SecondaryStorageVm","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":268435456,"maxRam":268435456,"arch":"x86_64","os":"Debian
> GNU/Linux 5.0 (32-bit)","bootArgs":" template\u003ddomP type\u003dsecstorage
> host\u003d10.223.49.6 port\u003d8250 name\u003ds-35-MyTestVM zone\u003d1
> pod\u003d1 guid\u003ds-35-MyTestVM
> resource\u003dcom.cloud.storage.resource.PremiumSecondaryStorageResource
> instance\u003dSecStorage sslcopy\u003dtrue role\u003dtemplateProcessor
> mtu\u003d1500 eth2ip\u003d10.223.138.133 eth2mask\u003d255.255.255.192
> gateway\u003d10.223.138.129 public.network.device\u003deth2
> eth0ip\u003d169.254.0.251 eth0mask\u003d255.255.0.0 eth1ip\u003d10.223.58.137
> eth1mask\u003d255.255.255.192 mgmtcidr\u003d10.223.49.0/26
> localgw\u003d10.223.58.129 private.network.device\u003deth1
> eth3ip\u003d10.223.58.147 eth3mask\u003d255.255.255.192
> storageip\u003d10.223.58.147 storagenetmask\u003d255.255.255.192
> storagegateway\u003d10.223.58.129 internaldns1\u003d10.223.240.234
> dns1\u003d10.223.240.232","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"6e5928251a8718f6","params":{},"uuid":"db3f9893-d98e-4fb4-a6a4-95f2c95ce407","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"488b20bf-e706-46b9-9039-4dd407aa23ba","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"4aedbaff-1e54-37a2-a150-0b67dbe58ed5","id":3,"poolType":"NetworkFilesystem","host":"10.223.57.195","path":"/export/home/kvm/primary1","port":2049,"url":"NetworkFilesystem://10.223.57.195//export/home/kvm/primary1/?ROLE\u003dPrimary\u0026STOREUUID\u003d4aedbaff-1e54-37a2-a150-0b67dbe58ed5"}},"name":"ROOT-35","size":0,"path":"488b20bf-e706-46b9-9039-4dd407aa23ba","volumeId":35,"vmName":"s-35-MyTestVM","accountId":1,"format":"QCOW2","id":35,"deviceId":0,"hypervisorType":"KVM"}},"diskSeq":0,"path":"488b20bf-e706-46b9-9039-4dd407aa23ba","type":"ROOT","_details":{"managed":"false","storagePort":"2049","storageHost":"10.223.57.195","volumeSize":"0"}}],"nics":[{"deviceId":2,"networkRateMbps":-1,"defaultNic":true,"uuid":"35eb2804-514b-40d5-8e20-a2f423ca2625","ip":"10.223.138.133","netmask":"255.255.255.192","gateway":"10.223.138.129","mac":"06:66:22:00:00:15","dns1":"10.223.240.232","broadcastType":"Vlan","type":"Public","broadcastUri":"vlan://1382","isolationUri":"vlan://1382","isSecurityGroupEnabled":false},{"deviceId":0,"networkRateMbps":-1,"defaultNic":false,"uuid":"ea38c96f-cc88-463b-812e-a4a69b59d7f7","ip":"169.254.0.251","netmask":"255.255.0.0","gateway":"169.254.0.1","mac":"0e:00:a9:fe:00:fb","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false},{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"uuid":"aa865f74-1add-476c-ad0f-86aed6b84155","ip":"10.223.58.137","netmask":"255.255.255.192","gateway":"10.223.58.129","mac":"06:10:f0:00:00:06","broadcastType":"Native","type":"Management","isSecurityGroupEnabled":false},{"deviceId":3,"networkRateMbps":-1,"defaultNic":false,"uuid":"032a8d30-fdf9-493d-ad2c-e3c2627e1869","ip":"10.223.58.147","netmask":"255.255.255.192","gateway":"10.223.58.129","mac":"06:40:ce:00:00:10","broadcastType":"Native","type":"Storage","isSecurityGroupEnabled":false}]},"hostIp":"10.223.58.131","executeInSequence":false,"contextMap":{},"wait":0}},{"com.cloud.agent.api.check.CheckSshCommand":{"ip":"169.254.0.251","port":3922,"interval":6,"retries":100,"name":"s-35-MyTestVM","contextMap":{},"wait":0}}]
> com.google.gson.JsonParseExc
[jira] [Commented] (CLOUDSTACK-5573) KVM- SSVM/CPVM stuck in "Starting" state Caused by: java.lang.NullPointerException.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854492#comment-13854492
]
Sangeetha Hariharan commented on CLOUDSTACK-5573:
-
I see the same kind of behavior where CPVM is stuck in "Starting" state.
Use case that was tested is :
Deploy few HA enabled Vms in each of the hosts .
Power down one of the hosts ( using IPMI).This results in the agent being
shutdown gracefully.
We see that the host gets into "Disconnected" state.
All the Vms that are running in this host continue to be in "Up" state.
After few minutes , power on the host.
All the Vms that are running in this host get marked as "Down" state. SSVM and
CPVM tried to start .SSVM succeeded in started. But CPVM fails to start with
following exception in agent logs:
2013-12-19 18:18:09,126 ERROR [agent.transport.Request]
(agentRequest-Handler-3:null) Caught problem with
[{"com.cloud.agent.api.StartCommand":{"vm":{"id":48,"name":"v-48-MyTestVM","type":
"ConsoleProxy","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":1073741824,"maxRam":1073741824,"arch":"x86_64","os":"Debian
GNU/Linux 5.0 (32-bit)","bootArgs":" template\u003ddomP type\u003
dconsoleproxy host\u003d10.223.49.6 port\u003d8250 name\u003dv-48-MyTestVM
premium\u003dtrue zone\u003d1 pod\u003d1 guid\u003dProxy.48 proxy_vm\u003d48
disable_rp_filter\u003dtrue eth2ip\u
003d10.223.138.132 eth2mask\u003d255.255.255.192 gateway\u003d10.223.138.129
eth0ip\u003d169.254.2.207 eth0mask\u003d255.255.0.0 eth1ip\u003d10.223.58.145
eth1mask\u003d255.255.255.192 mgm
tcidr\u003d10.223.49.0/26 localgw\u003d10.223.58.129
internaldns1\u003d10.223.240.234
dns1\u003d10.223.240.232","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"enableDynamicall
yScaleVm":false,"vncPassword":"489a2854edfb14be","params":{},"uuid":"64cb75cc-23ad-41a9-b192-7e1fdb09ecc7","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"34d1
dac7-40ff-46b3-8003-a7ccbe2ef524","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"4aedbaff-1e54-37a2-a150-0b67dbe58ed5","id":3,"poolType":"N
etworkFilesystem","host":"10.223.57.195","path":"/export/home/kvm/primary1","port":2049,"url":"NetworkFilesystem://10.223.57.195//export/home/kvm/primary1/?ROLE\u003dPrimary\u0026STOREUUID
\u003d4aedbaff-1e54-37a2-a150-0b67dbe58ed5"}},"name":"ROOT-48","size":269367296,"path":"34d1dac7-40ff-46b3-8003-a7ccbe2ef524","volumeId":48,"vmName":"v-48-MyTestVM","accountId":1,"format":
"QCOW2","id":48,"deviceId":0,"hypervisorType":"KVM"}},"diskSeq":0,"path":"34d1dac7-40ff-46b3-8003-a7ccbe2ef524","type":"ROOT","_details":{"managed":"false","storagePort":"2049","storageHos
t":"10.223.57.195","volumeSize":"269367296"}}],"nics":[{"deviceId":2,"networkRateMbps":-1,"defaultNic":true,"uuid":"d604020e-d1d4-4d03-a37c-c0edc4c21fc5","ip":"10.223.138.132","netmask":"2
55.255.255.192","gateway":"10.223.138.129","mac":"06:7d:80:00:00:14","dns1":"10.223.240.232","broadcastType":"Vlan","type":"Public","broadcastUri":"vlan://1382","isolationUri":"vlan://1382
","isSecurityGroupEnabled":false},{"deviceId":0,"networkRateMbps":-1,"defaultNic":false,"uuid":"31f8e128-d429-418b-9038-8edafdbefb9d","ip":"169.254.2.207","netmask":"255.255.0.0","gateway"
:"169.254.0.1","mac":"0e:00:a9:fe:02:cf","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false},{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"uuid":"7b249c6e
-1987-412e-a156-f3f4ab16db17","ip":"10.223.58.145","netmask":"255.255.255.192","gateway":"10.223.58.129","mac":"06:b6:7e:00:00:0e","broadcastType":"Native","type":"Management","isSecurityG
roupEnabled":false}]},"hostIp":"10.223.58.131","executeInSequence":false,"contextMap":{},"wait":0}},{"com.cloud.agent.api.check.CheckSshCommand":{"ip":"169.254.2.207","port":3922,"interval
":6,"retries":100,"name":"v-48-MyTestVM","contextMap":{},"wait":0}}]
com.google.gson.JsonParseException: The JsonDeserializer
com.cloud.agent.transport.InterfaceTypeAdaptor@2e864e43 failed to deserialize
json object {"org.apache.cloudstack.storage.to.Volume
ObjectTO":{"uuid":"34d1dac7-40ff-46b3-8003-a7ccbe2ef524","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"4aedbaff-1e54-37a2-a150-0b67dbe58ed
5","id":3,"poolType":"NetworkFilesystem","host":"10.223.57.195","path":"/export/home/kvm/primary1","port":2049,"url":"NetworkFilesystem://10.223.57.195//export/home/kvm/primary1/?ROLE=Prim
ary&STOREUUID=4aedbaff-1e54-37a2-a150-0b67dbe58ed5"}},"name":"ROOT-48","size":269367296,"path":"34d1dac7-40ff-46b3-8003-a7ccbe2ef524","volumeId":48,"vmName":"v-48-MyTestVM","accountId":1,"
format":"QCOW2","id":48,"deviceId":0,"hypervisorType":"KVM"}} given the type
interface com.cloud.agent.api.to.DataTO
at
com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeserializerExceptionWrapper.java:64)
at
com
[jira] [Resolved] (CLOUDSTACK-5572) HypervisorHelperImpl.quiesceVM() uses snapshot type DiskAndMemory instead of Disk
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-5572. --- Resolution: Fixed > HypervisorHelperImpl.quiesceVM() uses snapshot type DiskAndMemory instead of > Disk > - > > Key: CLOUDSTACK-5572 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5572 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.3.0 >Reporter: Chris Suich >Assignee: edison su > Labels: snapshot > Fix For: 4.3.0 > > Original Estimate: 1m > Remaining Estimate: 1m > > The VMSnapshotTO is currently using VMSnapshot.Type.DiskAndMemory as the type > and I believe it should be just using VMSnapshot.Type.Disk. When using > DiskAndMemory, it causes an issue when quiescing Windows VMs. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5572) HypervisorHelperImpl.quiesceVM() uses snapshot type DiskAndMemory instead of Disk
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854524#comment-13854524 ] ASF subversion and git services commented on CLOUDSTACK-5572: - Commit ddc3d87b4d6ee09633d5829788a7fe6e1b160e58 in branch refs/heads/4.3 from [~edison] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ddc3d87 ] CLOUDSTACK-5572: quicevm won't save memory, as it needs pv driver installed > HypervisorHelperImpl.quiesceVM() uses snapshot type DiskAndMemory instead of > Disk > - > > Key: CLOUDSTACK-5572 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5572 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.3.0 >Reporter: Chris Suich >Assignee: edison su > Labels: snapshot > Fix For: 4.3.0 > > Original Estimate: 1m > Remaining Estimate: 1m > > The VMSnapshotTO is currently using VMSnapshot.Type.DiskAndMemory as the type > and I believe it should be just using VMSnapshot.Type.Disk. When using > DiskAndMemory, it causes an issue when quiescing Windows VMs. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5572) HypervisorHelperImpl.quiesceVM() uses snapshot type DiskAndMemory instead of Disk
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854536#comment-13854536 ] ASF subversion and git services commented on CLOUDSTACK-5572: - Commit e52a4d93067fde04ac7413463cc962ba1998885e in branch refs/heads/master from [~edison] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e52a4d9 ] CLOUDSTACK-5572: quicevm won't save memory, as it needs pv driver installed Conflicts: engine/storage/src/org/apache/cloudstack/storage/helper/HypervisorHelperImpl.java > HypervisorHelperImpl.quiesceVM() uses snapshot type DiskAndMemory instead of > Disk > - > > Key: CLOUDSTACK-5572 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5572 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.3.0 >Reporter: Chris Suich >Assignee: edison su > Labels: snapshot > Fix For: 4.3.0 > > Original Estimate: 1m > Remaining Estimate: 1m > > The VMSnapshotTO is currently using VMSnapshot.Type.DiskAndMemory as the type > and I believe it should be just using VMSnapshot.Type.Disk. When using > DiskAndMemory, it causes an issue when quiescing Windows VMs. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5334) [Automation] Failed to create template from snapshot while executing copy command, observed NPE In SSVM log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su resolved CLOUDSTACK-5334.
---
Resolution: Fixed
fixed in 6e4192dc43dae2547c8c719bf5a9543578e30a89
> [Automation] Failed to create template from snapshot while executing copy
> command, observed NPE In SSVM log
> ---
>
> Key: CLOUDSTACK-5334
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5334
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Template
>Affects Versions: 4.3.0
> Environment: KVM
> Branch 4.3
>Reporter: Rayees Namathponnan
>Assignee: edison su
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: CLOUDSTACK-5334.rar
>
>
> Steps to reproduce
> Step 1 : snapshot root volume
> Step 2 : Create template from snapshot
> Result
> Failed to create template from snapshot, observed below "copy command failure
> and NPE" in MS log and SSVM log
> MS log
> 2013-12-02 08:28:49,406 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
> (Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) copyAsync inspecting src type
> SNAPSHOT copy
> Async inspecting dest type TEMPLATE
> 2013-12-02 08:28:49,418 DEBUG [c.c.a.t.Request]
> (Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) Seq 8-1124074796: Sending { Cmd
> , MgmtId: 29066118877352, via:
> 8(s-5-VM), Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"pa
> th":"snapshots/282/589/d2b20627-b60e-489b-9eee-9f4705331a72","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.223.110.232:/export/home/rayees/S
> C_QA_AUTO4/secondary","_role":"Image"}},"name":"VM-f9e129c2-8d62-4b70-8105-abd304bf7605_ROOT-526_20131202080509","hypervisorType":"KVM","id":20,"quiescevm":
> false}},"destTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/282/236","uuid":"1e48c6bf-388e-4184-93f5-28a21b12329c","id":236
> ,"format":"RAW","accountId":282,"hvm":true,"displayText":"raytemp","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.223.110.232:/export/ho
> me/rayees/SC_QA_AUTO4/secondary","_role":"Image"}},"name":"2c497573e-38cc-3f4d-a73a-49c7b63bbb6c","hypervisorType":"KVM"}},"executeInSequence":false,"wait":
> 10800}}] }
> 2013-12-02 08:28:49,655 DEBUG [c.c.a.t.Request]
> (AgentManager-Handler-14:null) Seq 8-1124074796: Processing: { Ans: ,
> MgmtId: 29066118877352, via: 8, Ver:
> v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"java.lang.NullPointerException\n\tat
> org.apache.cloudstack.storage.resource.NfsSeco
> ndaryStorageResource.copySnapshotToTemplateFromNfsToNfs(NfsSecondaryStorageResource.java:449)\n\tat
> org.apache.cloudstack.storage.resource.NfsSecondaryStora
> geResource.createTemplateFromSnapshot(NfsSecondaryStorageResource.java:546)\n\tat
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute
> (NfsSecondaryStorageResource.java:625)\n\tat
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.j
> ava:236)\n\tat
> com.cloud.storage.resource.PremiumSecondaryStorageResource.defaultAction(PremiumSecondaryStorageResource.java:63)\n\tat
> com.cloud.storage.res
> ource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:59)\n\tat
> com.cloud.agent.Agent.processRequest(Agent.java:498)\n\t
> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:806)\n\tat
> com.cloud.utils.nio.Task.run(Task.java:83)\n\tat
> java.util.concurrent.ThreadPoolEx
> ecutor.runWorker(ThreadPoolExecutor.java:1146)\n\tat
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
> java.lang.Thread.
> run(Thread.java:679)\n","wait":0}}] }
> 2013-12-02 08:28:49,656 DEBUG [c.c.a.t.Request]
> (Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) Seq 8-1124074796: Received: {
> Ans: , MgmtId: 29066118877352, v
> ia: 8, Ver: v1, Flags: 10, { Answer } }
> 2013-12-02 08:28:49,663 DEBUG [c.c.t.TemplateManagerImpl]
> (Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) Failed to create
> templatejava.lang.NullPointerExcepti
> on
> at
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.copySnapshotToTemplateFromNfsToNfs(NfsSecondaryStorageResource.java:449)
> at
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.createTemplateFromSnapshot(NfsSecondaryStorageResource.java:546)
> at
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:625)
> at
> org.apache.cloudstack.storage.resource.N
[jira] [Closed] (CLOUDSTACK-5520) Script errors seen when trying to seed the 64 bit Xenserver templates.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan closed CLOUDSTACK-5520. --- Tested with latest build from 4.3. No errors seen when seeding xenserver templates. [root@rhel64-1 CloudPlatform-4.3-113-rhel6.4]# /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://nfs1.lab.vmops.com/templates/felton_qa/64/systemvm64template-2013-12-16-master-xen.vhd.bz2 -h xenserver -F --2013-12-20 15:46:34-- http://nfs1.lab.vmops.com/templates/felton_qa/64/systemvm64template-2013-12-16-master-xen.vhd.bz2 Resolving nfs1.lab.vmops.com... 10.223.110.231 Connecting to nfs1.lab.vmops.com|10.223.110.231|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 229311649 (219M) [application/x-bzip2] Saving to: â/usr/share/cloudstack-common/scripts/storage/secondary/a324a7b4-c342-4958-8723-218fbb19a086.vhdâ 100%[=>] 229,311,649 89.2M/s in 2.5s 2013-12-20 15:46:36 (89.2 MB/s) - â/usr/share/cloudstack-common/scripts/storage/secondary/a324a7b4-c342-4958-8723-218fbb19a086.vhdâ Uncompressing to /usr/share/cloudstack-common/scripts/storage/secondary/a324a7b4-c342-4958-8723-218fbb19a086.vhd.tmp (type bz2)...could take a long time Moving to /mnt/secondary/template/tmpl/1/1///a324a7b4-c342-4958-8723-218fbb19a086.vhd...could take a while mv: failed to preserve ownership for `//mnt/secondary/template/tmpl/1/1///a324a7b4-c342-4958-8723-218fbb19a086.vhd': Invalid argument Successfully installed system VM template to /mnt/secondary/template/tmpl/1/1/ [root@rhel64-1 CloudPlatform-4.3-113-rhel6.4]# > Script errors seen when trying to seed the 64 bit Xenserver templates. > -- > > Key: CLOUDSTACK-5520 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5520 > 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 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Rajesh Battala >Priority: Critical > Labels: hyper-V, > Fix For: 4.3.0 > > > Following error seen when trying to seed the latest 64 bit template for > Xenserver but the script reports success. > [root@rhel64-1 secondary]# > /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt > -m /mnt/secondary -u > http://nfs1.lab.vmops.com/templates/felton_qa/64/systemvm64template-2013-12-16-master-xen.vhd.bz2 > -h xenserver -F > --2013-12-16 14:30:33-- > http://nfs1.lab.vmops.com/templates/felton_qa/64/systemvm64template-2013-12-16-master-xen.vhd.bz2 > Resolving nfs1.lab.vmops.com... 10.223.110.231 > Connecting to nfs1.lab.vmops.com|10.223.110.231|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 229311649 (219M) [application/x-bzip2] > Saving to: > â/usr/share/cloudstack-common/scripts/storage/secondary/91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhdâ > 100%[==>] > 229,311,649 112M/s in 2.0s > 2013-12-16 14:30:35 (112 MB/s) - > â/usr/share/cloudstack-common/scripts/storage/secondary/91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhdâ > Uncompressing to > /usr/share/cloudstack-common/scripts/storage/secondary/91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhd.tmp > (type bz2)...could take a long time > /usr/share/cloudstack-common/scripts/storage/secondary/createtmplt.sh: line > 207: [: isCifs: integer expression expected > Moving to > /mnt/secondary/template/tmpl/1/1///91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhd...could > take a while > mv: failed to preserve ownership for > `//mnt/secondary/template/tmpl/1/1///91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhd': > Invalid argument > Successfully installed system VM template to > /mnt/secondary/template/tmpl/1/1/ > [root@rhel64-1 secondary]# -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5597) attachVolume shouldn't create the volume on the primary storage if the vm's root volume is not created yet
Alena Prokharchyk created CLOUDSTACK-5597: - Summary: attachVolume shouldn't create the volume on the primary storage if the vm's root volume is not created yet Key: CLOUDSTACK-5597 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5597 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: Alena Prokharchyk Assignee: Alena Prokharchyk Fix For: 4.4.0 In cloudStack you can deploy a vm w/o actually starting it on the backend (startVm=false parameter should be passed to deployVm call to trigger this behavior). When vm is not started during the original deployment, its ROOT volume is not created either. It stays in Allocated state in the DB. Bug: when try to attach data disk to such a vm, current CS code creates it on the primary storage. The fix should be: when check to see if the volume needs to be created on the primary storage, validate the Vm's Root volume state. And if its Allocated, don't create it. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5551) [UI] Search not working in account's setting page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854579#comment-13854579 ] ASF subversion and git services commented on CLOUDSTACK-5551: - Commit 281d8323c555fe8209702f982932a4b03eb94e25 in branch refs/heads/4.3 from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=281d832 ] CLOUDSTACK-5551: Pass search 'name' field to listConfigurations UI Passes search bar value (by 'name') for the settings in the following sections' detail views: -Account -Primary storage -Cluster -Zone > [UI] Search not working in account's setting page > -- > > Key: CLOUDSTACK-5551 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5551 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 > Environment: branch 4.3 >Reporter: Rayees Namathponnan >Assignee: Brian Federle >Priority: Critical > Fix For: 4.3.0 > > > Steps to reproduce > Step 1 : Install Management server with 4.3 build > Step 2 : create an account > Step 3 : select the account -> select setting > Step 4 : In search box, enter > Expected Result > Nothing should be displayed in search result > Actual Result > Search is not working here, same content before search displayed -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5597) attachVolume shouldn't create the volume on the primary storage if the vm's root volume is not created yet
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk resolved CLOUDSTACK-5597. --- Resolution: Fixed > attachVolume shouldn't create the volume on the primary storage if the vm's > root volume is not created yet > -- > > Key: CLOUDSTACK-5597 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5597 > 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: Alena Prokharchyk >Assignee: Alena Prokharchyk > Fix For: 4.4.0 > > > In cloudStack you can deploy a vm w/o actually starting it on the backend > (startVm=false parameter should be passed to deployVm call to trigger this > behavior). When vm is not started during the original deployment, its ROOT > volume is not created either. It stays in Allocated state in the DB. > Bug: when try to attach data disk to such a vm, current CS code creates it on > the primary storage. > The fix should be: when check to see if the volume needs to be created on the > primary storage, validate the Vm's Root volume state. And if its Allocated, > don't create it. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5597) attachVolume shouldn't create the volume on the primary storage if the vm's root volume is not created yet
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854581#comment-13854581 ] ASF subversion and git services commented on CLOUDSTACK-5597: - Commit 1832cf6660085ee253a4daf6eabe0b15843ae1c9 in branch refs/heads/master from [~alena1108] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1832cf6 ] CLOUDSTACK-5597: don't perform data disk allocation on the primary storage when attachVolume calls is made for the vm which ROOT disk hasn't been created yet. > attachVolume shouldn't create the volume on the primary storage if the vm's > root volume is not created yet > -- > > Key: CLOUDSTACK-5597 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5597 > 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: Alena Prokharchyk >Assignee: Alena Prokharchyk > Fix For: 4.4.0 > > > In cloudStack you can deploy a vm w/o actually starting it on the backend > (startVm=false parameter should be passed to deployVm call to trigger this > behavior). When vm is not started during the original deployment, its ROOT > volume is not created either. It stays in Allocated state in the DB. > Bug: when try to attach data disk to such a vm, current CS code creates it on > the primary storage. > The fix should be: when check to see if the volume needs to be created on the > primary storage, validate the Vm's Root volume state. And if its Allocated, > don't create it. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5551) [UI] Search not working in account's setting page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854580#comment-13854580 ] ASF subversion and git services commented on CLOUDSTACK-5551: - Commit 932758e2efd8a0e2776f44a4f14cd65e14c08f1a in branch refs/heads/master from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=932758e ] CLOUDSTACK-5551: Pass search 'name' field to listConfigurations UI Passes search bar value (by 'name') for the settings in the following sections' detail views: -Account -Primary storage -Cluster -Zone > [UI] Search not working in account's setting page > -- > > Key: CLOUDSTACK-5551 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5551 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 > Environment: branch 4.3 >Reporter: Rayees Namathponnan >Assignee: Brian Federle >Priority: Critical > Fix For: 4.3.0 > > > Steps to reproduce > Step 1 : Install Management server with 4.3 build > Step 2 : create an account > Step 3 : select the account -> select setting > Step 4 : In search box, enter > Expected Result > Nothing should be displayed in search result > Actual Result > Search is not working here, same content before search displayed -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-5551) [UI] Search not working in account's setting page
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Federle reassigned CLOUDSTACK-5551:
-
Assignee: Rayees Namathponnan (was: Brian Federle)
Rayees, I fixed the UI for the settings pages' search, however the API is still
not filtering properly when searching by the 'name' field. This needs to be
corrected at the API level.
i.e., if I correctly pass '&name=...' to listConfigurations, I still get every
item:
.../client/api?command=listConfigurations&zoneid=4d4f73aa-5ba6-441d-9001-20f9a5f58a62&response=json&...&name=guest.domain.suffix&listAll=true&page=1&pagesize=20&...
{ "listconfigurationsresponse" : { "count":8 ,"configuration" : [...] } }
> [UI] Search not working in account's setting page
> --
>
> Key: CLOUDSTACK-5551
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5551
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.3.0
> Environment: branch 4.3
>Reporter: Rayees Namathponnan
>Assignee: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.3.0
>
>
> Steps to reproduce
> Step 1 : Install Management server with 4.3 build
> Step 2 : create an account
> Step 3 : select the account -> select setting
> Step 4 : In search box, enter
> Expected Result
> Nothing should be displayed in search result
> Actual Result
> Search is not working here, same content before search displayed
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5544) JS error on snapshot view of storage tab
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854590#comment-13854590
]
ASF subversion and git services commented on CLOUDSTACK-5544:
-
Commit bef63e206794d498d8c9e55d3de18791d8844f00 in branch refs/heads/4.3 from
[~bfederle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bef63e2 ]
CLOUDSTACK-5544: Snapshot action filter: Remove check on volume state
Removes conditional check of volume state for snapshot action filter,
since it causes a null pointer when trying to access view outside the storage
section. Now only '.revertable' attribute is checked. Storage state should now
be verified at the API level only.
> JS error on snapshot view of storage tab
>
>
> Key: CLOUDSTACK-5544
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5544
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.3.0
>Reporter: Chris Suich
>Assignee: Brian Federle
> Labels: ui
> Fix For: 4.3.0
>
>
> In this bit of code:
>var snapshotActionfilter = function(args) {
>var jsonObj = args.context.item;
>if (jsonObj.state == 'Destroyed') {
>return [];
>}
>var allowedActions = [];
>if (jsonObj.state == "BackedUp") {
>allowedActions.push("createTemplate");
>allowedActions.push("createVolume");
>if (jsonObj.revertable && args.context.volumes[0].vmstate ==
> "Stopped") {
>allowedActions.push("revertSnapshot");
>}
>}
>allowedActions.push("remove");
>return allowedActions;
>}
> An error is thrown on the snapshot view of the storage tab if
> jsonObj.revertable is true, since args.context.volumes is undefined when on
> this page.
> We should remove the ' && args.context.volumes[0].vmstate == "Stopped"'
> condition and simply make that check on the server side since the volume/vm
> state information is not available when looking at the snapshots page.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5544) JS error on snapshot view of storage tab
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854591#comment-13854591
]
ASF subversion and git services commented on CLOUDSTACK-5544:
-
Commit 08a69b00535caaa72a5727c595c2de80b8fce202 in branch refs/heads/master
from [~bfederle]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=08a69b0 ]
CLOUDSTACK-5544: Snapshot action filter: Remove check on volume state
Removes conditional check of volume state for snapshot action filter,
since it causes a null pointer when trying to access view outside the storage
section. Now only '.revertable' attribute is checked. Storage state should now
be verified at the API level only.
> JS error on snapshot view of storage tab
>
>
> Key: CLOUDSTACK-5544
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5544
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.3.0
>Reporter: Chris Suich
>Assignee: Brian Federle
> Labels: ui
> Fix For: 4.3.0
>
>
> In this bit of code:
>var snapshotActionfilter = function(args) {
>var jsonObj = args.context.item;
>if (jsonObj.state == 'Destroyed') {
>return [];
>}
>var allowedActions = [];
>if (jsonObj.state == "BackedUp") {
>allowedActions.push("createTemplate");
>allowedActions.push("createVolume");
>if (jsonObj.revertable && args.context.volumes[0].vmstate ==
> "Stopped") {
>allowedActions.push("revertSnapshot");
>}
>}
>allowedActions.push("remove");
>return allowedActions;
>}
> An error is thrown on the snapshot view of the storage tab if
> jsonObj.revertable is true, since args.context.volumes is undefined when on
> this page.
> We should remove the ' && args.context.volumes[0].vmstate == "Stopped"'
> condition and simply make that check on the server side since the volume/vm
> state information is not available when looking at the snapshots page.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5551) [UI] Search not working in account's setting page
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-5551: Assignee: (was: Rayees Namathponnan) > [UI] Search not working in account's setting page > -- > > Key: CLOUDSTACK-5551 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5551 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 > Environment: branch 4.3 >Reporter: Rayees Namathponnan >Priority: Critical > Fix For: 4.3.0 > > > Steps to reproduce > Step 1 : Install Management server with 4.3 build > Step 2 : create an account > Step 3 : select the account -> select setting > Step 4 : In search box, enter > Expected Result > Nothing should be displayed in search result > Actual Result > Search is not working here, same content before search displayed -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5544) JS error on snapshot view of storage tab
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Federle resolved CLOUDSTACK-5544.
---
Resolution: Fixed
> JS error on snapshot view of storage tab
>
>
> Key: CLOUDSTACK-5544
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5544
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.3.0
>Reporter: Chris Suich
>Assignee: Brian Federle
> Labels: ui
> Fix For: 4.3.0
>
>
> In this bit of code:
>var snapshotActionfilter = function(args) {
>var jsonObj = args.context.item;
>if (jsonObj.state == 'Destroyed') {
>return [];
>}
>var allowedActions = [];
>if (jsonObj.state == "BackedUp") {
>allowedActions.push("createTemplate");
>allowedActions.push("createVolume");
>if (jsonObj.revertable && args.context.volumes[0].vmstate ==
> "Stopped") {
>allowedActions.push("revertSnapshot");
>}
>}
>allowedActions.push("remove");
>return allowedActions;
>}
> An error is thrown on the snapshot view of the storage tab if
> jsonObj.revertable is true, since args.context.volumes is undefined when on
> this page.
> We should remove the ' && args.context.volumes[0].vmstate == "Stopped"'
> condition and simply make that check on the server side since the volume/vm
> state information is not available when looking at the snapshots page.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5598) XEN patch/hotfix certification - XS 6.2 SP1 patch installation fail
angeline shen created CLOUDSTACK-5598:
-
Summary: XEN patch/hotfix certification - XS 6.2 SP1 patch
installation fail
Key: CLOUDSTACK-5598
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5598
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: pre-4.0.0
Environment: MS 3.0.7 Patch D
CloudStack-PATCH_D-3.0.7-7-rhel6.3.tar.gz
hostXS 6.2 + hot fix installed :
XS62E001
XS62E002
XS62E004
XS62E005
XS62E007
XS62E008
XS62E009
XS62E010
XS62E011
XS62E012
XS62E013
Reporter: angeline shen
Priority: Critical
Fix For: pre-4.0.0
Per http://wiki-ccp.citrix.com/pages/viewpage.action?pageId=11829631
Xen Patch installation procedure
1. completed steps 1 thru 7 to upgrade master XEN host to XS 6.2 + 6.2 SP1
2. On slave host, perform step 8: on MS put slave host in maintenance mode
Result: On slave host: all guest VMs fail to migrate to master host, slave
host remained in Preparemaintenance mode
MS Log:
2013-12-19 18:51:37,965 DEBUG [cloud.capacity.CapacityManagerImpl]
(HA-Worker-0:work-2) CPU STATS after allocation: for host: 1, old used: 2100,
old reserved: 0, actual total: 9044, total with overprovisioning: 9044; new us
ed:2600, reserved:0; requested cpu:500,alloc_from_last:false
2013-12-19 18:51:37,965 DEBUG [cloud.capacity.CapacityManagerImpl]
(HA-Worker-0:work-2) RAM STATS after allocation: for host: 1, old used:
2818572288, old reserved: 0, total: 16001258112; new used: 3087007744,
reserved: 0;
requested mem: 268435456,alloc_from_last:false
2013-12-19 18:51:37,976 DEBUG [agent.transport.Request] (HA-Worker-0:work-2)
Seq 5-357629969: Waiting for Seq 357629965 Scheduling: { Cmd , MgmtId:
7692017993539, via: 5, Ver: v1, Flags: 100111, [{"MigrateCommand":{"vmName
":"s-1-VM","destIp":"10.223.51.3","hostGuid":"95273a98-5144-42a8-8fb9-2e9761ff2320","isWindows":false,"wait":0}}]
}
2013-12-19 18:51:38,146 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-11:null) Task failed! Task record: uuid:
4ea260eb-f447-cf59-fc0a-ab830d87f9d4
nameLabel: Async.VM.pool_migrate
nameDescription:
allowedOperations: []currentOperations: {} created: Thu Dec
19 18:54:55 PST 2013 finished: Thu Dec 19 18:54:55 PST 2013
status: FAILURE
residentOn: com.xensource.xenapi.Host@6d9f1105
progress: 1.0
type:result: errorInfo:
[VM_REQUIRES_SR, OpaqueRef:b68a7638-2937-58ea-0f5d-52cc3e2f6905,
OpaqueRef:fb25c62b-174a-2a50-fdc0-9ff47c37170c]
otherConfig: {}subtaskOf:
com.xensource.xenapi.Task@aaf13f6f subtasks: [] 2013-12-19
18:51:38,149 WARN [xen.resource.CitrixResourceBase] (DirectAgent-11:null)
Unable to migrate VM(i-2-3-VM) from host(f6c18d41-fa40-440b-932d-f84bf64e5772)
due to Task failed! Task record: uuid:
4ea260eb-f447-cf59-fc0a-ab830d87f9d4
nameLabel: Async.VM.pool_migrate nameDescription:
allowedOperations: []
currentOperations: {}
created: Thu Dec 19 18:54:55 PST 2013
finished: Thu Dec 19 18:54:55 PST 2013
status: FAILURE
residentOn: com.xensource.xenapi.Host@6d9f1105
progress: 1.0
type:
result:
errorInfo: [VM_REQUIRES_SR,
OpaqueRef:b68a7638-2937-58ea-0f5d-52cc3e2f6905,
OpaqueRef:fb25c62b-174a-2a50-fdc0-9ff47c37170c]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
Task failed! Task record: uuid:
4ea260eb-f447-cf59-fc0a-ab830d87f9d4
nameLabel: Async.VM.pool_migrate
nameDescription:
allowedOperations: []
currentOperations: {} created: Thu Dec 19 18:54:55 PST 2013
finished: Thu Dec 19 18:54:55 PST 2013
status: FAILURE
residentOn: com.xensource.xenapi.Host@6d9f1105
progress: 1.0
type:
result:
errorInfo: [VM_REQUIRES_SR,
OpaqueRef:b68a7638-2937-58ea-0f5d-52cc3e2f6905,
OpaqueRef:fb25c62b-174a-2a50-fdc0-9ff47c37170c]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.checkForSuccess(CitrixResourceBase.java:3178)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.migrateVM(CitrixResourceBase.java:3324)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2877)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:441)
at
com.cloud.hypervisor.xen.resource.XenServ
[jira] [Updated] (CLOUDSTACK-3562) UI: VPC network KVM Unable to create VPC tier
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angeline shen updated CLOUDSTACK-3562:
--
Attachment: management-server.log.2013-12-19.gz
Screenshot-CloudPlatform - Mozilla Firefox.png
> UI: VPC network KVM Unable to create VPC tier
> --
>
> Key: CLOUDSTACK-3562
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3562
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.2.0
> Environment: MS 10.223.195.113build
> CloudPlatform-4.2-212-rhel6.3.tar.gz
> host KVM rhel 6.3 build CloudPlatform-4.2-212-rhel6.3.tar.gz
>Reporter: angeline shen
>Assignee: Jessica Wang
>Priority: Blocker
> Fix For: 4.2.0
>
> Attachments: Screenshot-CloudPlatform - Mozilla Firefox.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox-1.png, Screenshot-CloudPlatform™
> - Mozilla Firefox-2.png, Screenshot-CloudPlatform™ - Mozilla Firefox-3.png,
> Screenshot-CloudPlatform™ - Mozilla Firefox.png, a1.png, bm1.png,
> management-server.log.2013-11-13.gz, management-server.log.2013-12-19.gz,
> management-server.log.gz, management-server.log.gz, vms1.png, vms2.png,
> vms3.png
>
>
> 1. advance zone. Create VPC network
> 2. Create Tier
> result: No API was executed. firebug generates error:
> args.$form is undefined
> [Break On This Error] if
> (args.$form.find('.form-item[rel=vlan]').is(':visible')) {
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5577) Remote Access VPN and S2S VPN should be treated as two seperate services for Network Offering creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang updated CLOUDSTACK-5577: --- Fix Version/s: (was: 4.3.0) 4.4.0 > Remote Access VPN and S2S VPN should be treated as two seperate services for > Network Offering creation > -- > > Key: CLOUDSTACK-5577 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5577 > 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: Chandan Purushothama >Assignee: Sheng Yang >Priority: Critical > Fix For: 4.4.0 > > > Currently we treat RemoteAccessVPN and S2S VPN Service as a single VPN > Service on "Create Network Offering" UI box. A VPN Service Provider might not > be in a position to support both services. We need to provide the two > services in the VPN as two seperate capabilities of VPN Service -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5575) Remote Access VPN and S2S VPN should be treated as two seperate services on VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang updated CLOUDSTACK-5575: --- Fix Version/s: (was: 4.3.0) 4.4.0 > Remote Access VPN and S2S VPN should be treated as two seperate services on > VPC > --- > > Key: CLOUDSTACK-5575 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5575 > 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: Chandan Purushothama >Assignee: Sheng Yang >Priority: Critical > Fix For: 4.4.0 > > > Currently we treat RemoteAccessVPN and S2S VPN Service as a single VPN > Service on the VPC. A VPN Service Provider might not be in a position to > support both services. We need to provide the two services in the VPN as two > seperate capabilities of VPN Service -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5281) resource limit shouldnt be counted for resources with display flag = 0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854677#comment-13854677 ] ASF subversion and git services commented on CLOUDSTACK-5281: - Commit f083f91b0bbfceaaf297b3d5c428589df9fd958e in branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f083f91 ] CLOUDSTACK-5281: Resource limit shouldnt be counted for resources with display flag = 0. Correcting this for the vms at the moment. > resource limit shouldnt be counted for resources with display flag = 0 > -- > > Key: CLOUDSTACK-5281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Nitin Mehta >Assignee: Nitin Mehta > Fix For: 4.4.0 > > > Resource limit shouldnt be counted for resources with display flag = 0 > These are resources created by admin and hidden from the end user so shouldnt > count in the resource count or limit while creating/deleting them. But once > the flag is turned on it should start getting counted in the resource count. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5599) [Automation] Test cases failing with "cannot import name cleanup_resources"
Rayees Namathponnan created CLOUDSTACK-5599: --- Summary: [Automation] Test cases failing with "cannot import name cleanup_resources" Key: CLOUDSTACK-5599 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5599 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: Rayees Namathponnan Fix For: 4.3.0 Job ; 228 Regression_Advanced_KVM_60_Multi Many test cases failing with error [root@autoclient1 component]# python test_assign_vm.py Traceback (most recent call last): File "test_assign_vm.py", line 32, in from marvin.integration.lib.common import (get_domain, ImportError: cannot import name cleanup_resources [root@autoclient1 component]# Test cases facing the issue test_assign_vm test_cpu_domain_limits test_cpu_project_limits -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5599) [Automation] Test cases failing with "cannot import name cleanup_resources"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854708#comment-13854708 ] Rayees Namathponnan commented on CLOUDSTACK-5599: - Looks like, this issue happening after below check-in https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=03811c0c46a3c74f4271b08faa8ce40a4e2598f7 Especially -from utils import * + from marvin.sshClient import SshClient -from utils import * -from base import * -from marvin.codes import PASS +import random > [Automation] Test cases failing with "cannot import name cleanup_resources" > --- > > Key: CLOUDSTACK-5599 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5599 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.3.0 >Reporter: Rayees Namathponnan > Fix For: 4.3.0 > > > Job ; 228 Regression_Advanced_KVM_60_Multi > Many test cases failing with error > [root@autoclient1 component]# python test_assign_vm.py > Traceback (most recent call last): > File "test_assign_vm.py", line 32, in > from marvin.integration.lib.common import (get_domain, > ImportError: cannot import name cleanup_resources > [root@autoclient1 component]# > Test cases facing the issue > test_assign_vm > test_cpu_domain_limits > test_cpu_project_limits -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-669) Better VM Sync
[ https://issues.apache.org/jira/browse/CLOUDSTACK-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854713#comment-13854713 ] ASF subversion and git services commented on CLOUDSTACK-669: Commit 497feab84119fabc31768f8a52772fd9e308818f in branch refs/heads/4.3 from [~kelveny] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=497feab ] CLOUDSTACK-669: covert VMsnapshot orchestration flows to make them be serialized with other VM operations > Better VM Sync > -- > > Key: CLOUDSTACK-669 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-669 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Hari Kannan >Assignee: Kelven Yang > Fix For: 4.3.0 > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/VMWare+Enhancements+-+Support+for+DRS+and+VM+HA -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5281) resource limit shouldnt be counted for resources with display flag = 0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854718#comment-13854718 ] ASF subversion and git services commented on CLOUDSTACK-5281: - Commit 6b62a04eaf1196ebcce5e81c29c9e0f59dd4f858 in branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6b62a04 ] CLOUDSTACK-5281: Resource limit shouldnt be counted for resources with display flag = 0. Correcting this for the networks at the moment. > resource limit shouldnt be counted for resources with display flag = 0 > -- > > Key: CLOUDSTACK-5281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Nitin Mehta >Assignee: Nitin Mehta > Fix For: 4.4.0 > > > Resource limit shouldnt be counted for resources with display flag = 0 > These are resources created by admin and hidden from the end user so shouldnt > count in the resource count or limit while creating/deleting them. But once > the flag is turned on it should start getting counted in the resource count. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Closed] (CLOUDSTACK-5259) Xenserver - Not able to create template from snapshot.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan closed CLOUDSTACK-5259.
---
Tested with 64 bit system Vm templates that were generated on 12/16.
We are able to create templates from snapshots successfully.
> Xenserver - Not able to create template from snapshot.
> ---
>
> Key: CLOUDSTACK-5259
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5259
> 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
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: Abhinandan Prateek
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: management-server.rar, xen1-2.rar, xen1.rar, xen2.rar
>
>
> Xenserver - Not able to create template from snapshot.
> Steps to reproduce the problem:
> Set up - Advanced zone with Xenserver 6.2
> Created hourly recurring snapshot.
> Create a template from snapshot.
> Template creation fails with the following exception:
> Failed to create
> template/usr/local/cloud/systemvm/scripts/storage/secondary/create_privatetemplate_from_snapshot_xen.sh:
> line 65: /bin/vhd-util: No such file or directory30#failed to query
> /mnt/SecStorage/8d6190f7-3fc3-3a66-8a8c-bd8e50f2bbc6/snapshots/9/89/a2c06f0c-92e4-41b2-a4cb-7d1675146111.vhd
> We see the following vhd file exist in the secondary store.
> root@nfs3 89]# pwd
> /export/home/sangeetha/felton/xen/secondary/snapshots/9/89
> [root@nfs3 89]# ls -ltr
> total 2579628
> -rw-r--r-- 1 root root 7186309632 Nov 22 15:42
> 8546a63f-dc01-4348-babc-c34c138579c7.vhd
> -rw-r--r-- 1 root root 155537920 Nov 22 16:36
> 9d1404ca-c97e-4f6b-a1a4-3bb5fb1d3900.vhd
> -rw-r--r-- 1 root root 229081600 Nov 24 18:52
> 0323b0cb-446e-4550-a443-d135c4a960b8.vhd
> -rw-r--r-- 1 root root 75690496 Nov 24 19:35
> e440d533-c5cf-464c-940a-505d5b0108c4.vhd
> -rw-r--r-- 1 root root 81994240 Nov 24 20:35
> 53f884fb-cd9c-4c35-bcf1-b90f3ce0ea5f.vhd
> -rw-r--r-- 1 root root 81994240 Nov 24 21:35
> 8ad156ad-e63f-44e1-a8ad-7bcc8acd0b26.vhd
> -rw-r--r-- 1 root root 79892992 Nov 24 22:35
> 2781b5af-7c92-482c-8775-f331c7df9b2b.vhd
> -rw-r--r-- 1 root root 75690496 Nov 24 23:35
> a2c06f0c-92e4-41b2-a4cb-7d1675146111.vhd
> -rw-r--r-- 1 root root 81994240 Nov 25 00:35
> 3bd9fe33-ce59-4148-825f-f9e75e56d088.vhd
> -rw-r--r-- 1 root root 81994240 Nov 25 01:35
> ab414c2b-ed16-4ee2-b3f8-d17b5075fe8d.vhd
> -rw-r--r-- 1 root root 81994240 Nov 25 02:35
> cdd97481-d32d-4350-aaae-0a2132c2d934.vhd
> -rw-r--r-- 1 root root 81994240 Nov 25 03:35
> 1d82a5a0-1a75-44f3-8a27-dffcf1127b62.vhd
> -rw-r--r-- 1 root root 81994240 Nov 25 04:35
> 061043e7-9c22-404c-88e5-183ab4590f5e.vhd
> -rw-r--r-- 1 root root 81994240 Nov 25 05:35
> f82e0d43-e83b-493b-b953-6f06a94a369b.vhd
> -rw-r--r-- 1 root root 84095488 Nov 25 06:35
> 6c0065ad-9fc0-4ce6-957c-0475153c2ed4.vhd
> [root@nfs3 89]#
> Management server logs:
> 2013-11-25 13:01:43,109 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-15:ctx-8576afd8 ctx-2f9b87f6) submit async job-726, details:
> AsyncJobVO {id:726, userI
> d: 2, accountId: 2, instanceType: Template, instanceId: 204, cmd:
> org.apache.cloudstack.api.command.user.template.CreateTemplateCmd, cmdInfo:
> {"sessionkey":"2I2cmFDP
> FQyACWMGWW8h54MGdC0\u003d","cmdEventType":"TEMPLATE.CREATE","ctxUserId":"2","httpmethod":"GET","osTypeId":"e7460654-52fe-11e3-821d-665544288891","isPublic":"true","i
> sdynamicallyscalable":"false","response":"json","id":"204","displayText":"temp99","snapshotid":"b6e507c5-3758-458f-bc98-01e69e2402b0","passwordEnabled":"false","name
> ":"temp99","_":"1385402509285","ctxAccountId":"2","ctxStartEventId":"21369"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, init
> Msid: 112516401760401, completeMsid: null, lastUpdated: null, lastPolled:
> null, created: null}
> 2013-11-25 13:01:43,110 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-15:ctx-8576afd8 ctx-2f9b87f6) ===END=== 10.215.3.7 -- GET
> command=createTemplate&response=json&sess
> ionkey=2I2cmFDPFQyACWMGWW8h54MGdC0%3D&snapshotid=b6e507c5-3758-458f-bc98-01e69e2402b0&name=temp99&displayText=temp99&osTypeId=e7460654-52fe-11e3-821d-665544288891&is
> Public=true&passwordEnabled=false&isdynamicallyscalable=false&_=1385402509285
> 2013-11-25 13:01:43,127 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl]
> (Job-Executor-105:ctx-d53e3263 ctx-2f9b87f6) template 204 is already in
> store:1, type:Image
> 2013-11-25 13:01:43,134 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
> (Job-Executor-105:ctx-d53e3263 ctx-2f9b87f6) copyAsync inspecting src type
> SNAPSHOT copyAsync ins
> pectin
[jira] [Closed] (CLOUDSTACK-5246) Xenserver - Hourly Snapshots - Creating snapshot from ROOT volume fails with NullPointer Exception.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan closed CLOUDSTACK-5246.
---
Tested with latest build from 4.3.
We are able to successfully create snapshots when recurring snapshots are
created.
> Xenserver - Hourly Snapshots - Creating snapshot from ROOT volume fails with
> NullPointer Exception.
> ---
>
> Key: CLOUDSTACK-5246
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5246
> 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
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: Min Chen
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: management-server.rar
>
>
> Xenserver - Hourly Snapshots - Creating snapshot from ROOT volume fails with
> NullPointer Exception.
> Steps to reproduce the problem:
> Advanced zone set up with 2 Xenserver 6.2 hosts
> Deploy 10 vms in each of the hosts.
> Create hourly scheduled snapshot policy for all the above Vm's ROOT volume at
> "15 mts".
> When creation of snapshot is attempted , they all fail with
> NullPointerException:
> 2013-11-21 22:18:02,992 DEBUG [c.c.s.s.SnapshotSchedulerImpl]
> (SnapshotPollTask:ctx-f5933165) Snapshot scheduler.poll is being called
> at 2013-11-22 03:18:02 GMT
> 2013-11-21 22:18:02,994 DEBUG [c.c.s.s.SnapshotSchedulerImpl]
> (SnapshotPollTask:ctx-f5933165) Got 21 snapshots to be executed at 2013-11-22
> 03:18:02 GMT
> 2013-11-21 22:18:03,003 DEBUG [c.c.s.s.SnapshotSchedulerImpl]
> (SnapshotPollTask:ctx-f5933165) Scheduling 1 snapshot for volume 28 for
> schedule id: 1 at 2013-11-22 03:15:00 GMT
> 2013-11-21 22:18:03,113 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (SnapshotPollTask:ctx-f5933165) submit async job-110, details: AsyncJobVO
> {id:110, userId: 1, accountId: 5, instanceType: Snapshot, instanceId: 1, cmd:
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo:
> {"id":"1","ctxUserId":"1","volumeid":"28","ctxAccountId":"5","ctxStartEventId":"1","policyid":"1"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 112516401760401, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2013-11-21 22:18:03,119 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-110:ctx-f6bd4e26) Add job-110 into job monitoring
> 2013-11-21 22:18:03,119 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-110:ctx-f6bd4e26) Executing AsyncJobVO {id:110, userId: 1,
> accountId: 5, instanceType: Snapshot, instanceId: 1, cmd:
> org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd, cmdInfo:
> {"id":"1","ctxUserId":"1","volumeid":"28","ctxAccountId":"5","ctxStartEventId":"1","policyid":"1"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 112516401760401, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2013-11-21 22:18:03,119 ERROR [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-110:ctx-f6bd4e26) Unexpected exception
> java.lang.NullPointerException
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl.getDispatcher(AsyncJobManagerImpl.java:454)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl.access$800(AsyncJobManagerImpl.java:80)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:518)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> 2013-11-21 22:18:03,120 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
[jira] [Closed] (CLOUDSTACK-5279) UI - Not able to list detail view of volumes.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sangeetha Hariharan closed CLOUDSTACK-5279.
---
With latest build from 4.3 , I am able to view the volume detail page now.
> UI - Not able to list detail view of volumes.
> -
>
> Key: CLOUDSTACK-5279
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5279
> 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
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: Jessica Wang
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: test.rar
>
>
> UI - Not able to list detail view of volumes.
> From storage-> list Volume , select any volume to list detail view of the
> volume.
> UI keeps spinning forever.
> Following error seen:
> TypeError: args.context.volumes is undefined
> url: createURL("listVolumes&id=" + args.context.volumes[0].id),
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5600) Xenserver - After HA , CPVM's disk is corrupted resulting in CPVM being stuck in "Starting" state.
Sangeetha Hariharan created CLOUDSTACK-5600: --- Summary: Xenserver - After HA , CPVM's disk is corrupted resulting in CPVM being stuck in "Starting" state. Key: CLOUDSTACK-5600 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5600 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 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Priority: Critical Fix For: 4.3.0 Xenserver - After HA , CPVM's disk is corrupted resulting in CPVM being stucK in "Starting" state. Steps to reproduce the problem: Duplicate or bad block in use! /dev/xvda5: Multiply-claimed block(s) in inode 224: 8455 8456 /dev/xvda5: Multiply-claimed block(s) in inode 2026: 8455 8456 /dev/xvda5: (There are 2 inodes containing multiply-claimed blocks.) /dev/xvda5: File /etc/inittab (inode #224, mod time Sat Dec 21 00:14:41 2013) has 2 multiply-claimed block(s), shared with 1 file(s): /dev/xvda5: /etc/iptables/rules.v4 (inode #2026, mod time Fri Dec 20 22:39:20 2013) /dev/xvda5: /dev/xvda5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options) fsck died with exit status 4 failed (code 4). An automatic file system check (fsck) of the root filesystem failed. A manual fsck must be performed, then the system restarted. The fsck should be performed in maintenance mode with the root filesystem mounted in read-only mode. ... failed! The root filesystem is currently mounted in read-only mode. A maintenance shell will now be started. After performing system maintenance, press CONTROL-D to terminate the maintenance shell and restart the system. ... (warning). Give root password for maintenance (or type Control-D to continue): -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5281) resource limit shouldnt be counted for resources with display flag = 0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13854736#comment-13854736 ] ASF subversion and git services commented on CLOUDSTACK-5281: - Commit ab37009e9015e90f39f001dbc7023ce52319dcff in branch refs/heads/master from [~alexhuang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ab37009 ] Revert "CLOUDSTACK-5281:" This reverts commit 6b62a04eaf1196ebcce5e81c29c9e0f59dd4f858. > resource limit shouldnt be counted for resources with display flag = 0 > -- > > Key: CLOUDSTACK-5281 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5281 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Nitin Mehta >Assignee: Nitin Mehta > Fix For: 4.4.0 > > > Resource limit shouldnt be counted for resources with display flag = 0 > These are resources created by admin and hidden from the end user so shouldnt > count in the resource count or limit while creating/deleting them. But once > the flag is turned on it should start getting counted in the resource count. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5600) Xenserver - After HA , CPVM's disk is corrupted resulting in CPVM being stuck in "Starting" state.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan updated CLOUDSTACK-5600: Description: Xenserver - After HA , CPVM's disk is corrupted resulting in CPVM being stucK in "Starting" state. Steps to reproduce the problem: Set up: Advanced zone with 2 xenserver 6.2 hosts. Steps to reproduce the problem: Deploy few HA enabled Vms in each of the hosts . Disconnect network connectivity on host1 ( ifconfig eth0 down). Host gets marked as down and all Vms gets HA-ed to the other host in the cluster - host2. CPVM got Ha-ed to host2 and worked fine. host1 get rebooted and is marked as "Up" state in CP. Now disconnect network connectivity on host2 ( ifconfig eth0 down). Host gets marked as down and all Vms gets HA-ed to the other host in the cluster - host1. After this HA process , I see that the CPVM is stuck in "Starting" state in CP , but is in "Running" state in Xenserver. When I log into the console of CPVM , we see the following exception suggesting a disk corruption: Duplicate or bad block in use! /dev/xvda5: Multiply-claimed block(s) in inode 224: 8455 8456 /dev/xvda5: Multiply-claimed block(s) in inode 2026: 8455 8456 /dev/xvda5: (There are 2 inodes containing multiply-claimed blocks.) /dev/xvda5: File /etc/inittab (inode #224, mod time Sat Dec 21 00:14:41 2013) has 2 multiply-claimed block(s), shared with 1 file(s): /dev/xvda5: /etc/iptables/rules.v4 (inode #2026, mod time Fri Dec 20 22:39:20 2013) /dev/xvda5: /dev/xvda5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options) fsck died with exit status 4 failed (code 4). An automatic file system check (fsck) of the root filesystem failed. A manual fsck must be performed, then the system restarted. The fsck should be performed in maintenance mode with the root filesystem mounted in read-only mode. ... failed! The root filesystem is currently mounted in read-only mode. A maintenance shell will now be started. After performing system maintenance, press CONTROL-D to terminate the maintenance shell and restart the system. ... (warning). Give root password for maintenance (or type Control-D to continue): was: Xenserver - After HA , CPVM's disk is corrupted resulting in CPVM being stucK in "Starting" state. Steps to reproduce the problem: Duplicate or bad block in use! /dev/xvda5: Multiply-claimed block(s) in inode 224: 8455 8456 /dev/xvda5: Multiply-claimed block(s) in inode 2026: 8455 8456 /dev/xvda5: (There are 2 inodes containing multiply-claimed blocks.) /dev/xvda5: File /etc/inittab (inode #224, mod time Sat Dec 21 00:14:41 2013) has 2 multiply-claimed block(s), shared with 1 file(s): /dev/xvda5: /etc/iptables/rules.v4 (inode #2026, mod time Fri Dec 20 22:39:20 2013) /dev/xvda5: /dev/xvda5: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. (i.e., without -a or -p options) fsck died with exit status 4 failed (code 4). An automatic file system check (fsck) of the root filesystem failed. A manual fsck must be performed, then the system restarted. The fsck should be performed in maintenance mode with the root filesystem mounted in read-only mode. ... failed! The root filesystem is currently mounted in read-only mode. A maintenance shell will now be started. After performing system maintenance, press CONTROL-D to terminate the maintenance shell and restart the system. ... (warning). Give root password for maintenance (or type Control-D to continue): > Xenserver - After HA , CPVM's disk is corrupted resulting in CPVM being stuck > in "Starting" state. > -- > > Key: CLOUDSTACK-5600 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5600 > 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 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Priority: Critical > Fix For: 4.3.0 > > > Xenserver - After HA , CPVM's disk is corrupted resulting in CPVM being stucK > in "Starting" state. > Steps to reproduce the problem: > Set up: > Advanced zone with 2 xenserver 6.2 hosts. > Steps to reproduce the problem: > Deploy few HA enabled Vms in each of the hosts . > Disconnect network connectivity on host1 ( ifconfig eth0 down). > Host gets marked as down and all Vms gets HA-ed to the other host in the > cluster - host2. > CPVM got Ha-ed to host2 and worked fine. > host1 get rebooted and is marked as "Up" state in CP. > Now disconnect network connectivity on host2 ( ifconfig eth0 down). > Host gets marked as down and all Vms gets HA-ed to the other host in the > cluster - host1. > After this HA process , I see th
