[jira] [Closed] (CLOUDSTACK-7546) [LXC] agent addition to MS is failing if we stop service NetworkManager
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7546. -- [LXC] agent addition to MS is failing if we stop service NetworkManager Key: CLOUDSTACK-7546 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7546 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Blocker Fix For: 4.5.0 Repro Steps: 1. Install MS and agent on two different host 2. Stop networkmanager on host and also chkconfig networkmanager off 3. Create a Advance zone with LXC Bug: Agent addition to CS will fail agent log shows : 2014-09-15 16:38:26,027 ERROR [cloud.agent.AgentShell] (main:null) Unable to start agent: com.cloud.utils.exception.CloudRuntimeException: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:830) at com.cloud.agent.Agent.init(Agent.java:163) at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:401) at com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:371) at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:355) at com.cloud.agent.AgentShell.start(AgentShell.java:465) 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.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243) 2014-09-15 16:39:37,406 INFO [cloud.agent.AgentShell] (main:null) Agent started Additional info : checked Libvirtd status once agent fails to start and status was stopped in above scenario But if we dont stop networkmanager service before adding agent to CS then agent addition succeeds without fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7568) [LXC] system VM fails to start on LXC host
shweta agarwal created CLOUDSTACK-7568:
--
Summary: [LXC] system VM fails to start on LXC host
Key: CLOUDSTACK-7568
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7568
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Blocker
Fix For: 4.5.0
Repro steps:
Create a LXC advance zone and enable it . Notice System VMs fails to start.
Agent log shows :
2014-09-17 12:14:12,737 WARN [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-4:null) LibvirtException
org.libvirt.LibvirtException: unsupported configuration: CPU tuning is not
available on this host
at org.libvirt.ErrorHandler.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.domainCreateXML(Unknown Source)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1253)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3781)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1347)
at com.cloud.agent.Agent.processRequest(Agent.java:503)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)
at com.cloud.utils.nio.Task.run(Task.java:84)
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-09-17 12:14:12,738 DEBUG [kvm.storage.KVMStoragePoolManager]
(agentRequest-Handler-4:null) Disconnecting disk
2c68fd25-7f69-4db6-b0d9-3e8072dea698
2014-09-17 12:14:12,738 DEBUG [kvm.storage.LibvirtStorageAdaptor]
(agentRequest-Handler-4:null) Trying to fetch storage pool
dfa2ec3c-d133-3284-8583-0a0845aa4424 from libvirt
2014-09-17 12:14:12,846 DEBUG [cloud.agent.Agent] (agentRequest-Handler-4:null)
Seq 1-4318389092694884367: { Ans: , MgmtId: 233845178472723, via: 1, Ver: v1,
Flags: 10,
[{com.cloud.agent.api.StartAnswer:{vm:{id:1,name:v-1-VM,type:ConsoleProxy,cpus:1,minSpeed:500,maxSpeed:500,minRam:1073741824,maxRam:1073741824,arch:x86_64,os:Debian
GNU/Linux 5.0 (64-bit),platformEmulator:Debian GNU/Linux 5,bootArgs:
template=domP type=consoleproxy host=10.147.28.41 port=8250 name=v-1-VM zone=1
pod=1 guid=Proxy.1 proxy_vm=1 disable_rp_filter=true eth2ip=10.147.30.160
eth2mask=255.255.255.0 gateway=10.147.30.1 eth0ip=169.254.1.68
eth0mask=255.255.0.0 eth1ip=10.147.28.167 eth1mask=255.255.255.0
mgmtcidr=10.147.28.0/24 localgw=10.147.28.1 internaldns1=10.140.50.6
dns1=10.140.50.6,enableHA:false,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:vzcOWbWjEvLy75PCdH0IIg==,vncAddr:10.147.28.49,params:{},uuid:b43765e9-c099-45f9-9ceb-8d455f9bf2a7,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:2c68fd25-7f69-4db6-b0d9-3e8072dea698,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:dfa2ec3c-d133-3284-8583-0a0845aa4424,id:1,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/shweta/goleta.lxc.primary,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=PrimarySTOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424}},name:ROOT-1,size:0,path:2c68fd25-7f69-4db6-b0d9-3e8072dea698,volumeId:1,vmName:v-1-VM,accountId:1,format:QCOW2,provisioningType:THIN,id:1,deviceId:0,hypervisorType:LXC}},diskSeq:0,path:2c68fd25-7f69-4db6-b0d9-3e8072dea698,type:ROOT,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:0}}],nics:[{deviceId:2,networkRateMbps:-1,defaultNic:true,pxeDisable:true,nicUuid:b1ca319a-0dbf-46c1-84db-f72b1bfa4aa0,uuid:30ffae39-67d2-47cf-afe7-48e7265dcdd6,ip:10.147.30.160,netmask:255.255.255.0,gateway:10.147.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7563) ClassCastException in VirtualMachineManagerImpl in handling various Agent command answer.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136956#comment-14136956 ] Rohit Yadav commented on CLOUDSTACK-7563: - Does this bug also apply for 4.3, 4.4 branch since in the description it says affects 4.3? ClassCastException in VirtualMachineManagerImpl in handling various Agent command answer. - Key: CLOUDSTACK-7563 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7563 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: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.5.0 irtualMachineManagerImpl has many methods directly cast the Answer received from AgentManager.send or AgentManager.easySend to the expected Answer class in the normal case. This will throw unhandled ClassCastException in some unexcepted cases where host is down and agent is disconnected, which will lead to cloud instability. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7143) Refactor systemvm build scripts to be easier to test
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136967#comment-14136967 ] ASF GitHub Bot commented on CLOUDSTACK-7143: Github user lsimons commented on the pull request: https://github.com/apache/cloudstack/pull/16#issuecomment-55866128 Hey Rohit, like I thought, a ruby issue.I'm surprised RVM isn't enabled already since the build was already using it (I think...). The fix should be along the lines of http://rvm.io/integration/jenkins . The other part of the fix is making sure that the inline shell scripts act as login scripts so that rvm is loaded, i.e. they need to start with ``` #!/bin/bash -l ``` Refactor systemvm build scripts to be easier to test Key: CLOUDSTACK-7143 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7143 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Reporter: Leo Simons Fix For: Future The veewee-wrapping build code could do with some love. E-mail thread: http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201407.mbox/%3C7A6CF878-7A28-4D4A-BCD2-0C264F8C90B7%40schubergphilis.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7387) [Automation] Fix the script test_vpc_host_maintenance.py - Code is hardcoded to use certain host tags
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136977#comment-14136977 ] ASF subversion and git services commented on CLOUDSTACK-7387: - Commit 20f9d3dcd8a980e03b651629b510b6e98e411271 in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=20f9d3d ] CLOUDSTACK-7387: Corrected code related to adding host tags Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org [Automation] Fix the script test_vpc_host_maintenance.py - Code is hardcoded to use certain host tags --- Key: CLOUDSTACK-7387 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7387 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Gaurav Aradhye Priority: Critical Fix For: 4.5.0 *Script is present at:* component/maint/test_vpc_host_maintenance.py Currently script assumes that the deployment has hosts with host_tag HOST_TAGS_HERE and uses two service offerings with this host_tag. The script is hardcoded with the above information. The proper design and correction should be as follows. # Find the cluster with two hosts ## If no two host cluster is found error out with proper message # Edit the host tags on the two hosts to two different unique names # Create corresponding service offerings with the two different unique names # Conduct the tests # In teardown script section of the script, edit the host tags on the hosts to empty. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7387) [Automation] Fix the script test_vpc_host_maintenance.py - Code is hardcoded to use certain host tags
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136976#comment-14136976 ] ASF subversion and git services commented on CLOUDSTACK-7387: - Commit 374d6ad7981bbec2270e414b161f2e7e74a93758 in cloudstack's branch refs/heads/master from SrikanteswaraRao Talluri [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=374d6ad ] Revert CLOUDSTACK-7387: Corrected code related to adding host tags This reverts commit 1b14fa6abef5811079eeb7cbd26ab718f6f69405. [Automation] Fix the script test_vpc_host_maintenance.py - Code is hardcoded to use certain host tags --- Key: CLOUDSTACK-7387 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7387 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Gaurav Aradhye Priority: Critical Fix For: 4.5.0 *Script is present at:* component/maint/test_vpc_host_maintenance.py Currently script assumes that the deployment has hosts with host_tag HOST_TAGS_HERE and uses two service offerings with this host_tag. The script is hardcoded with the above information. The proper design and correction should be as follows. # Find the cluster with two hosts ## If no two host cluster is found error out with proper message # Edit the host tags on the two hosts to two different unique names # Create corresponding service offerings with the two different unique names # Conduct the tests # In teardown script section of the script, edit the host tags on the hosts to empty. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7557) test_vpc_network.TestVPCNetworkUpgrade.test_01_network_services_upgrade failed with Network state should change to Allocated, it is Implemented
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136981#comment-14136981 ] ASF subversion and git services commented on CLOUDSTACK-7557: - Commit 58ea99a9d665b4370651fe867988d597ea16165e in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=58ea99a ] CLOUDSTACK-7557: test_vpc_network.py - Fixed wait period of network state check Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org test_vpc_network.TestVPCNetworkUpgrade.test_01_network_services_upgrade failed with Network state should change to Allocated, it is Implemented - Key: CLOUDSTACK-7557 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7557 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 After stopping VMs, the network state should change from Implemented to Allocated after some time. Root cause of failure: The wait time in test case is too less. It's 6 sec instead of 60 seconds. Hence the test case failed before the state changed to Allocated. Resolution: Fix the wait time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7547) [Task] Move Brocade device data to config file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136983#comment-14136983 ] ASF subversion and git services commented on CLOUDSTACK-7547: - Commit 71611da17f082d9d813c89767a69c5b13ba5adf1 in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=71611da ] CLOUDSTACK-7547: Brocade Device Data was hard coded, moved it to config file Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org [Task] Move Brocade device data to config file -- Key: CLOUDSTACK-7547 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7547 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 test_brocade_vcs.py has brocade device data hard coded in it. This data should be moved to config file which is specific to the setup, and also relevant changes should be done to the test case (to read the data from config). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7143) Refactor systemvm build scripts to be easier to test
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136986#comment-14136986 ] ASF GitHub Bot commented on CLOUDSTACK-7143: Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/16#issuecomment-55868179 Leo, From the jenkins job log [1] I see that the newly refactored build script is trying to setup ruby [2] and failing because of this. The jenkins job [1] already has rvm setup as I simply cloned it from previous systemvm jobs. Can you look at the job and fix it? If you don't have an account on [1], can may request access to Hugo, Edison, Chip and other PMC members. [1] http://jenkins.buildacloud.org/job/systemvm-refactor-CLOUDSTACK-7143/3/console [2] https://github.com/schubergphilis/cloudstack/blob/feature/systemvm-refactor-for-upstream/tools/appliance/build.sh#L272 Refactor systemvm build scripts to be easier to test Key: CLOUDSTACK-7143 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7143 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Reporter: Leo Simons Fix For: Future The veewee-wrapping build code could do with some love. E-mail thread: http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201407.mbox/%3C7A6CF878-7A28-4D4A-BCD2-0C264F8C90B7%40schubergphilis.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7497) [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] shweta agarwal closed CLOUDSTACK-7497. -- Verified fixed [UI] deploy VM failing as hypervisor type passed is KVM instead of LXC --- Key: CLOUDSTACK-7497 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7497 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Jessica Wang Priority: Blocker Labels: DEVREV Fix For: 4.5.0 Attachments: MS.tar.gz, after_checked_in_UI_fix.PNG, cloud.dmp, jessica_web_site_loaded_with_Shweta_databaseDump_1A.PNG, jessica_web_site_loaded_with_Shweta_databaseDump_1B.PNG, shweta_website.PNG Repro steps: Create a LXC zone with 2 cluster one LXc and one KVM Create VM with LXC template Bug: Deploy vm fails as hypervisor type is passed as KVM 014-09-05 14:06:09,520 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24) ===START=== 10.146.0.131 -- GET command=deployVirtualMachineresponse=jsonsessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3Dzoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82atemplateid=2175190d-212a-4078-aedb-d25e4ddcdeb3hypervisor=KVMserviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810baffinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48_=1409906169711 2014-09-05 14:06:09,581 INFO [c.c.a.ApiServer] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) Hypervisor passed to the deployVm call, is different from the hypervisor type of the template 2014-09-05 14:06:09,582 DEBUG [c.c.a.ApiServlet] (catalina-exec-8:ctx-7b5dcb24 ctx-2a5b99cd) ===END=== 10.146.0.131 -- GET command=deployVirtualMachineresponse=jsonsessionkey=NZyAJuyUuohCrPbjervw1hkdBlM%3Dzoneid=7d97ec72-39c7-4fbc-b6f3-7710ada1a82atemplateid=2175190d-212a-4078-aedb-d25e4ddcdeb3hypervisor=KVMserviceofferingid=82ab5842-2a12-4160-bba4-4b2ff81e810baffinitygroupids=345511d9-fa5f-46e8-b101-1d4ea0a1ba47iptonetworklist%5B0%5D.networkid=04bf986a-ac13-4eaf-84e9-e99dcf508c48_=1409906169711 2014-09-05 14:06:12,573 DEBUG [o.a.c.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-6de2885c) Zone 2 is ready to launch secondary storage VM 2014-09-05 14:06:12,689 DEBUG [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-a134b2b7) Zone 2 is ready to launch console proxy -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7547) [Task] Move Brocade device data to config file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye resolved CLOUDSTACK-7547. Resolution: Fixed [Task] Move Brocade device data to config file -- Key: CLOUDSTACK-7547 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7547 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 test_brocade_vcs.py has brocade device data hard coded in it. This data should be moved to config file which is specific to the setup, and also relevant changes should be done to the test case (to read the data from config). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7557) test_vpc_network.TestVPCNetworkUpgrade.test_01_network_services_upgrade failed with Network state should change to Allocated, it is Implemented
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye resolved CLOUDSTACK-7557. Resolution: Fixed test_vpc_network.TestVPCNetworkUpgrade.test_01_network_services_upgrade failed with Network state should change to Allocated, it is Implemented - Key: CLOUDSTACK-7557 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7557 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 After stopping VMs, the network state should change from Implemented to Allocated after some time. Root cause of failure: The wait time in test case is too less. It's 6 sec instead of 60 seconds. Hence the test case failed before the state changed to Allocated. Resolution: Fix the wait time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7569) [LXC] NetworkManager service restarts when we reboot LXC agent
shweta agarwal created CLOUDSTACK-7569: -- Summary: [LXC] NetworkManager service restarts when we reboot LXC agent Key: CLOUDSTACK-7569 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7569 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Blocker Fix For: 4.5.0 Repro steps: Create a LXC zone. Once zone is up and enable Reboot LXC host Bug: Network manager service starts with reboot of LXC host. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7570) min and max iops are being processed null while creating a vm using third party storage plugins
punith created CLOUDSTACK-7570: -- Summary: min and max iops are being processed null while creating a vm using third party storage plugins Key: CLOUDSTACK-7570 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7570 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: punith Fix For: 4.5.0 this bug will occur only in the following scenario 1 create a compute offering with custom mode but not custom IOPS 2 input the required min and max IOPS 3 now create a VM based on the created compute offering issue: ServiceOfferingVO dummyoffering = new ServiceOfferingVO(serviceOffering); this constructor is not setting the min and max IOPS for the dummyoffering fix: adding the min and max iops to the following constructor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7569) [LXC] NetworkManager service restarts when we reboot LXC agent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14137146#comment-14137146 ] ASF subversion and git services commented on CLOUDSTACK-7569: - Commit 983a3b80e2eb03dd967d38f2e46f4e07ac5dc1c6 in cloudstack's branch refs/heads/master from [~kishan] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=983a3b8 ] CLOUDSTACK-7568, CLOUDSTACK-7569: Use systemctl for managing services in RHEL7. chkconfig --del doesn't work in RHEL7. [LXC] NetworkManager service restarts when we reboot LXC agent -- Key: CLOUDSTACK-7569 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7569 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Blocker Fix For: 4.5.0 Repro steps: Create a LXC zone. Once zone is up and enable Reboot LXC host Bug: Network manager service starts with reboot of LXC host. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7568) [LXC] system VM fails to start on LXC host
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14137145#comment-14137145
]
ASF subversion and git services commented on CLOUDSTACK-7568:
-
Commit 983a3b80e2eb03dd967d38f2e46f4e07ac5dc1c6 in cloudstack's branch
refs/heads/master from [~kishan]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=983a3b8 ]
CLOUDSTACK-7568, CLOUDSTACK-7569: Use systemctl for managing services in RHEL7.
chkconfig --del doesn't work in RHEL7.
[LXC] system VM fails to start on LXC host
---
Key: CLOUDSTACK-7568
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7568
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Blocker
Fix For: 4.5.0
Repro steps:
Create a LXC advance zone and enable it . Notice System VMs fails to start.
Agent log shows :
2014-09-17 12:14:12,737 WARN [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-4:null) LibvirtException
org.libvirt.LibvirtException: unsupported configuration: CPU tuning is not
available on this host
at org.libvirt.ErrorHandler.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.domainCreateXML(Unknown Source)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1253)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3781)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1347)
at com.cloud.agent.Agent.processRequest(Agent.java:503)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)
at com.cloud.utils.nio.Task.run(Task.java:84)
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-09-17 12:14:12,738 DEBUG [kvm.storage.KVMStoragePoolManager]
(agentRequest-Handler-4:null) Disconnecting disk
2c68fd25-7f69-4db6-b0d9-3e8072dea698
2014-09-17 12:14:12,738 DEBUG [kvm.storage.LibvirtStorageAdaptor]
(agentRequest-Handler-4:null) Trying to fetch storage pool
dfa2ec3c-d133-3284-8583-0a0845aa4424 from libvirt
2014-09-17 12:14:12,846 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-4:null) Seq 1-4318389092694884367: { Ans: , MgmtId:
233845178472723, via: 1, Ver: v1, Flags: 10,
[{com.cloud.agent.api.StartAnswer:{vm:{id:1,name:v-1-VM,type:ConsoleProxy,cpus:1,minSpeed:500,maxSpeed:500,minRam:1073741824,maxRam:1073741824,arch:x86_64,os:Debian
GNU/Linux 5.0 (64-bit),platformEmulator:Debian GNU/Linux 5,bootArgs:
template=domP type=consoleproxy host=10.147.28.41 port=8250 name=v-1-VM
zone=1 pod=1 guid=Proxy.1 proxy_vm=1 disable_rp_filter=true
eth2ip=10.147.30.160 eth2mask=255.255.255.0 gateway=10.147.30.1
eth0ip=169.254.1.68 eth0mask=255.255.0.0 eth1ip=10.147.28.167
eth1mask=255.255.255.0 mgmtcidr=10.147.28.0/24 localgw=10.147.28.1
internaldns1=10.140.50.6
dns1=10.140.50.6,enableHA:false,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:vzcOWbWjEvLy75PCdH0IIg==,vncAddr:10.147.28.49,params:{},uuid:b43765e9-c099-45f9-9ceb-8d455f9bf2a7,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:2c68fd25-7f69-4db6-b0d9-3e8072dea698,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:dfa2ec3c-d133-3284-8583-0a0845aa4424,id:1,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/shweta/goleta.lxc.primary,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=PrimarySTOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424}},name:ROOT-1,size:0,path:2c68fd25-7f69-4db6-b0d9-3e8072dea698,volumeId:1,vmName:v-1-VM,accountId:1,format:QCOW2,provisioningType:THIN,id:1,deviceId:0,hypervisorType:LXC}},diskSeq:0,path:2c68fd25-7f69-4db6-b0d9-3e8072dea698,type:ROOT,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:0}}],nics:[{deviceId:2,networkRateMbps:-1,defaultNic:true,pxeDisable:true,nicUuid:b1ca319a-0dbf-46c1-84db-f72b1bfa4aa0,uuid:30ffae39-67d2-47cf-afe7-48e7265dcdd6,ip:10.147.30.160,netmask:255.255.255.0,gateway:10.147.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7568) [LXC] system VM fails to start on LXC host
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kishan Kavala resolved CLOUDSTACK-7568.
---
Resolution: Fixed
[LXC] system VM fails to start on LXC host
---
Key: CLOUDSTACK-7568
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7568
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Blocker
Fix For: 4.5.0
Repro steps:
Create a LXC advance zone and enable it . Notice System VMs fails to start.
Agent log shows :
2014-09-17 12:14:12,737 WARN [kvm.resource.LibvirtComputingResource]
(agentRequest-Handler-4:null) LibvirtException
org.libvirt.LibvirtException: unsupported configuration: CPU tuning is not
available on this host
at org.libvirt.ErrorHandler.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.processError(Unknown Source)
at org.libvirt.Connect.domainCreateXML(Unknown Source)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1253)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:3781)
at
com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1347)
at com.cloud.agent.Agent.processRequest(Agent.java:503)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:810)
at com.cloud.utils.nio.Task.run(Task.java:84)
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-09-17 12:14:12,738 DEBUG [kvm.storage.KVMStoragePoolManager]
(agentRequest-Handler-4:null) Disconnecting disk
2c68fd25-7f69-4db6-b0d9-3e8072dea698
2014-09-17 12:14:12,738 DEBUG [kvm.storage.LibvirtStorageAdaptor]
(agentRequest-Handler-4:null) Trying to fetch storage pool
dfa2ec3c-d133-3284-8583-0a0845aa4424 from libvirt
2014-09-17 12:14:12,846 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-4:null) Seq 1-4318389092694884367: { Ans: , MgmtId:
233845178472723, via: 1, Ver: v1, Flags: 10,
[{com.cloud.agent.api.StartAnswer:{vm:{id:1,name:v-1-VM,type:ConsoleProxy,cpus:1,minSpeed:500,maxSpeed:500,minRam:1073741824,maxRam:1073741824,arch:x86_64,os:Debian
GNU/Linux 5.0 (64-bit),platformEmulator:Debian GNU/Linux 5,bootArgs:
template=domP type=consoleproxy host=10.147.28.41 port=8250 name=v-1-VM
zone=1 pod=1 guid=Proxy.1 proxy_vm=1 disable_rp_filter=true
eth2ip=10.147.30.160 eth2mask=255.255.255.0 gateway=10.147.30.1
eth0ip=169.254.1.68 eth0mask=255.255.0.0 eth1ip=10.147.28.167
eth1mask=255.255.255.0 mgmtcidr=10.147.28.0/24 localgw=10.147.28.1
internaldns1=10.140.50.6
dns1=10.140.50.6,enableHA:false,limitCpuUse:false,enableDynamicallyScaleVm:false,vncPassword:vzcOWbWjEvLy75PCdH0IIg==,vncAddr:10.147.28.49,params:{},uuid:b43765e9-c099-45f9-9ceb-8d455f9bf2a7,disks:[{data:{org.apache.cloudstack.storage.to.VolumeObjectTO:{uuid:2c68fd25-7f69-4db6-b0d9-3e8072dea698,volumeType:ROOT,dataStore:{org.apache.cloudstack.storage.to.PrimaryDataStoreTO:{uuid:dfa2ec3c-d133-3284-8583-0a0845aa4424,id:1,poolType:NetworkFilesystem,host:10.147.28.7,path:/export/home/shweta/goleta.lxc.primary,port:2049,url:NetworkFilesystem://10.147.28.7/export/home/shweta/goleta.lxc.primary/?ROLE=PrimarySTOREUUID=dfa2ec3c-d133-3284-8583-0a0845aa4424}},name:ROOT-1,size:0,path:2c68fd25-7f69-4db6-b0d9-3e8072dea698,volumeId:1,vmName:v-1-VM,accountId:1,format:QCOW2,provisioningType:THIN,id:1,deviceId:0,hypervisorType:LXC}},diskSeq:0,path:2c68fd25-7f69-4db6-b0d9-3e8072dea698,type:ROOT,_details:{managed:false,storagePort:2049,storageHost:10.147.28.7,volumeSize:0}}],nics:[{deviceId:2,networkRateMbps:-1,defaultNic:true,pxeDisable:true,nicUuid:b1ca319a-0dbf-46c1-84db-f72b1bfa4aa0,uuid:30ffae39-67d2-47cf-afe7-48e7265dcdd6,ip:10.147.30.160,netmask:255.255.255.0,gateway:10.147.3
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7569) [LXC] NetworkManager service restarts when we reboot LXC agent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-7569. --- Resolution: Fixed [LXC] NetworkManager service restarts when we reboot LXC agent -- Key: CLOUDSTACK-7569 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7569 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Blocker Fix For: 4.5.0 Repro steps: Create a LXC zone. Once zone is up and enable Reboot LXC host Bug: Network manager service starts with reboot of LXC host. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7158) listCapacity API missing types for certain zones
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7158. -- Resolution: Fixed listCapacity API missing types for certain zones Key: CLOUDSTACK-7158 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7158 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 Issue listCapacity only shows type 2 6 when for certain zones. If zone id is specified all types are shown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7156) List templates API returns destroyed templates when recopying the template.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar updated CLOUDSTACK-7156: - Status: Open (was: Reviewable) The implementation has changed, This fix is not required in 4.5 List templates API returns destroyed templates when recopying the template. --- Key: CLOUDSTACK-7156 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7156 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 when we recopy a template multiple entries are created in the template_store_ref. As a result when we recopy a template and list the templates we might get a incorrect response which says the template download failed even thought it got copied successfully. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7155) Re-copying templates to other zones doesn't work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar resolved CLOUDSTACK-7155. -- Resolution: Fixed Re-copying templates to other zones doesn't work Key: CLOUDSTACK-7155 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7155 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 Steps to reproduce. 1. Create a new template. 2. Copy template to another zone. 3. Delete just created copy. 4. Reissue copy command DB record shows as removed in template_zone_ref table causing the deployment to fail in that zone. mysql select * from template_zone_ref where template_id=2755; -+ id zone_id template_id created last_updatedremoved -+ 4033 1 27552013-11-25 20:12:52 2013-11-25 20:12:52 NULL 4034 2 27552013-11-25 20:21:33 2013-11-25 20:24:04 2013-11-25 20:24:04 4046 6 27552013-11-26 20:08:18 2013-11-26 20:09:16 2013-11-26 20:09:16 -+ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7156) List templates API returns destroyed templates when recopying the template.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bharat Kumar closed CLOUDSTACK-7156. Resolution: Not a Problem List templates API returns destroyed templates when recopying the template. --- Key: CLOUDSTACK-7156 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7156 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 when we recopy a template multiple entries are created in the template_store_ref. As a result when we recopy a template and list the templates we might get a incorrect response which says the template download failed even thought it got copied successfully. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7571) changing value of cpu/mem.overprovisioning.factor for xen cluster is not affecting total memory at zone level
Bharat Kumar created CLOUDSTACK-7571: Summary: changing value of cpu/mem.overprovisioning.factor for xen cluster is not affecting total memory at zone level Key: CLOUDSTACK-7571 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7571 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 steps to reproduce == 1-prepare a CS3.6 setup with vmware and xen cluster 2-set mem.overprovisioning.factor=3 and cpu.overprovisioning.factor=2 2-upgrade it to CCP4.3 3-record total memory and cpu at zone level 4-change cpu/memory overprovisioning for xen server cluster to some valid value expected = at zone level total memory should get changed , depends on overprovisioning value Actual === 1-total memory is not getting changed at zone level 2-but total memory/cpu of xen cluster is getting changed with overprovisioning factor My observation == 1-if i change overspovisioning factor of vmware cluster total memory is getting changed 2-In fresh setup with one xen cluster i did not see this problem -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14137190#comment-14137190 ] ASF subversion and git services commented on CLOUDSTACK-7184: - Commit d0b39df1c38d33608628d650734410d8c72837e4 in cloudstack's branch refs/heads/hotfix/4.4/CLOUDSTACK-7184 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d0b39df ] CLOUDSTACK-7184 retry-wait loop config to deal with network glitches (cherry picked from commit b82f27be4150e70c017ed2597137319daa79560b) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down Key: CLOUDSTACK-7184 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server, XenServer Affects Versions: 4.3.0, 4.4.0, 4.5.0 Environment: CloudStack 4.3 with XenServer 6.2 hypervisors Reporter: Remi Bergsma Assignee: Daan Hoogland Priority: Blocker Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did discover this and marked the host as down, and immediately started HA. Just 18 seconds later the hypervisor returned and we ended up with 5 vm's that were running on two hypervisors at the same time. This, of course, resulted in file system corruption and the loss of the vm's. One side of the story is why XenServer allowed this to happen (will not bother you with this one). The CloudStack side of the story: HA should only start after at least xen.heartbeat.interval seconds. If the host is down long enough, the Xen heartbeat script will fence the hypervisor and prevent corruption. If it is not down long enough, nothing should happen. Logs (short): 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) . 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on the VMs . 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 505, name = mccpvmXX] cs marks host down: 2014-07-25 05:03:31,920 cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7565) [Automation] test_escalations_volumes test cases failing while attaching
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaurav Aradhye updated CLOUDSTACK-7565:
---
Status: Reviewable (was: In Progress)
[Automation] test_escalations_volumes test cases failing while attaching
-
Key: CLOUDSTACK-7565
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7565
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Environment: KVM
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Priority: Critical
Fix For: 4.5.0
Test case failing with QEMU error
Job failed: {jobprocstatus : 0, created : u'2014-09-13T22:11:54-0700',
jobresult : {errorcode : 530, errortext : u'Unexpected exception'}, cmd :
u'org.apache.cloudstack.api.command.user.volume.AttachVolumeCmd', userid :
u'40ce6901-3037-4a9b-9720-c3525af1971e', jobstatus : 2, jobid :
u'e6e007e0-4026-4476-ba21-86ba6da2fd46', jobresultcode : 530, jobinstanceid :
u'0f2ab3fb-977f-40ea-aa53-b95be017e38c', jobresulttype : u'object',
jobinstancetype : u'Volume', accountid :
u'db0c6f40-940e-43d4-bfb5-6afecbbe331d'}
begin captured stdout -
=== TestName: test_06_volume_snapshot_policy_hourly | Status : EXCEPTION ===
Test cases failing while attaching volume, error is from QEMU with duplicate
volume id, we cannot fix this issue in QEMU
I tested attach volume manually it works
there is a volume attach test case in BVT, it passes
We need to know why attach passing in BVT not in regrssion
we may need to update test case to work with KVM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7572) Virtual Console Proxy url domain
Martins Jakubovics created CLOUDSTACK-7572: -- Summary: Virtual Console Proxy url domain Key: CLOUDSTACK-7572 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7572 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VNC Proxy Affects Versions: 4.3.1 Environment: CentOS 6.5, CloudStack 4.3.1 from rhel packages. Reporter: Martins Jakubovics After CS upgrade from 4.3.0 or fresh install of 4.3.1, value consoleproxy.url.domain stopped to work. When launch console proxy, it connect to .realhostip.com domain in a way to connect real domain. When I clean this value, console proxy connects to IP. After entering any other value it connects to .realhostip.com anyway. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7376) passwd_server attempts to start but terminates with the exit code 137
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14137495#comment-14137495 ] ASF subversion and git services commented on CLOUDSTACK-7376: - Commit 29911dd2e1b650ed5b065448138f36744f4f7bc4 in cloudstack's branch refs/heads/master from [~bharat.kumar] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=29911dd ] CLOUDSTACK-7376 passwd_server attempts to start but terminates with the exit code 137 Signed-off-by: Sheng Yang sheng.y...@citrix.com passwd_server attempts to start but terminates with the exit code 137 - Key: CLOUDSTACK-7376 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7376 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Virtual Router Affects Versions: 4.5.0 Reporter: Bharat Kumar Assignee: Bharat Kumar Fix For: 4.5.0 Trying to add a non-contiguous IP range to an existing guest network, upon creation of an instance in the new range, the virtual router is updated with a new sub-interface but the passwd_server service (for serving passwords) is not running. If the script /opt/cloud/bin/passwd_server is run manually, then the service starts successfully and passwords can be served. If we reboot the virtual router via the CloudPlatform GUI, then it powers back up with the subinterface, but the passwd_server service is not running. Checking /var/log/cloud.log, the passwd_server attempts to start but terminates with the exit code 137, which from a quick google appears to be a SIGKILL termination. Steps to reproduce the issue i) Create a Shared Network in CCP and deploy a VM in the network. ii) Now add additional IP range to the same shared network. iii) Deploy a new VM in the additional IP range ( you can exhaust the first IP range to achieve this). iv) Once the new VM is deployed. Stop/start or restart the Router. The password server will fail to come up and following the entries in the logs In /var/log/cloud.log from VR /opt/cloud/bin/passwd_server_ip: line 32: 3161 Killed socat -lf /var/log/cloud.log TCP4-LISTEN:8080,reuseaddr,fork,crnl,bind=$addr SYSTEM:/opt/cloud/bin/serve_password.sh \\$SOCAT_PEERADDR\ Also, There is no issue in starting the service manually after ssh into the Router. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7567) Automate ACL test cases relating to depoying VM in shared network with different scopes - All/Domain/Domain with subdomain/Account for Admin, domain admin and regu
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14137645#comment-14137645 ] ASF subversion and git services commented on CLOUDSTACK-7567: - Commit d08adef264eb3e0cc5aae477a32efb043d0f3e7f in cloudstack's branch refs/heads/master from [~sangeethah] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d08adef ] CLOUDSTACK-7567 - Automate ACL test cases relating to depoying VM in shared network with different scopes - All/Domain/Domain with subdomain/Account for Admin, domain admin and regular users. Automate ACL test cases relating to depoying VM in shared network with different scopes - All/Domain/Domain with subdomain/Account for Admin, domain admin and regular users. - Key: CLOUDSTACK-7567 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7567 Project: CloudStack Issue Type: Task Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.4.0 Reporter: Sangeetha Hariharan Automate ACL test cases relating to depoying VM in shared network with different scopes - All/Domain/Domain with subdomain/Account for Admin, domain admin and regular users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7574) Fail to create Windows 2012r2 VM with OS type: Windows Server 2012 R2 (64-bit)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14137890#comment-14137890 ] Pierre-Luc Dion commented on CLOUDSTACK-7574: - similar past issues: * https://issues.apache.org/jira/browse/CLOUDSTACK-2354 * https://issues.apache.org/jira/browse/CLOUDSTACK-4055 Fail to create Windows 2012r2 VM with OS type: Windows Server 2012 R2 (64-bit) -- Key: CLOUDSTACK-7574 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7574 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: ISO, XenServer Affects Versions: 4.4.0, 4.4.1 Reporter: Pierre-Luc Dion Priority: Minor Cannot create Windows 2012r2 VM from an ISO with OS type: Windows Server 2012 R2 (64-bit), if the OS type is Windows Server 2012 (64-bit) The VM will succeed to create and boot from the iso. This as been reported by motty.c...@gmail.com. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7574) Fail to create Windows 2012r2 VM with OS type: Windows Server 2012 R2 (64-bit)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14137889#comment-14137889 ] Pierre-Luc Dion commented on CLOUDSTACK-7574: - I've tested this with 4.4.1-snapshot with XenServer 6.2 and got the same behavior. Fail to create Windows 2012r2 VM with OS type: Windows Server 2012 R2 (64-bit) -- Key: CLOUDSTACK-7574 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7574 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: ISO, XenServer Affects Versions: 4.4.0, 4.4.1 Reporter: Pierre-Luc Dion Priority: Minor Cannot create Windows 2012r2 VM from an ISO with OS type: Windows Server 2012 R2 (64-bit), if the OS type is Windows Server 2012 (64-bit) The VM will succeed to create and boot from the iso. This as been reported by motty.c...@gmail.com. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7474) Failed to start MS with java7 version mismatch error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan closed CLOUDSTACK-7474. --- Verified with latest build Failed to start MS with java7 version mismatch error Key: CLOUDSTACK-7474 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7474 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.5.0 Reporter: Rayees Namathponnan Assignee: Rayees Namathponnan Priority: Critical Fix For: 4.5.0 Steps to reproduce Step 1: Deploy new RHEL 6.3 machine Step 2 : Install MS Step 3: run deploy script and start MS Result Installation completed successfully, both java7 and java got installed as part of MS installation, but MS failed to start with below error SEVERE: Null component Catalina:type=JspMonitor,name=jsp,WebModule=//localhost/client,J2EEApplication=none,J2EEServer=none Sep 2, 2014 11:11:54 PM org.apache.catalina.startup.HostConfig deployDirectory SEVERE: Error deploying web application directory client java.lang.UnsupportedClassVersionError: org/apache/cloudstack/spring/module/web/CloudStackContextLoaderListener : Unsupported major.minor version 51.0 (unable to load class org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2335) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:976) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1451) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329) at org.apache.catalina.startup.WebAnnotationSet.loadClassAnnotation(WebAnnotationSet.java:145) at org.apache.catalina.startup.WebAnnotationSet.loadApplicationListenerAnnotations(WebAnnotationSet.java:73) at org.apache.catalina.startup.WebAnnotationSet.loadApplicationAnnotations(WebAnnotationSet.java:56) at org.apache.catalina.startup.ContextConfig.applicationAnnotationsConfig(ContextConfig.java:297) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1074) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:261) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4377) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) Default JAva version in this machcne is java6, while start MS, we need to pick java7 from /usr/lib/jvm/jre-1.7.0 or $JAVA_HOME We need to fix this in classpath.conf export CLASSPATH if [[ ! -d $JAVA_HOME -d /usr/lib/jvm/jre-1.7.0 ]]; then export JAVA_HOME=/usr/lib/jvm/jre-1.7.0 fi PATH=$JAVA_HOME/bin:/sbin:/usr/sbin:$PATH export PATH -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7352) [Automation] Test case test_01_list_vpncustomergateways_pagination trying to delete vpncustomergateways twice
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-7352.
---
Verified
[Automation] Test case test_01_list_vpncustomergateways_pagination trying to
delete vpncustomergateways twice
--
Key: CLOUDSTACK-7352
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7352
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Gaurav Aradhye
Fix For: 4.5.0
Test case
integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways.test_01_list_vpncustomergateways_pagination
fails with below error
{noformat}
xception: Job failed: {jobprocstatus : 0, created :
u'2014-08-14T16:40:08-0700', cmd :
u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd',
userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid :
u'cd8c0ebd-499d-404f-80a7-ae018e329e86', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : u'Fail to find customer
gateway with 3 !'}, accountid : u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}
test_01_list_vpncustomergateways_pagination
(integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways):
DEBUG: Response : FAILED
test_01_list_vpncustomergateways_pagination
(integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways):
ERROR: marvinRequest : CmdName:
marvin.cloudstackAPI.deleteVpnCustomerGateway.deleteVpnCustomerGatewayCmd
object at 0x1971b790 Exception: ['Traceback (most recent call last):\n', '
File /usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py,
line 374, in marvinRequest\nraise self.__lastError\n', Exception: Job
failed: {jobprocstatus : 0, created : u'2014-08-14T16:40:08-0700', cmd :
u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd',
userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid :
u'cd8c0ebd-499d-404f-80a7-ae018e329e86', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : u'Fail to find customer
gateway with 3 !'}, accountid : u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}\n]
Traceback (most recent call last):
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line
374, in marvinRequest
raise self.__lastError
Exception: Job failed: {jobprocstatus : 0, created :
u'2014-08-14T16:40:08-0700', cmd :
u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd',
userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid :
u'cd8c0ebd-499d-404f-80a7-ae018e329e86', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : u'Fail to find customer
gateway with 3 !'}, accountid : u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}
test_01_list_vpncustomergateways_pagination
(integration.component.test_escalations_vpncustomergateways.TestVpnCustomerGateways):
CRITICAL: EXCEPTION: test_01_list_vpncustomergateways_pagination:
['Traceback (most recent call last):\n', ' File
/usr/local/lib/python2.7/unittest/case.py, line 345, in run\n
self.tearDown()\n', ' File
/Repo_30X/ipcl/cloudstack/test/integration/component/test_escalations_vpncustomergateways.py,
line 94, in tearDown\ncleanup_resources(self.apiClient,
self.cleanup)\n', ' File
/usr/local/lib/python2.7/site-packages/marvin/lib/utils.py, line 121, in
cleanup_resources\nobj.delete(api_client)\n', ' File
/usr/local/lib/python2.7/site-packages/marvin/lib/base.py, line 3418, in
delete\napiclient.deleteVpnCustomerGateway(cmd)\n', ' File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 2333, in deleteVpnCustomerGateway\nresponse =
self.connection.marvinRequest(command, response_type=response,
method=method)\n', ' File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line
379, in marvinRequest\nraise e\n', Exception: Job failed: {jobprocstatus
: 0, created : u'2014-08-14T16:40:08-0700', cmd :
u'org.apache.cloudstack.api.command.user.vpn.DeleteVpnCustomerGatewayCmd',
userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 2, jobid :
u'cd8c0ebd-499d-404f-80a7-ae018e329e86', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : u'Fail to find customer
gateway with 3 !'}, accountid : u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}\n]
- end captured logging
[jira] [Closed] (CLOUDSTACK-7353) [Automation] Test case test_09_project_suspend, trying list VM under project after deleting this
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-7353.
---
Verified with latest run
[Automation] Test case test_09_project_suspend, trying list VM under project
after deleting this
-
Key: CLOUDSTACK-7353
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7353
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Girish Shilamkar
Fix For: 4.5.0
Run the test
integration.component.test_projects.TestProjectSuspendActivate.test_09_project_suspend
This test case fails with below error
{noformat}
est_09_project_suspend
(integration.component.test_projects.TestProjectSuspendActivate): DEBUG:
===Jobid:0655909d-4dbc-4bab-aabb-ccd532ff7435 ; StartTime:Thu Aug 14 13:26:44
2014 ; EndTime:Thu Aug 14 13:26:54 2014 ; TotalTime:-10===
test_09_project_suspend
(integration.component.test_projects.TestProjectSuspendActivate): DEBUG:
Response : {jobprocstatus : 0, created : u'2014-08-14T17:13:43-0700',
jobresult : {affinitygroup : [], nic : [], securitygroup : [], tags : []},
cmd : u'org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin',
userid : u'db822ed4-23f9-11e4-9ac6-1a6f7bb0d0a8', jobstatus : 1, jobid :
u'0655909d-4dbc-4bab-aabb-ccd532ff7435', jobresultcode : 0, jobinstanceid :
u'2def69e5-cb26-4506-8069-3237f049498b', jobresulttype : u'object',
jobinstancetype : u'VirtualMachine', accountid :
u'db8223a8-23f9-11e4-9ac6-1a6f7bb0d0a8'}
test_09_project_suspend
(integration.component.test_projects.TestProjectSuspendActivate): DEBUG:
Destroying VM: 2def69e5-cb26-4506-8069-3237f049498b
test_09_project_suspend
(integration.component.test_projects.TestProjectSuspendActivate): DEBUG:
Payload: {'apiKey':
u'uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zoTzASxzSN0OSUnfoQ',
'projectid': u'463389ae-64fc-42b4-a555-a15dbbe455e4', 'response': 'json',
'listall': True, 'command': 'listVirtualMachines', 'signature':
'mzQe0vheGxDPynM+QkNzOJv12d8='}
test_09_project_suspend
(integration.component.test_projects.TestProjectSuspendActivate): DEBUG:
Sending GET Cmd : listVirtualMachines===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 10.223.49.195
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zoTzASxzSN0OSUnfoQprojectid=463389ae-64fc-42b4-a555-a15dbbe455e4command=listVirtualMachinessignature=mzQe0vheGxDPynM%2BQkNzOJv12d8%3Dresponse=jsonlistall=True
HTTP/1.1 200 39
test_09_project_suspend
(integration.component.test_projects.TestProjectSuspendActivate): DEBUG:
Response : None
test_09_project_suspend
(integration.component.test_projects.TestProjectSuspendActivate): CRITICAL:
FAILED: test_09_project_suspend: ['Traceback (most recent call last):\n', '
File /usr/local/lib/python2.7/unittest/case.py, line 318, in run\n
testMethod()\n', ' File
/Repo_30X/ipcl/cloudstack/test/integration/component/test_projects.py, line
1625, in test_09_project_suspend\nCheck for a valid list accounts
response\n', ' File /usr/local/lib/python2.7/unittest/case.py, line 494,
in assertEqual\nassertion_func(first, second, msg=msg)\n', ' File
/usr/local/lib/python2.7/unittest/case.py, line 487, in _baseAssertEqual\n
raise self.failureException(msg)\n', 'AssertionError: Check for a valid
list accounts response\n']
- end captured logging -
Stacktrace
File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
testMethod()
File
/Repo_30X/ipcl/cloudstack/test/integration/component/test_projects.py, line
1625, in test_09_project_suspend
Check for a valid list accounts response
File /usr/local/lib/python2.7/unittest/case.py, line 494, in assertEqual
assertion_func(first, second, msg=msg)
File /usr/local/lib/python2.7/unittest/case.py, line 487, in
_baseAssertEqual
raise self.failureException(msg)
'Check for a valid list accounts response\n begin
captured stdout -\n=== TestName:
test_09_project_suspend | Status : FAILED ===\n\n\n-
end captured stdout --\n begin
captured logging
\ntest_08_cleanup_after_project_delete (int
{noformat}
Test case trying to list the VMs under project, after deleting the VM
{noformat}
1612 # Destroy Stopped VM
1613
[jira] [Commented] (CLOUDSTACK-7573) [Automation] Deployment of VM from ISO fails - due to Guest OS Type Issue
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14138132#comment-14138132
]
ASF subversion and git services commented on CLOUDSTACK-7573:
-
Commit f1f61e13e5322c2b17b227e9084c3bb25b499d1e in cloudstack's branch
refs/heads/master from [~chandanp]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f1f61e1 ]
CLOUDSTACK-7573 : Fixed the Guest OS Type used for the ISO
[Automation] Deployment of VM from ISO fails - due to Guest OS Type Issue
-
Key: CLOUDSTACK-7573
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7573
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Chandan Purushothama
Priority: Critical
Fix For: 4.5.0
The ISO Used in the test has been marked as CentOS 5.6 64-bit Guest OS. Since
the actual OS is not CentOS, it results in a failure
==
Error Information:
==
2014-07-11 17:16:39,475 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-253:ctx-b52ea3a8) Task failed! Task record: uuid:
83651aa2-4780-7aa5-7199-b03fbc95afa8
nameLabel: Async.VM.start_on
nameDescription:
allowedOperations: []
currentOperations: {}
created: Fri Jul 11 17:16:36 UTC 2014
finished: Fri Jul 11 17:16:39 UTC 2014
status: failure
residentOn: com.xensource.xenapi.Host@4a66a351
progress: 1.0
type: none/
result:
errorInfo: [BOOTLOADER_FAILED,
OpaqueRef:4bfa19dd-4b8f-1e63-7a09-67cd6a1caa49, INVALID_SOURCE
Unable to access a required file in the specified repository:
file:///tmp/cdrom-repo-LE7BgU/isolinux/vmlinuz.
]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
2014-07-11 17:16:39,514 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-253:ctx-b52ea3a8) Unable to start VM(i-159-108-VM) on
host(6788e9f2-76d1-4fa0-880b-76a06cb41bbe) due to Task failed! Task record:
uuid: 83651aa2-4780-7aa5-7199-b03fbc95afa8
nameLabel: Async.VM.start_on
nameDescription:
allowedOperations: []
currentOperations: {}
created: Fri Jul 11 17:16:36 UTC 2014
finished: Fri Jul 11 17:16:39 UTC 2014
status: failure
residentOn: com.xensource.xenapi.Host@4a66a351
progress: 1.0
type: none/
result:
errorInfo: [BOOTLOADER_FAILED,
OpaqueRef:4bfa19dd-4b8f-1e63-7a09-67cd6a1caa49, INVALID_SOURCE
Unable to access a required file in the specified repository:
file:///tmp/cdrom-repo-LE7BgU/isolinux/vmlinuz.
]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
Task failed! Task record: uuid: 83651aa2-4780-7aa5-7199-b03fbc95afa8
nameLabel: Async.VM.start_on
nameDescription:
allowedOperations: []
currentOperations: {}
created: Fri Jul 11 17:16:36 UTC 2014
finished: Fri Jul 11 17:16:39 UTC 2014
status: failure
residentOn: com.xensource.xenapi.Host@4a66a351
progress: 1.0
type: none/
result:
errorInfo: [BOOTLOADER_FAILED,
OpaqueRef:4bfa19dd-4b8f-1e63-7a09-67cd6a1caa49, INVALID_SOURCE
Unable to access a required file in the specified repository:
file:///tmp/cdrom-repo-LE7BgU/isolinux/vmlinuz.
]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
at
com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.checkForSuccess(CitrixResourceBase.java:3313)
at
com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.startVM(CitrixResourceBase.java:3425)
at
com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1752)
at
com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:502)
at
com.cloud.hypervisor.xenserver.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61)
at
com.cloud.hypervisor.xenserver.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:93)
at
com.cloud.hypervisor.xenserver.resource.XenServer620SP1Resource.executeRequest(XenServer620SP1Resource.java:64)
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
[jira] [Assigned] (CLOUDSTACK-7570) min and max iops are being processed null while creating a vm using third party storage plugins
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] punith reassigned CLOUDSTACK-7570: -- Assignee: punith min and max iops are being processed null while creating a vm using third party storage plugins --- Key: CLOUDSTACK-7570 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7570 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: punith Assignee: punith Fix For: 4.5.0 this bug will occur only in the following scenario 1 create a compute offering with custom mode but not custom IOPS 2 input the required min and max IOPS 3 now create a VM based on the created compute offering issue: ServiceOfferingVO dummyoffering = new ServiceOfferingVO(serviceOffering); this constructor is not setting the min and max IOPS for the dummyoffering fix: adding the min and max iops to the following constructor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
