[jira] [Assigned] (CLOUDSTACK-5036) [Automation] VPC test cases failing with ssh connection error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar reassigned CLOUDSTACK-5036: Assignee: Girish Shilamkar > [Automation] VPC test cases failing with ssh connection error > - > > Key: CLOUDSTACK-5036 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5036 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.2.1 > Environment: Automation KVM >Reporter: Rayees Namathponnan >Assignee: Girish Shilamkar > Fix For: 4.2.1 > > > VPC test cases failing inconsistently from different suite, with ssh > connection error > Observed below error from diffrent suites > 1) > integration.component.test_vpc_vms_deployment.TestVMDeployVPC.test_07_delete_network_with_rules > Stacktrace > File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run > testMethod() > File > "/Repo_30X/ipcl/cloudstack/test/integration/component/test_vpc_vms_deployment.py", > line 2251, in test_07_delete_network_with_rules > (public_ip_1.ipaddress.ipaddress, e)) > File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail > raise self.failureException(msg) > Failed to SSH into VM - 10.223.122.79, Failed to bring up ssh service in > time. Waited 300s. Error is error(113, 'No route to host') > 2) > integration.component.test_vpc_vm_life_cycle.TestVMLifeCycleSharedNwVPC.test_01_deploy_instance_in_network > Stacktrace > File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run > testMethod() > File > "/Repo_30X/ipcl/cloudstack/test/integration/component/test_vpc_vm_life_cycle.py", > line 1246, in test_01_deploy_instance_in_network > self.validate_network_rules() > File > "/Repo_30X/ipcl/cloudstack/test/integration/component/test_vpc_vm_life_cycle.py", > line 1211, in validate_network_rules > (self.public_ip_1.ipaddress.ipaddress, e)) > File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail > raise self.failureException(msg) > Failed to SSH into VM - 10.223.122.117, Ping to VM gateway should be > successful > >> begin captured logging << -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5851) add a nic to vm failed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] zhenglei updated CLOUDSTACK-5851: - Description: 1. Create a vm successfully in an advanced zone. 2. Create a network with the default networkoffering successfully. There is no vm in the network now, and also the vrouter is not started. 3. Add the network to the vm by calling the restful api successfully. 4. But when I login the cloudstack ui, I find the new network vrouter is not started and its status is ”starting“. so add nic operation is failed. 5. I want to check the vrouter by xencenter, but there is no this vrouter. 6. At last, i check the management server log files, There is no any ERROR and Exception. I think the reason is the vrouter is not started, But i don't know why. I also do some add nic or remove nic tests when a vrouer is running, and it is normal. so, why?Thanks... was: 1. Create a vm successfully in an advanced zone. 2. Create a network with the default networkoffering successfully. There is no vm in the network now, and also the vrouter is not started. 3. Add the network to the vm by calling the restful api successfully. 4. But when I login the cloudstack ui, I find the new network vrouter is not started and its status is ”starting“. so add nic operation is failed. 5. I want to check the vrouter by xencenter, but there is no this vrouter. 6. At last, i check the management server log files, There is no any ERROR and Exception. I think the reason is the vrouter is not started, But i don't why. I also do some add nic or remove nic tests when a vrouer is running, and it is normal. so, why?Thanks... > add a nic to vm failed > -- > > Key: CLOUDSTACK-5851 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5851 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.1.0 > Environment: cloudstack4.1.0 and xenserver6.0 >Reporter: zhenglei > > 1. Create a vm successfully in an advanced zone. > 2. Create a network with the default networkoffering successfully. There is > no vm in the network now, and also the vrouter is not started. > 3. Add the network to the vm by calling the restful api successfully. > 4. But when I login the cloudstack ui, I find the new network vrouter is not > started and its status is ”starting“. so add nic operation is failed. > 5. I want to check the vrouter by xencenter, but there is no this vrouter. > 6. At last, i check the management server log files, There is no any ERROR > and Exception. > I think the reason is the vrouter is not started, But i don't know why. I > also do some add nic or remove nic tests when a vrouer is running, and it is > normal. > so, why?Thanks... > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5804) [Automation] Warning! Cleanup failed: 'TestEgressFWRules' object has no attribute 'virtual_machine'
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar resolved CLOUDSTACK-5804. -- Resolution: Duplicate > [Automation] Warning! Cleanup failed: 'TestEgressFWRules' object has no > attribute 'virtual_machine' > --- > > Key: CLOUDSTACK-5804 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5804 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Test >Affects Versions: 4.3.0 >Reporter: Srikanteswararao Talluri > Fix For: 4.3.0 > > > test_12_egress_fr12 FAILED Warning! Cleanup failed: 'TestEgressFWRules' > object has no attribute 'virtual_machine' > test_13_1_egress_fr13 FAILED Warning! Cleanup failed: 'TestEgressFWRules' > object has no attribute 'virtual_machine' > test_13_egress_fr13 FAILED Warning! Cleanup failed: 'TestEgressFWRules' > object has no attribute 'virtual_machine' > Warning! Cleanup failed: 'TestEgressFWRules' object has no attribute > 'virtual_machine' -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-4340) [Automation] Test cases TestVMLifeCycleStoppedVPCVR.test_07_migrate_instance_in_network failed during migration
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Girish Shilamkar resolved CLOUDSTACK-4340.
--
Resolution: Fixed
> [Automation] Test cases
> TestVMLifeCycleStoppedVPCVR.test_07_migrate_instance_in_network failed during
> migration
> ---
>
> Key: CLOUDSTACK-4340
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4340
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API, Automation
>Affects Versions: 4.2.0
> Environment: Automation
> 4.2
>Reporter: Rayees Namathponnan
>Assignee: Rayees Namathponnan
> Fix For: 4.3.0
>
> Attachments: management-server.rar
>
>
> Test cases
> integration.component.test_vpc_vm_life_cycle.TestVMLifeCycleStoppedVPCVR.test_07_migrate_instance_in_network
> failed with latest build, failed during migration;
> observed below error in automation log
> --
> Failed to migrate instance, Execute cmd: asyncquery failed, due to:
> {errorcode : 530, errortext : u'Cannot migrate VM, VM is already presnt on
> this host, please specify valid destination host to migrate the VM'}
> >> begin captured logging <<
> testclient.testcase.TestVMLifeCycleStoppedVPCVR: DEBUG: Check the status of
> VPC virtual router
> testclient.testcase.TestVMLifeCycleStoppedVPCVR: DEBUG: Checking if the host
> is available for migration?
> testclient.testcase.TestVMLifeCycleStoppedVPCVR: DEBUG: Validating if the
> network rules work properly or not?
> testclient.testcase.TestVMLifeCycleStoppedVPCVR: DEBUG: Checking if we can
> SSH into VM_1 through 10.223.122.78?
> paramiko.transport: DEBUG: starting thread (client mode): 0xad8f910L
> paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_4.3)
> paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha1',
> 'diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server
> key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-cbc', '3des-cbc',
> 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour',
> 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr',
> 'aes192-ctr', 'aes256-ctr'] server encrypt:['aes128-cbc', '3des-cbc',
> 'blowfish-cbc', 'cast128-cbc', 'arcfour128', 'arcfour256', 'arcfour',
> 'aes192-cbc', 'aes256-cbc', 'rijndael-...@lysator.liu.se', 'aes128-ctr',
> 'aes192-ctr', 'aes256-ctr'] client mac:['hmac-md5', 'hmac-sha1',
> 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96',
> 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160',
> 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client
> compress:['none', 'z...@openssh.com'] server compress:['none',
> 'z...@openssh.com'] client lang:[''] server lang:[''] kex follows?False
> paramiko.transport: DEBUG: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr
> paramiko.transport: DEBUG: using kex diffie-hellman-group1-sha1; server key
> type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local
> hmac-sha1, remote hmac-sha1; compression: local none, remote none
> paramiko.transport: DEBUG: Switch to new keys ...
> paramiko.transport: DEBUG: Adding ssh-rsa host key for 10.223.122.78:
> 0f8b3ff9dc4dce10340227dab3cac032
> paramiko.transport: DEBUG: Trying discovered key
> 76be480fa6b8ad3b78082d6d19e4ee44 in /root/.ssh/id_rsa
> paramiko.transport: DEBUG: userauth is OK
> paramiko.transport: INFO: Authentication (publickey) failed.
> paramiko.transport: DEBUG: userauth is OK
> paramiko.transport: INFO: Authentication (password) successful!
> sshClient: DEBUG: SSH connect: root@10.223.122.78 with passwd password
> paramiko.transport: DEBUG: EOF in transport thread
> testclient.testcase.TestVMLifeCycleStoppedVPCVR: DEBUG: SSH into VM is
> successfully
> testclient.testcase.TestVMLifeCycleStoppedVPCVR: DEBUG: Verifying if we can
> ping to outside world from VM?
> paramiko.transport: DEBUG: [chan 1] Max packet in: 34816 bytes
> paramiko.transport: DEBUG: [chan 1] Max packet out: 32768 bytes
> paramiko.transport: INFO: Secsh channel 1 opened.
> paramiko.transport: DEBUG: [chan 1] Sesch channel 1 request ok
> paramiko.transport: DEBUG: [chan 1] EOF received (1)
> sshClient: DEBUG: {Cmd: ping -c 1 www.google.com via Host: 10.223.122.78}
> {returns: ['PING www.google.com (74.125.239.145) 56(84) bytes of data.', '64
> bytes from nuq05s02-in-f17.1e100.net (74.125.239.145): icmp_seq=1 ttl=48
> time=5.49 ms', '', '--- www.google.com ping statistics ---', '1 packets
> transmitted, 1 received, 0% packet loss, time 0ms', 'rtt min/avg/max/mdev =
> 5.497/
[jira] [Updated] (CLOUDSTACK-5734) Console not working for SSVM CPVM VR guest VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla updated CLOUDSTACK-5734: Attachment: Bug_5734.png Image depicting console access with QA provided setup information. > Console not working for SSVM CPVM VR guest VMs > -- > > Key: CLOUDSTACK-5734 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5734 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: MS4.3 release 1/2/14 > vcenter 5.5 host1 ESXi 5.5 host2 ESXi 5.5 >Reporter: angeline shen >Assignee: Santhosh Kumar Edukulla >Priority: Blocker > Fix For: 4.3.0 > > Attachments: Bug_5734.png, CLOUDSTACK-5734.png, > management-server(1).log.gz, vm43.png > > > 1. advance zone. Create VPC, VPC network, create VMs > 2. create windows 2008R2 iso -based VM > 3. Open console to SSVM CPVMVRguest VMs - blank -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5734) Console not working for SSVM CPVM VR guest VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867573#comment-13867573 ] Santhosh Kumar Edukulla commented on CLOUDSTACK-5734: - Team, 1. We mentioned it is reproducible with below setup. So, I just tried using the below mentioned setup now and attached is the snapshot depicting console proxy access. Am i missing anything here? Attached is the snapshot for the same. http://10.147.38.149:8080/client/ 2. If it is reproducible, please add as well steps using the below mentioned setup to reproduce if any for specific machine? 3. Also, please dont mix two bugs EX: 5764 and 5734( the current one ). We could see exception traces are copied to both bugs. Here, it was mentioned to be a blocker where no console access is working, there in 5764 we mentioned exception is logged. 4. Also, the bug flow is not clear. We mentioned initially that it is reproducible with all hypervisors, then we mentioned kvm and then we say only with rpms builds. Please mention a particular setup and flow. We marked this as blocker. Iam not able to reproduce the same. Marking this bug as resolved. Regards Santhosh ___ > Console not working for SSVM CPVM VR guest VMs > -- > > Key: CLOUDSTACK-5734 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5734 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: MS4.3 release 1/2/14 > vcenter 5.5 host1 ESXi 5.5 host2 ESXi 5.5 >Reporter: angeline shen >Assignee: Santhosh Kumar Edukulla >Priority: Blocker > Fix For: 4.3.0 > > Attachments: Bug_5734.png, CLOUDSTACK-5734.png, > management-server(1).log.gz, vm43.png > > > 1. advance zone. Create VPC, VPC network, create VMs > 2. create windows 2008R2 iso -based VM > 3. Open console to SSVM CPVMVRguest VMs - blank -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5734) Console not working for SSVM CPVM VR guest VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Santhosh Kumar Edukulla resolved CLOUDSTACK-5734. - Resolution: Cannot Reproduce Not Reproducible. > Console not working for SSVM CPVM VR guest VMs > -- > > Key: CLOUDSTACK-5734 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5734 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: MS4.3 release 1/2/14 > vcenter 5.5 host1 ESXi 5.5 host2 ESXi 5.5 >Reporter: angeline shen >Assignee: Santhosh Kumar Edukulla >Priority: Blocker > Fix For: 4.3.0 > > Attachments: Bug_5734.png, CLOUDSTACK-5734.png, > management-server(1).log.gz, vm43.png > > > 1. advance zone. Create VPC, VPC network, create VMs > 2. create windows 2008R2 iso -based VM > 3. Open console to SSVM CPVMVRguest VMs - blank -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-4810) Enable hypervisor snapshots for CloudStack-managed storage (for XenServer and VMware)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867563#comment-13867563 ] ASF subversion and git services commented on CLOUDSTACK-4810: - Commit 68fda5a8ddaa7817277ac740b1e4b6986dc710a8 in branch refs/heads/master from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=68fda5a ] Merge from 4.3: CLOUDSTACK-4810: Enable hypervisor snapshots for CloudStack-managed storage (for XenServer and VMware) > Enable hypervisor snapshots for CloudStack-managed storage (for XenServer and > VMware) > - > > Key: CLOUDSTACK-4810 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4810 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 > Environment: Ubuntu 12.04 >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.3.0 > > > CloudStack-managed storage was introduced into CloudStack with the new > storage framework in 4.2. > This allows CloudStack to create and delete storage repositories and > datastores as needed. > For 4.2 the VDI inside of an SR takes up almost as much space as is available > in the SR (so there is a one-to-one mapping between an SR and a VDI). This is > the same idea for datastores and VMDKs. > The SR or datastore should be sized larger than its VDI or VMDK so there is > space available for hypervisor snapshots that get stored on the same SR or > datastore. > How much larger can be determined by a cluster-level setting. > For example, if you want a 10 GB CloudStack volume, the storage plug-in in > question can create, say, a 20 GB volume on its SAN. 10 GB to be used for the > CloudStack volume and an additional 10 GB for hypervisor snapshots. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5716) [Hyper-v] Can't type Special character in console view
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjeev N closed CLOUDSTACK-5716.
-
Verified on latest 4.3 build. Works fine.
> [Hyper-v] Can't type Special character in console view
> --
>
> Key: CLOUDSTACK-5716
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5716
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Hypervisor Controller
>Affects Versions: 4.3.0
> Environment: Latest build from 4.3 branch with
> commit:95b6a7b96dab1c77e25987d6fe6003b4447281f1
>Reporter: Sanjeev N
>Assignee: Anshul Gangwar
>Priority: Critical
> Labels: hyper-V,, hyper-v, hyperv
> Fix For: 4.3.0
>
>
> [Hyper-v] Can't type Special character in console view
> Steps to Reproduce:
>
> 1.Bring up CS with Hyperv cluster
> 2.Wait for the CPVM to come up
> 3.Deploy guest vm with default cent os template
> 4.Try accessing the system/guest vms console from CS
> 5.Login and try to type special characters
> Result:
> =
> Can't type the special characters(Shift+(1-9,0)) and also other characters
> like below:
> ~
> `
> {
> }
> |
> <
> >
> ?
> :
> "
> +
> _
> -
> =
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5843) registering templates/isos should be either async or changed to non-blocking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867554#comment-13867554 ] Marcus Sorensen commented on CLOUDSTACK-5843: - We probably want to create a new async command and wrap the existing sync call in it, to maintain api compatibility until we move to the next major version. > registering templates/isos should be either async or changed to non-blocking > > > Key: CLOUDSTACK-5843 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5843 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0, 4.3.0, 4.4.0 >Reporter: Marcus Sorensen > Fix For: 4.4.0 > > > The call to register templates and isos does more than most sync calls do, it > seems to talk to the ssvm and have it run commands that can potentially time > out. I ran into this in a test system when we tried to register a template > with a non-routable URL. The cloudstack API call just hung. I realize that > there was a problem (ssvm could not reach the template host), but no sync > call should do anything like this that would block. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5492) Group by options in router pages always shows requiresupgrade as no
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal updated CLOUDSTACK-5492:
---
Attachment: upg.png
> Group by options in router pages always shows requiresupgrade as no
> ---
>
> Key: CLOUDSTACK-5492
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5492
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.3.0
> Environment: on 4.3. upgraded setup in which router is not yet
> upgraded
> goto router page via infrastructure
> Select option group by zone/pod/cluster
> Notice Requires upgrade is shown as No
> API call
> http://10.147.40.27:8080/client/api?command=listRouters&response=json&sessionkey=lDWk06sWJovcFLDuw3MHaS00N4Q%3D&podid=a5d5234e-86d6-41f8-ac8c-5bdf24288231&listAll=true&page=1&pagesize=20&_=1386935114493
> Response returns requires upgrade field as true
> { "listroutersresponse" : { "count":9 ,"router" : [
> {"id":"3d05883f-3089-449a-84a2-bb7d758f1e82","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","gateway":"10.147.51.1","name":"r-19-VM","podid":"a5d5234e-86d6-41f8-ac8c-5bdf24288231","hostid":"90ac48de-eb48-4283-b2f9-1a6581a92fb6","hostname":"Rack1Pod1Host24","linklocalip":"169.254.1.123","linklocalmacaddress":"0e:00:a9:fe:01:7b","linklocalnetmask":"255.255.0.0","linklocalnetworkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","publicip":"10.147.51.21","publicmacaddress":"06:bd:38:00:00:20","publicnetmask":"255.255.255.0","publicnetworkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","templateid":"ce21f5d6-630f-11e3-9a2f-97407caff5c2","created":"2013-12-12T17:56:08+0530","state":"Running","account":"admin","domainid":"94814869-1330-42b9-8e74-77a407a3cd7e","domain":"child1","serviceofferingid":"72743e39-323d-4aba-9076-6c43b72252c1","serviceofferingname":"System
> Offering For Software
> Router","isredundantrouter":false,"redundantstate":"UNKNOWN","version":"3.0","vpcid":"07fcf168-3086-40c0-bd9b-eddb70396aaa","role":"VIRTUAL_ROUTER","nic":[{"id":"87f6bfb3-f993-4cc6-8332-4b25efd298a3","networkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","netmask":"255.255.0.0","gateway":"169.254.0.1","ipaddress":"169.254.1.123","traffictype":"Control","isdefault":false,"macaddress":"0e:00:a9:fe:01:7b"},{"id":"8066d1e0-ee16-4ade-898e-3a232efb8345","networkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","netmask":"255.255.255.0","gateway":"10.147.51.1","ipaddress":"10.147.51.21","isolationuri":"vlan://51","broadcasturi":"vlan://51","traffictype":"Public","isdefault":true,"macaddress":"06:bd:38:00:00:20"}],"requiresupgrade":true},
>
> {"id":"70c807c7-679c-41b0-8c93-a38a54d3a47c","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","networkdomain":"cs8cloud.internal","gateway":"10.147.51.1","name":"r-18-VM","podid":"a5d5234e-86d6-41f8-ac8c-5bdf24288231","linklocalnetworkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","publicip":"10.147.51.20","publicmacaddress":"06:bc:86:00:00:1f","publicnetmask":"255.255.255.0","publicnetworkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","guestipaddress":"10.1.1.1","guestmacaddress":"02:00:20:79:00:02","guestnetmask":"255.255.255.0","guestnetworkid":"29a643b3-cabb-4855-a967-38853c150f73","templateid":"ce21f5d6-630f-11e3-9a2f-97407caff5c2","created":"2013-12-12T17:55:43+0530","state":"Stopped","account":"admin","domainid":"94814869-1330-42b9-8e74-77a407a3cd7e","domain":"child1","serviceofferingid":"72743e39-323d-4aba-9076-6c43b72252c1","serviceofferingname":"System
> Offering For Software
> Router","isredundantrouter":false,"redundantstate":"UNKNOWN","version":"3.0","role":"VIRTUAL_ROUTER","nic":[{"id":"5d3917d6-7022-446e-981c-04b88307151f","networkid":"29a643b3-cabb-4855-a967-38853c150f73","networkname":"admin2","netmask":"255.255.255.0","ipaddress":"10.1.1.1","traffictype":"Guest","type":"Isolated","isdefault":false,"macaddress":"02:00:20:79:00:02"},{"id":"42a50f06-4e66-41cc-8c4a-1b76afd893f1","networkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","traffictype":"Control","isdefault":false},{"id":"d7fda58e-ff9e-4427-99d9-aca3d1d0bc49","networkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","netmask":"255.255.255.0","gateway":"10.147.51.1","ipaddress":"10.147.51.20","isolationuri":"vlan://51","broadcasturi":"vlan://51","traffictype":"Public","isdefault":true,"macaddress":"06:bc:86:00:00:1f"}],"requiresupgrade":true},
>
> {"id":"27e5c26c-5101-4b13-b8c0-666e7f0adf72","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","gateway":"10.147.51.1","name":"r-16-VM","podid":"a5d5234e-86d6-41f8-ac8c-5bdf24288231","hostid":"90ac48de-eb48-4283-b2f9-1a6581a92fb6","hostname":"Rack1Pod1Host24","linklocalip":"169.254.2.220","link
[jira] [Commented] (CLOUDSTACK-5843) registering templates/isos should be either async or changed to non-blocking
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867553#comment-13867553 ] Marcus Sorensen commented on CLOUDSTACK-5843: - Looking at the code, it looks like it sends a command to the secondary storage vm agent, which does a bunch of things (creates directory on the nfs secondary storage to store the template, interrogates the remote url for things like download size, etc) before jumping into a thread to do the download and returning the sync command. It seems like this should be made async, and that's probably easier rather than trying to keep it from doing those things before returning. > registering templates/isos should be either async or changed to non-blocking > > > Key: CLOUDSTACK-5843 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5843 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0, 4.3.0, 4.4.0 >Reporter: Marcus Sorensen > Fix For: 4.4.0 > > > The call to register templates and isos does more than most sync calls do, it > seems to talk to the ssvm and have it run commands that can potentially time > out. I ran into this in a test system when we tried to register a template > with a non-routable URL. The cloudstack API call just hung. I realize that > there was a problem (ssvm could not reach the template host), but no sync > call should do anything like this that would block. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5492) Group by options in router pages always shows requiresupgrade as no
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal updated CLOUDSTACK-5492:
---
Attachment: cloud.sql
> Group by options in router pages always shows requiresupgrade as no
> ---
>
> Key: CLOUDSTACK-5492
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5492
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.3.0
> Environment: on 4.3. upgraded setup in which router is not yet
> upgraded
> goto router page via infrastructure
> Select option group by zone/pod/cluster
> Notice Requires upgrade is shown as No
> API call
> http://10.147.40.27:8080/client/api?command=listRouters&response=json&sessionkey=lDWk06sWJovcFLDuw3MHaS00N4Q%3D&podid=a5d5234e-86d6-41f8-ac8c-5bdf24288231&listAll=true&page=1&pagesize=20&_=1386935114493
> Response returns requires upgrade field as true
> { "listroutersresponse" : { "count":9 ,"router" : [
> {"id":"3d05883f-3089-449a-84a2-bb7d758f1e82","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","gateway":"10.147.51.1","name":"r-19-VM","podid":"a5d5234e-86d6-41f8-ac8c-5bdf24288231","hostid":"90ac48de-eb48-4283-b2f9-1a6581a92fb6","hostname":"Rack1Pod1Host24","linklocalip":"169.254.1.123","linklocalmacaddress":"0e:00:a9:fe:01:7b","linklocalnetmask":"255.255.0.0","linklocalnetworkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","publicip":"10.147.51.21","publicmacaddress":"06:bd:38:00:00:20","publicnetmask":"255.255.255.0","publicnetworkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","templateid":"ce21f5d6-630f-11e3-9a2f-97407caff5c2","created":"2013-12-12T17:56:08+0530","state":"Running","account":"admin","domainid":"94814869-1330-42b9-8e74-77a407a3cd7e","domain":"child1","serviceofferingid":"72743e39-323d-4aba-9076-6c43b72252c1","serviceofferingname":"System
> Offering For Software
> Router","isredundantrouter":false,"redundantstate":"UNKNOWN","version":"3.0","vpcid":"07fcf168-3086-40c0-bd9b-eddb70396aaa","role":"VIRTUAL_ROUTER","nic":[{"id":"87f6bfb3-f993-4cc6-8332-4b25efd298a3","networkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","netmask":"255.255.0.0","gateway":"169.254.0.1","ipaddress":"169.254.1.123","traffictype":"Control","isdefault":false,"macaddress":"0e:00:a9:fe:01:7b"},{"id":"8066d1e0-ee16-4ade-898e-3a232efb8345","networkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","netmask":"255.255.255.0","gateway":"10.147.51.1","ipaddress":"10.147.51.21","isolationuri":"vlan://51","broadcasturi":"vlan://51","traffictype":"Public","isdefault":true,"macaddress":"06:bd:38:00:00:20"}],"requiresupgrade":true},
>
> {"id":"70c807c7-679c-41b0-8c93-a38a54d3a47c","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","networkdomain":"cs8cloud.internal","gateway":"10.147.51.1","name":"r-18-VM","podid":"a5d5234e-86d6-41f8-ac8c-5bdf24288231","linklocalnetworkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","publicip":"10.147.51.20","publicmacaddress":"06:bc:86:00:00:1f","publicnetmask":"255.255.255.0","publicnetworkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","guestipaddress":"10.1.1.1","guestmacaddress":"02:00:20:79:00:02","guestnetmask":"255.255.255.0","guestnetworkid":"29a643b3-cabb-4855-a967-38853c150f73","templateid":"ce21f5d6-630f-11e3-9a2f-97407caff5c2","created":"2013-12-12T17:55:43+0530","state":"Stopped","account":"admin","domainid":"94814869-1330-42b9-8e74-77a407a3cd7e","domain":"child1","serviceofferingid":"72743e39-323d-4aba-9076-6c43b72252c1","serviceofferingname":"System
> Offering For Software
> Router","isredundantrouter":false,"redundantstate":"UNKNOWN","version":"3.0","role":"VIRTUAL_ROUTER","nic":[{"id":"5d3917d6-7022-446e-981c-04b88307151f","networkid":"29a643b3-cabb-4855-a967-38853c150f73","networkname":"admin2","netmask":"255.255.255.0","ipaddress":"10.1.1.1","traffictype":"Guest","type":"Isolated","isdefault":false,"macaddress":"02:00:20:79:00:02"},{"id":"42a50f06-4e66-41cc-8c4a-1b76afd893f1","networkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","traffictype":"Control","isdefault":false},{"id":"d7fda58e-ff9e-4427-99d9-aca3d1d0bc49","networkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","netmask":"255.255.255.0","gateway":"10.147.51.1","ipaddress":"10.147.51.20","isolationuri":"vlan://51","broadcasturi":"vlan://51","traffictype":"Public","isdefault":true,"macaddress":"06:bc:86:00:00:1f"}],"requiresupgrade":true},
>
> {"id":"27e5c26c-5101-4b13-b8c0-666e7f0adf72","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","gateway":"10.147.51.1","name":"r-16-VM","podid":"a5d5234e-86d6-41f8-ac8c-5bdf24288231","hostid":"90ac48de-eb48-4283-b2f9-1a6581a92fb6","hostname":"Rack1Pod1Host24","linklocalip":"169.254.2.220","li
[jira] [Reopened] (CLOUDSTACK-5492) Group by options in router pages always shows requiresupgrade as no
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shweta agarwal reopened CLOUDSTACK-5492:
I can still reproduce it .
My MS IP is 10.147.40.27
web url : 10.147.40.27:8080/client
login/password : admin/password
Attaching DB dump as well
> Group by options in router pages always shows requiresupgrade as no
> ---
>
> Key: CLOUDSTACK-5492
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5492
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.3.0
> Environment: on 4.3. upgraded setup in which router is not yet
> upgraded
> goto router page via infrastructure
> Select option group by zone/pod/cluster
> Notice Requires upgrade is shown as No
> API call
> http://10.147.40.27:8080/client/api?command=listRouters&response=json&sessionkey=lDWk06sWJovcFLDuw3MHaS00N4Q%3D&podid=a5d5234e-86d6-41f8-ac8c-5bdf24288231&listAll=true&page=1&pagesize=20&_=1386935114493
> Response returns requires upgrade field as true
> { "listroutersresponse" : { "count":9 ,"router" : [
> {"id":"3d05883f-3089-449a-84a2-bb7d758f1e82","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","gateway":"10.147.51.1","name":"r-19-VM","podid":"a5d5234e-86d6-41f8-ac8c-5bdf24288231","hostid":"90ac48de-eb48-4283-b2f9-1a6581a92fb6","hostname":"Rack1Pod1Host24","linklocalip":"169.254.1.123","linklocalmacaddress":"0e:00:a9:fe:01:7b","linklocalnetmask":"255.255.0.0","linklocalnetworkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","publicip":"10.147.51.21","publicmacaddress":"06:bd:38:00:00:20","publicnetmask":"255.255.255.0","publicnetworkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","templateid":"ce21f5d6-630f-11e3-9a2f-97407caff5c2","created":"2013-12-12T17:56:08+0530","state":"Running","account":"admin","domainid":"94814869-1330-42b9-8e74-77a407a3cd7e","domain":"child1","serviceofferingid":"72743e39-323d-4aba-9076-6c43b72252c1","serviceofferingname":"System
> Offering For Software
> Router","isredundantrouter":false,"redundantstate":"UNKNOWN","version":"3.0","vpcid":"07fcf168-3086-40c0-bd9b-eddb70396aaa","role":"VIRTUAL_ROUTER","nic":[{"id":"87f6bfb3-f993-4cc6-8332-4b25efd298a3","networkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","netmask":"255.255.0.0","gateway":"169.254.0.1","ipaddress":"169.254.1.123","traffictype":"Control","isdefault":false,"macaddress":"0e:00:a9:fe:01:7b"},{"id":"8066d1e0-ee16-4ade-898e-3a232efb8345","networkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","netmask":"255.255.255.0","gateway":"10.147.51.1","ipaddress":"10.147.51.21","isolationuri":"vlan://51","broadcasturi":"vlan://51","traffictype":"Public","isdefault":true,"macaddress":"06:bd:38:00:00:20"}],"requiresupgrade":true},
>
> {"id":"70c807c7-679c-41b0-8c93-a38a54d3a47c","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","networkdomain":"cs8cloud.internal","gateway":"10.147.51.1","name":"r-18-VM","podid":"a5d5234e-86d6-41f8-ac8c-5bdf24288231","linklocalnetworkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","publicip":"10.147.51.20","publicmacaddress":"06:bc:86:00:00:1f","publicnetmask":"255.255.255.0","publicnetworkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","guestipaddress":"10.1.1.1","guestmacaddress":"02:00:20:79:00:02","guestnetmask":"255.255.255.0","guestnetworkid":"29a643b3-cabb-4855-a967-38853c150f73","templateid":"ce21f5d6-630f-11e3-9a2f-97407caff5c2","created":"2013-12-12T17:55:43+0530","state":"Stopped","account":"admin","domainid":"94814869-1330-42b9-8e74-77a407a3cd7e","domain":"child1","serviceofferingid":"72743e39-323d-4aba-9076-6c43b72252c1","serviceofferingname":"System
> Offering For Software
> Router","isredundantrouter":false,"redundantstate":"UNKNOWN","version":"3.0","role":"VIRTUAL_ROUTER","nic":[{"id":"5d3917d6-7022-446e-981c-04b88307151f","networkid":"29a643b3-cabb-4855-a967-38853c150f73","networkname":"admin2","netmask":"255.255.255.0","ipaddress":"10.1.1.1","traffictype":"Guest","type":"Isolated","isdefault":false,"macaddress":"02:00:20:79:00:02"},{"id":"42a50f06-4e66-41cc-8c4a-1b76afd893f1","networkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","traffictype":"Control","isdefault":false},{"id":"d7fda58e-ff9e-4427-99d9-aca3d1d0bc49","networkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","netmask":"255.255.255.0","gateway":"10.147.51.1","ipaddress":"10.147.51.20","isolationuri":"vlan://51","broadcasturi":"vlan://51","traffictype":"Public","isdefault":true,"macaddress":"06:bc:86:00:00:1f"}],"requiresupgrade":true},
>
> {"id":"27e5c26c-5101-4b13-b8c0-666e7f0adf72","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","gateway":"10.147.51.1","name":"r-16-VM","podid":"a5d5234e-86d6-41f8-ac8c
[jira] [Commented] (CLOUDSTACK-5823) Taking a VMware snapshot doesn't work
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867545#comment-13867545
]
ASF subversion and git services commented on CLOUDSTACK-5823:
-
Commit a354d969ce316d065a4abf1405fce708955bdf0a in branch refs/heads/master
from [~mike-tutkowski]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a354d96 ]
Merge from 4.3: CLOUDSTACK-5823: Taking a VMware snapshot doesn't work
> Taking a VMware snapshot doesn't work
> -
>
> Key: CLOUDSTACK-5823
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5823
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: VMware
>Affects Versions: 4.3.0
> Environment: ESXi 5.1
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.3.0
>
>
> Per a discussion on the mailing list:
> VMware snapshot question
> Mike Tutkowski
> 4:10 PM (18 hours ago)
> to dev
> Hi,
> I was wondering about the following code in VmwareStorageManagerImpl. It is
> in the CreateVMSnapshotAnswer execute(VmwareHostService hostService,
> CreateVMSnapshotCommand cmd) method.
> The part I wonder about is in populating the mapNewDisk map. For disks like
> the following:
> i-2-9-VM/fksjfaklsjdgflajs.vmdk, the key for the map ends up being i-2.
> When we call this:
> String baseName = extractSnapshotBaseFileName(volumeTO.getPath());
> It uses a path such as the following:
> fksjfaklsjdgflajs
> There is no i-2-9-VM/ preceding the name, so the key we search on ends up
> being the following:
> fksjfaklsjdgflajs
> This leads to a newPath being equal to null.
> As it turns out, I believe null is actually correct, but - if that's the case
> - why do we have all this logic if - in the end - we are just going to assign
> null to newPath in every case when creating a VM snapshot for VMware? As it
> turns out, null is later interpreted to mean, "don't replace the path field
> of this volume in the volumes table," which is, I think, what we want.
> Thanks!
> VirtualDisk[] vdisks = vmMo.getAllDiskDevice();
> for (int i = 0; i < vdisks.length; i ++){
> List> vmdkFiles =
> vmMo.getDiskDatastorePathChain(vdisks[i], false);
> for(Pair fileItem :
> vmdkFiles) {
> String vmdkName = fileItem.first().split(" ")[1];
> if (vmdkName.endsWith(".vmdk")){
> vmdkName = vmdkName.substring(0,
> vmdkName.length() - (".vmdk").length());
> }
> String baseName =
> extractSnapshotBaseFileName(vmdkName);
> mapNewDisk.put(baseName, vmdkName);
> }
> }
> for (VolumeObjectTO volumeTO : volumeTOs) {
> String baseName =
> extractSnapshotBaseFileName(volumeTO.getPath());
> String newPath = mapNewDisk.get(baseName);
> // get volume's chain size for this VM snapshot, exclude
> current volume vdisk
> DataStoreTO store = volumeTO.getDataStore();
> long size =
> getVMSnapshotChainSize(context,hyperHost,baseName + "*.vmdk",
> store.getUuid(), newPath);
> if(volumeTO.getVolumeType()== Volume.Type.ROOT){
> // add memory snapshot size
> size = size +
> getVMSnapshotChainSize(context,hyperHost,cmd.getVmName()+"*.vmsn",store.getUuid(),null);
> }
> volumeTO.setSize(size);
> volumeTO.setPath(newPath);
> }
> Mike Tutkowski
> 4:35 PM (17 hours ago)
> to dev
> In short, I believe we can remove mapNewDisk and just assign null to newPath.
> This will keep the existing path for the volume in question (in the volumes
> table) in the same state as it was before we created a VMware snapshot, which
> I believe is the intent anyways.
> Thoughts on that?
> Mike Tutkowski
> 6:33 PM (15 hours ago)
> to Kelven, dev
> Actually, the more I look at this code, the more I think perhaps VMware
> snapshots are broken because the newPath field should probably not be
> assigned null after creating a new VMware snapshot (I'm thinking the intend
> is to replace the other path with a new path that refers to the delta file
> that was just created).
> Does anyone know who worked on VMware snapshots? I've love to ask these
> questions to him soon as we are approaching the end of 4.3.
> Thanks!
> Kelven Yang 10:02 PM (12 hours ago)
> Yes, your guess is correct, the intent to update with a new path is to
> reflec..
[jira] [Created] (CLOUDSTACK-5851) add a nic to vm failed
zhenglei created CLOUDSTACK-5851: Summary: add a nic to vm failed Key: CLOUDSTACK-5851 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5851 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.1.0 Environment: cloudstack4.1.0 and xenserver6.0 Reporter: zhenglei 1. Create a vm successfully in an advanced zone. 2. Create a network with the default networkoffering successfully. There is no vm in the network now, and also the vrouter is not started. 3. Add the network to the vm by calling the restful api successfully. 4. But when I login the cloudstack ui, I find the new network vrouter is not started and its status is ”starting“. so add nic operation is failed. 5. I want to check the vrouter by xencenter, but there is no this vrouter. 6. At last, i check the management server log files, There is no any ERROR and Exception. I think the reason is the vrouter is not started, But i don't why. I also do some add nic or remove nic tests when a vrouer is running, and it is normal. so, why?Thanks... -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5502) [Automation] createVlanIpRange API failing, if you pass VLAN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867537#comment-13867537
]
Marcus Sorensen commented on CLOUDSTACK-5502:
-
I think that won't work, as null fails to be allowed for public
networks, per the separate discussion. The suggestion would have the
same current behavior as Daans patch, disallowing the creation of
non-tagged public network that has worked for so long. The patch
posted preserves the existing behavior and fixes the original bug
issue by treating both 'untagged' and empty string as untagged.
Sorry, we had a long conversation about it on the mailing list that
wasn't properly captured here. See review request
https://reviews.apache.org/r/16758/
On Thu, Jan 9, 2014 at 2:59 PM, Alena Prokharchyk (JIRA)
> [Automation] createVlanIpRange API failing, if you pass VLAN
> -
>
> Key: CLOUDSTACK-5502
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5502
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
> Environment: KVM Basic Zone with SG
>Reporter: Rayees Namathponnan
>Assignee: Daan Hoogland
>Priority: Blocker
> Fix For: 4.3.0
>
>
> This issue found in KVM basic zone with SG automation run; test cases from
> below suite filed
> integration.component.test_multiple_ip_ranges.
> Steps to reproduce
> Step 1 : Create basic zone with SG
> Step 2 : Crete IP VLAN Range with below command (pass vlan=untagged)
> http://xxx..xxx.xxx:8096/?command=createVlanIpRange&gateway=10.223.251.1&forvirtualnetwork=false&startip=10.223.251.3&podid=0253bcbf-e636-4776-9e8c-216b70d195a2&zoneid=a9912aa8-a231-44d9-a70b-9d53e6db2d27&netmask=255.255.255.192&vlan=untagged
> Result;
> API command failed with error
> { "createvlaniprangeresponse" :
> {"uuidList":[],"errorcode":431,"cserrorcode":4350,"errortext":"Vlan doesn't
> match vlan of the network"} }
> this API command works only, if you are not passing any VLAN
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5651) deployVm: customparameters param name has to be changed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867539#comment-13867539 ] Bharat Kumar commented on CLOUDSTACK-5651: -- link to review board. https://reviews.apache.org/r/16750/ > deployVm: customparameters param name has to be changed > --- > > Key: CLOUDSTACK-5651 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5651 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Alena Prokharchyk >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.3.0 > > > deployVm API got a new param in 4.3 -“customparameters”. The description of > the parameter is very vague and generic “used to specify the custom > parameters”. > Is it just the metadata in form of value/key pairs? If so, please change the > name to “details” - the generic name used when specify key/value metadata in > other API commands. > Also you need to save this information in the “user_vm_details” table, and > return it in the UserVmResponse, “details” map parameter. I don’t see “custom > parameters” key map being returned anywhere in the UserVmResponse. Its very > confusing, because whatever is passed to the Create/Update call, should be > returned in the response as well. > It all has to be fixed in 4.3 branch. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5485) Vmware - Whe 10 hourly snapshots are scheduled at the same time , we see only 5 of them being processed actively at the same time.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5485: --- Assignee: Abhinandan Prateek (was: Likitha Shetty) > Vmware - Whe 10 hourly snapshots are scheduled at the same time , we see only > 5 of them being processed actively at the same time. > --- > > Key: CLOUDSTACK-5485 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5485 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Abhinandan Prateek >Priority: Critical > Fix For: 4.3.0 > > Attachments: vmware.rar > > > Vmware - When 10 hourly snapshots are scheduled at the same time , we see > only 5 of them being processed actively at the same time. > Set up : > Advanced Zone with 2 5.1 ESXI hosts. > Steps to reproduce the problem: > 1. Deploy 5 Vms in each of the hosts , so we start with 10 Vms. > 2. Start concurrent snapshots for ROOT volumes of all the Vms. > Noticed that on the Vsphere client , only 5 of these snapshots gets executed > in parallel.Rest of them get picked up when the current snapshot jobs > complete. > Why cant we do more than 5 parallel tasks ? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-4773) Generic SSVM Copy
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Suich closed CLOUDSTACK-4773. --- Resolution: Not A Problem > Generic SSVM Copy > - > > Key: CLOUDSTACK-4773 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4773 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Chris Suich > > The storage subsystem currently uses a number of hypervisor APIs for > transferring files between data stores (both primary and secondary). However, > while implementing the storage subsystem API as a storage provider, we have > discovered that there is a need for a generic copy method that can copy files > between (almost) any source and destination. For example, if we need to copy > a file from our storage to S3 or Swift. It would make more sense for the SSVM > to provide a generic method for copying files than for us to implement a copy > method for S3, Swift, etc. Additionally, the SSVM already has NFS volumes > mounted and has easier access to primary and secondary storage. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5111) Detail view fields marked with 'isPassword' are not obfuscated
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Suich closed CLOUDSTACK-5111. --- > Detail view fields marked with 'isPassword' are not obfuscated > -- > > Key: CLOUDSTACK-5111 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5111 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Chris Suich >Assignee: Chris Suich >Priority: Minor > Labels: ui > Fix For: 4.3.0 > > > Form fields marked with 'isPassword' are created as input fields with type > 'password' so that the value is obfuscated. However, detail view fields (when > editing) are not obfuscated. Additionally, if a value is entered and the edit > form is submitted, the password is still visible in plain text. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-4910) Take VM snapshot instantly returns success regardless of actual result
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Suich closed CLOUDSTACK-4910. --- > Take VM snapshot instantly returns success regardless of actual result > -- > > Key: CLOUDSTACK-4910 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4910 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Chris Suich >Assignee: Chris Suich > Labels: ui > Fix For: 4.3.0 > > Original Estimate: 1h > Remaining Estimate: 1h > > When taking a VM snapshot in the CloudStack UI, the result always instantly > comes back as successful regardless of the actual result. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-4774) Provide Option to Quiesce VMs While Taking Snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Suich resolved CLOUDSTACK-4774. - Resolution: Fixed > Provide Option to Quiesce VMs While Taking Snapshots > > > Key: CLOUDSTACK-4774 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4774 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Chris Suich > > CloudStack currently snapshots vm disks by taking hypervisor snapshots. > However, when implementing the storage subsystem API interface > takeSnapshot(), the VM associated with the requested volume is not quiesced > since a hypervisor snapshot is not necessarily taken. When creating a storage > level snapshot, there are ways around this and 'quiescing' the vm without > actually quiescing it (through hypervisor APIs). I would like to propose that > there be an option to quiesce VMs when taking snapshots both manually and > through recurring snapshot policies. One issue I see with this is that this > option is not always applicable. If the default storage provider is used, a > hypervisor snapshot will be taken and therefore the VM will always be > quiesced. Some storage providers may not respect the user's request to > quiesce. Because of this, I suggest that the option be shown to the user as > 'Quiesce VM (if applicable)'. This indicates to the user that the option will > be passed to the management server and respected if possible. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5139) Provision Secondary Storage Dialog incorrectly displays all storage providers
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Suich closed CLOUDSTACK-5139. --- > Provision Secondary Storage Dialog incorrectly displays all storage providers > - > > Key: CLOUDSTACK-5139 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5139 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Chris Suich >Assignee: Jessica Wang >Priority: Critical > Labels: ui > Fix For: 4.3.0 > > Attachments: Screen Shot 2013-10-30 at 2.59.04 PM.png, Screen Shot > 2013-10-30 at 2.59.48 PM.png > > > The secondary storage provisioning dialog currently assumes any storage > provider returned by listStorageProviders will be able to be handled by the > UI. However, the UI only supports Nfs, S3 and Swift secondary storage. The > secondary storage provisioning dropdown should only display the providers > which it knows how to handle. > See attached images for example -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5342) [Automation] Add NIC to virtual machine fails in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867527#comment-13867527
]
Girish Shilamkar commented on CLOUDSTACK-5342:
--
Ok, Animesh. I will go by the majority opinion. Btw, the test was already
changed.
Saksham,
In the latest run it again failed (Build #246). The current wait time is 5
secs. Do you want me to bump it up ?
Regards,
Girish
> [Automation] Add NIC to virtual machine fails in KVM
>
>
> Key: CLOUDSTACK-5342
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5342
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller
>Affects Versions: 4.3.0
> Environment: KVM advanced
>Reporter: Gaurav Aradhye
>Assignee: Saksham Srivastava
> Fix For: 4.3.0
>
>
> Add network to VM test cases fail in KVM with following error.
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u'Unable to add NIC to VM[User|VM-e9350ee5-bf2e-418c-91d6-1535dcb4d488]'}
> The same test cases execute successfully on XenServer. As per the feature
> specification (see
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Add+Remove+Networks+to+VMs),
> "Add network to VM" feature should be supported on KVM too.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5388) Volume Snapshot UI does not provide option of adding quiesce vm parameter
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Suich closed CLOUDSTACK-5388. --- > Volume Snapshot UI does not provide option of adding quiesce vm parameter > - > > Key: CLOUDSTACK-5388 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5388 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Chris Suich >Assignee: Chris Suich >Priority: Minor > Labels: ui > Fix For: 4.3.0 > > Original Estimate: 1h > Remaining Estimate: 1h > > Volume Snapshot UI does not provide option of adding quiesce vm parameter > when the underlying storage does support the option. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5384) UI dataProviders are unable to differentiate between load and refresh context
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Suich closed CLOUDSTACK-5384. --- > UI dataProviders are unable to differentiate between load and refresh context > - > > Key: CLOUDSTACK-5384 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5384 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Chris Suich >Assignee: Chris Suich > Labels: ui > Fix For: 4.3.0 > > Original Estimate: 1h > Remaining Estimate: 1h > > UI dataProviders are invoked for both loading listViews and refreshing > listViews, however, they are unable to tell the difference between the two > invocations. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5368) ListViews marked with 'needsRefresh' do not have loading overlay removed on error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Suich closed CLOUDSTACK-5368. --- > ListViews marked with 'needsRefresh' do not have loading overlay removed on > error > - > > Key: CLOUDSTACK-5368 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5368 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: Chris Suich >Assignee: Chris Suich > Fix For: 4.3.0 > > > ListView actions marked with 'needsRefresh' add a loading overlay before the > action is performed. If the operation succeeds, the overlay is properly > removed. If it fails, the overlay is NOT removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-4771) Support Revert VM Disk from Snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Suich closed CLOUDSTACK-4771. --- Resolution: Fixed > Support Revert VM Disk from Snapshot > > > Key: CLOUDSTACK-4771 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4771 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Chris Suich > > The storage subsystem API currently has an interface for takeSnapshot() and > an associated externally facing API for takeSnapshot. There is also a method > on the primary data store interface for revertSnapshot(). However, this > method is unused. The storage subsystem interface method should be hooked up > to an externally facing API so that storage providers can provide true VM > disk backup and recovery. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5544) JS error on snapshot view of storage tab
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Suich closed CLOUDSTACK-5544.
---
> JS error on snapshot view of storage tab
>
>
> Key: CLOUDSTACK-5544
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5544
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.3.0
>Reporter: Chris Suich
>Assignee: Brian Federle
> Labels: ui
> Fix For: 4.3.0
>
>
> In this bit of code:
>var snapshotActionfilter = function(args) {
>var jsonObj = args.context.item;
>if (jsonObj.state == 'Destroyed') {
>return [];
>}
>var allowedActions = [];
>if (jsonObj.state == "BackedUp") {
>allowedActions.push("createTemplate");
>allowedActions.push("createVolume");
>if (jsonObj.revertable && args.context.volumes[0].vmstate ==
> "Stopped") {
>allowedActions.push("revertSnapshot");
>}
>}
>allowedActions.push("remove");
>return allowedActions;
>}
> An error is thrown on the snapshot view of the storage tab if
> jsonObj.revertable is true, since args.context.volumes is undefined when on
> this page.
> We should remove the ' && args.context.volumes[0].vmstate == "Stopped"'
> condition and simply make that check on the server side since the volume/vm
> state information is not available when looking at the snapshots page.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5572) HypervisorHelperImpl.quiesceVM() uses snapshot type DiskAndMemory instead of Disk
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Suich closed CLOUDSTACK-5572. --- > HypervisorHelperImpl.quiesceVM() uses snapshot type DiskAndMemory instead of > Disk > - > > Key: CLOUDSTACK-5572 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5572 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.3.0 >Reporter: Chris Suich >Assignee: edison su > Labels: snapshot > Fix For: 4.3.0 > > Original Estimate: 1m > Remaining Estimate: 1m > > The VMSnapshotTO is currently using VMSnapshot.Type.DiskAndMemory as the type > and I believe it should be just using VMSnapshot.Type.Disk. When using > DiskAndMemory, it causes an issue when quiescing Windows VMs. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5662) XenServer can't discover iSCSI targets with different credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867504#comment-13867504 ] ASF subversion and git services commented on CLOUDSTACK-5662: - Commit 6944bf9bba5363ad35764b8ee6a31e43a96490d3 in branch refs/heads/master from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6944bf9 ] Merge from 4.3: CLOUDSTACK-5662: XenServer can't discover iSCSI targets with different credentials > XenServer can't discover iSCSI targets with different credentials > - > > Key: CLOUDSTACK-5662 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5662 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: XenServer 6.1 >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.3.0 > > > If you discover an iSCSI target using CHAP credentials, say, x and later want > to discover another iSCSI target using CHAP credentials, says, y, the second > iSCSI target cannot be discovered because XenServer only tries to discover > iSCSI targets using CHAP credentials x (which are the first CHAP credentials > XenServer encountered for the portal in question). > This is a problem for a multi-tenant storage system and I have seen this > issue when using the SolidFire plug-in. > The SolidFire plug-in needs to be changed to stop using CHAP with XenServer > and instead use its Volume Access Group feature (which maps host IQNs to > volumes). > This will also require changes in CloudStack itself. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-4774) Provide Option to Quiesce VMs While Taking Snapshots
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Suich closed CLOUDSTACK-4774. --- > Provide Option to Quiesce VMs While Taking Snapshots > > > Key: CLOUDSTACK-4774 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4774 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Chris Suich > > CloudStack currently snapshots vm disks by taking hypervisor snapshots. > However, when implementing the storage subsystem API interface > takeSnapshot(), the VM associated with the requested volume is not quiesced > since a hypervisor snapshot is not necessarily taken. When creating a storage > level snapshot, there are ways around this and 'quiescing' the vm without > actually quiescing it (through hypervisor APIs). I would like to propose that > there be an option to quiesce VMs when taking snapshots both manually and > through recurring snapshot policies. One issue I see with this is that this > option is not always applicable. If the default storage provider is used, a > hypervisor snapshot will be taken and therefore the VM will always be > quiesced. Some storage providers may not respect the user's request to > quiesce. Because of this, I suggest that the option be shown to the user as > 'Quiesce VM (if applicable)'. This indicates to the user that the option will > be passed to the management server and respected if possible. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5742) #cpu,cpu speed, and ram is getting updated under wrong usage_type(2) for dynamic compute offering in usage_vm_instance table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867501#comment-13867501 ] prashant kumar mishra commented on CLOUDSTACK-5742: --- Now #cpu,cpu speed and ram is getting updated under usage_type1 and 2.i talked to kishan ,it is expected behavior so closing it usage DB mysql> select * from usage_vm_instance where vm_instance_id=7; ++-+++-+-+-+-+-+-+---+---++ | usage_type | zone_id | account_id | vm_instance_id | vm_name | service_offering_id | template_id | hypervisor_type | start_date | end_date| cpu_speed | cpu_cores | memory | ++-+++-+-+-+-+-+-+---+---++ | 1 | 1 | 3 | 7 | pkm | 12 | 5 | XenServer | 2014-01-09 16:04:57 | 2014-01-09 16:18:27 | 100 | 1 |256 | | 1 | 1 | 3 | 7 | pkm | 12 | 5 | XenServer | 2014-01-09 16:42:18 | 2014-01-09 16:48:30 | 100 | 1 |256 | | 1 | 1 | 3 | 7 | pkm | 12 | 5 | XenServer | 2014-01-09 17:31:44 | NULL | 100 | 1 |256 | | 2 | 1 | 3 | 7 | pkm | 12 | 5 | XenServer | 2014-01-09 16:03:06 | NULL | 100 | 1 |256 | ++-+++-+-+-+-+-+-+---+---++ 4 rows in set (0.01 sec) > #cpu,cpu speed, and ram is getting updated under wrong usage_type(2) for > dynamic compute offering in usage_vm_instance table > > > Key: CLOUDSTACK-5742 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5742 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: prashant kumar mishra >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.3.0 > > Attachments: LOG_DB.rar > > > STEPS TO REPO > == > 1-prepare a CS setup 4.3 > 2-deploy a vm with small CO > 3-Change the vm CO to dynamic CO. > 4-check the usage_vm_instance table after cloud_usage db synch > EXPECTED > = > cpu and ram should get updated under usage type 1 > ACTUAL > === > cpu and ram is getting updated under usage type2 > DB > === > | 2 | 1 | 2 | 8 | test| > 12 | 202 | XenServer | 2014-01-03 10:10:15 | NULL > | 100 | 1 |256 | > | 1 | 1 | 2 | 8 | test| > 12 | 202 | XenServer | 2014-01-03 10:11:21 | NULL > | NULL | NULL | NULL | > ++-+++-+-+-+-+-+-+---+---++ -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5764) "java.lang.IllegalArgumentException" in CPVM agent logs when accessing the console of any VM.Blank console for all VMs.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar updated CLOUDSTACK-5764:
-
Assignee: Santhosh Kumar Edukulla (was: Bharat Kumar)
> "java.lang.IllegalArgumentException" in CPVM agent logs when accessing the
> console of any VM.Blank console for all VMs.
> ---
>
> Key: CLOUDSTACK-5764
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5764
> 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: manasaveloori
>Assignee: Santhosh Kumar Edukulla
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: cloud.log, management-server.log
>
>
> Steps:
> 1. Deploy CS 4.3 with KVM HV.
> 2. view the CPVM/SSVM/userVM console.
> Observing blank console.
> In CPVM agent logs observing the following exception when trying to access
> the console.
> 2014-01-03 11:30:47,362 DEBUG [cloud.agent.Agent] (Agent-Handler-4:null)
> Received response: Seq 4-44: { Ans: , MgmtId: 7494415941730, via: 4, Ver:
> v1, Flags: 100010,
> [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
> 2014-01-03 11:30:49,769 WARN [cloud.consoleproxy.ConsoleProxyAjaxHandler]
> (Thread-14:null) Exception,
> java.lang.IllegalArgumentException
> at
> com.cloud.consoleproxy.ConsoleProxyAjaxHandler.doHandle(ConsoleProxyAjaxHandler.java:96)
> at
> com.cloud.consoleproxy.ConsoleProxyAjaxHandler.handle(ConsoleProxyAjaxHandler.java:49)
> at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:83)
> at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:83)
> at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:86)
> at
> sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:598)
> at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:83)
> at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:568)
> at java.lang.Thread.run(Thread.java:679)
> 2014-01-03 11:30:52,352 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread]
> (Console Proxy GC Thread:null) connMap={}
> 2014-01-03 11:30:52,353 DEBUG [resource.consoleproxy.ConsoleProxyResource]
> (Console Proxy GC Thread:null) Report proxy load info, proxy : 5, load: {
> "connections": []
> }
> Attaching the CPVM logs and MS logs
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5662) XenServer can't discover iSCSI targets with different credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867525#comment-13867525 ] ASF subversion and git services commented on CLOUDSTACK-5662: - Commit 929838c8eb10bd96f14edcfd1d9f4579631d8d7c in branch refs/heads/master from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=929838c ] Merge from 4.3: CLOUDSTACK-5662: XenServer can't discover iSCSI targets with different credentials > XenServer can't discover iSCSI targets with different credentials > - > > Key: CLOUDSTACK-5662 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5662 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: XenServer 6.1 >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.3.0 > > > If you discover an iSCSI target using CHAP credentials, say, x and later want > to discover another iSCSI target using CHAP credentials, says, y, the second > iSCSI target cannot be discovered because XenServer only tries to discover > iSCSI targets using CHAP credentials x (which are the first CHAP credentials > XenServer encountered for the portal in question). > This is a problem for a multi-tenant storage system and I have seen this > issue when using the SolidFire plug-in. > The SolidFire plug-in needs to be changed to stop using CHAP with XenServer > and instead use its Volume Access Group feature (which maps host IQNs to > volumes). > This will also require changes in CloudStack itself. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5662) XenServer can't discover iSCSI targets with different credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867521#comment-13867521 ] ASF subversion and git services commented on CLOUDSTACK-5662: - Commit 7ef78aac407de5a4cbc9408533a03bc4edb93131 in branch refs/heads/master from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7ef78aa ] Merge from 4.3: CLOUDSTACK-5662: XenServer can't discover iSCSI targets with different credentials > XenServer can't discover iSCSI targets with different credentials > - > > Key: CLOUDSTACK-5662 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5662 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: XenServer 6.1 >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.3.0 > > > If you discover an iSCSI target using CHAP credentials, say, x and later want > to discover another iSCSI target using CHAP credentials, says, y, the second > iSCSI target cannot be discovered because XenServer only tries to discover > iSCSI targets using CHAP credentials x (which are the first CHAP credentials > XenServer encountered for the portal in question). > This is a problem for a multi-tenant storage system and I have seen this > issue when using the SolidFire plug-in. > The SolidFire plug-in needs to be changed to stop using CHAP with XenServer > and instead use its Volume Access Group feature (which maps host IQNs to > volumes). > This will also require changes in CloudStack itself. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5848) [Upgrade3.0.6-4.3]"Unable to parse VLAN tag" message when network associated with SRX external firewall device is rebooted.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
manasaveloori updated CLOUDSTACK-5848:
--
Attachment: mysqldump4.3.dmp
mysqldump306PatchE.dmp
> [Upgrade3.0.6-4.3]"Unable to parse VLAN tag" message when network associated
> with SRX external firewall device is rebooted.
>
>
> Key: CLOUDSTACK-5848
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5848
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Devices
>Affects Versions: 4.3.0
> Environment: upgraded the CS from 3.0.6 patch E to 4.3
>Reporter: manasaveloori
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: management-server.rar, mysqldump306PatchE.dmp,
> mysqldump4.3.dmp
>
>
> Steps:
> 1. Deploy CS 3.0.6 patch E using Xen 6.0.2 HV.
> 2. Add SRX device.
> 3 . Deploy the VMs uing the SRX network.
> 4. Enable PF,Static nat rules for the VM using SRX.
> 5. Upgrade the CS to 4.3.
> 6. Now restart the network associated with SRX or disable static nat etc.
> Observing following exceptions in logs:
> er root, class super-user --> xmlns:junos="http://xml.juniper.net/junos/10.4R6/junos";> xmlns="http://xml.juniper.net/xnm/1.1/xnm";
> xmlns:xnm="http://xml.juniper.net/xnm/1.1/xnm";>uncommitted changes
> will be discarded on exit
> 2014-01-09 22:27:14,815 DEBUG [c.c.n.r.JuniperSrxResource]
> (DirectAgent-22:ctx-357d339b) Opened a private configuration.
> 2014-01-09 22:27:14,816 ERROR [c.c.n.r.JuniperSrxResource]
> (DirectAgent-22:ctx-357d339b) com.cloud.utils.exception.ExecutionException:
> Unable to parse VLAN tag: 47
> 2014-01-09 22:27:14,816 DEBUG [c.c.n.r.JuniperSrxResource]
> (DirectAgent-22:ctx-357d339b) Sending request:
> 2014-01-09 22:27:14,868 DEBUG [c.c.n.r.JuniperSrxResource]
> (DirectAgent-22:ctx-357d339b) Checking response: xmlns:junos="http://xml.juniper.net/junos/10.4R6/junos";>
> 2014-01-09 22:27:14,868 DEBUG [c.c.n.r.JuniperSrxResource]
> (DirectAgent-22:ctx-357d339b) Closed private configuration.
> 2014-01-09 22:27:14,869 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-22:ctx-357d339b) Seq 9-550895625: Response Received:
> 2014-01-09 22:27:14,869 DEBUG [c.c.a.t.Request] (DirectAgent-22:ctx-357d339b)
> Seq 9-550895625: Processing: { Ans: , MgmtId: 6642334695485, via: 9, Ver:
> v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Exception:
> com.cloud.utils.exception.ExecutionException\nMessage: Unable to parse VLAN
> tag: 47\nStack: com.cloud.utils.exception.ExecutionException: Unable to parse
> VLAN tag: 47\n\tat
> com.cloud.network.resource.JuniperSrxResource.getVlanTag(JuniperSrxResource.java:3609)\n\tat
>
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:894)\n\tat
>
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:912)\n\tat
>
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:912)\n\tat
>
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:830)\n\tat
>
> com.cloud.network.resource.JuniperSrxResource.executeRequest(JuniperSrxResource.java:353)\n\tat
>
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)\n\tat
>
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)\n\tat
>
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)\n\tat
>
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)\n\tat
>
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)\n\tat
>
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)\n\tat
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:166)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)\n\tat
> java.lang.Thread.run(Thread.java:679)\n","wait":0}}] }
> 2014-01-09 22:27:14,870
[jira] [Updated] (CLOUDSTACK-5263) Virtual router stop/start modifies firewall rules allowing additional access
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Nalley updated CLOUDSTACK-5263: - Security: Public (was: Non-Public) > Virtual router stop/start modifies firewall rules allowing additional access > > > Key: CLOUDSTACK-5263 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5263 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.1.1 >Reporter: John Kinsella >Assignee: Jayapal Reddy >Priority: Critical > Labels: security > Fix For: 4.2.1, 4.3.0 > > Attachments: > 0001-Fix-issue-with-sourceCidr-not-being-passed-to-the-VR.patch > > > Say a user created a firewall rule to allow all access to port 22 from > 172.16.40.0/24 it would be correctly processed by the VRouter and stored in > the database. If the Vrouter instance would be stopped and started, the > source cidr (172.16.40.0/24) would become null and consequently set to > 0.0.0.0/0. Allowing free access to this port from the internet when the > router finished restarting. Changing a rule on the firewall would send the > correct information again including the sourceCids until the next stop start. > This behavior was observed in version 4.1.1 and confirmed to still exist in > the current master build. > Considering that a stop/start of the router vms is part of our standard > upgrade procedure, this is a serious issue. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5263) Virtual router stop/start modifies firewall rules allowing additional access
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Nalley updated CLOUDSTACK-5263: - Fix Version/s: 4.2.1 > Virtual router stop/start modifies firewall rules allowing additional access > > > Key: CLOUDSTACK-5263 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5263 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.1.1 >Reporter: John Kinsella >Assignee: Jayapal Reddy >Priority: Critical > Labels: security > Fix For: 4.2.1, 4.3.0 > > Attachments: > 0001-Fix-issue-with-sourceCidr-not-being-passed-to-the-VR.patch > > > Say a user created a firewall rule to allow all access to port 22 from > 172.16.40.0/24 it would be correctly processed by the VRouter and stored in > the database. If the Vrouter instance would be stopped and started, the > source cidr (172.16.40.0/24) would become null and consequently set to > 0.0.0.0/0. Allowing free access to this port from the internet when the > router finished restarting. Changing a rule on the firewall would send the > correct information again including the sourceCids until the next stop start. > This behavior was observed in version 4.1.1 and confirmed to still exist in > the current master build. > Considering that a stop/start of the router vms is part of our standard > upgrade procedure, this is a serious issue. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5742) #cpu,cpu speed, and ram is getting updated under wrong usage_type(2) for dynamic compute offering in usage_vm_instance table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra closed CLOUDSTACK-5742. - > #cpu,cpu speed, and ram is getting updated under wrong usage_type(2) for > dynamic compute offering in usage_vm_instance table > > > Key: CLOUDSTACK-5742 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5742 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: prashant kumar mishra >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.3.0 > > Attachments: LOG_DB.rar > > > STEPS TO REPO > == > 1-prepare a CS setup 4.3 > 2-deploy a vm with small CO > 3-Change the vm CO to dynamic CO. > 4-check the usage_vm_instance table after cloud_usage db synch > EXPECTED > = > cpu and ram should get updated under usage type 1 > ACTUAL > === > cpu and ram is getting updated under usage type2 > DB > === > | 2 | 1 | 2 | 8 | test| > 12 | 202 | XenServer | 2014-01-03 10:10:15 | NULL > | 100 | 1 |256 | > | 1 | 1 | 2 | 8 | test| > 12 | 202 | XenServer | 2014-01-03 10:11:21 | NULL > | NULL | NULL | NULL | > ++-+++-+-+-+-+-+-+---+---++ -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5848) [Upgrade3.0.6-4.3]"Unable to parse VLAN tag" message when network associated with SRX external firewall device is rebooted.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayapal Reddy updated CLOUDSTACK-5848:
--
Summary: [Upgrade3.0.6-4.3]"Unable to parse VLAN tag" message when network
associated with SRX external firewall device is rebooted. (was: "Unable to
parse VLAN tag" message when network associated with SRX external firewall
device is rebooted.)
> [Upgrade3.0.6-4.3]"Unable to parse VLAN tag" message when network associated
> with SRX external firewall device is rebooted.
>
>
> Key: CLOUDSTACK-5848
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5848
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Devices
>Affects Versions: 4.3.0
> Environment: upgraded the CS from 3.0.6 patch E to 4.3
>Reporter: manasaveloori
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: management-server.rar
>
>
> Steps:
> 1. Deploy CS 3.0.6 patch E using Xen 6.0.2 HV.
> 2. Add SRX device.
> 3 . Deploy the VMs uing the SRX network.
> 4. Enable PF,Static nat rules for the VM using SRX.
> 5. Upgrade the CS to 4.3.
> 6. Now restart the network associated with SRX or disable static nat etc.
> Observing following exceptions in logs:
> er root, class super-user --> xmlns:junos="http://xml.juniper.net/junos/10.4R6/junos";> xmlns="http://xml.juniper.net/xnm/1.1/xnm";
> xmlns:xnm="http://xml.juniper.net/xnm/1.1/xnm";>uncommitted changes
> will be discarded on exit
> 2014-01-09 22:27:14,815 DEBUG [c.c.n.r.JuniperSrxResource]
> (DirectAgent-22:ctx-357d339b) Opened a private configuration.
> 2014-01-09 22:27:14,816 ERROR [c.c.n.r.JuniperSrxResource]
> (DirectAgent-22:ctx-357d339b) com.cloud.utils.exception.ExecutionException:
> Unable to parse VLAN tag: 47
> 2014-01-09 22:27:14,816 DEBUG [c.c.n.r.JuniperSrxResource]
> (DirectAgent-22:ctx-357d339b) Sending request:
> 2014-01-09 22:27:14,868 DEBUG [c.c.n.r.JuniperSrxResource]
> (DirectAgent-22:ctx-357d339b) Checking response: xmlns:junos="http://xml.juniper.net/junos/10.4R6/junos";>
> 2014-01-09 22:27:14,868 DEBUG [c.c.n.r.JuniperSrxResource]
> (DirectAgent-22:ctx-357d339b) Closed private configuration.
> 2014-01-09 22:27:14,869 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-22:ctx-357d339b) Seq 9-550895625: Response Received:
> 2014-01-09 22:27:14,869 DEBUG [c.c.a.t.Request] (DirectAgent-22:ctx-357d339b)
> Seq 9-550895625: Processing: { Ans: , MgmtId: 6642334695485, via: 9, Ver:
> v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Exception:
> com.cloud.utils.exception.ExecutionException\nMessage: Unable to parse VLAN
> tag: 47\nStack: com.cloud.utils.exception.ExecutionException: Unable to parse
> VLAN tag: 47\n\tat
> com.cloud.network.resource.JuniperSrxResource.getVlanTag(JuniperSrxResource.java:3609)\n\tat
>
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:894)\n\tat
>
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:912)\n\tat
>
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:912)\n\tat
>
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:830)\n\tat
>
> com.cloud.network.resource.JuniperSrxResource.executeRequest(JuniperSrxResource.java:353)\n\tat
>
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)\n\tat
>
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)\n\tat
>
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)\n\tat
>
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)\n\tat
>
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)\n\tat
>
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)\n\tat
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:166)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n\tat
>
> java.util.concurrent.ThreadPoo
[jira] [Commented] (CLOUDSTACK-5662) XenServer can't discover iSCSI targets with different credentials
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867492#comment-13867492 ] ASF subversion and git services commented on CLOUDSTACK-5662: - Commit ae35782ccdc208c3b2952a1250b8164f86238f56 in branch refs/heads/master from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ae35782 ] Merge from 4.3: CLOUDSTACK-5662: XenServer can't discover iSCSI targets with different credentials > XenServer can't discover iSCSI targets with different credentials > - > > Key: CLOUDSTACK-5662 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5662 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: XenServer 6.1 >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.3.0 > > > If you discover an iSCSI target using CHAP credentials, say, x and later want > to discover another iSCSI target using CHAP credentials, says, y, the second > iSCSI target cannot be discovered because XenServer only tries to discover > iSCSI targets using CHAP credentials x (which are the first CHAP credentials > XenServer encountered for the portal in question). > This is a problem for a multi-tenant storage system and I have seen this > issue when using the SolidFire plug-in. > The SolidFire plug-in needs to be changed to stop using CHAP with XenServer > and instead use its Volume Access Group feature (which maps host IQNs to > volumes). > This will also require changes in CloudStack itself. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-4504) VM creation Is failing using the Ubuntu ISO with Xen 6.1 and 6.2
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867467#comment-13867467
]
Shanker Balan commented on CLOUDSTACK-4504:
---
According to the XenServer guest install guide, the ISO install method is not
supported for 10.04. You need to use the network install method which does not
work well with CloudStack.
As a workaround, you can create the template directly on a standalone XenServer
6.1/6.2 hypervisor using the network install method and later import this
template into CloudStack.
Alternatively, you can set the OS type to "other (32-bit)" and proceed with the
ISO installation.
> VM creation Is failing using the Ubuntu ISO with Xen 6.1 and 6.2
>
>
> Key: CLOUDSTACK-4504
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4504
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Install and Setup
>Affects Versions: 4.2.1
>Reporter: Kiran Koneti
>Assignee: Nitin Mehta
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: Screen Shot 2013-08-28 at 2.57.40 PM.png,
> management-server.zip
>
>
> 1)Registered a Ubuntu 10.04 32 bit in the CS.
> 2)Tried to create a VM using the ISO then observed the below error message
> "2013-08-26 21:28:58,345 DEBUG [agent.transport.Request]
> (AgentManager-Handler-14:null) Seq 3-347996257: Processing: { Ans: , MgmtId:
> 6703101771911, via: 3, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.storage.DownloadAnswer":{"jobId":"565318cc-d0b4-4365-aea2-044dedb938ea","downloadPct":100,"errorString":"Download
> success, starting install
> ","downloadStatus":"DOWNLOAD_IN_PROGRESS","downloadPath":"/mnt/SecStorage/ec67adf1-b86c-3674-ad7f-46ddd34d104f/template/tmpl/2/202/dnld2917500853441314915tmp_","installPath":"template/tmpl/2/202/202-2-c006beb1-8a48-3ac2-b4d5-af1b6c940b5e.iso","templateSize":0,"templatePhySicalSize":0,"checkSum":"27aa354b8088527ffcd32007b51b25bf","result":true,"details":"Download
> success, starting install ","wait":0}}] }
> 2013-08-26 21:29:00,477 DEBUG [cloud.server.StatsCollector]
> (StatsCollector-1:null) StorageCollector is running...
> ^C
> [root@Kiran-RHEl631 setup]# vi
> /var/log/cloudstack/management/management-server.log
> status: failure
> residentOn: com.xensource.xenapi.Host@e79e523d
> progress: 1.0
> type:
> result:
>errorInfo: [INTERNAL_ERROR, xenopsd internal error:
> XenguestHelper.Xenctrl_dom_linux_build_failure(2, " elf_xen_note_check:
> ERROR: Will only load images built \\\"")]
> otherConfig: {}
>subtaskOf: com.xensource.xenapi.Task@aaf13f6f
> subtasks: []
> com.cloud.utils.exception.CloudRuntimeException: Unable to start VM(i-2-3-VM)
> on host(fe1fce23-4155-4831-b669-a99988cd3259) due to Task failed! Task
> record: uuid: d7d77fe7-2d04-35a2-df1f-200ca1a80bbc
>nameLabel: Async.VM.start_on
> nameDescription:
>allowedOperations: []
>currentOperations: {}
> created: Mon Aug 26 12:06:14 IST 2013
> finished: Mon Aug 26 12:06:17 IST 2013
> status: failure
> residentOn: com.xensource.xenapi.Host@e79e523d
> progress: 1.0
> type:
> result:
>errorInfo: [INTERNAL_ERROR, xenopsd internal error:
> XenguestHelper.Xenctrl_dom_linux_build_failure(2, " elf_xen_note_check:
> ERROR: Will only load images built \\\"")]
> otherConfig: {}
>subtaskOf: com.xensource.xenapi.Task@aaf13f6f
> subtasks: []
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.startVM(CitrixResourceBase.java:3717)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1636)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:553)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
> at
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:104)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)"
> Atatching the MS logs for additional debugging.
> The DB table entries for the Ubuntu templates for the Xen are as below:
> mysql> select * from guest_os_hypervisor where guest_os_id in (select id from
> guest_os where display_name like '%ubu%');
> +-+-+-+-+
> | id
[jira] [Resolved] (CLOUDSTACK-5819) extractTemplate fails with Vmware host on migration of NFS to S3
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-5819.
--
Resolution: Fixed
We need to pack vmware template to ova before sending to S3.
> extractTemplate fails with Vmware host on migration of NFS to S3
>
>
> Key: CLOUDSTACK-5819
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5819
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Template, VMware
>Affects Versions: 4.3.0
> Environment: Latest Management server 4.3
> Two zones one with Xen host and other with VmWare host
>Reporter: Pavan Kumar Bandarupally
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.3.0
>
>
> Trying to download a template created from snapshot of root volume or
> template of root volume after migration of NFS to S3 store throws an error.
> Job Trace:
> ==
> 2014-01-07 22:07:44,221 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-8:ctx-3c03896e) ===START=== 10.146.0.11 -- GET
> command=extractTemplate&mode=HTTP_DOWNLOAD&id=3e35e5f4-9067-4c6e-ba15-3eb80494a6e8&response=json&sessionkey=BGTkrKxSTvEyZG7Nx4tTVof99Tw%3D&_=1389093486904
> 2014-01-07 22:07:44,255 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-8:ctx-3c03896e ctx-f274cea7) submit async job-89, details:
> AsyncJobVO {id:89, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 203, cmd:
> org.apache.cloudstack.api.command.user.template.ExtractTemplateCmd, cmdInfo:
> {"response":"json","id":"3e35e5f4-9067-4c6e-ba15-3eb80494a6e8","sessionkey":"BGTkrKxSTvEyZG7Nx4tTVof99Tw\u003d","cmdEventType":"TEMPLATE.EXTRACT","ctxUserId":"2","httpmethod":"GET","_":"1389093486904","ctxAccountId":"2","ctxStartEventId":"176","mode":"HTTP_DOWNLOAD"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7337246982268, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-01-07 22:07:44,258 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-8:ctx-3c03896e ctx-f274cea7) ===END=== 10.146.0.11 -- GET
> command=extractTemplate&mode=HTTP_DOWNLOAD&id=3e35e5f4-9067-4c6e-ba15-3eb80494a6e8&response=json&sessionkey=BGTkrKxSTvEyZG7Nx4tTVof99Tw%3D&_=1389093486904
> 2014-01-07 22:07:44,262 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-37:ctx-b68520ba) Add job-89 into job monitoring
> 2014-01-07 22:07:44,262 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-37:ctx-b68520ba) Executing AsyncJobVO {id:89, userId: 2,
> accountId: 2, instanceType: Template, instanceId: 203, cmd:
> org.apache.cloudstack.api.command.user.template.ExtractTemplateCmd, cmdInfo:
> {"response":"json","id":"3e35e5f4-9067-4c6e-ba15-3eb80494a6e8","sessionkey":"BGTkrKxSTvEyZG7Nx4tTVof99Tw\u003d","cmdEventType":"TEMPLATE.EXTRACT","ctxUserId":"2","httpmethod":"GET","_":"1389093486904","ctxAccountId":"2","ctxStartEventId":"176","mode":"HTTP_DOWNLOAD"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7337246982268, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-01-07 22:07:44,290 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl]
> (Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in
> store:3, type:Image
> 2014-01-07 22:07:44,300 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl]
> (Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in
> store:1, type:ImageCache
> 2014-01-07 22:07:44,302 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl]
> (Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in
> store:3, type:Image
> 2014-01-07 22:07:44,325 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
> (Job-Executor-37:ctx-b68520ba ctx-f274cea7) copyAsync inspecting src type
> TEMPLATE copyAsync inspecting dest type TEMPLATE
> 2014-01-07 22:07:44,371 DEBUG [c.c.a.t.Request] (Job-Executor-37:ctx-b68520ba
> ctx-f274cea7) Seq 3-242024639: Sending { Cmd , MgmtId: 7337246982268, via:
> 3(s-1-VM), Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/2/203/288329c8b-bb60-325f-8da8-b7e0e9764f99.ova","uuid":"3e35e5f4-9067-4c6e-ba15-3eb80494a6e8","id":203,"format":"OVA","accountId":2,"hvm":true,"displayText":"tmplt
> from root vol on Vmware
> before","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/home/pavan/secondaryVmWareMZ","_role":"ImageCache"}},"name":"288329c8b-bb60-325f-8da8-b7e0e9764f99","hypervisorType":"VMware"}},"destTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/2/203/288329c8b-bb60-325f-8da8-b7e0e9764f99","uuid":
[jira] [Commented] (CLOUDSTACK-5432) [Automation] Libvtd getting crashed and agent going to alert start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867401#comment-13867401 ] edison su commented on CLOUDSTACK-5432: --- we need to disable it by setting execute.in.sequence.hypervisor.commands=true. > [Automation] Libvtd getting crashed and agent going to alert start > --- > > Key: CLOUDSTACK-5432 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5432 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.3.0 > Environment: KVM (RHEL 6.3) > Branch : 4.3 >Reporter: Rayees Namathponnan >Assignee: Marcus Sorensen >Priority: Blocker > Fix For: 4.3.0 > > Attachments: CLOUDSTACK-5432_Jan_06.rar, KVM_Automation_Dec_11.rar, > agent1.rar, agent2.rar, management-server.rar > > > This issue is observed in 4.3 automation environment; libvirt crashed and > cloudstack agent went to alert start; > Please see the agent log; connection between agent and MS lost with error > "Connection closed with -1 on reading size." @ 2013-12-09 19:47:06,969 > 2013-12-09 19:43:41,495 DEBUG [cloud.agent.Agent] > (agentRequest-Handler-2:null) Processing command: > com.cloud.agent.api.GetStorageStatsCommand > 2013-12-09 19:47:06,969 DEBUG [utils.nio.NioConnection] (Agent-Selector:null) > Location 1: Socket Socket[addr=/10.223.49.195,port=8250,localport=40801] > closed on read. Probably -1 returned: Connection closed with -1 on reading > size. > 2013-12-09 19:47:06,969 DEBUG [utils.nio.NioConnection] (Agent-Selector:null) > Closing socket Socket[addr=/10.223.49.195,port=8250,localport=40801] > 2013-12-09 19:47:06,969 DEBUG [cloud.agent.Agent] (Agent-Handler-3:null) > Clearing watch list: 2 > 2013-12-09 19:47:11,969 INFO [cloud.agent.Agent] (Agent-Handler-3:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-09 19:47:11,970 INFO [cloud.agent.Agent] (Agent-Handler-3:null) > Cannot connect because we still have 5 commands in progress. > 2013-12-09 19:47:16,970 INFO [cloud.agent.Agent] (Agent-Handler-3:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-09 19:47:16,990 INFO [cloud.agent.Agent] (Agent-Handler-3:null) > Cannot connect because we still have 5 commands in progress. > 2013-12-09 19:47:21,990 INFO [cloud.agent.Agent] (Agent-Handler-3:null) Lost > connection to the server. Dealing with the remaining commands.. > Please see the lib virtd log at same time (please see the attached complete > log, there is a 5 hour difference in agent log and libvirt log ) > 2013-12-10 02:45:45.563+: 5938: error : qemuMonitorIO:574 : internal > error End of file from monitor > 2013-12-10 02:45:47.663+: 5942: error : virCommandWait:2308 : internal > error Child process (/bin/umount /mnt/41b632b5-40b3-3024-a38b-ea259c72579f) > status unexpected: exit status 16 > 2013-12-10 02:45:53.925+: 5943: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet14 root) status unexpected: > exit status 2 > 2013-12-10 02:45:53.929+: 5943: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet14 ingress) status > unexpected: exit status 2 > 2013-12-10 02:45:54.011+: 5943: warning : qemuDomainObjTaint:1297 : > Domain id=71 name='i-45-97-QA' uuid=7717ba08-be84-4b63-a674-1534f9dc7bef is > tainted: high-privileges > 2013-12-10 02:46:33.070+: 5940: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet12 root) status unexpected: > exit status 2 > 2013-12-10 02:46:33.081+: 5940: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet12 ingress) status > unexpected: exit status 2 > 2013-12-10 02:46:33.197+: 5940: warning : qemuDomainObjTaint:1297 : > Domain id=72 name='i-47-111-QA' uuid=7fcce58a-96dc-4207-9998-b8fb72b446ac is > tainted: high-privileges > 2013-12-10 02:46:36.394+: 5938: error : qemuMonitorIO:574 : internal > error End of file from monitor > 2013-12-10 02:46:37.685+: 5940: error : virCommandWait:2308 : internal > error Child process (/bin/umount /mnt/41b632b5-40b3-3024-a38b-ea259c72579f) > status unexpected: exit status 16 > 2013-12-10 02:46:57.869+: 5940: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet15 root) status unexpected: > exit status 2 > 2013-12-10 02:46:57.873+: 5940: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet15 ingress) status > unexpected: exit status 2 > 2013-12-10 02:46:57.925+: 5940: error : virCommandWait:2308 :
[jira] [Commented] (CLOUDSTACK-5432) [Automation] Libvtd getting crashed and agent going to alert start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867365#comment-13867365 ] Rayees Namathponnan commented on CLOUDSTACK-5432: - execute.in.sequence.hypervisor.commands = false already > [Automation] Libvtd getting crashed and agent going to alert start > --- > > Key: CLOUDSTACK-5432 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5432 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.3.0 > Environment: KVM (RHEL 6.3) > Branch : 4.3 >Reporter: Rayees Namathponnan >Assignee: Marcus Sorensen >Priority: Blocker > Fix For: 4.3.0 > > Attachments: CLOUDSTACK-5432_Jan_06.rar, KVM_Automation_Dec_11.rar, > agent1.rar, agent2.rar, management-server.rar > > > This issue is observed in 4.3 automation environment; libvirt crashed and > cloudstack agent went to alert start; > Please see the agent log; connection between agent and MS lost with error > "Connection closed with -1 on reading size." @ 2013-12-09 19:47:06,969 > 2013-12-09 19:43:41,495 DEBUG [cloud.agent.Agent] > (agentRequest-Handler-2:null) Processing command: > com.cloud.agent.api.GetStorageStatsCommand > 2013-12-09 19:47:06,969 DEBUG [utils.nio.NioConnection] (Agent-Selector:null) > Location 1: Socket Socket[addr=/10.223.49.195,port=8250,localport=40801] > closed on read. Probably -1 returned: Connection closed with -1 on reading > size. > 2013-12-09 19:47:06,969 DEBUG [utils.nio.NioConnection] (Agent-Selector:null) > Closing socket Socket[addr=/10.223.49.195,port=8250,localport=40801] > 2013-12-09 19:47:06,969 DEBUG [cloud.agent.Agent] (Agent-Handler-3:null) > Clearing watch list: 2 > 2013-12-09 19:47:11,969 INFO [cloud.agent.Agent] (Agent-Handler-3:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-09 19:47:11,970 INFO [cloud.agent.Agent] (Agent-Handler-3:null) > Cannot connect because we still have 5 commands in progress. > 2013-12-09 19:47:16,970 INFO [cloud.agent.Agent] (Agent-Handler-3:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-09 19:47:16,990 INFO [cloud.agent.Agent] (Agent-Handler-3:null) > Cannot connect because we still have 5 commands in progress. > 2013-12-09 19:47:21,990 INFO [cloud.agent.Agent] (Agent-Handler-3:null) Lost > connection to the server. Dealing with the remaining commands.. > Please see the lib virtd log at same time (please see the attached complete > log, there is a 5 hour difference in agent log and libvirt log ) > 2013-12-10 02:45:45.563+: 5938: error : qemuMonitorIO:574 : internal > error End of file from monitor > 2013-12-10 02:45:47.663+: 5942: error : virCommandWait:2308 : internal > error Child process (/bin/umount /mnt/41b632b5-40b3-3024-a38b-ea259c72579f) > status unexpected: exit status 16 > 2013-12-10 02:45:53.925+: 5943: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet14 root) status unexpected: > exit status 2 > 2013-12-10 02:45:53.929+: 5943: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet14 ingress) status > unexpected: exit status 2 > 2013-12-10 02:45:54.011+: 5943: warning : qemuDomainObjTaint:1297 : > Domain id=71 name='i-45-97-QA' uuid=7717ba08-be84-4b63-a674-1534f9dc7bef is > tainted: high-privileges > 2013-12-10 02:46:33.070+: 5940: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet12 root) status unexpected: > exit status 2 > 2013-12-10 02:46:33.081+: 5940: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet12 ingress) status > unexpected: exit status 2 > 2013-12-10 02:46:33.197+: 5940: warning : qemuDomainObjTaint:1297 : > Domain id=72 name='i-47-111-QA' uuid=7fcce58a-96dc-4207-9998-b8fb72b446ac is > tainted: high-privileges > 2013-12-10 02:46:36.394+: 5938: error : qemuMonitorIO:574 : internal > error End of file from monitor > 2013-12-10 02:46:37.685+: 5940: error : virCommandWait:2308 : internal > error Child process (/bin/umount /mnt/41b632b5-40b3-3024-a38b-ea259c72579f) > status unexpected: exit status 16 > 2013-12-10 02:46:57.869+: 5940: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet15 root) status unexpected: > exit status 2 > 2013-12-10 02:46:57.873+: 5940: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet15 ingress) status > unexpected: exit status 2 > 2013-12-10 02:46:57.925+: 5940: error : virCommandWait:2308 : in
[jira] [Commented] (CLOUDSTACK-5432) [Automation] Libvtd getting crashed and agent going to alert start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867361#comment-13867361 ] edison su commented on CLOUDSTACK-5432: --- can we disable execute.in.sequence.hypervisor.commands, which may cause libvirt hang? > [Automation] Libvtd getting crashed and agent going to alert start > --- > > Key: CLOUDSTACK-5432 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5432 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.3.0 > Environment: KVM (RHEL 6.3) > Branch : 4.3 >Reporter: Rayees Namathponnan >Assignee: Marcus Sorensen >Priority: Blocker > Fix For: 4.3.0 > > Attachments: CLOUDSTACK-5432_Jan_06.rar, KVM_Automation_Dec_11.rar, > agent1.rar, agent2.rar, management-server.rar > > > This issue is observed in 4.3 automation environment; libvirt crashed and > cloudstack agent went to alert start; > Please see the agent log; connection between agent and MS lost with error > "Connection closed with -1 on reading size." @ 2013-12-09 19:47:06,969 > 2013-12-09 19:43:41,495 DEBUG [cloud.agent.Agent] > (agentRequest-Handler-2:null) Processing command: > com.cloud.agent.api.GetStorageStatsCommand > 2013-12-09 19:47:06,969 DEBUG [utils.nio.NioConnection] (Agent-Selector:null) > Location 1: Socket Socket[addr=/10.223.49.195,port=8250,localport=40801] > closed on read. Probably -1 returned: Connection closed with -1 on reading > size. > 2013-12-09 19:47:06,969 DEBUG [utils.nio.NioConnection] (Agent-Selector:null) > Closing socket Socket[addr=/10.223.49.195,port=8250,localport=40801] > 2013-12-09 19:47:06,969 DEBUG [cloud.agent.Agent] (Agent-Handler-3:null) > Clearing watch list: 2 > 2013-12-09 19:47:11,969 INFO [cloud.agent.Agent] (Agent-Handler-3:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-09 19:47:11,970 INFO [cloud.agent.Agent] (Agent-Handler-3:null) > Cannot connect because we still have 5 commands in progress. > 2013-12-09 19:47:16,970 INFO [cloud.agent.Agent] (Agent-Handler-3:null) Lost > connection to the server. Dealing with the remaining commands... > 2013-12-09 19:47:16,990 INFO [cloud.agent.Agent] (Agent-Handler-3:null) > Cannot connect because we still have 5 commands in progress. > 2013-12-09 19:47:21,990 INFO [cloud.agent.Agent] (Agent-Handler-3:null) Lost > connection to the server. Dealing with the remaining commands.. > Please see the lib virtd log at same time (please see the attached complete > log, there is a 5 hour difference in agent log and libvirt log ) > 2013-12-10 02:45:45.563+: 5938: error : qemuMonitorIO:574 : internal > error End of file from monitor > 2013-12-10 02:45:47.663+: 5942: error : virCommandWait:2308 : internal > error Child process (/bin/umount /mnt/41b632b5-40b3-3024-a38b-ea259c72579f) > status unexpected: exit status 16 > 2013-12-10 02:45:53.925+: 5943: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet14 root) status unexpected: > exit status 2 > 2013-12-10 02:45:53.929+: 5943: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet14 ingress) status > unexpected: exit status 2 > 2013-12-10 02:45:54.011+: 5943: warning : qemuDomainObjTaint:1297 : > Domain id=71 name='i-45-97-QA' uuid=7717ba08-be84-4b63-a674-1534f9dc7bef is > tainted: high-privileges > 2013-12-10 02:46:33.070+: 5940: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet12 root) status unexpected: > exit status 2 > 2013-12-10 02:46:33.081+: 5940: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet12 ingress) status > unexpected: exit status 2 > 2013-12-10 02:46:33.197+: 5940: warning : qemuDomainObjTaint:1297 : > Domain id=72 name='i-47-111-QA' uuid=7fcce58a-96dc-4207-9998-b8fb72b446ac is > tainted: high-privileges > 2013-12-10 02:46:36.394+: 5938: error : qemuMonitorIO:574 : internal > error End of file from monitor > 2013-12-10 02:46:37.685+: 5940: error : virCommandWait:2308 : internal > error Child process (/bin/umount /mnt/41b632b5-40b3-3024-a38b-ea259c72579f) > status unexpected: exit status 16 > 2013-12-10 02:46:57.869+: 5940: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet15 root) status unexpected: > exit status 2 > 2013-12-10 02:46:57.873+: 5940: error : virCommandWait:2308 : internal > error Child process (/sbin/tc qdisc del dev vnet15 ingress) status > unexpected: exit status 2 > 2013-12-10 02:46:57.925+: 5940: error : virCommandWait
[jira] [Commented] (CLOUDSTACK-5653) S3 object store as Secondary Storage, the template created from different zone is not available for the other zones.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867332#comment-13867332 ] ASF subversion and git services commented on CLOUDSTACK-5653: - Commit 9f03150a4ff4269ef992b8271c2e30eb23802e8f in branch refs/heads/4.2 from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9f03150 ] CLOUDSTACK-5653:S3 object store as Secondary Storage, the template created from different zone is not available for the other zones. > S3 object store as Secondary Storage, the template created from different > zone is not available for the other zones. > - > > Key: CLOUDSTACK-5653 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5653 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.3.0 > > > Here are reproducible steps: > 1. Use S3 as secondary storage on a multi-zone environment. > 2. Create a template from snapshot in a specific zone. > 3. The created template cannot be used for another zone (cannot deploy a VM > using the created template). > It can only be used in the zone where it was created. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5656) UI shows PF,LB,firewall,static NAT rule operations success on non upgraded VR but logs show VR requires upgrade.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867322#comment-13867322
]
Jessica Wang commented on CLOUDSTACK-5656:
--
Kishan,
I just added "State" column (as in my attached screenshot
"2014-01-09_PortForwarding_newColumnState")
Jessica
> UI shows PF,LB,firewall,static NAT rule operations success on non upgraded VR
> but logs show VR requires upgrade.
>
>
> Key: CLOUDSTACK-5656
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5656
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.3.0
> Environment: 2.2.14 to 4.3 upgrade
>Reporter: manasaveloori
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: 2014-01-09_PortForwarding_newColumnState.PNG
>
>
> 1. Have CS 2.2.14 with xen 5.6sp2.
> 2.Deploy some VRS.
> 3. Upgrade to 4.3.
> 4. Perform any operation which sends commands to non upgraded VR like
> applying static nat,firewall rules,PF etc.
> Observation:
> UI shows all the operations as success but in logs we can see the messages as
> 2013-12-27 15:04:31,326 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-12:ctx-c0ac9a16 ctx-ed5f06a6) ===END=== 10.252.192.34 -- GET
> command=createFirewallRule&response=json&sessionkey=DE4U5L%2FWnxa60eF2LoJPuY6FVHw%3D&cidrlist=0.0.0.0%2F0&protocol=tcp&startport=1&endport=65535&ipaddressid=4&_=1388136871014
> 2013-12-27 15:04:31,354 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Applying ip association in
> network Ntwk[205|Guest|6]
> 2013-12-27 15:04:31,354 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Router r-6-VM requires upgrade,
> so not sending apply ip association commands to the backend
> 2013-12-27 15:04:31,362 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Applying firewall rules in
> network Ntwk[205|Guest|6]
> 2013-12-27 15:04:31,363 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Router r-6-VM requires upgrade,
> so not sending apply firewall rules commands to the backend
> 2013-12-27 15:04:31,430 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Complete async job-24, jobStatus:
> SUCCEEDED, resultCode: 0, result:
> org.apache.cloudstack.api.response.FirewallResponse/firewallrule/{"id":"b772c804-09cc-4eaa-96a3-61adcf1cb242","protocol":"tcp","startport":"1","endport":"65535","ipaddressid":"4","networkid":"205","ipaddress":"10.147.47.6","state":"Active","cidrlist":"","tags":[]}
> 2013-12-27 15:04:31,483 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5) Done executing
> org.apache.cloudstack.api.command.user.firewall.CreateFirewallRuleCmd for
> job-24
> UI shoul aslo show the message as " Router requires upgrade" and the action
> should fail.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5656) UI shows PF,LB,firewall,static NAT rule operations success on non upgraded VR but logs show VR requires upgrade.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jessica Wang updated CLOUDSTACK-5656:
-
Attachment: 2014-01-09_PortForwarding_newColumnState.PNG
> UI shows PF,LB,firewall,static NAT rule operations success on non upgraded VR
> but logs show VR requires upgrade.
>
>
> Key: CLOUDSTACK-5656
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5656
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.3.0
> Environment: 2.2.14 to 4.3 upgrade
>Reporter: manasaveloori
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: 2014-01-09_PortForwarding_newColumnState.PNG
>
>
> 1. Have CS 2.2.14 with xen 5.6sp2.
> 2.Deploy some VRS.
> 3. Upgrade to 4.3.
> 4. Perform any operation which sends commands to non upgraded VR like
> applying static nat,firewall rules,PF etc.
> Observation:
> UI shows all the operations as success but in logs we can see the messages as
> 2013-12-27 15:04:31,326 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-12:ctx-c0ac9a16 ctx-ed5f06a6) ===END=== 10.252.192.34 -- GET
> command=createFirewallRule&response=json&sessionkey=DE4U5L%2FWnxa60eF2LoJPuY6FVHw%3D&cidrlist=0.0.0.0%2F0&protocol=tcp&startport=1&endport=65535&ipaddressid=4&_=1388136871014
> 2013-12-27 15:04:31,354 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Applying ip association in
> network Ntwk[205|Guest|6]
> 2013-12-27 15:04:31,354 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Router r-6-VM requires upgrade,
> so not sending apply ip association commands to the backend
> 2013-12-27 15:04:31,362 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Applying firewall rules in
> network Ntwk[205|Guest|6]
> 2013-12-27 15:04:31,363 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Router r-6-VM requires upgrade,
> so not sending apply firewall rules commands to the backend
> 2013-12-27 15:04:31,430 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Complete async job-24, jobStatus:
> SUCCEEDED, resultCode: 0, result:
> org.apache.cloudstack.api.response.FirewallResponse/firewallrule/{"id":"b772c804-09cc-4eaa-96a3-61adcf1cb242","protocol":"tcp","startport":"1","endport":"65535","ipaddressid":"4","networkid":"205","ipaddress":"10.147.47.6","state":"Active","cidrlist":"","tags":[]}
> 2013-12-27 15:04:31,483 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5) Done executing
> org.apache.cloudstack.api.command.user.firewall.CreateFirewallRuleCmd for
> job-24
> UI shoul aslo show the message as " Router requires upgrade" and the action
> should fail.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5656) UI shows PF,LB,firewall,static NAT rule operations success on non upgraded VR but logs show VR requires upgrade.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867320#comment-13867320
]
ASF subversion and git services commented on CLOUDSTACK-5656:
-
Commit d758996b711458ae1442ebf72a926ec66bdc915f in branch refs/heads/4.3 from
[~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d758996 ]
CLOUDSTACK-5656: UI > network > IP Address > configuration tab > Port
Forwarding > add "State" column.
> UI shows PF,LB,firewall,static NAT rule operations success on non upgraded VR
> but logs show VR requires upgrade.
>
>
> Key: CLOUDSTACK-5656
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5656
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.3.0
> Environment: 2.2.14 to 4.3 upgrade
>Reporter: manasaveloori
>Assignee: Kishan Kavala
>Priority: Critical
> Fix For: 4.3.0
>
>
> 1. Have CS 2.2.14 with xen 5.6sp2.
> 2.Deploy some VRS.
> 3. Upgrade to 4.3.
> 4. Perform any operation which sends commands to non upgraded VR like
> applying static nat,firewall rules,PF etc.
> Observation:
> UI shows all the operations as success but in logs we can see the messages as
> 2013-12-27 15:04:31,326 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-12:ctx-c0ac9a16 ctx-ed5f06a6) ===END=== 10.252.192.34 -- GET
> command=createFirewallRule&response=json&sessionkey=DE4U5L%2FWnxa60eF2LoJPuY6FVHw%3D&cidrlist=0.0.0.0%2F0&protocol=tcp&startport=1&endport=65535&ipaddressid=4&_=1388136871014
> 2013-12-27 15:04:31,354 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Applying ip association in
> network Ntwk[205|Guest|6]
> 2013-12-27 15:04:31,354 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Router r-6-VM requires upgrade,
> so not sending apply ip association commands to the backend
> 2013-12-27 15:04:31,362 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Applying firewall rules in
> network Ntwk[205|Guest|6]
> 2013-12-27 15:04:31,363 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Router r-6-VM requires upgrade,
> so not sending apply firewall rules commands to the backend
> 2013-12-27 15:04:31,430 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5 ctx-ed5f06a6) Complete async job-24, jobStatus:
> SUCCEEDED, resultCode: 0, result:
> org.apache.cloudstack.api.response.FirewallResponse/firewallrule/{"id":"b772c804-09cc-4eaa-96a3-61adcf1cb242","protocol":"tcp","startport":"1","endport":"65535","ipaddressid":"4","networkid":"205","ipaddress":"10.147.47.6","state":"Active","cidrlist":"","tags":[]}
> 2013-12-27 15:04:31,483 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-18:ctx-0bb79ed5) Done executing
> org.apache.cloudstack.api.command.user.firewall.CreateFirewallRuleCmd for
> job-24
> UI shoul aslo show the message as " Router requires upgrade" and the action
> should fail.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5502) [Automation] createVlanIpRange API failing, if you pass VLAN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867303#comment-13867303
]
Animesh Chaturvedi commented on CLOUDSTACK-5502:
Daan,
Please review Marcus's comment we should continue with the old behavior.
Thanks
Animesh
> [Automation] createVlanIpRange API failing, if you pass VLAN
> -
>
> Key: CLOUDSTACK-5502
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5502
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
> Environment: KVM Basic Zone with SG
>Reporter: Rayees Namathponnan
>Assignee: Daan Hoogland
>Priority: Blocker
> Fix For: 4.3.0
>
>
> This issue found in KVM basic zone with SG automation run; test cases from
> below suite filed
> integration.component.test_multiple_ip_ranges.
> Steps to reproduce
> Step 1 : Create basic zone with SG
> Step 2 : Crete IP VLAN Range with below command (pass vlan=untagged)
> http://xxx..xxx.xxx:8096/?command=createVlanIpRange&gateway=10.223.251.1&forvirtualnetwork=false&startip=10.223.251.3&podid=0253bcbf-e636-4776-9e8c-216b70d195a2&zoneid=a9912aa8-a231-44d9-a70b-9d53e6db2d27&netmask=255.255.255.192&vlan=untagged
> Result;
> API command failed with error
> { "createvlaniprangeresponse" :
> {"uuidList":[],"errorcode":431,"cserrorcode":4350,"errortext":"Vlan doesn't
> match vlan of the network"} }
> this API command works only, if you are not passing any VLAN
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5849) Failed to shutdown the network when corresponding External LB provider gets Disabled while still in use by the network
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5849:
---
Assignee: Murali Reddy (was: Alena Prokharchyk)
> Failed to shutdown the network when corresponding External LB provider gets
> Disabled while still in use by the network
> --
>
> Key: CLOUDSTACK-5849
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5849
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller, Network Devices
>Affects Versions: 4.3.0
> Environment: upgraded from 3.0.6 patch E to 4.3
>Reporter: manasaveloori
>Assignee: Murali Reddy
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: management-server306.log.rar, management-server4.3.rar,
> mysqldump306PatchE.dmp, mysqldump4.3.dmp
>
>
> Steps:
> 1. Deployed CS 3.0.6 Patch E with Xen 6.0.2 HV.
> 2. Created the service offering for netscaler device.
> 3. Added incompatible version of Netscaler. added NS10.1: Build 120.1316
> to CS 3.0.6 build.
> it was success.
> 4. Now created the network using the service offering created in step 2.
> 5. Observed that the network went into shut down state as the netscaler
> failed to implement the network.
> 6. Removed the netscaler device from CS and disabled the service offering.
> 7. Now there were no VMs associated to that network.Tried to delete the
> network.But it failed as the network was not in correct state.
> Note: issue existed in 3.0.6 that network is not deleted if it is in shutdown
> state.
> 2014-01-07 21:32:09,720 DEBUG [agent.manager.AgentManagerImpl]
> (RouterMonitor-1:null) Details from executing class
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-01-07 21:32:09,720 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null)
> Recieved and Sent bytes are both 0. Not updating user_statistics
> 2014-01-07 21:32:11,498 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-5:null) Ping from 8
> 2014-01-07 21:32:11,917 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-6:null) Ping from 5
> 2014-01-07 21:32:12,164 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-19:null) submit async job-75, job: AsyncJobVO {id:75, userId:
> 2, accountId: 2, sessionKey: null, instanceType: null, instanceId: null, cmd:
> com.cloud.api.commands.DeleteNetworkCmd, cmdOriginator: null, cmdVersion: 0,
> callbackType: 0, callbackAddress: null, status: 0, processStatus: 0,
> resultCode: 0, result: null, initMsid: 6642334695485, completeMsid: null,
> lastUpdated: null, lastPolled: null, created: null}
> 2014-01-07 21:32:12,169 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Executing com.cloud.api.commands.DeleteNetworkCmd
> for job-75
> 2014-01-07 21:32:12,179 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Sync job-75 execution on object network.216
> 2014-01-07 21:32:12,188 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) job com.cloud.api.commands.DeleteNetworkCmd for
> job-75 was queued, processing the queue.
> 2014-01-07 21:32:12,197 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Executing sync queue item: SyncQueueItemVO {id:17,
> queueId: 17, contentType: AsyncJob, contentId: 75, lastProcessMsid:
> 6642334695485, lastprocessNumber: 1, lastProcessTime: Tue Jan 07 21:32:12 IST
> 2014, created: Tue Jan 07 21:32:12 IST 2014}
> 2014-01-07 21:32:12,199 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Schedule queued job-75
> 2014-01-07 21:32:12,207 DEBUG [cloud.async.SyncQueueManagerImpl]
> (Job-Executor-69:job-75) There is a pending process in sync queue(id: 17)
> 2014-01-07 21:32:12,210 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-70:job-75) Executing com.cloud.api.commands.DeleteNetworkCmd
> for job-75
> 2014-01-07 21:32:12,233 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-70:job-75) Network is not implemented: Ntwk[216|Guest|17]
> 2014-01-07 21:32:12,233 DEBUG [db.Transaction.Transaction]
> (Job-Executor-70:job-75) Rolling back the transaction: Time = 1 Name =
> -AsyncJobManagerImpl$1.run:396-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679;
> called by
> -Transaction.rollback:854-Transaction.removeUpTo:797-Transaction.close:621-DatabaseCallback.interceptComplete:67-DatabaseCallback.intercept:32-NetworkManagerImpl.destroyNetwork:3799-DatabaseCallback.intercept:30-NetworkManagerImpl.deleteNetwork:3656-ActionEventCallb
[jira] [Resolved] (CLOUDSTACK-5831) As regular user , when trying to take a snapshot , snapshot succeeds but user is presented with "The given command does not exist or it is not available for user" m
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su resolved CLOUDSTACK-5831.
---
Resolution: Fixed
> As regular user , when trying to take a snapshot , snapshot succeeds but user
> is presented with "The given command does not exist or it is not available
> for user" message.
> ---
>
> Key: CLOUDSTACK-5831
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5831
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.3.0
> Environment: Build from 4.3
>Reporter: Sangeetha Hariharan
>Assignee: edison su
> Fix For: 4.3.0
>
> Attachments: snapshot.png,
> the_checkin_that_causes_error_TheGivinCommandDoesNotExistOrItIsNotAvailableForUser.PNG
>
>
> As regular user , when trying to take a snapshot , snapshot succeeds but user
> is presented with "The given command does not exist or it is not available
> for user" message.
> As a regular user , deploy a VM.
> From storage list view , select ROOT volume and create a snapshot.
> On "Take Snapshot" notification pop up , click on "OK".
> Notice that you are presented withe following message:
> "The given command does not exist or it is not available for user"
> Following api call was made by the UI:
> http://10.223.49.5:8080/client/api?command=listStoragePools&id=undefined&response=json&sessionkey=4vcnR7sxOFnZcx6pUcyfnj%2BrN3o%3D&_=1389134167406
> { "errorresponse" :
> {"uuidList":[],"errorcode":432,"cserrorcode":,"errortext":"The given
> command does not exist or it is not available for user"} }
> This issue is not seen when testing as "Admin" user and happens only with
> regular users.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5819) extractTemplate fails with Vmware host on migration of NFS to S3
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867260#comment-13867260
]
ASF subversion and git services commented on CLOUDSTACK-5819:
-
Commit 64b8d1044d9e7759ebeebe86462740a4bcc019e2 in branch refs/heads/master
from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=64b8d10 ]
CLOUDSTACK-5819:extractTemplate fails with Vmware host on migration of
NFS to S3.
> extractTemplate fails with Vmware host on migration of NFS to S3
>
>
> Key: CLOUDSTACK-5819
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5819
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Template, VMware
>Affects Versions: 4.3.0
> Environment: Latest Management server 4.3
> Two zones one with Xen host and other with VmWare host
>Reporter: Pavan Kumar Bandarupally
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.3.0
>
>
> Trying to download a template created from snapshot of root volume or
> template of root volume after migration of NFS to S3 store throws an error.
> Job Trace:
> ==
> 2014-01-07 22:07:44,221 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-8:ctx-3c03896e) ===START=== 10.146.0.11 -- GET
> command=extractTemplate&mode=HTTP_DOWNLOAD&id=3e35e5f4-9067-4c6e-ba15-3eb80494a6e8&response=json&sessionkey=BGTkrKxSTvEyZG7Nx4tTVof99Tw%3D&_=1389093486904
> 2014-01-07 22:07:44,255 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-8:ctx-3c03896e ctx-f274cea7) submit async job-89, details:
> AsyncJobVO {id:89, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 203, cmd:
> org.apache.cloudstack.api.command.user.template.ExtractTemplateCmd, cmdInfo:
> {"response":"json","id":"3e35e5f4-9067-4c6e-ba15-3eb80494a6e8","sessionkey":"BGTkrKxSTvEyZG7Nx4tTVof99Tw\u003d","cmdEventType":"TEMPLATE.EXTRACT","ctxUserId":"2","httpmethod":"GET","_":"1389093486904","ctxAccountId":"2","ctxStartEventId":"176","mode":"HTTP_DOWNLOAD"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7337246982268, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-01-07 22:07:44,258 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-8:ctx-3c03896e ctx-f274cea7) ===END=== 10.146.0.11 -- GET
> command=extractTemplate&mode=HTTP_DOWNLOAD&id=3e35e5f4-9067-4c6e-ba15-3eb80494a6e8&response=json&sessionkey=BGTkrKxSTvEyZG7Nx4tTVof99Tw%3D&_=1389093486904
> 2014-01-07 22:07:44,262 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-37:ctx-b68520ba) Add job-89 into job monitoring
> 2014-01-07 22:07:44,262 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-37:ctx-b68520ba) Executing AsyncJobVO {id:89, userId: 2,
> accountId: 2, instanceType: Template, instanceId: 203, cmd:
> org.apache.cloudstack.api.command.user.template.ExtractTemplateCmd, cmdInfo:
> {"response":"json","id":"3e35e5f4-9067-4c6e-ba15-3eb80494a6e8","sessionkey":"BGTkrKxSTvEyZG7Nx4tTVof99Tw\u003d","cmdEventType":"TEMPLATE.EXTRACT","ctxUserId":"2","httpmethod":"GET","_":"1389093486904","ctxAccountId":"2","ctxStartEventId":"176","mode":"HTTP_DOWNLOAD"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7337246982268, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-01-07 22:07:44,290 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl]
> (Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in
> store:3, type:Image
> 2014-01-07 22:07:44,300 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl]
> (Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in
> store:1, type:ImageCache
> 2014-01-07 22:07:44,302 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl]
> (Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in
> store:3, type:Image
> 2014-01-07 22:07:44,325 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
> (Job-Executor-37:ctx-b68520ba ctx-f274cea7) copyAsync inspecting src type
> TEMPLATE copyAsync inspecting dest type TEMPLATE
> 2014-01-07 22:07:44,371 DEBUG [c.c.a.t.Request] (Job-Executor-37:ctx-b68520ba
> ctx-f274cea7) Seq 3-242024639: Sending { Cmd , MgmtId: 7337246982268, via:
> 3(s-1-VM), Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/2/203/288329c8b-bb60-325f-8da8-b7e0e9764f99.ova","uuid":"3e35e5f4-9067-4c6e-ba15-3eb80494a6e8","id":203,"format":"OVA","accountId":2,"hvm":true,"displayText":"tmplt
> from root vol on Vmware
> before","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/expor
[jira] [Updated] (CLOUDSTACK-5053) No Qemu-KVM module dependency error message is displayed (if not present)while installing KVM agent using ACS4.2 build
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-5053: Status: Ready To Review (was: In Progress) > No Qemu-KVM module dependency error message is displayed (if not > present)while installing KVM agent using ACS4.2 build > -- > > Key: CLOUDSTACK-5053 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5053 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.2.0 >Reporter: manasaveloori >Assignee: Rayees Namathponnan >Priority: Critical > Fix For: 4.3.0 > > > Install KVM agent as per the ACS doc. > Libvirtd will be installed as a part of agent installation.Qemu-kvm will > not get installed.so lsmod | grep kvm will not list kvm module .Also > /etc/sysconfig/modules will not list KVM_modules. > There is no dependency error/warning displayed while doing yum install > cloudstack-agent. > So the KVM host addition to CS fails. > Steps followed: > Did yum install kvm. > Now lsmod and /etc/sysconfig/modules will have kvm modules. > Now install cloudstack agent. > KVM host gets added to CS successfully. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Reopened] (CLOUDSTACK-5053) No Qemu-KVM module dependency error message is displayed (if not present)while installing KVM agent using ACS4.2 build
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan reopened CLOUDSTACK-5053: - > No Qemu-KVM module dependency error message is displayed (if not > present)while installing KVM agent using ACS4.2 build > -- > > Key: CLOUDSTACK-5053 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5053 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.2.0 >Reporter: manasaveloori >Assignee: Rayees Namathponnan >Priority: Critical > Fix For: 4.3.0 > > > Install KVM agent as per the ACS doc. > Libvirtd will be installed as a part of agent installation.Qemu-kvm will > not get installed.so lsmod | grep kvm will not list kvm module .Also > /etc/sysconfig/modules will not list KVM_modules. > There is no dependency error/warning displayed while doing yum install > cloudstack-agent. > So the KVM host addition to CS fails. > Steps followed: > Did yum install kvm. > Now lsmod and /etc/sysconfig/modules will have kvm modules. > Now install cloudstack agent. > KVM host gets added to CS successfully. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5053) No Qemu-KVM module dependency error message is displayed (if not present)while installing KVM agent using ACS4.2 build
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan resolved CLOUDSTACK-5053. - Resolution: Fixed https://reviews.apache.org/r/16774/ in review > No Qemu-KVM module dependency error message is displayed (if not > present)while installing KVM agent using ACS4.2 build > -- > > Key: CLOUDSTACK-5053 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5053 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Affects Versions: 4.2.0 >Reporter: manasaveloori >Assignee: Rayees Namathponnan >Priority: Critical > Fix For: 4.3.0 > > > Install KVM agent as per the ACS doc. > Libvirtd will be installed as a part of agent installation.Qemu-kvm will > not get installed.so lsmod | grep kvm will not list kvm module .Also > /etc/sysconfig/modules will not list KVM_modules. > There is no dependency error/warning displayed while doing yum install > cloudstack-agent. > So the KVM host addition to CS fails. > Steps followed: > Did yum install kvm. > Now lsmod and /etc/sysconfig/modules will have kvm modules. > Now install cloudstack agent. > KVM host gets added to CS successfully. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5492) Group by options in router pages always shows requiresupgrade as no
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jessica Wang resolved CLOUDSTACK-5492.
--
Resolution: Cannot Reproduce
shweta,
I'm unable to reproduce this bug from latest code of 4.3 branch.
If you are still able to reproduce it, please provide database dump or your URL.
It will be even better if you can provide both database dump and your URL.
thank you.
Jessica
> Group by options in router pages always shows requiresupgrade as no
> ---
>
> Key: CLOUDSTACK-5492
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5492
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.3.0
> Environment: on 4.3. upgraded setup in which router is not yet
> upgraded
> goto router page via infrastructure
> Select option group by zone/pod/cluster
> Notice Requires upgrade is shown as No
> API call
> http://10.147.40.27:8080/client/api?command=listRouters&response=json&sessionkey=lDWk06sWJovcFLDuw3MHaS00N4Q%3D&podid=a5d5234e-86d6-41f8-ac8c-5bdf24288231&listAll=true&page=1&pagesize=20&_=1386935114493
> Response returns requires upgrade field as true
> { "listroutersresponse" : { "count":9 ,"router" : [
> {"id":"3d05883f-3089-449a-84a2-bb7d758f1e82","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","gateway":"10.147.51.1","name":"r-19-VM","podid":"a5d5234e-86d6-41f8-ac8c-5bdf24288231","hostid":"90ac48de-eb48-4283-b2f9-1a6581a92fb6","hostname":"Rack1Pod1Host24","linklocalip":"169.254.1.123","linklocalmacaddress":"0e:00:a9:fe:01:7b","linklocalnetmask":"255.255.0.0","linklocalnetworkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","publicip":"10.147.51.21","publicmacaddress":"06:bd:38:00:00:20","publicnetmask":"255.255.255.0","publicnetworkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","templateid":"ce21f5d6-630f-11e3-9a2f-97407caff5c2","created":"2013-12-12T17:56:08+0530","state":"Running","account":"admin","domainid":"94814869-1330-42b9-8e74-77a407a3cd7e","domain":"child1","serviceofferingid":"72743e39-323d-4aba-9076-6c43b72252c1","serviceofferingname":"System
> Offering For Software
> Router","isredundantrouter":false,"redundantstate":"UNKNOWN","version":"3.0","vpcid":"07fcf168-3086-40c0-bd9b-eddb70396aaa","role":"VIRTUAL_ROUTER","nic":[{"id":"87f6bfb3-f993-4cc6-8332-4b25efd298a3","networkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","netmask":"255.255.0.0","gateway":"169.254.0.1","ipaddress":"169.254.1.123","traffictype":"Control","isdefault":false,"macaddress":"0e:00:a9:fe:01:7b"},{"id":"8066d1e0-ee16-4ade-898e-3a232efb8345","networkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","netmask":"255.255.255.0","gateway":"10.147.51.1","ipaddress":"10.147.51.21","isolationuri":"vlan://51","broadcasturi":"vlan://51","traffictype":"Public","isdefault":true,"macaddress":"06:bd:38:00:00:20"}],"requiresupgrade":true},
>
> {"id":"70c807c7-679c-41b0-8c93-a38a54d3a47c","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","networkdomain":"cs8cloud.internal","gateway":"10.147.51.1","name":"r-18-VM","podid":"a5d5234e-86d6-41f8-ac8c-5bdf24288231","linklocalnetworkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","publicip":"10.147.51.20","publicmacaddress":"06:bc:86:00:00:1f","publicnetmask":"255.255.255.0","publicnetworkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","guestipaddress":"10.1.1.1","guestmacaddress":"02:00:20:79:00:02","guestnetmask":"255.255.255.0","guestnetworkid":"29a643b3-cabb-4855-a967-38853c150f73","templateid":"ce21f5d6-630f-11e3-9a2f-97407caff5c2","created":"2013-12-12T17:55:43+0530","state":"Stopped","account":"admin","domainid":"94814869-1330-42b9-8e74-77a407a3cd7e","domain":"child1","serviceofferingid":"72743e39-323d-4aba-9076-6c43b72252c1","serviceofferingname":"System
> Offering For Software
> Router","isredundantrouter":false,"redundantstate":"UNKNOWN","version":"3.0","role":"VIRTUAL_ROUTER","nic":[{"id":"5d3917d6-7022-446e-981c-04b88307151f","networkid":"29a643b3-cabb-4855-a967-38853c150f73","networkname":"admin2","netmask":"255.255.255.0","ipaddress":"10.1.1.1","traffictype":"Guest","type":"Isolated","isdefault":false,"macaddress":"02:00:20:79:00:02"},{"id":"42a50f06-4e66-41cc-8c4a-1b76afd893f1","networkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","traffictype":"Control","isdefault":false},{"id":"d7fda58e-ff9e-4427-99d9-aca3d1d0bc49","networkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","netmask":"255.255.255.0","gateway":"10.147.51.1","ipaddress":"10.147.51.20","isolationuri":"vlan://51","broadcasturi":"vlan://51","traffictype":"Public","isdefault":true,"macaddress":"06:bc:86:00:00:1f"}],"requiresupgrade":true},
>
> {"id":"27e5c26c-5101-4b13-b8c0-666e7f0adf72","zoneid":"60e7f3ce-cb9c-4
[jira] [Commented] (CLOUDSTACK-5492) Group by options in router pages always shows requiresupgrade as no
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867232#comment-13867232
]
Jessica Wang commented on CLOUDSTACK-5492:
--
Kishan,
e.g. Group by zone:
for each zone, two API calls will be called. The first one without projectid,
the 2nd one with projectid=-1.
Because we need to count in project-related routers, that's what the 2nd
one(with projectid=-1) is for.
e.g. In my local environment (which has one zone), when clicking Group by Zone:
for zone (whose id is 6d83449c-e350-409d-91c6-c3dcc11f6b62), two API calls are
fired:
(1) without projectid:
http://10.215.3.26:8080/client/api?command=listRouters&response=json&sessionkey=ofdcvJgL8tiLmuFkd8SHIhpLya8%3D&listAll=true&pagesize=20&zoneid=6d83449c-e350-409d-91c6-c3dcc11f6b62&page=1&_=1389308261261
(2) with projectid = -1 :
http://10.215.3.26:8080/client/api?command=listRouters&response=json&sessionkey=ofdcvJgL8tiLmuFkd8SHIhpLya8%3D&listAll=true&pagesize=20&zoneid=6d83449c-e350-409d-91c6-c3dcc11f6b62&page=1&projectid=-1&_=1389308261402
Jessica
> Group by options in router pages always shows requiresupgrade as no
> ---
>
> Key: CLOUDSTACK-5492
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5492
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.3.0
> Environment: on 4.3. upgraded setup in which router is not yet
> upgraded
> goto router page via infrastructure
> Select option group by zone/pod/cluster
> Notice Requires upgrade is shown as No
> API call
> http://10.147.40.27:8080/client/api?command=listRouters&response=json&sessionkey=lDWk06sWJovcFLDuw3MHaS00N4Q%3D&podid=a5d5234e-86d6-41f8-ac8c-5bdf24288231&listAll=true&page=1&pagesize=20&_=1386935114493
> Response returns requires upgrade field as true
> { "listroutersresponse" : { "count":9 ,"router" : [
> {"id":"3d05883f-3089-449a-84a2-bb7d758f1e82","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","gateway":"10.147.51.1","name":"r-19-VM","podid":"a5d5234e-86d6-41f8-ac8c-5bdf24288231","hostid":"90ac48de-eb48-4283-b2f9-1a6581a92fb6","hostname":"Rack1Pod1Host24","linklocalip":"169.254.1.123","linklocalmacaddress":"0e:00:a9:fe:01:7b","linklocalnetmask":"255.255.0.0","linklocalnetworkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","publicip":"10.147.51.21","publicmacaddress":"06:bd:38:00:00:20","publicnetmask":"255.255.255.0","publicnetworkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","templateid":"ce21f5d6-630f-11e3-9a2f-97407caff5c2","created":"2013-12-12T17:56:08+0530","state":"Running","account":"admin","domainid":"94814869-1330-42b9-8e74-77a407a3cd7e","domain":"child1","serviceofferingid":"72743e39-323d-4aba-9076-6c43b72252c1","serviceofferingname":"System
> Offering For Software
> Router","isredundantrouter":false,"redundantstate":"UNKNOWN","version":"3.0","vpcid":"07fcf168-3086-40c0-bd9b-eddb70396aaa","role":"VIRTUAL_ROUTER","nic":[{"id":"87f6bfb3-f993-4cc6-8332-4b25efd298a3","networkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","netmask":"255.255.0.0","gateway":"169.254.0.1","ipaddress":"169.254.1.123","traffictype":"Control","isdefault":false,"macaddress":"0e:00:a9:fe:01:7b"},{"id":"8066d1e0-ee16-4ade-898e-3a232efb8345","networkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","netmask":"255.255.255.0","gateway":"10.147.51.1","ipaddress":"10.147.51.21","isolationuri":"vlan://51","broadcasturi":"vlan://51","traffictype":"Public","isdefault":true,"macaddress":"06:bd:38:00:00:20"}],"requiresupgrade":true},
>
> {"id":"70c807c7-679c-41b0-8c93-a38a54d3a47c","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","networkdomain":"cs8cloud.internal","gateway":"10.147.51.1","name":"r-18-VM","podid":"a5d5234e-86d6-41f8-ac8c-5bdf24288231","linklocalnetworkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","publicip":"10.147.51.20","publicmacaddress":"06:bc:86:00:00:1f","publicnetmask":"255.255.255.0","publicnetworkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","guestipaddress":"10.1.1.1","guestmacaddress":"02:00:20:79:00:02","guestnetmask":"255.255.255.0","guestnetworkid":"29a643b3-cabb-4855-a967-38853c150f73","templateid":"ce21f5d6-630f-11e3-9a2f-97407caff5c2","created":"2013-12-12T17:55:43+0530","state":"Stopped","account":"admin","domainid":"94814869-1330-42b9-8e74-77a407a3cd7e","domain":"child1","serviceofferingid":"72743e39-323d-4aba-9076-6c43b72252c1","serviceofferingname":"System
> Offering For Software
> Router","isredundantrouter":false,"redundantstate":"UNKNOWN","version":"3.0","role":"VIRTUAL_ROUTER","nic":[{"id":"5d3917d6-7022-446e-981c-04b88307151f","networkid":"29a643b3-cabb-4855-a967-38853c150f73","networkname":"admin2","netmask":"255.255.25
[jira] [Commented] (CLOUDSTACK-5557) [UI] Invalid UI for Network->Guest Network->.Able to see all configuration(FW/PF/LB)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867227#comment-13867227 ] ASF subversion and git services commented on CLOUDSTACK-5557: - Commit d11560d27b2f41320d644c4dca3b98e632667621 in branch refs/heads/4.3 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d11560d ] CLOUDSTACK-5557: UI > Network > Guest Network > IP Address > fix a bug that SourceNAT IP, VPC tier IP wrongly showed Configuration tab(firewall/portforwarding/loadbalancing). SourceNAT IP, VPC tier IP should not show Configuration tab(firewall/portforwarding/loadbalancing). > [UI] Invalid UI for Network->Guest Network->.Able to see all > configuration(FW/PF/LB) > --- > > Key: CLOUDSTACK-5557 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5557 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: manasaveloori >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.3.0 > > Attachments: VPCTierNW.jpg, management-server.log > > > Steps: > 1. Create a VPC. > 2. Create a tier network and VM using that network. > 3. Acquire IP and enable PF/LB rule. > Obseravation: > Under Network->GuestNetworks->Click on VPC tier network->IPaddresses. > Able to view the IP address and all the configurable items in > UI(firewall,PF,LB)like for normal networks. > Also user is allowed to configure the rules which results in exception > Attaching the SC -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5557) [UI] Invalid UI for Network->Guest Network->.Able to see all configuration(FW/PF/LB)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-5557. -- Resolution: Fixed > [UI] Invalid UI for Network->Guest Network->.Able to see all > configuration(FW/PF/LB) > --- > > Key: CLOUDSTACK-5557 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5557 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: manasaveloori >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.3.0 > > Attachments: VPCTierNW.jpg, management-server.log > > > Steps: > 1. Create a VPC. > 2. Create a tier network and VM using that network. > 3. Acquire IP and enable PF/LB rule. > Obseravation: > Under Network->GuestNetworks->Click on VPC tier network->IPaddresses. > Able to view the IP address and all the configurable items in > UI(firewall,PF,LB)like for normal networks. > Also user is allowed to configure the rules which results in exception > Attaching the SC -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-4810) Enable hypervisor snapshots for CloudStack-managed storage (for XenServer and VMware)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867212#comment-13867212 ] ASF subversion and git services commented on CLOUDSTACK-4810: - Commit 8b6e89c012a3ca4dfe4a4b25bd77b1b463a501a2 in branch refs/heads/master from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8b6e89c ] Merge from 4.3: CLOUDSTACK-4810: Enable hypervisor snapshots for CloudStack-managed storage (for XenServer and VMware) > Enable hypervisor snapshots for CloudStack-managed storage (for XenServer and > VMware) > - > > Key: CLOUDSTACK-4810 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4810 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 > Environment: Ubuntu 12.04 >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.3.0 > > > CloudStack-managed storage was introduced into CloudStack with the new > storage framework in 4.2. > This allows CloudStack to create and delete storage repositories and > datastores as needed. > For 4.2 the VDI inside of an SR takes up almost as much space as is available > in the SR (so there is a one-to-one mapping between an SR and a VDI). This is > the same idea for datastores and VMDKs. > The SR or datastore should be sized larger than its VDI or VMDK so there is > space available for hypervisor snapshots that get stored on the same SR or > datastore. > How much larger can be determined by a cluster-level setting. > For example, if you want a 10 GB CloudStack volume, the storage plug-in in > question can create, say, a 20 GB volume on its SAN. 10 GB to be used for the > CloudStack volume and an additional 10 GB for hypervisor snapshots. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5840) Migration from NFS to S3 should be done in one API instead of two APIs.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867199#comment-13867199 ] ASF subversion and git services commented on CLOUDSTACK-5840: - Commit 277b93c19cb315a1c2126bf9d3f7a4385fb359ea in branch refs/heads/4.3 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=277b93c ] CLOUDSTACK-5840: UI > Snapshots > create volume from snapshot dialog > add zone dropdown if region-wide secondary storage exists. > Migration from NFS to S3 should be done in one API instead of two APIs. > --- > > Key: CLOUDSTACK-5840 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5840 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.3.0 >Reporter: Min Chen >Assignee: Min Chen >Priority: Critical > Fix For: 4.3.0 > > > Currently to migrate NFS to use S3, admin needs to invoke two separate APIs > in sequence: > 1. For each NFS secondary storage, invoke prepareSecondaryStorageForMigration > to convert it to NFS staging store. > 2. Add a S3 image store. > These two steps are independent and not atomic. This process should be done > in one-step. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5725) VMSync: Management Server Logs do not have information pertaining to API Job to Work Job Relation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867193#comment-13867193 ] ASF subversion and git services commented on CLOUDSTACK-5725: - Commit 87381d42364d4b2ea0c78e1cf46ace9aa8ef2e8a in branch refs/heads/master from [~kelveny] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=87381d4 ] CLOUDSTACK-5725: put origin flow context id into log4j context prefix to link jobs with the orchestration work flow in logging > VMSync: Management Server Logs do not have information pertaining to API Job > to Work Job Relation > - > > Key: CLOUDSTACK-5725 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5725 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 >Reporter: Chandan Purushothama >Assignee: Kelven Yang > Fix For: 4.3.0 > > > Currently a VM related API Job is dependent on multiple work jobs for the API > job completion. The logs do not have any information pertaining to the > dependency of API and Work Job. This confuses the User to track the job on > the management server logs. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5765) [Automation] scale vm failed with error "Unable to serialize"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867197#comment-13867197 ] ASF subversion and git services commented on CLOUDSTACK-5765: - Commit 1e2e1ea0515178d40efc536dfa3328de4b8d48e1 in branch refs/heads/master from [~kelveny] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1e2e1ea ] CLOUDSTACK-5765: cleanup internal serialization and exception propagation issues > [Automation] scale vm failed with error "Unable to serialize" > - > > Key: CLOUDSTACK-5765 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5765 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: XS > Branch 4.3 >Reporter: Srikanteswararao Talluri >Assignee: Kelven Yang >Priority: Blocker > Fix For: 4.4.0 > > > Steps to reproduce > Step 1 : Create advanced zone in KVM or vmware > Step 2 : Deploy a VM > Step 3: scale virtualmachine to a bigger service offering > 2014-01-04 01:00:43,340 DEBUG [c.c.u.d.T.Transaction] > (Job-Executor-135:ctx-a364eef5 ctx-4ed77a9a) Rolling back the transaction: > Time = 20 Name = Job-Executor-135; called by > -TransactionLegacy.rollback:896-TransactionLegacy.removeUpTo:839-TransactionLegacy.close:663-Transaction.execute:41-Transaction.execute:46-VirtualMachineManagerImpl.migrateVmForScaleThroughJobQueue:4426-VirtualMachineManagerImpl.migrateForScale:3466-VirtualMachineManagerImpl.findHostAndMigrate:3448-UserVmManagerImpl.upgradeRunningVirtualMachine:1397-UserVmManagerImpl.upgradeVirtualMachine:1298-UserVmManagerImpl.upgradeVirtualMachine:1234-NativeMethodAccessorImpl.invoke0:-2 > 2014-01-04 01:00:43,343 WARN [c.c.v.UserVmManagerImpl] > (Job-Executor-135:ctx-a364eef5 ctx-4ed77a9a) Received exception while scaling > com.cloud.utils.exception.CloudRuntimeException: Unable to serialize: > com.cloud.vm.VmWorkMigrateForScale@3ea6dcee > at > org.apache.cloudstack.framework.jobs.impl.JobSerializerHelper.toObjectSerializedString(JobSerializerHelper.java:118) > at com.cloud.vm.VmWorkSerializer.serialize(VmWorkSerializer.java:63) > at > com.cloud.vm.VirtualMachineManagerImpl$8.doInTransactionWithoutResult(VirtualMachineManagerImpl.java:4455) > at > com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25) > at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49) > at com.cloud.utils.db.Transaction.execute(Transaction.java:37) > at com.cloud.utils.db.Transaction.execute(Transaction.java:46) > at > com.cloud.vm.VirtualMachineManagerImpl.migrateVmForScaleThroughJobQueue(VirtualMachineManagerImpl.java:4426) > at > com.cloud.vm.VirtualMachineManagerImpl.migrateForScale(VirtualMachineManagerImpl.java:3466) > at > com.cloud.vm.VirtualMachineManagerImpl.findHostAndMigrate(VirtualMachineManagerImpl.java:3448) > at > com.cloud.vm.UserVmManagerImpl.upgradeRunningVirtualMachine(UserVmManagerImpl.java:1397) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1298) > at > com.cloud.vm.UserVmManagerImpl.upgradeVirtualMachine(UserVmManagerImpl.java:1234) > 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:616) > 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 > com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) > 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 $Proxy169.upgradeVirtualMachine(Unknown Source) > at > org.apache.cloudstack.api.command.user.vm.ScaleVMCmd.execute(ScaleVMCmd.java:128) > at com.cloud.api.ApiDispat
[jira] [Commented] (CLOUDSTACK-5672) [Automation]Failed to add new nic to vm; error "Unable to serialize" observed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867194#comment-13867194
]
ASF subversion and git services commented on CLOUDSTACK-5672:
-
Commit 0965adb003905fa56dd642f48c632acae4b2c4fc in branch refs/heads/master
from [~kelveny]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0965adb ]
CLOUDSTACK-5672: Fix VM work job serialization issues in Add/Remove nic
> [Automation]Failed to add new nic to vm; error "Unable to serialize"
> observed
> ---
>
> Key: CLOUDSTACK-5672
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5672
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server, Network Controller
>Affects Versions: 4.3.0
> Environment: branch 4.3
>Reporter: Rayees Namathponnan
>Assignee: Kelven Yang
>Priority: Blocker
> Fix For: 4.3.0
>
>
> Steps to reproduce
> Step 1 : Create advanced zone
> Step 2 : Depoy and vm VM-QA1
> Step 3 : Create new network
> Step 4 : Add new nic to VM-QA1
> Result
> Failed to add new nic to the vm, below error observed
> nstanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.vm.AddNicToVMCmd, cmdInfo:
> {"response":"json","sessionkey":"ZZ4QXAUZwIPe83MSDipOFbHVpwo\u003d","virtualmachineid":"751ac91a-9a63-4d75-9700-70e269b539a4","cmdEventType":"NIC.CREATE","ctxUserId":"2","httpmethod":"GET","_":"1388332341748","ctxAccountId":"2","networkid":"ac35a773-08d1-4f55-9a57-bf0b78111698","ctxStartEventId":"16101"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 29066118877352, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2013-12-29 07:49:06,291 DEBUG [c.c.u.d.T.Transaction]
> (Job-Executor-29:ctx-f5b59752 ctx-fbfc6d7f) Rolling back the transaction:
> Time = 91 Name = Job-Executor-29; called by
> -TransactionLegacy.rollback:896-TransactionLegacy.removeUpTo:839-TransactionLegacy.close:663-Transaction.execute:41-Transaction.execute:46-VirtualMachineManagerImpl.addVmToNetworkThroughJobQueue:4525-VirtualMachineManagerImpl.addVmToNetwork:3112-UserVmManagerImpl.addNicToVirtualMachine:1038-GeneratedMethodAccessor813.invoke:-1-DelegatingMethodAccessorImpl.invoke:43-Method.invoke:616-AopUtils.invokeJoinpointUsingReflection:317
> 2013-12-29 07:49:06,324 ERROR [c.c.a.ApiAsyncJobDispatcher]
> (Job-Executor-29:ctx-f5b59752) Unexpected exception while executing
> org.apache.cloudstack.api.command.user.vm.AddNicToVMCmd
> com.cloud.utils.exception.CloudRuntimeException: Unable to serialize:
> com.cloud.vm.VmWorkAddVmToNetwork@57ca10b0
> at
> org.apache.cloudstack.framework.jobs.impl.JobSerializerHelper.toObjectSerializedString(JobSerializerHelper.java:118)
> at com.cloud.vm.VmWorkSerializer.serialize(VmWorkSerializer.java:63)
> at
> com.cloud.vm.VirtualMachineManagerImpl$10.doInTransactionWithoutResult(VirtualMachineManagerImpl.java:4554)
> at
> com.cloud.utils.db.TransactionCallbackNoReturn.doInTransaction(TransactionCallbackNoReturn.java:25)
> at
> com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49)
> at com.cloud.utils.db.Transaction.execute(Transaction.java:37)
> at com.cloud.utils.db.Transaction.execute(Transaction.java:46)
> at
> com.cloud.vm.VirtualMachineManagerImpl.addVmToNetworkThroughJobQueue(VirtualMachineManagerImpl.java:4525)
> at
> com.cloud.vm.VirtualMachineManagerImpl.addVmToNetwork(VirtualMachineManagerImpl.java:3112)
> at
> com.cloud.vm.UserVmManagerImpl.addNicToVirtualMachine(UserVmManagerImpl.java:1038)
> at sun.reflect.GeneratedMethodAccessor813.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> 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 $Proxy169.addNicToVirtualMachi
[jira] [Commented] (CLOUDSTACK-5767) Attach/Detach API command uses job status and job result field for other purpose, which can break underlying job scheduling logic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867192#comment-13867192 ] ASF subversion and git services commented on CLOUDSTACK-5767: - Commit ad6454d2bfff4b517b8dfca21b02f923ac8e9a51 in branch refs/heads/master from [~kelveny] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ad6454d ] CLOUDSTACK-5767: Remove the logic of using underlying job related fields for volume specific logic. > Attach/Detach API command uses job status and job result field for other > purpose, which can break underlying job scheduling logic > - > > Key: CLOUDSTACK-5767 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5767 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kelven Yang >Assignee: Kelven Yang >Priority: Blocker > -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5752) [vmsync] Persistent network fails to implement
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867196#comment-13867196 ] ASF subversion and git services commented on CLOUDSTACK-5752: - Commit a05d71a80c16628d8cb15c419c3a794df16ec6ff in branch refs/heads/master from [~kelveny] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a05d71a ] CLOUDSTACK-5752: Use pesudo job context when API dispather directly calls into orchestration flow > [vmsync] Persistent network fails to implement > --- > > Key: CLOUDSTACK-5752 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5752 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.3.0 > Environment: Advanced zone, any hypervisor >Reporter: Sowmya Krishnan >Assignee: Kelven Yang >Priority: Blocker > Labels: vmsync > Fix For: 4.3.0 > > Attachments: ms.log > > > Latest build fails to implement a persistent network. > Steps: > Create isolated network offering with persistent = true > Launch a network with this offering. > Logs simply say that it fails to implement the network and router fails to > launch and throws an NPE: > 2014-01-03 14:02:36,344 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (catalina-exec-9:ctx-e1417c9c ctx-499be25e) Starting router > VM[DomainRouter|r-34-VM] > 2014-01-03 14:02:36,344 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (catalina-exec-9:ctx-e1417c9c ctx-499be25e) Cleaning up because we're unable > to implement the network Ntwk[219|Guest|22] > 2014-01-03 14:02:36,349 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (catalina-exec-9:ctx-e1417c9c ctx-499be25e) Lock is acquired for network > Ntwk[219|Guest|22] as a part of network shutdown > 2014-01-03 14:02:36,355 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (catalina-exec-9:ctx-e1417c9c ctx-499be25e) Releasing 0 port forwarding rules > for network id=219 as a part of shutdownNetworkRu > les > 2014-01-03 14:02:36,355 DEBUG [c.c.n.f.FirewallManagerImpl] > (catalina-exec-9:ctx-e1417c9c ctx-499be25e) There are no rules to forward to > the network elements > 2014-01-03 14:02:36,356 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (catalina-exec-9:ctx-e1417c9c ctx-499be25e) Releasing 0 static nat rules for > network id=219 as a part of shutdownNetworkRules > 2014-01-03 14:02:36,356 DEBUG [c.c.n.f.FirewallManagerImpl] > (catalina-exec-9:ctx-e1417c9c ctx-499be25e) There are no rules to forward to > the network elements > 2014-01-03 14:02:36,357 DEBUG [c.c.n.l.LoadBalancingRulesManagerImpl] > (catalina-exec-9:ctx-e1417c9c ctx-499be25e) Revoking 0 Public load balancing > rules for network id=219 > ... > ... > 2014-01-03 14:02:36,383 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (catalina-exec-9:ctx-e1417c9c ctx-499be25e) Sending network shutdown to > VirtualRouter > 2014-01-03 14:02:36,384 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (catalina-exec-9:ctx-e1417c9c ctx-499be25e) Stopping router > VM[DomainRouter|r-34-VM] > 2014-01-03 14:02:36,384 WARN [o.a.c.e.o.NetworkOrchestrator] > (catalina-exec-9:ctx-e1417c9c ctx-499be25e) Unable to complete shutdown of > the network elements due to element: VirtualRouter > java.lang.NullPointerException > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1268) > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl.stop(VirtualNetworkApplianceManagerImpl.java:2702) > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl.stop(VirtualNetworkApplianceManagerImpl.java:139) > 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:616) > 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 $Proxy240.stop(Unknown Source) >
[jira] [Commented] (CLOUDSTACK-5734) Console not working for SSVM CPVM VR guest VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867183#comment-13867183 ] Rayees Namathponnan commented on CLOUDSTACK-5734: - is it due to any of the recent changes in console proxy ? https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=history;f=services/console-proxy/server;hb=refs/heads/4.3 > Console not working for SSVM CPVM VR guest VMs > -- > > Key: CLOUDSTACK-5734 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5734 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: MS4.3 release 1/2/14 > vcenter 5.5 host1 ESXi 5.5 host2 ESXi 5.5 >Reporter: angeline shen >Assignee: Santhosh Kumar Edukulla >Priority: Blocker > Fix For: 4.3.0 > > Attachments: CLOUDSTACK-5734.png, management-server(1).log.gz, > vm43.png > > > 1. advance zone. Create VPC, VPC network, create VMs > 2. create windows 2008R2 iso -based VM > 3. Open console to SSVM CPVMVRguest VMs - blank -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5734) Console not working for SSVM CPVM VR guest VMs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867178#comment-13867178
]
Rayees Namathponnan commented on CLOUDSTACK-5734:
-
Observed below error in CPVM cloud.log
2014-01-09 22:23:47,163 DEBUG [cloud.agent.Agent] (Agent-Handler-3:null)
Received response: Seq 6-11295: { Ans: , MgmtId: 29066118877352, via: 6, Ver:
v1, Flags: 100010,
[{"com.cloud.agent.api.PingAnswer":{"_command":{"hostType":"ConsoleProxy","hostId":6,"wait":0},"result":true,"wait":0}}]
}
2014-01-09 22:23:47,509 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread]
(Console Proxy GC Thread:null) connMap={}
2014-01-09 22:23:51,861 WARN [cloud.consoleproxy.ConsoleProxyAjaxHandler]
(Thread-13:null) Exception,
java.lang.IllegalArgumentException
at
com.cloud.consoleproxy.ConsoleProxyAjaxHandler.doHandle(ConsoleProxyAjaxHandler.java:96)
at
com.cloud.consoleproxy.ConsoleProxyAjaxHandler.handle(ConsoleProxyAjaxHandler.java:49)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:83)
at sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:83)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:86)
at
sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:598)
at com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:83)
at sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:568)
at java.lang.Thread.run(Thread.java:679)
2014-01-09 22:23:52,509 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread]
(Console Proxy GC Thread:null) connMap={}
2014-01-09 22:23:52,510 DEBUG [resource.consoleproxy.ConsoleProxyResource]
(Console Proxy GC Thread:null) Report proxy load info, proxy : 3, load: {
"connections": []
}
2014-01-09 22:23:52,510 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread]
(Console Proxy GC Thread:null) Report load change : {
"connections": []
}
2014-01-09 22:23:52,556 DEBUG [cloud.agent.Agent] (Agent-Handler-4:null)
Received response: Seq 6-11296: { Ans: , MgmtId: 29066118877352, via: 6, Ver:
v1, Flags: 100010,
[{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
Disk is not full
root@v-3-VM:/var/log/cloud# df -h
Filesystem Size Used Avail Use%
Mounted on
rootfs 276M 141M 122M 54% /
udev 10M 0 10M 0%
/dev
tmpfs 101M 224K 101M 1%
/run
/dev/disk/by-uuid/dfe59018-f53f-47f6-9075-4bf7ce0eb11a 276M 141M 122M 54% /
tmpfs 5.0M 0 5.0M 0%
/run/lock
tmpfs 314M 0 314M 0%
/run/shm
/dev/vda145M 22M 21M 51%
/boot
/dev/vda698M 5.6M 88M 6%
/home
/dev/vda8 368M 11M 339M 3%
/opt
/dev/vda10 63M 5.3M 55M 9%
/tmp
/dev/vda7 610M 496M 83M 86%
/usr
/dev/vda9 415M 168M 226M 43%
/var
root@v-3-VM:/var/log/cloud#
> Console not working for SSVM CPVM VR guest VMs
> --
>
> Key: CLOUDSTACK-5734
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5734
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: MS4.3 release 1/2/14
> vcenter 5.5 host1 ESXi 5.5 host2 ESXi 5.5
>Reporter: angeline shen
>Assignee: Santhosh Kumar Edukulla
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: CLOUDSTACK-5734.png, management-server(1).log.gz,
> vm43.png
>
>
> 1. advance zone. Create VPC, VPC network, create VMs
> 2. create windows 2008R2 iso -based VM
> 3. Open console to SSVM CPVMVRguest VMs - blank
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5468) Configuration property should be optional
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867166#comment-13867166 ] ASF subversion and git services commented on CLOUDSTACK-5468: - Commit a298f6fce994b45213be7d2b644b0e48a55c4b12 in branch refs/heads/master from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a298f6f ] Merge from 4.3: CLOUDSTACK-5468: Configuration property should be optional > Configuration property should be optional > - > > Key: CLOUDSTACK-5468 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5468 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Mac OS X 10.8.3 >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.3.0 > > > This is actually an issue with the SolidFire plug-in (as opposed to the > Management Server, which is the Component this is filed under). > The property "useMutualChapForVMware" should be optional. > We have already seen a customer have issues with this, so it is important to > fix in 4.3. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5819) extractTemplate fails with Vmware host on migration of NFS to S3
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867144#comment-13867144
]
ASF subversion and git services commented on CLOUDSTACK-5819:
-
Commit 9a4a2911da1b6e22180b55f09317b0a858d6e186 in branch refs/heads/4.3 from
[~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9a4a291 ]
CLOUDSTACK-5819:extractTemplate fails with Vmware host on migration of
NFS to S3.
> extractTemplate fails with Vmware host on migration of NFS to S3
>
>
> Key: CLOUDSTACK-5819
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5819
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Template, VMware
>Affects Versions: 4.3.0
> Environment: Latest Management server 4.3
> Two zones one with Xen host and other with VmWare host
>Reporter: Pavan Kumar Bandarupally
>Assignee: Min Chen
>Priority: Critical
> Fix For: 4.3.0
>
>
> Trying to download a template created from snapshot of root volume or
> template of root volume after migration of NFS to S3 store throws an error.
> Job Trace:
> ==
> 2014-01-07 22:07:44,221 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-8:ctx-3c03896e) ===START=== 10.146.0.11 -- GET
> command=extractTemplate&mode=HTTP_DOWNLOAD&id=3e35e5f4-9067-4c6e-ba15-3eb80494a6e8&response=json&sessionkey=BGTkrKxSTvEyZG7Nx4tTVof99Tw%3D&_=1389093486904
> 2014-01-07 22:07:44,255 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (catalina-exec-8:ctx-3c03896e ctx-f274cea7) submit async job-89, details:
> AsyncJobVO {id:89, userId: 2, accountId: 2, instanceType: Template,
> instanceId: 203, cmd:
> org.apache.cloudstack.api.command.user.template.ExtractTemplateCmd, cmdInfo:
> {"response":"json","id":"3e35e5f4-9067-4c6e-ba15-3eb80494a6e8","sessionkey":"BGTkrKxSTvEyZG7Nx4tTVof99Tw\u003d","cmdEventType":"TEMPLATE.EXTRACT","ctxUserId":"2","httpmethod":"GET","_":"1389093486904","ctxAccountId":"2","ctxStartEventId":"176","mode":"HTTP_DOWNLOAD"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7337246982268, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-01-07 22:07:44,258 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-8:ctx-3c03896e ctx-f274cea7) ===END=== 10.146.0.11 -- GET
> command=extractTemplate&mode=HTTP_DOWNLOAD&id=3e35e5f4-9067-4c6e-ba15-3eb80494a6e8&response=json&sessionkey=BGTkrKxSTvEyZG7Nx4tTVof99Tw%3D&_=1389093486904
> 2014-01-07 22:07:44,262 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-37:ctx-b68520ba) Add job-89 into job monitoring
> 2014-01-07 22:07:44,262 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-37:ctx-b68520ba) Executing AsyncJobVO {id:89, userId: 2,
> accountId: 2, instanceType: Template, instanceId: 203, cmd:
> org.apache.cloudstack.api.command.user.template.ExtractTemplateCmd, cmdInfo:
> {"response":"json","id":"3e35e5f4-9067-4c6e-ba15-3eb80494a6e8","sessionkey":"BGTkrKxSTvEyZG7Nx4tTVof99Tw\u003d","cmdEventType":"TEMPLATE.EXTRACT","ctxUserId":"2","httpmethod":"GET","_":"1389093486904","ctxAccountId":"2","ctxStartEventId":"176","mode":"HTTP_DOWNLOAD"},
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7337246982268, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: null}
> 2014-01-07 22:07:44,290 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl]
> (Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in
> store:3, type:Image
> 2014-01-07 22:07:44,300 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl]
> (Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in
> store:1, type:ImageCache
> 2014-01-07 22:07:44,302 DEBUG [o.a.c.s.i.TemplateDataFactoryImpl]
> (Job-Executor-37:ctx-b68520ba ctx-f274cea7) template 203 is already in
> store:3, type:Image
> 2014-01-07 22:07:44,325 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
> (Job-Executor-37:ctx-b68520ba ctx-f274cea7) copyAsync inspecting src type
> TEMPLATE copyAsync inspecting dest type TEMPLATE
> 2014-01-07 22:07:44,371 DEBUG [c.c.a.t.Request] (Job-Executor-37:ctx-b68520ba
> ctx-f274cea7) Seq 3-242024639: Sending { Cmd , MgmtId: 7337246982268, via:
> 3(s-1-VM), Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/2/203/288329c8b-bb60-325f-8da8-b7e0e9764f99.ova","uuid":"3e35e5f4-9067-4c6e-ba15-3eb80494a6e8","id":203,"format":"OVA","accountId":2,"hvm":true,"displayText":"tmplt
> from root vol on Vmware
> before","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.147.28.7/export/h
[jira] [Commented] (CLOUDSTACK-4810) Enable hypervisor snapshots for CloudStack-managed storage (for XenServer and VMware)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867146#comment-13867146 ] ASF subversion and git services commented on CLOUDSTACK-4810: - Commit caf87ac5d9bd51aff9d1800814866b9f781b4335 in branch refs/heads/master from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=caf87ac ] Merge from 4.3: CLOUDSTACK-4810: Enable hypervisor snapshots for CloudStack-managed storage (for XenServer and VMware) > Enable hypervisor snapshots for CloudStack-managed storage (for XenServer and > VMware) > - > > Key: CLOUDSTACK-4810 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4810 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 > Environment: Ubuntu 12.04 >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.3.0 > > > CloudStack-managed storage was introduced into CloudStack with the new > storage framework in 4.2. > This allows CloudStack to create and delete storage repositories and > datastores as needed. > For 4.2 the VDI inside of an SR takes up almost as much space as is available > in the SR (so there is a one-to-one mapping between an SR and a VDI). This is > the same idea for datastores and VMDKs. > The SR or datastore should be sized larger than its VDI or VMDK so there is > space available for hypervisor snapshots that get stored on the same SR or > datastore. > How much larger can be determined by a cluster-level setting. > For example, if you want a 10 GB CloudStack volume, the storage plug-in in > question can create, say, a 20 GB volume on its SAN. 10 GB to be used for the > CloudStack volume and an additional 10 GB for hypervisor snapshots. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5502) [Automation] createVlanIpRange API failing, if you pass VLAN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867135#comment-13867135
]
Alena Prokharchyk commented on CLOUDSTACK-5502:
---
I agree that its ambiguous that we treat NULL and untagged the same way. Its
NULL in the network, and "untagged" in corresponding vlans:
mysql> select broadcast_uri from networks where traffic_type='guest' and
removed is null;
+---+
| broadcast_uri |
+---+
| NULL |
| NULL |
| NULL |
+---+
mysql> select vlan_id from vlan;
+--+
| vlan_id |
+--+
| untagged |
| untagged |
| untagged |
+--+
Daan, I think your fix should be changed (revert the old code, and commit a new
fix). Instead of changing ConfigurationManager, you need to fix addVlanRange
API class. Basically when "untagged" is passed in, convert it to NULL there as
if nothing has been passed in. Then let the networking code translate it to
whatever it understands and perform the validation. In this case you will
preserve the old behavior.
Marcus, please let me/Daan know if the possible fix I've suggested, breaks
anything on your side. By reviewing the code, I don't see that anything will be
wrong after applying the fix I've suggested.
> [Automation] createVlanIpRange API failing, if you pass VLAN
> -
>
> Key: CLOUDSTACK-5502
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5502
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
> Environment: KVM Basic Zone with SG
>Reporter: Rayees Namathponnan
>Assignee: Daan Hoogland
>Priority: Blocker
> Fix For: 4.3.0
>
>
> This issue found in KVM basic zone with SG automation run; test cases from
> below suite filed
> integration.component.test_multiple_ip_ranges.
> Steps to reproduce
> Step 1 : Create basic zone with SG
> Step 2 : Crete IP VLAN Range with below command (pass vlan=untagged)
> http://xxx..xxx.xxx:8096/?command=createVlanIpRange&gateway=10.223.251.1&forvirtualnetwork=false&startip=10.223.251.3&podid=0253bcbf-e636-4776-9e8c-216b70d195a2&zoneid=a9912aa8-a231-44d9-a70b-9d53e6db2d27&netmask=255.255.255.192&vlan=untagged
> Result;
> API command failed with error
> { "createvlaniprangeresponse" :
> {"uuidList":[],"errorcode":431,"cserrorcode":4350,"errortext":"Vlan doesn't
> match vlan of the network"} }
> this API command works only, if you are not passing any VLAN
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5734) Console not working for SSVM CPVM VR guest VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867132#comment-13867132 ] Wei Zhou commented on CLOUDSTACK-5734: -- Is the disk full on CPVM? > Console not working for SSVM CPVM VR guest VMs > -- > > Key: CLOUDSTACK-5734 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5734 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: MS4.3 release 1/2/14 > vcenter 5.5 host1 ESXi 5.5 host2 ESXi 5.5 >Reporter: angeline shen >Assignee: Santhosh Kumar Edukulla >Priority: Blocker > Fix For: 4.3.0 > > Attachments: CLOUDSTACK-5734.png, management-server(1).log.gz, > vm43.png > > > 1. advance zone. Create VPC, VPC network, create VMs > 2. create windows 2008R2 iso -based VM > 3. Open console to SSVM CPVMVRguest VMs - blank -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5774) [Automation] VPCChecker failed to delete the VPC VR's Volume due to NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi resolved CLOUDSTACK-5774.
Resolution: Cannot Reproduce
> [Automation] VPCChecker failed to delete the VPC VR's Volume due to NPE
> ---
>
> Key: CLOUDSTACK-5774
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5774
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
>Reporter: Chandan Purushothama
>Assignee: Chandan Purushothama
>Priority: Critical
> Fix For: 4.3.0
>
>
> ==
> NullPointer Exception:
> ==
> 2014-01-04 00:47:14,661 INFO [c.c.n.v.VpcManagerImpl]
> (VpcChecker-1:ctx-4daa3c04) Found 1 removed VPCs to cleanup
> 2014-01-04 00:47:14,662 DEBUG [c.c.n.v.VpcManagerImpl]
> (VpcChecker-1:ctx-4daa3c04) Cleaning up [VPC [5-TestVPC-G9J5FX]
> 2014-01-04 00:47:14,665 DEBUG [c.c.n.v.VpcManagerImpl]
> (VpcChecker-1:ctx-4daa3c04) Destroying vpc [VPC [5-TestVPC-G9J5FX]
> 2014-01-04 00:47:14,668 DEBUG [c.c.n.v.VpcManagerImpl]
> (VpcChecker-1:ctx-4daa3c04) Shutting down vpc [VPC [5-TestVPC-G9J5FX]
> 2014-01-04 00:47:14,677 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
> (VpcChecker-1:ctx-4daa3c04) Attempting to destroy router 77
> 2014-01-04 00:47:14,682 DEBUG [c.c.v.VirtualMachineManagerImpl]
> (VpcChecker-1:ctx-4daa3c04) Stopped called on VM[DomainRouter|r-77-QA] but
> the state is Expunging
> 2014-01-04 00:47:14,684 DEBUG [c.c.c.CapacityManagerImpl]
> (VpcChecker-1:ctx-4daa3c04) VM state transitted from :Expunging to Expunging
> with event: ExpungeOperationvm's original host id: 1 new host id: 2 host id
> before state transition: 2
> 2014-01-04 00:47:14,684 DEBUG [c.c.v.VirtualMachineManagerImpl]
> (VpcChecker-1:ctx-4daa3c04) Destroying vm VM[DomainRouter|r-77-QA]
> 2014-01-04 00:47:14,685 DEBUG [c.c.v.VirtualMachineManagerImpl]
> (VpcChecker-1:ctx-4daa3c04) Cleaning up NICS
> 2014-01-04 00:47:14,685 DEBUG [o.a.c.e.o.NetworkOrchestrator]
> (VpcChecker-1:ctx-4daa3c04) Cleaning network for vm: 77
> 2014-01-04 00:47:14,686 DEBUG [c.c.v.VirtualMachineManagerImpl]
> (VpcChecker-1:ctx-4daa3c04) Cleaning up hypervisor data structures (ex. SRs
> in XenServer) for managed storage
> 2014-01-04 00:47:14,688 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-250:ctx-1c5db065) Seq 2-1933902599: Response Received:
> 2014-01-04 00:47:14,689 DEBUG [c.c.a.t.Request]
> (DirectAgent-250:ctx-1c5db065) Seq 2-1933902599: Processing: { Ans: ,
> MgmtId: 6631563722783, via: 2, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-13-QA","bytesSent":1440,"bytesReceived":0,"result":true,"details":"","wait":0}}]
> }
> 2014-01-04 00:47:14,689 DEBUG [c.c.a.t.Request]
> (RouterMonitor-1:ctx-83046987) Seq 2-1933902599: Received: { Ans: , MgmtId:
> 6631563722783, via: 2, Ver: v1, Flags: 10, { NetworkUsageAnswer } }
> 2014-01-04 00:47:14,689 DEBUG [c.c.a.m.AgentManagerImpl]
> (RouterMonitor-1:ctx-83046987) Details from executing class
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-01-04 00:47:14,708 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-146:ctx-4ab2a172) Seq 2-1933902600: Response Received:
> 2014-01-04 00:47:14,709 DEBUG [c.c.a.t.Request]
> (DirectAgent-146:ctx-4ab2a172) Seq 2-1933902600: Processing: { Ans: ,
> MgmtId: 6631563722783, via: 2, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":true,"wait":0}}] }
> 2014-01-04 00:47:14,709 DEBUG [c.c.a.t.Request]
> (AccountChecker-1:ctx-3dd8fde4) Seq 2-1933902600: Received: { Ans: , MgmtId:
> 6631563722783, via: 2, Ver: v1, Flags: 10, { Answer } }
> 2014-01-04 00:47:14,719 DEBUG [o.a.c.e.o.VolumeOrchestrator]
> (VpcChecker-1:ctx-4daa3c04) Cleaning storage for vm: 77
> 2014-01-04 00:47:14,724 DEBUG [o.a.c.e.o.VolumeOrchestrator]
> (VpcChecker-1:ctx-4daa3c04) Skipping destroy for the volume
> Vol[83|vm=77|ROOT] as its in state Expunged
> 2014-01-04 00:47:14,730 INFO [o.a.c.s.v.VolumeServiceImpl]
> (AccountChecker-1:ctx-3dd8fde4) Volume 83 is not referred anywhere, remove it
> from volumes table
> 2014-01-04 00:47:14,751 DEBUG [c.c.v.VirtualMachineManagerImpl]
> (AccountChecker-1:ctx-3dd8fde4) Expunged VM[DomainRouter|r-77-QA]
> 2014-01-04 00:47:14,753 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-154:ctx-9dc1ad33) Seq 2-1933902601: Executing request
> 2014-01-04 00:47:14,779 DEBUG [c.c.n.v.VpcManagerImpl]
> (AccountChecker-1:ctx-3dd8fde4) Vpc [VPC [5-TestVPC-G9J5FX] has been shutdown
> succesfully
> 2014-01-04 00:47:14,779 DEBUG [c.c.n.v.VpcManagerImpl]
> (AccountChecker-1:ctx-3dd8fde4) Cleaning up resources for vpc id=5
> 2014-01-04 00:47:14,779 DEB
[jira] [Commented] (CLOUDSTACK-5005) issue with stopping vms parallelly
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867127#comment-13867127
]
Animesh Chaturvedi commented on CLOUDSTACK-5005:
Pushing it out to 4.4 since it is pre-existing issue and newer VMSync changes
should address it
> issue with stopping vms parallelly
> ---
>
> Key: CLOUDSTACK-5005
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5005
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.1
>Reporter: prashant kumar mishra
>Assignee: Kelven Yang
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: MS_XEN_DB.rar
>
>
> steps to reproduce
> ---
> 1-prepare CS setup with xen 6.1
> 2-set execute.in.sequence.hypervisor.commands and
> execute.in.sequence.network.element.commands to false
> 3-Restart MS
> 4-deploy 35 vms parallelly with default centOS template
> 5-try to stop all uservms using script
> Expected
> -
> All vms should get stopped ,
> Actual
>
> before vms went in stopped state , Log show error messages
> Logs
>
> [root@localhost ~]# grep "job-436"
> /var/log/cloudstack/management/management-server.log
> 2013-10-30 12:21:57,817 DEBUG [cloud.async.AsyncJobManagerImpl]
> (ApiServer-1:null) submit async job-436 = [
> 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ], details: AsyncJobVO {id:436, userId:
> 1, accountId: 1, sessionKey: null, instanceType: VirtualMachine, instanceId:
> 78, cmd: org.apache.cloudstack.api.command.user.vm.StopVMCmd, cmdOriginator:
> null, cmdInfo:
> {"id":"78","cmdEventType":"VM.STOP","ctxUserId":"1","httpmethod":"GET","ctxAccountId":"1","ctxStartEventId":"1384"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 7484181839895,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-10-30 12:21:57,818 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
> Executing org.apache.cloudstack.api.command.user.vm.StopVMCmd for job-436 = [
> 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]
> 2013-10-30 12:21:57,941 DEBUG [cloud.api.ApiDispatcher]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
> ControlledEntity name is:com.cloud.vm.VirtualMachine
> 2013-10-30 12:21:58,056 DEBUG [cloud.api.ApiDispatcher]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
> ControlledEntity name is:com.cloud.uservm.UserVm
> 2013-10-30 12:21:58,111 DEBUG [cloud.api.ApiDispatcher]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
> ControlledEntity name is:com.cloud.network.router.VirtualRouter
> 2013-10-30 12:21:58,528 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) VM
> state transitted from :Running to Stopping with event: StopRequestedvm's
> original host id: 3 new host id: 3 host id before state transition: 3
> 2013-10-30 12:21:58,696 DEBUG [agent.transport.Request]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Seq
> 3-125568146: Sending { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1, Flags:
> 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-78-VM","wait":0}}]
> }
> 2013-10-30 12:21:58,696 DEBUG [agent.transport.Request]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Seq
> 3-125568146: Executing: { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1,
> Flags: 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-78-VM","wait":0}}]
> }
> 2013-10-30 12:22:58,051 DEBUG [agent.transport.Request]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Seq
> 3-125568146: Received: { Ans: , MgmtId: 7484181839895, via: 3, Ver: v1,
> Flags: 10, { StopAnswer } }
> 2013-10-30 12:22:58,078 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
> VM[User|f1ad8bfe-b9a4-4669-a37c-f0edb2f0098f] is stopped on the host.
> Proceeding to release resource held.
> 2013-10-30 12:22:58,088 DEBUG [cloud.network.NetworkModelImpl]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Service
> SecurityGroup is not supported in the network id=204
> 2013-10-30 12:22:58,095 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
> Changing active number of nics for network id=204 on -1
> 2013-10-30 12:22:58,123 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-
[jira] [Updated] (CLOUDSTACK-5005) issue with stopping vms parallelly
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5005:
---
Fix Version/s: (was: 4.3.0)
4.4.0
> issue with stopping vms parallelly
> ---
>
> Key: CLOUDSTACK-5005
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5005
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.2.1
>Reporter: prashant kumar mishra
>Assignee: Kelven Yang
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: MS_XEN_DB.rar
>
>
> steps to reproduce
> ---
> 1-prepare CS setup with xen 6.1
> 2-set execute.in.sequence.hypervisor.commands and
> execute.in.sequence.network.element.commands to false
> 3-Restart MS
> 4-deploy 35 vms parallelly with default centOS template
> 5-try to stop all uservms using script
> Expected
> -
> All vms should get stopped ,
> Actual
>
> before vms went in stopped state , Log show error messages
> Logs
>
> [root@localhost ~]# grep "job-436"
> /var/log/cloudstack/management/management-server.log
> 2013-10-30 12:21:57,817 DEBUG [cloud.async.AsyncJobManagerImpl]
> (ApiServer-1:null) submit async job-436 = [
> 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ], details: AsyncJobVO {id:436, userId:
> 1, accountId: 1, sessionKey: null, instanceType: VirtualMachine, instanceId:
> 78, cmd: org.apache.cloudstack.api.command.user.vm.StopVMCmd, cmdOriginator:
> null, cmdInfo:
> {"id":"78","cmdEventType":"VM.STOP","ctxUserId":"1","httpmethod":"GET","ctxAccountId":"1","ctxStartEventId":"1384"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 7484181839895,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-10-30 12:21:57,818 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
> Executing org.apache.cloudstack.api.command.user.vm.StopVMCmd for job-436 = [
> 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]
> 2013-10-30 12:21:57,941 DEBUG [cloud.api.ApiDispatcher]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
> ControlledEntity name is:com.cloud.vm.VirtualMachine
> 2013-10-30 12:21:58,056 DEBUG [cloud.api.ApiDispatcher]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
> ControlledEntity name is:com.cloud.uservm.UserVm
> 2013-10-30 12:21:58,111 DEBUG [cloud.api.ApiDispatcher]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
> ControlledEntity name is:com.cloud.network.router.VirtualRouter
> 2013-10-30 12:21:58,528 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) VM
> state transitted from :Running to Stopping with event: StopRequestedvm's
> original host id: 3 new host id: 3 host id before state transition: 3
> 2013-10-30 12:21:58,696 DEBUG [agent.transport.Request]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Seq
> 3-125568146: Sending { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1, Flags:
> 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-78-VM","wait":0}}]
> }
> 2013-10-30 12:21:58,696 DEBUG [agent.transport.Request]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Seq
> 3-125568146: Executing: { Cmd , MgmtId: 7484181839895, via: 3, Ver: v1,
> Flags: 100011,
> [{"com.cloud.agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"i-2-78-VM","wait":0}}]
> }
> 2013-10-30 12:22:58,051 DEBUG [agent.transport.Request]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Seq
> 3-125568146: Received: { Ans: , MgmtId: 7484181839895, via: 3, Ver: v1,
> Flags: 10, { StopAnswer } }
> 2013-10-30 12:22:58,078 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
> VM[User|f1ad8bfe-b9a4-4669-a37c-f0edb2f0098f] is stopped on the host.
> Proceeding to release resource held.
> 2013-10-30 12:22:58,088 DEBUG [cloud.network.NetworkModelImpl]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Service
> SecurityGroup is not supported in the network id=204
> 2013-10-30 12:22:58,095 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ])
> Changing active number of nics for network id=204 on -1
> 2013-10-30 12:22:58,123 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-122:job-436 = [ 432f8bd7-8f4b-4e72-b69b-b148fc1733dc ]) Asking
> VirtualRouter to re
[jira] [Updated] (CLOUDSTACK-5342) [Automation] Add NIC to virtual machine fails in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5342:
---
Priority: Major (was: Blocker)
> [Automation] Add NIC to virtual machine fails in KVM
>
>
> Key: CLOUDSTACK-5342
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5342
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller
>Affects Versions: 4.3.0
> Environment: KVM advanced
>Reporter: Gaurav Aradhye
>Assignee: Saksham Srivastava
> Fix For: 4.3.0
>
>
> Add network to VM test cases fail in KVM with following error.
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u'Unable to add NIC to VM[User|VM-e9350ee5-bf2e-418c-91d6-1535dcb4d488]'}
> The same test cases execute successfully on XenServer. As per the feature
> specification (see
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Add+Remove+Networks+to+VMs),
> "Add network to VM" feature should be supported on KVM too.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5342) [Automation] Add NIC to virtual machine fails in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867124#comment-13867124
]
Animesh Chaturvedi commented on CLOUDSTACK-5342:
Agree with Saksham if it is a known qemu issue test should be fixed to
accommodate it. No point failing the test every time for this known issue.
Bumping down to major
> [Automation] Add NIC to virtual machine fails in KVM
>
>
> Key: CLOUDSTACK-5342
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5342
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller
>Affects Versions: 4.3.0
> Environment: KVM advanced
>Reporter: Gaurav Aradhye
>Assignee: Saksham Srivastava
> Fix For: 4.3.0
>
>
> Add network to VM test cases fail in KVM with following error.
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u'Unable to add NIC to VM[User|VM-e9350ee5-bf2e-418c-91d6-1535dcb4d488]'}
> The same test cases execute successfully on XenServer. As per the feature
> specification (see
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Add+Remove+Networks+to+VMs),
> "Add network to VM" feature should be supported on KVM too.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5742) #cpu,cpu speed, and ram is getting updated under wrong usage_type(2) for dynamic compute offering in usage_vm_instance table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi resolved CLOUDSTACK-5742. Resolution: Fixed Resolving based on the commit > #cpu,cpu speed, and ram is getting updated under wrong usage_type(2) for > dynamic compute offering in usage_vm_instance table > > > Key: CLOUDSTACK-5742 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5742 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: prashant kumar mishra >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.3.0 > > Attachments: LOG_DB.rar > > > STEPS TO REPO > == > 1-prepare a CS setup 4.3 > 2-deploy a vm with small CO > 3-Change the vm CO to dynamic CO. > 4-check the usage_vm_instance table after cloud_usage db synch > EXPECTED > = > cpu and ram should get updated under usage type 1 > ACTUAL > === > cpu and ram is getting updated under usage type2 > DB > === > | 2 | 1 | 2 | 8 | test| > 12 | 202 | XenServer | 2014-01-03 10:10:15 | NULL > | 100 | 1 |256 | > | 1 | 1 | 2 | 8 | test| > 12 | 202 | XenServer | 2014-01-03 10:11:21 | NULL > | NULL | NULL | NULL | > ++-+++-+-+-+-+-+-+---+---++ -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-4810) Enable hypervisor snapshots for CloudStack-managed storage (for XenServer and VMware)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867116#comment-13867116 ] ASF subversion and git services commented on CLOUDSTACK-4810: - Commit 03118c2969d145bdade7f685ee580c37124187c8 in branch refs/heads/master from [~mike-tutkowski] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=03118c2 ] Merge from 4.3: CLOUDSTACK-4810: Enable hypervisor snapshots for CloudStack-managed storage (for XenServer and VMware) > Enable hypervisor snapshots for CloudStack-managed storage (for XenServer and > VMware) > - > > Key: CLOUDSTACK-4810 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4810 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 > Environment: Ubuntu 12.04 >Reporter: Mike Tutkowski >Assignee: Mike Tutkowski > Fix For: 4.3.0 > > > CloudStack-managed storage was introduced into CloudStack with the new > storage framework in 4.2. > This allows CloudStack to create and delete storage repositories and > datastores as needed. > For 4.2 the VDI inside of an SR takes up almost as much space as is available > in the SR (so there is a one-to-one mapping between an SR and a VDI). This is > the same idea for datastores and VMDKs. > The SR or datastore should be sized larger than its VDI or VMDK so there is > space available for hypervisor snapshots that get stored on the same SR or > datastore. > How much larger can be determined by a cluster-level setting. > For example, if you want a 10 GB CloudStack volume, the storage plug-in in > question can create, say, a 20 GB volume on its SAN. 10 GB to be used for the > CloudStack volume and an additional 10 GB for hypervisor snapshots. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5848) "Unable to parse VLAN tag" message when network associated with SRX external firewall device is rebooted.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5848:
---
Assignee: Jayapal Reddy
> "Unable to parse VLAN tag" message when network associated with SRX external
> firewall device is rebooted.
> --
>
> Key: CLOUDSTACK-5848
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5848
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Devices
>Affects Versions: 4.3.0
> Environment: upgraded the CS from 3.0.6 patch E to 4.3
>Reporter: manasaveloori
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: management-server.rar
>
>
> Steps:
> 1. Deploy CS 3.0.6 patch E using Xen 6.0.2 HV.
> 2. Add SRX device.
> 3 . Deploy the VMs uing the SRX network.
> 4. Enable PF,Static nat rules for the VM using SRX.
> 5. Upgrade the CS to 4.3.
> 6. Now restart the network associated with SRX or disable static nat etc.
> Observing following exceptions in logs:
> er root, class super-user --> xmlns:junos="http://xml.juniper.net/junos/10.4R6/junos";> xmlns="http://xml.juniper.net/xnm/1.1/xnm";
> xmlns:xnm="http://xml.juniper.net/xnm/1.1/xnm";>uncommitted changes
> will be discarded on exit
> 2014-01-09 22:27:14,815 DEBUG [c.c.n.r.JuniperSrxResource]
> (DirectAgent-22:ctx-357d339b) Opened a private configuration.
> 2014-01-09 22:27:14,816 ERROR [c.c.n.r.JuniperSrxResource]
> (DirectAgent-22:ctx-357d339b) com.cloud.utils.exception.ExecutionException:
> Unable to parse VLAN tag: 47
> 2014-01-09 22:27:14,816 DEBUG [c.c.n.r.JuniperSrxResource]
> (DirectAgent-22:ctx-357d339b) Sending request:
> 2014-01-09 22:27:14,868 DEBUG [c.c.n.r.JuniperSrxResource]
> (DirectAgent-22:ctx-357d339b) Checking response: xmlns:junos="http://xml.juniper.net/junos/10.4R6/junos";>
> 2014-01-09 22:27:14,868 DEBUG [c.c.n.r.JuniperSrxResource]
> (DirectAgent-22:ctx-357d339b) Closed private configuration.
> 2014-01-09 22:27:14,869 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-22:ctx-357d339b) Seq 9-550895625: Response Received:
> 2014-01-09 22:27:14,869 DEBUG [c.c.a.t.Request] (DirectAgent-22:ctx-357d339b)
> Seq 9-550895625: Processing: { Ans: , MgmtId: 6642334695485, via: 9, Ver:
> v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Exception:
> com.cloud.utils.exception.ExecutionException\nMessage: Unable to parse VLAN
> tag: 47\nStack: com.cloud.utils.exception.ExecutionException: Unable to parse
> VLAN tag: 47\n\tat
> com.cloud.network.resource.JuniperSrxResource.getVlanTag(JuniperSrxResource.java:3609)\n\tat
>
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:894)\n\tat
>
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:912)\n\tat
>
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:912)\n\tat
>
> com.cloud.network.resource.JuniperSrxResource.execute(JuniperSrxResource.java:830)\n\tat
>
> com.cloud.network.resource.JuniperSrxResource.executeRequest(JuniperSrxResource.java:353)\n\tat
>
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)\n\tat
>
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)\n\tat
>
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)\n\tat
>
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)\n\tat
>
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)\n\tat
>
> org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)\n\tat
>
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)\n\tat
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:166)\n\tat
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)\n\tat
>
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)\n\tat
> java.lang.Thread.run(Thread.java:679)\n","wait":0}}] }
> 2014-01-09 22:27:14,870 DEBUG [c.c.a.t.Request] (Job-Executor-37:ctx-5ce0e0b1
> ctx-50987553) Seq 9-550895625: Received: { Ans: , MgmtId
[jira] [Resolved] (CLOUDSTACK-5720) [upgrad]Live migration is failing ;java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi resolved CLOUDSTACK-5720.
Resolution: Fixed
> [upgrad]Live migration is failing ;java.lang.NullPointerException
> -
>
> Key: CLOUDSTACK-5720
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5720
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: hyp:xen6.2
>Reporter: prashant kumar mishra
>Assignee: Kelven Yang
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: Logs_DB.rar
>
>
> STEPS TO REPO
> ==
> 1-prepare a ACS 4.2 setup +two xen6.2 host in a cluster
> 2-deploy some vms
> 3-upgrade it to 4.3
> 4-try to migrate
> EXPECTED
> ===
> Migration should be successful
> ACTUAL
> ===
> Migration is failing because NPE
> LOG
>
> 014-01-02 12:04:43,865 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (AsyncJobMgr-Heartbeat-1:ctx-e8b68d56) Schedule queued job-47
> 2014-01-02 12:04:43,880 INFO [o.a.c.f.j.i.AsyncJobMonitor]
> (Job-Executor-14:ctx-ad5bbb25) Add job-47 into job monitoring
> 2014-01-02 12:04:43,882 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (Job-Executor-14:ctx-ad5bbb25) Executing AsyncJobVO {id:47, userId: 2,
> accountId: 2, instanceType: null, instanceId: null, cmd:
> com.cloud.vm.VmWorkMigrate, cmdInfo:
> rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIABXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXNxAH4ABwAEcQB-AAlwcQB-AAk,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7145449848920, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Thu Jan 02 12:04:42 EST 2014}
> 2014-01-02 12:04:43,882 DEBUG [c.c.v.VmWorkJobDispatcher]
> (Job-Executor-14:ctx-ad5bbb25) Run VM work job: com.cloud.vm.VmWorkMigrate
> 2014-01-02 12:04:43,886 DEBUG [c.c.v.VmWorkJobHandlerProxy]
> (Job-Executor-14:ctx-ad5bbb25 ctx-2899d402) Execute VM work job:
> com.cloud.vm.VmWorkMigrate{"zoneId":1,"podId":1,"clusterId":1,"hostId":4,"srcHostId":1,"userId":2,"accountId":2,"vmId":5,"handlerName":"VirtualMachineManagerImpl"}
> 2014-01-02 12:04:43,890 ERROR [c.c.v.VmWorkJobHandlerProxy]
> (Job-Executor-14:ctx-ad5bbb25 ctx-2899d402) Invocation exception, caused by:
> java.lang.NullPointerException
> 2014-01-02 12:04:43,891 ERROR [c.c.v.VmWorkJobDispatcher]
> (Job-Executor-14:ctx-ad5bbb25 ctx-2899d402) Unable to complete AsyncJobVO
> {id:47, userId: 2, accountId: 2, instanceType: null, instanceId: null, cmd:
> com.cloud.vm.VmWorkMigrate, cmdInfo:
> rO0ABXNyABpjb20uY2xvdWQudm0uVm1Xb3JrTWlncmF0ZRdxQXtPtzYqAgAGSgAJc3JjSG9zdElkTAAJY2x1c3RlcklkdAAQTGphdmEvbGFuZy9Mb25nO0wABmhvc3RJZHEAfgABTAAFcG9kSWRxAH4AAUwAB3N0b3JhZ2V0AA9MamF2YS91dGlsL01hcDtMAAZ6b25lSWRxAH4AAXhyABNjb20uY2xvdWQudm0uVm1Xb3Jrn5m2VvAlZ2sCAARKAAlhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAACAAIABXQAGVZpcnR1YWxNYWNoaW5lTWFuYWdlckltcGwAAXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAAAXNxAH4ABwAEcQB-AAlwcQB-AAk,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7145449848920, completeMsid: null, lastUpdated: null,
> lastPolled: null, created: Thu Jan 02 12:04:42 EST 2014}
> java.lang.NullPointerException
> at
> com.cloud.vm.VmWorkMigrate.getDeployDestination(VmWorkMigrate.java:60)
> at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateMigrate(VirtualMachineManagerImpl.java:4758)
> 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:616)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4855)
> at
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:99)
> at
> o
[jira] [Comment Edited] (CLOUDSTACK-5535) Do not allow addNetwork to create NIC across VPC tiers and Isolated Networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867094#comment-13867094 ] Marcus Sorensen edited comment on CLOUDSTACK-5535 at 1/9/14 9:33 PM: - I'm not sure about that, as VPC was in development at the same time we developed this (4.0) it's hard to say. I can say I was unaware that the deploy code was updated at some point to disallow multiple tiers. It just breaks primary scenarios that prompted us to contribute it to cloudstack in the first place, and one of the primary reasons we contribute to cloudstack, frankly, is to help us ensure compatibility going forward. Anything we have that isn't in the community version has to be maintained and re-patched by us everytime cloudstack changes. I'm not sure how this breaks ACLs. If I add a VM to two networks, it's explicitly because I want that. If we add in VM 3 into tier 1 and VM 4 into tier 2, they still cannot talk to each other, ACLs are respected as any VM *on* the network can only talk to VMs *on the same network*. Adding a VM to a network is not breaking ACLs, it's allowing flexibility to the admin to design their network how they choose. It's very common for real servers to be plugged into multiple networks/switches/vlans, why not allow that? was (Author: mlsorensen): I'm not sure about that, as VPC was in development at the same time we developed this (4.0) it's hard to say. I can say I was unaware that the deploy code was updated at some point to disallow multiple tiers. It just breaks primary scenarios that prompted us to contribute it to cloudstack in the first place, and one of the primary reasons we contribute to cloudstack, frankly, is to help us ensure compatibility going forward. Anything we have that isn't in the community version has to be maintained and re-patched by us everytime cloudstack changes. I'm not sure how this breaks ACLs. If I add a VM to two networks, it's explicitly because I want that. If we add in VM 3 into tier 1 and VM 4 into tier 2, they still cannot talk to each other, ACLs are respected as any VM *on* the network can only talk to VMs *on the same network*. Adding a VM to a network is not breaking ACLs, it's allowing flexibility to the admin to design their network how they choose. > Do not allow addNetwork to create NIC across VPC tiers and Isolated Networks > - > > Key: CLOUDSTACK-5535 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5535 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server >Affects Versions: 4.3.0 >Reporter: Saksham Srivastava >Assignee: Saksham Srivastava >Priority: Critical > Fix For: 4.3.0 > > > addNetworkToVM allows adding any network to VM. > Ideally a VM running in isolated Guest Network should not be able to add a > VPC tier. > A VM running in VPC tier should not be allowed to add another tier > A VM running in VPC tier should not be allowed to add another isolated guest > network. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5535) Do not allow addNetwork to create NIC across VPC tiers and Isolated Networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867094#comment-13867094 ] Marcus Sorensen commented on CLOUDSTACK-5535: - I'm not sure about that, as VPC was in development at the same time we developed this (4.0) it's hard to say. I can say I was unaware that the deploy code was updated at some point to disallow multiple tiers. It just breaks primary scenarios that prompted us to contribute it to cloudstack in the first place, and one of the primary reasons we contribute to cloudstack, frankly, is to help us ensure compatibility going forward. Anything we have that isn't in the community version has to be maintained and re-patched by us everytime cloudstack changes. I'm not sure how this breaks ACLs. If I add a VM to two networks, it's explicitly because I want that. If we add in VM 3 into tier 1 and VM 4 into tier 2, they still cannot talk to each other, ACLs are respected as any VM *on* the network can only talk to VMs *on the same network*. Adding a VM to a network is not breaking ACLs, it's allowing flexibility to the admin to design their network how they choose. > Do not allow addNetwork to create NIC across VPC tiers and Isolated Networks > - > > Key: CLOUDSTACK-5535 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5535 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server >Affects Versions: 4.3.0 >Reporter: Saksham Srivastava >Assignee: Saksham Srivastava >Priority: Critical > Fix For: 4.3.0 > > > addNetworkToVM allows adding any network to VM. > Ideally a VM running in isolated Guest Network should not be able to add a > VPC tier. > A VM running in VPC tier should not be allowed to add another tier > A VM running in VPC tier should not be allowed to add another isolated guest > network. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5502) [Automation] createVlanIpRange API failing, if you pass VLAN
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867090#comment-13867090
]
Animesh Chaturvedi commented on CLOUDSTACK-5502:
Daan we need to continue with older behavior as called out by Marcus, please
review and respond as this has been pending,
> [Automation] createVlanIpRange API failing, if you pass VLAN
> -
>
> Key: CLOUDSTACK-5502
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5502
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.3.0
> Environment: KVM Basic Zone with SG
>Reporter: Rayees Namathponnan
>Assignee: Daan Hoogland
>Priority: Blocker
> Fix For: 4.3.0
>
>
> This issue found in KVM basic zone with SG automation run; test cases from
> below suite filed
> integration.component.test_multiple_ip_ranges.
> Steps to reproduce
> Step 1 : Create basic zone with SG
> Step 2 : Crete IP VLAN Range with below command (pass vlan=untagged)
> http://xxx..xxx.xxx:8096/?command=createVlanIpRange&gateway=10.223.251.1&forvirtualnetwork=false&startip=10.223.251.3&podid=0253bcbf-e636-4776-9e8c-216b70d195a2&zoneid=a9912aa8-a231-44d9-a70b-9d53e6db2d27&netmask=255.255.255.192&vlan=untagged
> Result;
> API command failed with error
> { "createvlaniprangeresponse" :
> {"uuidList":[],"errorcode":431,"cserrorcode":4350,"errortext":"Vlan doesn't
> match vlan of the network"} }
> this API command works only, if you are not passing any VLAN
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5485) Vmware - Whe 10 hourly snapshots are scheduled at the same time , we see only 5 of them being processed actively at the same time.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867085#comment-13867085 ] Animesh Chaturvedi commented on CLOUDSTACK-5485: Sangeetha can you review the comments from Likitha on the design limitation. I think we may have to push this out to 4.4 > Vmware - Whe 10 hourly snapshots are scheduled at the same time , we see only > 5 of them being processed actively at the same time. > --- > > Key: CLOUDSTACK-5485 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5485 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Likitha Shetty >Priority: Critical > Fix For: 4.3.0 > > Attachments: vmware.rar > > > Vmware - When 10 hourly snapshots are scheduled at the same time , we see > only 5 of them being processed actively at the same time. > Set up : > Advanced Zone with 2 5.1 ESXI hosts. > Steps to reproduce the problem: > 1. Deploy 5 Vms in each of the hosts , so we start with 10 Vms. > 2. Start concurrent snapshots for ROOT volumes of all the Vms. > Noticed that on the Vsphere client , only 5 of these snapshots gets executed > in parallel.Rest of them get picked up when the current snapshot jobs > complete. > Why cant we do more than 5 parallel tasks ? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5734) Console not working for SSVM CPVM VR guest VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867076#comment-13867076 ] Rayees Namathponnan commented on CLOUDSTACK-5734: - I am facing same issue in KVM with latest build > Console not working for SSVM CPVM VR guest VMs > -- > > Key: CLOUDSTACK-5734 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5734 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: MS4.3 release 1/2/14 > vcenter 5.5 host1 ESXi 5.5 host2 ESXi 5.5 >Reporter: angeline shen >Assignee: Santhosh Kumar Edukulla >Priority: Blocker > Fix For: 4.3.0 > > Attachments: CLOUDSTACK-5734.png, management-server(1).log.gz, > vm43.png > > > 1. advance zone. Create VPC, VPC network, create VMs > 2. create windows 2008R2 iso -based VM > 3. Open console to SSVM CPVMVRguest VMs - blank -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5850) [vmware] Vcenter 5.5 host ESXi 5.5 VMsnapshot - attach datadisk for VMs that have VM snapshot result in screenful JAVA errors
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Animesh Chaturvedi updated CLOUDSTACK-5850:
---
Assignee: Likitha Shetty
> [vmware] Vcenter 5.5 host ESXi 5.5 VMsnapshot - attach datadisk for VMs that
> have VM snapshot result in screenful JAVA errors
> ---
>
> Key: CLOUDSTACK-5850
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5850
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: MS build 1/8/2014
> vcenter 5.5 host1 host2 ESXi 5.5
>Reporter: angeline shen
>Assignee: Likitha Shetty
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: management-server(4).log.gz, vm11.png
>
>
> 1. advance zone.create VMs.
> 2. VM1 create VM snapshot.
> 3. create volume vol1.attach vol1 to VM1
> result:
> sreenful of JAVA errors dispalyed
> MS log:
> 2014-01-09 11:52:54,808 ERROR [c.c.v.VmWorkJobHandlerProxy]
> (Job-Executor-51:ctx-38b7725a ctx-56558271) Invocation exception, caused by:
> com.cloud.exception.InvalidParameterValueException: Unable to atta
> ch volume, please specify a VM that does not have VM snapshots
> 2014-01-09 11:52:54,809 ERROR [c.c.v.VmWorkJobDispatcher]
> (Job-Executor-51:ctx-38b7725a ctx-56558271) Unable to complete AsyncJobVO
> {id:170, userId: 2, accountId: 2, instanceType: null, instanceId: null,
> cmd: com.cloud.storage.VmWorkAttachVolume, cmdInfo:
> rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtBdHRhY2hWb2x1bWUHra_5YYfiHAIAAkwACGRldmljZUlkdAAQTGphdmEvbGFuZy9Mb25nO0wACHZvbHVtZUlkcQB-AAF4cgATY29tLmNsb3
> VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACAAN0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbHBzcgAOamF2YS5sYW5nLkxvb
> mc7i-SQzI8j3wIAAUoABXZhbHVleHIAEGphdmEubGFuZy5OdW1iZXKGrJUdC5TgiwIAAHhwAA4,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7425730021290, completeMsi
> d: null, lastUpdated: null, lastPolled: null, created: Thu Jan 09 11:52:53
> PST 2014}, job origin:56558271-286a-4205-b7af-a6974d16c0e7
> com.cloud.exception.InvalidParameterValueException: Unable to attach volume,
> please specify a VM that does not have VM snapshots
> at
> com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1193)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1125)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:2400)
> 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:616)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2431)
> at sun.reflect.GeneratedMethodAccessor374.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> 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 sun.proxy.$Proxy195.handleVmWorkJob(Unknown Source)
> at
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:101)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:524)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedC
[jira] [Commented] (CLOUDSTACK-5651) deployVm: customparameters param name has to be changed
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867067#comment-13867067 ] Animesh Chaturvedi commented on CLOUDSTACK-5651: Bharat If you put a bug for InReview do include reviewboard link. Please add it now > deployVm: customparameters param name has to be changed > --- > > Key: CLOUDSTACK-5651 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5651 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Alena Prokharchyk >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.3.0 > > > deployVm API got a new param in 4.3 -“customparameters”. The description of > the parameter is very vague and generic “used to specify the custom > parameters”. > Is it just the metadata in form of value/key pairs? If so, please change the > name to “details” - the generic name used when specify key/value metadata in > other API commands. > Also you need to save this information in the “user_vm_details” table, and > return it in the UserVmResponse, “details” map parameter. I don’t see “custom > parameters” key map being returned anywhere in the UserVmResponse. Its very > confusing, because whatever is passed to the Create/Update call, should be > returned in the response as well. > It all has to be fixed in 4.3 branch. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5535) Do not allow addNetwork to create NIC across VPC tiers and Isolated Networks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867063#comment-13867063 ] Alena Prokharchyk commented on CLOUDSTACK-5535: --- Marcus, We do allow adding nic from Shared network to the VPC. Here are the scenarios we support: 1) Vm is part of VPC network 2) Vm is part of VPC network + (1-n) number of Shared networks All other scenarios are not supported, and deployVm call always made this check. Only addNic was error prone call. So your core feature was written based on the buggy CS behavior. Now why don't we allow it. The entire purpose of vpc is to control traffic from one tier to another (by NetworkACL rules on the VPCVR). If vm is a part of 2 vpc tiers, this control gets broken. Think about like that: 1) VPC has tier1 and tier2 2) Vm1 belongs to tier1, VM2 belongs to tier2. 3) Network ACL restricts ingress traffic from tier1 to tier2, so vm1 can't access vm2. 4) introduce vm1 to tier2 by plugging nic of that tier. Now vm1 can access vm2 as they are the part of another network now, and networkACL is not respected. The entire VPC concept gets broken right here. Let me know if what I said needs more clarification. > Do not allow addNetwork to create NIC across VPC tiers and Isolated Networks > - > > Key: CLOUDSTACK-5535 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5535 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Management Server >Affects Versions: 4.3.0 >Reporter: Saksham Srivastava >Assignee: Saksham Srivastava >Priority: Critical > Fix For: 4.3.0 > > > addNetworkToVM allows adding any network to VM. > Ideally a VM running in isolated Guest Network should not be able to add a > VPC tier. > A VM running in VPC tier should not be allowed to add another tier > A VM running in VPC tier should not be allowed to add another isolated guest > network. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-5849) Unable to delete the network after upgrading from 3.0.6 to 4.3
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alena Prokharchyk reassigned CLOUDSTACK-5849:
-
Assignee: Alena Prokharchyk (was: Murali Reddy)
> Unable to delete the network after upgrading from 3.0.6 to 4.3
> --
>
> Key: CLOUDSTACK-5849
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5849
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller, Network Devices
>Affects Versions: 4.3.0
> Environment: upgraded from 3.0.6 patch E to 4.3
>Reporter: manasaveloori
>Assignee: Alena Prokharchyk
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: management-server306.log.rar, management-server4.3.rar,
> mysqldump306PatchE.dmp, mysqldump4.3.dmp
>
>
> Steps:
> 1. Deployed CS 3.0.6 Patch E with Xen 6.0.2 HV.
> 2. Created the service offering for netscaler device.
> 3. Added incompatible version of Netscaler. added NS10.1: Build 120.1316
> to CS 3.0.6 build.
> it was success.
> 4. Now created the network using the service offering created in step 2.
> 5. Observed that the network went into shut down state as the netscaler
> failed to implement the network.
> 6. Removed the netscaler device from CS and disabled the service offering.
> 7. Now there were no VMs associated to that network.Tried to delete the
> network.But it failed as the network was not in correct state.
> Note: issue existed in 3.0.6 that network is not deleted if it is in shutdown
> state.
> 2014-01-07 21:32:09,720 DEBUG [agent.manager.AgentManagerImpl]
> (RouterMonitor-1:null) Details from executing class
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-01-07 21:32:09,720 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null)
> Recieved and Sent bytes are both 0. Not updating user_statistics
> 2014-01-07 21:32:11,498 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-5:null) Ping from 8
> 2014-01-07 21:32:11,917 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-6:null) Ping from 5
> 2014-01-07 21:32:12,164 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-19:null) submit async job-75, job: AsyncJobVO {id:75, userId:
> 2, accountId: 2, sessionKey: null, instanceType: null, instanceId: null, cmd:
> com.cloud.api.commands.DeleteNetworkCmd, cmdOriginator: null, cmdVersion: 0,
> callbackType: 0, callbackAddress: null, status: 0, processStatus: 0,
> resultCode: 0, result: null, initMsid: 6642334695485, completeMsid: null,
> lastUpdated: null, lastPolled: null, created: null}
> 2014-01-07 21:32:12,169 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Executing com.cloud.api.commands.DeleteNetworkCmd
> for job-75
> 2014-01-07 21:32:12,179 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Sync job-75 execution on object network.216
> 2014-01-07 21:32:12,188 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) job com.cloud.api.commands.DeleteNetworkCmd for
> job-75 was queued, processing the queue.
> 2014-01-07 21:32:12,197 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Executing sync queue item: SyncQueueItemVO {id:17,
> queueId: 17, contentType: AsyncJob, contentId: 75, lastProcessMsid:
> 6642334695485, lastprocessNumber: 1, lastProcessTime: Tue Jan 07 21:32:12 IST
> 2014, created: Tue Jan 07 21:32:12 IST 2014}
> 2014-01-07 21:32:12,199 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Schedule queued job-75
> 2014-01-07 21:32:12,207 DEBUG [cloud.async.SyncQueueManagerImpl]
> (Job-Executor-69:job-75) There is a pending process in sync queue(id: 17)
> 2014-01-07 21:32:12,210 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-70:job-75) Executing com.cloud.api.commands.DeleteNetworkCmd
> for job-75
> 2014-01-07 21:32:12,233 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-70:job-75) Network is not implemented: Ntwk[216|Guest|17]
> 2014-01-07 21:32:12,233 DEBUG [db.Transaction.Transaction]
> (Job-Executor-70:job-75) Rolling back the transaction: Time = 1 Name =
> -AsyncJobManagerImpl$1.run:396-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679;
> called by
> -Transaction.rollback:854-Transaction.removeUpTo:797-Transaction.close:621-DatabaseCallback.interceptComplete:67-DatabaseCallback.intercept:32-NetworkManagerImpl.destroyNetwork:3799-DatabaseCallback.intercept:30-NetworkManagerImpl.deleteNetwork:3656-ActionEventCallback.intercept:32-DeleteNetworkCmd.execute:65-ApiDispatcher.dispatch:263-AsyncJobManagerImpl$1.run:430
> 20
[jira] [Updated] (CLOUDSTACK-5849) Failed to shutdown the network when corresponding External LB provider gets Disabled while still in use by the network
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alena Prokharchyk updated CLOUDSTACK-5849:
--
Summary: Failed to shutdown the network when corresponding External LB
provider gets Disabled while still in use by the network (was: Unable to
delete the network after upgrading from 3.0.6 to 4.3)
> Failed to shutdown the network when corresponding External LB provider gets
> Disabled while still in use by the network
> --
>
> Key: CLOUDSTACK-5849
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5849
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller, Network Devices
>Affects Versions: 4.3.0
> Environment: upgraded from 3.0.6 patch E to 4.3
>Reporter: manasaveloori
>Assignee: Alena Prokharchyk
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: management-server306.log.rar, management-server4.3.rar,
> mysqldump306PatchE.dmp, mysqldump4.3.dmp
>
>
> Steps:
> 1. Deployed CS 3.0.6 Patch E with Xen 6.0.2 HV.
> 2. Created the service offering for netscaler device.
> 3. Added incompatible version of Netscaler. added NS10.1: Build 120.1316
> to CS 3.0.6 build.
> it was success.
> 4. Now created the network using the service offering created in step 2.
> 5. Observed that the network went into shut down state as the netscaler
> failed to implement the network.
> 6. Removed the netscaler device from CS and disabled the service offering.
> 7. Now there were no VMs associated to that network.Tried to delete the
> network.But it failed as the network was not in correct state.
> Note: issue existed in 3.0.6 that network is not deleted if it is in shutdown
> state.
> 2014-01-07 21:32:09,720 DEBUG [agent.manager.AgentManagerImpl]
> (RouterMonitor-1:null) Details from executing class
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-01-07 21:32:09,720 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null)
> Recieved and Sent bytes are both 0. Not updating user_statistics
> 2014-01-07 21:32:11,498 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-5:null) Ping from 8
> 2014-01-07 21:32:11,917 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-6:null) Ping from 5
> 2014-01-07 21:32:12,164 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-19:null) submit async job-75, job: AsyncJobVO {id:75, userId:
> 2, accountId: 2, sessionKey: null, instanceType: null, instanceId: null, cmd:
> com.cloud.api.commands.DeleteNetworkCmd, cmdOriginator: null, cmdVersion: 0,
> callbackType: 0, callbackAddress: null, status: 0, processStatus: 0,
> resultCode: 0, result: null, initMsid: 6642334695485, completeMsid: null,
> lastUpdated: null, lastPolled: null, created: null}
> 2014-01-07 21:32:12,169 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Executing com.cloud.api.commands.DeleteNetworkCmd
> for job-75
> 2014-01-07 21:32:12,179 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Sync job-75 execution on object network.216
> 2014-01-07 21:32:12,188 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) job com.cloud.api.commands.DeleteNetworkCmd for
> job-75 was queued, processing the queue.
> 2014-01-07 21:32:12,197 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Executing sync queue item: SyncQueueItemVO {id:17,
> queueId: 17, contentType: AsyncJob, contentId: 75, lastProcessMsid:
> 6642334695485, lastprocessNumber: 1, lastProcessTime: Tue Jan 07 21:32:12 IST
> 2014, created: Tue Jan 07 21:32:12 IST 2014}
> 2014-01-07 21:32:12,199 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Schedule queued job-75
> 2014-01-07 21:32:12,207 DEBUG [cloud.async.SyncQueueManagerImpl]
> (Job-Executor-69:job-75) There is a pending process in sync queue(id: 17)
> 2014-01-07 21:32:12,210 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-70:job-75) Executing com.cloud.api.commands.DeleteNetworkCmd
> for job-75
> 2014-01-07 21:32:12,233 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-70:job-75) Network is not implemented: Ntwk[216|Guest|17]
> 2014-01-07 21:32:12,233 DEBUG [db.Transaction.Transaction]
> (Job-Executor-70:job-75) Rolling back the transaction: Time = 1 Name =
> -AsyncJobManagerImpl$1.run:396-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679;
> called by
> -Transaction.rollback:854-Transaction.removeUpTo:797-Transaction.close:621-DatabaseCallback.interceptComplete:6
[jira] [Assigned] (CLOUDSTACK-5849) Unable to delete the network after upgrading from 3.0.6 to 4.3
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alena Prokharchyk reassigned CLOUDSTACK-5849:
-
Assignee: Murali Reddy (was: Alena Prokharchyk)
> Unable to delete the network after upgrading from 3.0.6 to 4.3
> --
>
> Key: CLOUDSTACK-5849
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5849
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller, Network Devices
>Affects Versions: 4.3.0
> Environment: upgraded from 3.0.6 patch E to 4.3
>Reporter: manasaveloori
>Assignee: Murali Reddy
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: management-server306.log.rar, management-server4.3.rar,
> mysqldump306PatchE.dmp, mysqldump4.3.dmp
>
>
> Steps:
> 1. Deployed CS 3.0.6 Patch E with Xen 6.0.2 HV.
> 2. Created the service offering for netscaler device.
> 3. Added incompatible version of Netscaler. added NS10.1: Build 120.1316
> to CS 3.0.6 build.
> it was success.
> 4. Now created the network using the service offering created in step 2.
> 5. Observed that the network went into shut down state as the netscaler
> failed to implement the network.
> 6. Removed the netscaler device from CS and disabled the service offering.
> 7. Now there were no VMs associated to that network.Tried to delete the
> network.But it failed as the network was not in correct state.
> Note: issue existed in 3.0.6 that network is not deleted if it is in shutdown
> state.
> 2014-01-07 21:32:09,720 DEBUG [agent.manager.AgentManagerImpl]
> (RouterMonitor-1:null) Details from executing class
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-01-07 21:32:09,720 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null)
> Recieved and Sent bytes are both 0. Not updating user_statistics
> 2014-01-07 21:32:11,498 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-5:null) Ping from 8
> 2014-01-07 21:32:11,917 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-6:null) Ping from 5
> 2014-01-07 21:32:12,164 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-19:null) submit async job-75, job: AsyncJobVO {id:75, userId:
> 2, accountId: 2, sessionKey: null, instanceType: null, instanceId: null, cmd:
> com.cloud.api.commands.DeleteNetworkCmd, cmdOriginator: null, cmdVersion: 0,
> callbackType: 0, callbackAddress: null, status: 0, processStatus: 0,
> resultCode: 0, result: null, initMsid: 6642334695485, completeMsid: null,
> lastUpdated: null, lastPolled: null, created: null}
> 2014-01-07 21:32:12,169 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Executing com.cloud.api.commands.DeleteNetworkCmd
> for job-75
> 2014-01-07 21:32:12,179 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Sync job-75 execution on object network.216
> 2014-01-07 21:32:12,188 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) job com.cloud.api.commands.DeleteNetworkCmd for
> job-75 was queued, processing the queue.
> 2014-01-07 21:32:12,197 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Executing sync queue item: SyncQueueItemVO {id:17,
> queueId: 17, contentType: AsyncJob, contentId: 75, lastProcessMsid:
> 6642334695485, lastprocessNumber: 1, lastProcessTime: Tue Jan 07 21:32:12 IST
> 2014, created: Tue Jan 07 21:32:12 IST 2014}
> 2014-01-07 21:32:12,199 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Schedule queued job-75
> 2014-01-07 21:32:12,207 DEBUG [cloud.async.SyncQueueManagerImpl]
> (Job-Executor-69:job-75) There is a pending process in sync queue(id: 17)
> 2014-01-07 21:32:12,210 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-70:job-75) Executing com.cloud.api.commands.DeleteNetworkCmd
> for job-75
> 2014-01-07 21:32:12,233 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-70:job-75) Network is not implemented: Ntwk[216|Guest|17]
> 2014-01-07 21:32:12,233 DEBUG [db.Transaction.Transaction]
> (Job-Executor-70:job-75) Rolling back the transaction: Time = 1 Name =
> -AsyncJobManagerImpl$1.run:396-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679;
> called by
> -Transaction.rollback:854-Transaction.removeUpTo:797-Transaction.close:621-DatabaseCallback.interceptComplete:67-DatabaseCallback.intercept:32-NetworkManagerImpl.destroyNetwork:3799-DatabaseCallback.intercept:30-NetworkManagerImpl.deleteNetwork:3656-ActionEventCallback.intercept:32-DeleteNetworkCmd.execute:65-ApiDispatcher.dispatch:263-AsyncJobManagerImpl$1.run:430
> 2014-01
[jira] [Commented] (CLOUDSTACK-5849) Unable to delete the network after upgrading from 3.0.6 to 4.3
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13867040#comment-13867040
]
Alena Prokharchyk commented on CLOUDSTACK-5849:
---
It has nothing to do with the Netscaler versioning. Netscaler serves as and LB
provider for certain networks:
mysql> select * from ntwk_service_map where provider not like '%VirtualRouter%'
and service='Lb' and network_id in (select id from networks where removed is
null);
+++-+---+-+
| id | network_id | service | provider | created |
+++-+---+-+
| 76 |216 | Lb | Netscaler | 2014-01-07 15:58:21 |
| 83 |217 | Lb | Netscaler | 2014-01-07 15:59:54 |
+++-+---+-+
2 rows in set (0.00 sec)
Then some time along the way (may be in 3.0.6) the provider was disabled on the
physical network:
mysql> select provider_name, state, removed from
physical_network_service_providers where provider_name='Netscaler';
+---+--+-+
| provider_name | state| removed |
+---+--+-+
| Netscaler | Disabled | NULL|
| Netscaler | Disabled | NULL|
+---+--+-+
2 rows in set (0.00 sec)
Not sure if because of that, but the netscaler was removed from the
netscaler/network references:
mysql> select * from network_external_lb_device_map;
Empty set (0.00 sec)
When the network gets shutdown, the call expects the reference to be there.
When it can't be found, it results in the Exception.
This bug most likely has nothing to do with the upgrade. Murali, assigning it
to you as you wrote External Devices logic, and you know the expected
behavior/original design better.
>From my point of view, we shouldn't delete the references when there are
>active networks still using it. If so, you should fix the upgrade code to add
>the references back to network_external_lb_device_map table.
> Unable to delete the network after upgrading from 3.0.6 to 4.3
> --
>
> Key: CLOUDSTACK-5849
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5849
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller, Network Devices
>Affects Versions: 4.3.0
> Environment: upgraded from 3.0.6 patch E to 4.3
>Reporter: manasaveloori
>Assignee: Alena Prokharchyk
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: management-server306.log.rar, management-server4.3.rar,
> mysqldump306PatchE.dmp, mysqldump4.3.dmp
>
>
> Steps:
> 1. Deployed CS 3.0.6 Patch E with Xen 6.0.2 HV.
> 2. Created the service offering for netscaler device.
> 3. Added incompatible version of Netscaler. added NS10.1: Build 120.1316
> to CS 3.0.6 build.
> it was success.
> 4. Now created the network using the service offering created in step 2.
> 5. Observed that the network went into shut down state as the netscaler
> failed to implement the network.
> 6. Removed the netscaler device from CS and disabled the service offering.
> 7. Now there were no VMs associated to that network.Tried to delete the
> network.But it failed as the network was not in correct state.
> Note: issue existed in 3.0.6 that network is not deleted if it is in shutdown
> state.
> 2014-01-07 21:32:09,720 DEBUG [agent.manager.AgentManagerImpl]
> (RouterMonitor-1:null) Details from executing class
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-01-07 21:32:09,720 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null)
> Recieved and Sent bytes are both 0. Not updating user_statistics
> 2014-01-07 21:32:11,498 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-5:null) Ping from 8
> 2014-01-07 21:32:11,917 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-6:null) Ping from 5
> 2014-01-07 21:32:12,164 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-19:null) submit async job-75, job: AsyncJobVO {id:75, userId:
> 2, accountId: 2, sessionKey: null, instanceType: null, instanceId: null, cmd:
> com.cloud.api.commands.DeleteNetworkCmd, cmdOriginator: null, cmdVersion: 0,
> callbackType: 0, callbackAddress: null, status: 0, processStatus: 0,
> resultCode: 0, result: null, initMsid: 6642334695485, completeMsid: null,
> lastUpdated: null, lastPolled: null, created: null}
> 2014-01-07 21:32:12,169 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Executing com.cloud.api.commands.DeleteNetworkCmd
> for job-75
> 2014-01-07 21:32:12,179 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Execut
[jira] [Updated] (CLOUDSTACK-5850) [vmware] Vcenter 5.5 host ESXi 5.5 VMsnapshot - attach datadisk for VMs that have VM snapshot result in screenful JAVA errors
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angeline shen updated CLOUDSTACK-5850:
--
Attachment: management-server(4).log.gz
> [vmware] Vcenter 5.5 host ESXi 5.5 VMsnapshot - attach datadisk for VMs that
> have VM snapshot result in screenful JAVA errors
> ---
>
> Key: CLOUDSTACK-5850
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5850
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: MS build 1/8/2014
> vcenter 5.5 host1 host2 ESXi 5.5
>Reporter: angeline shen
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: management-server(4).log.gz, vm11.png
>
>
> 1. advance zone.create VMs.
> 2. VM1 create VM snapshot.
> 3. create volume vol1.attach vol1 to VM1
> result:
> sreenful of JAVA errors dispalyed
> MS log:
> 2014-01-09 11:52:54,808 ERROR [c.c.v.VmWorkJobHandlerProxy]
> (Job-Executor-51:ctx-38b7725a ctx-56558271) Invocation exception, caused by:
> com.cloud.exception.InvalidParameterValueException: Unable to atta
> ch volume, please specify a VM that does not have VM snapshots
> 2014-01-09 11:52:54,809 ERROR [c.c.v.VmWorkJobDispatcher]
> (Job-Executor-51:ctx-38b7725a ctx-56558271) Unable to complete AsyncJobVO
> {id:170, userId: 2, accountId: 2, instanceType: null, instanceId: null,
> cmd: com.cloud.storage.VmWorkAttachVolume, cmdInfo:
> rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtBdHRhY2hWb2x1bWUHra_5YYfiHAIAAkwACGRldmljZUlkdAAQTGphdmEvbGFuZy9Mb25nO0wACHZvbHVtZUlkcQB-AAF4cgATY29tLmNsb3
> VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACAAN0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbHBzcgAOamF2YS5sYW5nLkxvb
> mc7i-SQzI8j3wIAAUoABXZhbHVleHIAEGphdmEubGFuZy5OdW1iZXKGrJUdC5TgiwIAAHhwAA4,
> cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
> null, initMsid: 7425730021290, completeMsi
> d: null, lastUpdated: null, lastPolled: null, created: Thu Jan 09 11:52:53
> PST 2014}, job origin:56558271-286a-4205-b7af-a6974d16c0e7
> com.cloud.exception.InvalidParameterValueException: Unable to attach volume,
> please specify a VM that does not have VM snapshots
> at
> com.cloud.storage.VolumeApiServiceImpl.attachVolumeToVM(VolumeApiServiceImpl.java:1193)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:1125)
> at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateAttachVolumeToVM(VolumeApiServiceImpl.java:2400)
> 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:616)
> at
> com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
> at
> com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2431)
> at sun.reflect.GeneratedMethodAccessor374.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> 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 sun.proxy.$Proxy195.handleVmWorkJob(Unknown Source)
> at
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:101)
> at
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:524)
> at
> org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedConte
[jira] [Assigned] (CLOUDSTACK-5849) Unable to delete the network after upgrading from 3.0.6 to 4.3
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alena Prokharchyk reassigned CLOUDSTACK-5849:
-
Assignee: Alena Prokharchyk
> Unable to delete the network after upgrading from 3.0.6 to 4.3
> --
>
> Key: CLOUDSTACK-5849
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5849
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller, Network Devices
>Affects Versions: 4.3.0
> Environment: upgraded from 3.0.6 patch E to 4.3
>Reporter: manasaveloori
>Assignee: Alena Prokharchyk
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: management-server306.log.rar, management-server4.3.rar,
> mysqldump306PatchE.dmp, mysqldump4.3.dmp
>
>
> Steps:
> 1. Deployed CS 3.0.6 Patch E with Xen 6.0.2 HV.
> 2. Created the service offering for netscaler device.
> 3. Added incompatible version of Netscaler. added NS10.1: Build 120.1316
> to CS 3.0.6 build.
> it was success.
> 4. Now created the network using the service offering created in step 2.
> 5. Observed that the network went into shut down state as the netscaler
> failed to implement the network.
> 6. Removed the netscaler device from CS and disabled the service offering.
> 7. Now there were no VMs associated to that network.Tried to delete the
> network.But it failed as the network was not in correct state.
> Note: issue existed in 3.0.6 that network is not deleted if it is in shutdown
> state.
> 2014-01-07 21:32:09,720 DEBUG [agent.manager.AgentManagerImpl]
> (RouterMonitor-1:null) Details from executing class
> com.cloud.agent.api.NetworkUsageCommand:
> 2014-01-07 21:32:09,720 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl] (RouterMonitor-1:null)
> Recieved and Sent bytes are both 0. Not updating user_statistics
> 2014-01-07 21:32:11,498 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-5:null) Ping from 8
> 2014-01-07 21:32:11,917 DEBUG [agent.manager.AgentManagerImpl]
> (AgentManager-Handler-6:null) Ping from 5
> 2014-01-07 21:32:12,164 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-19:null) submit async job-75, job: AsyncJobVO {id:75, userId:
> 2, accountId: 2, sessionKey: null, instanceType: null, instanceId: null, cmd:
> com.cloud.api.commands.DeleteNetworkCmd, cmdOriginator: null, cmdVersion: 0,
> callbackType: 0, callbackAddress: null, status: 0, processStatus: 0,
> resultCode: 0, result: null, initMsid: 6642334695485, completeMsid: null,
> lastUpdated: null, lastPolled: null, created: null}
> 2014-01-07 21:32:12,169 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Executing com.cloud.api.commands.DeleteNetworkCmd
> for job-75
> 2014-01-07 21:32:12,179 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Sync job-75 execution on object network.216
> 2014-01-07 21:32:12,188 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) job com.cloud.api.commands.DeleteNetworkCmd for
> job-75 was queued, processing the queue.
> 2014-01-07 21:32:12,197 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Executing sync queue item: SyncQueueItemVO {id:17,
> queueId: 17, contentType: AsyncJob, contentId: 75, lastProcessMsid:
> 6642334695485, lastprocessNumber: 1, lastProcessTime: Tue Jan 07 21:32:12 IST
> 2014, created: Tue Jan 07 21:32:12 IST 2014}
> 2014-01-07 21:32:12,199 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-69:job-75) Schedule queued job-75
> 2014-01-07 21:32:12,207 DEBUG [cloud.async.SyncQueueManagerImpl]
> (Job-Executor-69:job-75) There is a pending process in sync queue(id: 17)
> 2014-01-07 21:32:12,210 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-70:job-75) Executing com.cloud.api.commands.DeleteNetworkCmd
> for job-75
> 2014-01-07 21:32:12,233 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-70:job-75) Network is not implemented: Ntwk[216|Guest|17]
> 2014-01-07 21:32:12,233 DEBUG [db.Transaction.Transaction]
> (Job-Executor-70:job-75) Rolling back the transaction: Time = 1 Name =
> -AsyncJobManagerImpl$1.run:396-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRun:334-FutureTask.run:166-ThreadPoolExecutor.runWorker:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679;
> called by
> -Transaction.rollback:854-Transaction.removeUpTo:797-Transaction.close:621-DatabaseCallback.interceptComplete:67-DatabaseCallback.intercept:32-NetworkManagerImpl.destroyNetwork:3799-DatabaseCallback.intercept:30-NetworkManagerImpl.deleteNetwork:3656-ActionEventCallback.intercept:32-DeleteNetworkCmd.execute:65-ApiDispatcher.dispatch:263-AsyncJobManagerImpl$1.run:430
> 2014-01-07 21:32:12,235
