[jira] [Updated] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-7364: --- Fix Version/s: (was: 4.6.0) Future NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Fix For: Future Attachments: 10_1NS_vlan_ip_if.png, 10_5_NS_vlan_ip_if.png, management-server.log.debug.gz, screenshot-1.png, screenshot-2.png When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8672) NCC Integration with CloudStack
Rajesh Battala created CLOUDSTACK-8672: -- Summary: NCC Integration with CloudStack Key: CLOUDSTACK-8672 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8672 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Network Devices Affects Versions: 4.6.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8673) NS-Vpx LifeCycle with CloudStack
Rajesh Battala created CLOUDSTACK-8673: -- Summary: NS-Vpx LifeCycle with CloudStack Key: CLOUDSTACK-8673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8673 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller, Network Devices Affects Versions: 4.6.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8275) Deploying vApp(Stack of services/instances) with user defined template from CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14349711#comment-14349711 ] Rajesh Battala commented on CLOUDSTACK-8275: Hi Buddhika, you get familiar with cloudstack before the selection process beguns, it would be easily achievable. the wiki link has all the info for the beginners. if you face issues you can discuss on the mailing list there are many people ready to help with your issue Thanks Rajesh Battala Deploying vApp(Stack of services/instances) with user defined template from CloudStack -- Key: CLOUDSTACK-8275 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8275 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Rajesh Battala Labels: gsoc2015 Fix For: 4.5.0 This idea will help the cloud admin/user to deploy the Stack of instance which can act as his service solution. Use Case: Suppose cloud admin/user wants to deploy a web service portal and he has presentation template, logic tier template and database template. In the present situation, the user had to provision Vm from each template and then do the configuration so that they can logically act as one service stack. He has to create a network (deployVR) then he has to deploy multiple instances from each template and then later configure them to act as one solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8275) Deploying vApp(Stack of services/instances) with user defined template from CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14348948#comment-14348948 ] Rajesh Battala commented on CLOUDSTACK-8275: Hi, great to see your interest in cloudstack. I would like to know whether you are interested to implement this feature or someother feature? this should help you starting. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Development+101 Deploying vApp(Stack of services/instances) with user defined template from CloudStack -- Key: CLOUDSTACK-8275 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8275 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Rajesh Battala Labels: gsoc2015 Fix For: 4.5.0 This idea will help the cloud admin/user to deploy the Stack of instance which can act as his service solution. Use Case: Suppose cloud admin/user wants to deploy a web service portal and he has presentation template, logic tier template and database template. In the present situation, the user had to provision Vm from each template and then do the configuration so that they can logically act as one service stack. He has to create a network (deployVR) then he has to deploy multiple instances from each template and then later configure them to act as one solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8275) Deploying vApp(Stack of services/instances) with user defined template from CloudStack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14348947#comment-14348947 ] Rajesh Battala commented on CLOUDSTACK-8275: Hi, great to see your interest in cloudstack. I would like to know whether you are interested to implement this feature or someother feature? this should help you starting. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Development+101 Deploying vApp(Stack of services/instances) with user defined template from CloudStack -- Key: CLOUDSTACK-8275 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8275 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Rajesh Battala Labels: gsoc2015 Fix For: 4.5.0 This idea will help the cloud admin/user to deploy the Stack of instance which can act as his service solution. Use Case: Suppose cloud admin/user wants to deploy a web service portal and he has presentation template, logic tier template and database template. In the present situation, the user had to provision Vm from each template and then do the configuration so that they can logically act as one service stack. He has to create a network (deployVR) then he has to deploy multiple instances from each template and then later configure them to act as one solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8275) Deploying vApp(Stack of services/instances) with user defined template from CloudStack
Rajesh Battala created CLOUDSTACK-8275: -- Summary: Deploying vApp(Stack of services/instances) with user defined template from CloudStack Key: CLOUDSTACK-8275 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8275 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Rajesh Battala Fix For: 4.5.0 This idea will help the cloud admin/user to deploy the Stack of instance which can act as his service solution. Use Case: Suppose cloud admin/user wants to deploy a web service portal and he has presentation template, logic tier template and database template. In the present situation, the user had to provision Vm from each template and then do the configuration so that they can logically act as one service stack. He has to create a network (deployVR) then he has to deploy multiple instances from each template and then later configure them to act as one solution. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8266) Automatic workload Management in the clusters Managed by CloudStack for efficient host Management.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14328700#comment-14328700 ] Rajesh Battala commented on CLOUDSTACK-8266: Thanks for Nice Suggestions Automatic workload Management in the clusters Managed by CloudStack for efficient host Management. -- Key: CLOUDSTACK-8266 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8266 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server Affects Versions: 4.5.0 Environment: Java, Linux, Hypervisor Reporter: Rajesh Battala Labels: gsoc2015 Fix For: 4.5.0 CloudStack manages hypervisor hosts as clusters. It will deploy the vm's to ensure proper hosts capacity are used max. Due to some operations by user on vm's like stop/migrate/destroy hosts usage in the clusters will be in inefficient state. To solve this issue we can have a new Manager who will regularly checks host capacity and implement Server Consolidtion by taking the actions: 1. Live migrate the vm's if possible along with storage. Migrate them such that hosts are fully utilized. 2. After redistributing the vm's Shutdown the hosts which are empty. 3. When load is getting increased,power-on the hosts remotely by WOL(Wake On Lan) mechanisam. This idea is discussed and presented in Collab Conference 2014. Here is the youtube link https://www.youtube.com/watch?v=hJKdZcSpGNQ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8266) Automatic workload Management in the clusters Managed by CloudStack for efficient host Management.
Rajesh Battala created CLOUDSTACK-8266: -- Summary: Automatic workload Management in the clusters Managed by CloudStack for efficient host Management. Key: CLOUDSTACK-8266 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8266 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server Affects Versions: 4.5.0 Environment: Java, Linux, Hypervisor Reporter: Rajesh Battala Fix For: 4.5.0 CloudStack manages hypervisor hosts as clusters. It will deploy the vm's to ensure proper hosts capacity are used max. Due to some operations by user on vm's like stop/migrate/destroy hosts usage in the clusters will be in inefficient state. To solve this issue we can have a new Manager who will regularly checks host capacity and implement Server Consolidtion by taking the actions: 1. Live migrate the vm's if possible along with storage. Migrate them such that hosts are fully utilized. 2. After redistributing the vm's Shutdown the hosts which are empty. 3. When load is getting increased,power-on the hosts remotely by WOL(Wake On Lan) mechanisam. This idea is discussed and presented in Collab Conference 2014. Here is the youtube link https://www.youtube.com/watch?v=hJKdZcSpGNQ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8227) Creating VDI support tool for cloudstack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14317504#comment-14317504 ] Rajesh Battala commented on CLOUDSTACK-8227: Great. I will go through it and let you know. Thanks Rajesh Battala Creating VDI support tool for cloudstack Key: CLOUDSTACK-8227 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8227 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Tilak Raj Singh Labels: cloud, gsoc2015, java I wish to create a VDI support tool for cloudstack so that DesktopAsAService can be provided using Cloudstack. I wish to use Guacamole Web Service (http://guac-dev.org/) for the purpose which is based on VNC to do the same -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8227) Creating VDI support tool for cloudstack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14316033#comment-14316033 ] Rajesh Battala commented on CLOUDSTACK-8227: Hi Tilak. We can discuss over mailing listing. we can see your initial setup and what's your plan. Thank Rajesh Battala Creating VDI support tool for cloudstack Key: CLOUDSTACK-8227 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8227 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Tilak Raj Singh Labels: cloud, gsoc2015, java I wish to create a VDI support tool for cloudstack so that DesktopAsAService can be provided using Cloudstack. I wish to use Guacamole Web Service (http://guac-dev.org/) for the purpose which is based on VNC to do the same -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8227) Creating VDI support tool for cloudstack
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14313799#comment-14313799 ] Rajesh Battala commented on CLOUDSTACK-8227: I can Mentor you, if you are interested to implement this feature. Creating VDI support tool for cloudstack Key: CLOUDSTACK-8227 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8227 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Reporter: Tilak Raj Singh Labels: cloud, gsoc2015, java I wish to create a VDI support tool for cloudstack so that DesktopAsAService can be provided using Cloudstack. I wish to use Guacamole Web Service (http://guac-dev.org/) for the purpose which is based on VNC to do the same -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8142) [Hyper-V] While creating system vms attach systemvm.iso directly from sec storage folder instead from host local path
Rajesh Battala created CLOUDSTACK-8142: -- Summary: [Hyper-V] While creating system vms attach systemvm.iso directly from sec storage folder instead from host local path Key: CLOUDSTACK-8142 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8142 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.6.0 Reporter: Rajesh Battala Assignee: Devdeep Singh Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-7364: --- Fix Version/s: 4.6.0 NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Fix For: 4.6.0 Attachments: 10_1NS_vlan_ip_if.png, 10_5_NS_vlan_ip_if.png, management-server.log.debug.gz, screenshot-1.png, screenshot-2.png When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14234985#comment-14234985 ] Rajesh Battala commented on CLOUDSTACK-7364: I have observed that on NS vpx provisioned by Cloudstack has the above settings on public interface. On unmanaged NS device its not there. However as there is no functionality impact, Am moving this to fix in next release. NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Attachments: 10_1NS_vlan_ip_if.png, 10_5_NS_vlan_ip_if.png, management-server.log.debug.gz, screenshot-1.png, screenshot-2.png When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reopened CLOUDSTACK-7364: NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Fix For: 4.6.0 Attachments: 10_1NS_vlan_ip_if.png, 10_5_NS_vlan_ip_if.png, management-server.log.debug.gz, screenshot-1.png, screenshot-2.png When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14222767#comment-14222767 ] Rajesh Battala commented on CLOUDSTACK-7364: Attaching the screenshots of 10.1 and 10.5 version NS VPX. where the public vlan (100) is binded to the public interfance (1/1) and public ip and subnet are bindined to vlan(100) NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Attachments: management-server.log.debug.gz, screenshot-1.png, screenshot-2.png When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-7364: --- Attachment: 10_5_NS_vlan_ip_if.png 10_1NS_vlan_ip_if.png NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Attachments: 10_1NS_vlan_ip_if.png, 10_5_NS_vlan_ip_if.png, management-server.log.debug.gz, screenshot-1.png, screenshot-2.png When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-7364. Resolution: Cannot Reproduce NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Attachments: 10_1NS_vlan_ip_if.png, 10_5_NS_vlan_ip_if.png, management-server.log.debug.gz, screenshot-1.png, screenshot-2.png When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reopened CLOUDSTACK-7364: NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Attachments: 10_1NS_vlan_ip_if.png, 10_5_NS_vlan_ip_if.png, management-server.log.debug.gz, screenshot-1.png, screenshot-2.png When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14217541#comment-14217541 ] Rajesh Battala commented on CLOUDSTACK-7364: I have verified on NS 10.1. I see the behaviour is same. The commands bind vlan public vlan to interface and then bind vlan to public ip address. I have verified these commands executed on 10.1 and 10.5. when checked NS resource java, we bind the public vlan to interfance and ip address. there is no version specific code changes or branches in code. here is output from 10.1 NS. Done show version NetScaler NS10.1: Build 126.12.nc, Date: May 13 2014, 07:39:11 Done show vlan 1) VLAN ID: 1 Link-local IPv6 addr: fe80::fc03:cdff:fe6f:9e52/64 Interfaces : 1/1 1/2 0/1 0/2 LO/1 2) VLAN ID: 100VLAN Alias Name: Interfaces : 1/1(T) IPs : 10.102.242.199 Mask: 255.255.254.0 3) VLAN ID: 458VLAN Alias Name: Interfaces : 1/2(T) IPs : 10.1.32.21 Mask: 255.255.240.0 Done these are commands gets executed in NS to bind vlan and ip address bind vlan 100 -IPAddres s 10.102.242.199 255.255.254.0 -devno 18120704 - Status Success Nov 19 00:18:48 local0.info 10.102.246.15 11/19/2014:00:18:48 GMT Cloud-VPX-10 0-PPE-0 : UI CMD_EXECUTED 153 0 : User nsroot - Remote_ip 10.102.192.251 - Command bind vlan 100 -ifnum 1/ 1 -tagged -devno 18153472 - Status Success us Success Nov 19 00:18:48 local0.info 10.102.246.15 11/19/2014:00:18:48 GMT Cloud-VPX-10 0-PPE-0 : UI CMD_EXECUTED 152 0 : User nsroot - Remote_ip 10.102.192.251 - Command bind vlan 100 -IPAddres s 10.102.242.199 255.255.254.0 -devno 18120704 - Status Success Nov 19 00:18:48 local0.info 10.102.246.15 11/19/2014:00:18:48 GMT Cloud-VPX-10 0-PPE-0 : UI CMD_EXECUTED 153 0 : User nsroot - Remote_ip 10.102.192.251 - Command bind vlan 100 -ifnum 1/ 1 -tagged -devno 18153472 - Status Success NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Attachments: management-server.log.debug.gz, screenshot-1.png, screenshot-2.png When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-7364. Resolution: Not a Problem NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Attachments: management-server.log.debug.gz, screenshot-1.png, screenshot-2.png When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214441#comment-14214441 ] Rajesh Battala commented on CLOUDSTACK-7364: from NS config and code I see we are binding the public SNIP to interface 1/1. we are binding vlan and ip to the public interface (1/1) show ip IpaddressTraffic Domain Type Mode Arp Icmp Vserver State --- --- --- -- 1) 10.102.246.250 NetScaler IP Active Enabled Enabled NA Enabled 2) 10.102.242.193 0 SNIP Active Enabled Enabled NA Enabled 3) 10.1.0.890 SNIP Active Enabled Enabled NA Enabled 4) 10.102.242.194 0 VIP Active Enabled Enabled Enabled Enabled Done show vlan 1) VLAN ID: 1 Link-local IPv6 addr: fe80::1c9a:87ff:fe55:8c01/64 Interfaces : 1/1 1/2 0/1 0/2 LO/1 2) VLAN ID: 100VLAN Alias Name: Interfaces : 1/1(T) IPs : 10.102.242.193 Mask: 255.255.254.0 3) VLAN ID: 456VLAN Alias Name: Interfaces : 1/2(T) IPs : 10.1.0.89 Mask: 255.255.240.0 Done show version NetScaler NS10.5: Build 52.11.nc, Date: Sep 30 2014, 01:20:43 Done NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Attachments: management-server.log.debug.gz, screenshot-1.png, screenshot-2.png When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214645#comment-14214645 ] Rajesh Battala commented on CLOUDSTACK-7364: That's not an issue. We take the public interface value specified while adding the device and use it to bind vlan and ip address . NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Attachments: management-server.log.debug.gz, screenshot-1.png, screenshot-2.png When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7774) Description field is missing in Health policy API's
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Battala resolved CLOUDSTACK-7774.
Resolution: Fixed
Description field is missing in Health policy API's
---
Key: CLOUDSTACK-7774
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7774
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.5.0
Reporter: Rajesh Battala
Assignee: Rajesh Battala
Fix For: 4.5.0
Load balancer Health Policy API's does not return description field.
API's:
listLBHealthCheckPolicies
createLBHealthCheckPolicy
updateLBHealthCheckPolicy
Example:
When we call listLBHealthCheckPolicies API, following is the resultant json.
{ listlbhealthcheckpoliciesresponse : { count:1 ,healthcheckpolicies :
[
{lbruleid:318c4fcb-1c49-473d-a065-ba730b81840b,account:newcorp,domainid:4415b414-b742-4540-987f-835edaafc9bc,domain:AA04,healthcheckpolicy:[{id:67167ce7-c31c-47fc-b370-d1a70837e908,pingpath:/,responsetime:2,healthcheckinterval:5,healthcheckthresshold:2,unhealthcheckthresshold:1}]}
] } }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214205#comment-14214205 ] Rajesh Battala commented on CLOUDSTACK-7364: we are binding the public vlan to (1/1) mentioned public interface in cloudstack in Netscaler device. From the code, we are binding the vlan to nsip similar like private ip. NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Attachments: management-server.log.debug.gz When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214229#comment-14214229 ] Rajesh Battala commented on CLOUDSTACK-7364: I saw public vlan is bouned to public interface. let me check whether public ip is bouned to vlan. NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Attachments: management-server.log.debug.gz, screenshot-1.png, screenshot-2.png When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-5673) [Hyper-V] Default IP address never configured on eth0 with default CentOS template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14176679#comment-14176679 ] Rajesh Battala edited comment on CLOUDSTACK-5673 at 11/15/14 10:22 AM: --- from my above #1 comments it by design. I don't see any functionality is affected by it. if so, please feel free to open with details. was (Author: rajesh_battala): from my above #1 comments it by design. [Hyper-V] Default IP address never configured on eth0 with default CentOS template -- Key: CLOUDSTACK-5673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5673 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Template Affects Versions: 4.3.0 Environment: Hyper-V Reporter: Sowmya Krishnan Assignee: Rajesh Battala Priority: Minor Labels: hyper-v Fix For: 4.4.0, 4.5.0 Deploy VM with the default CentOS 6.4 template that comes for Hyper-V. Observe that default IP never gets configured on eth0. While this doesn't seem to impact anything directly, it may have issues while configuring multiple IPs for a VM. There may some workarounds needed to get multiple IPs to work on the non-default interface. It is instead desirable to have the default IP configured on eth0 itself like the default templates for other hypervisors. here's a sample of ifconfig from the deployed VM: [root@VM1 ~]# ifconfig eth2 Link encap:Ethernet HWaddr 02:00:74:88:00:01 inet addr:10.0.17.2 Bcast:10.0.31.255 Mask:255.255.240.0 inet6 addr: fe80::74ff:fe88:1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13925 errors:0 dropped:0 overruns:0 frame:0 TX packets:14043 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:838100 (818.4 KiB) TX bytes:851899 (831.9 KiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:240 (240.0 b) TX bytes:240 (240.0 b) [root@VM1 ~]# ls /etc/sysconfig/network-scripts/ ifcfg-eth0 ifdown-isdnifup-aliases ifup-plusb init.ipv6-global ifcfg-lo ifdown-postifup-bnep ifup-post net.hotplug ifdown ifdown-ppp ifup-eth ifup-ppp network-functions ifdown-bnep ifdown-routes ifup-ippp ifup-routes network-functions-ipv6 ifdown-eth ifdown-sit ifup-ipv6 ifup-sit ifdown-ippp ifdown-tunnel ifup-isdn ifup-tunnel ifdown-ipv6 ifup ifup-plip ifup-wireless -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7712) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-7712: --- Fix Version/s: (was: 4.5.0) 4.6.0 Triage and fix Coverity defects --- Key: CLOUDSTACK-7712 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7712 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Santhosh Kumar Edukulla Assignee: Rajesh Battala Fix For: 4.6.0 1. We have Coverity setup available, running as scheduled and individual owners are assigned with analyzed bugs. 2. As part of this bug, please triage and fix the relevant Coverity bugs assigned. It could be a count as small as 25 bugs. 3. First start with high impact in order to others later. 4. We can either triage them accordingly as fix required or false positive or not a bug accordingly. But, triage and fix accordingly wherever relevant and applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-5673) [Hyper-V] Default IP address never configured on eth0 with default CentOS template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-5673. Resolution: Not a Problem [Hyper-V] Default IP address never configured on eth0 with default CentOS template -- Key: CLOUDSTACK-5673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5673 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Template Affects Versions: 4.3.0 Environment: Hyper-V Reporter: Sowmya Krishnan Assignee: Rajesh Battala Priority: Minor Labels: hyper-v Fix For: 4.4.0, 4.5.0 Deploy VM with the default CentOS 6.4 template that comes for Hyper-V. Observe that default IP never gets configured on eth0. While this doesn't seem to impact anything directly, it may have issues while configuring multiple IPs for a VM. There may some workarounds needed to get multiple IPs to work on the non-default interface. It is instead desirable to have the default IP configured on eth0 itself like the default templates for other hypervisors. here's a sample of ifconfig from the deployed VM: [root@VM1 ~]# ifconfig eth2 Link encap:Ethernet HWaddr 02:00:74:88:00:01 inet addr:10.0.17.2 Bcast:10.0.31.255 Mask:255.255.240.0 inet6 addr: fe80::74ff:fe88:1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13925 errors:0 dropped:0 overruns:0 frame:0 TX packets:14043 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:838100 (818.4 KiB) TX bytes:851899 (831.9 KiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:240 (240.0 b) TX bytes:240 (240.0 b) [root@VM1 ~]# ls /etc/sysconfig/network-scripts/ ifcfg-eth0 ifdown-isdnifup-aliases ifup-plusb init.ipv6-global ifcfg-lo ifdown-postifup-bnep ifup-post net.hotplug ifdown ifdown-ppp ifup-eth ifup-ppp network-functions ifdown-bnep ifdown-routes ifup-ippp ifup-routes network-functions-ipv6 ifdown-eth ifdown-sit ifup-ipv6 ifup-sit ifdown-ippp ifdown-tunnel ifup-isdn ifup-tunnel ifdown-ipv6 ifup ifup-plip ifup-wireless -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7582) Not able to remove tag from primary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-7582. Resolution: Fixed Not able to remove tag from primary storage --- Key: CLOUDSTACK-7582 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7582 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.5.0 Reporter: prashant kumar mishra Assignee: Rajesh Battala Fix For: 4.5.0 steps to reproduce == 1-update storage tags 2-try to remove tag by passing empty value expected: tags should be removed actual storage tag is not getting removed API === http://10.147.59.173:8096/client/api?command=updateStoragePoolid=f672eae0-b400-3767-808f-b787a5c04d5ftags=capacitybytes=5497558138880response=xml updatestoragepoolresponse cloud-stack-version=4.5.0-SNAPSHOTstoragepoolidf672eae0-b400-3767-808f-b787a5c04d5f/idzoneidd5e96cca-0985-49fe-a777-49b257278c8a/zoneidzonenamemanasa/zonenamenameprimaryVMw/nameipaddress10.147.28.7/ipaddresspath/export/home/manasa/primaryVMw/pathcreated2014-09-12T11:26:37+0530/createdtypeNetworkFilesystem/typedisksizetotal5497558138880/disksizetotaldisksizeallocated4294967296/disksizeallocateddisksizeused2696516272128/disksizeusedtagsab/tagsstateUp/statescopeZONE/scopehypervisorVMware/hypervisor/storagepool/updatestoragepoolresponse -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7711) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-7711. Resolution: Duplicate Triage and fix Coverity defects --- Key: CLOUDSTACK-7711 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7711 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Santhosh Kumar Edukulla Assignee: Rajesh Battala Fix For: 4.5.0 1. We have Coverity setup available, running as scheduled and individual owners are assigned with analyzed bugs. 2. As part of this bug, please triage and fix the relevant Coverity bugs assigned. It could be a count as small as 25 bugs. 3. First start with high impact in order to others later. 4. We can either triage them accordingly as fix required or false positive or not a bug accordingly. But, triage and fix accordingly wherever relevant and applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7582) Not able to remove tag from prinmary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reassigned CLOUDSTACK-7582: -- Assignee: Rajesh Battala (was: Saksham Srivastava) Not able to remove tag from prinmary storage Key: CLOUDSTACK-7582 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7582 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.5.0 Reporter: prashant kumar mishra Assignee: Rajesh Battala Fix For: 4.5.0 steps to reproduce == 1-update storage tags 2-try to remove tag by passing empty value expected: tags should be removed actual storage tag is not getting removed API === http://10.147.59.173:8096/client/api?command=updateStoragePoolid=f672eae0-b400-3767-808f-b787a5c04d5ftags=capacitybytes=5497558138880response=xml updatestoragepoolresponse cloud-stack-version=4.5.0-SNAPSHOTstoragepoolidf672eae0-b400-3767-808f-b787a5c04d5f/idzoneidd5e96cca-0985-49fe-a777-49b257278c8a/zoneidzonenamemanasa/zonenamenameprimaryVMw/nameipaddress10.147.28.7/ipaddresspath/export/home/manasa/primaryVMw/pathcreated2014-09-12T11:26:37+0530/createdtypeNetworkFilesystem/typedisksizetotal5497558138880/disksizetotaldisksizeallocated4294967296/disksizeallocateddisksizeused2696516272128/disksizeusedtagsab/tagsstateUp/statescopeZONE/scopehypervisorVMware/hypervisor/storagepool/updatestoragepoolresponse -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7711) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reassigned CLOUDSTACK-7711: -- Assignee: Rajesh Battala (was: Saksham Srivastava) Triage and fix Coverity defects --- Key: CLOUDSTACK-7711 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7711 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Santhosh Kumar Edukulla Assignee: Rajesh Battala Fix For: 4.5.0 1. We have Coverity setup available, running as scheduled and individual owners are assigned with analyzed bugs. 2. As part of this bug, please triage and fix the relevant Coverity bugs assigned. It could be a count as small as 25 bugs. 3. First start with high impact in order to others later. 4. We can either triage them accordingly as fix required or false positive or not a bug accordingly. But, triage and fix accordingly wherever relevant and applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reassigned CLOUDSTACK-7364: -- Assignee: Rajesh Battala (was: Saksham Srivastava) NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Attachments: management-server.log.debug.gz When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7774) Description field is missing in Health policy API's
Rajesh Battala created CLOUDSTACK-7774:
--
Summary: Description field is missing in Health policy API's
Key: CLOUDSTACK-7774
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7774
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Affects Versions: 4.5.0
Reporter: Rajesh Battala
Assignee: Rajesh Battala
Fix For: 4.5.0
Load balancer Health Policy API's does not return description field.
API's:
listLBHealthCheckPolicies
createLBHealthCheckPolicy
updateLBHealthCheckPolicy
Example:
When we call listLBHealthCheckPolicies API, following is the resultant json.
{ listlbhealthcheckpoliciesresponse : { count:1 ,healthcheckpolicies : [
{lbruleid:318c4fcb-1c49-473d-a065-ba730b81840b,account:newcorp,domainid:4415b414-b742-4540-987f-835edaafc9bc,domain:AA04,healthcheckpolicy:[{id:67167ce7-c31c-47fc-b370-d1a70837e908,pingpath:/,responsetime:2,healthcheckinterval:5,healthcheckthresshold:2,unhealthcheckthresshold:1}]}
] } }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5673) [Hyper-V] Default IP address never configured on eth0 with default CentOS template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14176679#comment-14176679 ] Rajesh Battala commented on CLOUDSTACK-5673: from my above #1 comments it by design. [Hyper-V] Default IP address never configured on eth0 with default CentOS template -- Key: CLOUDSTACK-5673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5673 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Template Affects Versions: 4.3.0 Environment: Hyper-V Reporter: Sowmya Krishnan Assignee: Rajesh Battala Priority: Minor Labels: hyper-v Fix For: 4.4.0 Deploy VM with the default CentOS 6.4 template that comes for Hyper-V. Observe that default IP never gets configured on eth0. While this doesn't seem to impact anything directly, it may have issues while configuring multiple IPs for a VM. There may some workarounds needed to get multiple IPs to work on the non-default interface. It is instead desirable to have the default IP configured on eth0 itself like the default templates for other hypervisors. here's a sample of ifconfig from the deployed VM: [root@VM1 ~]# ifconfig eth2 Link encap:Ethernet HWaddr 02:00:74:88:00:01 inet addr:10.0.17.2 Bcast:10.0.31.255 Mask:255.255.240.0 inet6 addr: fe80::74ff:fe88:1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13925 errors:0 dropped:0 overruns:0 frame:0 TX packets:14043 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:838100 (818.4 KiB) TX bytes:851899 (831.9 KiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:240 (240.0 b) TX bytes:240 (240.0 b) [root@VM1 ~]# ls /etc/sysconfig/network-scripts/ ifcfg-eth0 ifdown-isdnifup-aliases ifup-plusb init.ipv6-global ifcfg-lo ifdown-postifup-bnep ifup-post net.hotplug ifdown ifdown-ppp ifup-eth ifup-ppp network-functions ifdown-bnep ifdown-routes ifup-ippp ifup-routes network-functions-ipv6 ifdown-eth ifdown-sit ifup-ipv6 ifup-sit ifdown-ippp ifdown-tunnel ifup-isdn ifup-tunnel ifdown-ipv6 ifup ifup-plip ifup-wireless -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-5673) [Hyper-V] Default IP address never configured on eth0 with default CentOS template
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-5673: --- Priority: Minor (was: Major) [Hyper-V] Default IP address never configured on eth0 with default CentOS template -- Key: CLOUDSTACK-5673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5673 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup, Template Affects Versions: 4.3.0 Environment: Hyper-V Reporter: Sowmya Krishnan Assignee: Rajesh Battala Priority: Minor Labels: hyper-v Fix For: 4.4.0 Deploy VM with the default CentOS 6.4 template that comes for Hyper-V. Observe that default IP never gets configured on eth0. While this doesn't seem to impact anything directly, it may have issues while configuring multiple IPs for a VM. There may some workarounds needed to get multiple IPs to work on the non-default interface. It is instead desirable to have the default IP configured on eth0 itself like the default templates for other hypervisors. here's a sample of ifconfig from the deployed VM: [root@VM1 ~]# ifconfig eth2 Link encap:Ethernet HWaddr 02:00:74:88:00:01 inet addr:10.0.17.2 Bcast:10.0.31.255 Mask:255.255.240.0 inet6 addr: fe80::74ff:fe88:1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13925 errors:0 dropped:0 overruns:0 frame:0 TX packets:14043 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:838100 (818.4 KiB) TX bytes:851899 (831.9 KiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:240 (240.0 b) TX bytes:240 (240.0 b) [root@VM1 ~]# ls /etc/sysconfig/network-scripts/ ifcfg-eth0 ifdown-isdnifup-aliases ifup-plusb init.ipv6-global ifcfg-lo ifdown-postifup-bnep ifup-post net.hotplug ifdown ifdown-ppp ifup-eth ifup-ppp network-functions ifdown-bnep ifdown-routes ifup-ippp ifup-routes network-functions-ipv6 ifdown-eth ifdown-sit ifup-ipv6 ifup-sit ifdown-ippp ifdown-tunnel ifup-isdn ifup-tunnel ifdown-ipv6 ifup ifup-plip ifup-wireless -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7313) Provisioning vpx in SDX from CS is failing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-7313. Resolution: Fixed Provisioning vpx in SDX from CS is failing -- Key: CLOUDSTACK-7313 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7313 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Devices Affects Versions: 4.5.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Priority: Critical Fix For: 4.5.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7712) Triage and fix Coverity defects
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14170779#comment-14170779 ] Rajesh Battala commented on CLOUDSTACK-7712: will work on this in the coming sprint. Triage and fix Coverity defects --- Key: CLOUDSTACK-7712 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7712 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Santhosh Kumar Edukulla Assignee: Rajesh Battala Fix For: 4.5.0 1. We have Coverity setup available, running as scheduled and individual owners are assigned with analyzed bugs. 2. As part of this bug, please triage and fix the relevant Coverity bugs assigned. It could be a count as small as 25 bugs. 3. First start with high impact in order to others later. 4. We can either triage them accordingly as fix required or false positive or not a bug accordingly. But, triage and fix accordingly wherever relevant and applicable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7654) createtmplt.sh (invoked by cloud-install-sys-tmplt) is not able to seed zipped templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-7654. Resolution: Fixed createtmplt.sh (invoked by cloud-install-sys-tmplt) is not able to seed zipped templates Key: CLOUDSTACK-7654 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7654 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.5.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Priority: Critical Fix For: 4.5.0 I tried to seed the hyper-v template which is now in zipped format and the script seems to be failing to do the same although there is no explicit error message. Template used : from jenkins job Steps: = 1. Mount the secondary storage in a local mount point 2. Seed the system vm template using /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /temp -u http://10.102.192.128/templates/systemvm64template-master-hyperv.vhd.zip -h hyperv 3. Verify after the set up is brought up Result = System VMs fail to come up since the system vm template in the secondary storage is corrupted. Following is the error message from Hyper-V install: Failed to open attachment '\\smb19\hyperv-share\sowmya-ps1\9e5ee642-ce2a-44fc-bb65-690936634b0f.vhd'. Error: 'The file or directory is corrupted and unreadable The cloud-install-sys-tmplt seems to invoke the createtmplt.sh script to uncompress and copy the template to secondary storage. But is probably failing to uncompress. While executing the script, I get the following message which implies that it is failing to uncompress the zipped file: File /usr/share/cloudstack-common/scripts/storage/secondary/2618f45e-c2fc-445b-81cd-b93906d23dda.vhd does not appear to be compressed Further, when we manually unzip the above zipped template file and launch a VM from the unzipped vhd, it launches the VM properly. This implies that it is either not un compressed or somewhere corrupting the file before copying over to the secondary storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7654) createtmplt.sh (invoked by cloud-install-sys-tmplt) is not able to seed zipped templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14153057#comment-14153057 ] Rajesh Battala commented on CLOUDSTACK-7654: root cause: case matching issue while finding the file type for zipped file createtmplt.sh (invoked by cloud-install-sys-tmplt) is not able to seed zipped templates Key: CLOUDSTACK-7654 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7654 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.5.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Priority: Critical Fix For: 4.5.0 I tried to seed the hyper-v template which is now in zipped format and the script seems to be failing to do the same although there is no explicit error message. Template used : from jenkins job Steps: = 1. Mount the secondary storage in a local mount point 2. Seed the system vm template using /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /temp -u http://10.102.192.128/templates/systemvm64template-master-hyperv.vhd.zip -h hyperv 3. Verify after the set up is brought up Result = System VMs fail to come up since the system vm template in the secondary storage is corrupted. Following is the error message from Hyper-V install: Failed to open attachment '\\smb19\hyperv-share\sowmya-ps1\9e5ee642-ce2a-44fc-bb65-690936634b0f.vhd'. Error: 'The file or directory is corrupted and unreadable The cloud-install-sys-tmplt seems to invoke the createtmplt.sh script to uncompress and copy the template to secondary storage. But is probably failing to uncompress. While executing the script, I get the following message which implies that it is failing to uncompress the zipped file: File /usr/share/cloudstack-common/scripts/storage/secondary/2618f45e-c2fc-445b-81cd-b93906d23dda.vhd does not appear to be compressed Further, when we manually unzip the above zipped template file and launch a VM from the unzipped vhd, it launches the VM properly. This implies that it is either not un compressed or somewhere corrupting the file before copying over to the secondary storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7654) createtmplt.sh (invoked by cloud-install-sys-tmplt) is not able to seed zipped templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14153052#comment-14153052 ] Rajesh Battala commented on CLOUDSTACK-7654: This issue is reproducible when user tries to register the .zip file and try to create the instance from the template. createtmplt.sh (invoked by cloud-install-sys-tmplt) is not able to seed zipped templates Key: CLOUDSTACK-7654 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7654 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.5.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Priority: Critical Fix For: 4.5.0 I tried to seed the hyper-v template which is now in zipped format and the script seems to be failing to do the same although there is no explicit error message. Template used : from jenkins job Steps: = 1. Mount the secondary storage in a local mount point 2. Seed the system vm template using /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /temp -u http://10.102.192.128/templates/systemvm64template-master-hyperv.vhd.zip -h hyperv 3. Verify after the set up is brought up Result = System VMs fail to come up since the system vm template in the secondary storage is corrupted. Following is the error message from Hyper-V install: Failed to open attachment '\\smb19\hyperv-share\sowmya-ps1\9e5ee642-ce2a-44fc-bb65-690936634b0f.vhd'. Error: 'The file or directory is corrupted and unreadable The cloud-install-sys-tmplt seems to invoke the createtmplt.sh script to uncompress and copy the template to secondary storage. But is probably failing to uncompress. While executing the script, I get the following message which implies that it is failing to uncompress the zipped file: File /usr/share/cloudstack-common/scripts/storage/secondary/2618f45e-c2fc-445b-81cd-b93906d23dda.vhd does not appear to be compressed Further, when we manually unzip the above zipped template file and launch a VM from the unzipped vhd, it launches the VM properly. This implies that it is either not un compressed or somewhere corrupting the file before copying over to the secondary storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7496) [Automation][HyperV] Unable to ssh into the System VMs after Reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-7496: --- Assignee: Sowmya Krishnan (was: Rajesh Battala) [Automation][HyperV] Unable to ssh into the System VMs after Reboot --- Key: CLOUDSTACK-7496 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7496 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Sowmya Krishnan Priority: Critical Fix For: 4.5.0 Attachments: runinfo.zip I attached the Automation client log information to this bug report. It shows that the System VMs could not be accessed via ssh after reboot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-7364: --- Assignee: Saksham Srivastava (was: Rajesh Battala) NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Saksham Srivastava Priority: Critical Attachments: management-server.log.debug.gz When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Battala updated CLOUDSTACK-7493:
---
Assignee: Jayapal Reddy (was: Rajesh Battala)
[Automation] Egress Firewall Rule fails to create on the Virtual Router in
Hyper-V Setup - Reports Success instead of failure report
Key: CLOUDSTACK-7493
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Jayapal Reddy
Priority: Blocker
Fix For: 4.5.0
Attachments: client_managementLogs.zip
==
Error in management Server log:
==
{code}
2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===
10.220.135.217 -- GET
jobid=561bbb6c-7931-493d-a778-525086befb96apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3gcommand=queryAsyncJobResultresponse=jsonsignature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
(API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
1-4477422454536405316: Sending { Cmd , MgmtId: 174253150778429, via:
1(10.220.163.36), Ver: v1, Flags: 11,
[{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
}
2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
(API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
1-4477422454536405316: Executing: { Cmd , MgmtId: 174253150778429, via:
1(10.220.163.36), Ver: v1, Flags: 11,
[{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
}
2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP :
10.220.165.184
2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-316:ctx-c363d57a) Run command on VR: 10.220.165.184, script:
firewall_egress.sh with args: -F -E -P 0 -a :all:0:0:0.0.0.0/0:,
2014-09-03 18:04:37,394 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-14:null) SeqA 3-604: Processing Seq 3-604: { Cmd ,
MgmtId: -1, via: 3, Ver: v1, Flags: 11,
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
\connections\: []\n},wait:0}}] }
2014-09-03 18:04:37,397 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-14:null) SeqA 3-604: Sending Seq 3-604: { Ans: ,
MgmtId: 174253150778429, via: 3, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2014-09-03 18:04:37,826 DEBUG [c.c.s.StorageManagerImpl]
(StorageManager-Scavenger-3:ctx-e8a5b20a) Storage pool garbage collector
found 0 templates to clean up in storage pool:
XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
2014-09-03 18:04:37,829 DEBUG [c.c.s.StorageManagerImpl]
(StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
found 0 templates to cleanup on template_store_ref for store:
cifs://10.220.163.36/storage/secondary
2014-09-03 18:04:37,831 DEBUG [c.c.s.StorageManagerImpl]
(StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
found 0 snapshots to cleanup on snapshot_store_ref for store:
cifs://10.220.163.36/storage/secondary
2014-09-03 18:04:37,832 DEBUG [c.c.s.StorageManagerImpl]
(StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
found 0 volumes to cleanup on volume_store_ref for store:
cifs://10.220.163.36/storage/secondary
2014-09-03 18:04:37,940 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-316:ctx-c363d57a) firewall_egress.sh execution result: true
2014-09-03 18:04:37,940 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-316:ctx-c363d57a) Seq
[jira] [Commented] (CLOUDSTACK-7496) [Automation][HyperV] Unable to ssh into the System VMs after Reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14125370#comment-14125370 ] Rajesh Battala commented on CLOUDSTACK-7496: [~chandanp] Can you please check it manually by sshing to systemvm's. If sshing to systemvm's wont work then nothing can be deployed in Hyper-V. I have checked sshing to systemvms before and after reboot. Its working fine. Attaching the snippet root@rajesh-HVM-domU:/home/rajesh/hyperv/client/target/cloud-client-ui-4.5.0-SNAPSHOT/WEB-INF/classes/scripts/vm/systemvm# ssh root@10.102.246.15 -p3922 -i ~/.ssh/id_rsa.cloud Linux s-2-VM 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Mon Sep 8 09:59:35 2014 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@s-2-VM:~# [Automation][HyperV] Unable to ssh into the System VMs after Reboot --- Key: CLOUDSTACK-7496 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7496 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Test Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Rajesh Battala Priority: Critical Fix For: 4.5.0 Attachments: runinfo.zip I attached the Automation client log information to this bug report. It shows that the System VMs could not be accessed via ssh after reboot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Battala updated CLOUDSTACK-7493:
---
Assignee: Jayapal Reddy (was: Rajesh Battala)
[Automation] Egress Firewall Rule fails to create on the Virtual Router in
Hyper-V Setup - Reports Success instead of failure report
Key: CLOUDSTACK-7493
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Jayapal Reddy
Priority: Blocker
Fix For: 4.5.0
==
Error in management Server log:
==
{code}
2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===
10.220.135.217 -- GET
jobid=561bbb6c-7931-493d-a778-525086befb96apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3gcommand=queryAsyncJobResultresponse=jsonsignature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
(API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
1-4477422454536405316: Sending { Cmd , MgmtId: 174253150778429, via:
1(10.220.163.36), Ver: v1, Flags: 11,
[{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
}
2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
(API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
1-4477422454536405316: Executing: { Cmd , MgmtId: 174253150778429, via:
1(10.220.163.36), Ver: v1, Flags: 11,
[{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
}
2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP :
10.220.165.184
2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-316:ctx-c363d57a) Run command on VR: 10.220.165.184, script:
firewall_egress.sh with args: -F -E -P 0 -a :all:0:0:0.0.0.0/0:,
2014-09-03 18:04:37,394 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-14:null) SeqA 3-604: Processing Seq 3-604: { Cmd ,
MgmtId: -1, via: 3, Ver: v1, Flags: 11,
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
\connections\: []\n},wait:0}}] }
2014-09-03 18:04:37,397 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-14:null) SeqA 3-604: Sending Seq 3-604: { Ans: ,
MgmtId: 174253150778429, via: 3, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2014-09-03 18:04:37,826 DEBUG [c.c.s.StorageManagerImpl]
(StorageManager-Scavenger-3:ctx-e8a5b20a) Storage pool garbage collector
found 0 templates to clean up in storage pool:
XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
2014-09-03 18:04:37,829 DEBUG [c.c.s.StorageManagerImpl]
(StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
found 0 templates to cleanup on template_store_ref for store:
cifs://10.220.163.36/storage/secondary
2014-09-03 18:04:37,831 DEBUG [c.c.s.StorageManagerImpl]
(StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
found 0 snapshots to cleanup on snapshot_store_ref for store:
cifs://10.220.163.36/storage/secondary
2014-09-03 18:04:37,832 DEBUG [c.c.s.StorageManagerImpl]
(StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
found 0 volumes to cleanup on volume_store_ref for store:
cifs://10.220.163.36/storage/secondary
2014-09-03 18:04:37,940 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-316:ctx-c363d57a) firewall_egress.sh execution result: true
2014-09-03 18:04:37,940 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Response Received:
2014-09-03
[jira] [Commented] (CLOUDSTACK-7493) [Automation] Egress Firewall Rule fails to create on the Virtual Router in Hyper-V Setup - Reports Success instead of failure report
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14124303#comment-14124303
]
Rajesh Battala commented on CLOUDSTACK-7493:
Its specific to iptables and firewall rules configuration.
[~jayapal] can you please look at the above iptables log and share your input.
Thanks
Rajesh Battala
[Automation] Egress Firewall Rule fails to create on the Virtual Router in
Hyper-V Setup - Reports Success instead of failure report
Key: CLOUDSTACK-7493
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7493
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Rajesh Battala
Priority: Blocker
Fix For: 4.5.0
==
Error in management Server log:
==
{code}
2014-09-03 18:04:36,689 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-a84568da ctx-c6c0fc58 ctx-985e7722) ===END===
10.220.135.217 -- GET
jobid=561bbb6c-7931-493d-a778-525086befb96apiKey=hCPmYiAF1lm_sBLrhXIEWXCJt0vYbxzkeFfv7E1ZhyPPL_TF6BvI8cVOm2AqLlzWwa2w9dO0eFQu6SafM_st3gcommand=queryAsyncJobResultresponse=jsonsignature=fWkgkcIGrOu7YQc%2Fw5GD%2B3HHGkM%3D
2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
(API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
1-4477422454536405316: Sending { Cmd , MgmtId: 174253150778429, via:
1(10.220.163.36), Ver: v1, Flags: 11,
[{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
}
2014-09-03 18:04:36,701 DEBUG [c.c.a.t.Request]
(API-Job-Executor-33:ctx-4c5fd3c9 job-316 ctx-8bc88918) Seq
1-4477422454536405316: Executing: { Cmd , MgmtId: 174253150778429, via:
1(10.220.163.36), Ver: v1, Flags: 11,
[{com.cloud.agent.api.routing.SetFirewallRulesCommand:{rules:[{id:36,srcIp:,protocol:all,revoked:false,alreadyAdded:false,sourceCidrList:[0.0.0.0/0],purpose:Firewall,trafficType:Egress,defaultEgressPolicy:false}],accessDetails:{router.guest.ip:192.168.200.1,firewall.egress.default:false,zone.network.type:Advanced,router.ip:10.220.165.184,router.name:r-45-VM},wait:0}}]
}
2014-09-03 18:04:36,702 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-316:ctx-c363d57a) Seq 1-4477422454536405316: Executing request
2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-316:ctx-c363d57a) Use router's private IP for SSH control. IP :
10.220.165.184
2014-09-03 18:04:36,702 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-316:ctx-c363d57a) Run command on VR: 10.220.165.184, script:
firewall_egress.sh with args: -F -E -P 0 -a :all:0:0:0.0.0.0/0:,
2014-09-03 18:04:37,394 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-14:null) SeqA 3-604: Processing Seq 3-604: { Cmd ,
MgmtId: -1, via: 3, Ver: v1, Flags: 11,
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
\connections\: []\n},wait:0}}] }
2014-09-03 18:04:37,397 DEBUG [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-14:null) SeqA 3-604: Sending Seq 3-604: { Ans: ,
MgmtId: 174253150778429, via: 3, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2014-09-03 18:04:37,826 DEBUG [c.c.s.StorageManagerImpl]
(StorageManager-Scavenger-3:ctx-e8a5b20a) Storage pool garbage collector
found 0 templates to clean up in storage pool:
XenRT-Zone-0-Pod-0-Cluster-0-Primary-Store-0
2014-09-03 18:04:37,829 DEBUG [c.c.s.StorageManagerImpl]
(StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
found 0 templates to cleanup on template_store_ref for store:
cifs://10.220.163.36/storage/secondary
2014-09-03 18:04:37,831 DEBUG [c.c.s.StorageManagerImpl]
(StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
found 0 snapshots to cleanup on snapshot_store_ref for store:
cifs://10.220.163.36/storage/secondary
2014-09-03 18:04:37,832 DEBUG [c.c.s.StorageManagerImpl]
(StorageManager-Scavenger-3:ctx-e8a5b20a) Secondary storage garbage collector
found 0 volumes to cleanup on volume_store_ref for store:
cifs://10.220.163.36/storage/secondary
2014-09-03 18:04:37,940 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-316:ctx-c363d57a) firewall_egress.sh
[jira] [Updated] (CLOUDSTACK-6990) VM console displays blank page.AgentControlChannelException in cloud.log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Battala updated CLOUDSTACK-6990:
---
Labels: DEVREV (was: )
VM console displays blank page.AgentControlChannelException in cloud.log
Key: CLOUDSTACK-6990
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6990
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: SystemVM
Affects Versions: 4.4.0
Reporter: manasaveloori
Assignee: Rajesh Battala
Priority: Critical
Labels: DEVREV
Fix For: 4.4.0, 4.5.0
Attachments: cloud.log, management-server.rar
Deployed Cloudstack using the build :
[root@RHEL63test ~]# cloudstack-sccs
9024ad14681858ac7caafaf86f267a213ce6b61c
Deployed a user VM.
Now try to open the console of any VM.
It is displaying blank page.
In CPVM cloud.log observed the following exception continuously:
2014-06-25 06:31:14,620 INFO [utils.exception.CSExceptionErrorCode] (Console
Proxy GC Thread:null) Could not find exception:
com.cloud.exception.AgentControlChannelException in error code list for
exceptions
2014-06-25 06:31:14,621 ERROR [resource.consoleproxy.ConsoleProxyResource]
(Console Proxy GC Thread:null) Unable to send out load info due to Unable to
post agent control request as link is not available
com.cloud.exception.AgentControlChannelException: Unable to post agent
control request as link is not available
at com.cloud.agent.Agent.postRequest(Agent.java:689)
at com.cloud.agent.Agent.postRequest(Agent.java:677)
at
com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:418)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
at
com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
2014-06-25 06:31:14,621 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread]
(Console Proxy GC Thread:null) Report load change : {
connections: []
}
2014-06-25 06:31:14,897 INFO [cloud.agent.Agent] (Agent-Handler-4:null)
Reconnecting...
2014-06-25 06:31:14,897 INFO [utils.nio.NioClient] (Agent-Selector:null)
Connecting to 10.147.59.222:8250
Attaching the Ms logs and CPVM log.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6990) VM console displays blank page.AgentControlChannelException in cloud.log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14119715#comment-14119715
]
Rajesh Battala commented on CLOUDSTACK-6990:
This is solve by this bug CLOUDSTACK-5946
please use required procedure from the above bug.
QA had already closed and verified it.
VM console displays blank page.AgentControlChannelException in cloud.log
Key: CLOUDSTACK-6990
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6990
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: SystemVM
Affects Versions: 4.4.0
Reporter: manasaveloori
Assignee: Rajesh Battala
Priority: Critical
Labels: DEVREV
Fix For: 4.4.0, 4.5.0
Attachments: cloud.log, management-server.rar
Deployed Cloudstack using the build :
[root@RHEL63test ~]# cloudstack-sccs
9024ad14681858ac7caafaf86f267a213ce6b61c
Deployed a user VM.
Now try to open the console of any VM.
It is displaying blank page.
In CPVM cloud.log observed the following exception continuously:
2014-06-25 06:31:14,620 INFO [utils.exception.CSExceptionErrorCode] (Console
Proxy GC Thread:null) Could not find exception:
com.cloud.exception.AgentControlChannelException in error code list for
exceptions
2014-06-25 06:31:14,621 ERROR [resource.consoleproxy.ConsoleProxyResource]
(Console Proxy GC Thread:null) Unable to send out load info due to Unable to
post agent control request as link is not available
com.cloud.exception.AgentControlChannelException: Unable to post agent
control request as link is not available
at com.cloud.agent.Agent.postRequest(Agent.java:689)
at com.cloud.agent.Agent.postRequest(Agent.java:677)
at
com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:418)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
at
com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
2014-06-25 06:31:14,621 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread]
(Console Proxy GC Thread:null) Report load change : {
connections: []
}
2014-06-25 06:31:14,897 INFO [cloud.agent.Agent] (Agent-Handler-4:null)
Reconnecting...
2014-06-25 06:31:14,897 INFO [utils.nio.NioClient] (Agent-Selector:null)
Connecting to 10.147.59.222:8250
Attaching the Ms logs and CPVM log.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reassigned CLOUDSTACK-7364: -- Assignee: Rajesh Battala NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Assignee: Rajesh Battala Priority: Critical Attachments: management-server.log.debug.gz When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14100812#comment-14100812 ] Rajesh Battala commented on CLOUDSTACK-7364: can you post the log/ info about the same? NetScaler won't create the Public VLAN and Bind the IP to it Key: CLOUDSTACK-7364 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.4.0, 4.4.1 Reporter: Francois Gaudreault Priority: Critical When adding a Load Balancing rule with the NetScaler, the provider will tag and bind the private IP to the appropriate interface. However, the behaviour for the Public Interface is different. It simply adds the IP untagged on all interfaces. This is wrong. The public VLAN should be tagged, and the VIP bound to the right VLAN tag to avoid unnecessary ARP on other VLANs. NS Version tested: 123,11, 127.10, 128.8 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6990) VM console displays blank page.AgentControlChannelException in cloud.log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Battala resolved CLOUDSTACK-6990.
Resolution: Fixed
VM console displays blank page.AgentControlChannelException in cloud.log
Key: CLOUDSTACK-6990
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6990
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: SystemVM
Affects Versions: 4.4.0
Reporter: manasaveloori
Assignee: Rajesh Battala
Priority: Critical
Fix For: 4.4.0, 4.5.0
Attachments: cloud.log, management-server.rar
Deployed Cloudstack using the build :
[root@RHEL63test ~]# cloudstack-sccs
9024ad14681858ac7caafaf86f267a213ce6b61c
Deployed a user VM.
Now try to open the console of any VM.
It is displaying blank page.
In CPVM cloud.log observed the following exception continuously:
2014-06-25 06:31:14,620 INFO [utils.exception.CSExceptionErrorCode] (Console
Proxy GC Thread:null) Could not find exception:
com.cloud.exception.AgentControlChannelException in error code list for
exceptions
2014-06-25 06:31:14,621 ERROR [resource.consoleproxy.ConsoleProxyResource]
(Console Proxy GC Thread:null) Unable to send out load info due to Unable to
post agent control request as link is not available
com.cloud.exception.AgentControlChannelException: Unable to post agent
control request as link is not available
at com.cloud.agent.Agent.postRequest(Agent.java:689)
at com.cloud.agent.Agent.postRequest(Agent.java:677)
at
com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:418)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
at
com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
2014-06-25 06:31:14,621 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread]
(Console Proxy GC Thread:null) Report load change : {
connections: []
}
2014-06-25 06:31:14,897 INFO [cloud.agent.Agent] (Agent-Handler-4:null)
Reconnecting...
2014-06-25 06:31:14,897 INFO [utils.nio.NioClient] (Agent-Selector:null)
Connecting to 10.147.59.222:8250
Attaching the Ms logs and CPVM log.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-7313) Provisioning vpx in SDX from CS is failing
Rajesh Battala created CLOUDSTACK-7313: -- Summary: Provisioning vpx in SDX from CS is failing Key: CLOUDSTACK-7313 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7313 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Devices Affects Versions: 4.5.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Priority: Critical Fix For: 4.5.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6990) VM console displays blank page.AgentControlChannelException in cloud.log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Battala updated CLOUDSTACK-6990:
---
Fix Version/s: 4.5.0
VM console displays blank page.AgentControlChannelException in cloud.log
Key: CLOUDSTACK-6990
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6990
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: SystemVM
Affects Versions: 4.4.0
Reporter: manasaveloori
Assignee: Rajesh Battala
Priority: Critical
Fix For: 4.4.0, 4.5.0
Attachments: cloud.log, management-server.rar
Deployed Cloudstack using the build :
[root@RHEL63test ~]# cloudstack-sccs
9024ad14681858ac7caafaf86f267a213ce6b61c
Deployed a user VM.
Now try to open the console of any VM.
It is displaying blank page.
In CPVM cloud.log observed the following exception continuously:
2014-06-25 06:31:14,620 INFO [utils.exception.CSExceptionErrorCode] (Console
Proxy GC Thread:null) Could not find exception:
com.cloud.exception.AgentControlChannelException in error code list for
exceptions
2014-06-25 06:31:14,621 ERROR [resource.consoleproxy.ConsoleProxyResource]
(Console Proxy GC Thread:null) Unable to send out load info due to Unable to
post agent control request as link is not available
com.cloud.exception.AgentControlChannelException: Unable to post agent
control request as link is not available
at com.cloud.agent.Agent.postRequest(Agent.java:689)
at com.cloud.agent.Agent.postRequest(Agent.java:677)
at
com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:418)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
at
com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
2014-06-25 06:31:14,621 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread]
(Console Proxy GC Thread:null) Report load change : {
connections: []
}
2014-06-25 06:31:14,897 INFO [cloud.agent.Agent] (Agent-Handler-4:null)
Reconnecting...
2014-06-25 06:31:14,897 INFO [utils.nio.NioClient] (Agent-Selector:null)
Connecting to 10.147.59.222:8250
Attaching the Ms logs and CPVM log.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6990) VM console displays blank page.AgentControlChannelException in cloud.log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082040#comment-14082040
]
Rajesh Battala commented on CLOUDSTACK-6990:
this issue will get fixed by
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=c61c636ce8a1d74fd22d89026d40ba904fff6cf8
VM console displays blank page.AgentControlChannelException in cloud.log
Key: CLOUDSTACK-6990
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6990
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: SystemVM
Affects Versions: 4.4.0
Reporter: manasaveloori
Assignee: Rajesh Battala
Priority: Critical
Fix For: 4.4.0, 4.5.0
Attachments: cloud.log, management-server.rar
Deployed Cloudstack using the build :
[root@RHEL63test ~]# cloudstack-sccs
9024ad14681858ac7caafaf86f267a213ce6b61c
Deployed a user VM.
Now try to open the console of any VM.
It is displaying blank page.
In CPVM cloud.log observed the following exception continuously:
2014-06-25 06:31:14,620 INFO [utils.exception.CSExceptionErrorCode] (Console
Proxy GC Thread:null) Could not find exception:
com.cloud.exception.AgentControlChannelException in error code list for
exceptions
2014-06-25 06:31:14,621 ERROR [resource.consoleproxy.ConsoleProxyResource]
(Console Proxy GC Thread:null) Unable to send out load info due to Unable to
post agent control request as link is not available
com.cloud.exception.AgentControlChannelException: Unable to post agent
control request as link is not available
at com.cloud.agent.Agent.postRequest(Agent.java:689)
at com.cloud.agent.Agent.postRequest(Agent.java:677)
at
com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:418)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
at
com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
2014-06-25 06:31:14,621 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread]
(Console Proxy GC Thread:null) Report load change : {
connections: []
}
2014-06-25 06:31:14,897 INFO [cloud.agent.Agent] (Agent-Handler-4:null)
Reconnecting...
2014-06-25 06:31:14,897 INFO [utils.nio.NioClient] (Agent-Selector:null)
Connecting to 10.147.59.222:8250
Attaching the Ms logs and CPVM log.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6924) Exceptions are thrown when a data disk on local storage is attached/migrated to a clusterwide primary storage, zonewide primary storage or to local storage on anoth
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Battala reassigned CLOUDSTACK-6924:
--
Assignee: Rajesh Battala
Exceptions are thrown when a data disk on local storage is attached/migrated
to a clusterwide primary storage, zonewide primary storage or to local
storage on another host
---
Key: CLOUDSTACK-6924
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6924
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.4.0
Environment: Hyperv Setup with local storage, cluster wide primary
storage and zone wide primary storage
Reporter: Abhinav Roy
Assignee: Rajesh Battala
Fix For: 4.4.0
Steps :
1. Deploy a hyperv Setup with multiple clusters having local storage, cluster
wide primary storage and zone wide primary storage.
2. Deploy VMs with datadisk
v1 on local storage on host1, v2 on cwps and v3 on zwps, v4 on local
storage on host2
3. Detach the data disk from v1 and attach to v2 or v3 or v4
Expected behavior :
=
Since the migration of a data disk on local storage to cpws , zwps or local
storage on another host is not supported, we should error out the operation
with appropriate error msg and should not throw any exception.
Observed behavior :
=
Expecptions are thrown during these operations :
MS logs when with conflicting Host and Cluster scope :
---
2014-06-17 15:11:47,303 DEBUG [c.c.a.ApiServlet]
(catalina-exec-18:ctx-fb917520) ===START=== 10.144.6.9 -- GET
command=attachVolumeid=8fcefeed-9606-45a0-a482-48a52554ecd1virtualMachineId=89612a65-8398-4a61-92b4-2431b9adbe52response=jsonsessionkey=usW3Wz8dQ4fHD24kCe9r5A27Tbc%3D_=1402997805674
2014-06-17 15:11:47,348 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-18:ctx-fb917520 ctx-0622857b) submit async job-93, details:
AsyncJobVO {id:93, userId: 2, accountId: 2, instanceType: Volume, instanceId:
23, cmd:
org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin,
cmdInfo:
{response:json,id:8fcefeed-9606-45a0-a482-48a52554ecd1,sessionkey:usW3Wz8dQ4fHD24kCe9r5A27Tbc\u003d,ctxDetails:{\com.cloud.storage.Volume\:\8fcefeed-9606-45a0-a482-48a52554ecd1\,\com.cloud.vm.VirtualMachine\:\89612a65-8398-4a61-92b4-2431b9adbe52\},cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:89612a65-8398-4a61-92b4-2431b9adbe52,httpmethod:GET,_:1402997805674,uuid:8fcefeed-9606-45a0-a482-48a52554ecd1,ctxAccountId:2,ctxStartEventId:189},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-06-17 15:11:47,349 DEBUG [c.c.a.ApiServlet]
(catalina-exec-18:ctx-fb917520 ctx-0622857b) ===END=== 10.144.6.9 -- GET
command=attachVolumeid=8fcefeed-9606-45a0-a482-48a52554ecd1virtualMachineId=89612a65-8398-4a61-92b4-2431b9adbe52response=jsonsessionkey=usW3Wz8dQ4fHD24kCe9r5A27Tbc%3D_=1402997805674
2014-06-17 15:11:47,354 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-60:ctx-daa38c1b job-93) Add job-93 into job monitoring
2014-06-17 15:11:47,354 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-60:ctx-daa38c1b job-93) Executing AsyncJobVO {id:93,
userId: 2, accountId: 2, instanceType: Volume, instanceId: 23, cmd:
org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin,
cmdInfo:
{response:json,id:8fcefeed-9606-45a0-a482-48a52554ecd1,sessionkey:usW3Wz8dQ4fHD24kCe9r5A27Tbc\u003d,ctxDetails:{\com.cloud.storage.Volume\:\8fcefeed-9606-45a0-a482-48a52554ecd1\,\com.cloud.vm.VirtualMachine\:\89612a65-8398-4a61-92b4-2431b9adbe52\},cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:89612a65-8398-4a61-92b4-2431b9adbe52,httpmethod:GET,_:1402997805674,uuid:8fcefeed-9606-45a0-a482-48a52554ecd1,ctxAccountId:2,ctxStartEventId:189},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-06-17 15:11:47,372 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-60:ctx-daa38c1b job-93 ctx-9c523ebe) Sync job-94 execution
on object VmWorkJobQueue.12
2014-06-17 15:11:47,375 DEBUG [c.c.s.VolumeApiServiceImpl]
(API-Job-Executor-60:ctx-daa38c1b job-93 ctx-9c523ebe) New job 94, result
field: null
2014-06-17 15:11:47,375 WARN [c.c.u.d.Merovingian2]
(API-Job-Executor-60:ctx-daa38c1b
[jira] [Updated] (CLOUDSTACK-3265) [UI] [Health Check for NS LB]Failure to create a lb health check policy returns a API response in the UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-3265: --- Summary: [UI] [Health Check for NS LB]Failure to create a lb health check policy returns a API response in the UI (was: [Health Check for NS LB]Failure to create a lb health check policy returns a API response in the UI) [UI] [Health Check for NS LB]Failure to create a lb health check policy returns a API response in the UI Key: CLOUDSTACK-3265 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3265 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.2.0 Reporter: Abhinav Roy Priority: Minor Fix For: 4.4.0 Attachments: lb healthchecks.jpg Steps: 1. Create a LB rule with VR as LB provider. 2. Attach VMs to the LB rule. 3. Create Health check policy for that rule Expected behaviour: === 1. Since VR is not the supported provider for LB health checks the policy creation should fail gracefully. Observed behaviour: == 1. The policy creation fails as expected but the API response is turned in the UI which should not happen. A proper failure message should be displayed instead. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6924) Exceptions are thrown when a data disk on local storage is attached/migrated to a clusterwide primary storage, zonewide primary storage or to local storage on anothe
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Battala updated CLOUDSTACK-6924:
---
Assignee: (was: Rajesh Battala)
Exceptions are thrown when a data disk on local storage is attached/migrated
to a clusterwide primary storage, zonewide primary storage or to local
storage on another host
---
Key: CLOUDSTACK-6924
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6924
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.4.0
Environment: Hyperv Setup with local storage, cluster wide primary
storage and zone wide primary storage
Reporter: Abhinav Roy
Fix For: 4.4.0
Steps :
1. Deploy a hyperv Setup with multiple clusters having local storage, cluster
wide primary storage and zone wide primary storage.
2. Deploy VMs with datadisk
v1 on local storage on host1, v2 on cwps and v3 on zwps, v4 on local
storage on host2
3. Detach the data disk from v1 and attach to v2 or v3 or v4
Expected behavior :
=
Since the migration of a data disk on local storage to cpws , zwps or local
storage on another host is not supported, we should error out the operation
with appropriate error msg and should not throw any exception.
Observed behavior :
=
Expecptions are thrown during these operations :
MS logs when with conflicting Host and Cluster scope :
---
2014-06-17 15:11:47,303 DEBUG [c.c.a.ApiServlet]
(catalina-exec-18:ctx-fb917520) ===START=== 10.144.6.9 -- GET
command=attachVolumeid=8fcefeed-9606-45a0-a482-48a52554ecd1virtualMachineId=89612a65-8398-4a61-92b4-2431b9adbe52response=jsonsessionkey=usW3Wz8dQ4fHD24kCe9r5A27Tbc%3D_=1402997805674
2014-06-17 15:11:47,348 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-18:ctx-fb917520 ctx-0622857b) submit async job-93, details:
AsyncJobVO {id:93, userId: 2, accountId: 2, instanceType: Volume, instanceId:
23, cmd:
org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin,
cmdInfo:
{response:json,id:8fcefeed-9606-45a0-a482-48a52554ecd1,sessionkey:usW3Wz8dQ4fHD24kCe9r5A27Tbc\u003d,ctxDetails:{\com.cloud.storage.Volume\:\8fcefeed-9606-45a0-a482-48a52554ecd1\,\com.cloud.vm.VirtualMachine\:\89612a65-8398-4a61-92b4-2431b9adbe52\},cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:89612a65-8398-4a61-92b4-2431b9adbe52,httpmethod:GET,_:1402997805674,uuid:8fcefeed-9606-45a0-a482-48a52554ecd1,ctxAccountId:2,ctxStartEventId:189},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-06-17 15:11:47,349 DEBUG [c.c.a.ApiServlet]
(catalina-exec-18:ctx-fb917520 ctx-0622857b) ===END=== 10.144.6.9 -- GET
command=attachVolumeid=8fcefeed-9606-45a0-a482-48a52554ecd1virtualMachineId=89612a65-8398-4a61-92b4-2431b9adbe52response=jsonsessionkey=usW3Wz8dQ4fHD24kCe9r5A27Tbc%3D_=1402997805674
2014-06-17 15:11:47,354 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(API-Job-Executor-60:ctx-daa38c1b job-93) Add job-93 into job monitoring
2014-06-17 15:11:47,354 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-60:ctx-daa38c1b job-93) Executing AsyncJobVO {id:93,
userId: 2, accountId: 2, instanceType: Volume, instanceId: 23, cmd:
org.apache.cloudstack.api.command.admin.volume.AttachVolumeCmdByAdmin,
cmdInfo:
{response:json,id:8fcefeed-9606-45a0-a482-48a52554ecd1,sessionkey:usW3Wz8dQ4fHD24kCe9r5A27Tbc\u003d,ctxDetails:{\com.cloud.storage.Volume\:\8fcefeed-9606-45a0-a482-48a52554ecd1\,\com.cloud.vm.VirtualMachine\:\89612a65-8398-4a61-92b4-2431b9adbe52\},cmdEventType:VOLUME.ATTACH,ctxUserId:2,virtualMachineId:89612a65-8398-4a61-92b4-2431b9adbe52,httpmethod:GET,_:1402997805674,uuid:8fcefeed-9606-45a0-a482-48a52554ecd1,ctxAccountId:2,ctxStartEventId:189},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 213737702773493, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-06-17 15:11:47,372 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-60:ctx-daa38c1b job-93 ctx-9c523ebe) Sync job-94 execution
on object VmWorkJobQueue.12
2014-06-17 15:11:47,375 DEBUG [c.c.s.VolumeApiServiceImpl]
(API-Job-Executor-60:ctx-daa38c1b job-93 ctx-9c523ebe) New job 94, result
field: null
2014-06-17 15:11:47,375 WARN [c.c.u.d.Merovingian2]
(API-Job-Executor-60:ctx-daa38c1b job-93 ctx-9c523ebe) Was unable to
[jira] [Commented] (CLOUDSTACK-6990) VM console displays blank page.AgentControlChannelException in cloud.log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14066194#comment-14066194
]
Rajesh Battala commented on CLOUDSTACK-6990:
from logs
management server is not able to generate ssl key and trying to use the
fail-safe key.
console proxy is trying to initiate the connection and mgmt server is throwing
the request.
can you try disable zone, delete console proxy and re-enable zone.
Check why mgmt server is not generating the ssl key that would also cause the
issue.
VM console displays blank page.AgentControlChannelException in cloud.log
Key: CLOUDSTACK-6990
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6990
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: SystemVM
Affects Versions: 4.4.0
Reporter: manasaveloori
Assignee: Rajesh Battala
Priority: Critical
Fix For: 4.4.0
Attachments: cloud.log, management-server.rar
Deployed Cloudstack using the build :
[root@RHEL63test ~]# cloudstack-sccs
9024ad14681858ac7caafaf86f267a213ce6b61c
Deployed a user VM.
Now try to open the console of any VM.
It is displaying blank page.
In CPVM cloud.log observed the following exception continuously:
2014-06-25 06:31:14,620 INFO [utils.exception.CSExceptionErrorCode] (Console
Proxy GC Thread:null) Could not find exception:
com.cloud.exception.AgentControlChannelException in error code list for
exceptions
2014-06-25 06:31:14,621 ERROR [resource.consoleproxy.ConsoleProxyResource]
(Console Proxy GC Thread:null) Unable to send out load info due to Unable to
post agent control request as link is not available
com.cloud.exception.AgentControlChannelException: Unable to post agent
control request as link is not available
at com.cloud.agent.Agent.postRequest(Agent.java:689)
at com.cloud.agent.Agent.postRequest(Agent.java:677)
at
com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:418)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
at
com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
2014-06-25 06:31:14,621 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread]
(Console Proxy GC Thread:null) Report load change : {
connections: []
}
2014-06-25 06:31:14,897 INFO [cloud.agent.Agent] (Agent-Handler-4:null)
Reconnecting...
2014-06-25 06:31:14,897 INFO [utils.nio.NioClient] (Agent-Selector:null)
Connecting to 10.147.59.222:8250
Attaching the Ms logs and CPVM log.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6493) Multiple Nic for the guest VM running on Hyper-V
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-6493: --- Labels: S1 hyper-V, (was: BLR-S1 hyper-V,) Multiple Nic for the guest VM running on Hyper-V Key: CLOUDSTACK-6493 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6493 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Labels: S1, hyper-V, Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6493) Multiple Nic for the guest VM running on Hyper-V
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-6493: --- Labels: BLR-S1 hyper-V, (was: hyper-V,) Multiple Nic for the guest VM running on Hyper-V Key: CLOUDSTACK-6493 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6493 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Labels: BLR-S1, hyper-V, Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-5563) path field is set to null in volumes table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-5563: --- Labels: BLR-S1 hyper-V, (was: hyper-V,) path field is set to null in volumes table --- Key: CLOUDSTACK-5563 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5563 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server, Volumes Affects Versions: 4.3.0 Environment: Latest build from 4.3 with commit :197ef921f7b3c80998359f376fe045b13558633c Reporter: Sanjeev N Assignee: Rajesh Battala Labels: BLR-S1, hyper-V, Fix For: 4.4.0 path field is set to null in volumes table Steps to Reproduce: = 1.Bring up CS in advanced zone with hyper-v host using CIFS for both primary and secondary storage 2.Deploy a vm using default cent-os template 3.Check root volume details in volumes table. Following is the volume details from cloud DB: mysql select * from volumes where instance_id=6\G; *** 1. row *** id: 8 account_id: 2 domain_id: 1 pool_id: 1 last_pool_id: NULL instance_id: 6 device_id: 0 name: ROOT-6 uuid: 70c71522-16ec-4329-a91d-c6006534078d size: 5368709120 folder: NULL path: NULL pod_id: NULL data_center_id: 1 iscsi_name: NULL host_ip: NULL volume_type: ROOT pool_type: NULL disk_offering_id: 1 template_id: 6 first_snapshot_backup_uuid: NULL recreatable: 0 created: 2013-12-19 10:04:33 attached: NULL updated: 2013-12-19 10:04:38 removed: NULL state: Ready chain_info: NULL update_count: 2 disk_type: NULL vm_snapshot_chain_size: NULL iso_id: NULL display_volume: 1 format: NULL min_iops: NULL max_iops: NULL hv_ss_reserve: NULL 1 row in set (0.00 sec) ERROR: No query specified -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6493) Multiple Nic for the guest VM running on Hyper-V
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala closed CLOUDSTACK-6493. -- Resolution: Fixed Multiple Nic for the guest VM running on Hyper-V Key: CLOUDSTACK-6493 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6493 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Labels: hyper-V, Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-5563) path field is set to null in volumes table
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala closed CLOUDSTACK-5563. -- Resolution: Fixed path field is set to null in volumes table --- Key: CLOUDSTACK-5563 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5563 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server, Volumes Affects Versions: 4.3.0 Environment: Latest build from 4.3 with commit :197ef921f7b3c80998359f376fe045b13558633c Reporter: Sanjeev N Assignee: Rajesh Battala Labels: hyper-V, Fix For: 4.4.0 path field is set to null in volumes table Steps to Reproduce: = 1.Bring up CS in advanced zone with hyper-v host using CIFS for both primary and secondary storage 2.Deploy a vm using default cent-os template 3.Check root volume details in volumes table. Following is the volume details from cloud DB: mysql select * from volumes where instance_id=6\G; *** 1. row *** id: 8 account_id: 2 domain_id: 1 pool_id: 1 last_pool_id: NULL instance_id: 6 device_id: 0 name: ROOT-6 uuid: 70c71522-16ec-4329-a91d-c6006534078d size: 5368709120 folder: NULL path: NULL pod_id: NULL data_center_id: 1 iscsi_name: NULL host_ip: NULL volume_type: ROOT pool_type: NULL disk_offering_id: 1 template_id: 6 first_snapshot_backup_uuid: NULL recreatable: 0 created: 2013-12-19 10:04:33 attached: NULL updated: 2013-12-19 10:04:38 removed: NULL state: Ready chain_info: NULL update_count: 2 disk_type: NULL vm_snapshot_chain_size: NULL iso_id: NULL display_volume: 1 format: NULL min_iops: NULL max_iops: NULL hv_ss_reserve: NULL 1 row in set (0.00 sec) ERROR: No query specified -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6521) [Hyper-V] fix generating of Hyper-v template in jenkins
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-6521. Resolution: Fixed [Hyper-V] fix generating of Hyper-v template in jenkins --- Key: CLOUDSTACK-6521 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6521 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6261) remove the forceful timeout setting when login to NetScaler
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala closed CLOUDSTACK-6261. -- Resolution: Fixed remove the forceful timeout setting when login to NetScaler --- Key: CLOUDSTACK-6261 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6261 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Devices Affects Versions: 4.4.0 Environment: NetScaler VPX/MPX 10.5+ (code does not force timeout when login to SDX) Reporter: Vijay Venkatachalam Assignee: Rajesh Battala Priority: Minor Labels: patch Fix For: 4.4.0 Original Estimate: 2h Remaining Estimate: 2h Today, the NetScaler Resource forces a idle timeout of 100,000 seconds (~1 day and 4 hours) during login. The request is to remove forcing the timeout to a specific value. Also, future versions of NetScaler is planning to have a cap of 1 day for this setting. It is best to leave it to the system default which is 30 mins. This should be enough, anyway there are threads for monitoring of member status, and statistics collections that keeps the session alive and it is unlikely to gather idle time. The NetScaler resource already handles timeout expiry using retries so there should not be any see side effects by leaving the idle time out to be the default value 30 mins.. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7037) Unable to add new vm/service to existing LB rule of SSL protocol
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-7037. Resolution: Fixed Unable to add new vm/service to existing LB rule of SSL protocol Key: CLOUDSTACK-7037 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7037 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.5.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Priority: Blocker Fix For: 4.5.0 Exception is thrown from nitro api when try to add new vm to LB rule. INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-20:ctx-eb12ce6b job-82) Add job-82 into job monitoring ERROR [c.c.n.r.NetscalerResource] (DirectAgent-418:ctx-6caefe76) Failed to execute LoadBalancerConfigCommand due to com.citrix.netscaler.nitro.exception.nitro_exception: Operation not permitted at com.citrix.netscaler.nitro.resource.base.base_resource.put_data(base_resource.java:693) at com.citrix.netscaler.nitro.resource.base.base_resource.update_resource(base_resource.java:196) at com.citrix.netscaler.nitro.resource.base.base_resource.update_resource(base_resource.java:180) at com.citrix.netscaler.nitro.resource.config.lb.lbvserver_service_binding.add(lbvserver_service_binding.java:256) at com.cloud.network.resource.NetscalerResource.execute(NetscalerResource.java:650) at com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:427) at com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:416) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:293) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6920) Support listing of LBHealthcheck policy with LBHealthcheck policy ID
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-6920. Resolution: Fixed Support listing of LBHealthcheck policy with LBHealthcheck policy ID Key: CLOUDSTACK-6920 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6920 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7037) Unable to add new vm/service to existing LB rule of SSL protocol
Rajesh Battala created CLOUDSTACK-7037: -- Summary: Unable to add new vm/service to existing LB rule of SSL protocol Key: CLOUDSTACK-7037 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7037 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.5.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Priority: Blocker Fix For: 4.5.0 Exception is thrown from nitro api when try to add new vm to LB rule. INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-20:ctx-eb12ce6b job-82) Add job-82 into job monitoring ERROR [c.c.n.r.NetscalerResource] (DirectAgent-418:ctx-6caefe76) Failed to execute LoadBalancerConfigCommand due to com.citrix.netscaler.nitro.exception.nitro_exception: Operation not permitted at com.citrix.netscaler.nitro.resource.base.base_resource.put_data(base_resource.java:693) at com.citrix.netscaler.nitro.resource.base.base_resource.update_resource(base_resource.java:196) at com.citrix.netscaler.nitro.resource.base.base_resource.update_resource(base_resource.java:180) at com.citrix.netscaler.nitro.resource.config.lb.lbvserver_service_binding.add(lbvserver_service_binding.java:256) at com.cloud.network.resource.NetscalerResource.execute(NetscalerResource.java:650) at com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:427) at com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:416) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:293) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7037) Unable to add new vm/service to existing LB rule of SSL protocol
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14049722#comment-14049722 ] Rajesh Battala commented on CLOUDSTACK-7037: Root Cause: When try to add the VM to LB rule of SSL protocol, first service is getting added with ssl type instead of HTTP. As service is getting created with SSL type and binding to SSL lb vserver which will take HTTP based servers is failing. This bug is introduced by SSL Offload/Terminate feature. I will be fixing this issue by making servvice to be HTTP type when its getting assigned to SSL type lb vserver. Unable to add new vm/service to existing LB rule of SSL protocol Key: CLOUDSTACK-7037 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7037 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.5.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Priority: Blocker Fix For: 4.5.0 Exception is thrown from nitro api when try to add new vm to LB rule. INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-20:ctx-eb12ce6b job-82) Add job-82 into job monitoring ERROR [c.c.n.r.NetscalerResource] (DirectAgent-418:ctx-6caefe76) Failed to execute LoadBalancerConfigCommand due to com.citrix.netscaler.nitro.exception.nitro_exception: Operation not permitted at com.citrix.netscaler.nitro.resource.base.base_resource.put_data(base_resource.java:693) at com.citrix.netscaler.nitro.resource.base.base_resource.update_resource(base_resource.java:196) at com.citrix.netscaler.nitro.resource.base.base_resource.update_resource(base_resource.java:180) at com.citrix.netscaler.nitro.resource.config.lb.lbvserver_service_binding.add(lbvserver_service_binding.java:256) at com.cloud.network.resource.NetscalerResource.execute(NetscalerResource.java:650) at com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:427) at com.cloud.network.resource.NetscalerResource.executeRequest(NetscalerResource.java:416) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:293) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6971) createAutoScaleVmProfile failed with NPE due to lack of bean injection.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14039765#comment-14039765 ] Rajesh Battala commented on CLOUDSTACK-6971: Am able to created autoscale polices successfuly now. createAutoScaleVmProfile failed with NPE due to lack of bean injection. --- Key: CLOUDSTACK-6971 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6971 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.4.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.4.0 When creating autoscale policy, its failing to create with below NPE exception. INFO [o.a.c.f.j.i.AsyncJobMonitor] (API-Job-Executor-4:ctx-f439aaf2 job-146) Remove job-146 from job monitoring ERROR [c.c.a.ApiServer] (21050798@qtp-4315003-10:ctx-1bb507da ctx-db84c324) unhandled exception executing api command: [Ljava.lang.String;@17b6fd java.lang.NullPointerException at org.apache.cloudstack.api.command.user.vm.DeployVMCmd.getEntityOwnerId(DeployVMCmd.java:410) at com.cloud.api.dispatch.ParamProcessWorker.doAccessChecks(ParamProcessWorker.java:222) at com.cloud.api.dispatch.ParamProcessWorker.processParameters(ParamProcessWorker.java:216) at com.cloud.api.dispatch.ParamProcessWorker.handle(ParamProcessWorker.java:88) at com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37) at com.cloud.network.as.AutoScaleManagerImpl.createAutoScaleVmProfile(AutoScaleManagerImpl.java:373) 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:601) 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.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51) 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 $Proxy250.createAutoScaleVmProfile(Unknown Source) at org.apache.cloudstack.api.command.user.autoscale.CreateAutoScaleVmProfileCmd.create(CreateAutoScaleVmProfileCmd.java:263) at com.cloud.api.dispatch.CommandCreationWorker.handle(CommandCreationWorker.java:47) at com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37) at com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:79) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:614) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:506) at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:330) at com.cloud.api.ApiServlet.access$000(ApiServlet.java:54) at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) at
[jira] [Commented] (CLOUDSTACK-6921) Support listing of LBStickinesspolicy with LBStickiness policy ID
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14035591#comment-14035591 ] Rajesh Battala commented on CLOUDSTACK-6921: fixed by this commit https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=b0d726a872e2859a56ee677c15079cc3a59ab894 Support listing of LBStickinesspolicy with LBStickiness policy ID - Key: CLOUDSTACK-6921 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6921 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6921) Support listing of LBStickinesspolicy with LBStickiness policy ID
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-6921. Resolution: Fixed Support listing of LBStickinesspolicy with LBStickiness policy ID - Key: CLOUDSTACK-6921 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6921 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6921) Support listing of LBStickinesspolicy with LBStickiness policy ID
Rajesh Battala created CLOUDSTACK-6921: -- Summary: Support listing of LBStickinesspolicy with LBStickiness policy ID Key: CLOUDSTACK-6921 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6921 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6886) Cannot add SDX Netscaler device
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027423#comment-14027423 ] Rajesh Battala commented on CLOUDSTACK-6886: is license activated on the device? Cannot add SDX Netscaler device --- Key: CLOUDSTACK-6886 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886 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: CloudStack 4.3 build with noredist packages Reporter: Pierre-Luc Dion Attachments: cs4.3_SDXfail.png on CloudStack 4.3 with noredist packages, Adding a Netscaler device in Network Service Providers as NetScaler SDX LoadBalancer type failed with following error message: Failed to enable ssl feature on load balancer due to null Test perform using CloudStack webui. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6603) [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to 4.4
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-6603. Resolution: Fixed [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to 4.4 Key: CLOUDSTACK-6603 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6603 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.4.0 Reporter: manasaveloori Assignee: Rajesh Battala Priority: Blocker Fix For: 4.4.0 Attachments: management-server.rar, mysqldump43.dmp, mysqldump44.dmp 1. Deploy CS 4.3 with 2 zones using xen 6.1 and KVM hypervisor. 2. Configured LB rules,firewall rules. 3. Registered the template for 4.4 (using the naming convention systemvm-xenserver-4.4,systemvm-kvm-4.4) 4. Upgraded to 4.4 Start the management server: Below are the observations: 2014-05-05 05:05:13,567 DEBUG [c.c.s.StatsCollector] (StatsCollector-4:ctx-e36f20e1) AutoScaling Monitor is running... 2014-05-05 05:05:13,577 ERROR [c.c.s.StatsCollector] (StatsCollector-4:ctx-e36f20e1) Error trying to monitor autoscaling com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@5b140551: SELECT autoscale_vmgroups.id, autoscale_vmgroups.uuid, autoscale_vmgroups.zone_id, autoscale_vmgroups.domain_id, autoscale_vmgroups.account_id, autoscale_vmgroups.load_balancer_id, autoscale_vmgroups.min_members, autoscale_vmgroups.max_members, autoscale_vmgroups.member_port, autoscale_vmgroups.interval, autoscale_vmgroups.last_interval, autoscale_vmgroups.profile_id, autoscale_vmgroups.removed, autoscale_vmgroups.created, autoscale_vmgroups.state, autoscale_vmgroups.display FROM autoscale_vmgroups WHERE autoscale_vmgroups.removed IS NULL at com.cloud.utils.db.GenericDaoBase.executeList(GenericDaoBase.java:1127) at com.cloud.utils.db.GenericDaoBase.listAll(GenericDaoBase.java:1150) at com.cloud.utils.db.GenericDaoBase.listAll(GenericDaoBase.java:1136) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) 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 com.sun.proxy.$Proxy220.listAll(Unknown Source) at com.cloud.server.StatsCollector$AutoScaleMonitor.runInContext(StatsCollector.java:673) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Unknown column 'autoscale_vmgroups.last_interval' in 'field list' at
[jira] [Resolved] (CLOUDSTACK-6831) [Hyper-V] Improve the logging for VM snapshot failures as it is not supported. Right now it is throwing NPEs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-6831. Resolution: Fixed [Hyper-V] Improve the logging for VM snapshot failures as it is not supported. Right now it is throwing NPEs Key: CLOUDSTACK-6831 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6831 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: HyperV Reporter: Abhinav Roy Assignee: Rajesh Battala Fix For: 4.4.0 Steps : 1. Deploy a advanced zone hyperv setup. 2. Create a VM v1. 3. Create a VM snapshot on v1 Expected behavior : Since VM snapshot is not supported in 4.4.0 for HyperV, the operation should fail gracefully with appropriate error message. Observed behavior : === VM snapshot operation fails with a NPE 2014-06-03 15:21:25,150 DEBUG [c.c.a.ApiServlet] (catalina-exec-7:ctx-8ce4a754) ===START=== 10.144.7.13 -- GET command=createVMSnapshotvirtualmachineid=fb624f96-c70f-4e25-94a0-65f9daf145aasnapshotmemory=falsequiescevm=falsename=ssresponse=jsonsessionkey=o%2F8Vw1YoKZS4JAca7rkI3sCMSDs%3D_=1401788814498 2014-06-03 15:21:25,168 ERROR [c.c.a.ApiServer] (catalina-exec-7:ctx-8ce4a754 ctx-ce4443a6) unhandled exception executing api command: [Ljava.lang.String;@7cfb6b51 java.lang.NullPointerException at com.cloud.hypervisor.dao.HypervisorCapabilitiesDaoImpl.isVmSnapshotEnabled(HypervisorCapabilitiesDaoImpl.java:104) 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:601) 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.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) 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 $Proxy179.isVmSnapshotEnabled(Unknown Source) at com.cloud.vm.snapshot.VMSnapshotManagerImpl.allocVMSnapshot(VMSnapshotManagerImpl.java:265) 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:601) 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 $Proxy182.allocVMSnapshot(Unknown Source) at org.apache.cloudstack.api.command.user.vmsnapshot.CreateVMSnapshotCmd.create(CreateVMSnapshotCmd.java:92) at com.cloud.api.dispatch.CommandCreationWorker.handle(CommandCreationWorker.java:47) at com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37) at com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:79) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:614) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:506) at
[jira] [Resolved] (CLOUDSTACK-6833) [Hyper-V] Volume snapshot creation returns success even though snapshots are not supported for Hyper-V
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-6833. Resolution: Fixed [Hyper-V] Volume snapshot creation returns success even though snapshots are not supported for Hyper-V -- Key: CLOUDSTACK-6833 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6833 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Snapshot Affects Versions: 4.4.0 Environment: Hyper-V Reporter: Abhinav Roy Assignee: Rajesh Battala Fix For: 4.4.0 Steps : 1. Deploy an advanced zone CS setup with hyperv . 2. Create a VM. 3. Goto the ROOT volume of the VM created in above step and take a snapshot. Expected behavior : Since snapshots are not supported for Hyper-V in Felton, the operation should error out with a valid exception/error and the job should fail. Observed behaviour : === Exception is thrown in MS but the async job succeeds. In the UI also job succeeds but snapshots are in error state. 2014-06-03 15:31:30,360 DEBUG [o.a.c.s.s.SnapshotServiceImpl] (Work-Job-Executor-40:ctx-9b7ff57b job-145/job-146 ctx-079ae456) create snapshot stag4_ROOT-23_20140603100128 failed: org.apache.cloudstack.storage.command.CreateObjectCommand failed on exception, Object reference not set to an instance of an object. 2014-06-03 15:31:30,382 DEBUG [o.a.c.s.s.XenserverSnapshotStrategy] (Work-Job-Executor-40:ctx-9b7ff57b job-145/job-146 ctx-079ae456) Failed to take snapshot: org.apache.cloudstack.storage.command.CreateObjectCommand failed on exception, Object reference not set to an instance of an object. 2014-06-03 15:31:30,398 DEBUG [c.c.s.s.SnapshotManagerImpl] (Work-Job-Executor-40:ctx-9b7ff57b job-145/job-146 ctx-079ae456) Failed to create snapshot com.cloud.utils.exception.CloudRuntimeException: org.apache.cloudstack.storage.command.CreateObjectCommand failed on exception, Object reference not set to an instance of an object. at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:287) at com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:922) 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:601) 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 $Proxy177.takeSnapshot(Unknown Source) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1503) at com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1769) at com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:2504) 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:601) at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) at com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2512) 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:601) at
[jira] [Assigned] (CLOUDSTACK-6831) [Hyper-V] Improve the logging for VM snapshot failures as it is not supported. Right now it is throwing NPEs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala reassigned CLOUDSTACK-6831: -- Assignee: Rajesh Battala [Hyper-V] Improve the logging for VM snapshot failures as it is not supported. Right now it is throwing NPEs Key: CLOUDSTACK-6831 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6831 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Environment: HyperV Reporter: Abhinav Roy Assignee: Rajesh Battala Fix For: 4.4.0 Steps : 1. Deploy a advanced zone hyperv setup. 2. Create a VM v1. 3. Create a VM snapshot on v1 Expected behavior : Since VM snapshot is not supported in 4.4.0 for HyperV, the operation should fail gracefully with appropriate error message. Observed behavior : === VM snapshot operation fails with a NPE 2014-06-03 15:21:25,150 DEBUG [c.c.a.ApiServlet] (catalina-exec-7:ctx-8ce4a754) ===START=== 10.144.7.13 -- GET command=createVMSnapshotvirtualmachineid=fb624f96-c70f-4e25-94a0-65f9daf145aasnapshotmemory=falsequiescevm=falsename=ssresponse=jsonsessionkey=o%2F8Vw1YoKZS4JAca7rkI3sCMSDs%3D_=1401788814498 2014-06-03 15:21:25,168 ERROR [c.c.a.ApiServer] (catalina-exec-7:ctx-8ce4a754 ctx-ce4443a6) unhandled exception executing api command: [Ljava.lang.String;@7cfb6b51 java.lang.NullPointerException at com.cloud.hypervisor.dao.HypervisorCapabilitiesDaoImpl.isVmSnapshotEnabled(HypervisorCapabilitiesDaoImpl.java:104) 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:601) 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.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) 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 $Proxy179.isVmSnapshotEnabled(Unknown Source) at com.cloud.vm.snapshot.VMSnapshotManagerImpl.allocVMSnapshot(VMSnapshotManagerImpl.java:265) 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:601) 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 $Proxy182.allocVMSnapshot(Unknown Source) at org.apache.cloudstack.api.command.user.vmsnapshot.CreateVMSnapshotCmd.create(CreateVMSnapshotCmd.java:92) at com.cloud.api.dispatch.CommandCreationWorker.handle(CommandCreationWorker.java:47) at com.cloud.api.dispatch.DispatchChain.dispatch(DispatchChain.java:37) at com.cloud.api.ApiDispatcher.dispatchCreateCmd(ApiDispatcher.java:79) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:614) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:506) at
[jira] [Commented] (CLOUDSTACK-6603) [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to 4.4
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14015397#comment-14015397 ] Rajesh Battala commented on CLOUDSTACK-6603: this issues got created by this commit https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=dc151115be3e922933ea26ab1507eb6469a91e11 schema of autoscale_vmgroups table got changed in wrong version of schema file cause the upgrade failed. Instead of adding to the upgrade path file it was added to setup/db/db/schema-40to410.sql file. [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to 4.4 Key: CLOUDSTACK-6603 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6603 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.4.0 Reporter: manasaveloori Assignee: Rajesh Battala Priority: Blocker Fix For: 4.4.0 Attachments: management-server.rar, mysqldump43.dmp, mysqldump44.dmp 1. Deploy CS 4.3 with 2 zones using xen 6.1 and KVM hypervisor. 2. Configured LB rules,firewall rules. 3. Registered the template for 4.4 (using the naming convention systemvm-xenserver-4.4,systemvm-kvm-4.4) 4. Upgraded to 4.4 Start the management server: Below are the observations: 2014-05-05 05:05:13,567 DEBUG [c.c.s.StatsCollector] (StatsCollector-4:ctx-e36f20e1) AutoScaling Monitor is running... 2014-05-05 05:05:13,577 ERROR [c.c.s.StatsCollector] (StatsCollector-4:ctx-e36f20e1) Error trying to monitor autoscaling com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@5b140551: SELECT autoscale_vmgroups.id, autoscale_vmgroups.uuid, autoscale_vmgroups.zone_id, autoscale_vmgroups.domain_id, autoscale_vmgroups.account_id, autoscale_vmgroups.load_balancer_id, autoscale_vmgroups.min_members, autoscale_vmgroups.max_members, autoscale_vmgroups.member_port, autoscale_vmgroups.interval, autoscale_vmgroups.last_interval, autoscale_vmgroups.profile_id, autoscale_vmgroups.removed, autoscale_vmgroups.created, autoscale_vmgroups.state, autoscale_vmgroups.display FROM autoscale_vmgroups WHERE autoscale_vmgroups.removed IS NULL at com.cloud.utils.db.GenericDaoBase.executeList(GenericDaoBase.java:1127) at com.cloud.utils.db.GenericDaoBase.listAll(GenericDaoBase.java:1150) at com.cloud.utils.db.GenericDaoBase.listAll(GenericDaoBase.java:1136) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) 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 com.sun.proxy.$Proxy220.listAll(Unknown Source) at com.cloud.server.StatsCollector$AutoScaleMonitor.runInContext(StatsCollector.java:673) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
[jira] [Resolved] (CLOUDSTACK-6519) [Hyper-V] while adding VM to Network it should throw error when it is in running state
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-6519. Resolution: Fixed [Hyper-V] while adding VM to Network it should throw error when it is in running state -- Key: CLOUDSTACK-6519 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6519 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Priority: Critical Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6603) [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to 4.4
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14014525#comment-14014525 ] Rajesh Battala commented on CLOUDSTACK-6603: last_interval column is created along with the table creation of autoscale_vmgroups from ./db/db/schema-40to410.sql In 4.2 and 4.3, deploying db autoscale_vmgroups tables don't have last_interval column. but in 4.4 code deploying db this column is present. As the column last_interval is missing, autoscale manager and autoscalevmgroupvo is referring to this column exception is happening. [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to 4.4 Key: CLOUDSTACK-6603 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6603 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.4.0 Reporter: manasaveloori Assignee: Rajesh Battala Priority: Blocker Fix For: 4.4.0 Attachments: management-server.rar, mysqldump43.dmp, mysqldump44.dmp 1. Deploy CS 4.3 with 2 zones using xen 6.1 and KVM hypervisor. 2. Configured LB rules,firewall rules. 3. Registered the template for 4.4 (using the naming convention systemvm-xenserver-4.4,systemvm-kvm-4.4) 4. Upgraded to 4.4 Start the management server: Below are the observations: 2014-05-05 05:05:13,567 DEBUG [c.c.s.StatsCollector] (StatsCollector-4:ctx-e36f20e1) AutoScaling Monitor is running... 2014-05-05 05:05:13,577 ERROR [c.c.s.StatsCollector] (StatsCollector-4:ctx-e36f20e1) Error trying to monitor autoscaling com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@5b140551: SELECT autoscale_vmgroups.id, autoscale_vmgroups.uuid, autoscale_vmgroups.zone_id, autoscale_vmgroups.domain_id, autoscale_vmgroups.account_id, autoscale_vmgroups.load_balancer_id, autoscale_vmgroups.min_members, autoscale_vmgroups.max_members, autoscale_vmgroups.member_port, autoscale_vmgroups.interval, autoscale_vmgroups.last_interval, autoscale_vmgroups.profile_id, autoscale_vmgroups.removed, autoscale_vmgroups.created, autoscale_vmgroups.state, autoscale_vmgroups.display FROM autoscale_vmgroups WHERE autoscale_vmgroups.removed IS NULL at com.cloud.utils.db.GenericDaoBase.executeList(GenericDaoBase.java:1127) at com.cloud.utils.db.GenericDaoBase.listAll(GenericDaoBase.java:1150) at com.cloud.utils.db.GenericDaoBase.listAll(GenericDaoBase.java:1136) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) 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 com.sun.proxy.$Proxy220.listAll(Unknown Source) at com.cloud.server.StatsCollector$AutoScaleMonitor.runInContext(StatsCollector.java:673) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at
[jira] [Resolved] (CLOUDSTACK-6038) systemvm template for HyperV with jre7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-6038. Resolution: Fixed systemvm template for hyperv is running with jre7 systemvm template for HyperV with jre7 -- Key: CLOUDSTACK-6038 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6038 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Labels: hyperv Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6521) [Hyper-V] fix generating of Hyper-v template in jenkins
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14014528#comment-14014528 ] Rajesh Battala commented on CLOUDSTACK-6521: got fixed with this commit https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=fefddc062486ed0c997309b719fd4b2f89b9b62c [Hyper-V] fix generating of Hyper-v template in jenkins --- Key: CLOUDSTACK-6521 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6521 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6778) [HyperV] Storage motion/migration is failing if the Hosts are having different NIC names
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajesh Battala updated CLOUDSTACK-6778:
---
Assignee: Anshul Gangwar (was: Rajesh Battala)
[HyperV] Storage motion/migration is failing if the Hosts are having
different NIC names
Key: CLOUDSTACK-6778
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6778
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.4.0
Reporter: Abhinav Roy
Assignee: Anshul Gangwar
Priority: Critical
Labels: hyper-V,, hyper-v, hyperv
Fix For: 4.4.0
Steps :
==
1. Deploy a CS advanced zone setup with HyperV having 2 clusters.
2. cl1 has 2 hosts h1 and h2, cl2 has 1 host h3,
3. Deploy a VM on cl1 and the migrate that VM2 to h3.
Here the NIC names of h1 and h3 are different :
h1 : Broadcom BCM5716C NetXtreme II GigE (NDIS VBD Client) #38 - Virtual
Switch
h3 : Broadcom BCM5716C NetXtreme II GigE (NDIS VBD Client) #39 - Virtual
Switch
Expected behavior :
===
The migration of VM with storage should succeed.
Observed behavior :
===
Migration fails with the following error :
2014-05-27 14:29:09,072 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-434:ctx-960ed94b) POST response is
[{com.cloud.agent.api.MigrateWithStorageAnswer:{result:false,volumeTos:[{id:9,name:ROOT-7,path:f2c8aa38-288f-4477-afd7-b2c23f5fd848,size:5368709120,type:ROOT,storagePoolType:SMB,storagePoolUuid:38aee7de-07f1-3f23-8f8d-6a772fb9811d,deviceId:0}],details:com.cloud.agent.api.MigrateWithStorageCommand
failed due to Hyper-V Job failed, Error Code:32784, Description: Virtual
machine migration operation for 'i-2-7-VM' failed at migration destination
'HYPERV20.blr.cloudstack.org'. (Virtual machine ID
FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)
The virtual machine 'i-2-7-VM' is not compatible with physical computer
'HYPERV20'. (Virtual machine ID FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)
Could not find Ethernet switch 'Broadcom BCM5716C NetXtreme II GigE (NDIS VBD
Client) #39 - Virtual Switch'.,contextMap:{}}}]
2014-05-27 14:29:09,073 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-434:ctx-960ed94b) executeRequest received response
[Lcom.cloud.agent.api.Answer;@3ab8553b
2014-05-27 14:29:09,073 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-434:ctx-960ed94b) Seq 5-2135832123280457911: Response Received:
2014-05-27 14:29:09,073 DEBUG [c.c.a.t.Request]
(DirectAgent-434:ctx-960ed94b) Seq 5-2135832123280457911: Processing: { Ans:
, MgmtId: 213737702773493, via: 5, Ver: v1, Flags: 110,
[{com.cloud.agent.api.MigrateWithStorageAnswer:{volumeTos:[{name:ROOT-7,size:5368709120,path:f2c8aa38-288f-4477-afd7-b2c23f5fd848,accountId:0,id:9,deviceId:0}],result:false,details:com.cloud.agent.api.MigrateWithStorageCommand
failed due to Hyper-V Job failed, Error Code:32784, Description: Virtual
machine migration operation for 'i-2-7-VM' failed at migration destination
'HYPERV20.blr.cloudstack.org'. (Virtual machine ID
FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)\n\nThe virtual machine 'i-2-7-VM' is
not compatible with physical computer 'HYPERV20'. (Virtual machine ID
FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)\n\nCould not find Ethernet switch
'Broadcom BCM5716C NetXtreme II GigE (NDIS VBD Client) #39 - Virtual
Switch'.,wait:0}}] }
2014-05-27 14:29:09,074 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-5:ctx-083e8c2f job-45/job-46 ctx-966940f6) Seq
5-2135832123280457911: Received: { Ans: , MgmtId: 213737702773493, via: 5,
Ver: v1, Flags: 110, { MigrateWithStorageAnswer } }
2014-05-27 14:29:09,077 DEBUG [c.c.a.m.AgentAttache]
(DirectAgent-434:ctx-960ed94b) Seq 5-2135832123280457911: No more commands
found
2014-05-27 14:29:09,074 ERROR [o.a.c.s.m.HypervStorageMotionStrategy]
(Work-Job-Executor-5:ctx-083e8c2f job-45/job-46 ctx-966940f6) Migration with
storage of vm VM[User|i-2-7-VM] failed. Details:
com.cloud.agent.api.MigrateWithStorageCommand failed due to Hyper-V Job
failed, Error Code:32784, Description: Virtual machine migration operation
for 'i-2-7-VM' failed at migration destination 'HYPERV20.blr.cloudstack.org'.
(Virtual machine ID FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)
The virtual machine 'i-2-7-VM' is not compatible with physical computer
'HYPERV20'. (Virtual machine ID FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)
Could not find Ethernet switch 'Broadcom BCM5716C NetXtreme II GigE (NDIS VBD
Client) #39 - Virtual Switch'.
2014-05-27 14:29:09,077 ERROR
[jira] [Commented] (CLOUDSTACK-6603) [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to 4.4
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011221#comment-14011221 ] Rajesh Battala commented on CLOUDSTACK-6603: I have analysed the dumps. this field last_interval is not present in 43 db dmp and 4.4 db dmp. Will figure out any new code changes had caused issues. [Upgrade]DB Exception while Autoscale monitoring after upgrading from 4.3 to 4.4 Key: CLOUDSTACK-6603 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6603 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.4.0 Reporter: manasaveloori Assignee: Rajesh Battala Priority: Blocker Fix For: 4.4.0 Attachments: management-server.rar, mysqldump43.dmp, mysqldump44.dmp 1. Deploy CS 4.3 with 2 zones using xen 6.1 and KVM hypervisor. 2. Configured LB rules,firewall rules. 3. Registered the template for 4.4 (using the naming convention systemvm-xenserver-4.4,systemvm-kvm-4.4) 4. Upgraded to 4.4 Start the management server: Below are the observations: 2014-05-05 05:05:13,567 DEBUG [c.c.s.StatsCollector] (StatsCollector-4:ctx-e36f20e1) AutoScaling Monitor is running... 2014-05-05 05:05:13,577 ERROR [c.c.s.StatsCollector] (StatsCollector-4:ctx-e36f20e1) Error trying to monitor autoscaling com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.jdbc.JDBC4PreparedStatement@5b140551: SELECT autoscale_vmgroups.id, autoscale_vmgroups.uuid, autoscale_vmgroups.zone_id, autoscale_vmgroups.domain_id, autoscale_vmgroups.account_id, autoscale_vmgroups.load_balancer_id, autoscale_vmgroups.min_members, autoscale_vmgroups.max_members, autoscale_vmgroups.member_port, autoscale_vmgroups.interval, autoscale_vmgroups.last_interval, autoscale_vmgroups.profile_id, autoscale_vmgroups.removed, autoscale_vmgroups.created, autoscale_vmgroups.state, autoscale_vmgroups.display FROM autoscale_vmgroups WHERE autoscale_vmgroups.removed IS NULL at com.cloud.utils.db.GenericDaoBase.executeList(GenericDaoBase.java:1127) at com.cloud.utils.db.GenericDaoBase.listAll(GenericDaoBase.java:1150) at com.cloud.utils.db.GenericDaoBase.listAll(GenericDaoBase.java:1136) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) 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 com.sun.proxy.$Proxy220.listAll(Unknown Source) at com.cloud.server.StatsCollector$AutoScaleMonitor.runInContext(StatsCollector.java:673) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at
[jira] [Resolved] (CLOUDSTACK-6518) [Hyper-V] Efficient way of finding the empty nic in VR
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-6518. Resolution: Fixed [Hyper-V] Efficient way of finding the empty nic in VR --- Key: CLOUDSTACK-6518 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6518 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Priority: Critical Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6778) [HyperV] Storage motion/migration is failing if the Hosts are having different NIC names
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14011997#comment-14011997
]
Rajesh Battala commented on CLOUDSTACK-6778:
Any traffic labels are configured from cloudstack?
how about manual migration from hyperv manager of the same VM?
can you share the results when migrating the same VM with c/s without cs(hyperv
manager).
[HyperV] Storage motion/migration is failing if the Hosts are having
different NIC names
Key: CLOUDSTACK-6778
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6778
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server
Affects Versions: 4.4.0
Reporter: Abhinav Roy
Assignee: Rajesh Battala
Priority: Critical
Labels: hyper-V,, hyper-v, hyperv
Fix For: 4.4.0
Steps :
==
1. Deploy a CS advanced zone setup with HyperV having 2 clusters.
2. cl1 has 2 hosts h1 and h2, cl2 has 1 host h3,
3. Deploy a VM on cl1 and the migrate that VM2 to h3.
Here the NIC names of h1 and h3 are different :
h1 : Broadcom BCM5716C NetXtreme II GigE (NDIS VBD Client) #38 - Virtual
Switch
h3 : Broadcom BCM5716C NetXtreme II GigE (NDIS VBD Client) #39 - Virtual
Switch
Expected behavior :
===
The migration of VM with storage should succeed.
Observed behavior :
===
Migration fails with the following error :
2014-05-27 14:29:09,072 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-434:ctx-960ed94b) POST response is
[{com.cloud.agent.api.MigrateWithStorageAnswer:{result:false,volumeTos:[{id:9,name:ROOT-7,path:f2c8aa38-288f-4477-afd7-b2c23f5fd848,size:5368709120,type:ROOT,storagePoolType:SMB,storagePoolUuid:38aee7de-07f1-3f23-8f8d-6a772fb9811d,deviceId:0}],details:com.cloud.agent.api.MigrateWithStorageCommand
failed due to Hyper-V Job failed, Error Code:32784, Description: Virtual
machine migration operation for 'i-2-7-VM' failed at migration destination
'HYPERV20.blr.cloudstack.org'. (Virtual machine ID
FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)
The virtual machine 'i-2-7-VM' is not compatible with physical computer
'HYPERV20'. (Virtual machine ID FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)
Could not find Ethernet switch 'Broadcom BCM5716C NetXtreme II GigE (NDIS VBD
Client) #39 - Virtual Switch'.,contextMap:{}}}]
2014-05-27 14:29:09,073 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
(DirectAgent-434:ctx-960ed94b) executeRequest received response
[Lcom.cloud.agent.api.Answer;@3ab8553b
2014-05-27 14:29:09,073 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-434:ctx-960ed94b) Seq 5-2135832123280457911: Response Received:
2014-05-27 14:29:09,073 DEBUG [c.c.a.t.Request]
(DirectAgent-434:ctx-960ed94b) Seq 5-2135832123280457911: Processing: { Ans:
, MgmtId: 213737702773493, via: 5, Ver: v1, Flags: 110,
[{com.cloud.agent.api.MigrateWithStorageAnswer:{volumeTos:[{name:ROOT-7,size:5368709120,path:f2c8aa38-288f-4477-afd7-b2c23f5fd848,accountId:0,id:9,deviceId:0}],result:false,details:com.cloud.agent.api.MigrateWithStorageCommand
failed due to Hyper-V Job failed, Error Code:32784, Description: Virtual
machine migration operation for 'i-2-7-VM' failed at migration destination
'HYPERV20.blr.cloudstack.org'. (Virtual machine ID
FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)\n\nThe virtual machine 'i-2-7-VM' is
not compatible with physical computer 'HYPERV20'. (Virtual machine ID
FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)\n\nCould not find Ethernet switch
'Broadcom BCM5716C NetXtreme II GigE (NDIS VBD Client) #39 - Virtual
Switch'.,wait:0}}] }
2014-05-27 14:29:09,074 DEBUG [c.c.a.t.Request]
(Work-Job-Executor-5:ctx-083e8c2f job-45/job-46 ctx-966940f6) Seq
5-2135832123280457911: Received: { Ans: , MgmtId: 213737702773493, via: 5,
Ver: v1, Flags: 110, { MigrateWithStorageAnswer } }
2014-05-27 14:29:09,077 DEBUG [c.c.a.m.AgentAttache]
(DirectAgent-434:ctx-960ed94b) Seq 5-2135832123280457911: No more commands
found
2014-05-27 14:29:09,074 ERROR [o.a.c.s.m.HypervStorageMotionStrategy]
(Work-Job-Executor-5:ctx-083e8c2f job-45/job-46 ctx-966940f6) Migration with
storage of vm VM[User|i-2-7-VM] failed. Details:
com.cloud.agent.api.MigrateWithStorageCommand failed due to Hyper-V Job
failed, Error Code:32784, Description: Virtual machine migration operation
for 'i-2-7-VM' failed at migration destination 'HYPERV20.blr.cloudstack.org'.
(Virtual machine ID FF9CAE31-3CD1-4F19-886B-8FBE58E669F7)
The virtual machine 'i-2-7-VM' is not compatible with physical computer
'HYPERV20'. (Virtual machine ID
[jira] [Resolved] (CLOUDSTACK-6143) Storage Live-Migration support for Hyper-V
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-6143. Resolution: Fixed Storage Live-Migration support for Hyper-V -- Key: CLOUDSTACK-6143 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6143 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Devdeep Singh Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6106) Support of VPC in HyperV
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-6106. Resolution: Fixed Support of VPC in HyperV Key: CLOUDSTACK-6106 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6106 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6572) [Hyper-V] Deploy VM inside VPC tier fails due to VR unable to find nic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13992529#comment-13992529 ] Rajesh Battala commented on CLOUDSTACK-6572: Daan, I have made a patch to resolve ^M characters due to windows. https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=648a724dfc49222873124089464ccda92278fa9f I have sent mail to you about it. Please do the needful. [Hyper-V] Deploy VM inside VPC tier fails due to VR unable to find nic -- Key: CLOUDSTACK-6572 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6572 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Network Controller Affects Versions: 4.4.0 Environment: 4.4, Hyper-V Advanced zone, VPC Reporter: Sowmya Krishnan Assignee: Rajesh Battala Priority: Blocker Fix For: 4.4.0 Create a VPC offering with all services provided by VPCVR Create a VPC using this offering Configure a tier in the VPC with all services enabled including LB Launch a VM in the tier Fails to deploy VM since VR is unable to find a nic. VR has allocated all 8 nics but only eth0 has acquired private IP Here's ifconfig output of VR: eth0 Link encap:Ethernet HWaddr 02:00:02:2d:00:01 inet addr:10.102.195.179 Bcast:10.102.195.255 Mask:255.255.252.0 inet6 addr: fe80::2ff:fe2d:1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:25785 errors:0 dropped:0 overruns:0 frame:0 TX packets:431 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2160968 (2.0 MiB) TX bytes:79183 (77.3 KiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:214 (214.0 B) TX bytes:214 (214.0 B) mysql select * from domain_router where id = 3\G id: 3 element_id: 2 public_mac_address: 06:4b:c6:00:00:0e public_ip_address: 10.102.196.237 public_netmask: 255.255.255.0 guest_netmask: NULL guest_ip_address: NULL is_redundant_router: 0 priority: 0 is_priority_bumpup: 0 redundant_state: UNKNOWN stop_pending: 0 role: VIRTUAL_ROUTER template_version: Cloudstack Release 4.4.0 Fri Apr 11 18:25:32 UTC 2014 scripts_version: 16486954f5bda9ef9254913c0d692bd0 vpc_id: 1 1 row in set (0.00 sec) mysql select * from nics where vm_type = 'DomainRouter'; | id | uuid | instance_id | mac_address | ip4_address| netmask | gateway | ip_type | broadcast_uri | network_id | mode | state| strategy | reserver_name| reservation_id | device_id | update_time | isolation_uri | ip6_address | default_nic | vm_type | created | removed | ip6_gateway | ip6_cidr | secondary_ip | display_nic | ++--+-+---++-+--+-+---+++--+--+--+--+---+-+---+-+-+--+-+-+-+--+--+-+ | 8 | a218f142-213f-4dff-9b43-7d9c2b577ea4 | 3 | 02:00:02:2d:00:01 | 10.102.195.179 | 255.255.252.0 | 10.102.192.1 | Ip4 | NULL | 202 | Static | Reserved | Start| ControlNetworkGuru | 09a63fe0-a914-4a76-ab47-54558b82d900 | 0 | 2014-05-05 09:14:39 | NULL | NULL| 0 | DomainRouter | 2014-05-05 03:44:39 | NULL| NULL| NULL |0 | 1 | | 9 | 79883821-1efe-4a52-9af9-1f4a8413ed8f | 3 | 06:4b:c6:00:00:0e | 10.102.196.237 | 255.255.255.0 | 10.102.196.1 | NULL| vlan://100| 200 | Static | Reserved | Managed | PublicNetworkGuru| NULL | 1 | 2014-05-05 09:14:39 | vlan://100 | NULL| 1 | DomainRouter | 2014-05-05 03:44:39 | NULL | NULL| NULL |0 | 1 | | 11 | fd7db89a-f5a8-4653-aab8-c7c2621546bf | 3 | 02:00:6c:8a:00:02 | 10.10.1.1 |
[jira] [Resolved] (CLOUDSTACK-6528) SetupGuestNetwork command is not deleting the guest network configured on the eth device
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala resolved CLOUDSTACK-6528. Resolution: Fixed SetupGuestNetwork command is not deleting the guest network configured on the eth device Key: CLOUDSTACK-6528 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6528 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6572) [Hyper-V] Deploy VM inside VPC tier fails due to VR unable to find nic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13991610#comment-13991610 ] Rajesh Battala commented on CLOUDSTACK-6572: this commit will fix the issue. Commit cf41ccaa5b6475dace0bddbe6681c98cc5149189 in cloudstack's branch refs/heads/4.4-forward from Rajesh Battala [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cf41cca ] CLOUDSTACK-6518 [Hyper-V] Efficient way of finding the empty nic in VR/VpcVR to configure VPC entities [Hyper-V] Deploy VM inside VPC tier fails due to VR unable to find nic -- Key: CLOUDSTACK-6572 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6572 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Network Controller Affects Versions: 4.4.0 Environment: 4.4, Hyper-V Advanced zone, VPC Reporter: Sowmya Krishnan Priority: Blocker Fix For: 4.4.0 Create a VPC offering with all services provided by VPCVR Create a VPC using this offering Configure a tier in the VPC with all services enabled including LB Launch a VM in the tier Fails to deploy VM since VR is unable to find a nic. VR has allocated all 8 nics but only eth0 has acquired private IP Here's ifconfig output of VR: eth0 Link encap:Ethernet HWaddr 02:00:02:2d:00:01 inet addr:10.102.195.179 Bcast:10.102.195.255 Mask:255.255.252.0 inet6 addr: fe80::2ff:fe2d:1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:25785 errors:0 dropped:0 overruns:0 frame:0 TX packets:431 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2160968 (2.0 MiB) TX bytes:79183 (77.3 KiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:214 (214.0 B) TX bytes:214 (214.0 B) mysql select * from domain_router where id = 3\G id: 3 element_id: 2 public_mac_address: 06:4b:c6:00:00:0e public_ip_address: 10.102.196.237 public_netmask: 255.255.255.0 guest_netmask: NULL guest_ip_address: NULL is_redundant_router: 0 priority: 0 is_priority_bumpup: 0 redundant_state: UNKNOWN stop_pending: 0 role: VIRTUAL_ROUTER template_version: Cloudstack Release 4.4.0 Fri Apr 11 18:25:32 UTC 2014 scripts_version: 16486954f5bda9ef9254913c0d692bd0 vpc_id: 1 1 row in set (0.00 sec) mysql select * from nics where vm_type = 'DomainRouter'; | id | uuid | instance_id | mac_address | ip4_address| netmask | gateway | ip_type | broadcast_uri | network_id | mode | state| strategy | reserver_name| reservation_id | device_id | update_time | isolation_uri | ip6_address | default_nic | vm_type | created | removed | ip6_gateway | ip6_cidr | secondary_ip | display_nic | ++--+-+---++-+--+-+---+++--+--+--+--+---+-+---+-+-+--+-+-+-+--+--+-+ | 8 | a218f142-213f-4dff-9b43-7d9c2b577ea4 | 3 | 02:00:02:2d:00:01 | 10.102.195.179 | 255.255.252.0 | 10.102.192.1 | Ip4 | NULL | 202 | Static | Reserved | Start| ControlNetworkGuru | 09a63fe0-a914-4a76-ab47-54558b82d900 | 0 | 2014-05-05 09:14:39 | NULL | NULL| 0 | DomainRouter | 2014-05-05 03:44:39 | NULL| NULL| NULL |0 | 1 | | 9 | 79883821-1efe-4a52-9af9-1f4a8413ed8f | 3 | 06:4b:c6:00:00:0e | 10.102.196.237 | 255.255.255.0 | 10.102.196.1 | NULL| vlan://100| 200 | Static | Reserved | Managed | PublicNetworkGuru| NULL | 1 | 2014-05-05 09:14:39 | vlan://100 | NULL| 1 | DomainRouter | 2014-05-05 03:44:39 | NULL | NULL| NULL |0 | 1 | | 11 | fd7db89a-f5a8-4653-aab8-c7c2621546bf |
[jira] [Commented] (CLOUDSTACK-6295) Management server cannot start because Java 7 missing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13990650#comment-13990650 ] Rajesh Battala commented on CLOUDSTACK-6295: it should get fixed with this commit https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=16342f8 Am closing it, if you are able to face the same issue. feel free to open it. Management server cannot start because Java 7 missing - Key: CLOUDSTACK-6295 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6295 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Install and Setup Affects Versions: 4.4.0 Environment: centos 6.5 Reporter: Paul Angus Priority: Blocker Management server cannot start because java 7 is not installed. Java 7 package dependency needs to be added into installation. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6528) SetupGuestNetwork command is not deleting the guest network configured on the eth device
Rajesh Battala created CLOUDSTACK-6528: -- Summary: SetupGuestNetwork command is not deleting the guest network configured on the eth device Key: CLOUDSTACK-6528 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6528 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6521) [Hyper-V] fix generating of Hyper-v template in jenkins
Rajesh Battala created CLOUDSTACK-6521: -- Summary: [Hyper-V] fix generating of Hyper-v template in jenkins Key: CLOUDSTACK-6521 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6521 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.4.0 Reporter: Rajesh Battala Assignee: Rajesh Battala Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-4475) [ZWPS] attaching an uploaded volume to a VM is always going to first primary storage added
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-4475: --- Priority: Major (was: Critical) [ZWPS] attaching an uploaded volume to a VM is always going to first primary storage added -- Key: CLOUDSTACK-4475 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4475 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc, Storage Controller Affects Versions: 4.2.1 Environment: vmware esxi 5.1 Reporter: Srikanteswararao Talluri Labels: ReleaseNote Fix For: 4.4.0 Steps to reproduce: == 1. Have an advanced zone deployment with two cluster one host and one cluster scoped primary storage each 2. add two more zone wide primary storages 3. create a deployment on zone scoped primary storage 4. upload a volume. 5. attach uploaded volume to VM created in step 3. Observation: = While attaching volume, volume is always copied to first available primary storage in the storage_pool table and as a result attaching a volume created on cluster scoped primary storage to a VM with its root volume on zone wide primary storage fails. mysql select * from storage_pool; ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ | id | name | uuid | pool_type | port | data_center_id | pod_id | cluster_id | used_bytes| capacity_bytes | host_address | user_info | path | created | removed | update_time | status | storage_provider_name | scope | hypervisor | managed | capacity_iops | ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ | 1 | primaryclus1 | 722e6181-8497-3d31-9933-a0a267ae376c | NetworkFilesystem | 2049 | 1 | 1 | 1 | 1678552014848 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/primary | 2013-08-23 12:11:12 | NULL | NULL| Maintenance | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 2 | pimaryclu2 | 9fd9b0fc-c9fd-39b8-8d66-06372c5ff6d2 | NetworkFilesystem | 2049 | 1 | 1 | 2 | 1676566495232 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus1primary | 2013-08-23 12:18:14 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 3 | clus1p2 | 22e0c3fe-a390-38fa-8ff7-e1d965a36309 | NetworkFilesystem | 2049 | 1 | 1 | 1 | 1660903886848 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus1p2 | 2013-08-23 14:30:32 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 4 | clus1p3 | f2d9fb6b-c433-3c03-acf8-8f73eac48fae | NetworkFilesystem | 2049 | 1 | 1 | 1 | 1660901400576 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus1p3 | 2013-08-23 14:31:05 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 5 | clus2p2 | 13bf579c-51f3-317b-893a-98ff6ca8f486 | NetworkFilesystem | 2049 | 1 | 1 | 2 | 1660900147200 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus2p2 | 2013-08-23 14:31:38 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 7 | clus2p3 | 294ae9ff-cb02-33a0-8f31-21fdd8ff34db | NetworkFilesystem | 2049 | 1 | 1 | 2 | 1660894195712 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus2p3 | 2013-08-23 14:33:03 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 8 | z1 |
[jira] [Updated] (CLOUDSTACK-4475) [ZWPS] attaching an uploaded volume to a VM is always going to first primary storage added
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-4475: --- Priority: Critical (was: Major) [ZWPS] attaching an uploaded volume to a VM is always going to first primary storage added -- Key: CLOUDSTACK-4475 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4475 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Doc, Storage Controller Affects Versions: 4.2.1 Environment: vmware esxi 5.1 Reporter: Srikanteswararao Talluri Priority: Critical Labels: ReleaseNote Fix For: 4.4.0 Steps to reproduce: == 1. Have an advanced zone deployment with two cluster one host and one cluster scoped primary storage each 2. add two more zone wide primary storages 3. create a deployment on zone scoped primary storage 4. upload a volume. 5. attach uploaded volume to VM created in step 3. Observation: = While attaching volume, volume is always copied to first available primary storage in the storage_pool table and as a result attaching a volume created on cluster scoped primary storage to a VM with its root volume on zone wide primary storage fails. mysql select * from storage_pool; ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ | id | name | uuid | pool_type | port | data_center_id | pod_id | cluster_id | used_bytes| capacity_bytes | host_address | user_info | path | created | removed | update_time | status | storage_provider_name | scope | hypervisor | managed | capacity_iops | ++--+--+---+--++++---++--+---++-+-+-+-+---+-++-+---+ | 1 | primaryclus1 | 722e6181-8497-3d31-9933-a0a267ae376c | NetworkFilesystem | 2049 | 1 | 1 | 1 | 1678552014848 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/primary | 2013-08-23 12:11:12 | NULL | NULL| Maintenance | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 2 | pimaryclu2 | 9fd9b0fc-c9fd-39b8-8d66-06372c5ff6d2 | NetworkFilesystem | 2049 | 1 | 1 | 2 | 1676566495232 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus1primary | 2013-08-23 12:18:14 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 3 | clus1p2 | 22e0c3fe-a390-38fa-8ff7-e1d965a36309 | NetworkFilesystem | 2049 | 1 | 1 | 1 | 1660903886848 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus1p2 | 2013-08-23 14:30:32 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 4 | clus1p3 | f2d9fb6b-c433-3c03-acf8-8f73eac48fae | NetworkFilesystem | 2049 | 1 | 1 | 1 | 1660901400576 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus1p3 | 2013-08-23 14:31:05 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 5 | clus2p2 | 13bf579c-51f3-317b-893a-98ff6ca8f486 | NetworkFilesystem | 2049 | 1 | 1 | 2 | 1660900147200 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus2p2 | 2013-08-23 14:31:38 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 7 | clus2p3 | 294ae9ff-cb02-33a0-8f31-21fdd8ff34db | NetworkFilesystem | 2049 | 1 | 1 | 2 | 1660894195712 | 590228480 | 10.147.28.7 | NULL | /export/home/talluri/vmware.campo/clus2p3 | 2013-08-23 14:33:03 | NULL | NULL| Up | DefaultPrimary| CLUSTER | NULL | 0 | NULL | | 8 | z1
