[jira] [Commented] (CLOUDSTACK-6055) [Automation] Firewall rule creation failing for portable public IP with error "Failed to create firewall rule"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14034907#comment-14034907 ] Murali Reddy commented on CLOUDSTACK-6055: -- I just ran the test on Vmware setup. I am not running into any issue. > [Automation] Firewall rule creation failing for portable public IP with error > "Failed to create firewall rule" > -- > > Key: CLOUDSTACK-6055 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6055 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.4.0 > Environment: Observed yet on VMWare. >Reporter: Gaurav Aradhye >Assignee: Murali Reddy > Labels: automation > Fix For: 4.4.0 > > Attachments: portableip-Firewall-MgtSrvrLog.txt > > > Steps to reproduce: > 1) Add a portable public IP range > 2) Create an isolated network > 3) Acquire portable IP in the network > 4) Try to create firewall rule for the IP address > Step 4 Fails. > Management Server log attached. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6055) [Automation] Firewall rule creation failing for portable public IP with error "Failed to create firewall rule"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy resolved CLOUDSTACK-6055. -- Resolution: Cannot Reproduce > [Automation] Firewall rule creation failing for portable public IP with error > "Failed to create firewall rule" > -- > > Key: CLOUDSTACK-6055 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6055 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.4.0 > Environment: Observed yet on VMWare. >Reporter: Gaurav Aradhye >Assignee: Murali Reddy > Labels: automation > Fix For: 4.4.0 > > Attachments: portableip-Firewall-MgtSrvrLog.txt > > > Steps to reproduce: > 1) Add a portable public IP range > 2) Create an isolated network > 3) Acquire portable IP in the network > 4) Try to create firewall rule for the IP address > Step 4 Fails. > Management Server log attached. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6931) LXC agent install : hypervisor.type not set
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-6931: -- Fix Version/s: 4.5.0 > LXC agent install : hypervisor.type not set > --- > > Key: CLOUDSTACK-6931 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6931 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > Fix For: 4.5.0 > > > While adding LXC host, hypervisor.type param in agent.properties is not set. > Agent defaults to KVM when the param is not set. cloudstack-agent-setup > script should update hypervisor.type as lxc -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6931) LXC agent install : hypervisor.type not set
Kishan Kavala created CLOUDSTACK-6931: - Summary: LXC agent install : hypervisor.type not set Key: CLOUDSTACK-6931 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6931 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Kishan Kavala Assignee: Kishan Kavala While adding LXC host, hypervisor.type param in agent.properties is not set. Agent defaults to KVM when the param is not set. cloudstack-agent-setup script should update hypervisor.type as lxc -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6906) [Automation] volume resize test cases failing in BVT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14034931#comment-14034931 ] ASF subversion and git services commented on CLOUDSTACK-6906: - Commit 8aea23a4e36559e8113d7bc0427aa950ae8082eb in cloudstack's branch refs/heads/4.4-forward from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8aea23a ] CLOUDSTACK-6906: Fixed volume resize BVT failure > [Automation] volume resize test cases failing in BVT > - > > Key: CLOUDSTACK-6906 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6906 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Rayees Namathponnan >Priority: Critical > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6906) [Automation] volume resize test cases failing in BVT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14034930#comment-14034930 ] ASF subversion and git services commented on CLOUDSTACK-6906: - Commit e65b746b346f33fc4f879479f7e45a081e06f90a in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e65b746 ] CLOUDSTACK-6906: Fixed volume resize BVT failure > [Automation] volume resize test cases failing in BVT > - > > Key: CLOUDSTACK-6906 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6906 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Rayees Namathponnan >Priority: Critical > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6887) [Automation] Test cases not deleting account after complete the test
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14034938#comment-14034938 ] ASF subversion and git services commented on CLOUDSTACK-6887: - Commit 942fc98848855c5ff2f177b251a44b1f2b971a57 in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=942fc98 ] CLOUDSTACK-6887: Code enhancement to ensure better cleanup > [Automation] Test cases not deleting account after complete the test > - > > Key: CLOUDSTACK-6887 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6887 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye > Fix For: 4.4.0 > > > Still there are test cases not deleting account after complete the test, i > can see below account exist in management server , after complete regression, > As per management server log,these account are not even tried to delete the > account > 1) test-account-TestDeployVmWithAffinityGroup-GTFNV7 > 2) test-TestAccountSnapshotClean-C1M23S > 3) test-TestSnapshotLimit-XWVZAT > 4) test-TestVolumes-test_01_volume_iso_attach-C3KHZK > 5) test-TestVolumes-test_create_volume_under_domain-9SC6RP > 6) test-TestVpnUsage-test_01_snapshot_usage-QREFF2 > 7) test-TestVpnUsage-test_01_snapshot_usage-TBKTOK > 8) > test-TestVPCNetworkUpgrade-test_05_create_network_diff_account_1_network_offering-1KF0TL > 9) > test-TestPortableIpTransferAcrossNetworks-test_create_portable_ip_range_non_root_admin-EAKO69 > 10) > test-TestPortableIpTransferAcrossNetworks-test_disassociate_ip_address_other_account-CJJ0S6 > 11)test_add_remove_network_vm-TestUpdateVirtualMachineNIC-test_24_add_nw_different_domain-PKXXHF > 12) test-account-TestVPCNetworkOperations-test_vpc_delete_account-Y28RMP > 13) test-account-TestVPCNetworkOperations-test_vpc_force_delete_domain-NJTE7Y > 14) test-account-TestVPCNetworkOperations-test_vpc_force_delete_domain-9MLF0N > 15) test-TestVPC-test_15_deploy_vm_2-1I5L2M > 16) DoA-TestVPC-test_18_create_net_for_user_diff_domain_by_doadmin-80A4XM > 17) test-TestUserLogin-test_01_non_root_admin_Privileges-MCQ3HG > 18) > test-TestProjectSuspendActivate-test_08_cleanup_after_project_delete-MT8L6G -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6887) [Automation] Test cases not deleting account after complete the test
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14034937#comment-14034937 ] ASF subversion and git services commented on CLOUDSTACK-6887: - Commit 588e3e37afdd5740816d1225d449164ed2024c03 in cloudstack's branch refs/heads/4.4-forward from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=588e3e3 ] CLOUDSTACK-6887: Code enhancement to ensure better cleanup > [Automation] Test cases not deleting account after complete the test > - > > Key: CLOUDSTACK-6887 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6887 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye > Fix For: 4.4.0 > > > Still there are test cases not deleting account after complete the test, i > can see below account exist in management server , after complete regression, > As per management server log,these account are not even tried to delete the > account > 1) test-account-TestDeployVmWithAffinityGroup-GTFNV7 > 2) test-TestAccountSnapshotClean-C1M23S > 3) test-TestSnapshotLimit-XWVZAT > 4) test-TestVolumes-test_01_volume_iso_attach-C3KHZK > 5) test-TestVolumes-test_create_volume_under_domain-9SC6RP > 6) test-TestVpnUsage-test_01_snapshot_usage-QREFF2 > 7) test-TestVpnUsage-test_01_snapshot_usage-TBKTOK > 8) > test-TestVPCNetworkUpgrade-test_05_create_network_diff_account_1_network_offering-1KF0TL > 9) > test-TestPortableIpTransferAcrossNetworks-test_create_portable_ip_range_non_root_admin-EAKO69 > 10) > test-TestPortableIpTransferAcrossNetworks-test_disassociate_ip_address_other_account-CJJ0S6 > 11)test_add_remove_network_vm-TestUpdateVirtualMachineNIC-test_24_add_nw_different_domain-PKXXHF > 12) test-account-TestVPCNetworkOperations-test_vpc_delete_account-Y28RMP > 13) test-account-TestVPCNetworkOperations-test_vpc_force_delete_domain-NJTE7Y > 14) test-account-TestVPCNetworkOperations-test_vpc_force_delete_domain-9MLF0N > 15) test-TestVPC-test_15_deploy_vm_2-1I5L2M > 16) DoA-TestVPC-test_18_create_net_for_user_diff_domain_by_doadmin-80A4XM > 17) test-TestUserLogin-test_01_non_root_admin_Privileges-MCQ3HG > 18) > test-TestProjectSuspendActivate-test_08_cleanup_after_project_delete-MT8L6G -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-1466) [Automation] Limit Resources on domains/accounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14034972#comment-14034972 ] ASF subversion and git services commented on CLOUDSTACK-1466: - Commit e7fe391be4076309a9dc9a0f9bf8ea58181dfa12 in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e7fe391 ] CLOUDSTACK-1466: Automatiion - Primary Storage Limits test cases > [Automation] Limit Resources on domains/accounts > - > > Key: CLOUDSTACK-1466 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1466 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.1.0 >Reporter: Girish Shilamkar >Assignee: Ashutosk Kelkar >Priority: Critical > Fix For: 4.3.0 > > Attachments: LimitResourcesTestPlan1.xlsx > > > Automate attached test plan for feature - Limit resources on domain/accounts > (cpu/memory/primary storage/secondary storage) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6906) [Automation] volume resize test cases failing in BVT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar reassigned CLOUDSTACK-6906: Assignee: Girish Shilamkar > [Automation] volume resize test cases failing in BVT > - > > Key: CLOUDSTACK-6906 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6906 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Rayees Namathponnan >Assignee: Girish Shilamkar >Priority: Critical > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6906) [Automation] volume resize test cases failing in BVT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar resolved CLOUDSTACK-6906. -- Resolution: Fixed Fix Version/s: 4.5.0 > [Automation] volume resize test cases failing in BVT > - > > Key: CLOUDSTACK-6906 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6906 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Rayees Namathponnan >Assignee: Girish Shilamkar >Priority: Critical > Fix For: 4.4.0, 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6780) integration.component.test_portable_ip.TestDisassociatePublicIp.test_disassociate_ip_address_other_account failed during cleanup
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Girish Shilamkar resolved CLOUDSTACK-6780.
--
Resolution: Fixed
Fix Version/s: 4.5.0
> integration.component.test_portable_ip.TestDisassociatePublicIp.test_disassociate_ip_address_other_account
> failed during cleanup
>
>
> Key: CLOUDSTACK-6780
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6780
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.4.0
> Environment: VMware
>Reporter: Ashutosk Kelkar
>Assignee: Ashutosk Kelkar
> Labels: automation
> Fix For: 4.4.0, 4.5.0
>
>
> Warning: Exception during cleanup : Job failed: {jobprocstatus : 0, created :
> u'2014-05-26T14:19:26-0700', cmd :
> u'org.apache.cloudstack.api.command.admin.region.DeletePortableIpRangeCmd',
> userid : u'7fff39d0-e506-11e3-a257-52b2d980df8a', jobstatus : 2, jobid :
> u'2e7ff9e0-b012-42d2-bb9d-46ff18d4325d', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 530, errortext : u"Can't delete portable
> IP range as there are IP's assigned."}, accountid :
> u'7fff2cec-e506-11e3-a257-52b2d980df8a'}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6887) [Automation] Test cases not deleting account after complete the test
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar resolved CLOUDSTACK-6887. -- Resolution: Fixed Fix Version/s: 4.5.0 > [Automation] Test cases not deleting account after complete the test > - > > Key: CLOUDSTACK-6887 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6887 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye > Fix For: 4.4.0, 4.5.0 > > > Still there are test cases not deleting account after complete the test, i > can see below account exist in management server , after complete regression, > As per management server log,these account are not even tried to delete the > account > 1) test-account-TestDeployVmWithAffinityGroup-GTFNV7 > 2) test-TestAccountSnapshotClean-C1M23S > 3) test-TestSnapshotLimit-XWVZAT > 4) test-TestVolumes-test_01_volume_iso_attach-C3KHZK > 5) test-TestVolumes-test_create_volume_under_domain-9SC6RP > 6) test-TestVpnUsage-test_01_snapshot_usage-QREFF2 > 7) test-TestVpnUsage-test_01_snapshot_usage-TBKTOK > 8) > test-TestVPCNetworkUpgrade-test_05_create_network_diff_account_1_network_offering-1KF0TL > 9) > test-TestPortableIpTransferAcrossNetworks-test_create_portable_ip_range_non_root_admin-EAKO69 > 10) > test-TestPortableIpTransferAcrossNetworks-test_disassociate_ip_address_other_account-CJJ0S6 > 11)test_add_remove_network_vm-TestUpdateVirtualMachineNIC-test_24_add_nw_different_domain-PKXXHF > 12) test-account-TestVPCNetworkOperations-test_vpc_delete_account-Y28RMP > 13) test-account-TestVPCNetworkOperations-test_vpc_force_delete_domain-NJTE7Y > 14) test-account-TestVPCNetworkOperations-test_vpc_force_delete_domain-9MLF0N > 15) test-TestVPC-test_15_deploy_vm_2-1I5L2M > 16) DoA-TestVPC-test_18_create_net_for_user_diff_domain_by_doadmin-80A4XM > 17) test-TestUserLogin-test_01_non_root_admin_Privileges-MCQ3HG > 18) > test-TestProjectSuspendActivate-test_08_cleanup_after_project_delete-MT8L6G -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6764) [Marvin]: VM deployment fails in advanced zone when network id is passed while deploying VM and the account contains more than one networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar resolved CLOUDSTACK-6764. -- Resolution: Fixed Fix Version/s: 4.5.0 > [Marvin]: VM deployment fails in advanced zone when network id is passed > while deploying VM and the account contains more than one networks > --- > > Key: CLOUDSTACK-6764 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6764 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 > Environment: All hypervisors >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Fix For: 4.4.0, 4.5.0 > > > When network id is passed while deploying VM in advanced zone, it is not > passed to method "access_ssh_over_nat", hence public associating ip address > fails with "more than one network exists in account". -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6764) [Marvin]: VM deployment fails in advanced zone when network id is passed while deploying VM and the account contains more than one networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye closed CLOUDSTACK-6764. -- > [Marvin]: VM deployment fails in advanced zone when network id is passed > while deploying VM and the account contains more than one networks > --- > > Key: CLOUDSTACK-6764 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6764 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 > Environment: All hypervisors >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Fix For: 4.4.0, 4.5.0 > > > When network id is passed while deploying VM in advanced zone, it is not > passed to method "access_ssh_over_nat", hence public associating ip address > fails with "more than one network exists in account". -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6922) createFireWall and EgressFwRule share the same action event
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy resolved CLOUDSTACK-6922. --- Resolution: Fixed > createFireWall and EgressFwRule share the same action event > --- > > Key: CLOUDSTACK-6922 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6922 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.0.2 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Fix For: 4.4.0 > > > 3 fixes required here. > createFireWall and EgressFwRule share the same action event - why ? This > should be changed. > There is no started and completed action event for createFireWall and the > manager entry method is used by a lot of other apis, so how to put in the > action event annotation ? > deleteFireWallRule - FIREWALL.CLOSE event is used by a bunch of apis. We need > to separate it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6926) Usage service fails to start when java 1.6 is not installed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-6926: Status: Reviewable (was: In Progress) > Usage service fails to start when java 1.6 is not installed > --- > > Key: CLOUDSTACK-6926 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6926 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup, Usage >Affects Versions: 4.2.1 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > > was able to start only after editing JDK_DIRS in /etc/init.d/cloudstack-usage > it is searching only 1.6 java install directories by default -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6926) Usage service fails to start when java 1.6 is not installed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14035548#comment-14035548 ] Rajani Karuturi commented on CLOUDSTACK-6926: - patch on review board > Usage service fails to start when java 1.6 is not installed > --- > > Key: CLOUDSTACK-6926 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6926 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup, Usage >Affects Versions: 4.2.1 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > > was able to start only after editing JDK_DIRS in /etc/init.d/cloudstack-usage > it is searching only 1.6 java install directories by default -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CLOUDSTACK-6926) Usage service fails to start when java 1.6 is not installed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14035548#comment-14035548 ] Rajani Karuturi edited comment on CLOUDSTACK-6926 at 6/18/14 10:17 AM: --- patch on review board https://reviews.apache.org/r/22721/ was (Author: rajanik): patch on review board > Usage service fails to start when java 1.6 is not installed > --- > > Key: CLOUDSTACK-6926 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6926 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup, Usage >Affects Versions: 4.2.1 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > > was able to start only after editing JDK_DIRS in /etc/init.d/cloudstack-usage > it is searching only 1.6 java install directories by default -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6920) Support listing of LBHealthcheck policy with LBHealthcheck policy ID
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14035557#comment-14035557 ] ASF subversion and git services commented on CLOUDSTACK-6920: - Commit 21e452ff4f0459422f0612f2ddf7033a963b0a19 in cloudstack's branch refs/heads/4.4-forward from [~rajesh_battala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=21e452f ] CLOUDSTACK-6920 Support listing of LBHealthcheck policy with LBHealthcheck policy ID > Support listing of LBHealthcheck policy with LBHealthcheck policy ID > > > Key: CLOUDSTACK-6920 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6920 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.4.0 >Reporter: Rajesh Battala >Assignee: Rajesh Battala > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6932) Remove redundant file component/test_escalations.py
Gaurav Aradhye created CLOUDSTACK-6932: -- Summary: Remove redundant file component/test_escalations.py Key: CLOUDSTACK-6932 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6932 Project: CloudStack Issue Type: Task Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.4.0 test_escalations.py file has already been divided into different test suites such as test_escalations_instances.py test_escalations_isos.py test_escalations_snapshots.py test_escalations_volumes.py test_escalations_ipaddresses.py test_escalations_networks.py test_escalations_securitygroups.py test_escalations_templates.py test_escalations_vpncustomergateways.py so the parent file needs to be removed from the repo. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6932) Remove redundant file component/test_escalations.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14035588#comment-14035588 ] ASF subversion and git services commented on CLOUDSTACK-6932: - Commit 7e4303821570d58ad962c85a1a3bd6dbf32f8d73 in cloudstack's branch refs/heads/4.4-forward from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7e43038 ] CLOUDSTACK-6932: Removing redundant file test_escalations.py > Remove redundant file component/test_escalations.py > --- > > Key: CLOUDSTACK-6932 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6932 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.4.0 > > > test_escalations.py file has already been divided into different test suites > such as > test_escalations_instances.py > test_escalations_isos.py > test_escalations_snapshots.py > test_escalations_volumes.py > test_escalations_ipaddresses.py > test_escalations_networks.py > test_escalations_securitygroups.py > test_escalations_templates.py > test_escalations_vpncustomergateways.py > so the parent file needs to be removed from the repo. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6932) Remove redundant file component/test_escalations.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14035590#comment-14035590 ] ASF subversion and git services commented on CLOUDSTACK-6932: - Commit aa5572c0ee5efcc6431b7a48e342b157e5fd33ac in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aa5572c ] CLOUDSTACK-6932: Removing redundant file test_escalations.py > Remove redundant file component/test_escalations.py > --- > > Key: CLOUDSTACK-6932 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6932 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.4.0 > > > test_escalations.py file has already been divided into different test suites > such as > test_escalations_instances.py > test_escalations_isos.py > test_escalations_snapshots.py > test_escalations_volumes.py > test_escalations_ipaddresses.py > test_escalations_networks.py > test_escalations_securitygroups.py > test_escalations_templates.py > test_escalations_vpncustomergateways.py > so the parent file needs to be removed from the repo. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6921) Support listing of LBStickinesspolicy with LBStickiness policy ID
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14035591#comment-14035591 ] Rajesh Battala commented on CLOUDSTACK-6921: fixed by this commit https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=b0d726a872e2859a56ee677c15079cc3a59ab894 > Support listing of LBStickinesspolicy with LBStickiness policy ID > - > > Key: CLOUDSTACK-6921 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6921 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.4.0 >Reporter: Rajesh Battala >Assignee: Rajesh Battala > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6921) Support listing of LBStickinesspolicy with LBStickiness policy ID
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-6921. Resolution: Fixed > Support listing of LBStickinesspolicy with LBStickiness policy ID > - > > Key: CLOUDSTACK-6921 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6921 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.4.0 >Reporter: Rajesh Battala >Assignee: Rajesh Battala > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6920) Support listing of LBHealthcheck policy with LBHealthcheck policy ID
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14035593#comment-14035593 ] ASF subversion and git services commented on CLOUDSTACK-6920: - Commit 6b9ac8be8b38f67c3372fcfd589ee057f362bb78 in cloudstack's branch refs/heads/4.4 from [~rajesh_battala] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6b9ac8b ] CLOUDSTACK-6920 Support listing of LBHealthcheck policy with LBHealthcheck policy ID (cherry picked from commit 21e452ff4f0459422f0612f2ddf7033a963b0a19) Conflicts: api/src/com/cloud/network/lb/LoadBalancingRulesService.java > Support listing of LBHealthcheck policy with LBHealthcheck policy ID > > > Key: CLOUDSTACK-6920 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6920 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.4.0 >Reporter: Rajesh Battala >Assignee: Rajesh Battala > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6272) UI > Instance > actions > make it easy to distinguish between the action that fires recoverVirtualMachine API and the action that fires restoreVirtualMachine API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14035594#comment-14035594 ] ASF subversion and git services commented on CLOUDSTACK-6272: - Commit ab6012f1941ef2f19c1ea97132a349293c46c783 in cloudstack's branch refs/heads/4.3 from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ab6012f ] CLOUDSTACK-6272: Fix recover/restore VM actions -Label recoverVirtualMachine as 'Recover VM' -Label restoreVirtualMachine as 'Reinstall VM' -Change confirmation text for restoreVirtualMachine to be more explicit -Change restoreVirtualMachine icon to 'recycle' symbol, to avoid confusion with the reboot VM icon Conflicts: ui/images/sprites.png ui/scripts/instances.js > UI > Instance > actions > make it easy to distinguish between the action that > fires recoverVirtualMachine API and the action that fires > restoreVirtualMachine API > - > > Key: CLOUDSTACK-6272 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6272 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Brian Federle > Fix For: 4.4.0 > > > (1) Label the action icon that fires recoverVirtualMachine API as "Recover". > Label the action icon that fires restoreVirtualMachine API as > "Reinstall". > (2) change text in confirmation dialog of Reinstall action as: > e.g. "The VM will be reinstalled from template, all current data will be > lost, proceed with caution! Extra data volumes, if any, will not be touched." > (3) Change Reinstall icon to use a 'recycle' symbol, to avoid confusion w/ > reboot VM -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6272) UI > Instance > actions > make it easy to distinguish between the action that fires recoverVirtualMachine API and the action that fires restoreVirtualMachine API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14035596#comment-14035596 ] ASF subversion and git services commented on CLOUDSTACK-6272: - Commit 59353846ec2389f006faa3a59e5d5736147a0a8f in cloudstack's branch refs/heads/4.3 from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5935384 ] CLOUDSTACK-6272: Fix icons for recover/restore VM > UI > Instance > actions > make it easy to distinguish between the action that > fires recoverVirtualMachine API and the action that fires > restoreVirtualMachine API > - > > Key: CLOUDSTACK-6272 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6272 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Brian Federle > Fix For: 4.4.0 > > > (1) Label the action icon that fires recoverVirtualMachine API as "Recover". > Label the action icon that fires restoreVirtualMachine API as > "Reinstall". > (2) change text in confirmation dialog of Reinstall action as: > e.g. "The VM will be reinstalled from template, all current data will be > lost, proceed with caution! Extra data volumes, if any, will not be touched." > (3) Change Reinstall icon to use a 'recycle' symbol, to avoid confusion w/ > reboot VM -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6272) UI > Instance > actions > make it easy to distinguish between the action that fires recoverVirtualMachine API and the action that fires restoreVirtualMachine API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14035595#comment-14035595 ] ASF subversion and git services commented on CLOUDSTACK-6272: - Commit 835ff355069ac57566b6727887927960290b4557 in cloudstack's branch refs/heads/4.3 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=835ff35 ] CLOUDSTACK-6272: UI > Instance > actions > replace internal action name "restore" with "recover", "reset" with "reinstall". > UI > Instance > actions > make it easy to distinguish between the action that > fires recoverVirtualMachine API and the action that fires > restoreVirtualMachine API > - > > Key: CLOUDSTACK-6272 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6272 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Brian Federle > Fix For: 4.4.0 > > > (1) Label the action icon that fires recoverVirtualMachine API as "Recover". > Label the action icon that fires restoreVirtualMachine API as > "Reinstall". > (2) change text in confirmation dialog of Reinstall action as: > e.g. "The VM will be reinstalled from template, all current data will be > lost, proceed with caution! Extra data volumes, if any, will not be touched." > (3) Change Reinstall icon to use a 'recycle' symbol, to avoid confusion w/ > reboot VM -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6928) IOPS throttling setting isn't applied to a dinamically attached volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-6928: -- Assignee: (was: Hugo Trippaers) > IOPS throttling setting isn't applied to a dinamically attached volume > -- > > Key: CLOUDSTACK-6928 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6928 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: Future, 4.4.0 > Environment: CloudStack 4.4-forward w/ KVM deployment > Ubuntu Server 14.04 >Reporter: Yoshikazu Nojima >Priority: Blocker > Labels: KVM > > IOPS throttling setting is NOT applied to a volume attached while VM is > running. > I confirmed the setting is applied to a volume attached while VM is stopped. > attach volume agent log: > 2014-06-17 19:07:22,356 DEBUG [cloud.agent.Agent] > (agentRequest-Handler-3:null) Processing command: > org.apache.cloudstack.storage.command.AttachCommand > 2014-06-17 19:07:22,401 DEBUG [kvm.storage.KVMStorageProcessor] > (agentRequest-Handler-3:null) Attaching device: type='file'> > > file='/mnt/ec7a4ea0-a11f-3ab6-89f5-6c2702e3fcf8/e01df6a7-f832-4616-a151-8ad8bcd4cf64'/> > > > start instance agent log: > 2014-06-17 19:10:47,984 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-1:null) starting i-2-3-VM: > i-2-3-VM > 8fad689b-d63d-4802-81d9-d11acf91b879 > CentOS 5.5 (64-bit) > > > > > > > > > /usr/bin/kvm-spice > > > > > > > > > > > > > passwd='987a62e28e4358d8'/> > > > file='/mnt/e70b1e09-b7e8-3f14-8779-cfb75b651119/b1967fe4-6100-4777-8804-26a349ef06ea'/> > > > > > file='/mnt/ec7a4ea0-a11f-3ab6-89f5-6c2702e3fcf8/92920d85-1190-43ce-af03-5d2f6a6e1004'/> > > > 200 > 200 > > > > > file='/mnt/ec7a4ea0-a11f-3ab6-89f5-6c2702e3fcf8/e01df6a7-f832-4616-a151-8ad8bcd4cf64'/> > > > 200 > 200 > > > > > > > > > > > > > 1048576 > > > > 1 > > hvm > > > > > 1000 > > restart > destroy > destroy > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6928) IOPS throttling setting isn't applied to a dinamically attached volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-6928: -- Assignee: Hugo Trippaers > IOPS throttling setting isn't applied to a dinamically attached volume > -- > > Key: CLOUDSTACK-6928 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6928 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: Future, 4.4.0 > Environment: CloudStack 4.4-forward w/ KVM deployment > Ubuntu Server 14.04 >Reporter: Yoshikazu Nojima >Assignee: Hugo Trippaers >Priority: Blocker > Labels: KVM > > IOPS throttling setting is NOT applied to a volume attached while VM is > running. > I confirmed the setting is applied to a volume attached while VM is stopped. > attach volume agent log: > 2014-06-17 19:07:22,356 DEBUG [cloud.agent.Agent] > (agentRequest-Handler-3:null) Processing command: > org.apache.cloudstack.storage.command.AttachCommand > 2014-06-17 19:07:22,401 DEBUG [kvm.storage.KVMStorageProcessor] > (agentRequest-Handler-3:null) Attaching device: type='file'> > > file='/mnt/ec7a4ea0-a11f-3ab6-89f5-6c2702e3fcf8/e01df6a7-f832-4616-a151-8ad8bcd4cf64'/> > > > start instance agent log: > 2014-06-17 19:10:47,984 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-1:null) starting i-2-3-VM: > i-2-3-VM > 8fad689b-d63d-4802-81d9-d11acf91b879 > CentOS 5.5 (64-bit) > > > > > > > > > /usr/bin/kvm-spice > > > > > > > > > > > > > passwd='987a62e28e4358d8'/> > > > file='/mnt/e70b1e09-b7e8-3f14-8779-cfb75b651119/b1967fe4-6100-4777-8804-26a349ef06ea'/> > > > > > file='/mnt/ec7a4ea0-a11f-3ab6-89f5-6c2702e3fcf8/92920d85-1190-43ce-af03-5d2f6a6e1004'/> > > > 200 > 200 > > > > > file='/mnt/ec7a4ea0-a11f-3ab6-89f5-6c2702e3fcf8/e01df6a7-f832-4616-a151-8ad8bcd4cf64'/> > > > 200 > 200 > > > > > > > > > > > > > 1048576 > > > > 1 > > hvm > > > > > 1000 > > restart > destroy > destroy > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6892) Database HA Config prevents mgmt server from starting
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-6892: -- Assignee: Hugo Trippaers > Database HA Config prevents mgmt server from starting > - > > Key: CLOUDSTACK-6892 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6892 > 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: Future, 4.3.0, 4.4.0 > Environment: MySQL configured for DB HA >Reporter: Adrian Lewis >Assignee: Hugo Trippaers >Priority: Critical > > When configuring the database HA feature introduced in 4.3, the manangement > server fails to create the DB connection due to the mysql connector jar being > loaded using tomcat's common class loader but the > "cloud-plugin-database-mysqlha-4.3.0.jar" is loaded by the webapp class > loader. > The cloud-plugin-database-mysqlha-4.3.0.jar needs to also be loaded from the > common class loader instead of webapp class loader. > Fix is to declare the cloud-plugin-database-mysqlha-4.3.0.jar under the > common.loader section in /etc/cloudstack/management/catalina.properties. > Only tested using a fresh install on Centos 6.5 and the public repo packages. > Manual fix provided by Damoder Reddy in users mailing list: "Looks like we > did not change the catalina.properties while refactoring out the mysql > connector part" -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6928) IOPS throttling setting isn't applied to a dinamically attached volume
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-6928: -- Priority: Critical (was: Blocker) > IOPS throttling setting isn't applied to a dinamically attached volume > -- > > Key: CLOUDSTACK-6928 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6928 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: Future, 4.4.0 > Environment: CloudStack 4.4-forward w/ KVM deployment > Ubuntu Server 14.04 >Reporter: Yoshikazu Nojima >Priority: Critical > Labels: KVM > > IOPS throttling setting is NOT applied to a volume attached while VM is > running. > I confirmed the setting is applied to a volume attached while VM is stopped. > attach volume agent log: > 2014-06-17 19:07:22,356 DEBUG [cloud.agent.Agent] > (agentRequest-Handler-3:null) Processing command: > org.apache.cloudstack.storage.command.AttachCommand > 2014-06-17 19:07:22,401 DEBUG [kvm.storage.KVMStorageProcessor] > (agentRequest-Handler-3:null) Attaching device: type='file'> > > file='/mnt/ec7a4ea0-a11f-3ab6-89f5-6c2702e3fcf8/e01df6a7-f832-4616-a151-8ad8bcd4cf64'/> > > > start instance agent log: > 2014-06-17 19:10:47,984 DEBUG [kvm.resource.LibvirtComputingResource] > (agentRequest-Handler-1:null) starting i-2-3-VM: > i-2-3-VM > 8fad689b-d63d-4802-81d9-d11acf91b879 > CentOS 5.5 (64-bit) > > > > > > > > > /usr/bin/kvm-spice > > > > > > > > > > > > > passwd='987a62e28e4358d8'/> > > > file='/mnt/e70b1e09-b7e8-3f14-8779-cfb75b651119/b1967fe4-6100-4777-8804-26a349ef06ea'/> > > > > > file='/mnt/ec7a4ea0-a11f-3ab6-89f5-6c2702e3fcf8/92920d85-1190-43ce-af03-5d2f6a6e1004'/> > > > 200 > 200 > > > > > file='/mnt/ec7a4ea0-a11f-3ab6-89f5-6c2702e3fcf8/e01df6a7-f832-4616-a151-8ad8bcd4cf64'/> > > > 200 > 200 > > > > > > > > > > > > > 1048576 > > > > 1 > > hvm > > > > > 1000 > > restart > destroy > destroy > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6923) deleteLBStickinessPolicy takes in the id of stickiness policy but the list stickiness policy doesn't take the stickiness id
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14035624#comment-14035624 ] ASF subversion and git services commented on CLOUDSTACK-6923: - Commit 335f165b5bc423065600473023033d33d70ced0a in cloudstack's branch refs/heads/4.4 from Jayapal [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=335f165 ] CLOUDSTACK-6923: updated listLBStickinessPolicies API to list using stickinesspolicy id (cherry picked from commit b0d726a872e2859a56ee677c15079cc3a59ab894) Conflicts: api/src/com/cloud/network/lb/LoadBalancingRulesService.java > deleteLBStickinessPolicy takes in the id of stickiness policy but the list > stickiness policy doesn't take the stickiness id > --- > > Key: CLOUDSTACK-6923 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6923 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.0.2 >Reporter: Jayapal Reddy >Assignee: Jayapal Reddy > Fix For: 4.4.0 > > > deleteLBStickinessPolicy takes in the id of stickiness policy but the list > stickiness policy doesn't take the stickiness id. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (CLOUDSTACK-6496) addHost fails for XenServer with vSwitch networking
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doug Clark reopened CLOUDSTACK-6496:
This is a behaviour change in 4.4 that could be confusing to CS users. If
adding XS hosts with vSwitch network backend is not permitted in 4.4 basic mode
that is ok but there should be a clear error reported telling the user why the
addHost operation has failed.
This change in behaviour has also been discussed on the mailing list:
http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201405.mbox/%3cCAGQtxvYw65a1qJ+nL80UW1ecZAyviqK=Du+5LeB=ng5v6iy...@mail.gmail.com%3e
> addHost fails for XenServer with vSwitch networking
> ---
>
> Key: CLOUDSTACK-6496
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6496
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: XenServer
>Affects Versions: Future, 4.4.0
> Environment: MS: ACS Master
> (http://jenkins.buildacloud.org/job/package-rhel63-master/2647)
> XenServer 6.2
>Reporter: Doug Clark
>Assignee: Anthony Xu
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: management-server.log
>
>
> Attempt to add a XenServer host (with the default vSwitch networking) to a
> Basic Networking Zone fails. Adding a XenServer host configured to use
> bridge works ok.
> From MS log (attached):
> {noformat}
> 2014-04-24 13:41:07,361 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-1:ctx-3e360a0c) Failed to configure brige firewall
> 2014-04-24 13:41:07,361 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-1:ctx-3e360a0c) Check host 10.81.40.102 for CSP is installed or
> not and check network mode for bridge
> 2014-04-24 13:41:07,361 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-1:ctx-3e360a0c) Seq 1-7133701809754865665: Response Received:
> 2014-04-24 13:41:07,363 DEBUG [c.c.a.t.Request] (DirectAgent-1:ctx-3e360a0c)
> Seq 1-7133701809754865665: Processing: { Ans: , MgmtId: 275410316893143,
> via: 1, Ver: v1, Flags: 110, [{"com.cloud.agent.api.Set
> upAnswer":{"_reconnect":true,"result":false,"details":"Failed to configure
> brige firewall","wait":0}}] }
> 2014-04-24 13:41:07,363 DEBUG [c.c.a.t.Request] (catalina-exec-2:ctx-407da4e1
> ctx-e02434c0 ctx-a13beb18) Seq 1-7133701809754865665: Received: { Ans: ,
> MgmtId: 275410316893143, via: 1, Ver: v1, Flags: 110,
> { SetupAnswer } }
> 2014-04-24 13:41:07,363 WARN [c.c.h.x.d.XcpServerDiscoverer]
> (catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Unable to setup
> agent 1 due to Failed to configure brige firewall
> 2014-04-24 13:41:07,364 INFO [c.c.u.e.CSExceptionErrorCode]
> (catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Could not find
> exception: com.cloud.exception.ConnectionException in error code list for
> exceptions
> 2014-04-24 13:41:07,364 WARN [c.c.a.m.AgentManagerImpl]
> (catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Monitor
> XcpServerDiscoverer says there is an error in the connect process for 1 due
> to Reini
> tialize agent after setup.
> 2014-04-24 13:41:07,364 INFO [c.c.a.m.AgentManagerImpl]
> (catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Host 1 is
> disconnecting with event AgentDisconnected
> 2014-04-24 13:41:07,364 DEBUG [c.c.a.m.AgentAttache]
> (DirectAgent-1:ctx-3e360a0c) Seq 1-7133701809754865665: No more commands found
> 2014-04-24 13:41:07,366 DEBUG [c.c.a.m.AgentManagerImpl]
> (catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) The next status of
> agent 1is Alert, current status is Connecting
> 2014-04-24 13:41:07,366 DEBUG [c.c.a.m.AgentManagerImpl]
> (catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Deregistering link
> for 1 with state Alert
> 2014-04-24 13:41:07,366 DEBUG [c.c.a.m.AgentManagerImpl]
> (catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Remove Agent : 1
> {noformat}
> ...snip...
> {noformat}
> 2014-04-24 13:41:07,460 DEBUG [c.c.a.m.AgentManagerImpl]
> (catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Sending Disconnect
> to listener: com.cloud.network.router.VirtualNetworkApplianceManagerImpl
> 2014-04-24 13:41:07,460 DEBUG [c.c.h.Status] (catalina-exec-2:ctx-407da4e1
> ctx-e02434c0 ctx-a13beb18) Transition:[Resource state = Enabled, Agent event
> = AgentDisconnected, Host id = 1, name = xrtuk-09-03]
> 2014-04-24 13:41:07,766 DEBUG [c.c.a.m.ClusteredAgentManagerImpl]
> (catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Notifying other
> nodes of to disconnect
> 2014-04-24 13:41:07,770 WARN [c.c.r.ResourceManagerImpl]
> (catalina-exec-2:ctx-407da4e1 ctx-e02434c0 ctx-a13beb18) Unable to connect
> due to
> com.cloud.exception.ConnectionException: Reinitialize agent after setup.
> at
[jira] [Resolved] (CLOUDSTACK-6932) Remove redundant file component/test_escalations.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye resolved CLOUDSTACK-6932. Resolution: Fixed > Remove redundant file component/test_escalations.py > --- > > Key: CLOUDSTACK-6932 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6932 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.4.0 > > > test_escalations.py file has already been divided into different test suites > such as > test_escalations_instances.py > test_escalations_isos.py > test_escalations_snapshots.py > test_escalations_volumes.py > test_escalations_ipaddresses.py > test_escalations_networks.py > test_escalations_securitygroups.py > test_escalations_templates.py > test_escalations_vpncustomergateways.py > so the parent file needs to be removed from the repo. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6932) Remove redundant file component/test_escalations.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye closed CLOUDSTACK-6932. -- > Remove redundant file component/test_escalations.py > --- > > Key: CLOUDSTACK-6932 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6932 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.4.0 > > > test_escalations.py file has already been divided into different test suites > such as > test_escalations_instances.py > test_escalations_isos.py > test_escalations_snapshots.py > test_escalations_volumes.py > test_escalations_ipaddresses.py > test_escalations_networks.py > test_escalations_securitygroups.py > test_escalations_templates.py > test_escalations_vpncustomergateways.py > so the parent file needs to be removed from the repo. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6933) registering an iso fails in KVM deployment.
Bharat Kumar created CLOUDSTACK-6933: Summary: registering an iso fails in KVM deployment. Key: CLOUDSTACK-6933 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6933 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Environment: KVM advanced network Reporter: Bharat Kumar Fix For: 4.4.0 registing an iso fails with the connection refused error in KVM deployment. below are the iptable rules on the relevant SSVM in the env. Chain INPUT (policy DROP 28 packets, 1340 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 0 0 ACCEPT tcp -- eth1 * 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:3922 172 13277 ACCEPT all -- eth0 * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 4122 469K ACCEPT all -- eth1 * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 196 10976 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 0 0 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 3 180 ACCEPT tcp -- eth0 * 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 511 packets, 81586 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * eth10.0.0.0/0 172.16.88.0/24 state NEW tcp 2576 155K ACCEPT tcp -- * eth10.0.0.0/0 172.16.88.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 root@s-54-QA:~# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 172.16.171.10.0.0.0 UG0 00 eth2 169.254.0.0 0.0.0.0 255.255.0.0 U 0 00 eth0 172.16.88.0 0.0.0.0 255.255.255.0 U 0 00 eth1 172.16.88.0 0.0.0.0 255.255.255.0 U 0 00 eth3 172.16.171.00.0.0.0 255.255.255.0 U 0 00 eth2 As per the above config when a packet is sent to 172.16.88.x/24 subnet we are routing it via interface eth1. but we also have a reject rule in the OUTPUT chain for the packets leaving from eth1. as a result the packets get dropped. if we interchange the routes i.e. if the route related to eth3 is hit before hitting the eth1 route the register iso is successful. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6911) [Automation] volume attachment test cases failing from "test_escalations*" suite in KVM runs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Girish Shilamkar resolved CLOUDSTACK-6911.
--
Resolution: Not a Problem
> [Automation] volume attachment test cases failing from "test_escalations*"
> suite in KVM runs
>
>
> Key: CLOUDSTACK-6911
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6911
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.4.0
> Environment: KVM
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
>Priority: Critical
> Fix For: 4.4.0
>
>
> There are few new test cases start with name "test_escalations" added
> integration suite, in this suite few test cases trying attach volume to vm,
> and fails with below error
> Error Message
> Job failed: {jobprocstatus : 0, created : u'2014-06-12T17:37:10-0700', cmd :
> u'org.apache.cloudstack.api.command.user.iso.AttachIsoCmd', userid :
> u'86bb71c1-6592-4ed7-8ed1-f97939fcf81d', jobstatus : 2, jobid :
> u'a5275b8d-d24f-4ab6-86f2-b063ab8f9600', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 530, errortext : u'Cannot attach
> Xenserver PV drivers to incompatible hypervisor KVM'}, accountid :
> u'6e632b6b-739d-4b60-b4c6-153402cd243f'}
> >> begin captured stdout << -
> === TestName: test_13_attach_detach_iso | Status : EXCEPTION ===
> - >> end captured stdout << --
> Test cases failed
> integration.component.test_escalations.TestInstances.test_13_attach_detach_iso
>
> integration.component.test_escalations.TestVolumes.test_06_volume_snapshot_policy_hourly
> integration.component.test_escalations.TestVolumes.test_07_volume_snapshot_policy
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6911) [Automation] volume attachment test cases failing from "test_escalations*" suite in KVM runs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14035698#comment-14035698
]
Girish Shilamkar commented on CLOUDSTACK-6911:
--
The test is skipped for KVM with the commit:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=89c35abb4db0f362f9159ea39a6eb70ad4351921
> [Automation] volume attachment test cases failing from "test_escalations*"
> suite in KVM runs
>
>
> Key: CLOUDSTACK-6911
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6911
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.4.0
> Environment: KVM
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
>Priority: Critical
> Fix For: 4.4.0
>
>
> There are few new test cases start with name "test_escalations" added
> integration suite, in this suite few test cases trying attach volume to vm,
> and fails with below error
> Error Message
> Job failed: {jobprocstatus : 0, created : u'2014-06-12T17:37:10-0700', cmd :
> u'org.apache.cloudstack.api.command.user.iso.AttachIsoCmd', userid :
> u'86bb71c1-6592-4ed7-8ed1-f97939fcf81d', jobstatus : 2, jobid :
> u'a5275b8d-d24f-4ab6-86f2-b063ab8f9600', jobresultcode : 530, jobresulttype :
> u'object', jobresult : {errorcode : 530, errortext : u'Cannot attach
> Xenserver PV drivers to incompatible hypervisor KVM'}, accountid :
> u'6e632b6b-739d-4b60-b4c6-153402cd243f'}
> >> begin captured stdout << -
> === TestName: test_13_attach_detach_iso | Status : EXCEPTION ===
> - >> end captured stdout << --
> Test cases failed
> integration.component.test_escalations.TestInstances.test_13_attach_detach_iso
>
> integration.component.test_escalations.TestVolumes.test_06_volume_snapshot_policy_hourly
> integration.component.test_escalations.TestVolumes.test_07_volume_snapshot_policy
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-6934) NPE at VolumeOrchestrator.java:868 during vm expunge when vm has volumes in Allocated state (not created on storage yet)
Alena Prokharchyk created CLOUDSTACK-6934: - Summary: NPE at VolumeOrchestrator.java:868 during vm expunge when vm has volumes in Allocated state (not created on storage yet) Key: CLOUDSTACK-6934 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6934 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Fix For: 4.5.0 Steps to reproduce: 1) Deploy 2 vms; VM2 should be deployed with startVm=false option. 2) Stop VM1. Detach the Root disks from VM1 and VM2; attach the root disk of VM2 to VM1. 3) Try to expunge the VM1 now. NPE happens on INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-2:ctx-228bd156 job-890/job-892) Remove job-892 from job monitoring WARN [c.c.v.UserVmManagerImpl] (UserVm-Scavenger-1:ctx-d72384e8) Unable to expunge VM[User|i-2-24-st] java.lang.NullPointerException at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.disconnectVolumesFromHost(VolumeOrchestrator.java:868) at com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:528) at com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:464) at com.cloud.vm.UserVmManagerImpl.expunge(UserVmManagerImpl.java:1670) at com.cloud.vm.UserVmManagerImpl.expungeVm(UserVmManagerImpl.java:3691) NPE happens because in the code we assume that when VM has not null hostId/lastHostId (indicating it had been running at some point), then its volumes should have not null storagepoolId. This assumption is incorrect, and we should check storagePoolId of the volume first before attempting to disconnect it from the host. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6935) Some storage pool filter is not enabled in ZoneWideStoragePoolAllocator
Yoshikazu Nojima created CLOUDSTACK-6935: Summary: Some storage pool filter is not enabled in ZoneWideStoragePoolAllocator Key: CLOUDSTACK-6935 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6935 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Storage Controller Reporter: Yoshikazu Nojima Assignee: Yoshikazu Nojima Some storage pool filtering logic like hypervisor type check, storage type check for root volume and avoid list check is not enabled in ZoneWideStoragePoolAllocator. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6935) Some storage pool filter is not enabled in ZoneWideStoragePoolAllocator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14035963#comment-14035963 ] ASF subversion and git services commented on CLOUDSTACK-6935: - Commit 31de58edab563eb1cb50c5c06437fdd3efc6a3d2 in cloudstack's branch refs/heads/master from [~ynojima] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=31de58e ] CLOUDSTACK-6935 refactor StoragePoolAllocator#filter logic to support IOPS capacity control in a cluster wide storage pool and a local storage pool to enable hypervisor type check, storage type check for root volume and avoid list check > Some storage pool filter is not enabled in ZoneWideStoragePoolAllocator > --- > > Key: CLOUDSTACK-6935 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6935 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Storage Controller >Reporter: Yoshikazu Nojima >Assignee: Yoshikazu Nojima > > Some storage pool filtering logic like hypervisor type check, storage type > check for root volume and avoid list check is not enabled in > ZoneWideStoragePoolAllocator. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6935) Some storage pool filter is not enabled in ZoneWideStoragePoolAllocator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036039#comment-14036039 ] ASF subversion and git services commented on CLOUDSTACK-6935: - Commit cd414a0f56798ae801fc464be127e37daabef809 in cloudstack's branch refs/heads/4.4-forward from [~ynojima] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cd414a0 ] CLOUDSTACK-6935 refactor StoragePoolAllocator#filter logic to support IOPS capacity control in a cluster wide storage pool and a local storage pool to enable hypervisor type check, storage type check for root volume and avoid list check > Some storage pool filter is not enabled in ZoneWideStoragePoolAllocator > --- > > Key: CLOUDSTACK-6935 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6935 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Storage Controller >Reporter: Yoshikazu Nojima >Assignee: Yoshikazu Nojima > > Some storage pool filtering logic like hypervisor type check, storage type > check for root volume and avoid list check is not enabled in > ZoneWideStoragePoolAllocator. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6602) [UI] createNetworkACL API action param value passed incorrectly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi resolved CLOUDSTACK-6602. Resolution: Fixed Resolving based on commits > [UI] createNetworkACL API action param value passed incorrectly > --- > > Key: CLOUDSTACK-6602 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6602 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.4.0 >Reporter: Jayapal Reddy >Assignee: Jessica Wang >Priority: Blocker > Fix For: 4.4.0 > > Attachments: regression_caused_by.PNG > > > createNetworkACL&response=json&sessionkey=9PnsnXugAKpfi24BgcTNguWYMt0%3D&number=1&cidrlist=0.0.0.0%2F0&action=label.allow&protocol=tcp&startport=22&endport=22&traffictype=Ingress&aclid=f3022110-80fc-4f77-943c-33f7103a6aa3&_=1399524604770 > The action parameter from UI is passed incorrectly 'label.allow'. It supposed > to 'allow' or 'deny'. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6842) [Automation] Detach volume fails with LibvirtException: Storage pool not found: no storage pool with matching uuid
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036066#comment-14036066
]
Animesh Chaturvedi commented on CLOUDSTACK-6842:
Edison do you mind checking this issue?
> [Automation] Detach volume fails with LibvirtException: Storage pool not
> found: no storage pool with matching uuid
> --
>
> Key: CLOUDSTACK-6842
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6842
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Volumes
>Affects Versions: 4.4.0
> Environment: KVM - RHEL 6.3
> Branch - 4.4-forward
>Reporter: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: CLOUDSTACK-6842.rar
>
>
> This issue is observed during KVM automation run, test cases failed during
> detach volume operation below exception
> 2014-06-03 22:51:27,825 DEBUG [c.c.n.NetworkModelImpl]
> (Network-Scavenger-1:ctx-355fa5da) Network id=221 is not ready for GC
> as it has vms that are Starting at the moment
> 2014-06-03 22:51:27,878 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-18:ctx-673fdee8) ===START=== 10.223.240.194 -- GET jobid=18
> 3bb2f8-adac-4577-a19c-a7df2a31b0b6&apiKey=fRS2dHRVFlXSTC9bs2rBKXwD0FNnpHk-Dz_2XI8fgFZii_P6Tx5eLyzluOx8lvuonsbqknPHnIFYT5xNhEv
> UEA&command=queryAsyncJobResult&response=json&signature=PNHiNNyW76saC8ZAnPwgL89sx9w%3D
> 2014-06-03 22:51:27,893 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-18:ctx-673fdee8 ctx-2f4bea09 ctx-49740006) ===END=== 10.223.
> 240.194 -- GET
> jobid=183bb2f8-adac-4577-a19c-a7df2a31b0b6&apiKey=fRS2dHRVFlXSTC9bs2rBKXwD0FNnpHk-Dz_2XI8fgFZii_P6Tx5eLyzluOx
> 8lvuonsbqknPHnIFYT5xNhEvUEA&command=queryAsyncJobResult&response=json&signature=PNHiNNyW76saC8ZAnPwgL89sx9w%3D
> 2014-06-03 22:51:28,502 DEBUG [c.c.a.t.Request]
> (AgentManager-Handler-12:null) Seq 1-7390406988514984214: Processing: { Ans:
> , MgmtId: 29066118877352, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"com.cloud.ut
> ils.exception.CloudRuntimeException: org.libvirt.LibvirtException: Storage
> pool not found: no storage pool with matching uuid
> \n\tat
> com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.getStoragePool(LibvirtStorageAdaptor.java:389)\n\tat
> com.cloud.
> hypervisor.kvm.storage.KVMStoragePoolManager.disconnectPhysicalDisk(KVMStoragePoolManager.java:291)\n\tat
> com.cloud.hyperviso
> r.kvm.storage.KVMStorageProcessor.dettachVolume(KVMStorageProcessor.java:1032)\n\tat
> com.cloud.storage.resource.StorageSubsys
> temCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:147)\n\tat
> com.cloud.storage.resource.StorageSubsystemC
> ommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:60)\n\tat
> com.cloud.hypervisor.kvm.resource.L
> ibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1357)\n\tat
> com.cloud.agent.Agent.processRequest(Agent.j
> ava:501)\n\tat
> com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)\n\tat
> com.cloud.utils.nio.Task.run(Task.java:
> 84)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n\tat
> java.util.concurrent.ThreadPo
> olExecutor$Worker.run(ThreadPoolExecutor.java:603)\n\tat
> java.lang.Thread.run(Thread.java:722)\nCaused by: org.libvirt.Libvir
> tException: Storage pool not found: no storage pool with matching uuid\n\tat
> org.libvirt.ErrorHandler.processError(Unknown So
> urce)\n\tat org.libvirt.Connect.processError(Unknown Source)\n\tat
> org.libvirt.StoragePool.processError(Unknown Source)\n\tat
> org.libvirt.StoragePool.getInfo(Unknown Source)\n\tat
> com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.getStoragePool(
> LibvirtStorageAdaptor.java:382)\n\t... 11 more\n","wait":0}}] }
> 2014-06-03 22:51:28,502 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-39:ctx-de2c749a job-164/job-165 ctx-82508c0e) Seq
> 1-7390406988514984214: Received: { Ans: , MgmtId: 29066118877352, via: 1,
> Ver: v1, Flags: 10, { Answer } }
> 2014-06-03 22:51:28,502 ERROR [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-39:ctx-de2c749a job-164/job-165 ctx-82508c0e) Invocation
> exception, caused by: com.cloud.utils.exception.CloudRuntimeException: Failed
> to detach volume Test Volume from VM QA-19a2e3f6-1ce7-4ed0-9e2e-c436c41a68c1;
> com.cloud.utils.exception.CloudRuntimeException:
> org.libvirt.LibvirtException: Storage pool not found: no storage pool with
> matching uuid
> at
> com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.getStoragePool(LibvirtStorageAdaptor.java:389)
> at
> com.cloud.hyperv
[jira] [Updated] (CLOUDSTACK-6842) [Automation] Detach volume fails with LibvirtException: Storage pool not found: no storage pool with matching uuid
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-6842:
---
Assignee: edison su
> [Automation] Detach volume fails with LibvirtException: Storage pool not
> found: no storage pool with matching uuid
> --
>
> Key: CLOUDSTACK-6842
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6842
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM, Volumes
>Affects Versions: 4.4.0
> Environment: KVM - RHEL 6.3
> Branch - 4.4-forward
>Reporter: Rayees Namathponnan
>Assignee: edison su
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: CLOUDSTACK-6842.rar
>
>
> This issue is observed during KVM automation run, test cases failed during
> detach volume operation below exception
> 2014-06-03 22:51:27,825 DEBUG [c.c.n.NetworkModelImpl]
> (Network-Scavenger-1:ctx-355fa5da) Network id=221 is not ready for GC
> as it has vms that are Starting at the moment
> 2014-06-03 22:51:27,878 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-18:ctx-673fdee8) ===START=== 10.223.240.194 -- GET jobid=18
> 3bb2f8-adac-4577-a19c-a7df2a31b0b6&apiKey=fRS2dHRVFlXSTC9bs2rBKXwD0FNnpHk-Dz_2XI8fgFZii_P6Tx5eLyzluOx8lvuonsbqknPHnIFYT5xNhEv
> UEA&command=queryAsyncJobResult&response=json&signature=PNHiNNyW76saC8ZAnPwgL89sx9w%3D
> 2014-06-03 22:51:27,893 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-18:ctx-673fdee8 ctx-2f4bea09 ctx-49740006) ===END=== 10.223.
> 240.194 -- GET
> jobid=183bb2f8-adac-4577-a19c-a7df2a31b0b6&apiKey=fRS2dHRVFlXSTC9bs2rBKXwD0FNnpHk-Dz_2XI8fgFZii_P6Tx5eLyzluOx
> 8lvuonsbqknPHnIFYT5xNhEvUEA&command=queryAsyncJobResult&response=json&signature=PNHiNNyW76saC8ZAnPwgL89sx9w%3D
> 2014-06-03 22:51:28,502 DEBUG [c.c.a.t.Request]
> (AgentManager-Handler-12:null) Seq 1-7390406988514984214: Processing: { Ans:
> , MgmtId: 29066118877352, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"com.cloud.ut
> ils.exception.CloudRuntimeException: org.libvirt.LibvirtException: Storage
> pool not found: no storage pool with matching uuid
> \n\tat
> com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.getStoragePool(LibvirtStorageAdaptor.java:389)\n\tat
> com.cloud.
> hypervisor.kvm.storage.KVMStoragePoolManager.disconnectPhysicalDisk(KVMStoragePoolManager.java:291)\n\tat
> com.cloud.hyperviso
> r.kvm.storage.KVMStorageProcessor.dettachVolume(KVMStorageProcessor.java:1032)\n\tat
> com.cloud.storage.resource.StorageSubsys
> temCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:147)\n\tat
> com.cloud.storage.resource.StorageSubsystemC
> ommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:60)\n\tat
> com.cloud.hypervisor.kvm.resource.L
> ibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1357)\n\tat
> com.cloud.agent.Agent.processRequest(Agent.j
> ava:501)\n\tat
> com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)\n\tat
> com.cloud.utils.nio.Task.run(Task.java:
> 84)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n\tat
> java.util.concurrent.ThreadPo
> olExecutor$Worker.run(ThreadPoolExecutor.java:603)\n\tat
> java.lang.Thread.run(Thread.java:722)\nCaused by: org.libvirt.Libvir
> tException: Storage pool not found: no storage pool with matching uuid\n\tat
> org.libvirt.ErrorHandler.processError(Unknown So
> urce)\n\tat org.libvirt.Connect.processError(Unknown Source)\n\tat
> org.libvirt.StoragePool.processError(Unknown Source)\n\tat
> org.libvirt.StoragePool.getInfo(Unknown Source)\n\tat
> com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.getStoragePool(
> LibvirtStorageAdaptor.java:382)\n\t... 11 more\n","wait":0}}] }
> 2014-06-03 22:51:28,502 DEBUG [c.c.a.t.Request]
> (Work-Job-Executor-39:ctx-de2c749a job-164/job-165 ctx-82508c0e) Seq
> 1-7390406988514984214: Received: { Ans: , MgmtId: 29066118877352, via: 1,
> Ver: v1, Flags: 10, { Answer } }
> 2014-06-03 22:51:28,502 ERROR [c.c.v.VmWorkJobHandlerProxy]
> (Work-Job-Executor-39:ctx-de2c749a job-164/job-165 ctx-82508c0e) Invocation
> exception, caused by: com.cloud.utils.exception.CloudRuntimeException: Failed
> to detach volume Test Volume from VM QA-19a2e3f6-1ce7-4ed0-9e2e-c436c41a68c1;
> com.cloud.utils.exception.CloudRuntimeException:
> org.libvirt.LibvirtException: Storage pool not found: no storage pool with
> matching uuid
> at
> com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.getStoragePool(LibvirtStorageAdaptor.java:389)
> at
> com.cloud.hypervisor.kvm.storage.KVMStoragePoolManager.d
[jira] [Commented] (CLOUDSTACK-6594) Observed many DB Exception while starting MS "Can't DROP 'last_sent'; check that column/key exists"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036071#comment-14036071 ] Animesh Chaturvedi commented on CLOUDSTACK-6594: If this is a benign issue then why even log it > Observed many DB Exception while starting MS "Can't DROP 'last_sent'; check > that column/key exists" > --- > > Key: CLOUDSTACK-6594 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6594 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0 > Environment: RHEL 6.3, > Build - 4.4-forward, > Also Ubuntu 14.04, CS 4.4.0-snapshot 20140513 >Reporter: Rayees Namathponnan >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.4.0 > > Attachments: CLOUDSTACK-6594.rar, management-server.log > > > Below exception observed while staring MS > INFO [o.a.c.s.m.m.i.DefaultModuleDefinitionSet] (main:null) Loading module > context [system] from URL > [jar:file:/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-core-4.4.0-SNAPSHOT.jar!/META-INF/cloudstack/bootstrap/spring-bootstrap-context-inheritable.xml] > INFO [c.c.u.d.T.Transaction] (main:null) Is Data Base High Availiability > enabled? Ans : false > INFO [c.c.u.d.Merovingian2] (main:null) Cleaning up locks for 29066118877352 > INFO [c.c.u.d.Merovingian2] (main:null) Released 0 locks for 29066118877352 > INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Running system > integrity checker com.cloud.upgrade.DatabaseUpgradeChecker@883ca2e > INFO [c.c.u.DatabaseUpgradeChecker] (main:null) Grabbing lock to check for > database upgrade. > INFO [c.c.u.DatabaseUpgradeChecker] (main:null) DB version = 4.0.0 Code > Version = 4.4.0-SNAPSHOT > INFO [c.c.u.DatabaseUpgradeChecker] (main:null) Database upgrade must be > performed from 4.0.0 to 4.4.0-SNAPSHOT > WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when > trying to drop key last_sent on table alert > com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Can't DROP > 'last_sent'; check that column/key exists > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) > at com.mysql.jdbc.Util.getInstance(Util.java:386) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529) > at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990) > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625) > at > com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119) > at > com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2415) > at > com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2333) > at > com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2318) > at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) > at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) > at > com.cloud.upgrade.dao.DatabaseAccessObject.dropKey(DatabaseAccessObject.java:37) > at > com.cloud.upgrade.dao.DbUpgradeUtils.dropKeysIfExist(DbUpgradeUtils.java:28) > at > com.cloud.upgrade.dao.Upgrade410to420.addIndexForAlert(Upgrade410to420.java:543) > at > com.cloud.upgrade.dao.Upgrade410to420.performDataMigration(Upgrade410to420.java:98) > at > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:310) > at > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:432) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55) > at > org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167)
[jira] [Commented] (CLOUDSTACK-6594) Observed many DB Exception while starting MS "Can't DROP 'last_sent'; check that column/key exists"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036095#comment-14036095 ] Nitin Mehta commented on CLOUDSTACK-6594: - Exactly, thats what my first comment was hinting towards. > Observed many DB Exception while starting MS "Can't DROP 'last_sent'; check > that column/key exists" > --- > > Key: CLOUDSTACK-6594 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6594 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0 > Environment: RHEL 6.3, > Build - 4.4-forward, > Also Ubuntu 14.04, CS 4.4.0-snapshot 20140513 >Reporter: Rayees Namathponnan >Assignee: Nitin Mehta >Priority: Critical > Fix For: 4.4.0 > > Attachments: CLOUDSTACK-6594.rar, management-server.log > > > Below exception observed while staring MS > INFO [o.a.c.s.m.m.i.DefaultModuleDefinitionSet] (main:null) Loading module > context [system] from URL > [jar:file:/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/cloud-core-4.4.0-SNAPSHOT.jar!/META-INF/cloudstack/bootstrap/spring-bootstrap-context-inheritable.xml] > INFO [c.c.u.d.T.Transaction] (main:null) Is Data Base High Availiability > enabled? Ans : false > INFO [c.c.u.d.Merovingian2] (main:null) Cleaning up locks for 29066118877352 > INFO [c.c.u.d.Merovingian2] (main:null) Released 0 locks for 29066118877352 > INFO [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Running system > integrity checker com.cloud.upgrade.DatabaseUpgradeChecker@883ca2e > INFO [c.c.u.DatabaseUpgradeChecker] (main:null) Grabbing lock to check for > database upgrade. > INFO [c.c.u.DatabaseUpgradeChecker] (main:null) DB version = 4.0.0 Code > Version = 4.4.0-SNAPSHOT > INFO [c.c.u.DatabaseUpgradeChecker] (main:null) Database upgrade must be > performed from 4.0.0 to 4.4.0-SNAPSHOT > WARN [c.c.u.d.DatabaseAccessObject] (main:null) Ignored SQL Exception when > trying to drop key last_sent on table alert > com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Can't DROP > 'last_sent'; check that column/key exists > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) > at com.mysql.jdbc.Util.getInstance(Util.java:386) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3597) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3529) > at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1990) > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2151) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2625) > at > com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2119) > at > com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2415) > at > com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2333) > at > com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2318) > at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) > at > org.apache.commons.dbcp.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:105) > at > com.cloud.upgrade.dao.DatabaseAccessObject.dropKey(DatabaseAccessObject.java:37) > at > com.cloud.upgrade.dao.DbUpgradeUtils.dropKeysIfExist(DbUpgradeUtils.java:28) > at > com.cloud.upgrade.dao.Upgrade410to420.addIndexForAlert(Upgrade410to420.java:543) > at > com.cloud.upgrade.dao.Upgrade410to420.performDataMigration(Upgrade410to420.java:98) > at > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:310) > at > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:432) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65) > at > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55) > at > org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:167) >
[jira] [Created] (CLOUDSTACK-6936) UI > Infrastructure > Primary Storages > Add Primary Storage dialog fails to pop up when listClusters response is empty.
Jessica Wang created CLOUDSTACK-6936: Summary: UI > Infrastructure > Primary Storages > Add Primary Storage dialog fails to pop up when listClusters response is empty. Key: CLOUDSTACK-6936 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6936 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6936) UI > Infrastructure > Primary Storages > Add Primary Storage dialog fails to pop up when listClusters response is empty.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036124#comment-14036124 ] Jessica Wang commented on CLOUDSTACK-6936: -- https://issues.citrite.net/i#browse/CS-20342 > UI > Infrastructure > Primary Storages > Add Primary Storage dialog fails to > pop up when listClusters response is empty. > > > Key: CLOUDSTACK-6936 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6936 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6910) [CI] Phase 1: tagging of test cases
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla reassigned CLOUDSTACK-6910: --- Assignee: Santhosh Kumar Edukulla > [CI] Phase 1: tagging of test cases > --- > > Key: CLOUDSTACK-6910 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6910 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Abhinandan Prateek >Assignee: Santhosh Kumar Edukulla >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6910) [CI] Phase 1: tagging of test cases
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036155#comment-14036155 ] Santhosh Kumar Edukulla commented on CLOUDSTACK-6910: - 1. required_hardware="true" or required_hardware="false" tags were added to all bvt cases. 2. simulator, selfservice, tags were added at many places, these are same. Removed them as part of clean up. 3. There were few tags say "test", and few misc tags added, cleaned up them. 4. There were few places where zone type information like advanced or basic was missing. Added them now. 5. Need to change marvin/pom.xml where references to simulator tag was there. Need to remove references here, along with it load option has to be removed. 6. Next, add hypervisor attribute with various hypervisor information, such that they can be picked up based upon the hypervisor we are running upon. This, we will discuss inside community before proceeding. > [CI] Phase 1: tagging of test cases > --- > > Key: CLOUDSTACK-6910 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6910 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Abhinandan Prateek >Assignee: Santhosh Kumar Edukulla >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6935) Some storage pool filter is not enabled in ZoneWideStoragePoolAllocator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036182#comment-14036182 ] ASF subversion and git services commented on CLOUDSTACK-6935: - Commit 77e74841a0b2b5217c5517d3f3241664a6100e5a in cloudstack's branch refs/heads/master from [~ynojima] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=77e7484 ] Revert "CLOUDSTACK-6935 refactor StoragePoolAllocator#filter logic" This reverts commit 31de58edab563eb1cb50c5c06437fdd3efc6a3d2. > Some storage pool filter is not enabled in ZoneWideStoragePoolAllocator > --- > > Key: CLOUDSTACK-6935 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6935 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Storage Controller >Reporter: Yoshikazu Nojima >Assignee: Yoshikazu Nojima > > Some storage pool filtering logic like hypervisor type check, storage type > check for root volume and avoid list check is not enabled in > ZoneWideStoragePoolAllocator. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6935) Some storage pool filter is not enabled in ZoneWideStoragePoolAllocator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036188#comment-14036188 ] ASF subversion and git services commented on CLOUDSTACK-6935: - Commit a61f77523dd70ebf54e577426fe2535e4359cc25 in cloudstack's branch refs/heads/4.4-forward from [~ynojima] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a61f775 ] Revert "CLOUDSTACK-6935 refactor StoragePoolAllocator#filter logic" This reverts commit cd414a0f56798ae801fc464be127e37daabef809. > Some storage pool filter is not enabled in ZoneWideStoragePoolAllocator > --- > > Key: CLOUDSTACK-6935 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6935 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Storage Controller >Reporter: Yoshikazu Nojima >Assignee: Yoshikazu Nojima > > Some storage pool filtering logic like hypervisor type check, storage type > check for root volume and avoid list check is not enabled in > ZoneWideStoragePoolAllocator. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6910) Phase 1: tagging of test cases
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla updated CLOUDSTACK-6910: Summary: Phase 1: tagging of test cases (was: [CI] Phase 1: tagging of test cases) > Phase 1: tagging of test cases > -- > > Key: CLOUDSTACK-6910 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6910 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Abhinandan Prateek >Assignee: Santhosh Kumar Edukulla >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CLOUDSTACK-6910) [CI] Phase 1: tagging of test cases
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036155#comment-14036155 ] Santhosh Kumar Edukulla edited comment on CLOUDSTACK-6910 at 6/18/14 7:12 PM: -- 1. required_hardware="true" or required_hardware="false" tags were added to all bvt cases. 2. simulator, selfservice, tags earlier added were redundant, at many places, these are same. Removed them as part of clean up. 3. There were few tags say "test", and few misc tags available which are not much useful, cleaned up them. 4. There were few places where zone type information like advanced or basic was missing. Added them now. 5. Need to change marvin/pom.xml where references to simulator tag was there. Need to remove references here, along with it load option has to be removed. 6. Next, add hypervisor attribute with various hypervisor information, such that they can be picked up based upon the hypervisor we are running upon. This, we will discuss inside community before proceeding. was (Author: santhoshe): 1. required_hardware="true" or required_hardware="false" tags were added to all bvt cases. 2. simulator, selfservice, tags were added at many places, these are same. Removed them as part of clean up. 3. There were few tags say "test", and few misc tags added, cleaned up them. 4. There were few places where zone type information like advanced or basic was missing. Added them now. 5. Need to change marvin/pom.xml where references to simulator tag was there. Need to remove references here, along with it load option has to be removed. 6. Next, add hypervisor attribute with various hypervisor information, such that they can be picked up based upon the hypervisor we are running upon. This, we will discuss inside community before proceeding. > [CI] Phase 1: tagging of test cases > --- > > Key: CLOUDSTACK-6910 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6910 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.4.0 >Reporter: Abhinandan Prateek >Assignee: Santhosh Kumar Edukulla >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6936) UI > Infrastructure > Primary Storages > Add Primary Storage dialog fails to pop up when listClusters response is empty.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036223#comment-14036223 ] ASF subversion and git services commented on CLOUDSTACK-6936: - Commit b8a29615838bd12d0f6699ef3e64bb9b89158c26 in cloudstack's branch refs/heads/4.4-forward from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b8a2961 ] CLOUDSTACK-6936: UI - (1)dialog widget > dropdown field > provide a blank option if there is no data for option(s) in a dropdown field. (2) Add Primary Storage dialog - cluster dropdown field - still calls args.response.success() when there is no data for option(s). > UI > Infrastructure > Primary Storages > Add Primary Storage dialog fails to > pop up when listClusters response is empty. > > > Key: CLOUDSTACK-6936 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6936 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6936) UI > Infrastructure > Primary Storages > Add Primary Storage dialog fails to pop up when listClusters response is empty.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang closed CLOUDSTACK-6936. > UI > Infrastructure > Primary Storages > Add Primary Storage dialog fails to > pop up when listClusters response is empty. > > > Key: CLOUDSTACK-6936 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6936 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6936) UI > Infrastructure > Primary Storages > Add Primary Storage dialog fails to pop up when listClusters response is empty.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036224#comment-14036224 ] ASF subversion and git services commented on CLOUDSTACK-6936: - Commit dbbc6d42fdfc76649f4a7884859dd9668e0203ab in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dbbc6d4 ] CLOUDSTACK-6936: UI - (1)dialog widget > dropdown field > provide a blank option if there is no data for option(s) in a dropdown field. (2) Add Primary Storage dialog - cluster dropdown field - still calls args.response.success() when there is no data for option(s). > UI > Infrastructure > Primary Storages > Add Primary Storage dialog fails to > pop up when listClusters response is empty. > > > Key: CLOUDSTACK-6936 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6936 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6936) UI > Infrastructure > Primary Storages > Add Primary Storage dialog fails to pop up when listClusters response is empty.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-6936. -- Resolution: Fixed > UI > Infrastructure > Primary Storages > Add Primary Storage dialog fails to > pop up when listClusters response is empty. > > > Key: CLOUDSTACK-6936 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6936 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Reporter: Jessica Wang >Assignee: Jessica Wang > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6934) NPE at VolumeOrchestrator.java:868 during vm expunge when vm has volumes in Allocated state (not created on storage yet)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036252#comment-14036252 ] ASF subversion and git services commented on CLOUDSTACK-6934: - Commit 3312394154c1ee42b3ff014eadc277a0c39b97cf in cloudstack's branch refs/heads/master from [~alena1108] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3312394 ] CLOUDSTACK-6934: don't try to detach volume from host when volume was never allocated to a primary storage > NPE at VolumeOrchestrator.java:868 during vm expunge when vm has volumes in > Allocated state (not created on storage yet) > > > Key: CLOUDSTACK-6934 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6934 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0 >Reporter: Alena Prokharchyk >Assignee: Alena Prokharchyk > Fix For: 4.5.0 > > > Steps to reproduce: > 1) Deploy 2 vms; VM2 should be deployed with startVm=false option. > 2) Stop VM1. Detach the Root disks from VM1 and VM2; attach the root disk of > VM2 to VM1. > 3) Try to expunge the VM1 now. NPE happens on > INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-2:ctx-228bd156 > job-890/job-892) Remove job-892 from job monitoring > WARN [c.c.v.UserVmManagerImpl] (UserVm-Scavenger-1:ctx-d72384e8) Unable to > expunge VM[User|i-2-24-st] > java.lang.NullPointerException > at > org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.disconnectVolumesFromHost(VolumeOrchestrator.java:868) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:528) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:464) > at com.cloud.vm.UserVmManagerImpl.expunge(UserVmManagerImpl.java:1670) > at com.cloud.vm.UserVmManagerImpl.expungeVm(UserVmManagerImpl.java:3691) > NPE happens because in the code we assume that when VM has not null > hostId/lastHostId (indicating it had been running at some point), then its > volumes should have not null storagepoolId. This assumption is incorrect, and > we should check storagePoolId of the volume first before attempting to > disconnect it from the host. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6934) NPE at VolumeOrchestrator.java:868 during vm expunge when vm has volumes in Allocated state (not created on storage yet)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alena Prokharchyk resolved CLOUDSTACK-6934. --- Resolution: Fixed > NPE at VolumeOrchestrator.java:868 during vm expunge when vm has volumes in > Allocated state (not created on storage yet) > > > Key: CLOUDSTACK-6934 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6934 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0 >Reporter: Alena Prokharchyk >Assignee: Alena Prokharchyk > Fix For: 4.5.0 > > > Steps to reproduce: > 1) Deploy 2 vms; VM2 should be deployed with startVm=false option. > 2) Stop VM1. Detach the Root disks from VM1 and VM2; attach the root disk of > VM2 to VM1. > 3) Try to expunge the VM1 now. NPE happens on > INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-2:ctx-228bd156 > job-890/job-892) Remove job-892 from job monitoring > WARN [c.c.v.UserVmManagerImpl] (UserVm-Scavenger-1:ctx-d72384e8) Unable to > expunge VM[User|i-2-24-st] > java.lang.NullPointerException > at > org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.disconnectVolumesFromHost(VolumeOrchestrator.java:868) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:528) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:464) > at com.cloud.vm.UserVmManagerImpl.expunge(UserVmManagerImpl.java:1670) > at com.cloud.vm.UserVmManagerImpl.expungeVm(UserVmManagerImpl.java:3691) > NPE happens because in the code we assume that when VM has not null > hostId/lastHostId (indicating it had been running at some point), then its > volumes should have not null storagepoolId. This assumption is incorrect, and > we should check storagePoolId of the volume first before attempting to > disconnect it from the host. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6934) NPE at VolumeOrchestrator.java:868 during vm expunge when vm has volumes in Allocated state (not created on storage yet)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036253#comment-14036253 ] ASF subversion and git services commented on CLOUDSTACK-6934: - Commit 92fea032da08938749cde73e312370f1b9da1567 in cloudstack's branch refs/heads/4.4-forward from [~alena1108] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=92fea03 ] CLOUDSTACK-6934: don't try to detach volume from host when volume was never allocated to a primary storage > NPE at VolumeOrchestrator.java:868 during vm expunge when vm has volumes in > Allocated state (not created on storage yet) > > > Key: CLOUDSTACK-6934 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6934 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0 >Reporter: Alena Prokharchyk >Assignee: Alena Prokharchyk > Fix For: 4.5.0 > > > Steps to reproduce: > 1) Deploy 2 vms; VM2 should be deployed with startVm=false option. > 2) Stop VM1. Detach the Root disks from VM1 and VM2; attach the root disk of > VM2 to VM1. > 3) Try to expunge the VM1 now. NPE happens on > INFO [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-2:ctx-228bd156 > job-890/job-892) Remove job-892 from job monitoring > WARN [c.c.v.UserVmManagerImpl] (UserVm-Scavenger-1:ctx-d72384e8) Unable to > expunge VM[User|i-2-24-st] > java.lang.NullPointerException > at > org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.disconnectVolumesFromHost(VolumeOrchestrator.java:868) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:528) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceExpunge(VirtualMachineManagerImpl.java:464) > at com.cloud.vm.UserVmManagerImpl.expunge(UserVmManagerImpl.java:1670) > at com.cloud.vm.UserVmManagerImpl.expungeVm(UserVmManagerImpl.java:3691) > NPE happens because in the code we assume that when VM has not null > hostId/lastHostId (indicating it had been running at some point), then its > volumes should have not null storagepoolId. This assumption is incorrect, and > we should check storagePoolId of the volume first before attempting to > disconnect it from the host. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6935) Some storage pool filter is not enabled in ZoneWideStoragePoolAllocator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036258#comment-14036258 ] ASF subversion and git services commented on CLOUDSTACK-6935: - Commit 318e497e601b7b8d910021be06c138037122d012 in cloudstack's branch refs/heads/master from [~ynojima] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=318e497 ] CLOUDSTACK-6935 refactor StoragePoolAllocator#filter logic to support IOPS capacity control in a cluster wide storage pool and a local storage pool to enable hypervisor type check, storage type check for root volume and avoid list check Since original commit(31de58edab563eb1cb50c5c06437fdd3efc6a3d2) contained a bug, it was reverted and this commit is a revised one. > Some storage pool filter is not enabled in ZoneWideStoragePoolAllocator > --- > > Key: CLOUDSTACK-6935 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6935 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Storage Controller >Reporter: Yoshikazu Nojima >Assignee: Yoshikazu Nojima > > Some storage pool filtering logic like hypervisor type check, storage type > check for root volume and avoid list check is not enabled in > ZoneWideStoragePoolAllocator. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6935) Some storage pool filter is not enabled in ZoneWideStoragePoolAllocator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036275#comment-14036275 ] ASF subversion and git services commented on CLOUDSTACK-6935: - Commit 45f0c7367680f4bfbcee470139b708d69322be78 in cloudstack's branch refs/heads/4.4-forward from [~ynojima] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=45f0c73 ] CLOUDSTACK-6935 refactor StoragePoolAllocator#filter logic to support IOPS capacity control in a cluster wide storage pool and a local storage pool to enable hypervisor type check, storage type check for root volume and avoid list check Since original commit(31de58edab563eb1cb50c5c06437fdd3efc6a3d2) contained a bug, it was reverted and this commit is a revised one. > Some storage pool filter is not enabled in ZoneWideStoragePoolAllocator > --- > > Key: CLOUDSTACK-6935 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6935 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Storage Controller >Reporter: Yoshikazu Nojima >Assignee: Yoshikazu Nojima > > Some storage pool filtering logic like hypervisor type check, storage type > check for root volume and avoid list check is not enabled in > ZoneWideStoragePoolAllocator. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6937) IAM - ROOT admin - Not able to list network owned by accounts under any domain by passing uuid.
Sangeetha Hariharan created CLOUDSTACK-6937: --- Summary: IAM - ROOT admin - Not able to list network owned by accounts under any domain by passing uuid. Key: CLOUDSTACK-6937 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6937 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: Build from 4.4-forward Reporter: Sangeetha Hariharan IAM - ROOT admin - Not able to list network owned by accounts under any domain by passing uuid. Create a domain d1 and deploy a vm as an account under this domain. As ROOT admin , try to listNetwork of this VM by passing uuid of the network. Empyt result is returned. when listall=true is passed along with id parameter , then we are able to list the network. http://10.223.49.6:8080/client/api?command=listNetworks&id=decebcd9-58f9-40b1-b4c4-bc554457f3d7&response=json&sessionkey=WGOtz0CAa5c57Imzm2iY8caUVYg%3D This returns empty list. When passed with listall=true then network is listed: http://10.223.49.6:8080/client/api?command=listNetworks&id=decebcd9-58f9-40b1-b4c4-bc554457f3d7&response=json&sessionkey=WGOtz0CAa5c57Imzm2iY8caUVYg%3D&%20%3E%3E%201010.223.49.6:8080/client/api?command=listNetworks&id=decebcd9-58f9-40b1-b4c4-bc554457f3d7&response=json&sessionkey=WGOtz0CAa5c57Imzm2iY8caUVYg=&listall=true -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6938) Cannot create template from snapshot when using S3 storage
Logan B created CLOUDSTACK-6938: --- Summary: Cannot create template from snapshot when using S3 storage Key: CLOUDSTACK-6938 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6938 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Snapshot Affects Versions: 4.4.0 Environment: KVM + S3 Secondary Storage Reporter: Logan B Priority: Blocker When trying to create a template from a snapshot with S3 secondary storage, the command immediately fails with a NullPointerException. This appears to only happen when there is a pre-existing snapshot folder in the NFS staging store. This indicates that there is something wrong with the copy command (e.g., it's using 'mkdir' instead of 'mkdir -p'). The issue can be worked around by deleting the existing snapshot folder on the staging store every time you want to create a new template. This is obviously not viable for end users. This issue should be fixed before 4.4 ships because it should be a stupid simple thing to correct, but completely breaks restoring snapshots for end users. Waiting for 4.5 would be far too long for an issue like this. 2014-06-18 21:13:54,789 DEBUG [cloud.agent.Agent] (agentRequest-Handler-2:null) Processing command: org.apache.cloudstack.storage.command.CopyCommand 2014-06-18 21:13:54,789 INFO [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-2:null) Determined host 172.16.48.99 corresponds to IP 172.16.48.99 2014-06-18 21:13:54,797 ERROR [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-2:null) Unable to create directory /mnt/SecStorage/6b9bdec9-fdc9-3fdd-a5f8-0481df177ae8/snapshots/2/25 to copy from S3 to cache. I'm guessing it's an issue with the mkdirs() function in the code, but I've been unable to find it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6938) Cannot create template from snapshot when using S3 storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Logan B updated CLOUDSTACK-6938: Fix Version/s: 4.4.0 > Cannot create template from snapshot when using S3 storage > -- > > Key: CLOUDSTACK-6938 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6938 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.4.0 > Environment: KVM + S3 Secondary Storage >Reporter: Logan B >Priority: Blocker > Fix For: 4.4.0 > > > When trying to create a template from a snapshot with S3 secondary storage, > the command immediately fails with a NullPointerException. > This appears to only happen when there is a pre-existing snapshot folder in > the NFS staging store. This indicates that there is something wrong with the > copy command (e.g., it's using 'mkdir' instead of 'mkdir -p'). > The issue can be worked around by deleting the existing snapshot folder on > the staging store every time you want to create a new template. This is > obviously not viable for end users. > This issue should be fixed before 4.4 ships because it should be a stupid > simple thing to correct, but completely breaks restoring snapshots for end > users. Waiting for 4.5 would be far too long for an issue like this. > 2014-06-18 21:13:54,789 DEBUG [cloud.agent.Agent] > (agentRequest-Handler-2:null) Processing command: > org.apache.cloudstack.storage.command.CopyCommand > 2014-06-18 21:13:54,789 INFO [storage.resource.NfsSecondaryStorageResource] > (agentRequest-Handler-2:null) Determined host 172.16.48.99 corresponds to IP > 172.16.48.99 > 2014-06-18 21:13:54,797 ERROR [storage.resource.NfsSecondaryStorageResource] > (agentRequest-Handler-2:null) Unable to create directory > /mnt/SecStorage/6b9bdec9-fdc9-3fdd-a5f8-0481df177ae8/snapshots/2/25 to copy > from S3 to cache. > I'm guessing it's an issue with the mkdirs() function in the code, but I've > been unable to find it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6939) IAM - DomainAdmin - Not able to listNetwork belonging to a subdomain by passing uuid.
Sangeetha Hariharan created CLOUDSTACK-6939:
---
Summary: IAM - DomainAdmin - Not able to listNetwork belonging to
a subdomain by passing uuid.
Key: CLOUDSTACK-6939
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6939
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.4.0
Environment: Build from 4.4-forward
Reporter: Sangeetha Hariharan
IAM - DomainAdmin - Not able to listNetwork belonging to a subdomain by passing
uuid.
Steps to reproduce the problem:
Create a domain D1 with domain admin user - d1
Create a subdomain D1/D11 with regular user - d11a.
As d11a user , create an isolated network.
As domain admin d1 , use listNetworks() command to list network of d11a by
passing id paramater.
listNetwork() returns empty list.
When i pass listall=true parameter along with uuid parameter , then I am able
to get the list.
When empty result is returned:
2014-05-02 14:40:54,273 INFO [a.c.c.a.ApiServer] (catalina-exec-19:ctx-7b012c50
ctx-d447137f) (userId=14 acc
ountId=14 sessionId=0662CF854C84368E87A0D1E1283323A4) 10.215.2.8 – GET
command=listNetworks&id=323c350f-8345
-493e-bc50-5b9592fe4ab3&response=json&sessionkey=B2T%2FRltf8yQnVVqLXpbocOU4HyE%3D&_=1399080286519
200 { "list
networksresponse" : { } }
with listall=true parameter , network is being listed:
2014-05-02 14:41:08,454 INFO [a.c.c.a.ApiServer] (catalina-exec-8:ctx-4cccd2f8
ctx-c091216f) (userId=14 acco
untId=14 sessionId=0662CF854C84368E87A0D1E1283323A4) 10.215.2.8 – GET
command=listNetworks&id=323c350f-8345-
493e-bc50-5b9592fe4ab3&response=json&sessionkey=B2T%2FRltf8yQnVVqLXpbocOU4HyE%3D&_=1399080286519&listall=true
200 { "listnetworksresponse" : { "count":1 ,"network" : [
{"id":"323c350f-8345-493e-bc50-5b9592fe4ab3","nam
e":"testD11-TestNetworkList-OPXQKG-network","displaytext":"testD11-TestNetworkList-OPXQKG-network","broadcast
domaintype":"Vlan","traffictype":"Guest","gateway":"10.1.1.1","netmask":"255.255.255.0","cidr":"10.1.1.0/24",
"zoneid":"b690dddf-5755-49ab-8a4d-0aff04fa39f7","zonename":"BLR1","networkofferingid":"fc25eb7b-d884-4cc3-acb
b-a321817a3567","networkofferingname":"DefaultIsolatedNetworkOfferingWithSourceNatService","networkofferingdi
splaytext":"Offering for Isolated networks with Source Nat service
enabled","networkofferingconservemode":tru
e,"networkofferingavailability":"Required","issystem":false,"state":"Implemented","related":"323c350f-8345-49
3e-bc50-5b9592fe4ab3","dns1":"4.2.2.2","type":"Isolated","acltype":"Account","account":"testD11-TestNetworkLi
st-OPXQKG","domainid":"63282e89-0798-456b-9f1d-a234af5fb046","domain":"D11-BVD36X","service":[
{"name":"PortFo rwarding"}
,
{"name":"UserData"}
,{"name":"Firewall","capability":[
{"name":"MultipleIps","value":"true","canchoo seservicecapability":false}
,
{"name":"SupportedEgressProtocols","value":"tcp,udp,icmp,
all","canchooseservicec apability":false}
,
{"name":"SupportedProtocols","value":"tcp,udp,icmp","canchooseservicecapability":false}
,
{"name":"SupportedTrafficDirection","value":"ingress,
egress","canchooseservicecapability":false}
,
{"name":"TrafficStatistics","value":"per public
ip","canchooseservicecapability":false}
]},{"name":"Lb","capability":[{"name":"AutoScaleCounters","value":"[
{\"methodname\":\"cpu\",\"paramlist\":[]}
,
{\"methodname\":\"memory\",\"paramlist\":[]}
]","canchooseservicecapability":false},
{"name":"SupportedLBIsolation","value":"dedicated","canchooseservicecapability":false}
,
{"name":"SupportedLbAlgorithms","value":"roundrobin,leastconn,source","canchooseservicecapability":false}
,
{"name":"LbSchemes","value":"Public","canchooseservicecapability":false}
,
{"name":"SupportedProtocols","value":"tcp,
udp","canchooseservicecapability":false}
,{"name":"SupportedStickinessMethods","value":"[{\"methodname\":\"LbCookie\",\"paramlist\":[
{\"paramname\":\"cookie-name\",\"required\":false,\"isflag\":false,\"description\":\"
\"}
,
{\"paramname\":\"mode\",\"required\":false,\"isflag\":false,\"description\":\"
\"}
,
{\"paramname\":\"nocache\",\"required\":false,\"isflag\":true,\"description\":\"
\"}
,
{\"paramname\":\"indirect\",\"required\":false,\"isflag\":true,\"description\":\"
\"}
,
{\"paramname\":\"postonly\",\"required\":false,\"isflag\":true,\"description\":\"
\"}
,{\"paramname\":\"domain\",\"required\":false,\"isflag\":false,
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6938) Cannot create template from snapshot when using S3 storage
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036468#comment-14036468
]
Logan B commented on CLOUDSTACK-6938:
-
This is the relevant bit of code:
In NfsSecondaryStorageResource.java:
if (!downloadDirectory.mkdirs()) {
final String errMsg = "Unable to create directory " +
downloadPath + " to copy from S3 to cache.";
s_logger.error(errMsg);
return new CopyCmdAnswer(errMsg);
} else {
s_logger.debug("Directory " + downloadPath + " already exists");
}
I believe mkdirs() returns false if the directory already exists. So this
failure logic is prone to breaking.
Better logic might be:
if (downloadDirectory.exists()) {
s_logger.debug("Directory " + downloadPath + " already exists");
} else {
if (!downloadDirectory.mkdirs()) {
final String errMsg = "Unable to create directory " +
downloadPath + " to copy from S3 to cache.";
s_logger.error(errMsg);
return new CopyCmdAnswer(errMsg);
}
I'm not a programmer, but it seems that checking for the existing path before
blindly failing would be better here. If this code checks out I'll try to
figure out how to offer a commit for cherry picking.
> Cannot create template from snapshot when using S3 storage
> --
>
> Key: CLOUDSTACK-6938
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6938
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Snapshot
>Affects Versions: 4.4.0
> Environment: KVM + S3 Secondary Storage
>Reporter: Logan B
>Priority: Blocker
> Fix For: 4.4.0
>
>
> When trying to create a template from a snapshot with S3 secondary storage,
> the command immediately fails with a NullPointerException.
> This appears to only happen when there is a pre-existing snapshot folder in
> the NFS staging store. This indicates that there is something wrong with the
> copy command (e.g., it's using 'mkdir' instead of 'mkdir -p').
> The issue can be worked around by deleting the existing snapshot folder on
> the staging store every time you want to create a new template. This is
> obviously not viable for end users.
> This issue should be fixed before 4.4 ships because it should be a stupid
> simple thing to correct, but completely breaks restoring snapshots for end
> users. Waiting for 4.5 would be far too long for an issue like this.
> 2014-06-18 21:13:54,789 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command:
> org.apache.cloudstack.storage.command.CopyCommand
> 2014-06-18 21:13:54,789 INFO [storage.resource.NfsSecondaryStorageResource]
> (agentRequest-Handler-2:null) Determined host 172.16.48.99 corresponds to IP
> 172.16.48.99
> 2014-06-18 21:13:54,797 ERROR [storage.resource.NfsSecondaryStorageResource]
> (agentRequest-Handler-2:null) Unable to create directory
> /mnt/SecStorage/6b9bdec9-fdc9-3fdd-a5f8-0481df177ae8/snapshots/2/25 to copy
> from S3 to cache.
> I'm guessing it's an issue with the mkdirs() function in the code, but I've
> been unable to find it.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6844) [Automation] NPE observed while adding KVM agent host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036496#comment-14036496 ] ASF subversion and git services commented on CLOUDSTACK-6844: - Commit 2ec7359b4eb501b0d9e80ed87af7a54938e9d505 in cloudstack's branch refs/heads/4.4-forward from [~anthonyxu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2ec7359 ] CLOUDSTACK-6662 CLOUDSTACK-6844 exit status delivery might get delayed Please enter the commit message for your changes. Lines starting > [Automation] NPE observed while adding KVM agent host > - > > Key: CLOUDSTACK-6844 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6844 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0 > Environment: KVM - RHEL 6.3 > 4.4-forward branch >Reporter: Rayees Namathponnan >Priority: Critical > Fix For: 4.4.0 > > Attachments: management-server.log.2014-06-03.gz > > > NPE expection observed while adding KVM agent > 2014-06-03 22:21:21,690 INFO [c.c.r.ResourceManagerImpl] > (catalina-exec-2:ctx-f3869ee3 ctx-10800f51 ctx-56aa1511) Trying to > add a new host at http://10.223.49.130 in data center 2 > 2014-06-03 22:21:21,821 DEBUG [c.c.u.s.SSHCmdHelper] > (catalina-exec-2:ctx-f3869ee3 ctx-10800f51 ctx-56aa1511) Executing cmd: > lsmod|grep kvm > 2014-06-03 22:21:22,949 DEBUG [c.c.u.s.SSHCmdHelper] > (catalina-exec-2:ctx-f3869ee3 ctx-10800f51 ctx-56aa1511) lsmod|grep kvm > output:kvm_intel 52570 0 > kvm 314739 1 kvm_intel > 2014-06-03 22:21:22,949 DEBUG [c.c.u.s.SSHCmdHelper] > (catalina-exec-2:ctx-f3869ee3 ctx-10800f51 ctx-56aa1511) Ssh executed fa > iled > java.lang.NullPointerException > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmdOneShotWithExitCode(SSHCmdHelper.java:159) > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmdOneShot(SSHCmdHelper.java:170) > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmd(SSHCmdHelper.java:66) > at > com.cloud.hypervisor.kvm.discoverer.LibvirtServerDiscoverer.find(LibvirtServerDiscoverer.java:161) > at > com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:735) > at > com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy146.discoverHosts(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:683) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:506) > at > com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330) > at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) > 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 com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6662) New XenServer host is not activated due to no agent connection
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036495#comment-14036495 ] ASF subversion and git services commented on CLOUDSTACK-6662: - Commit 2ec7359b4eb501b0d9e80ed87af7a54938e9d505 in cloudstack's branch refs/heads/4.4-forward from [~anthonyxu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2ec7359 ] CLOUDSTACK-6662 CLOUDSTACK-6844 exit status delivery might get delayed Please enter the commit message for your changes. Lines starting > New XenServer host is not activated due to no agent connection > -- > > Key: CLOUDSTACK-6662 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6662 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0 >Reporter: Daan Hoogland >Assignee: Anthony Xu >Priority: Critical > > A new xenserver 6.0.2 or devcloud2 with xcp 4.1 or the newer one with xcp 4.4 > won't become active after adding because of the ssh command erroneously > failing a remote execution of 'mkdir -p /opt/cloud/bin /var/log/cloud'. The > command executes succesfully but an exceptions is logged: > 2014-05-12 15:52:50,395 DEBUG [c.c.u.s.SSHCmdHelper] > (DirectAgent-1:ctx-704cd231) Executing cmd: mkdir -p /opt/cloud/bin > /var/log/cloud > 2014-05-12 15:52:51,409 DEBUG [c.c.u.s.SSHCmdHelper] > (DirectAgent-1:ctx-704cd231) Ssh executed failed > java.lang.NullPointerException > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmdOneShotWithExitCode(SSHCmdHelper.java:159) > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmdOneShot(SSHCmdHelper.java:170) > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmd(SSHCmdHelper.java:66) > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmd(SSHCmdHelper.java:91) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.setupServer(CitrixResourceBase.java:4845) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4674) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:490) > at > com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:176) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) > 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.run(FutureTask.java:262) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6844) [Automation] NPE observed while adding KVM agent host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Xu resolved CLOUDSTACK-6844. Resolution: Fixed > [Automation] NPE observed while adding KVM agent host > - > > Key: CLOUDSTACK-6844 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6844 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0 > Environment: KVM - RHEL 6.3 > 4.4-forward branch >Reporter: Rayees Namathponnan >Priority: Critical > Fix For: 4.4.0 > > Attachments: management-server.log.2014-06-03.gz > > > NPE expection observed while adding KVM agent > 2014-06-03 22:21:21,690 INFO [c.c.r.ResourceManagerImpl] > (catalina-exec-2:ctx-f3869ee3 ctx-10800f51 ctx-56aa1511) Trying to > add a new host at http://10.223.49.130 in data center 2 > 2014-06-03 22:21:21,821 DEBUG [c.c.u.s.SSHCmdHelper] > (catalina-exec-2:ctx-f3869ee3 ctx-10800f51 ctx-56aa1511) Executing cmd: > lsmod|grep kvm > 2014-06-03 22:21:22,949 DEBUG [c.c.u.s.SSHCmdHelper] > (catalina-exec-2:ctx-f3869ee3 ctx-10800f51 ctx-56aa1511) lsmod|grep kvm > output:kvm_intel 52570 0 > kvm 314739 1 kvm_intel > 2014-06-03 22:21:22,949 DEBUG [c.c.u.s.SSHCmdHelper] > (catalina-exec-2:ctx-f3869ee3 ctx-10800f51 ctx-56aa1511) Ssh executed fa > iled > java.lang.NullPointerException > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmdOneShotWithExitCode(SSHCmdHelper.java:159) > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmdOneShot(SSHCmdHelper.java:170) > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmd(SSHCmdHelper.java:66) > at > com.cloud.hypervisor.kvm.discoverer.LibvirtServerDiscoverer.find(LibvirtServerDiscoverer.java:161) > at > com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:735) > at > com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy146.discoverHosts(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:683) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:506) > at > com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330) > at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) > 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 com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6844) [Automation] NPE observed while adding KVM agent host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036513#comment-14036513 ] ASF subversion and git services commented on CLOUDSTACK-6844: - Commit ce3550f8bc0bafacae5bdca8de8905bf31cc in cloudstack's branch refs/heads/master from [~anthonyxu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ce3550f ] CLOUDSTACK-6662 CLOUDSTACK-6844 exit status delivery might get delayed Please enter the commit message for your changes. Lines starting > [Automation] NPE observed while adding KVM agent host > - > > Key: CLOUDSTACK-6844 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6844 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0 > Environment: KVM - RHEL 6.3 > 4.4-forward branch >Reporter: Rayees Namathponnan >Priority: Critical > Fix For: 4.4.0 > > Attachments: management-server.log.2014-06-03.gz > > > NPE expection observed while adding KVM agent > 2014-06-03 22:21:21,690 INFO [c.c.r.ResourceManagerImpl] > (catalina-exec-2:ctx-f3869ee3 ctx-10800f51 ctx-56aa1511) Trying to > add a new host at http://10.223.49.130 in data center 2 > 2014-06-03 22:21:21,821 DEBUG [c.c.u.s.SSHCmdHelper] > (catalina-exec-2:ctx-f3869ee3 ctx-10800f51 ctx-56aa1511) Executing cmd: > lsmod|grep kvm > 2014-06-03 22:21:22,949 DEBUG [c.c.u.s.SSHCmdHelper] > (catalina-exec-2:ctx-f3869ee3 ctx-10800f51 ctx-56aa1511) lsmod|grep kvm > output:kvm_intel 52570 0 > kvm 314739 1 kvm_intel > 2014-06-03 22:21:22,949 DEBUG [c.c.u.s.SSHCmdHelper] > (catalina-exec-2:ctx-f3869ee3 ctx-10800f51 ctx-56aa1511) Ssh executed fa > iled > java.lang.NullPointerException > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmdOneShotWithExitCode(SSHCmdHelper.java:159) > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmdOneShot(SSHCmdHelper.java:170) > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmd(SSHCmdHelper.java:66) > at > com.cloud.hypervisor.kvm.discoverer.LibvirtServerDiscoverer.find(LibvirtServerDiscoverer.java:161) > at > com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:735) > at > com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:586) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy146.discoverHosts(Unknown Source) > at > org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142) > at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141) > at com.cloud.api.ApiServer.queueCommand(ApiServer.java:683) > at com.cloud.api.ApiServer.handleRequest(ApiServer.java:506) > at > com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330) > at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54) > at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) > 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 com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6662) New XenServer host is not activated due to no agent connection
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Xu resolved CLOUDSTACK-6662. Resolution: Fixed > New XenServer host is not activated due to no agent connection > -- > > Key: CLOUDSTACK-6662 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6662 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0 >Reporter: Daan Hoogland >Assignee: Anthony Xu >Priority: Critical > > A new xenserver 6.0.2 or devcloud2 with xcp 4.1 or the newer one with xcp 4.4 > won't become active after adding because of the ssh command erroneously > failing a remote execution of 'mkdir -p /opt/cloud/bin /var/log/cloud'. The > command executes succesfully but an exceptions is logged: > 2014-05-12 15:52:50,395 DEBUG [c.c.u.s.SSHCmdHelper] > (DirectAgent-1:ctx-704cd231) Executing cmd: mkdir -p /opt/cloud/bin > /var/log/cloud > 2014-05-12 15:52:51,409 DEBUG [c.c.u.s.SSHCmdHelper] > (DirectAgent-1:ctx-704cd231) Ssh executed failed > java.lang.NullPointerException > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmdOneShotWithExitCode(SSHCmdHelper.java:159) > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmdOneShot(SSHCmdHelper.java:170) > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmd(SSHCmdHelper.java:66) > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmd(SSHCmdHelper.java:91) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.setupServer(CitrixResourceBase.java:4845) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4674) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:490) > at > com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:176) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) > 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.run(FutureTask.java:262) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6662) New XenServer host is not activated due to no agent connection
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036512#comment-14036512 ] ASF subversion and git services commented on CLOUDSTACK-6662: - Commit ce3550f8bc0bafacae5bdca8de8905bf31cc in cloudstack's branch refs/heads/master from [~anthonyxu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ce3550f ] CLOUDSTACK-6662 CLOUDSTACK-6844 exit status delivery might get delayed Please enter the commit message for your changes. Lines starting > New XenServer host is not activated due to no agent connection > -- > > Key: CLOUDSTACK-6662 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6662 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.0 >Reporter: Daan Hoogland >Assignee: Anthony Xu >Priority: Critical > > A new xenserver 6.0.2 or devcloud2 with xcp 4.1 or the newer one with xcp 4.4 > won't become active after adding because of the ssh command erroneously > failing a remote execution of 'mkdir -p /opt/cloud/bin /var/log/cloud'. The > command executes succesfully but an exceptions is logged: > 2014-05-12 15:52:50,395 DEBUG [c.c.u.s.SSHCmdHelper] > (DirectAgent-1:ctx-704cd231) Executing cmd: mkdir -p /opt/cloud/bin > /var/log/cloud > 2014-05-12 15:52:51,409 DEBUG [c.c.u.s.SSHCmdHelper] > (DirectAgent-1:ctx-704cd231) Ssh executed failed > java.lang.NullPointerException > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmdOneShotWithExitCode(SSHCmdHelper.java:159) > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmdOneShot(SSHCmdHelper.java:170) > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmd(SSHCmdHelper.java:66) > at > com.cloud.utils.ssh.SSHCmdHelper.sshExecuteCmd(SSHCmdHelper.java:91) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.setupServer(CitrixResourceBase.java:4845) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4674) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:490) > at > com.cloud.hypervisor.xen.resource.XcpOssResource.executeRequest(XcpOssResource.java:176) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) > 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.run(FutureTask.java:262) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6940) Templates cannot be downloaded from URLs without matching file extensions
Min Chen created CLOUDSTACK-6940: Summary: Templates cannot be downloaded from URLs without matching file extensions Key: CLOUDSTACK-6940 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6940 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.2.1 Reporter: Min Chen Assignee: Min Chen Fix For: 4.5.0 When registering templates with CloudStack, it is necessary to provide a URL from which the template can be downloaded. CloudStack validates the format of these URLs, but it does so quite aggressively, sometimes rejecting URLs that are perfectly valid. In particular, CloudStack expects and requires the URL to carry a file extension that matches the expected template, eg. ".vhd" or ".vhd.gz". If the URL doesn't have such an extension, it will be rejected, even if it is a perfectly valid URL from which a VHD can be downloaded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6940) Templates cannot be downloaded from URLs without matching file extensions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036604#comment-14036604 ] ASF subversion and git services commented on CLOUDSTACK-6940: - Commit 008162a75770b83f6249be153f42fd753bdacde5 in cloudstack's branch refs/heads/4.4-forward from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=008162a ] CLOUDSTACK-6940:Templates cannot be downloaded from URLs without matching file extensions. > Templates cannot be downloaded from URLs without matching file extensions > - > > Key: CLOUDSTACK-6940 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6940 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.1 >Reporter: Min Chen >Assignee: Min Chen > Fix For: 4.5.0 > > > When registering templates with CloudStack, it is necessary to provide a URL > from which the template can be downloaded. > CloudStack validates the format of these URLs, but it does so quite > aggressively, sometimes rejecting URLs that are perfectly valid. > In particular, CloudStack expects and requires the URL to carry a file > extension that matches the expected template, eg. ".vhd" or ".vhd.gz". If the > URL doesn't have such an extension, it will be rejected, even if it is a > perfectly valid URL from which a VHD can be downloaded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6941) Can't choose storage for the volume, when attaching uploaded data volume to VM
Prachi Damle created CLOUDSTACK-6941: Summary: Can't choose storage for the volume, when attaching uploaded data volume to VM Key: CLOUDSTACK-6941 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6941 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: Prachi Damle Assignee: Prachi Damle Fix For: 4.4.0, 4.5.0 When a user uploads a data volume to the CCP and wants to attach to VM, then it is not possible to choose on which storage to put volume. In Short: User needs ability to specify the primary storage when attaching an uploaded volume to an instance. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6940) Templates cannot be downloaded from URLs without matching file extensions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036635#comment-14036635 ] ASF subversion and git services commented on CLOUDSTACK-6940: - Commit 569e94908b6fa471f2f72578e1ff21f3fa7c6a4e in cloudstack's branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=569e949 ] CLOUDSTACK-6940:Templates cannot be downloaded from URLs without matching file extensions. > Templates cannot be downloaded from URLs without matching file extensions > - > > Key: CLOUDSTACK-6940 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6940 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.1 >Reporter: Min Chen >Assignee: Min Chen > Fix For: 4.5.0 > > > When registering templates with CloudStack, it is necessary to provide a URL > from which the template can be downloaded. > CloudStack validates the format of these URLs, but it does so quite > aggressively, sometimes rejecting URLs that are perfectly valid. > In particular, CloudStack expects and requires the URL to carry a file > extension that matches the expected template, eg. ".vhd" or ".vhd.gz". If the > URL doesn't have such an extension, it will be rejected, even if it is a > perfectly valid URL from which a VHD can be downloaded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6940) Templates cannot be downloaded from URLs without matching file extensions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-6940. -- Resolution: Fixed > Templates cannot be downloaded from URLs without matching file extensions > - > > Key: CLOUDSTACK-6940 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6940 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.1 >Reporter: Min Chen >Assignee: Min Chen > Fix For: 4.5.0 > > > When registering templates with CloudStack, it is necessary to provide a URL > from which the template can be downloaded. > CloudStack validates the format of these URLs, but it does so quite > aggressively, sometimes rejecting URLs that are perfectly valid. > In particular, CloudStack expects and requires the URL to carry a file > extension that matches the expected template, eg. ".vhd" or ".vhd.gz". If the > URL doesn't have such an extension, it will be rejected, even if it is a > perfectly valid URL from which a VHD can be downloaded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6941) Can't choose storage for the volume, when attaching uploaded data volume to VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036660#comment-14036660 ] ASF subversion and git services commented on CLOUDSTACK-6941: - Commit 13bd8beb914ae11d45630b2aa34e15889aff91da in cloudstack's branch refs/heads/4.4-forward from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=13bd8be ] CLOUDSTACK-6941: Can't choose storage for the volume, when attaching uploaded data volume to VM Changes: - Only way to choose a certain storage pool is by using disk_offering_tags - Added a parameter to take in a disk offering Id. - Admin will have to create a custom sized disk offering and tag it as necessary for the user - This custom offering Id should be passed during uploadVolume to associate the volume with this disk offering > Can't choose storage for the volume, when attaching uploaded data volume to VM > -- > > Key: CLOUDSTACK-6941 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6941 > 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: Prachi Damle >Assignee: Prachi Damle > Fix For: 4.4.0, 4.5.0 > > > When a user uploads a data volume to the CCP and wants to attach to VM, then > it is not possible to choose on which storage to put volume. > In Short: User needs ability to specify the primary storage when attaching an > uploaded volume to an instance. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6941) Can't choose storage for the volume, when attaching uploaded data volume to VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036688#comment-14036688 ] ASF subversion and git services commented on CLOUDSTACK-6941: - Commit 05c01a7dc958391c086d7b100a2aa94a98c252d6 in cloudstack's branch refs/heads/master from [~prachidamle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=05c01a7 ] CLOUDSTACK-6941: Can't choose storage for the volume, when attaching uploaded data volume to VM Changes: - Only way to choose a certain storage pool is by using disk_offering_tags - Added a parameter to take in a disk offering Id. - Admin will have to create a custom sized disk offering and tag it as necessary for the user - This custom offering Id should be passed during uploadVolume to associate the volume with this disk offering > Can't choose storage for the volume, when attaching uploaded data volume to VM > -- > > Key: CLOUDSTACK-6941 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6941 > 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: Prachi Damle >Assignee: Prachi Damle > Fix For: 4.4.0, 4.5.0 > > > When a user uploads a data volume to the CCP and wants to attach to VM, then > it is not possible to choose on which storage to put volume. > In Short: User needs ability to specify the primary storage when attaching an > uploaded volume to an instance. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6941) Can't choose storage for the volume, when attaching uploaded data volume to VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Damle resolved CLOUDSTACK-6941. -- Resolution: Fixed > Can't choose storage for the volume, when attaching uploaded data volume to VM > -- > > Key: CLOUDSTACK-6941 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6941 > 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: Prachi Damle >Assignee: Prachi Damle > Fix For: 4.4.0, 4.5.0 > > > When a user uploads a data volume to the CCP and wants to attach to VM, then > it is not possible to choose on which storage to put volume. > In Short: User needs ability to specify the primary storage when attaching an > uploaded volume to an instance. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6698) listResourceDetals - normal user able to list details not belonging to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi reassigned CLOUDSTACK-6698: --- Assignee: Rajani Karuturi > listResourceDetals - normal user able to list details not belonging to it > - > > Key: CLOUDSTACK-6698 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6698 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0 >Reporter: Nitin Mehta >Assignee: Rajani Karuturi >Priority: Critical > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6698) listResourceDetals - normal user able to list details not belonging to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-6698: Assignee: (was: Rajani Karuturi) > listResourceDetals - normal user able to list details not belonging to it > - > > Key: CLOUDSTACK-6698 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6698 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0 >Reporter: Nitin Mehta >Priority: Critical > Fix For: 4.4.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6122) LXC 2.0
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-6122: Assignee: Kishan Kavala > LXC 2.0 > --- > > Key: CLOUDSTACK-6122 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6122 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > > LXC support was added to CloudStack in 4.2 release. The objective of this > feature is to enhance LXC support by adding more features. > Features: > - Support data disk while creating container > - Support attach/detach data disk > - Support Ceph storage > - Migrate volume of a stopped container > - Create template from ROOT volume > - Attach/Detach an ISO to a container > - Launch container from ISO > - Console Access > I'll create sub-tickets for each of the above items -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6942) LXC: optimize template copy to primary
Rajani Karuturi created CLOUDSTACK-6942: --- Summary: LXC: optimize template copy to primary Key: CLOUDSTACK-6942 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6942 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller Reporter: Rajani Karuturi Assignee: Rajani Karuturi Fix For: 4.5.0 most of the time spent when launching a container is in template copy extraction. optimize it so that the template creation can be faster. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6942) LXC: optimize template copy to primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-6942: Description: most of the time spent when launching a container is in template copy and extraction. optimize it so that the container launch can be faster. (was: most of the time spent when launching a container is in template copy and extraction. optimize it so that the template creation can be faster.) > LXC: optimize template copy to primary > -- > > Key: CLOUDSTACK-6942 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6942 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > Fix For: 4.5.0 > > > most of the time spent when launching a container is in template copy and > extraction. optimize it so that the container launch can be faster. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6942) LXC: optimize template copy to primary
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-6942: Description: most of the time spent when launching a container is in template copy and extraction. optimize it so that the template creation can be faster. (was: most of the time spent when launching a container is in template copy extraction. optimize it so that the template creation can be faster.) > LXC: optimize template copy to primary > -- > > Key: CLOUDSTACK-6942 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6942 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi > Fix For: 4.5.0 > > > most of the time spent when launching a container is in template copy and > extraction. optimize it so that the template creation can be faster. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6636) [Windows] Can not create Template from ROOT snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036950#comment-14036950 ] ASF subversion and git services commented on CLOUDSTACK-6636: - Commit 5cbb182c6d280a2d286d6b2443b235bcf87f2f17 in cloudstack's branch refs/heads/master from [~damoder.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5cbb182 ] CLOUDSTACK-6636: [Windows] Can not create Template from ROOT snapshot on Windows management server with Xen/NFS storage type. This change is only for XenServer with NFS Storage Server. Will fix remaining when we touch them. Signed-off-by: Koushik Das > [Windows] Can not create Template from ROOT snapshot > > > Key: CLOUDSTACK-6636 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6636 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: Future, 4.5.0 >Reporter: Damodar Reddy T >Assignee: Damodar Reddy T > > Steps to reproduce the issue > 1. Create a snapshot from ROOT disk > 2. Goto the above created snapshot > 3. Try to create template out of it. > It is failing with the following trace. > 014-05-12 04:02:01,813 WARN [c.c.h.x.r.XenServerStorageProcessor] > (DirectAgent-428:ctx-2ece4baa) null due to Illegal character in path at index > 47: > nfs://10.147.28.7/export/home/damoder/secondary\snapshots/2/3\dc74fe1c-0891-4cb3-aaf2-1c03a25b6d58.vhd > java.net.URISyntaxException: Illegal character in path at index 47: > nfs://10.147.28.7/export/home/damoder/secondary\snapshots/2/3\dc74fe1c-0891-4cb3-aaf2-1c03a25b6d58.vhd > at java.net.URI$Parser.fail(Unknown Source) > at java.net.URI$Parser.checkChars(Unknown Source) > at java.net.URI$Parser.parseHierarchical(Unknown Source) > at java.net.URI$Parser.parse(Unknown Source) > at java.net.URI.(Unknown Source) > at > com.cloud.hypervisor.xen.resource.XenServerStorageProcessor.createVolumeFromSnapshot(XenServerStorageProcessor.java:1617) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute(StorageSubsystemCommandHandlerBase.java:96) > at > com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleStorageCommands(StorageSubsystemCommandHandlerBase.java:52) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:542) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:60) > at > com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:93) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) > 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(Unknown Source) > at java.util.concurrent.FutureTask.run(Unknown Source) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown > Source) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown > Source) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6896) Dynamically added OS Type throws NoSuchElement Exception on Xen
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kumar Bandarupally closed CLOUDSTACK-6896. Closing as per dev comments > Dynamically added OS Type throws NoSuchElement Exception on Xen > --- > > Key: CLOUDSTACK-6896 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6896 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller >Affects Versions: 4.4.0 > Environment: Managment Server: 4.4.0 > Host: XenServer Hypervisor 6.2 >Reporter: Pavan Kumar Bandarupally >Assignee: Amogh Vasekar >Priority: Critical > Fix For: 4.4.0 > > Attachments: management-server.log > > > A dynamically added OS is used as OS type for an ISO registered in > cloudstack. An instance deployed using that ISO doesn't get created throwing > an exception. > MS Exception trace excerpt: > = > 2014-06-12 02:03:45,707 DEBUG [c.c.a.m.DirectAgentAttache] > (DirectAgent-281:ctx-c47880f2) Seq 1-5437252125119752015: Executing request > 2014-06-12 02:03:45,720 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-281:ctx-c47880f2) 1. The VM i-2-8-VM is in Starting state. > 2014-06-12 02:03:45,723 WARN [c.c.h.x.r.XenServer620Resource] > (DirectAgent-281:ctx-c47880f2) XenServer 6.2.0 DOES NOT support Guest OS type > centospavan > 2014-06-12 02:03:45,726 DEBUG [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-281:ctx-c47880f2) Cannot find template : null on XS version: > com.cloud.hypervisor.xen.resource.XenServer620Resource > 2014-06-12 02:03:45,727 WARN [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-281:ctx-c47880f2) Catch Exception: class > java.util.NoSuchElementException due to java.util.NoSuchElementException > java.util.NoSuchElementException > at > java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:396) > at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:405) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTemplate(CitrixResourceBase.java:1359) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1787) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:504) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61) > at > com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:293) > 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.run(FutureTask.java:262) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > 2014-06-12 02:03:45,729 WARN [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-281:ctx-c47880f2) Unable to start i-2-8-VM due to > java.util.NoSuchElementException > at > java.util.LinkedHashMap$LinkedHashIterator.nextEntry(LinkedHashMap.java:396) > at java.util.LinkedHashMap$KeyIterator.next(LinkedHashMap.java:405) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVmFromTemplate(CitrixResourceBase.java:1359) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1787) > at > com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:504) > at > com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
[jira] [Commented] (CLOUDSTACK-6931) LXC agent install : hypervisor.type not set
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14037010#comment-14037010 ] ASF subversion and git services commented on CLOUDSTACK-6931: - Commit 89854de18da62d0808363781ad27fc310eb9b8cd in cloudstack's branch refs/heads/master from [~kishan] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=89854de ] CLOUDSTACK-6931: Set hypervisor.type in agent.properties using cloudstack-setup -t option. Default is kvm. > LXC agent install : hypervisor.type not set > --- > > Key: CLOUDSTACK-6931 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6931 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala > Fix For: 4.5.0 > > > While adding LXC host, hypervisor.type param in agent.properties is not set. > Agent defaults to KVM when the param is not set. cloudstack-agent-setup > script should update hypervisor.type as lxc -- This message was sent by Atlassian JIRA (v6.2#6252)
