[jira] [Commented] (CLOUDSTACK-6001) [Hyper-v] can't get console access after vm live migration for 3 minutes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893155#comment-13893155 ] ASF subversion and git services commented on CLOUDSTACK-6001: - Commit fb87c85b2a313d75af7cd4b790118fea30a2dd1b in branch refs/heads/4.3-forward from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fb87c85 ] CLOUDSTACK-6001: Fixed hyperv vm console not working for 3 minutes after migration. [Hyper-v] can't get console access after vm live migration for 3 minutes Key: CLOUDSTACK-6001 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6001 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.3.0 Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.3.0 [Hyper-v] can't get console access after vm live migration for 3 minutes -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-6001) [Hyper-v] can't get console access after vm live migration for 3 minutes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshul Gangwar resolved CLOUDSTACK-6001. Resolution: Fixed [Hyper-v] can't get console access after vm live migration for 3 minutes Key: CLOUDSTACK-6001 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6001 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.3.0 Reporter: Anshul Gangwar Assignee: Anshul Gangwar Priority: Critical Fix For: 4.3.0 [Hyper-v] can't get console access after vm live migration for 3 minutes -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-5904) Small UI bug
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Hitchins reassigned CLOUDSTACK-5904: - Assignee: Alex Hitchins Small UI bug Key: CLOUDSTACK-5904 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5904 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Environment: Firefox ESR 24.2.0 (the stock browser from RHEL/CentOS 6.5) Reporter: Nux Assignee: Alex Hitchins Priority: Trivial Labels: UI Please see the linked image, the isolation method dropdown is almost covered by other elements. http://img.nux.ro/4vCx-newacsuibug.png -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-5874) Cannot delete events for deleted accounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Hitchins reassigned CLOUDSTACK-5874: - Assignee: Alex Hitchins Cannot delete events for deleted accounts - Key: CLOUDSTACK-5874 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5874 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.1 Reporter: Francois Gaudreault Assignee: Alex Hitchins Priority: Minor If there are events for a deleted account, you cannot remove them. I see this error in the logs : 530 Unable to delete Events, one or more parameters has invalid values To reproduce: - Create an account - Generate an event using this account - Delete the account - Try to delete the event. It will fail with 530 Unable to delete Events, one or more parameters has invalid values When you delete an account, it should either ask if you want to delete/archive events or just allow deleting the events regardless. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-5524) [UI]root disk size field should be removed from the add instance wizard since this feature is not implemented
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Hitchins reassigned CLOUDSTACK-5524: - Assignee: Alex Hitchins [UI]root disk size field should be removed from the add instance wizard since this feature is not implemented --- Key: CLOUDSTACK-5524 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5524 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: prashant kumar mishra Assignee: Alex Hitchins Priority: Minor Fix For: 4.3.0 Attachments: screenshot-1.jpg please check screenshot -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-5450) Data values cleared when navigating back through add zone wizard
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Hitchins reassigned CLOUDSTACK-5450: - Assignee: Alex Hitchins Data values cleared when navigating back through add zone wizard Key: CLOUDSTACK-5450 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5450 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: Brian Federle Assignee: Alex Hitchins Priority: Minor Fix For: Future When adding an advanced zone using the add zone wizard, navigating back to the beginning of the wizard and then stepping forward again resulted in the guest VLAN range and the primary storage server address being cleared necessitating the values to be reentered. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-5953) In hypervisor_capabilities, max_guests_limit are not correct for XS 6.2 or other specific version hypervisor
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893305#comment-13893305 ] ASF subversion and git services commented on CLOUDSTACK-5953: - Commit bba6b77177a6404f1d27f7adc278b46fe00759f0 in branch refs/heads/4.3-forward from [~sanjay.tripathi] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bba6b77 ] CLOUDSTACK-5953: In hypervisor_capabilities, max_guests_limit are not correct for XS 6.2 or other specific version hypervisor. In hypervisor_capabilities, max_guests_limit are not correct for XS 6.2 or other specific version hypervisor Key: CLOUDSTACK-5953 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5953 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.2.1 Reporter: Sanjay Tripathi Assignee: Sanjay Tripathi In hypervisor_capabilities table, for XS6.1 XS6.2, maxGuestVMs are set to 50 which is not correct. For XS6.1 the max no. of supported guest VMs are 150 and for XS6.2, the value is 500. Configuration limits for XS 6.1 and XS6.2: http://support.citrix.com/servlet/KbServlet/download/32312-102-692726/CTX134789%20-%20XenServer%206.1.0_Configuration%20Limits.pdf http://support.citrix.com/servlet/KbServlet/download/34966-102-704363/CTX137837_XenServer%206_2_0_Configuration%20Limits.pdf -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-6040) Failed to configure PF on vm secondary ip for shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy reassigned CLOUDSTACK-6040: - Assignee: Jayapal Reddy Failed to configure PF on vm secondary ip for shared network Key: CLOUDSTACK-6040 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6040 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Jayapal Reddy Assignee: Jayapal Reddy Configuring PF on vm secondary ip failed for shared network with ip range 192.168.x.x -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6040) Failed to configure PF on vm secondary ip for shared network
Jayapal Reddy created CLOUDSTACK-6040: - Summary: Failed to configure PF on vm secondary ip for shared network Key: CLOUDSTACK-6040 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6040 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Jayapal Reddy Configuring PF on vm secondary ip failed for shared network with ip range 192.168.x.x -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6040) Failed to configure PF on vm secondary ip for shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893317#comment-13893317 ] ASF subversion and git services commented on CLOUDSTACK-6040: - Commit 7a71cf33ce103392914ac51cd4689a6f5a340d0a in branch refs/heads/4.3-forward from [~jayapal] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7a71cf3 ] CLOUDSTACK-6040: Updated the ip addr validation in create port forwarding Failed to configure PF on vm secondary ip for shared network Key: CLOUDSTACK-6040 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6040 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Jayapal Reddy Assignee: Jayapal Reddy Priority: Critical Configuring PF on vm secondary ip failed for shared network with ip range 192.168.x.x -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6040) Failed to configure PF on vm secondary ip for shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy updated CLOUDSTACK-6040: -- Priority: Critical (was: Major) Failed to configure PF on vm secondary ip for shared network Key: CLOUDSTACK-6040 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6040 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Jayapal Reddy Assignee: Jayapal Reddy Priority: Critical Configuring PF on vm secondary ip failed for shared network with ip range 192.168.x.x -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6041) [Automation] Port forwarding rule for secondary IP (ranges - 172.16.x.x and 192.168.x.x) in Shared Network fails with Invalid vm ip address
Gaurav Aradhye created CLOUDSTACK-6041: -- Summary: [Automation] Port forwarding rule for secondary IP (ranges - 172.16.x.x and 192.168.x.x) in Shared Network fails with Invalid vm ip address Key: CLOUDSTACK-6041 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6041 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.4.0 Environment: Observed on VMware. Not yet verified on Xen and KVM. Reporter: Gaurav Aradhye Fix For: 4.4.0 This works for 10.x.x.x Steps to reproduce: 1) Create a shared network (PF enabled) with range in 172.16.x.x or 192.168.x.x 2) Deploy a VM in this and add secondary IP to the default NIC of VM 3) Acquire a public IP in the shared network and try to create a NAT rule using this public ip to the secondary IP of VM Operation fails. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6041) [Automation] Creating port forwarding rule for secondary IP (ranges - 172.16.x.x and 192.168.x.x) in Shared Network fails with Invalid vm ip address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-6041: --- Summary: [Automation] Creating port forwarding rule for secondary IP (ranges - 172.16.x.x and 192.168.x.x) in Shared Network fails with Invalid vm ip address (was: [Automation] Port forwarding rule for secondary IP (ranges - 172.16.x.x and 192.168.x.x) in Shared Network fails with Invalid vm ip address) [Automation] Creating port forwarding rule for secondary IP (ranges - 172.16.x.x and 192.168.x.x) in Shared Network fails with Invalid vm ip address -- Key: CLOUDSTACK-6041 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6041 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.4.0 Environment: Observed on VMware. Not yet verified on Xen and KVM. Reporter: Gaurav Aradhye Labels: automation Fix For: 4.4.0 This works for 10.x.x.x Steps to reproduce: 1) Create a shared network (PF enabled) with range in 172.16.x.x or 192.168.x.x 2) Deploy a VM in this and add secondary IP to the default NIC of VM 3) Acquire a public IP in the shared network and try to create a NAT rule using this public ip to the secondary IP of VM Operation fails. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6040) Failed to configure PF on vm secondary ip for shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy updated CLOUDSTACK-6040: -- Affects Version/s: (was: 4.3.0) 4.2.1 Failed to configure PF on vm secondary ip for shared network Key: CLOUDSTACK-6040 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6040 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.1 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Priority: Critical Fix For: 4.3.0 Configuring PF on vm secondary ip failed for shared network with ip range 192.168.x.x -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6040) Failed to configure PF on vm secondary ip for shared network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy updated CLOUDSTACK-6040: -- Fix Version/s: 4.3.0 Failed to configure PF on vm secondary ip for shared network Key: CLOUDSTACK-6040 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6040 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.2.1 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Priority: Critical Fix For: 4.3.0 Configuring PF on vm secondary ip failed for shared network with ip range 192.168.x.x -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-6041) [Automation] Creating port forwarding rule for secondary IP (ranges - 172.16.x.x and 192.168.x.x) in Shared Network fails with Invalid vm ip address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy resolved CLOUDSTACK-6041. --- Resolution: Duplicate [Automation] Creating port forwarding rule for secondary IP (ranges - 172.16.x.x and 192.168.x.x) in Shared Network fails with Invalid vm ip address -- Key: CLOUDSTACK-6041 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6041 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.4.0 Environment: Observed on VMware. Not yet verified on Xen and KVM. Reporter: Gaurav Aradhye Labels: automation Fix For: 4.4.0 This works for 10.x.x.x Steps to reproduce: 1) Create a shared network (PF enabled) with range in 172.16.x.x or 192.168.x.x 2) Deploy a VM in this and add secondary IP to the default NIC of VM 3) Acquire a public IP in the shared network and try to create a NAT rule using this public ip to the secondary IP of VM Operation fails. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-2692) [MIPN][Enhancement] Add load balancing support for MIPN
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893335#comment-13893335 ] Jayapal Reddy commented on CLOUDSTACK-2692: --- https://cwiki.apache.org/confluence/display/CLOUDSTACK/Configuring+load+balancing+rules+for+VM+nic+secondary+ips [MIPN][Enhancement] Add load balancing support for MIPN --- Key: CLOUDSTACK-2692 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2692 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.1.0, 4.2.0 Reporter: Jayapal Reddy Assignee: Jayapal Reddy Fix For: Future Add support of Load balancing for MIPN feature -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6042) automation:need to modify the scripts to handle new default built-in Template(deployvm script is failing)
sadhu suresh created CLOUDSTACK-6042: Summary: automation:need to modify the scripts to handle new default built-in Template(deployvm script is failing) Key: CLOUDSTACK-6042 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6042 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.3.0 Reporter: sadhu suresh Assignee: sadhu suresh Priority: Minor right now in the test scripts default built-in template is pointing to centos5.3 but in 4.3 default template is centos 5.6 for xen. due to this scripts(ex:deployvm )are failing with unable to find the default template centos-5.3 select * from vm_template where id in (2,5)\G; 1. row *** id: 2 unique_name: centos53-x86_64 name: CentOS 5.3(64-bit) no GUI (XenServer) uuid: d0c8c942-883d-11e3-9f41-06a8f47f public: 1 featured: 1 type: BUILTIN hvm: 0 bits: 64 url: http://download.cloud.com/templates/builtin/f59f18fb-ae94-4f97-afd2-f84755767aca.vhd.bz2 format: VHD created: 2014-01-28 22:31:22 removed: NULL account_id: 1 checksum: b63d854a9560c013142567bbae8d98cf display_text: CentOS 5.3(64-bit) no GUI (XenServer) enable_password: 0 enable_sshkey: 0 guest_os_id: 12 bootable: 1 prepopulate: 0 cross_zones: 1 extractable: 1 hypervisor_type: XenServer source_template_id: NULL template_tag: NULL sort_key: 0 size: 8589934592 state: Inactive update_count: 0
[jira] [Commented] (CLOUDSTACK-4992) Domain/Account/User Sync Up Among Multiple Regions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893382#comment-13893382 ] Alex Ough commented on CLOUDSTACK-4992: --- Review requested. https://reviews.apache.org/r/17790/ Domain/Account/User Sync Up Among Multiple Regions -- Key: CLOUDSTACK-4992 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4992 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: Future Reporter: Alex Ough Assignee: Alex Ough Labels: features Fix For: Future Currently, under the environment of cloudstack with multiple regions, each region has its own management server running with a separate database. So if we want to support multiple regions and provide one point of entry for a customer, we need to duplicate domain/account/user information of that customer to all of the databases of regions the customer accesses, which will cause data discrepancies when users update those data independently in each management server. So I'd like to provide a way to sync up the data using the messaging system introduced in 4.1.0. Using the events from each management server, updates from each region can be propagated to the rest regions and they can be executed accordingly. Discussion http://markmail.org/thread/k4x63ef55chcj4y5 Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain-Account-User+Sync+Up+Among+Multiple+Regions The implementation https://github.com/alexoughsg/Albatross/tree/albatross -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6043) VMware detaching volume fails if volume has snapshots
Chris Suich created CLOUDSTACK-6043: --- Summary: VMware detaching volume fails if volume has snapshots Key: CLOUDSTACK-6043 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6043 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VMware, Volumes Affects Versions: 4.3.0 Reporter: Chris Suich Assignee: Kelven Yang Fix For: 4.3.0 When detaching VMware volumes, a call is first made to the hypervisor to remove all snapshots for that volume. After this happens, the path for the volume potentially changes, but isn't updated in the ACS DB, which causes problems when the call is made to actually detach the volume. For example, if the volume has a single snapshot, then the current path would be something like VOLUME-1.vmdk which is a delta disk for VOLUME.vmdk. Once the snapshot is deleted, VOLUME-1.vmdk is coalesced into VOLUME.vmdk, which becomes the active path. However, ACS still believes the correct path is VOLUME-1.vmdk which causes the detach to fail. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6044) Long fields in list views cause the table to look weird.
Chris Suich created CLOUDSTACK-6044: --- Summary: Long fields in list views cause the table to look weird. Key: CLOUDSTACK-6044 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6044 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Chris Suich Priority: Minor See attached screenshot. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6044) Long fields in list views cause the table to look weird.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Suich updated CLOUDSTACK-6044: Attachment: Screen Shot 2014-02-05 at 3.51.59 PM.png Long fields in list views cause the table to look weird. Key: CLOUDSTACK-6044 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6044 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Chris Suich Priority: Minor Labels: ui Attachments: Screen Shot 2014-02-05 at 3.51.59 PM.png See attached screenshot. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-6044) Long fields in list views cause the table to look weird.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle resolved CLOUDSTACK-6044. --- Resolution: Fixed Long fields in list views cause the table to look weird. Key: CLOUDSTACK-6044 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6044 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Chris Suich Assignee: Brian Federle Priority: Minor Labels: ui Attachments: Screen Shot 2014-02-05 at 3.51.59 PM.png See attached screenshot. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-6044) Long fields in list views cause the table to look weird.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle reassigned CLOUDSTACK-6044: - Assignee: Brian Federle Long fields in list views cause the table to look weird. Key: CLOUDSTACK-6044 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6044 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Chris Suich Assignee: Brian Federle Priority: Minor Labels: ui Attachments: Screen Shot 2014-02-05 at 3.51.59 PM.png See attached screenshot. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6044) Long fields in list views cause the table to look weird.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893581#comment-13893581 ] ASF subversion and git services commented on CLOUDSTACK-6044: - Commit 916728634b5d4af359269a41d655466fd628554b in branch refs/heads/master from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9167286 ] CLOUDSTACK-6044: Primary storage list: truncate long values Long fields in list views cause the table to look weird. Key: CLOUDSTACK-6044 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6044 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.3.0 Reporter: Chris Suich Priority: Minor Labels: ui Attachments: Screen Shot 2014-02-05 at 3.51.59 PM.png See attached screenshot. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6045) [GSoC] Create GUI to add primary storage based on plug-ins
Mike Tutkowski created CLOUDSTACK-6045: -- Summary: [GSoC] Create GUI to add primary storage based on plug-ins Key: CLOUDSTACK-6045 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6045 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.4.0 Environment: All browsers that CloudStack supports Reporter: Mike Tutkowski Fix For: 4.4.0 At the time being, if an admin wants to add primary storage to CloudStack that is NOT based on the default storage plug-in, the admin must invoke the addStoragePool API outside of the CloudStack GUI. It would be beneficial to CloudStack admins if they could add this kind of primary storage to CloudStack via its standard GUI. This project will require a degree of usability work in that the designer must analyze CloudStack's GUI sufficiently to come up with a plan for where the necessary information can be input. Once a GUI prototype has been developed (one could use a tool like PowerPoint for this purpose), then the developer must analyze the necessary HTML and JavaScript logic to add the proposed support. This project could take the form of an optional GUI plug-in. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-6045) [GSoC] Create GUI to add primary storage based on plug-ins
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Tutkowski updated CLOUDSTACK-6045: --- Description: At the time being, if an admin wants to add primary storage to CloudStack that is NOT based on the default storage plug-in, the admin must invoke the addStoragePool API outside of the CloudStack GUI. It would be beneficial to CloudStack admins if they could add this kind of primary storage to CloudStack via its standard GUI. This project will require a degree of usability work in that the designer must analyze CloudStack's GUI sufficiently to come up with a plan for where the necessary information can be input. Once a GUI prototype has been developed (one could use a tool like PowerPoint for this purpose), then the developer must analyze the necessary HTML and JavaScript logic to add the proposed support. This project could take the form of an optional GUI plug-in. It is possible this project may add one or more parameters to the addStoragePool API. If so, then this will require Java changes on the backend. was: At the time being, if an admin wants to add primary storage to CloudStack that is NOT based on the default storage plug-in, the admin must invoke the addStoragePool API outside of the CloudStack GUI. It would be beneficial to CloudStack admins if they could add this kind of primary storage to CloudStack via its standard GUI. This project will require a degree of usability work in that the designer must analyze CloudStack's GUI sufficiently to come up with a plan for where the necessary information can be input. Once a GUI prototype has been developed (one could use a tool like PowerPoint for this purpose), then the developer must analyze the necessary HTML and JavaScript logic to add the proposed support. This project could take the form of an optional GUI plug-in. [GSoC] Create GUI to add primary storage based on plug-ins -- Key: CLOUDSTACK-6045 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6045 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.4.0 Environment: All browsers that CloudStack supports Reporter: Mike Tutkowski Labels: gsoc Fix For: 4.4.0 At the time being, if an admin wants to add primary storage to CloudStack that is NOT based on the default storage plug-in, the admin must invoke the addStoragePool API outside of the CloudStack GUI. It would be beneficial to CloudStack admins if they could add this kind of primary storage to CloudStack via its standard GUI. This project will require a degree of usability work in that the designer must analyze CloudStack's GUI sufficiently to come up with a plan for where the necessary information can be input. Once a GUI prototype has been developed (one could use a tool like PowerPoint for this purpose), then the developer must analyze the necessary HTML and JavaScript logic to add the proposed support. This project could take the form of an optional GUI plug-in. It is possible this project may add one or more parameters to the addStoragePool API. If so, then this will require Java changes on the backend. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6015) Write Sellenium tests for the UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893815#comment-13893815 ] Rayees Namathponnan commented on CLOUDSTACK-6015: - https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=tree;f=test/selenium;h=a395204062849493e44ac26964165ed855aa39d8;hb=refs/heads/master https://cwiki.apache.org/confluence/display/CLOUDSTACK/UI+Automation+using+Selenium+and+Python Write Sellenium tests for the UI Key: CLOUDSTACK-6015 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6015 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.4.0 Reporter: sebastien goasguen Labels: gsoc2014 To increase tests coverage for CloudStack we need to write a test suite for the UI. Using Sellenium we can write these tests for multiple browsers and export everything in Python. http://docs.seleniumhq.org These will be used with the unittest and the integration tests to make CloudStack higher quality. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6015) Write Sellenium tests for the UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893853#comment-13893853 ] Yichi Lu commented on CLOUDSTACK-6015: -- I'll start working on this. Code will be checked in to test/selenium. I'll post my progress here. Write Sellenium tests for the UI Key: CLOUDSTACK-6015 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6015 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.4.0 Reporter: sebastien goasguen Labels: gsoc2014 To increase tests coverage for CloudStack we need to write a test suite for the UI. Using Sellenium we can write these tests for multiple browsers and export everything in Python. http://docs.seleniumhq.org These will be used with the unittest and the integration tests to make CloudStack higher quality. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6003) cloudstack api doesn't report unknown parameters
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893923#comment-13893923 ] ASF subversion and git services commented on CLOUDSTACK-6003: - Commit 782c53068564b96d11a09775d489a6e1b38adbd8 in branch refs/heads/master from [~alena1108] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=782c530 ] Revert CLOUDSTACK-6003 fixing plus refactoring dispatcher as it breaks API dispatching for commands having MapString,String as a parameter type This reverts commit 447430c3df38c36d947c44c4aebd961d8cbb14c4. Conflicts: api/src/org/apache/cloudstack/api/BaseCmd.java server/src/com/cloud/api/ApiDispatcher.java server/src/com/cloud/network/as/AutoScaleManagerImpl.java server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java cloudstack api doesn't report unknown parameters Key: CLOUDSTACK-6003 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6003 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Reporter: Antonio Fornie Assignee: Daan Hoogland Priority: Minor Labels: API Fix For: 4.4.0 Original Estimate: 48h Remaining Estimate: 48h When a CS API request requires or accepts parameters A, B and C, if the request includes also parameters X and Y, that should be detected and logged. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-5779) Consolidate all the VR commands execution to one resource
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang closed CLOUDSTACK-5779. -- Consolidate all the VR commands execution to one resource - Key: CLOUDSTACK-5779 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5779 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sheng Yang Assignee: Sheng Yang Priority: Critical Fix For: 4.4.0 Currently when anyone add one command to VR(which happened very frequently these days), they need to modify every hypervisor resources to accommodate the new command, which is really inconvenient as well as bug prone, since e.g. the parameters formation would be duplicate across the hypervisors. This improvement would make all VR commands to be executed by only one resource, and in the future, any new command/improvement or bug fixes to VR resource would only need to be done once in the VR resource. This would be done through: 1. Use routeProxy script for all VR commands, no more standalone script for each VR scripts in the host. All VR command scripts would be moved to /opt/cloud/bin for this purpose as well. 2. Every hypervisor would provide an executor to VR resource, to execute the command in giving hypervisor. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5779) Consolidate all the VR commands execution to one resource
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-5779. Resolution: Fixed Done. Now every hypervisor would use VirtualRoutingResources code to execute the VR commands. Consolidate all the VR commands execution to one resource - Key: CLOUDSTACK-5779 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5779 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Sheng Yang Assignee: Sheng Yang Priority: Critical Fix For: 4.4.0 Currently when anyone add one command to VR(which happened very frequently these days), they need to modify every hypervisor resources to accommodate the new command, which is really inconvenient as well as bug prone, since e.g. the parameters formation would be duplicate across the hypervisors. This improvement would make all VR commands to be executed by only one resource, and in the future, any new command/improvement or bug fixes to VR resource would only need to be done once in the VR resource. This would be done through: 1. Use routeProxy script for all VR commands, no more standalone script for each VR scripts in the host. All VR command scripts would be moved to /opt/cloud/bin for this purpose as well. 2. Every hypervisor would provide an executor to VR resource, to execute the command in giving hypervisor. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5575) Remote Access VPN and S2S VPN should be treated as two seperate services on VPC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-5575. Resolution: Duplicate Would be contained in CLOUDSTACK-5832. Remote Access VPN and S2S VPN should be treated as two seperate services on VPC --- Key: CLOUDSTACK-5575 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5575 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Chandan Purushothama Assignee: Sheng Yang Priority: Critical Fix For: 4.4.0 Currently we treat RemoteAccessVPN and S2S VPN Service as a single VPN Service on the VPC. A VPN Service Provider might not be in a position to support both services. We need to provide the two services in the VPN as two seperate capabilities of VPN Service -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-5577) Remote Access VPN and S2S VPN should be treated as two seperate services for Network Offering creation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-5577. Resolution: Duplicate Would be a part of CLOUDSTACK-5832 Remote Access VPN and S2S VPN should be treated as two seperate services for Network Offering creation -- Key: CLOUDSTACK-5577 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5577 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Chandan Purushothama Assignee: Sheng Yang Priority: Critical Fix For: 4.4.0 Currently we treat RemoteAccessVPN and S2S VPN Service as a single VPN Service on Create Network Offering UI box. A VPN Service Provider might not be in a position to support both services. We need to provide the two services in the VPN as two seperate capabilities of VPN Service -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6047) Make Virtual Router to aggregate execution of commands
Sheng Yang created CLOUDSTACK-6047: -- Summary: Make Virtual Router to aggregate execution of commands Key: CLOUDSTACK-6047 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6047 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller, Virtual Router Reporter: Sheng Yang Assignee: Sheng Yang Priority: Blocker Fix For: 4.4.0 Currently VR has an scalability issue during the large deployment. Everytime when VR need to be re-create or reboot, CloudStack would send lots of programming commands to it. VR would treat them as individual commands then execute them. In large deployment, it would take tens of minutes or even hours to complete all the necessary updates, like setup DHCP and programming firewall. For example, in the past, everytime we setup DHCP in VR, we need to restart dnsmasq service for every programming, which is very time consuming. Though we've introduced a way to reload without restart dnsmasq, but the same issue existed with apache2 and other services as well. And every SSH to VR would also time consuming. The new approach of reprogramming VR, would help greatly on this issue, and hopefully great reduce the VR programming time. It would introduce a mechanism to aggregate the commands to be executed, and do it in one batch inside VR. And restart the related services(if necesary) only after the whole batch is completed. The configuration would be transfer to VR in one piece as well, eliminate any unnecessary ssh. We would expect in such scenario, most configuration would only be text update and involve no more time consuming operations. We would leave every possible time consuming operation to the end of execution of aggregated commands. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6046) CreateVolume from snapshot is failing with S3 as secondary storage and zone-wide primary storage.
Min Chen created CLOUDSTACK-6046:
Summary: CreateVolume from snapshot is failing with S3 as
secondary storage and zone-wide primary storage.
Key: CLOUDSTACK-6046
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6046
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Storage Controller
Affects Versions: 4.2.1
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.3.0
1. Have CS with KVM HV, S3 as secondary storage, zone-wide primary storage.
2. Create a VM and create snapshot of root volume.
3. Now creatVolume from snapshot taken in stpe2.
Observation:
Observed the follwoing exception in MS logs and create volume from snapshot
failed:
2014-02-03 20:33:07,109 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-22:ctx-58f7b84e ctx-d6b53517) submit async job-96, details:
AsyncJobVO {id:96, userId: 2, accountId: 2, instanceType: Volume, instanceId:
21, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo:
{id:21,response:json,sessionkey:48nz1Dz96CYsK87tCQeRSeGmZ2E\u003d,cmdEventType:VOLUME.CREATE,ctxUserId:2,snapshotid:388aeb8c-b9ea-4117-9c20-a8453c546ccc,name:volsanp,httpmethod:GET,_:1391420610122,ctxAccountId:2,ctxStartEventId:203}
, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7494415941730, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-02-03 20:33:07,111 DEBUG [c.c.a.ApiServlet] (catalina-exec-22:ctx-58f7b84e
ctx-d6b53517) ===END=== 10.252.192.33 – GET
command=createVolumeresponse=jsonsessionkey=48nz1Dz96CYsK87tCQeRSeGmZ2E%3Dsnapshotid=388aeb8c-b9ea-4117-9c20-a8453c546cccname=volsanp_=1391420610122
2014-02-03 20:33:07,115 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-89:ctx-7e16453b) Add job-96 into job monitoring
2014-02-03 20:33:07,116 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-89:ctx-7e16453b) Executing AsyncJobVO {id:96, userId: 2,
accountId: 2, instanceType: Volume, instanceId: 21, cmd:
org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo:
{id:21,response:json,sessionkey:48nz1Dz96CYsK87tCQeRSeGmZ2E\u003d,cmdEventType:VOLUME.CREATE,ctxUserId:2,snapshotid:388aeb8c-b9ea-4117-9c20-a8453c546ccc,name:volsanp,httpmethod:GET,_:1391420610122,ctxAccountId:2,ctxStartEventId:203}
, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 7494415941730, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-02-03 20:33:07,156 DEBUG [o.a.c.s.a.LocalStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) LocalStoragePoolAllocator trying to
find storage pool to fit the vm
2014-02-03 20:33:07,156 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) ClusterScopeStoragePoolAllocator
looking for storage pool
2014-02-03 20:33:07,157 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Looking for pools in dc: 1 pod:1
cluster:null
2014-02-03 20:33:07,159 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Found pools matching tags: []
2014-02-03 20:33:07,161 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) No storage pools available for
shared volume allocation, returning
2014-02-03 20:33:07,161 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) ZoneWideStoragePoolAllocator to
find storage pool
2014-02-03 20:33:07,170 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Removing pool
Pool[1|NetworkFilesystem] from avoid set, must have been inserted when
searching for another disk's tag
2014-02-03 20:33:07,177 DEBUG [c.c.s.StorageManagerImpl]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Checking pool 1 for storage,
totalSize: 5902284816384, usedBytes: 3731833782272, usedPct:
0.6322693496445476, disable threshold: 0.85
2014-02-03 20:33:07,187 DEBUG [c.c.s.StorageManagerImpl]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Checking pool: 1 for volume
allocation [Vol[21|vm=null|DATADISK]], maxSize : 11804569632768,
totalAllocatedSize : 63747532288, askingSize : 8589934592, allocated disable
threshold: 0.85
2014-02-03 20:33:07,189 DEBUG [o.a.c.e.o.VolumeOrchestrator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Found a suitable pool for create
volume: 1
2014-02-03 20:33:07,197 DEBUG [o.a.c.s.s.SnapshotServiceImpl]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) sync snapshot 3 from cache to
object store...
2014-02-03 20:33:07,201 DEBUG [o.a.c.s.s.SnapshotServiceImpl]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) sync snapshot 5 from cache to
object store...
2014-02-03 20:33:07,204
[jira] [Commented] (CLOUDSTACK-6046) CreateVolume from snapshot is failing with S3 as secondary storage and zone-wide primary storage.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893976#comment-13893976
]
ASF subversion and git services commented on CLOUDSTACK-6046:
-
Commit 900c51103ab1e29b86ea5f76cb73c72b3de51db7 in branch
refs/heads/4.3-forward from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=900c511 ]
CLOUDSTACK-6046:CreateVolume from snapshot is failing with S3 as
secondary storage and zone-wide primary storage.
CreateVolume from snapshot is failing with S3 as secondary storage and
zone-wide primary storage.
-
Key: CLOUDSTACK-6046
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6046
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: 4.2.1
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.3.0
1. Have CS with KVM HV, S3 as secondary storage, zone-wide primary storage.
2. Create a VM and create snapshot of root volume.
3. Now creatVolume from snapshot taken in stpe2.
Observation:
Observed the follwoing exception in MS logs and create volume from snapshot
failed:
2014-02-03 20:33:07,109 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-22:ctx-58f7b84e ctx-d6b53517) submit async job-96, details:
AsyncJobVO {id:96, userId: 2, accountId: 2, instanceType: Volume, instanceId:
21, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd,
cmdInfo:
{id:21,response:json,sessionkey:48nz1Dz96CYsK87tCQeRSeGmZ2E\u003d,cmdEventType:VOLUME.CREATE,ctxUserId:2,snapshotid:388aeb8c-b9ea-4117-9c20-a8453c546ccc,name:volsanp,httpmethod:GET,_:1391420610122,ctxAccountId:2,ctxStartEventId:203}
, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
result: null, initMsid: 7494415941730, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-02-03 20:33:07,111 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-58f7b84e ctx-d6b53517) ===END=== 10.252.192.33 – GET
command=createVolumeresponse=jsonsessionkey=48nz1Dz96CYsK87tCQeRSeGmZ2E%3Dsnapshotid=388aeb8c-b9ea-4117-9c20-a8453c546cccname=volsanp_=1391420610122
2014-02-03 20:33:07,115 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-89:ctx-7e16453b) Add job-96 into job monitoring
2014-02-03 20:33:07,116 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-89:ctx-7e16453b) Executing AsyncJobVO {id:96, userId: 2,
accountId: 2, instanceType: Volume, instanceId: 21, cmd:
org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo:
{id:21,response:json,sessionkey:48nz1Dz96CYsK87tCQeRSeGmZ2E\u003d,cmdEventType:VOLUME.CREATE,ctxUserId:2,snapshotid:388aeb8c-b9ea-4117-9c20-a8453c546ccc,name:volsanp,httpmethod:GET,_:1391420610122,ctxAccountId:2,ctxStartEventId:203}
, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
result: null, initMsid: 7494415941730, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-02-03 20:33:07,156 DEBUG [o.a.c.s.a.LocalStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) LocalStoragePoolAllocator trying
to find storage pool to fit the vm
2014-02-03 20:33:07,156 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) ClusterScopeStoragePoolAllocator
looking for storage pool
2014-02-03 20:33:07,157 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Looking for pools in dc: 1 pod:1
cluster:null
2014-02-03 20:33:07,159 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Found pools matching tags: []
2014-02-03 20:33:07,161 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) No storage pools available for
shared volume allocation, returning
2014-02-03 20:33:07,161 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) ZoneWideStoragePoolAllocator to
find storage pool
2014-02-03 20:33:07,170 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Removing pool
Pool[1|NetworkFilesystem] from avoid set, must have been inserted when
searching for another disk's tag
2014-02-03 20:33:07,177 DEBUG [c.c.s.StorageManagerImpl]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Checking pool 1 for storage,
totalSize: 5902284816384, usedBytes: 3731833782272, usedPct:
0.6322693496445476, disable threshold: 0.85
2014-02-03 20:33:07,187 DEBUG [c.c.s.StorageManagerImpl]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Checking pool: 1 for
[jira] [Commented] (CLOUDSTACK-6046) CreateVolume from snapshot is failing with S3 as secondary storage and zone-wide primary storage.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13893994#comment-13893994
]
ASF subversion and git services commented on CLOUDSTACK-6046:
-
Commit 621276715afbe27c861bfa8ee4bf0a96bd202106 in branch refs/heads/master
from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6212767 ]
CLOUDSTACK-6046:CreateVolume from snapshot is failing with S3 as
secondary storage and zone-wide primary storage.
CreateVolume from snapshot is failing with S3 as secondary storage and
zone-wide primary storage.
-
Key: CLOUDSTACK-6046
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6046
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: 4.2.1
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.3.0
1. Have CS with KVM HV, S3 as secondary storage, zone-wide primary storage.
2. Create a VM and create snapshot of root volume.
3. Now creatVolume from snapshot taken in stpe2.
Observation:
Observed the follwoing exception in MS logs and create volume from snapshot
failed:
2014-02-03 20:33:07,109 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-22:ctx-58f7b84e ctx-d6b53517) submit async job-96, details:
AsyncJobVO {id:96, userId: 2, accountId: 2, instanceType: Volume, instanceId:
21, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd,
cmdInfo:
{id:21,response:json,sessionkey:48nz1Dz96CYsK87tCQeRSeGmZ2E\u003d,cmdEventType:VOLUME.CREATE,ctxUserId:2,snapshotid:388aeb8c-b9ea-4117-9c20-a8453c546ccc,name:volsanp,httpmethod:GET,_:1391420610122,ctxAccountId:2,ctxStartEventId:203}
, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
result: null, initMsid: 7494415941730, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-02-03 20:33:07,111 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-58f7b84e ctx-d6b53517) ===END=== 10.252.192.33 – GET
command=createVolumeresponse=jsonsessionkey=48nz1Dz96CYsK87tCQeRSeGmZ2E%3Dsnapshotid=388aeb8c-b9ea-4117-9c20-a8453c546cccname=volsanp_=1391420610122
2014-02-03 20:33:07,115 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-89:ctx-7e16453b) Add job-96 into job monitoring
2014-02-03 20:33:07,116 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-89:ctx-7e16453b) Executing AsyncJobVO {id:96, userId: 2,
accountId: 2, instanceType: Volume, instanceId: 21, cmd:
org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo:
{id:21,response:json,sessionkey:48nz1Dz96CYsK87tCQeRSeGmZ2E\u003d,cmdEventType:VOLUME.CREATE,ctxUserId:2,snapshotid:388aeb8c-b9ea-4117-9c20-a8453c546ccc,name:volsanp,httpmethod:GET,_:1391420610122,ctxAccountId:2,ctxStartEventId:203}
, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
result: null, initMsid: 7494415941730, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-02-03 20:33:07,156 DEBUG [o.a.c.s.a.LocalStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) LocalStoragePoolAllocator trying
to find storage pool to fit the vm
2014-02-03 20:33:07,156 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) ClusterScopeStoragePoolAllocator
looking for storage pool
2014-02-03 20:33:07,157 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Looking for pools in dc: 1 pod:1
cluster:null
2014-02-03 20:33:07,159 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Found pools matching tags: []
2014-02-03 20:33:07,161 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) No storage pools available for
shared volume allocation, returning
2014-02-03 20:33:07,161 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) ZoneWideStoragePoolAllocator to
find storage pool
2014-02-03 20:33:07,170 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Removing pool
Pool[1|NetworkFilesystem] from avoid set, must have been inserted when
searching for another disk's tag
2014-02-03 20:33:07,177 DEBUG [c.c.s.StorageManagerImpl]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Checking pool 1 for storage,
totalSize: 5902284816384, usedBytes: 3731833782272, usedPct:
0.6322693496445476, disable threshold: 0.85
2014-02-03 20:33:07,187 DEBUG [c.c.s.StorageManagerImpl]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Checking pool: 1 for
[jira] [Resolved] (CLOUDSTACK-6046) CreateVolume from snapshot is failing with S3 as secondary storage and zone-wide primary storage.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-6046.
--
Resolution: Fixed
CreateVolume from snapshot is failing with S3 as secondary storage and
zone-wide primary storage.
-
Key: CLOUDSTACK-6046
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6046
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Storage Controller
Affects Versions: 4.2.1
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.3.0
1. Have CS with KVM HV, S3 as secondary storage, zone-wide primary storage.
2. Create a VM and create snapshot of root volume.
3. Now creatVolume from snapshot taken in stpe2.
Observation:
Observed the follwoing exception in MS logs and create volume from snapshot
failed:
2014-02-03 20:33:07,109 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-22:ctx-58f7b84e ctx-d6b53517) submit async job-96, details:
AsyncJobVO {id:96, userId: 2, accountId: 2, instanceType: Volume, instanceId:
21, cmd: org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd,
cmdInfo:
{id:21,response:json,sessionkey:48nz1Dz96CYsK87tCQeRSeGmZ2E\u003d,cmdEventType:VOLUME.CREATE,ctxUserId:2,snapshotid:388aeb8c-b9ea-4117-9c20-a8453c546ccc,name:volsanp,httpmethod:GET,_:1391420610122,ctxAccountId:2,ctxStartEventId:203}
, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
result: null, initMsid: 7494415941730, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-02-03 20:33:07,111 DEBUG [c.c.a.ApiServlet]
(catalina-exec-22:ctx-58f7b84e ctx-d6b53517) ===END=== 10.252.192.33 – GET
command=createVolumeresponse=jsonsessionkey=48nz1Dz96CYsK87tCQeRSeGmZ2E%3Dsnapshotid=388aeb8c-b9ea-4117-9c20-a8453c546cccname=volsanp_=1391420610122
2014-02-03 20:33:07,115 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-89:ctx-7e16453b) Add job-96 into job monitoring
2014-02-03 20:33:07,116 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-89:ctx-7e16453b) Executing AsyncJobVO {id:96, userId: 2,
accountId: 2, instanceType: Volume, instanceId: 21, cmd:
org.apache.cloudstack.api.command.user.volume.CreateVolumeCmd, cmdInfo:
{id:21,response:json,sessionkey:48nz1Dz96CYsK87tCQeRSeGmZ2E\u003d,cmdEventType:VOLUME.CREATE,ctxUserId:2,snapshotid:388aeb8c-b9ea-4117-9c20-a8453c546ccc,name:volsanp,httpmethod:GET,_:1391420610122,ctxAccountId:2,ctxStartEventId:203}
, cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0,
result: null, initMsid: 7494415941730, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-02-03 20:33:07,156 DEBUG [o.a.c.s.a.LocalStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) LocalStoragePoolAllocator trying
to find storage pool to fit the vm
2014-02-03 20:33:07,156 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) ClusterScopeStoragePoolAllocator
looking for storage pool
2014-02-03 20:33:07,157 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Looking for pools in dc: 1 pod:1
cluster:null
2014-02-03 20:33:07,159 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Found pools matching tags: []
2014-02-03 20:33:07,161 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) No storage pools available for
shared volume allocation, returning
2014-02-03 20:33:07,161 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) ZoneWideStoragePoolAllocator to
find storage pool
2014-02-03 20:33:07,170 DEBUG [o.a.c.s.a.ZoneWideStoragePoolAllocator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Removing pool
Pool[1|NetworkFilesystem] from avoid set, must have been inserted when
searching for another disk's tag
2014-02-03 20:33:07,177 DEBUG [c.c.s.StorageManagerImpl]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Checking pool 1 for storage,
totalSize: 5902284816384, usedBytes: 3731833782272, usedPct:
0.6322693496445476, disable threshold: 0.85
2014-02-03 20:33:07,187 DEBUG [c.c.s.StorageManagerImpl]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Checking pool: 1 for volume
allocation [Vol[21|vm=null|DATADISK]], maxSize : 11804569632768,
totalAllocatedSize : 63747532288, askingSize : 8589934592, allocated disable
threshold: 0.85
2014-02-03 20:33:07,189 DEBUG [o.a.c.e.o.VolumeOrchestrator]
(Job-Executor-89:ctx-7e16453b ctx-d6b53517) Found a suitable pool for create
volume: 1
2014-02-03 20:33:07,197 DEBUG
[jira] [Resolved] (CLOUDSTACK-5686) Contrail:CPVM: Console proxy view of guest VM's being timed out
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Parth Jagirdar resolved CLOUDSTACK-5686.
Resolution: Fixed
Fixed with public connectivity using devstack gateway.
Contrail:CPVM: Console proxy view of guest VM's being timed out
---
Key: CLOUDSTACK-5686
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5686
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Contrail, SystemVM
Affects Versions: 4.2.0
Environment: Contrail
Reporter: Parth Jagirdar
Priority: Critical
CPVM is up and in running state.
2013-12-30 17:23:12,050 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-8:null) SeqA 2-43172: Processing Seq 2-43172: { Cmd ,
MgmtId: -1, via: 2, Ver: v1, Flags: 11,
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
\connections\: []\n},wait:0}}] }
2013-12-30 17:23:12,054 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-8:null) SeqA 2-43172: Sending Seq 2-43172: { Ans: ,
MgmtId: 86780043846508, via: 2, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2013-12-30 17:23:13,024 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-712654670: Sending { Cmd , MgmtId:
86780043846508, via: 1, Ver: v1, Flags: 100011,
[{com.cloud.agent.api.GetVncPortCommand:{id:3039,name:i-2-3039-VM,wait:0}}]
}
2013-12-30 17:23:13,024 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-712654670: Executing: { Cmd , MgmtId:
86780043846508, via: 1, Ver: v1, Flags: 100011,
[{com.cloud.agent.api.GetVncPortCommand:{id:3039,name:i-2-3039-VM,wait:0}}]
}
2013-12-30 17:23:13,024 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-219:null) Seq 1-712654670: Executing request
2013-12-30 17:23:13,165 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-219:null) Seq 1-712654670: Response Received:
2013-12-30 17:23:13,166 DEBUG [agent.transport.Request]
(DirectAgent-219:null) Seq 1-712654670: Processing: { Ans: , MgmtId:
86780043846508, via: 1, Ver: v1, Flags: 10,
[{com.cloud.agent.api.GetVncPortAnswer:{address:consoleurl=https://10.223.58.68/console?uuid=97f7d540-63a4-fbce-71e2-2c2035b7fe24sessionref=OpaqueRef:5a258d6f-6549-f894-d740-1f4dd3e40e0c,port:-1,result:true,wait:0}}]
}
2013-12-30 17:23:13,166 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-712654670: Received: { Ans: , MgmtId:
86780043846508, via: 1, Ver: v1, Flags: 10, { GetVncPortAnswer } }
2013-12-30 17:23:13,166 DEBUG [cloud.servlet.ConsoleProxyServlet]
(catalina-exec-23:null) Port info
consoleurl=https://10.223.58.68/console?uuid=97f7d540-63a4-fbce-71e2-2c2035b7fe24sessionref=OpaqueRef:5a258d6f-6549-f894-d740-1f4dd3e40e0c
2013-12-30 17:23:13,166 INFO [cloud.servlet.ConsoleProxyServlet]
(catalina-exec-23:null) Parse host info returned from executing
GetVNCPortCommand. host info:
consoleurl=https://10.223.58.68/console?uuid=97f7d540-63a4-fbce-71e2-2c2035b7fe24sessionref=OpaqueRef:5a258d6f-6549-f894-d740-1f4dd3e40e0c
2013-12-30 17:23:13,168 DEBUG [cloud.servlet.ConsoleProxyServlet]
(catalina-exec-23:null) Compose console url:
https://10-223-138-3.realhostip.com/ajax?token=jbfEZBHaxjTQJndV5T1HMf5zgIrBE7IEyfI-8Tmi428dLW1rwxGG7nAe0h3ys_-uhPylt2tSO6vaTstQzKEb8-WyCEhDt_YMnGHqTRgvAOBc64cz8cw9EAqdxH9JWZRi3o-uUrazsGIV2nd4y5zzut_FtEOeWdkCNbWQcSHUJcQeK6CaF-BIgZL8CMzJiu4i0JKrZ-0NZWep4YDG9F8wGIIFRkHjLMQC5h0Qso9nJcLCvodUF0tpwRyS6M-DT-XyUPnU-Q7BCEat5DnU44FXN-ZNzBaJkLGOW4DpI5spApUXab8VRlp5DZBkzdoH_Mk1Ht38hQ48XKhD7BVYUp_xCFTJdzvsc-185eQuTmy1GN5UKth2tV2Ly6uzuQowFnN95rijJkVUyhFu7Wvpy8dLqI5ZNNM-xYaG4YXzsSIJTomNDfTa__24bqLyOZzSMVbyZUixmgMZ_K0lDHdXgTgUtAnJ-ygBIDvfxmh-cga4JwU
2013-12-30 17:23:13,168 DEBUG [cloud.servlet.ConsoleProxyServlet]
(catalina-exec-23:null) the console url is ::
htmltitlescapegoat/titleframesetframe
src=https://10-223-138-3.realhostip.com/ajax?token=jbfEZBHaxjTQJndV5T1HMf5zgIrBE7IEyfI-8Tmi428dLW1rwxGG7nAe0h3ys_-uhPylt2tSO6vaTstQzKEb8-WyCEhDt_YMnGHqTRgvAOBc64cz8cw9EAqdxH9JWZRi3o-uUrazsGIV2nd4y5zzut_FtEOeWdkCNbWQcSHUJcQeK6CaF-BIgZL8CMzJiu4i0JKrZ-0NZWep4YDG9F8wGIIFRkHjLMQC5h0Qso9nJcLCvodUF0tpwRyS6M-DT-XyUPnU-Q7BCEat5DnU44FXN-ZNzBaJkLGOW4DpI5spApUXab8VRlp5DZBkzdoH_Mk1Ht38hQ48XKhD7BVYUp_xCFTJdzvsc-185eQuTmy1GN5UKth2tV2Ly6uzuQowFnN95rijJkVUyhFu7Wvpy8dLqI5ZNNM-xYaG4YXzsSIJTomNDfTa__24bqLyOZzSMVbyZUixmgMZ_K0lDHdXgTgUtAnJ-ygBIDvfxmh-cga4JwU;/frame/frameset/html
2013-12-30 17:23:18,907 DEBUG [storage.secondary.SecondaryStorageManagerImpl]
(secstorage-1:null) Zone 1 is ready to launch secondary storage VM
2013-12-30 17:23:19,093 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl]
(consoleproxy-1:null) Zone
[jira] [Reopened] (CLOUDSTACK-5686) Contrail:CPVM: Console proxy view of guest VM's being timed out
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Parth Jagirdar reopened CLOUDSTACK-5686:
Verified using devstack.
Contrail:CPVM: Console proxy view of guest VM's being timed out
---
Key: CLOUDSTACK-5686
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5686
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Contrail, SystemVM
Affects Versions: 4.2.0
Environment: Contrail
Reporter: Parth Jagirdar
Priority: Critical
CPVM is up and in running state.
2013-12-30 17:23:12,050 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-8:null) SeqA 2-43172: Processing Seq 2-43172: { Cmd ,
MgmtId: -1, via: 2, Ver: v1, Flags: 11,
[{com.cloud.agent.api.ConsoleProxyLoadReportCommand:{_proxyVmId:2,_loadInfo:{\n
\connections\: []\n},wait:0}}] }
2013-12-30 17:23:12,054 DEBUG [agent.manager.AgentManagerImpl]
(AgentManager-Handler-8:null) SeqA 2-43172: Sending Seq 2-43172: { Ans: ,
MgmtId: 86780043846508, via: 2, Ver: v1, Flags: 100010,
[{com.cloud.agent.api.AgentControlAnswer:{result:true,wait:0}}] }
2013-12-30 17:23:13,024 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-712654670: Sending { Cmd , MgmtId:
86780043846508, via: 1, Ver: v1, Flags: 100011,
[{com.cloud.agent.api.GetVncPortCommand:{id:3039,name:i-2-3039-VM,wait:0}}]
}
2013-12-30 17:23:13,024 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-712654670: Executing: { Cmd , MgmtId:
86780043846508, via: 1, Ver: v1, Flags: 100011,
[{com.cloud.agent.api.GetVncPortCommand:{id:3039,name:i-2-3039-VM,wait:0}}]
}
2013-12-30 17:23:13,024 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-219:null) Seq 1-712654670: Executing request
2013-12-30 17:23:13,165 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-219:null) Seq 1-712654670: Response Received:
2013-12-30 17:23:13,166 DEBUG [agent.transport.Request]
(DirectAgent-219:null) Seq 1-712654670: Processing: { Ans: , MgmtId:
86780043846508, via: 1, Ver: v1, Flags: 10,
[{com.cloud.agent.api.GetVncPortAnswer:{address:consoleurl=https://10.223.58.68/console?uuid=97f7d540-63a4-fbce-71e2-2c2035b7fe24sessionref=OpaqueRef:5a258d6f-6549-f894-d740-1f4dd3e40e0c,port:-1,result:true,wait:0}}]
}
2013-12-30 17:23:13,166 DEBUG [agent.transport.Request]
(catalina-exec-23:null) Seq 1-712654670: Received: { Ans: , MgmtId:
86780043846508, via: 1, Ver: v1, Flags: 10, { GetVncPortAnswer } }
2013-12-30 17:23:13,166 DEBUG [cloud.servlet.ConsoleProxyServlet]
(catalina-exec-23:null) Port info
consoleurl=https://10.223.58.68/console?uuid=97f7d540-63a4-fbce-71e2-2c2035b7fe24sessionref=OpaqueRef:5a258d6f-6549-f894-d740-1f4dd3e40e0c
2013-12-30 17:23:13,166 INFO [cloud.servlet.ConsoleProxyServlet]
(catalina-exec-23:null) Parse host info returned from executing
GetVNCPortCommand. host info:
consoleurl=https://10.223.58.68/console?uuid=97f7d540-63a4-fbce-71e2-2c2035b7fe24sessionref=OpaqueRef:5a258d6f-6549-f894-d740-1f4dd3e40e0c
2013-12-30 17:23:13,168 DEBUG [cloud.servlet.ConsoleProxyServlet]
(catalina-exec-23:null) Compose console url:
https://10-223-138-3.realhostip.com/ajax?token=jbfEZBHaxjTQJndV5T1HMf5zgIrBE7IEyfI-8Tmi428dLW1rwxGG7nAe0h3ys_-uhPylt2tSO6vaTstQzKEb8-WyCEhDt_YMnGHqTRgvAOBc64cz8cw9EAqdxH9JWZRi3o-uUrazsGIV2nd4y5zzut_FtEOeWdkCNbWQcSHUJcQeK6CaF-BIgZL8CMzJiu4i0JKrZ-0NZWep4YDG9F8wGIIFRkHjLMQC5h0Qso9nJcLCvodUF0tpwRyS6M-DT-XyUPnU-Q7BCEat5DnU44FXN-ZNzBaJkLGOW4DpI5spApUXab8VRlp5DZBkzdoH_Mk1Ht38hQ48XKhD7BVYUp_xCFTJdzvsc-185eQuTmy1GN5UKth2tV2Ly6uzuQowFnN95rijJkVUyhFu7Wvpy8dLqI5ZNNM-xYaG4YXzsSIJTomNDfTa__24bqLyOZzSMVbyZUixmgMZ_K0lDHdXgTgUtAnJ-ygBIDvfxmh-cga4JwU
2013-12-30 17:23:13,168 DEBUG [cloud.servlet.ConsoleProxyServlet]
(catalina-exec-23:null) the console url is ::
htmltitlescapegoat/titleframesetframe
src=https://10-223-138-3.realhostip.com/ajax?token=jbfEZBHaxjTQJndV5T1HMf5zgIrBE7IEyfI-8Tmi428dLW1rwxGG7nAe0h3ys_-uhPylt2tSO6vaTstQzKEb8-WyCEhDt_YMnGHqTRgvAOBc64cz8cw9EAqdxH9JWZRi3o-uUrazsGIV2nd4y5zzut_FtEOeWdkCNbWQcSHUJcQeK6CaF-BIgZL8CMzJiu4i0JKrZ-0NZWep4YDG9F8wGIIFRkHjLMQC5h0Qso9nJcLCvodUF0tpwRyS6M-DT-XyUPnU-Q7BCEat5DnU44FXN-ZNzBaJkLGOW4DpI5spApUXab8VRlp5DZBkzdoH_Mk1Ht38hQ48XKhD7BVYUp_xCFTJdzvsc-185eQuTmy1GN5UKth2tV2Ly6uzuQowFnN95rijJkVUyhFu7Wvpy8dLqI5ZNNM-xYaG4YXzsSIJTomNDfTa__24bqLyOZzSMVbyZUixmgMZ_K0lDHdXgTgUtAnJ-ygBIDvfxmh-cga4JwU;/frame/frameset/html
2013-12-30 17:23:18,907 DEBUG [storage.secondary.SecondaryStorageManagerImpl]
(secstorage-1:null) Zone 1 is ready to launch secondary storage VM
2013-12-30 17:23:19,093 DEBUG [cloud.consoleproxy.ConsoleProxyManagerImpl]
(consoleproxy-1:null) Zone 1 is ready to launch console proxy
2013-12-30
[jira] [Closed] (CLOUDSTACK-5768) Contrail:MS: No public network access
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar closed CLOUDSTACK-5768. -- Workaround available using devstack. Contrail:MS: No public network access - Key: CLOUDSTACK-5768 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5768 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Contrail Affects Versions: 4.2.0 Environment: Contrail Reporter: Parth Jagirdar Priority: Critical Fix For: 4.2.1 Guest VM's, System VM's have no public network access. Need a workaround to be able to reach public network without a physical router running BGP/GRE. No public network access results in failure while registering templates and ISO. (Assuming following exception is due to connectivity) 2014-01-03 11:34:41,708 DEBUG [cloud.api.ApiServlet] (catalina-exec-24:null) ===START=== 10.215.2.19 -- GET command=registerIsoresponse=jsonsessionkey=6NRmRzTiABw%2Fcqv6%2FfkDDI7HWjg%3Dname=CentOS-6.4-x86_64-minimaldisplayText=CentOS-6.4-x86_64-minimalurl=http%3A%2F%2Fnfs1.lab.vmops.com%2Fparth%2FCentOS-6.4-x86_64-minimal.isozoneid=-1isextractable=falsebootable=trueosTypeId=90a6b632-677a-11e3-b51d-4eed0dafe36cispublic=trueisfeatured=true_=1388777693620 2014-01-03 11:34:41,797 DEBUG [storage.image.TemplateDataFactoryImpl] (catalina-exec-24:null) template 201 is already in store:1, type:Image 2014-01-03 11:34:41,810 DEBUG [storage.image.TemplateDataFactoryImpl] (catalina-exec-24:null) template 201 is already in store:1, type:Image 2014-01-03 11:34:41,822 DEBUG [storage.image.BaseImageStoreDriverImpl] (catalina-exec-24:null) Downloading template to data store 1 2014-01-03 11:34:41,828 INFO [storage.download.DownloadMonitorImpl] (catalina-exec-24:null) Template download is already in progress or already downloaded 2014-01-03 11:34:41,828 DEBUG [storage.image.BaseImageStoreDriverImpl] (catalina-exec-24:null) Performing image store createTemplate async callback 2014-01-03 11:34:41,851 DEBUG [contrail.management.EventUtils$EventInterceptor] (catalina-exec-24:null) interceptException 2014-01-03 11:34:41,851 ERROR [cloud.api.ApiServer] (catalina-exec-24:null) unhandled exception executing api command: registerIso java.lang.RuntimeException: InvocationTargetException when invoking RPC callback for command: createTemplateAsyncCallback at org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.dispatch(AsyncCallbackDispatcher.java:148) at org.apache.cloudstack.framework.async.InplaceAsyncCallbackDriver.performCompletionCallback(InplaceAsyncCallbackDriver.java:26) at org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.complete(AsyncCallbackDispatcher.java:120) at com.cloud.storage.download.DownloadMonitorImpl.downloadTemplateToStorage(DownloadMonitorImpl.java:214) at org.apache.cloudstack.storage.image.BaseImageStoreDriverImpl.createAsync(BaseImageStoreDriverImpl.java:120) at org.apache.cloudstack.storage.image.TemplateServiceImpl.createTemplateAsync(TemplateServiceImpl.java:175) at com.cloud.template.HypervisorTemplateAdapter.create(HypervisorTemplateAdapter.java:213) at com.cloud.template.TemplateManagerImpl.registerIso(TemplateManagerImpl.java:322) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.iso.RegisterIsoCmd.execute(RegisterIsoCmd.java:180) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at
[jira] [Resolved] (CLOUDSTACK-5768) Contrail:MS: No public network access
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Parth Jagirdar resolved CLOUDSTACK-5768. Resolution: Fixed Fix Version/s: 4.2.1 Use devstack to decapsulate traffic. Contrail:MS: No public network access - Key: CLOUDSTACK-5768 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5768 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Contrail Affects Versions: 4.2.0 Environment: Contrail Reporter: Parth Jagirdar Priority: Critical Fix For: 4.2.1 Guest VM's, System VM's have no public network access. Need a workaround to be able to reach public network without a physical router running BGP/GRE. No public network access results in failure while registering templates and ISO. (Assuming following exception is due to connectivity) 2014-01-03 11:34:41,708 DEBUG [cloud.api.ApiServlet] (catalina-exec-24:null) ===START=== 10.215.2.19 -- GET command=registerIsoresponse=jsonsessionkey=6NRmRzTiABw%2Fcqv6%2FfkDDI7HWjg%3Dname=CentOS-6.4-x86_64-minimaldisplayText=CentOS-6.4-x86_64-minimalurl=http%3A%2F%2Fnfs1.lab.vmops.com%2Fparth%2FCentOS-6.4-x86_64-minimal.isozoneid=-1isextractable=falsebootable=trueosTypeId=90a6b632-677a-11e3-b51d-4eed0dafe36cispublic=trueisfeatured=true_=1388777693620 2014-01-03 11:34:41,797 DEBUG [storage.image.TemplateDataFactoryImpl] (catalina-exec-24:null) template 201 is already in store:1, type:Image 2014-01-03 11:34:41,810 DEBUG [storage.image.TemplateDataFactoryImpl] (catalina-exec-24:null) template 201 is already in store:1, type:Image 2014-01-03 11:34:41,822 DEBUG [storage.image.BaseImageStoreDriverImpl] (catalina-exec-24:null) Downloading template to data store 1 2014-01-03 11:34:41,828 INFO [storage.download.DownloadMonitorImpl] (catalina-exec-24:null) Template download is already in progress or already downloaded 2014-01-03 11:34:41,828 DEBUG [storage.image.BaseImageStoreDriverImpl] (catalina-exec-24:null) Performing image store createTemplate async callback 2014-01-03 11:34:41,851 DEBUG [contrail.management.EventUtils$EventInterceptor] (catalina-exec-24:null) interceptException 2014-01-03 11:34:41,851 ERROR [cloud.api.ApiServer] (catalina-exec-24:null) unhandled exception executing api command: registerIso java.lang.RuntimeException: InvocationTargetException when invoking RPC callback for command: createTemplateAsyncCallback at org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.dispatch(AsyncCallbackDispatcher.java:148) at org.apache.cloudstack.framework.async.InplaceAsyncCallbackDriver.performCompletionCallback(InplaceAsyncCallbackDriver.java:26) at org.apache.cloudstack.framework.async.AsyncCallbackDispatcher.complete(AsyncCallbackDispatcher.java:120) at com.cloud.storage.download.DownloadMonitorImpl.downloadTemplateToStorage(DownloadMonitorImpl.java:214) at org.apache.cloudstack.storage.image.BaseImageStoreDriverImpl.createAsync(BaseImageStoreDriverImpl.java:120) at org.apache.cloudstack.storage.image.TemplateServiceImpl.createTemplateAsync(TemplateServiceImpl.java:175) at com.cloud.template.HypervisorTemplateAdapter.create(HypervisorTemplateAdapter.java:213) at com.cloud.template.TemplateManagerImpl.registerIso(TemplateManagerImpl.java:322) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.iso.RegisterIsoCmd.execute(RegisterIsoCmd.java:180) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158) at com.cloud.api.ApiServer.queueCommand(ApiServer.java:514) at com.cloud.api.ApiServer.handleRequest(ApiServer.java:372) at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:305) at com.cloud.api.ApiServlet.doGet(ApiServlet.java:66) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
[jira] [Commented] (CLOUDSTACK-6048) [UI] [Report Sockets] To remove LXC and OVM entries from Sockets in Infrastructure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894034#comment-13894034 ] Jessica Wang commented on CLOUDSTACK-6048: -- http://bugs-ccp.citrix.com/browse/CS-19063 [UI] [Report Sockets] To remove LXC and OVM entries from Sockets in Infrastructure Key: CLOUDSTACK-6048 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6048 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang 1) we have to remove LXC and OVM hypervisor entries from Sockets list page in Infrastructure Sockets 2) We need to differentiate Xenserver version in sockets list page something like Xenserver 6.1.x and before Xenserver 6.2 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6048) [UI] [Report Sockets] To remove LXC and OVM entries from Sockets in Infrastructure
Jessica Wang created CLOUDSTACK-6048: Summary: [UI] [Report Sockets] To remove LXC and OVM entries from Sockets in Infrastructure Key: CLOUDSTACK-6048 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6048 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang 1) we have to remove LXC and OVM hypervisor entries from Sockets list page in Infrastructure Sockets 2) We need to differentiate Xenserver version in sockets list page something like Xenserver 6.1.x and before Xenserver 6.2 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (CLOUDSTACK-6048) [UI] [Report Sockets] To remove LXC and OVM entries from Sockets in Infrastructure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894055#comment-13894055 ] ASF subversion and git services commented on CLOUDSTACK-6048: - Commit 04766c6d476226192f663913cfaa911fc3ec29b2 in branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=04766c6 ] CLOUDSTACK-6048: UI Infrastructure socket listing (1) remove LXC, OVM. (2) change XenServer label to differentiate XenServer version. [UI] [Report Sockets] To remove LXC and OVM entries from Sockets in Infrastructure Key: CLOUDSTACK-6048 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6048 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang 1) we have to remove LXC and OVM hypervisor entries from Sockets list page in Infrastructure Sockets 2) We need to differentiate Xenserver version in sockets list page something like Xenserver 6.1.x and before Xenserver 6.2 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (CLOUDSTACK-6048) [UI] [Report Sockets] To remove LXC and OVM entries from Sockets in Infrastructure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-6048. -- Resolution: Fixed [UI] [Report Sockets] To remove LXC and OVM entries from Sockets in Infrastructure Key: CLOUDSTACK-6048 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6048 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang 1) we have to remove LXC and OVM hypervisor entries from Sockets list page in Infrastructure Sockets 2) We need to differentiate Xenserver version in sockets list page something like Xenserver 6.1.x and before Xenserver 6.2 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Closed] (CLOUDSTACK-6048) [UI] [Report Sockets] To remove LXC and OVM entries from Sockets in Infrastructure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang closed CLOUDSTACK-6048. [UI] [Report Sockets] To remove LXC and OVM entries from Sockets in Infrastructure Key: CLOUDSTACK-6048 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6048 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang 1) we have to remove LXC and OVM hypervisor entries from Sockets list page in Infrastructure Sockets 2) We need to differentiate Xenserver version in sockets list page something like Xenserver 6.1.x and before Xenserver 6.2 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-6049) CreateTemplate from snapshot is failing on a multi-zone setup after migration of NFS to S3.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen reassigned CLOUDSTACK-6049: Assignee: Min Chen CreateTemplate from snapshot is failing on a multi-zone setup after migration of NFS to S3. --- Key: CLOUDSTACK-6049 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6049 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.3.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.3.0 1. Have CS with 2 zones each zone with zen and KVM. 2. deploy VMs in both zones. 3. Create snapshots of root volumes. 4. Migrate NFS to S3. 5. Create template from snapshots. Observation : After migrating the NFS secondary storage to S3 1st time createTemplate from snapshot is failing with NPE but next createTemplate from snapshots are going fine. KVM: 2014-02-03 19:56:28,023 DEBUG [c.c.a.m.AgentAttache] (AgentManager-Handler-13:null) Seq 8-983761017: No more commands found 2014-02-03 19:56:28,039 DEBUG [o.a.c.s.m.AncientDataMotionStrategy] (Job-Executor-63:ctx-a3bdfb4e ctx-5c6dd9da) copy failed java.lang.NullPointerException at org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.createTemplateFromSnapshot(AncientDataMotionStrategy.java:459) at org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:413) at org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:70) at org.apache.cloudstack.storage.image.TemplateServiceImpl.copyAsync(TemplateServiceImpl.java:646) at org.apache.cloudstack.storage.image.TemplateServiceImpl.createTemplateFromSnapshotAsync(TemplateServiceImpl.java:653) at com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1385) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy158.createPrivateTemplate(Unknown Source) at org.apache.cloudstack.api.command.user.template.CreateTemplateCmd.execute(CreateTemplateCmd.java:265) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) 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.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:509) 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
[jira] [Created] (CLOUDSTACK-6049) CreateTemplate from snapshot is failing on a multi-zone setup after migration of NFS to S3.
Min Chen created CLOUDSTACK-6049: Summary: CreateTemplate from snapshot is failing on a multi-zone setup after migration of NFS to S3. Key: CLOUDSTACK-6049 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6049 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.3.0 Reporter: Min Chen Priority: Critical Fix For: 4.3.0 1. Have CS with 2 zones each zone with zen and KVM. 2. deploy VMs in both zones. 3. Create snapshots of root volumes. 4. Migrate NFS to S3. 5. Create template from snapshots. Observation : After migrating the NFS secondary storage to S3 1st time createTemplate from snapshot is failing with NPE but next createTemplate from snapshots are going fine. KVM: 2014-02-03 19:56:28,023 DEBUG [c.c.a.m.AgentAttache] (AgentManager-Handler-13:null) Seq 8-983761017: No more commands found 2014-02-03 19:56:28,039 DEBUG [o.a.c.s.m.AncientDataMotionStrategy] (Job-Executor-63:ctx-a3bdfb4e ctx-5c6dd9da) copy failed java.lang.NullPointerException at org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.createTemplateFromSnapshot(AncientDataMotionStrategy.java:459) at org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:413) at org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:70) at org.apache.cloudstack.storage.image.TemplateServiceImpl.copyAsync(TemplateServiceImpl.java:646) at org.apache.cloudstack.storage.image.TemplateServiceImpl.createTemplateFromSnapshotAsync(TemplateServiceImpl.java:653) at com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1385) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy158.createPrivateTemplate(Unknown Source) at org.apache.cloudstack.api.command.user.template.CreateTemplateCmd.execute(CreateTemplateCmd.java:265) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) 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.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:509) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2014-02-03 19:56:28,052 DEBUG [c.c.t.TemplateManagerImpl] (Job-Executor-63:ctx-a3bdfb4e ctx-5c6dd9da)
[jira] [Commented] (CLOUDSTACK-6049) CreateTemplate from snapshot is failing on a multi-zone setup after migration of NFS to S3.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894082#comment-13894082 ] ASF subversion and git services commented on CLOUDSTACK-6049: - Commit bac2c1e5b49a1b5c4be37ca17d5e4829a2906782 in branch refs/heads/master from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bac2c1e ] CLOUDSTACK-6049: Give priority to cache stores where data object is already there instead of randomly picking one in case there are multiple cache stores in the scope. CreateTemplate from snapshot is failing on a multi-zone setup after migration of NFS to S3. --- Key: CLOUDSTACK-6049 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6049 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.3.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.3.0 1. Have CS with 2 zones each zone with zen and KVM. 2. deploy VMs in both zones. 3. Create snapshots of root volumes. 4. Migrate NFS to S3. 5. Create template from snapshots. Observation : After migrating the NFS secondary storage to S3 1st time createTemplate from snapshot is failing with NPE but next createTemplate from snapshots are going fine. KVM: 2014-02-03 19:56:28,023 DEBUG [c.c.a.m.AgentAttache] (AgentManager-Handler-13:null) Seq 8-983761017: No more commands found 2014-02-03 19:56:28,039 DEBUG [o.a.c.s.m.AncientDataMotionStrategy] (Job-Executor-63:ctx-a3bdfb4e ctx-5c6dd9da) copy failed java.lang.NullPointerException at org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.createTemplateFromSnapshot(AncientDataMotionStrategy.java:459) at org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:413) at org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:70) at org.apache.cloudstack.storage.image.TemplateServiceImpl.copyAsync(TemplateServiceImpl.java:646) at org.apache.cloudstack.storage.image.TemplateServiceImpl.createTemplateFromSnapshotAsync(TemplateServiceImpl.java:653) at com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1385) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy158.createPrivateTemplate(Unknown Source) at org.apache.cloudstack.api.command.user.template.CreateTemplateCmd.execute(CreateTemplateCmd.java:265) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) 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.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:509) 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
[jira] [Resolved] (CLOUDSTACK-6049) CreateTemplate from snapshot is failing on a multi-zone setup after migration of NFS to S3.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Min Chen resolved CLOUDSTACK-6049. -- Resolution: Fixed CreateTemplate from snapshot is failing on a multi-zone setup after migration of NFS to S3. --- Key: CLOUDSTACK-6049 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6049 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.3.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.3.0 1. Have CS with 2 zones each zone with zen and KVM. 2. deploy VMs in both zones. 3. Create snapshots of root volumes. 4. Migrate NFS to S3. 5. Create template from snapshots. Observation : After migrating the NFS secondary storage to S3 1st time createTemplate from snapshot is failing with NPE but next createTemplate from snapshots are going fine. KVM: 2014-02-03 19:56:28,023 DEBUG [c.c.a.m.AgentAttache] (AgentManager-Handler-13:null) Seq 8-983761017: No more commands found 2014-02-03 19:56:28,039 DEBUG [o.a.c.s.m.AncientDataMotionStrategy] (Job-Executor-63:ctx-a3bdfb4e ctx-5c6dd9da) copy failed java.lang.NullPointerException at org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.createTemplateFromSnapshot(AncientDataMotionStrategy.java:459) at org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:413) at org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:70) at org.apache.cloudstack.storage.image.TemplateServiceImpl.copyAsync(TemplateServiceImpl.java:646) at org.apache.cloudstack.storage.image.TemplateServiceImpl.createTemplateFromSnapshotAsync(TemplateServiceImpl.java:653) at com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1385) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy158.createPrivateTemplate(Unknown Source) at org.apache.cloudstack.api.command.user.template.CreateTemplateCmd.execute(CreateTemplateCmd.java:265) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) 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.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:509) 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
[jira] [Commented] (CLOUDSTACK-6049) CreateTemplate from snapshot is failing on a multi-zone setup after migration of NFS to S3.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894071#comment-13894071 ] ASF subversion and git services commented on CLOUDSTACK-6049: - Commit e00241f41d6542cf1c5d93216fed55609cd7746a in branch refs/heads/4.3-forward from [~minchen07] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e00241f ] CLOUDSTACK-6049: Give priority to cache stores where data object is already there instead of randomly picking one in case there are multiple cache stores in the scope. CreateTemplate from snapshot is failing on a multi-zone setup after migration of NFS to S3. --- Key: CLOUDSTACK-6049 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6049 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Affects Versions: 4.3.0 Reporter: Min Chen Assignee: Min Chen Priority: Critical Fix For: 4.3.0 1. Have CS with 2 zones each zone with zen and KVM. 2. deploy VMs in both zones. 3. Create snapshots of root volumes. 4. Migrate NFS to S3. 5. Create template from snapshots. Observation : After migrating the NFS secondary storage to S3 1st time createTemplate from snapshot is failing with NPE but next createTemplate from snapshots are going fine. KVM: 2014-02-03 19:56:28,023 DEBUG [c.c.a.m.AgentAttache] (AgentManager-Handler-13:null) Seq 8-983761017: No more commands found 2014-02-03 19:56:28,039 DEBUG [o.a.c.s.m.AncientDataMotionStrategy] (Job-Executor-63:ctx-a3bdfb4e ctx-5c6dd9da) copy failed java.lang.NullPointerException at org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.createTemplateFromSnapshot(AncientDataMotionStrategy.java:459) at org.apache.cloudstack.storage.motion.AncientDataMotionStrategy.copyAsync(AncientDataMotionStrategy.java:413) at org.apache.cloudstack.storage.motion.DataMotionServiceImpl.copyAsync(DataMotionServiceImpl.java:70) at org.apache.cloudstack.storage.image.TemplateServiceImpl.copyAsync(TemplateServiceImpl.java:646) at org.apache.cloudstack.storage.image.TemplateServiceImpl.createTemplateFromSnapshotAsync(TemplateServiceImpl.java:653) at com.cloud.template.TemplateManagerImpl.createPrivateTemplate(TemplateManagerImpl.java:1385) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at $Proxy158.createPrivateTemplate(Unknown Source) at org.apache.cloudstack.api.command.user.template.CreateTemplateCmd.execute(CreateTemplateCmd.java:265) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109) at com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66) 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.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:509) 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
[jira] [Updated] (CLOUDSTACK-3941) Put dynamic scaling attribute in the service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinandan Prateek updated CLOUDSTACK-3941: --- Assignee: Bharat Kumar (was: Nitin Mehta) Put dynamic scaling attribute in the service offering - Key: CLOUDSTACK-3941 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3941 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: We should put the dynamic scaling capability in the service offering so that by default the its not enabled for all the deployed vms. Only if the user wants it does then he should be charged a premium and accordingly attributes set for it. Reporter: Nitin Mehta Assignee: Bharat Kumar Fix For: Future -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6050) A limitations on min-max on CPU/RAM for a dynamic offering
Abhinandan Prateek created CLOUDSTACK-6050: -- Summary: A limitations on min-max on CPU/RAM for a dynamic offering Key: CLOUDSTACK-6050 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6050 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Abhinandan Prateek Assignee: Bharat Kumar Priority: Critical Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6051) VR Rolling upgrade: Make the numbers of Routers parallely being upgraded as configurable
Abhinandan Prateek created CLOUDSTACK-6051: -- Summary: VR Rolling upgrade: Make the numbers of Routers parallely being upgraded as configurable Key: CLOUDSTACK-6051 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6051 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.3.0 Reporter: Abhinandan Prateek Assignee: Kishan Kavala Priority: Critical Fix For: 4.4.0 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5993) Cloud agent fails to start on 32-bit system vms (cpvm and ssvm) created with 4GB RAM offering
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koushik Das updated CLOUDSTACK-5993:
Fix Version/s: (was: 4.4.0)
4.3.0
Cloud agent fails to start on 32-bit system vms (cpvm and ssvm) created with
4GB RAM offering
-
Key: CLOUDSTACK-5993
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5993
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Reporter: Koushik Das
Assignee: shweta agarwal
Priority: Critical
Fix For: 4.3.0
Repro steps:
- Create cpvm with 4GB RAM offering
- Once the VM is up and running, verify that cloud agent is not started
- Check the logs at /var/log/cloud/cloud.out and see the following lines
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
There is a script _run.sh that gets deployed as part of systemvm.iso. This
computes the max. heap size for the agent JVM based on the below logic.
tot_mem_k=$(cat /proc/meminfo | grep MemTotal | awk '{print $2}')
let tot_mem_m=tot_mem_k10
let eightypcnt=$tot_mem_m*8/10
let maxmem=$tot_mem_m-80
if [ $maxmem -gt $eightypcnt ]
then
maxmem=$eightypcnt
fi
I did some testing and found that for 32 bit system vms if the max. heap size
specified is more than ~2600MB then the JVM fails to launch with the error
message provided in repro steps. Now for 4GB RAM, the computed heap size is
~3.2G (0.8*4G). As a result agent JVM fails to start.
For 64 bit system vms things work fine based on the above logic. I have
verified by creating system vms with 8GB and 12GB RAM and didn't notice any
issues.
Planning to fix the problem by adding the following logic
if [ $(uname -m | grep '64') == ]; then
let maxmem32bit=2600
if [ $maxmem -gt $maxmem32bit ]; then
maxmem=$maxmem32bit
fi
fi
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5989) Trying to start a vm while 'vm snapshot' is in progress results in inconsistency
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das updated CLOUDSTACK-5989: Fix Version/s: 4.3.0 Trying to start a vm while 'vm snapshot' is in progress results in inconsistency Key: CLOUDSTACK-5989 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5989 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Koushik Das Assignee: shweta agarwal Priority: Critical Fix For: 4.3.0, 4.4.0 Repro steps: 1. Deploy a user VM 2. Stop the VM 3. Issue a vm snapshot command 4. Immediately after that start the VM (while vm snapshot is still in progress) 5. VM stuck in starting state -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (CLOUDSTACK-5993) Cloud agent fails to start on 32-bit system vms (cpvm and ssvm) created with 4GB RAM offering
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koushik Das updated CLOUDSTACK-5993:
Fix Version/s: 4.4.0
Cloud agent fails to start on 32-bit system vms (cpvm and ssvm) created with
4GB RAM offering
-
Key: CLOUDSTACK-5993
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5993
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Reporter: Koushik Das
Assignee: shweta agarwal
Priority: Critical
Fix For: 4.3.0, 4.4.0
Repro steps:
- Create cpvm with 4GB RAM offering
- Once the VM is up and running, verify that cloud agent is not started
- Check the logs at /var/log/cloud/cloud.out and see the following lines
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
There is a script _run.sh that gets deployed as part of systemvm.iso. This
computes the max. heap size for the agent JVM based on the below logic.
tot_mem_k=$(cat /proc/meminfo | grep MemTotal | awk '{print $2}')
let tot_mem_m=tot_mem_k10
let eightypcnt=$tot_mem_m*8/10
let maxmem=$tot_mem_m-80
if [ $maxmem -gt $eightypcnt ]
then
maxmem=$eightypcnt
fi
I did some testing and found that for 32 bit system vms if the max. heap size
specified is more than ~2600MB then the JVM fails to launch with the error
message provided in repro steps. Now for 4GB RAM, the computed heap size is
~3.2G (0.8*4G). As a result agent JVM fails to start.
For 64 bit system vms things work fine based on the above logic. I have
verified by creating system vms with 8GB and 12GB RAM and didn't notice any
issues.
Planning to fix the problem by adding the following logic
if [ $(uname -m | grep '64') == ]; then
let maxmem32bit=2600
if [ $maxmem -gt $maxmem32bit ]; then
maxmem=$maxmem32bit
fi
fi
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Assigned] (CLOUDSTACK-6052) List VM enhancement to support querying with multiple VM IDs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das reassigned CLOUDSTACK-6052: --- Assignee: Koushik Das List VM enhancement to support querying with multiple VM IDs Key: CLOUDSTACK-6052 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6052 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.3.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.4.0 Currently list VM can only be called using a single VM ID. So if there is a need to query a set of VMs using ID then either multiple list VM calls need to be made or all VMs needs to be fetched and then do a client side filtering. Both approaches are sub-optimal - the former results in multiple queries to database and the latter will be an overkill if you need a small subset from a very large number of VMs. The proposal is to have an additional parameter to specify a list of VM IDs for which the data needs to be fetched. Using this the required VMs can be queried in an efficient manner. With the new parameter the syntax would look like http://localhost:8096/api?command=listVirtualMachineslistAll=trueids=eddac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-254979ba0134 The new 'ids' parameter will be mutually exclusive with the existing 'id' parameter. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (CLOUDSTACK-6052) List VM enhancement to support querying with multiple VM IDs
Koushik Das created CLOUDSTACK-6052: --- Summary: List VM enhancement to support querying with multiple VM IDs Key: CLOUDSTACK-6052 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6052 Project: CloudStack Issue Type: New Feature Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.3.0 Reporter: Koushik Das Fix For: 4.4.0 Currently list VM can only be called using a single VM ID. So if there is a need to query a set of VMs using ID then either multiple list VM calls need to be made or all VMs needs to be fetched and then do a client side filtering. Both approaches are sub-optimal - the former results in multiple queries to database and the latter will be an overkill if you need a small subset from a very large number of VMs. The proposal is to have an additional parameter to specify a list of VM IDs for which the data needs to be fetched. Using this the required VMs can be queried in an efficient manner. With the new parameter the syntax would look like http://localhost:8096/api?command=listVirtualMachineslistAll=trueids=eddac053-9b12-4d2e-acb7-233de2e98112,009966fc-4d7b-4f84-8609-254979ba0134 The new 'ids' parameter will be mutually exclusive with the existing 'id' parameter. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
