[jira] [Commented] (CLOUDSTACK-7646) test_nuage_vsp.py - Fix indentation issues and list out of index, mark test case as invalid, should be moved to BVT
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14217622#comment-14217622 ] Suresh Ramamurthy commented on CLOUDSTACK-7646: --- Hi Hugo, Gaurav, My apologies for delayed response. Thanks for fixing the indentation. We need entire Nuage VSP setup like SDN controller, Nuage VRS(openvswitch) on hypervisor, Nuage VSD to have Nuage VSP setup to test the test case. We make sure that we execute the integration test locally before submitting the code. So, we added the test case under integration. Please advise us the location where I need to add these test case. Thanks, Suresh > test_nuage_vsp.py - Fix indentation issues and list out of index, mark test > case as invalid, should be moved to BVT > --- > > Key: CLOUDSTACK-7646 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7646 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 > Environment: Observed on KVM >Reporter: Gaurav Aradhye >Assignee: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > This test has many indentation issues and list index issues. > Also even after fixing the issues the test case does not pass which indicates > it has not run before adding to regression test cases. > It should be marked as Invalid. > After author fixes the remaining issues, this test suite should be moved to > Smoke (BVT) as it has only one test case which is clearly a BVT. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7940) Exception printed completely on the UI. Not in a readable format
Sanjay Tripathi created CLOUDSTACK-7940:
---
Summary: Exception printed completely on the UI. Not in a readable
format
Key: CLOUDSTACK-7940
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7940
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: API
Affects Versions: 4.5.0
Reporter: Sanjay Tripathi
Assignee: Sanjay Tripathi
Fix For: 4.6.0
Steps:
===
1. Brought up a setup with 2 host and installed a windows 2012 VM (VM did not
have the tools installed at this point of time)
2. Migrated the VM to another host and observed the following exception on the
UI.
[Please see the attached screenshot.]
2014-11-10 06:13:38,432 WARN [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-374:ctx-dde7176f) Unable to migrate VM(i-2-6-VM) from
host(689bc2d8-f9f1-48d4-ad13-a35605ea005c) due to Task failed! Task record:
uuid: 75321ebd-30eb-32db-fb09-1db3fa0af65d
nameLabel: Async.VM.pool_migrate
nameDescription:
allowedOperations: []
currentOperations: {}
created: Mon Nov 10 06:13:37 UTC 2014
finished: Mon Nov 10 06:13:37 UTC 2014
status: failure
residentOn: com.xensource.xenapi.Host@f8cb719f
progress: 1.0
type:
result:
errorInfo: [VM_MISSING_PV_DRIVERS,
OpaqueRef:da164d58-b78f-965d-2726-5507f932c81a]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
Task failed! Task record: uuid:
75321ebd-30eb-32db-fb09-1db3fa0af65d
nameLabel: Async.VM.pool_migrate
nameDescription:
allowedOperations: []
currentOperations: {}
created: Mon Nov 10 06:13:37 UTC 2014
finished: Mon Nov 10 06:13:37 UTC 2014
status: failure
residentOn: com.xensource.xenapi.Host@f8cb719f
progress: 1.0
type:
result:
errorInfo: [VM_MISSING_PV_DRIVERS,
OpaqueRef:da164d58-b78f-965d-2726-5507f932c81a]
otherConfig: {}
subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
at
com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.checkForSuccess(CitrixResourceBase.java:3190)
at
com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.migrateVM(CitrixResourceBase.java:3343)
Observed behavior:
=
Full exception is seen on the UI.
Expected behavior:
=
A proper non-generic error message should be displayed on the screen instead of
an exception.
This is applicable to other scenarios where the exception is printed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7940) Exception printed completely on the UI. Not in a readable format
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjay Tripathi updated CLOUDSTACK-7940:
Attachment: screenshot-1.png
> Exception printed completely on the UI. Not in a readable format
>
>
> Key: CLOUDSTACK-7940
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7940
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.5.0
>Reporter: Sanjay Tripathi
>Assignee: Sanjay Tripathi
> Fix For: 4.6.0
>
> Attachments: screenshot-1.png
>
>
> Steps:
> ===
> 1. Brought up a setup with 2 host and installed a windows 2012 VM (VM did not
> have the tools installed at this point of time)
> 2. Migrated the VM to another host and observed the following exception on
> the UI.
> [Please see the attached screenshot.]
> 2014-11-10 06:13:38,432 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-374:ctx-dde7176f) Unable to migrate VM(i-2-6-VM) from
> host(689bc2d8-f9f1-48d4-ad13-a35605ea005c) due to Task failed! Task record:
> uuid: 75321ebd-30eb-32db-fb09-1db3fa0af65d
>nameLabel: Async.VM.pool_migrate
> nameDescription:
>allowedOperations: []
>currentOperations: {}
> created: Mon Nov 10 06:13:37 UTC 2014
> finished: Mon Nov 10 06:13:37 UTC 2014
> status: failure
> residentOn: com.xensource.xenapi.Host@f8cb719f
> progress: 1.0
> type:
> result:
>errorInfo: [VM_MISSING_PV_DRIVERS,
> OpaqueRef:da164d58-b78f-965d-2726-5507f932c81a]
> otherConfig: {}
>subtaskOf: com.xensource.xenapi.Task@aaf13f6f
> subtasks: []
> Task failed! Task record: uuid:
> 75321ebd-30eb-32db-fb09-1db3fa0af65d
>nameLabel: Async.VM.pool_migrate
> nameDescription:
>allowedOperations: []
>currentOperations: {}
> created: Mon Nov 10 06:13:37 UTC 2014
> finished: Mon Nov 10 06:13:37 UTC 2014
> status: failure
> residentOn: com.xensource.xenapi.Host@f8cb719f
> progress: 1.0
> type:
> result:
>errorInfo: [VM_MISSING_PV_DRIVERS,
> OpaqueRef:da164d58-b78f-965d-2726-5507f932c81a]
> otherConfig: {}
>subtaskOf: com.xensource.xenapi.Task@aaf13f6f
> subtasks: []
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.checkForSuccess(CitrixResourceBase.java:3190)
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.migrateVM(CitrixResourceBase.java:3343)
> Observed behavior:
> =
> Full exception is seen on the UI.
> Expected behavior:
> =
> A proper non-generic error message should be displayed on the screen instead
> of an exception.
> This is applicable to other scenarios where the exception is printed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7940) Exception printed completely on the UI. Not in a readable format
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14217690#comment-14217690
]
ASF subversion and git services commented on CLOUDSTACK-7940:
-
Commit dda29949366f16c06445dde9161c3b1151ed3f36 in cloudstack's branch
refs/heads/master from [~sanjay.tripathi]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dda2994 ]
CLOUDSTACK-7940: Exception printed completely on the UI. Not in a readable
format.
> Exception printed completely on the UI. Not in a readable format
>
>
> Key: CLOUDSTACK-7940
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7940
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.5.0
>Reporter: Sanjay Tripathi
>Assignee: Sanjay Tripathi
> Fix For: 4.6.0
>
> Attachments: screenshot-1.png
>
>
> Steps:
> ===
> 1. Brought up a setup with 2 host and installed a windows 2012 VM (VM did not
> have the tools installed at this point of time)
> 2. Migrated the VM to another host and observed the following exception on
> the UI.
> [Please see the attached screenshot.]
> 2014-11-10 06:13:38,432 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-374:ctx-dde7176f) Unable to migrate VM(i-2-6-VM) from
> host(689bc2d8-f9f1-48d4-ad13-a35605ea005c) due to Task failed! Task record:
> uuid: 75321ebd-30eb-32db-fb09-1db3fa0af65d
>nameLabel: Async.VM.pool_migrate
> nameDescription:
>allowedOperations: []
>currentOperations: {}
> created: Mon Nov 10 06:13:37 UTC 2014
> finished: Mon Nov 10 06:13:37 UTC 2014
> status: failure
> residentOn: com.xensource.xenapi.Host@f8cb719f
> progress: 1.0
> type:
> result:
>errorInfo: [VM_MISSING_PV_DRIVERS,
> OpaqueRef:da164d58-b78f-965d-2726-5507f932c81a]
> otherConfig: {}
>subtaskOf: com.xensource.xenapi.Task@aaf13f6f
> subtasks: []
> Task failed! Task record: uuid:
> 75321ebd-30eb-32db-fb09-1db3fa0af65d
>nameLabel: Async.VM.pool_migrate
> nameDescription:
>allowedOperations: []
>currentOperations: {}
> created: Mon Nov 10 06:13:37 UTC 2014
> finished: Mon Nov 10 06:13:37 UTC 2014
> status: failure
> residentOn: com.xensource.xenapi.Host@f8cb719f
> progress: 1.0
> type:
> result:
>errorInfo: [VM_MISSING_PV_DRIVERS,
> OpaqueRef:da164d58-b78f-965d-2726-5507f932c81a]
> otherConfig: {}
>subtaskOf: com.xensource.xenapi.Task@aaf13f6f
> subtasks: []
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.checkForSuccess(CitrixResourceBase.java:3190)
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.migrateVM(CitrixResourceBase.java:3343)
> Observed behavior:
> =
> Full exception is seen on the UI.
> Expected behavior:
> =
> A proper non-generic error message should be displayed on the screen instead
> of an exception.
> This is applicable to other scenarios where the exception is printed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7941) CloudStack should log IP address of actual client even if a ReverseProxy is there
Saksham Srivastava created CLOUDSTACK-7941: -- Summary: CloudStack should log IP address of actual client even if a ReverseProxy is there Key: CLOUDSTACK-7941 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7941 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Saksham Srivastava Assignee: Saksham Srivastava Fix For: 4.5.0 In certain deployments there could be a reverse proxy in front of CloudStack. The event log "USER.LOGIN" is shown as 'user has logged in from IP Address x.x.x.x'. The IP address 'x.x.x.x' is the IP of the reverse proxy. In most deployments the reverse proxy/LB will add a HTTP header(X-Forwarded-For, HTTP_CLIENT_IP, HTTP_X_FORWARDED_FOR, Remote_Addr) to the request. CloudStack should try to get the correct client IP using these headers. This support must be added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7941) CloudStack should log IP address of actual client even if a ReverseProxy is there
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14217709#comment-14217709 ] ASF subversion and git services commented on CLOUDSTACK-7941: - Commit f0a4a639de231929bd63f673c4d6adc6bfb5ca80 in cloudstack's branch refs/heads/master from [~saksham] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f0a4a63 ] CLOUDSTACK-7941: CloudStack should log IP address of actual client even if a ReverseProxy is there > CloudStack should log IP address of actual client even if a ReverseProxy is > there > - > > Key: CLOUDSTACK-7941 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7941 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: Saksham Srivastava >Assignee: Saksham Srivastava > Fix For: 4.5.0 > > > In certain deployments there could be a reverse proxy in front of CloudStack. > The event log "USER.LOGIN" is shown as 'user has logged in from IP Address > x.x.x.x'. The IP address 'x.x.x.x' is the IP of the reverse proxy. > In most deployments the reverse proxy/LB will add a HTTP > header(X-Forwarded-For, HTTP_CLIENT_IP, HTTP_X_FORWARDED_FOR, Remote_Addr) to > the request. > CloudStack should try to get the correct client IP using these headers. > This support must be added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7941) CloudStack should log IP address of actual client even if a ReverseProxy is there
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saksham Srivastava resolved CLOUDSTACK-7941. Resolution: Fixed > CloudStack should log IP address of actual client even if a ReverseProxy is > there > - > > Key: CLOUDSTACK-7941 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7941 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: Saksham Srivastava >Assignee: Saksham Srivastava > Fix For: 4.5.0 > > > In certain deployments there could be a reverse proxy in front of CloudStack. > The event log "USER.LOGIN" is shown as 'user has logged in from IP Address > x.x.x.x'. The IP address 'x.x.x.x' is the IP of the reverse proxy. > In most deployments the reverse proxy/LB will add a HTTP > header(X-Forwarded-For, HTTP_CLIENT_IP, HTTP_X_FORWARDED_FOR, Remote_Addr) to > the request. > CloudStack should try to get the correct client IP using these headers. > This support must be added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7752) Management Server goes in infinite loop while creating a vm with tagged local data disk when the pool is not tagged
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14217744#comment-14217744 ] ASF subversion and git services commented on CLOUDSTACK-7752: - Commit 5b620951a399188bd956f1198cd35d96b4008862 in cloudstack's branch refs/heads/4.4 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5b62095 ] CLOUDSTACK-7752: Fixed deployment planner stuck in infinite loop. If we create VM with shared service offering and attach disk with local disk offering, and one of storage pool is full(cannot be allocated) and other is not full then we are not putting the cluster in avoid list which is causing this infinite loop. Fixed by putting the cluster in avoid list even if one of the storage pool is full(cannot be allocated) Signed-off-by: Daan Hoogland > Management Server goes in infinite loop while creating a vm with tagged local > data disk when the pool is not tagged > --- > > Key: CLOUDSTACK-7752 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7752 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar >Priority: Critical > > Steps to reproduce: > Setup must have a single cluster with both local and shared storage. > 1) Create a local disk offering and tag it T1 > 2) Deploy vm with shared root disk and local data disk > Management server goes in an infinite loop. The vm is never started/expunged. > Also this causes vmops.log size to go very high. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7940) Exception printed completely on the UI. Not in a readable format
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sanjay Tripathi resolved CLOUDSTACK-7940.
-
Resolution: Fixed
> Exception printed completely on the UI. Not in a readable format
>
>
> Key: CLOUDSTACK-7940
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7940
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.5.0
>Reporter: Sanjay Tripathi
>Assignee: Sanjay Tripathi
> Fix For: 4.6.0
>
> Attachments: screenshot-1.png
>
>
> Steps:
> ===
> 1. Brought up a setup with 2 host and installed a windows 2012 VM (VM did not
> have the tools installed at this point of time)
> 2. Migrated the VM to another host and observed the following exception on
> the UI.
> [Please see the attached screenshot.]
> 2014-11-10 06:13:38,432 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-374:ctx-dde7176f) Unable to migrate VM(i-2-6-VM) from
> host(689bc2d8-f9f1-48d4-ad13-a35605ea005c) due to Task failed! Task record:
> uuid: 75321ebd-30eb-32db-fb09-1db3fa0af65d
>nameLabel: Async.VM.pool_migrate
> nameDescription:
>allowedOperations: []
>currentOperations: {}
> created: Mon Nov 10 06:13:37 UTC 2014
> finished: Mon Nov 10 06:13:37 UTC 2014
> status: failure
> residentOn: com.xensource.xenapi.Host@f8cb719f
> progress: 1.0
> type:
> result:
>errorInfo: [VM_MISSING_PV_DRIVERS,
> OpaqueRef:da164d58-b78f-965d-2726-5507f932c81a]
> otherConfig: {}
>subtaskOf: com.xensource.xenapi.Task@aaf13f6f
> subtasks: []
> Task failed! Task record: uuid:
> 75321ebd-30eb-32db-fb09-1db3fa0af65d
>nameLabel: Async.VM.pool_migrate
> nameDescription:
>allowedOperations: []
>currentOperations: {}
> created: Mon Nov 10 06:13:37 UTC 2014
> finished: Mon Nov 10 06:13:37 UTC 2014
> status: failure
> residentOn: com.xensource.xenapi.Host@f8cb719f
> progress: 1.0
> type:
> result:
>errorInfo: [VM_MISSING_PV_DRIVERS,
> OpaqueRef:da164d58-b78f-965d-2726-5507f932c81a]
> otherConfig: {}
>subtaskOf: com.xensource.xenapi.Task@aaf13f6f
> subtasks: []
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.checkForSuccess(CitrixResourceBase.java:3190)
> at
> com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.migrateVM(CitrixResourceBase.java:3343)
> Observed behavior:
> =
> Full exception is seen on the UI.
> Expected behavior:
> =
> A proper non-generic error message should be displayed on the screen instead
> of an exception.
> This is applicable to other scenarios where the exception is printed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7680) Adding kwargs to volume.upload in base.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra closed CLOUDSTACK-7680. - Resolution: Fixed > Adding kwargs to volume.upload in base.py > - > > Key: CLOUDSTACK-7680 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7680 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Reporter: prashant kumar mishra >Assignee: prashant kumar mishra > > modifying volume.upload to take number of parameter like checksum, projectid, > magestoreuuid, diskofferingid etc -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7752) Management Server goes in infinite loop while creating a vm with tagged local data disk when the pool is not tagged
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14217773#comment-14217773 ] ASF subversion and git services commented on CLOUDSTACK-7752: - Commit 14e048dadabba67d09f85d12019fcd39b8b47db1 in cloudstack's branch refs/heads/4.3 from [~anshulg] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=14e048d ] CLOUDSTACK-7752: Fixed deployment planner stuck in infinite loop. If we create VM with shared service offering and attach disk with local disk offering, and one of storage pool is full(cannot be allocated) and other is not full then we are not putting the cluster in avoid list which is causing this infinite loop. Fixed by putting the cluster in avoid list even if one of the storage pool is full(cannot be allocated) Signed-off-by: Daan Hoogland > Management Server goes in infinite loop while creating a vm with tagged local > data disk when the pool is not tagged > --- > > Key: CLOUDSTACK-7752 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7752 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar >Priority: Critical > > Steps to reproduce: > Setup must have a single cluster with both local and shared storage. > 1) Create a local disk offering and tag it T1 > 2) Deploy vm with shared root disk and local data disk > Management server goes in an infinite loop. The vm is never started/expunged. > Also this causes vmops.log size to go very high. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7579) Adding a method to base.py to update storage pool
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra closed CLOUDSTACK-7579. - Resolution: Fixed > Adding a method to base.py to update storage pool > - > > Key: CLOUDSTACK-7579 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7579 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Reporter: prashant kumar mishra >Assignee: prashant kumar mishra > > Adding a method to base.py to update storage pool -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7632) Automation for volume life cycle testPath
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra resolved CLOUDSTACK-7632. --- Resolution: Fixed > Automation for volume life cycle testPath > - > > Key: CLOUDSTACK-7632 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7632 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Reporter: prashant kumar mishra >Assignee: prashant kumar mishra > > write automation for volume life cycle testcPath1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-6811) Allocated capacity is greater than the total capacity for primary storage with overprovisioning 1
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saksham Srivastava updated CLOUDSTACK-6811: --- Fix Version/s: (was: 4.5.0) 4.6.0 > Allocated capacity is greater than the total capacity for primary storage > with overprovisioning 1 > - > > Key: CLOUDSTACK-6811 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6811 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.4.0 >Reporter: prashant kumar mishra >Assignee: Saksham Srivastava > Fix For: 4.6.0 > > Attachments: Logs_DB.rar > > > steps to repo > === > 1-add two primary storage to a cluster say pm1(40GB) pm2(20GB) > 2-set over provisioning factor 4 for pm1 and 1 for pm2 > 3-add a volume of size 40 gb pm1 > 4-migrate volume to pm2 > 5-check the allocated and available size for ps2 > expected > > with over provisioning 1 allocated should never be more that available > Actual > = > allocated is >> available -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-856) [DOC] Document CPU and memory overcommit functionality.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra resolved CLOUDSTACK-856. -- Resolution: Fixed > [DOC] Document CPU and memory overcommit functionality. > > > Key: CLOUDSTACK-856 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-856 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: David Nalley >Assignee: prashant kumar mishra > Fix For: 4.3.0 > > > Document CPU and memory overcommit functionality -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7942) test_templates.TestTemplates.test_04_template_from_snapshot failing with account permission issue
Ashutosk Kelkar created CLOUDSTACK-7942: --- Summary: test_templates.TestTemplates.test_04_template_from_snapshot failing with account permission issue Key: CLOUDSTACK-7942 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7942 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Fix For: 4.5.0 Execute cmd: deployvirtualmachine failed, due to: errorCode: 531, errorText:Acct[e5335eee-442a-4f5d-a00f-fc501b172073-test-TestTemplates-test_01_create_template-6FKH7G] does not have permission to operate with resource Acct[f95f972e-6e19-11e4-a8a4-f661c2db1170-admin] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3952) Persist VR nic details in DB for additional public ranges
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala updated CLOUDSTACK-3952: -- Fix Version/s: (was: 4.5.0) (was: 4.4.0) Future > Persist VR nic details in DB for additional public ranges > - > > Key: CLOUDSTACK-3952 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3952 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Reporter: Kishan Kavala >Assignee: Kishan Kavala > Fix For: Future > > > For non-vpcs VR, nics are dynamically created for addtional IP ranges with > different Vlan. Prepare fro migration doesn't setup the destination host > correctly due to this and migration fails. > Temporary workaround was added as part of CLOUDSTACK-3439 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7700) Volume Snapshot Async Job returns Success for a failed operation
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen updated CLOUDSTACK-7700:
-
Description:
Setup :
Single zone , two clusters , one host in each cluster , have cluster wide
storages and one zone wide primary storage
Steps:
1. Install and configure Adv zone with Vmware 5.5.
2. Deploy VM with DATA disk using Zonewide storage tagged offering and ensure
that root and data disk of this VM are placed in ZWPS
3. Stop the VM and Try to create Volume snapshots till it gets failed.
Observation:
1. It failed to create snapshot due to some temporary network issues .
But It is returning success for a failed operation.
2014-10-13 17:39:52,365 DEBUG [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37 ctx-14ac0075) Done executing
VM work job: com.cloud.storage.VmWorkTakeVolumeSnapshot
{"volumeId":4,"policyId":0,"snapshotId":7,"quiesceVm":false,"userId":2,"accountId":3,"vmId":3,"handlerName":"VolumeApiServiceImpl"}
2014-10-13 17:39:52,365 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37 ctx-14ac0075) Complete async
job-37, jobStatus: SUCCEEDED, resultCode: 0, result:
rO0ABXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAABw
2014-10-13 17:39:52,375 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Done with run of VM work job:
com.cloud.storage.VmWorkTakeVolumeSnapshot for VM 3, job origin: 36
2014-10-13 17:39:52,375 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Done executing
com.cloud.storage.VmWorkTakeVolumeSnapshot for job-37
2014-10-13 17:39:52,392 DEBUG [o.a.c.f.j.i.SyncQueueManagerImpl]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Sync queue (3) is currently
empty
2014-10-13 17:39:52,393 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Remove job-37 from job
monitoring
2014-10-13 17:39:52,395 DEBUG [c.c.a.ApiResponseHelper]
(API-Job-Executor-21:ctx-d9e77f3d job-36 ctx-16075f77) Unable to find info for
image store snapshot with uuid 91fec32b-77f1-42af-909d-acca69772581
2014-10-13 17:39:52,396 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-21:ctx-d9e77f3d job-36 ctx-16075f77) Complete async job-36,
jobStatus: SUCCEEDED, resultCode: 0, result:
org.apache.cloudstack.api.response.SnapshotResponse/snapshot/
{"id":"91fec32b-77f1-42af-909d-acca69772581","account":"cdcuser1","domainid":"0dc68c16-49d3-47ef-9ae2-40e043d3fe81","domain":"cdc","snapshottype":"MANUAL","volumeid":"5097706f-97d6-4133-b010-3c803bca66cf","volumename":"DATA-3","volumetype":"DATADISK","created":"2014-10-13T17:39:43+0530","name":"cdcuserinst1_DATA-3_20141013120943","intervaltype":"MANUAL","state":"Error","tags":[],"revertable":false}
2014-10-13 17:39:52,417 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-21:ctx-d9e77f3d job-36) Done executing
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-36
was:
Setup :
Single zone , two clusters , one host in each cluster , have cluster wide
storages and one zone wide primary storage
Steps:
1. Install and configure Adv zone with Vmware 5.5 and CCP 4.3.0.1 setup
2. Deploy VM with DATA disk using Zonewide storage tagged offering and ensure
that root and data disk of this VM are placed in ZWPS
3. Stop the VM and Try to create Volume snapshots till it gets failed.
Observation:
1. It failed to create snapshot due to some temporary network issues .
But It is returning success for a failed operation.
2014-10-13 17:39:52,365 DEBUG [c.c.v.VmWorkJobHandlerProxy]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37 ctx-14ac0075) Done executing
VM work job: com.cloud.storage.VmWorkTakeVolumeSnapshot
{"volumeId":4,"policyId":0,"snapshotId":7,"quiesceVm":false,"userId":2,"accountId":3,"vmId":3,"handlerName":"VolumeApiServiceImpl"}
2014-10-13 17:39:52,365 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37 ctx-14ac0075) Complete async
job-37, jobStatus: SUCCEEDED, resultCode: 0, result:
rO0ABXNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAABw
2014-10-13 17:39:52,375 DEBUG [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Done with run of VM work job:
com.cloud.storage.VmWorkTakeVolumeSnapshot for VM 3, job origin: 36
2014-10-13 17:39:52,375 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Done executing
com.cloud.storage.VmWorkTakeVolumeSnapshot for job-37
2014-10-13 17:39:52,392 DEBUG [o.a.c.f.j.i.SyncQueueManagerImpl]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Sync queue (3) is currently
empty
2014-10-13 17:39:52,393 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Work-Job-Executor-12:ctx-9c1911cf job-36/job-37) Remove job-37
[jira] [Updated] (CLOUDSTACK-7746) Baremetal related script erros seen on router console
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] frank zhang updated CLOUDSTACK-7746: Assignee: Harikrishna Patnala (was: frank zhang) > Baremetal related script erros seen on router console > - > > Key: CLOUDSTACK-7746 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7746 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: Build from master >Reporter: Sangeetha Hariharan >Assignee: Harikrishna Patnala >Priority: Critical > Fix For: 4.5.0 > > Attachments: router.png > > > Baremetal related script erros seen on router console. > Advanced zone set up with 3 xenserver hosts in a cluster. > When logging into the console view of router , following script errors are > seen: > /opt/cloud/bin/baremetal-vr.py:159: SyntaxWarning : name 'server' is assigned > to before glocal declaration. .. > Attached is the screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7746) Baremetal related script erros seen on router console
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218403#comment-14218403 ] frank zhang commented on CLOUDSTACK-7746: - reassign to Hari. please close it after fixing the template > Baremetal related script erros seen on router console > - > > Key: CLOUDSTACK-7746 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7746 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: Build from master >Reporter: Sangeetha Hariharan >Assignee: Harikrishna Patnala >Priority: Critical > Fix For: 4.5.0 > > Attachments: router.png > > > Baremetal related script erros seen on router console. > Advanced zone set up with 3 xenserver hosts in a cluster. > When logging into the console view of router , following script errors are > seen: > /opt/cloud/bin/baremetal-vr.py:159: SyntaxWarning : name 'server' is assigned > to before glocal declaration. .. > Attached is the screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7943) UI > storage > volume > create template action > add "XenServer Tools Version 6.1+" checkbox.
Jessica Wang created CLOUDSTACK-7943: Summary: UI > storage > volume > create template action > add "XenServer Tools Version 6.1+" checkbox. Key: CLOUDSTACK-7943 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7943 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 Priority: Critical -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7618) Baremetal - AddHost() API docs should include parameters - cpunumber,cpuspeed,memory,hostmac
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218410#comment-14218410 ] frank zhang commented on CLOUDSTACK-7618: - This is some architecture flaw that cannot be fixed in 4.5 CloudStack API doesn't provide a way that accepts extra parameters. Back to 3 years ago when baremetal was initially designed, the extra parameters cpunumber,cpuspeed,memory,hostmac were passed in as query parameters in URL, and baremetal discoverer will parse these parameters by itself; this make API doc generation code will not be aware of these parameters' existence. To fix it, we need to either build a new API doc generator or introduce new API that has these parameters as class field. Given the design change, I suggest putting off this bug to next release, as it won't effect any CloudStack functionality. > Baremetal - AddHost() API docs should include parameters - > cpunumber,cpuspeed,memory,hostmac > > > Key: CLOUDSTACK-7618 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7618 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Sangeetha Hariharan >Assignee: frank zhang > Fix For: 4.5.0 > > > Baremetal - AddHost() API docs should include parameters - > cpunumber,cpuspeed,memory,hostmac. > When adding a baremetal host , following 4 parameters are supported for > addHost() API call - cpunumber,cpuspeed,memory,hostmac. > API docs should include information about these parameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7618) Baremetal - AddHost() API docs should include parameters - cpunumber,cpuspeed,memory,hostmac
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] frank zhang updated CLOUDSTACK-7618: Affects Version/s: (was: 4.5.0) 4.6.0 > Baremetal - AddHost() API docs should include parameters - > cpunumber,cpuspeed,memory,hostmac > > > Key: CLOUDSTACK-7618 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7618 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Sangeetha Hariharan >Assignee: frank zhang > Fix For: 4.6.0 > > > Baremetal - AddHost() API docs should include parameters - > cpunumber,cpuspeed,memory,hostmac. > When adding a baremetal host , following 4 parameters are supported for > addHost() API call - cpunumber,cpuspeed,memory,hostmac. > API docs should include information about these parameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7618) Baremetal - AddHost() API docs should include parameters - cpunumber,cpuspeed,memory,hostmac
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] frank zhang updated CLOUDSTACK-7618: Fix Version/s: (was: 4.5.0) 4.6.0 > Baremetal - AddHost() API docs should include parameters - > cpunumber,cpuspeed,memory,hostmac > > > Key: CLOUDSTACK-7618 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7618 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.6.0 >Reporter: Sangeetha Hariharan >Assignee: frank zhang > Fix For: 4.6.0 > > > Baremetal - AddHost() API docs should include parameters - > cpunumber,cpuspeed,memory,hostmac. > When adding a baremetal host , following 4 parameters are supported for > addHost() API call - cpunumber,cpuspeed,memory,hostmac. > API docs should include information about these parameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7943) UI > storage > volume > create template action > add "XenServer Tools Version 6.1+" checkbox.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218414#comment-14218414 ] ASF subversion and git services commented on CLOUDSTACK-7943: - Commit fee6664612b977ffcce2130eb8a36cf1cf109926 in cloudstack's branch refs/heads/4.5 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fee6664 ] CLOUDSTACK-7943: UI > dialog widget > checkbox field > isChecked property > if isChecked property is a funciton, pass "args" along when calling isChecked() function. > UI > storage > volume > create template action > add "XenServer Tools Version > 6.1+" checkbox. > - > > Key: CLOUDSTACK-7943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7943 > 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 >Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7943) UI > storage > volume > create template action > add "XenServer Tools Version 6.1+" checkbox.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218416#comment-14218416 ] ASF subversion and git services commented on CLOUDSTACK-7943: - Commit 2c9310e62210e98ec5584041681a484c2320ef59 in cloudstack's branch refs/heads/4.5 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2c9310e ] CLOUDSTACK-7943: UI > storage > volume > create template action > add "XenServer Tools Version 6.1+" checkbox. Default it as its VM's "XenServer Tools Version 6.1+" property. > UI > storage > volume > create template action > add "XenServer Tools Version > 6.1+" checkbox. > - > > Key: CLOUDSTACK-7943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7943 > 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 >Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7943) UI > storage > volume > create template action > add "XenServer Tools Version 6.1+" checkbox.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218418#comment-14218418 ] ASF subversion and git services commented on CLOUDSTACK-7943: - Commit b11380eebe6bd5af62f88de8853028200528b77b in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b11380e ] CLOUDSTACK-7943: UI > dialog widget > checkbox field > isChecked property > if isChecked property is a funciton, pass "args" along when calling isChecked() function. > UI > storage > volume > create template action > add "XenServer Tools Version > 6.1+" checkbox. > - > > Key: CLOUDSTACK-7943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7943 > 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 >Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7943) UI > storage > volume > create template action > add "XenServer Tools Version 6.1+" checkbox.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218419#comment-14218419 ] ASF subversion and git services commented on CLOUDSTACK-7943: - Commit 7b6f49617d35ccbb237a8ba36424e987b5b23a3b in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7b6f496 ] CLOUDSTACK-7943: UI > storage > volume > create template action > add "XenServer Tools Version 6.1+" checkbox. Default it as its VM's "XenServer Tools Version 6.1+" property. > UI > storage > volume > create template action > add "XenServer Tools Version > 6.1+" checkbox. > - > > Key: CLOUDSTACK-7943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7943 > 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 >Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7943) UI > storage > volume > create template action > add "XenServer Tools Version 6.1+" checkbox.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-7943: - Fix Version/s: 4.5.0 > UI > storage > volume > create template action > add "XenServer Tools Version > 6.1+" checkbox. > - > > Key: CLOUDSTACK-7943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7943 > 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 >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7943) UI > storage > volume > create template action > add "XenServer Tools Version 6.1+" checkbox.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-7943. -- Resolution: Fixed > UI > storage > volume > create template action > add "XenServer Tools Version > 6.1+" checkbox. > - > > Key: CLOUDSTACK-7943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7943 > 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 >Priority: Critical > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7943) UI > storage > volume > create template action > add "XenServer Tools Version 6.1+" checkbox.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang closed CLOUDSTACK-7943. > UI > storage > volume > create template action > add "XenServer Tools Version > 6.1+" checkbox. > - > > Key: CLOUDSTACK-7943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7943 > 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 >Priority: Critical > Fix For: 4.5.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7943) UI > storage > volume > create template action > add "XenServer Tools Version 6.1+" checkbox.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-7943: - Attachment: after_checked_in_UI_change_2.PNG after_checked_in_UI_change_1.PNG > UI > storage > volume > create template action > add "XenServer Tools Version > 6.1+" checkbox. > - > > Key: CLOUDSTACK-7943 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7943 > 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 >Priority: Critical > Fix For: 4.5.0 > > Attachments: after_checked_in_UI_change_1.PNG, > after_checked_in_UI_change_2.PNG > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7383) [LXC][UI] dont show vm snapshot button in UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang reassigned CLOUDSTACK-7383: Assignee: shweta agarwal (was: Jessica Wang) shweta, I'm unable to reproduce this bug in my environment. Please provide your database dump. Jessica > [LXC][UI] dont show vm snapshot button in UI > > > Key: CLOUDSTACK-7383 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7383 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: shweta agarwal >Priority: Critical > Fix For: 4.5.0 > > Attachments: lxc.png, vmsnap.png > > > Repro steps: > Vm snapshot is not supported in LXC so we should not show VM snapshot option > in UI in instance tab , the way we do it for KVM .We dont show VM snapshot > button in cae of KVM vm. > Attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7383) [LXC][UI] dont show vm snapshot button in UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218590#comment-14218590 ] Jessica Wang edited comment on CLOUDSTACK-7383 at 11/19/14 10:21 PM: - shweta, I'm unable to reproduce this bug in my environment. Please provide: (1) your database dump. (2) steps to reproduce. e.g. (i) log in as "admin/password" (ii) UI > Instances > click instance "???" > detail panel > see "Take Snapshot" option and "View Snapshots" link. Jessica was (Author: jessicawang): shweta, I'm unable to reproduce this bug in my environment. Please provide your database dump. Jessica > [LXC][UI] dont show vm snapshot button in UI > > > Key: CLOUDSTACK-7383 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7383 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: shweta agarwal >Priority: Critical > Fix For: 4.5.0 > > Attachments: lxc.png, vmsnap.png > > > Repro steps: > Vm snapshot is not supported in LXC so we should not show VM snapshot option > in UI in instance tab , the way we do it for KVM .We dont show VM snapshot > button in cae of KVM vm. > Attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7604) [Automation] NPE during deletion of Volume
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Xu resolved CLOUDSTACK-7604.
Resolution: Cannot Reproduce
please reopen when you see this again
> [Automation] NPE during deletion of Volume
> --
>
> Key: CLOUDSTACK-7604
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7604
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test, Volumes
>Affects Versions: 4.5.0
>Reporter: Chandan Purushothama
>Assignee: Anthony Xu
>Priority: Critical
> Fix For: 4.5.0
>
> Attachments: management-server.zip
>
>
> *Null Pointer Exception:*
> {noformat}
> 2014-09-21 16:19:44,090 DEBUG [c.c.v.UserVmManagerImpl]
> (API-Job-Executor-16:ctx-3978d571 job-3320 ctx-d788d20d) Removed vm id=325
> from all load balancers as a part of expunge process
> 2014-09-21 16:19:44,091 DEBUG [c.c.v.UserVmManagerImpl]
> (API-Job-Executor-16:ctx-3978d571 job-3320 ctx-d788d20d) Successfully cleaned
> up vm VM[User|i-163-325-VM] resources as a part of expunge process
> 2014-09-21 16:19:44,098 INFO [c.c.s.VolumeApiServiceImpl]
> (API-Job-Executor-16:ctx-3978d571 job-3320 ctx-d788d20d) Expunging volume 362
> from primary data store
> 2014-09-21 16:19:44,116 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-16:ctx-3978d571 job-3320 ctx-d788d20d) Seq
> 1-5202783469519768584: Sending { Cmd , MgmtId: 16226561876200, via:
> 1(xrtuk-02-05), Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.DeleteCommand":{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"53c820f0-13f4-4fcf-8bf5-ccb2967453a5","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"3161f583-6550-363c-9d0b-44aede011126","id":1,"poolType":"NetworkFilesystem","host":"10.81.24.13","path":"/vol/xenrtnfs/836249-z1NhU1","port":2049,"url":"NetworkFilesystem://10.81.24.13/vol/xenrtnfs/836249-z1NhU1/?ROLE=Primary&STOREUUID=3161f583-6550-363c-9d0b-44aede011126"}},"name":"ROOT-320","size":5368709120,"path":"827d2dae-4b86-4e75-a298-084d70553395","volumeId":362,"accountId":163,"format":"VHD","provisioningType":"THIN","id":362,"hypervisorType":"XenServer"}},"wait":0}}]
> }
> 2014-09-21 16:19:44,117 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-16:ctx-3978d571 job-3320 ctx-d788d20d) Seq
> 1-5202783469519768584: Executing: { Cmd , MgmtId: 16226561876200, via:
> 1(xrtuk-02-05), Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.DeleteCommand":{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"53c820f0-13f4-4fcf-8bf5-ccb2967453a5","volumeType":"DATADISK","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"3161f583-6550-363c-9d0b-44aede011126","id":1,"poolType":"NetworkFilesystem","host":"10.81.24.13","path":"/vol/xenrtnfs/836249-z1NhU1","port":2049,"url":"NetworkFilesystem://10.81.24.13/vol/xenrtnfs/836249-z1NhU1/?ROLE=Primary&STOREUUID=3161f583-6550-363c-9d0b-44aede011126"}},"name":"ROOT-320","size":5368709120,"path":"827d2dae-4b86-4e75-a298-084d70553395","volumeId":362,"accountId":163,"format":"VHD","provisioningType":"THIN","id":362,"hypervisorType":"XenServer"}},"wait":0}}]
> }
> 2014-09-21 16:19:44,117 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-273:ctx-25b5c023) Seq 1-5202783469519768584: Executing request
> 2014-09-21 16:19:44,236 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-7:ctx-2837c726) ===START=== 10.81.29.29 -- GET
> jobid=908d3367-c7db-4bdd-90d6-ebaff799ecd3&apiKey=mLrTCdYRf3-d4xO7DnO-QXw1Uqrdae1uxenHTEPj_ulDpIYTaujsXwkNzARz222s6M4xChsTAE2W-TUur5bKNQ&command=queryAsyncJobResult&response=json&signature=TgBQLMCJxcuRj%2BNOZFHatiLZSzw%3D
> 2014-09-21 16:19:44,253 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-7:ctx-2837c726 ctx-8f7c1e09 ctx-c08f5999) ===END===
> 10.81.29.29 -- GET
> jobid=908d3367-c7db-4bdd-90d6-ebaff799ecd3&apiKey=mLrTCdYRf3-d4xO7DnO-QXw1Uqrdae1uxenHTEPj_ulDpIYTaujsXwkNzARz222s6M4xChsTAE2W-TUur5bKNQ&command=queryAsyncJobResult&response=json&signature=TgBQLMCJxcuRj%2BNOZFHatiLZSzw%3D
> 2014-09-21 16:19:44,517 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-273:ctx-25b5c023) Seq 1-5202783469519768584: Response Received:
> 2014-09-21 16:19:44,517 DEBUG [c.c.a.t.Request]
> (DirectAgent-273:ctx-25b5c023) Seq 1-5202783469519768584: Processing: { Ans:
> , MgmtId: 16226561876200, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":true,"wait":0}}] }
> 2014-09-21 16:19:44,517 DEBUG [c.c.a.t.Request]
> (API-Job-Executor-16:ctx-3978d571 job-3320 ctx-d788d20d) Seq
> 1-5202783469519768584: Received: { Ans: , MgmtId: 16226561876200, via: 1,
> Ver: v1, Flags: 10, { Answer } }
> 2014-09-21 16:19:44,524 INFO [o.a.c.s.v.Volu
[jira] [Created] (CLOUDSTACK-7944) IPv6 deployment failure
Sheng Yang created CLOUDSTACK-7944: -- Summary: IPv6 deployment failure Key: CLOUDSTACK-7944 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7944 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Sheng Yang Assignee: Sheng Yang Priority: Blocker Fix For: 4.5.0 Recently I found I failed to deploy VM in ipv6 network. The following exception showed: com.cloud.exception.AgentUnavailableException: Resource [Host:1] is unreachable: Host 1: Unable to start instance due to Unable to start VM[DomainRouter|r-11-VM] due to error in finalizeStart, not retrying at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1106) at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4436) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) at com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4592) at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103) at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:536) 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 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:493) 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:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) Caused by: com.cloud.utils.exception.ExecutionException: Unable to start VM[DomainRouter|r-11-VM] due to error in finalizeStart, not retrying at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1070) ... 21 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7944) IPv6 deployment failure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218644#comment-14218644 ] Sheng Yang commented on CLOUDSTACK-7944: After dig into it, I found the reason is due to sysctl.conf. cloud-early-config and procps are at same priority during booting up. If procps was after cloud-early-config, the sysctl config cloud-early-config did would be override, though if procps was loaded before cloud-early-config, it would be fine. > IPv6 deployment failure > --- > > Key: CLOUDSTACK-7944 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7944 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Blocker > Fix For: 4.5.0 > > > Recently I found I failed to deploy VM in ipv6 network. > The following exception showed: > com.cloud.exception.AgentUnavailableException: Resource [Host:1] is > unreachable: Host 1: Unable to start instance due to Unable to start > VM[DomainRouter|r-11-VM] due to error in finalizeStart, not retrying > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1106) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4436) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4592) > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:536) > 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 > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:493) > 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:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > Caused by: com.cloud.utils.exception.ExecutionException: Unable to start > VM[DomainRouter|r-11-VM] due to error in finalizeStart, not retrying > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1070) > ... 21 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7944) IPv6 deployment failure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218648#comment-14218648 ] ASF subversion and git services commented on CLOUDSTACK-7944: - Commit 50b262e02a898a1aafc592d9f72cd8a3b6b272ff in cloudstack's branch refs/heads/4.5 from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=50b262e ] CLOUDSTACK-7944: Ensure ipv6 is enabled in sysctl.conf The booting sequence result in change of IPv6 related sysctl options was overrided by sysctl.conf which is loaded later. So this patch would patch sysctl.conf in VR as well, ensure IPv6 would be enabled during booting period otherwise the network setup may not work, result in IPv6 VM deployment failure. > IPv6 deployment failure > --- > > Key: CLOUDSTACK-7944 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7944 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Blocker > Fix For: 4.5.0 > > > Recently I found I failed to deploy VM in ipv6 network. > The following exception showed: > com.cloud.exception.AgentUnavailableException: Resource [Host:1] is > unreachable: Host 1: Unable to start instance due to Unable to start > VM[DomainRouter|r-11-VM] due to error in finalizeStart, not retrying > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1106) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4436) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4592) > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:536) > 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 > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:493) > 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:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > Caused by: com.cloud.utils.exception.ExecutionException: Unable to start > VM[DomainRouter|r-11-VM] due to error in finalizeStart, not retrying > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1070) > ... 21 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7944) IPv6 deployment failure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218646#comment-14218646 ] ASF subversion and git services commented on CLOUDSTACK-7944: - Commit bb352da3024844b71dcaacb866c3b464c50408a6 in cloudstack's branch refs/heads/master from [~yasker] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bb352da ] CLOUDSTACK-7944: Ensure ipv6 is enabled in sysctl.conf The booting sequence result in change of IPv6 related sysctl options was overrided by sysctl.conf which is loaded later. So this patch would patch sysctl.conf in VR as well, ensure IPv6 would be enabled during booting period otherwise the network setup may not work, result in IPv6 VM deployment failure. > IPv6 deployment failure > --- > > Key: CLOUDSTACK-7944 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7944 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Blocker > Fix For: 4.5.0 > > > Recently I found I failed to deploy VM in ipv6 network. > The following exception showed: > com.cloud.exception.AgentUnavailableException: Resource [Host:1] is > unreachable: Host 1: Unable to start instance due to Unable to start > VM[DomainRouter|r-11-VM] due to error in finalizeStart, not retrying > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1106) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4436) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4592) > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:536) > 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 > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:493) > 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:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > Caused by: com.cloud.utils.exception.ExecutionException: Unable to start > VM[DomainRouter|r-11-VM] due to error in finalizeStart, not retrying > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1070) > ... 21 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7944) IPv6 deployment failure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sheng Yang resolved CLOUDSTACK-7944. Resolution: Fixed > IPv6 deployment failure > --- > > Key: CLOUDSTACK-7944 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7944 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Sheng Yang >Assignee: Sheng Yang >Priority: Blocker > Fix For: 4.5.0 > > > Recently I found I failed to deploy VM in ipv6 network. > The following exception showed: > com.cloud.exception.AgentUnavailableException: Resource [Host:1] is > unreachable: Host 1: Unable to start instance due to Unable to start > VM[DomainRouter|r-11-VM] due to error in finalizeStart, not retrying > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1106) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4436) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4592) > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:103) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:536) > 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 > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:493) > 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:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > Caused by: com.cloud.utils.exception.ExecutionException: Unable to start > VM[DomainRouter|r-11-VM] due to error in finalizeStart, not retrying > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1070) > ... 21 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-458) xen:snapshots:Storage gc fail to clean the failed snapshot images from secondarystorage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su updated CLOUDSTACK-458: - Fix Version/s: (was: 4.5.0) Future > xen:snapshots:Storage gc fail to clean the failed snapshot images from > secondarystorage > --- > > Key: CLOUDSTACK-458 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-458 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot >Affects Versions: 4.0.0 >Reporter: deepti dohare >Assignee: edison su >Priority: Minor > Fix For: Future > > > After storage cleanup still see the snapshot image oin the secondary storage > snapshot folder for the failure snapshots > In this case : next hourly snapshot was successful but previous snapshot was > stuck in backingupstate > Steps: > *** > 1.Deploy a VM and set concurrent.snapshots.threshold.per host to 2 > 2.Once its successful,schedule the recurring snapshots hourly on the root > volume and also perform snapshot on other instance volumes > 3.configure the storage.cleanup.interval to 150 and restart the > cloud-management service while hourly snapshot on root volume is in progress > 4.check the secondary storage snapshot folder > 5. after few hours,delete all the created snapshots from Cloudstack and check > the storage cleanup thread cleansup all the snapshots form the snapshot > folder or not. > Actual result: > step4:snapshots job failed and secondary storage has copied image file and > database shows snapshot job status as "Backing UP" > next hourly snapshot was successful. > Step5: > It cleans all the successful hourly snapshot images except the failed > snapshot image files > Expected result: > ** > Storage GC should clean all image files exists in the snapshot folder when we > delete the all the snapshots from Cloud stack. > also when previous hourly snapshot stuck in backing up state ,the next hourly > snapshot is successful,Cloudstack should intelligent enough to update the > status of failure jobs properly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3995) No error notification is generated when Primary storage (Zonelevel) is added with wrong path and it is allowed to add
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su updated CLOUDSTACK-3995:
--
Fix Version/s: (was: 4.5.0)
Future
> No error notification is generated when Primary storage (Zonelevel) is added
> with wrong path and it is allowed to add
> -
>
> Key: CLOUDSTACK-3995
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3995
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, VMware
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
>Assignee: edison su
>Priority: Minor
> Fix For: Future
>
> Attachments: apilog.log, management-server.log
>
>
> Steps:
> 1. Configure Adv zone with VMWARE
> 2. Tried to add wrong Zone wide primary storage point
> Observation:
> It is allowed to add with wrong path and there is no failure error
> notification. But in the logs it says storage pool addition failed.
> 2013-08-01 10:11:30,741 DEBUG [cloud.api.ApiServlet] (catalina-exec-17:null)
> ===START=== 10.144.6.19 -- GET
> command=createStoragePool&scope=zone&zoneid=176d7081-e1d2-4472-8a17-eff1322ddd39&hypervisor=VMware&name=wrongzwps1&url=nfs%3A%2F%2F10.102.192.100%2Fcpg_vol%2Fsailaja%2Fwrongzwps1&response=json&sessionkey=x8JP8GtGm4LirW0b8AK9sVj26D0%3D&_=1375332320686
> 2013-08-01 10:11:30,748 DEBUG
> [datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl]
> (catalina-exec-17:null) createPool Params @ scheme - nfs storageHost -
> 10.102.192.100 hostPath - /cpg_vol/sailaja/wrongzwps1 port - -1
> 2013-08-01 10:11:30,763 DEBUG [cloud.storage.StorageManagerImpl]
> (catalina-exec-17:null) Adding pool null to host 1
> 2013-08-01 10:11:30,767 DEBUG [agent.transport.Request]
> (catalina-exec-17:null) Seq 1-757532167: Sending { Cmd , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.ModifyStoragePoolCommand":{"add":true,"pool":{"id":6,"uuid":"8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","host":"10.102.192.100","path":"/cpg_vol/sailaja/wrongzwps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","wait":0}}]
> }
> 2013-08-01 10:11:30,767 DEBUG [agent.transport.Request]
> (catalina-exec-17:null) Seq 1-757532167: Executing: { Cmd , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.ModifyStoragePoolCommand":{"add":true,"pool":{"id":6,"uuid":"8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","host":"10.102.192.100","path":"/cpg_vol/sailaja/wrongzwps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","wait":0}}]
> }
> 2013-08-01 10:11:30,768 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-52:null) Seq 1-757532167: Executing request
> 2013-08-01 10:11:30,768 INFO [vmware.resource.VmwareResource]
> (DirectAgent-52:10.102.192.18) Executing resource ModifyStoragePoolCommand:
> {"add":true,"pool":{"id":6,"uuid":"8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","host":"10.102.192.100","path":"/cpg_vol/sailaja/wrongzwps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","wait":0}
> 2013-08-01 10:11:30,949 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RouterStatusMonitor-1:null) Found 3 routers to update status.
> 2013-08-01 10:11:30,951 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RouterStatusMonitor-1:null) Found 0 networks to update RvR status.
> 2013-08-01 10:11:30,962 INFO [vmware.mo.HostMO]
> (DirectAgent-52:10.102.192.18) Creation of NFS datastore on vCenter failed.
> Details: vCenter API trace - mountDatastore(). target MOR: host-8973, vmfs:
> false, poolHost: 10.102.192.100, poolHostPort: 2049, poolPath:
> /cpg_vol/sailaja/wrongzwps1, poolUuid: 8f4e2b4b76a23f11b98c2ee8108ab900.
> Exception mesg: An error occurred during host configuration.
> 2013-08-01 10:11:30,962 ERROR [vmware.resource.VmwareResource]
> (DirectAgent-52:10.102.192.18) ModifyStoragePoolCommand failed due to
> Exception: java.lang.Exception
> Message: Creation of NFS datastore on vCenter failed.
> java.lang.Exception: Creation of NFS datastore on vCenter failed.
> at
> com.cloud.hypervisor.vmware.mo.HostMO.mountDatastore(HostMO.java:772)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4102)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:472)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executor
[jira] [Updated] (CLOUDSTACK-3896) [PrimaryStorage] deleteStoragePool is not kicking GC for the downloaded system vm templates on Primary Storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su updated CLOUDSTACK-3896: -- Fix Version/s: (was: 4.5.0) Future > [PrimaryStorage] deleteStoragePool is not kicking GC for the downloaded > system vm templates on Primary Storage > -- > > Key: CLOUDSTACK-3896 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3896 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Affects Versions: 4.2.0 > Environment: commit # ca474d0e09f772cb22abf2802a308a2da5351592 >Reporter: venkata swamybabu budumuru >Assignee: edison su >Priority: Minor > Fix For: Future > > Attachments: logs.tgz > > > Steps to reproduce: > 1. Have the latest cloudstack setup with at least 1 advanced zone using > XenServer > 2. make sure that system vm is up and running (which means the system vm is > downloaded to the primary storage) > 3. Disable zone and destroy the system vas > 4. place the primary & secondary storages in maintenance mode. > 5. delete both primary and secondary > # select * from storage_pool where id=12 > *** 9. row *** >id: 12 > name: primaryZone2 > uuid: NULL > pool_type: NetworkFilesystem > port: 2049 >data_center_id: 2 >pod_id: 2 >cluster_id: 2 >used_bytes: 1993387966464 >capacity_bytes: 5902284816384 > host_address: 10.147.28.7 > user_info: NULL > path: /export/home/swamy/primary.campo.xen.1.cluster > created: 2013-07-29 07:19:06 > removed: 2013-07-29 09:14:19 > update_time: NULL >status: Maintenance > storage_provider_name: DefaultPrimary > scope: CLUSTER >hypervisor: NULL > managed: 0 > capacity_iops: NULL > 6. check cloud.template_spool_ref for the above system vm template. > Observations: > (i) template_spool_ref still shows that system vm template as "Ready" > (ii) storage GC didn't happen for the above template. > mysql> select * from template_spool_ref where pool_id=12\G > *** 1. row *** > id: 10 >pool_id: 12 >template_id: 1 >created: 2013-07-29 07:22:12 > last_updated: NULL > job_id: NULL > download_pct: 100 > download_state: DOWNLOADED > error_str: NULL > local_path: 332cedca-b187-4af8-9d0a-ac3379741211 > install_path: 332cedca-b187-4af8-9d0a-ac3379741211 > template_size: 0 > marked_for_gc: 0 > state: Ready > update_count: 2 >updated: 2013-07-29 07:36:24 > 1 row in set (0.00 sec) > (iii) Storage.cleanup.interval is enabled and set to 10 in my setup. > Attaching all the required logs along with db dump to the bug. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-3995) No error notification is generated when Primary storage (Zonelevel) is added with wrong path and it is allowed to add
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edison su updated CLOUDSTACK-3995:
--
Fix Version/s: (was: Future)
4.5.0
> No error notification is generated when Primary storage (Zonelevel) is added
> with wrong path and it is allowed to add
> -
>
> Key: CLOUDSTACK-3995
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3995
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, VMware
>Affects Versions: 4.2.0
>Reporter: Sailaja Mada
>Assignee: edison su
>Priority: Minor
> Fix For: 4.5.0
>
> Attachments: apilog.log, management-server.log
>
>
> Steps:
> 1. Configure Adv zone with VMWARE
> 2. Tried to add wrong Zone wide primary storage point
> Observation:
> It is allowed to add with wrong path and there is no failure error
> notification. But in the logs it says storage pool addition failed.
> 2013-08-01 10:11:30,741 DEBUG [cloud.api.ApiServlet] (catalina-exec-17:null)
> ===START=== 10.144.6.19 -- GET
> command=createStoragePool&scope=zone&zoneid=176d7081-e1d2-4472-8a17-eff1322ddd39&hypervisor=VMware&name=wrongzwps1&url=nfs%3A%2F%2F10.102.192.100%2Fcpg_vol%2Fsailaja%2Fwrongzwps1&response=json&sessionkey=x8JP8GtGm4LirW0b8AK9sVj26D0%3D&_=1375332320686
> 2013-08-01 10:11:30,748 DEBUG
> [datastore.lifecycle.CloudStackPrimaryDataStoreLifeCycleImpl]
> (catalina-exec-17:null) createPool Params @ scheme - nfs storageHost -
> 10.102.192.100 hostPath - /cpg_vol/sailaja/wrongzwps1 port - -1
> 2013-08-01 10:11:30,763 DEBUG [cloud.storage.StorageManagerImpl]
> (catalina-exec-17:null) Adding pool null to host 1
> 2013-08-01 10:11:30,767 DEBUG [agent.transport.Request]
> (catalina-exec-17:null) Seq 1-757532167: Sending { Cmd , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.ModifyStoragePoolCommand":{"add":true,"pool":{"id":6,"uuid":"8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","host":"10.102.192.100","path":"/cpg_vol/sailaja/wrongzwps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","wait":0}}]
> }
> 2013-08-01 10:11:30,767 DEBUG [agent.transport.Request]
> (catalina-exec-17:null) Seq 1-757532167: Executing: { Cmd , MgmtId:
> 187767034175903, via: 1, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.ModifyStoragePoolCommand":{"add":true,"pool":{"id":6,"uuid":"8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","host":"10.102.192.100","path":"/cpg_vol/sailaja/wrongzwps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","wait":0}}]
> }
> 2013-08-01 10:11:30,768 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-52:null) Seq 1-757532167: Executing request
> 2013-08-01 10:11:30,768 INFO [vmware.resource.VmwareResource]
> (DirectAgent-52:10.102.192.18) Executing resource ModifyStoragePoolCommand:
> {"add":true,"pool":{"id":6,"uuid":"8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","host":"10.102.192.100","path":"/cpg_vol/sailaja/wrongzwps1","port":2049,"type":"NetworkFilesystem"},"localPath":"/mnt//8f4e2b4b-76a2-3f11-b98c-2ee8108ab900","wait":0}
> 2013-08-01 10:11:30,949 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RouterStatusMonitor-1:null) Found 3 routers to update status.
> 2013-08-01 10:11:30,951 DEBUG
> [network.router.VirtualNetworkApplianceManagerImpl]
> (RouterStatusMonitor-1:null) Found 0 networks to update RvR status.
> 2013-08-01 10:11:30,962 INFO [vmware.mo.HostMO]
> (DirectAgent-52:10.102.192.18) Creation of NFS datastore on vCenter failed.
> Details: vCenter API trace - mountDatastore(). target MOR: host-8973, vmfs:
> false, poolHost: 10.102.192.100, poolHostPort: 2049, poolPath:
> /cpg_vol/sailaja/wrongzwps1, poolUuid: 8f4e2b4b76a23f11b98c2ee8108ab900.
> Exception mesg: An error occurred during host configuration.
> 2013-08-01 10:11:30,962 ERROR [vmware.resource.VmwareResource]
> (DirectAgent-52:10.102.192.18) ModifyStoragePoolCommand failed due to
> Exception: java.lang.Exception
> Message: Creation of NFS datastore on vCenter failed.
> java.lang.Exception: Creation of NFS datastore on vCenter failed.
> at
> com.cloud.hypervisor.vmware.mo.HostMO.mountDatastore(HostMO.java:772)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:4102)
> at
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:472)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors
[jira] [Commented] (CLOUDSTACK-7613) [UI]CPU Sockets page does not display XenServer 6.5 Information
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218688#comment-14218688 ] ASF subversion and git services commented on CLOUDSTACK-7613: - Commit 6dc77127938c39c330f71cdc22b057ba64804aa7 in cloudstack's branch refs/heads/4.5 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6dc7712 ] CLOUDSTACK-7613: UI > Infrastructure > CPU Sockets > add a new row for "XenServer 6.5.0". > [UI]CPU Sockets page does not display XenServer 6.5 Information > --- > > Key: CLOUDSTACK-7613 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7613 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Sailaja Mada >Assignee: Jessica Wang > Fix For: 4.5.0 > > Attachments: listCPUsocktesUI.png, sailajacloud.sql, > sailajacloud_usage.sql > > > Steps: > 1. Install and configure Adv zone with XS 6.5 > 2. Tried to view CPU Sockets page from Infrastructure page > Observation: > 1. It is calling list hosts by XenServer hypervisor and its receiving the > count 2 for XS 6.5. But its displayed in the UI. > Attached snap. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7613) [UI]CPU Sockets page does not display XenServer 6.5 Information
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218690#comment-14218690 ] ASF subversion and git services commented on CLOUDSTACK-7613: - Commit e32eec8b3eacd1d90f706946d8d0c5248fbd8bcd in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e32eec8 ] CLOUDSTACK-7613: UI > Infrastructure > CPU Sockets > add a new row for "XenServer 6.5.0". > [UI]CPU Sockets page does not display XenServer 6.5 Information > --- > > Key: CLOUDSTACK-7613 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7613 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Sailaja Mada >Assignee: Jessica Wang > Fix For: 4.5.0 > > Attachments: listCPUsocktesUI.png, sailajacloud.sql, > sailajacloud_usage.sql > > > Steps: > 1. Install and configure Adv zone with XS 6.5 > 2. Tried to view CPU Sockets page from Infrastructure page > Observation: > 1. It is calling list hosts by XenServer hypervisor and its receiving the > count 2 for XS 6.5. But its displayed in the UI. > Attached snap. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7613) [UI]CPU Sockets page does not display XenServer 6.5 Information
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-7613: - Attachment: after_I_checked_in_UI_change.PNG > [UI]CPU Sockets page does not display XenServer 6.5 Information > --- > > Key: CLOUDSTACK-7613 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7613 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Sailaja Mada >Assignee: Jessica Wang > Fix For: 4.5.0 > > Attachments: after_I_checked_in_UI_change.PNG, listCPUsocktesUI.png, > sailajacloud.sql, sailajacloud_usage.sql > > > Steps: > 1. Install and configure Adv zone with XS 6.5 > 2. Tried to view CPU Sockets page from Infrastructure page > Observation: > 1. It is calling list hosts by XenServer hypervisor and its receiving the > count 2 for XS 6.5. But its displayed in the UI. > Attached snap. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7613) [UI]CPU Sockets page does not display XenServer 6.5 Information
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-7613. -- Resolution: Fixed > [UI]CPU Sockets page does not display XenServer 6.5 Information > --- > > Key: CLOUDSTACK-7613 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7613 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: Sailaja Mada >Assignee: Jessica Wang > Fix For: 4.5.0 > > Attachments: after_I_checked_in_UI_change.PNG, listCPUsocktesUI.png, > sailajacloud.sql, sailajacloud_usage.sql > > > Steps: > 1. Install and configure Adv zone with XS 6.5 > 2. Tried to view CPU Sockets page from Infrastructure page > Observation: > 1. It is calling list hosts by XenServer hypervisor and its receiving the > count 2 for XS 6.5. But its displayed in the UI. > Attached snap. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7383) [LXC][UI] dont show vm snapshot button in UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang resolved CLOUDSTACK-7383. -- Resolution: Incomplete Assignee: Jessica Wang (was: shweta agarwal) > [LXC][UI] dont show vm snapshot button in UI > > > Key: CLOUDSTACK-7383 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7383 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.5.0 >Reporter: shweta agarwal >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.5.0 > > Attachments: lxc.png, vmsnap.png > > > Repro steps: > Vm snapshot is not supported in LXC so we should not show VM snapshot option > in UI in instance tab , the way we do it for KVM .We dont show VM snapshot > button in cae of KVM vm. > Attaching snapshot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5446) KVM-Secondary Store down-Even after secondary store is brought back up after being down for few hours,snapshot jobs do not get triggered with reason "there is othe
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218733#comment-14218733 ] ASF subversion and git services commented on CLOUDSTACK-5446: - Commit 2667855ccb932f9a03ddf6639f6411c73fea1b2c in cloudstack's branch refs/heads/4.5 from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2667855 ] CLOUDSTACK-5446: delete all the leftover snapshots on primary storage in case of snapshot errors, after a new backup snapshot is finished > KVM-Secondary Store down-Even after secondary store is brought back up after > being down for few hours,snapshot jobs do not get triggered with reason > "there is other active snapshot tasks on the instance to which the volume is > attached" > --- > > Key: CLOUDSTACK-5446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: edison su > Fix For: 4.4.0, 4.5.0 > > Attachments: agentdown.rar, ssdown.rar > > > KVM - Secondary Store down - Even after secondary store is brought back up > after being down for few hours , snapshot jobs do not get triggered with > reason "here is other active snapshot tasks on the instance to which the > volume is attached, please try again later" > Set up: > Advanced Zone set up with 2 KVM (RHEL 6.3) hosts. > Steps to reproduce the problem: > 1. Deploy 5 Vms in each of the hosts with 10 GB ROOT volume size , so we > start with 10 Vms. > 2. Start concurrent snapshots for ROOT volumes of all the Vms. > 3. Shutdown the Secondary storage server when the snapshots are in the > progress. > 4. Bring the Secondary storage server up after ~ 12 hours. > When the secondary storage was down: > The snapshot jobs that were in progress timed out after 6 hours. > Even after this , I do not see the hourly snapshots being scheduled due to > the following reason: > > 2013-12-10 13:07:49,285 WARN [c.c.s.s.SnapshotSchedulerImpl] > (SnapshotPollTask:ctx-cf0775f7) Scheduling snapshot failed due to > com.cloud.utils.exception.CloudRuntimeException: There is other active > snapshot tasks on the instance to which the volume is attached, please try > again later > Even after the secondary storage was brought up , there is no hourly > snapshots being scheduled due to the same reason - > "com.cloud.utils.exception.CloudRuntimeException: There is other active > snapshot tasks on the instance to which the volume is attached, please try > again later" > mysql> select * FROM snapshots; > ++++---+---+--+--+--+-+--+---+--+-+-+-++--++--+-+-+---+ > | id | data_center_id | account_id | domain_id | volume_id | disk_offering_id > | status | path | name| > uuid | snapshot_type | type_description | > size| created | removed | backup_snap_id | swift_id | > sechost_id | prev_snap_id | hypervisor_type | version | s3_id | > ++++---+---+--+--+--+-+--+---+--+-+-+-++--++--+-+-+---+ > | 1 | 1 | 6 | 1 |45 | 18 > | BackedUp | NULL | TestVM-tiny-host-0ps-0-0_ROOT-45_20131209234410 | > ee2c46b7-7623-439a-9a30-63eec1d95c56 | 3 | HOURLY | > 21474836480 | 2013-12-09 23:44:10 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > | 2 | 1 | 6 | 1 |43 | 18 > | BackedUp | NULL | TestVM-1_ROOT-43_20131209234410 | > 62c01389-49df-475b-b225-617d3903d25a | 3 | HOURLY | > 21474836480 | 2013-12-09 23:44:10 | NULL| NULL | NULL | > NULL
[jira] [Commented] (CLOUDSTACK-5446) KVM-Secondary Store down-Even after secondary store is brought back up after being down for few hours,snapshot jobs do not get triggered with reason "there is othe
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218731#comment-14218731 ] ASF subversion and git services commented on CLOUDSTACK-5446: - Commit 0e3aebbb9db795b1acbc14d4f035da3cb2345f34 in cloudstack's branch refs/heads/master from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0e3aebb ] CLOUDSTACK-5446: delete all the leftover snapshots on primary storage in case of snapshot errors, after a new backup snapshot is finished > KVM-Secondary Store down-Even after secondary store is brought back up after > being down for few hours,snapshot jobs do not get triggered with reason > "there is other active snapshot tasks on the instance to which the volume is > attached" > --- > > Key: CLOUDSTACK-5446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: edison su > Fix For: 4.4.0, 4.5.0 > > Attachments: agentdown.rar, ssdown.rar > > > KVM - Secondary Store down - Even after secondary store is brought back up > after being down for few hours , snapshot jobs do not get triggered with > reason "here is other active snapshot tasks on the instance to which the > volume is attached, please try again later" > Set up: > Advanced Zone set up with 2 KVM (RHEL 6.3) hosts. > Steps to reproduce the problem: > 1. Deploy 5 Vms in each of the hosts with 10 GB ROOT volume size , so we > start with 10 Vms. > 2. Start concurrent snapshots for ROOT volumes of all the Vms. > 3. Shutdown the Secondary storage server when the snapshots are in the > progress. > 4. Bring the Secondary storage server up after ~ 12 hours. > When the secondary storage was down: > The snapshot jobs that were in progress timed out after 6 hours. > Even after this , I do not see the hourly snapshots being scheduled due to > the following reason: > > 2013-12-10 13:07:49,285 WARN [c.c.s.s.SnapshotSchedulerImpl] > (SnapshotPollTask:ctx-cf0775f7) Scheduling snapshot failed due to > com.cloud.utils.exception.CloudRuntimeException: There is other active > snapshot tasks on the instance to which the volume is attached, please try > again later > Even after the secondary storage was brought up , there is no hourly > snapshots being scheduled due to the same reason - > "com.cloud.utils.exception.CloudRuntimeException: There is other active > snapshot tasks on the instance to which the volume is attached, please try > again later" > mysql> select * FROM snapshots; > ++++---+---+--+--+--+-+--+---+--+-+-+-++--++--+-+-+---+ > | id | data_center_id | account_id | domain_id | volume_id | disk_offering_id > | status | path | name| > uuid | snapshot_type | type_description | > size| created | removed | backup_snap_id | swift_id | > sechost_id | prev_snap_id | hypervisor_type | version | s3_id | > ++++---+---+--+--+--+-+--+---+--+-+-+-++--++--+-+-+---+ > | 1 | 1 | 6 | 1 |45 | 18 > | BackedUp | NULL | TestVM-tiny-host-0ps-0-0_ROOT-45_20131209234410 | > ee2c46b7-7623-439a-9a30-63eec1d95c56 | 3 | HOURLY | > 21474836480 | 2013-12-09 23:44:10 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > | 2 | 1 | 6 | 1 |43 | 18 > | BackedUp | NULL | TestVM-1_ROOT-43_20131209234410 | > 62c01389-49df-475b-b225-617d3903d25a | 3 | HOURLY | > 21474836480 | 2013-12-09 23:44:10 | NULL| NULL | NULL | > N
[jira] [Resolved] (CLOUDSTACK-5446) KVM-Secondary Store down-Even after secondary store is brought back up after being down for few hours,snapshot jobs do not get triggered with reason "there is other
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-5446. --- Resolution: Fixed A new snapshot will delete all the leftover snapshot on primary storage > KVM-Secondary Store down-Even after secondary store is brought back up after > being down for few hours,snapshot jobs do not get triggered with reason > "there is other active snapshot tasks on the instance to which the volume is > attached" > --- > > Key: CLOUDSTACK-5446 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5446 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: edison su > Fix For: 4.4.0, 4.5.0 > > Attachments: agentdown.rar, ssdown.rar > > > KVM - Secondary Store down - Even after secondary store is brought back up > after being down for few hours , snapshot jobs do not get triggered with > reason "here is other active snapshot tasks on the instance to which the > volume is attached, please try again later" > Set up: > Advanced Zone set up with 2 KVM (RHEL 6.3) hosts. > Steps to reproduce the problem: > 1. Deploy 5 Vms in each of the hosts with 10 GB ROOT volume size , so we > start with 10 Vms. > 2. Start concurrent snapshots for ROOT volumes of all the Vms. > 3. Shutdown the Secondary storage server when the snapshots are in the > progress. > 4. Bring the Secondary storage server up after ~ 12 hours. > When the secondary storage was down: > The snapshot jobs that were in progress timed out after 6 hours. > Even after this , I do not see the hourly snapshots being scheduled due to > the following reason: > > 2013-12-10 13:07:49,285 WARN [c.c.s.s.SnapshotSchedulerImpl] > (SnapshotPollTask:ctx-cf0775f7) Scheduling snapshot failed due to > com.cloud.utils.exception.CloudRuntimeException: There is other active > snapshot tasks on the instance to which the volume is attached, please try > again later > Even after the secondary storage was brought up , there is no hourly > snapshots being scheduled due to the same reason - > "com.cloud.utils.exception.CloudRuntimeException: There is other active > snapshot tasks on the instance to which the volume is attached, please try > again later" > mysql> select * FROM snapshots; > ++++---+---+--+--+--+-+--+---+--+-+-+-++--++--+-+-+---+ > | id | data_center_id | account_id | domain_id | volume_id | disk_offering_id > | status | path | name| > uuid | snapshot_type | type_description | > size| created | removed | backup_snap_id | swift_id | > sechost_id | prev_snap_id | hypervisor_type | version | s3_id | > ++++---+---+--+--+--+-+--+---+--+-+-+-++--++--+-+-+---+ > | 1 | 1 | 6 | 1 |45 | 18 > | BackedUp | NULL | TestVM-tiny-host-0ps-0-0_ROOT-45_20131209234410 | > ee2c46b7-7623-439a-9a30-63eec1d95c56 | 3 | HOURLY | > 21474836480 | 2013-12-09 23:44:10 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > | 2 | 1 | 6 | 1 |43 | 18 > | BackedUp | NULL | TestVM-1_ROOT-43_20131209234410 | > 62c01389-49df-475b-b225-617d3903d25a | 3 | HOURLY | > 21474836480 | 2013-12-09 23:44:10 | NULL| NULL | NULL | > NULL | NULL | KVM | 2.2 | NULL | > | 3 | 1 | 6 | 1 |54 | 19 > | BackedUp | NULL | TestVM-tiny-host-1ps-0-4_ROOT-54_20131209234410 | > 8c7621f0-5d94-4f22-b3f8-7954c810e1be | 3 | HOURLY | > 21474836480 | 2013-12-0
[jira] [Created] (CLOUDSTACK-7945) Volume Snapshots - Discrepancies in state/removed fields for Snapshots that are deleted
edison su created CLOUDSTACK-7945: - Summary: Volume Snapshots - Discrepancies in state/removed fields for Snapshots that are deleted Key: CLOUDSTACK-7945 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7945 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Reporter: edison su Assignee: edison su Fix For: 4.5.0 Currently we have 2 different ways of handing deletion of snapshot that are in “BackedUp” state Vs “Error” state. In case of Snapshots in “Error” state , we marked the removed column. But in case of of Snapshots in “BackedUp” state , we see that state being marked as “Destroyed”. Why is there this discrepancy? mysql> select id,name,status,removed from snapshots; --+ id namestatus removed --+ 1 sangee-1_ROOT-3_20141027234323 Error 2014-10-28 17:38:36 2 sangee-1_ROOT-3_20141027235507 Destroyed NULL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7945) Volume Snapshots - Discrepancies in state/removed fields for Snapshots that are deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-7945. --- Resolution: Fixed > Volume Snapshots - Discrepancies in state/removed fields for Snapshots that > are deleted > --- > > Key: CLOUDSTACK-7945 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7945 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Reporter: edison su >Assignee: edison su > Fix For: 4.5.0 > > > Currently we have 2 different ways of handing deletion of snapshot that are > in “BackedUp” state Vs “Error” state. > In case of Snapshots in “Error” state , we marked the removed column. But in > case of of Snapshots in “BackedUp” state , we see that state being marked as > “Destroyed”. > Why is there this discrepancy? > mysql> select id,name,status,removed from snapshots; > --+ > idnamestatus removed > --+ > 1 sangee-1_ROOT-3_20141027234323 Error 2014-10-28 17:38:36 > 2 sangee-1_ROOT-3_20141027235507 Destroyed NULL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7945) Volume Snapshots - Discrepancies in state/removed fields for Snapshots that are deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218737#comment-14218737 ] ASF subversion and git services commented on CLOUDSTACK-7945: - Commit 5018db8b62dbb9ddb6612914d828baf2f98c43bb in cloudstack's branch refs/heads/4.5 from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5018db8 ] CLOUDSTACK-7945: set removed field in snapshots table in case of snaphsot failure. Reviewed-by: Frank > Volume Snapshots - Discrepancies in state/removed fields for Snapshots that > are deleted > --- > > Key: CLOUDSTACK-7945 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7945 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Reporter: edison su >Assignee: edison su > Fix For: 4.5.0 > > > Currently we have 2 different ways of handing deletion of snapshot that are > in “BackedUp” state Vs “Error” state. > In case of Snapshots in “Error” state , we marked the removed column. But in > case of of Snapshots in “BackedUp” state , we see that state being marked as > “Destroyed”. > Why is there this discrepancy? > mysql> select id,name,status,removed from snapshots; > --+ > idnamestatus removed > --+ > 1 sangee-1_ROOT-3_20141027234323 Error 2014-10-28 17:38:36 > 2 sangee-1_ROOT-3_20141027235507 Destroyed NULL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7945) Volume Snapshots - Discrepancies in state/removed fields for Snapshots that are deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218738#comment-14218738 ] ASF subversion and git services commented on CLOUDSTACK-7945: - Commit c05cda0d28d86bb0f0b87cf37d0828a0717b9045 in cloudstack's branch refs/heads/master from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c05cda0 ] CLOUDSTACK-7945: set removed field in snapshots table in case of snaphsot failure. Reviewed-by: Frank > Volume Snapshots - Discrepancies in state/removed fields for Snapshots that > are deleted > --- > > Key: CLOUDSTACK-7945 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7945 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Reporter: edison su >Assignee: edison su > Fix For: 4.5.0 > > > Currently we have 2 different ways of handing deletion of snapshot that are > in “BackedUp” state Vs “Error” state. > In case of Snapshots in “Error” state , we marked the removed column. But in > case of of Snapshots in “BackedUp” state , we see that state being marked as > “Destroyed”. > Why is there this discrepancy? > mysql> select id,name,status,removed from snapshots; > --+ > idnamestatus removed > --+ > 1 sangee-1_ROOT-3_20141027234323 Error 2014-10-28 17:38:36 > 2 sangee-1_ROOT-3_20141027235507 Destroyed NULL -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7946) volume went in creating state ;when ms got restarted while volume attach was in process
edison su created CLOUDSTACK-7946: - Summary: volume went in creating state ;when ms got restarted while volume attach was in process Key: CLOUDSTACK-7946 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7946 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Reporter: edison su Assignee: edison su Priority: Critical Fix For: 4.5.0 steps to reproduce 1-create a volume 2-Attache to a vm 3- while attach is in process restart MS issue volume went in creating status , Ui does not provide any action button for the volume -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7946) volume went in creating state ;when ms got restarted while volume attach was in process
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218750#comment-14218750 ] ASF subversion and git services commented on CLOUDSTACK-7946: - Commit 67113ff0b28f05ece2a76e11bcc136bed648e7c6 in cloudstack's branch refs/heads/master from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=67113ff ] CLOUDSTACK-7946: remove leftover state in volume and snapshot table in case of mgt server shutdown during storage operation. Reviewed-by: Min > volume went in creating state ;when ms got restarted while volume attach was > in process > --- > > Key: CLOUDSTACK-7946 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7946 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Reporter: edison su >Assignee: edison su >Priority: Critical > Fix For: 4.5.0 > > > steps to reproduce > > 1-create a volume > 2-Attache to a vm > 3- while attach is in process restart MS > issue > > volume went in creating status , Ui does not provide any action button for > the volume -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7946) volume went in creating state ;when ms got restarted while volume attach was in process
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218752#comment-14218752 ] ASF subversion and git services commented on CLOUDSTACK-7946: - Commit d856a2acad99875bff0ea7902c84a3dbf913d506 in cloudstack's branch refs/heads/4.5 from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d856a2a ] CLOUDSTACK-7946: remove leftover state in volume and snapshot table in case of mgt server shutdown during storage operation. Reviewed-by: Min > volume went in creating state ;when ms got restarted while volume attach was > in process > --- > > Key: CLOUDSTACK-7946 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7946 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Reporter: edison su >Assignee: edison su >Priority: Critical > Fix For: 4.5.0 > > > steps to reproduce > > 1-create a volume > 2-Attache to a vm > 3- while attach is in process restart MS > issue > > volume went in creating status , Ui does not provide any action button for > the volume -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7946) volume went in creating state ;when ms got restarted while volume attach was in process
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218753#comment-14218753 ] ASF subversion and git services commented on CLOUDSTACK-7946: - Commit 15c0efb77432351bfaaa76e41c4b1c847f60a2ca in cloudstack's branch refs/heads/4.5 from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=15c0efb ] CLOUDSTACK-7946: fix compile > volume went in creating state ;when ms got restarted while volume attach was > in process > --- > > Key: CLOUDSTACK-7946 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7946 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Reporter: edison su >Assignee: edison su >Priority: Critical > Fix For: 4.5.0 > > > steps to reproduce > > 1-create a volume > 2-Attache to a vm > 3- while attach is in process restart MS > issue > > volume went in creating status , Ui does not provide any action button for > the volume -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7946) volume went in creating state ;when ms got restarted while volume attach was in process
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218755#comment-14218755 ] ASF subversion and git services commented on CLOUDSTACK-7946: - Commit 2ccecce515297bd74a78645e45e7a66d1eb43a83 in cloudstack's branch refs/heads/master from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2ccecce ] CLOUDSTACK-7946: fix compile > volume went in creating state ;when ms got restarted while volume attach was > in process > --- > > Key: CLOUDSTACK-7946 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7946 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Reporter: edison su >Assignee: edison su >Priority: Critical > Fix For: 4.5.0 > > > steps to reproduce > > 1-create a volume > 2-Attache to a vm > 3- while attach is in process restart MS > issue > > volume went in creating status , Ui does not provide any action button for > the volume -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7946) volume went in creating state ;when ms got restarted while volume attach was in process
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-7946. --- Resolution: Fixed > volume went in creating state ;when ms got restarted while volume attach was > in process > --- > > Key: CLOUDSTACK-7946 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7946 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Reporter: edison su >Assignee: edison su >Priority: Critical > Fix For: 4.5.0 > > > steps to reproduce > > 1-create a volume > 2-Attache to a vm > 3- while attach is in process restart MS > issue > > volume went in creating status , Ui does not provide any action button for > the volume -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7947) Unable to take a snapshot of a volumes
edison su created CLOUDSTACK-7947: - Summary: Unable to take a snapshot of a volumes Key: CLOUDSTACK-7947 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7947 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Storage Controller Reporter: edison su Assignee: edison su Priority: Critical Fix For: 4.5.0 2014-08-14 10:31:49,926 DEBUG [o.a.c.s.d.d.CloudStackPrimaryDataStoreDriverImpl] (Work-Job-Executor-127:ctx-89498f92 job-18945/job-18946 ctx-1fd165da) Failed to take snapshot: 1582 java.lang.NullPointerException at org.apache.cloudstack.storage.snapshot.SnapshotObject.getId(SnapshotObject.java:149) at org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.findObject(ObjectInDataStoreManagerImpl.java:338) at org.apache.cloudstack.storage.snapshot.SnapshotObject.getPath(SnapshotObject.java:206) at org.apache.cloudstack.storage.to.SnapshotObjectTO.(SnapshotObjectTO.java:60) at org.apache.cloudstack.storage.snapshot.SnapshotObject.getTO(SnapshotObject.java:274) at org.apache.cloudstack.storage.datastore.driver.CloudStackPrimaryDataStoreDriverImpl.takeSnapshot(CloudStackPrimaryDataStoreDriverImpl.java:258) at org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.takeSnapshot(SnapshotServiceImpl.java:204) at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:291) at com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:946) at sun.reflect.GeneratedMethodAccessor412.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy160.takeSnapshot(Unknown Source) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1387) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7947) Unable to take a snapshot of a volumes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218762#comment-14218762 ] ASF subversion and git services commented on CLOUDSTACK-7947: - Commit 414081154942ff03bd4b73dd834eeec559608799 in cloudstack's branch refs/heads/master from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4140811 ] CLOUDSTACK-7947: double check if parent snapshot is removed or not, when creating new snapshot Reviewed-by: Min > Unable to take a snapshot of a volumes > -- > > Key: CLOUDSTACK-7947 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7947 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Reporter: edison su >Assignee: edison su >Priority: Critical > Fix For: 4.5.0 > > > 2014-08-14 10:31:49,926 DEBUG > [o.a.c.s.d.d.CloudStackPrimaryDataStoreDriverImpl] > (Work-Job-Executor-127:ctx-89498f92 job-18945/job-18946 ctx-1fd165da) Failed > to take snapshot: 1582 > java.lang.NullPointerException > at > org.apache.cloudstack.storage.snapshot.SnapshotObject.getId(SnapshotObject.java:149) > at > org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.findObject(ObjectInDataStoreManagerImpl.java:338) > at > org.apache.cloudstack.storage.snapshot.SnapshotObject.getPath(SnapshotObject.java:206) > at > org.apache.cloudstack.storage.to.SnapshotObjectTO.(SnapshotObjectTO.java:60) > at > org.apache.cloudstack.storage.snapshot.SnapshotObject.getTO(SnapshotObject.java:274) > at > org.apache.cloudstack.storage.datastore.driver.CloudStackPrimaryDataStoreDriverImpl.takeSnapshot(CloudStackPrimaryDataStoreDriverImpl.java:258) > at > org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.takeSnapshot(SnapshotServiceImpl.java:204) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:291) > at > com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:946) > at sun.reflect.GeneratedMethodAccessor412.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy160.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1387) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7947) Unable to take a snapshot of a volumes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-7947. --- Resolution: Fixed > Unable to take a snapshot of a volumes > -- > > Key: CLOUDSTACK-7947 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7947 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Reporter: edison su >Assignee: edison su >Priority: Critical > Fix For: 4.5.0 > > > 2014-08-14 10:31:49,926 DEBUG > [o.a.c.s.d.d.CloudStackPrimaryDataStoreDriverImpl] > (Work-Job-Executor-127:ctx-89498f92 job-18945/job-18946 ctx-1fd165da) Failed > to take snapshot: 1582 > java.lang.NullPointerException > at > org.apache.cloudstack.storage.snapshot.SnapshotObject.getId(SnapshotObject.java:149) > at > org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.findObject(ObjectInDataStoreManagerImpl.java:338) > at > org.apache.cloudstack.storage.snapshot.SnapshotObject.getPath(SnapshotObject.java:206) > at > org.apache.cloudstack.storage.to.SnapshotObjectTO.(SnapshotObjectTO.java:60) > at > org.apache.cloudstack.storage.snapshot.SnapshotObject.getTO(SnapshotObject.java:274) > at > org.apache.cloudstack.storage.datastore.driver.CloudStackPrimaryDataStoreDriverImpl.takeSnapshot(CloudStackPrimaryDataStoreDriverImpl.java:258) > at > org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.takeSnapshot(SnapshotServiceImpl.java:204) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:291) > at > com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:946) > at sun.reflect.GeneratedMethodAccessor412.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy160.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1387) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7947) Unable to take a snapshot of a volumes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218761#comment-14218761 ] ASF subversion and git services commented on CLOUDSTACK-7947: - Commit bd799653293f9dc257ab68a3b04f6ea769e08e36 in cloudstack's branch refs/heads/4.5 from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bd79965 ] CLOUDSTACK-7947: double check if parent snapshot is removed or not, when creating new snapshot Reviewed-by: Min > Unable to take a snapshot of a volumes > -- > > Key: CLOUDSTACK-7947 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7947 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Reporter: edison su >Assignee: edison su >Priority: Critical > Fix For: 4.5.0 > > > 2014-08-14 10:31:49,926 DEBUG > [o.a.c.s.d.d.CloudStackPrimaryDataStoreDriverImpl] > (Work-Job-Executor-127:ctx-89498f92 job-18945/job-18946 ctx-1fd165da) Failed > to take snapshot: 1582 > java.lang.NullPointerException > at > org.apache.cloudstack.storage.snapshot.SnapshotObject.getId(SnapshotObject.java:149) > at > org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.findObject(ObjectInDataStoreManagerImpl.java:338) > at > org.apache.cloudstack.storage.snapshot.SnapshotObject.getPath(SnapshotObject.java:206) > at > org.apache.cloudstack.storage.to.SnapshotObjectTO.(SnapshotObjectTO.java:60) > at > org.apache.cloudstack.storage.snapshot.SnapshotObject.getTO(SnapshotObject.java:274) > at > org.apache.cloudstack.storage.datastore.driver.CloudStackPrimaryDataStoreDriverImpl.takeSnapshot(CloudStackPrimaryDataStoreDriverImpl.java:258) > at > org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.takeSnapshot(SnapshotServiceImpl.java:204) > at > org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:291) > at > com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:946) > at sun.reflect.GeneratedMethodAccessor412.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) > at > org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) > at com.sun.proxy.$Proxy160.takeSnapshot(Unknown Source) > at > org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1387) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7742) Xenserver HA - SSVM failing to start since it is running out of management ip address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218782#comment-14218782 ] ASF subversion and git services commented on CLOUDSTACK-7742: - Commit ab19edf09d4f87f2807c52ba279aeb013f2545f9 in cloudstack's branch refs/heads/4.5 from [~anthonyxu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ab19edf ] CLOUDSTACK-7742: root cause: when vmsync reports system VM is down, CCP doesn't release the VM resource before starting it. fix: make sure cleanup is called for a VM when it is reported as Stopped > Xenserver HA - SSVM failing to start since it is running out of management ip > address > -- > > Key: CLOUDSTACK-7742 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7742 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: Build from master >Reporter: Sangeetha Hariharan >Assignee: Anthony Xu > Attachments: ssvm-fail.rar > > > HA - SSVM failing to start since it is running out of management ip address > Set up: > Cluster with 3 Xenserver hosts. > I am executing host HA scenarios where host is being brought down ( or > simulating contol path network failure / storage network failure). > After couple of such scenarios , i see that the SSVM fails to start as part > of HA the reason being running out of management nic: > management server logs: > 014-10-16 12:15:44,311 DEBUG [c.c.u.d.T.Transaction] > (Work-Job-Executor-106:ctx-323991ca job-771/job-943 ctx-3a2e9ed6) Rolling > back the transaction: Time = 1 Name = Work-Job-Executor-106; called by > -TransactionLegacy.rollback:902-DataCenterIpAddressDaoImpl.takeIpAddress:61-GeneratedMethodAccessor493.invoke:-1-DelegatingMethodAccessorImpl.invoke:43-Method.invoke:606-AopUtils.invokeJoinpointUsingReflection:317-ReflectiveMethodInvocation.invokeJoinpoint:183-ReflectiveMethodInvocation.proceed:150-TransactionContextInterceptor.invoke:34-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172 > 2014-10-16 12:15:44,312 INFO [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-106:ctx-323991ca job-771/job-943 ctx-3a2e9ed6) > Insufficient capacity > com.cloud.exception.InsufficientAddressCapacityException: Unable to get a > management ip addressScope=interface com.cloud.dc.Pod; id=1 > at > com.cloud.network.guru.PodBasedNetworkGuru.reserve(PodBasedNetworkGuru.java:123) > at > com.cloud.network.guru.StorageNetworkGuru.reserve(StorageNetworkGuru.java:122) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1338) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1309) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:970) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4590) > at sun.reflect.GeneratedMethodAccessor210.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4746) > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:513) > 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 > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:470) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadP
[jira] [Commented] (CLOUDSTACK-7742) Xenserver HA - SSVM failing to start since it is running out of management ip address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218790#comment-14218790 ] ASF subversion and git services commented on CLOUDSTACK-7742: - Commit 02e22dba7d36a1be04f715efdf5dcaa085f00241 in cloudstack's branch refs/heads/master from [~anthonyxu] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=02e22db ] CLOUDSTACK-7742: root cause: when vmsync reports system VM is down, CCP doesn't release the VM resource before starting it. fix: make sure cleanup is called for a VM when it is reported as Stopped > Xenserver HA - SSVM failing to start since it is running out of management ip > address > -- > > Key: CLOUDSTACK-7742 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7742 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: Build from master >Reporter: Sangeetha Hariharan >Assignee: Anthony Xu > Attachments: ssvm-fail.rar > > > HA - SSVM failing to start since it is running out of management ip address > Set up: > Cluster with 3 Xenserver hosts. > I am executing host HA scenarios where host is being brought down ( or > simulating contol path network failure / storage network failure). > After couple of such scenarios , i see that the SSVM fails to start as part > of HA the reason being running out of management nic: > management server logs: > 014-10-16 12:15:44,311 DEBUG [c.c.u.d.T.Transaction] > (Work-Job-Executor-106:ctx-323991ca job-771/job-943 ctx-3a2e9ed6) Rolling > back the transaction: Time = 1 Name = Work-Job-Executor-106; called by > -TransactionLegacy.rollback:902-DataCenterIpAddressDaoImpl.takeIpAddress:61-GeneratedMethodAccessor493.invoke:-1-DelegatingMethodAccessorImpl.invoke:43-Method.invoke:606-AopUtils.invokeJoinpointUsingReflection:317-ReflectiveMethodInvocation.invokeJoinpoint:183-ReflectiveMethodInvocation.proceed:150-TransactionContextInterceptor.invoke:34-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172 > 2014-10-16 12:15:44,312 INFO [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-106:ctx-323991ca job-771/job-943 ctx-3a2e9ed6) > Insufficient capacity > com.cloud.exception.InsufficientAddressCapacityException: Unable to get a > management ip addressScope=interface com.cloud.dc.Pod; id=1 > at > com.cloud.network.guru.PodBasedNetworkGuru.reserve(PodBasedNetworkGuru.java:123) > at > com.cloud.network.guru.StorageNetworkGuru.reserve(StorageNetworkGuru.java:122) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1338) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1309) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:970) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4590) > at sun.reflect.GeneratedMethodAccessor210.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4746) > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:513) > 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 > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:470) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(Thre
[jira] [Resolved] (CLOUDSTACK-7742) Xenserver HA - SSVM failing to start since it is running out of management ip address
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Xu resolved CLOUDSTACK-7742. Resolution: Fixed commit ab19edf09d4f87f2807c52ba279aeb013f2545f9 Author: Anthony Xu Date: Wed Nov 19 16:27:51 2014 -0800 CLOUDSTACK-7742: root cause: when vmsync reports system VM is down, CCP doesn't release the VM resource b fix: make sure cleanup is called for a VM when it is reported as Stopped > Xenserver HA - SSVM failing to start since it is running out of management ip > address > -- > > Key: CLOUDSTACK-7742 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7742 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: Build from master >Reporter: Sangeetha Hariharan >Assignee: Anthony Xu > Attachments: ssvm-fail.rar > > > HA - SSVM failing to start since it is running out of management ip address > Set up: > Cluster with 3 Xenserver hosts. > I am executing host HA scenarios where host is being brought down ( or > simulating contol path network failure / storage network failure). > After couple of such scenarios , i see that the SSVM fails to start as part > of HA the reason being running out of management nic: > management server logs: > 014-10-16 12:15:44,311 DEBUG [c.c.u.d.T.Transaction] > (Work-Job-Executor-106:ctx-323991ca job-771/job-943 ctx-3a2e9ed6) Rolling > back the transaction: Time = 1 Name = Work-Job-Executor-106; called by > -TransactionLegacy.rollback:902-DataCenterIpAddressDaoImpl.takeIpAddress:61-GeneratedMethodAccessor493.invoke:-1-DelegatingMethodAccessorImpl.invoke:43-Method.invoke:606-AopUtils.invokeJoinpointUsingReflection:317-ReflectiveMethodInvocation.invokeJoinpoint:183-ReflectiveMethodInvocation.proceed:150-TransactionContextInterceptor.invoke:34-ReflectiveMethodInvocation.proceed:161-ExposeInvocationInterceptor.invoke:91-ReflectiveMethodInvocation.proceed:172 > 2014-10-16 12:15:44,312 INFO [c.c.v.VirtualMachineManagerImpl] > (Work-Job-Executor-106:ctx-323991ca job-771/job-943 ctx-3a2e9ed6) > Insufficient capacity > com.cloud.exception.InsufficientAddressCapacityException: Unable to get a > management ip addressScope=interface com.cloud.dc.Pod; id=1 > at > com.cloud.network.guru.PodBasedNetworkGuru.reserve(PodBasedNetworkGuru.java:123) > at > com.cloud.network.guru.StorageNetworkGuru.reserve(StorageNetworkGuru.java:122) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1338) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1309) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:970) > at > com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4590) > at sun.reflect.GeneratedMethodAccessor210.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at > com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) > at > com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4746) > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:513) > 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 > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:470) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Th
[jira] [Created] (CLOUDSTACK-7948) [Automation] Two "VOLUME.DELETE" Events are being registered instead of one - On Destroying a User VM belonging to a Project
Chandan Purushothama created CLOUDSTACK-7948:
Summary: [Automation] Two "VOLUME.DELETE" Events are being
registered instead of one - On Destroying a User VM belonging to a Project
Key: CLOUDSTACK-7948
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7948
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Fix For: 4.5.0
==
User VM in Project Events Information in the Database:
==
{noformat}
mysql> select * from usage_event where account_id=6;
++-++-+-+-++-+-+-++---+--+
| id | type| account_id | created | zone_id |
resource_id | resource_name | offering_id | template_id | size|
resource_type | processed | virtual_size |
++-++-+-+-++-+-+-++---+--+
| 19 | TEMPLATE.CREATE | 6 | 2014-11-19 21:28:14 | 1 |
202 | TestTemplate-1 |NULL |NULL | 1708331520 | NULL
| 0 | 8589934592 |
| 20 | VOLUME.CREATE | 6 | 2014-11-19 21:32:23 | 1 |
9 | ROOT-9 | 1 | 5 | 21474836480 | NULL
| 0 | NULL |
| 21 | VM.CREATE | 6 | 2014-11-19 21:32:23 | 1 |
9 | Project-VM-1 | 1 | 5 |NULL |
XenServer | 0 | NULL |
| 22 | NET.IPASSIGN| 6 | 2014-11-19 21:32:25 | 1 |
6 | 10.219.196.151 |NULL | 0 | 0 |
DirectAttached | 0 | NULL |
| 23 | NETWORK.OFFERING.ASSIGN | 6 | 2014-11-19 21:32:33 | 1 |
9 | 19 | 6 |NULL | 1 | NULL
| 0 | NULL |
| 24 | SG.ASSIGN | 6 | 2014-11-19 21:32:33 | 1 |
9 | NULL | 4 |NULL |NULL | NULL
| 0 | NULL |
| 25 | VM.START| 6 | 2014-11-19 21:32:33 | 1 |
9 | Project-VM-1 | 1 | 5 |NULL |
XenServer | 0 | NULL |
| 26 | SG.REMOVE | 6 | 2014-11-19 21:33:10 | 1 |
9 | NULL | 4 |NULL |NULL | NULL
| 0 | NULL |
| 27 | VM.STOP | 6 | 2014-11-19 21:33:10 | 1 |
9 | Project-VM-1 | 1 | 5 |NULL |
XenServer | 0 | NULL |
| 28 | NETWORK.OFFERING.REMOVE | 6 | 2014-11-19 21:33:10 | 1 |
9 | 19 | 6 |NULL | 0 | NULL
| 0 | NULL |
| 31 | VM.DESTROY | 6 | 2014-11-20 00:08:37 | 1 |
9 | Project-VM-1 | 1 | 5 |NULL |
XenServer | 0 | NULL |
| 32 | VOLUME.DELETE | 6 | 2014-11-20 00:08:37 | 1 |
9 | ROOT-9 |NULL |NULL |NULL | NULL
| 0 | NULL |
| 33 | NET.IPRELEASE | 6 | 2014-11-20 00:08:39 | 1 |
6 | 10.219.196.151 |NULL | 0 | 0 |
DirectAttached | 0 | NULL |
| 34 | VOLUME.DELETE | 6 | 2014-11-20 00:08:39 | 1 |
9 | ROOT-9 |NULL |NULL |NULL | NULL
| 0 | NULL |
++-++-+-+-++-+-+-++---+--+
14 rows in set (0.00 sec)
{noformat}
=
Destroy VM Job Log:
=
{noformat}
2014-11-20 00:08:35,021 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(catalina-exec-11:ctx-fb3a3d80 ctx-67753d29) submit async job-50, details:
AsyncJobVO {id:50, userId: 2, accountId: 2, instanceType: VirtualMachine,
instanceId: 9, cmd:
org.apache.cloudstack.api.command.admin.vm.DestroyVMCmdByAdmin, cmdInfo:
{"sessionkey":"KxWOb6uxo53LBRidu+yVRm8qK04\u003d","cmdEventType":"VM.DESTROY","ctxUserId":"2","httpmethod":"GET","id":"ede32a62-67d7-487a-bb20-12c53d6e7c5a","response":"json","ctxDetails":"{\"com.
[jira] [Resolved] (CLOUDSTACK-7726) [Automation][XenServer] Failed to Remove LoadBalancer Rule due to callHostPlugin failure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Xu resolved CLOUDSTACK-7726. Resolution: Won't Fix can't reproduce, please reopen when you see it again > [Automation][XenServer] Failed to Remove LoadBalancer Rule due to > callHostPlugin failure > > > Key: CLOUDSTACK-7726 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7726 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.5.0 >Reporter: Chandan Purushothama >Assignee: Anthony Xu >Priority: Critical > Fix For: 4.5.0 > > Attachments: management-server.zip > > > === > CallHost Plugin Failure while trying to remove the Load Balancing Rule: > === > 2014-10-13 19:20:06,408 DEBUG [c.c.a.m.DirectAgentAttache] > (DirectAgent-45:ctx-fb2667f4) Seq 1-122723089845846136: Executing request > 2014-10-13 19:20:06,410 WARN [c.c.h.x.r.CitrixResourceBase] > (DirectAgent-89:ctx-0a5fbdf2) callHostPlugin failed for cmd: createFileInDomr > with args filepath: /etc/haproxy/haproxy.cfg.new.1413228006238, domrip: > 169.254.2.250, filecontents: global > log 127.0.0.1:3914 local0 warning > maxconn 4096 > maxpipes 1024 > chroot /var/lib/haproxy > user haproxy > group haproxy > daemon > > defaults > log global > modetcp > option dontlognull > retries 3 > option redispatch > option forwardfor > option forceclose > timeout connect5000 > timeout client 5 > timeout server 5 > listen stats_on_public 10.220.166.19:8081 > mode http > option httpclose > stats enable > stats uri /admin?stats > stats realm Haproxy\ Statistics > stats authadmin1:AdMiN123 > > listen 10_220_166_28- 10.220.166.28: > balance roundrobin > > > , due to There was a failure communicating with the plugin. > 2014-10-13 19:20:06,410 WARN [c.c.a.m.DirectAgentAttache] > (DirectAgent-89:ctx-0a5fbdf2) Seq 1-122723089845846135: Throwable caught > while executing command > com.cloud.utils.exception.CloudRuntimeException: callHostPlugin failed for > cmd: createFileInDomr with args filepath: > /etc/haproxy/haproxy.cfg.new.1413228006238, domrip: 169.254.2.250, > filecontents: global > log 127.0.0.1:3914 local0 warning > maxconn 4096 > maxpipes 1024 > chroot /var/lib/haproxy > user haproxy > group haproxy > daemon > > defaults > log global > modetcp > option dontlognull > retries 3 > option redispatch > option forwardfor > option forceclose > timeout connect5000 > timeout client 5 > timeout server 5 > listen stats_on_public 10.220.166.19:8081 > mode http > option httpclose > stats enable > stats uri /admin?stats > stats realm Haproxy\ Statistics > stats authadmin1:AdMiN123 > > listen 10_220_166_28- 10.220.166.28: > balance roundrobin > > > , due to There was a failure communicating with the plugin. > at > com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.callHostPlugin(CitrixResourceBase.java:3670) > at > com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.createFileInVR(CitrixResourceBase.java:575) > at > com.cloud.agent.resource.virtualnetwork.VirtualRoutingResource.applyConfigToVR(VirtualRoutingResource.java:161) > at > com.cloud.agent.resource.virtualnetwork.VirtualRoutingResource.applyConfigToVR(VirtualRoutingResource.java:155) > at > com.cloud.agent.resource.virtualnetwork.VirtualRoutingResource.applyConfig(VirtualRoutingResource.java:179) > at > com.cloud.agent.resource.virtualnetwork.VirtualRoutingResource.executeRequest(VirtualRoutingResource.java:125) > at > com.cloud.hypervisor.xenserver.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:430) > at > com.cloud.hypervisor.xenserver.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:64) > at > com.cloud.hypervisor.xenserver.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:87) > at > com.cloud.hypervisor.xenserver.resource.XenServer620SP1Resource.executeRequest(XenServer620SP1Resource.java:65) > at > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:304) > at > org.
[jira] [Commented] (CLOUDSTACK-7629) addBaremetalRct() API call is not available in cloudstackAPI library in marvin.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218815#comment-14218815 ] ASF subversion and git services commented on CLOUDSTACK-7629: - Commit 3dfe532e42e21b141e0f7c8f4ca41a0589d67457 in cloudstack's branch refs/heads/master from [~frank.zhang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3dfe532 ] CLOUDSTACK-7629 addBaremetalRct() API call is not available in cloudstackAPI library in marvin. > addBaremetalRct() API call is not available in cloudstackAPI library in > marvin. > --- > > Key: CLOUDSTACK-7629 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7629 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Sangeetha Hariharan >Assignee: frank zhang > Fix For: 4.5.0 > > > addBaremetalRct() API call is not available in cloudstackAPI library in > marvin. > When a new API call is added , we expect the python libraries for this API to > be available as part of cloudstackAPI in marvin. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7629) addBaremetalRct() API call is not available in cloudstackAPI library in marvin.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] frank zhang resolved CLOUDSTACK-7629. - Resolution: Fixed > addBaremetalRct() API call is not available in cloudstackAPI library in > marvin. > --- > > Key: CLOUDSTACK-7629 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7629 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Sangeetha Hariharan >Assignee: frank zhang > Fix For: 4.5.0 > > > addBaremetalRct() API call is not available in cloudstackAPI library in > marvin. > When a new API call is added , we expect the python libraries for this API to > be available as part of cloudstackAPI in marvin. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7629) addBaremetalRct() API call is not available in cloudstackAPI library in marvin.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218816#comment-14218816 ] ASF subversion and git services commented on CLOUDSTACK-7629: - Commit 2db1dd74320e92fbd501300426bac0632eb71c7a in cloudstack's branch refs/heads/4.5 from [~frank.zhang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2db1dd7 ] CLOUDSTACK-7629 addBaremetalRct() API call is not available in cloudstackAPI library in marvin. > addBaremetalRct() API call is not available in cloudstackAPI library in > marvin. > --- > > Key: CLOUDSTACK-7629 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7629 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 >Reporter: Sangeetha Hariharan >Assignee: frank zhang > Fix For: 4.5.0 > > > addBaremetalRct() API call is not available in cloudstackAPI library in > marvin. > When a new API call is added , we expect the python libraries for this API to > be available as part of cloudstackAPI in marvin. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7283) Allow regular user to execute listUsers API call
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radhika Nair reassigned CLOUDSTACK-7283: Assignee: (was: Radhika Nair) > Allow regular user to execute listUsers API call > > > Key: CLOUDSTACK-7283 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7283 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Doc >Affects Versions: 4.5.0 >Reporter: Alena Prokharchyk > Fix For: 4.5.0 > > > Since normal-user role can have access to listAccounts API that returns user > info + he can update users info by calling updateUser, he should have an > access to listUsers API. The response should return his user info only. Other > users belonging to the same user's account, shouldn't be returned. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7619) Baremetal - Have an out of the box Isolated network offering with PXE & DHCP services provided by VR along with all other services from default isolated network offe
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] frank zhang updated CLOUDSTACK-7619: Affects Version/s: (was: 4.5.0) 4.6.0 > Baremetal - Have an out of the box Isolated network offering with PXE & DHCP > services provided by VR along with all other services from default isolated > network offering for baremetal instances. > -- > > Key: CLOUDSTACK-7619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Sangeetha Hariharan >Assignee: frank zhang > Fix For: 4.6.0 > > > Baremetal - Have an out of the box Isolated network offering with PXE & DHCP > services provided by VR slong with all other services from default isolated > network offering for baremetal instances. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7619) Baremetal - Have an out of the box Isolated network offering with PXE & DHCP services provided by VR along with all other services from default isolated network offe
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] frank zhang updated CLOUDSTACK-7619: Fix Version/s: (was: 4.5.0) 4.6.0 > Baremetal - Have an out of the box Isolated network offering with PXE & DHCP > services provided by VR along with all other services from default isolated > network offering for baremetal instances. > -- > > Key: CLOUDSTACK-7619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Sangeetha Hariharan >Assignee: frank zhang > Fix For: 4.6.0 > > > Baremetal - Have an out of the box Isolated network offering with PXE & DHCP > services provided by VR slong with all other services from default isolated > network offering for baremetal instances. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7619) Baremetal - Have an out of the box Isolated network offering with PXE & DHCP services provided by VR along with all other services from default isolated network of
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218827#comment-14218827 ] frank zhang commented on CLOUDSTACK-7619: - This need schema change which is too late to 4.5. It's an enhancement feature; put it off to 4.6 > Baremetal - Have an out of the box Isolated network offering with PXE & DHCP > services provided by VR along with all other services from default isolated > network offering for baremetal instances. > -- > > Key: CLOUDSTACK-7619 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7619 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Sangeetha Hariharan >Assignee: frank zhang > Fix For: 4.6.0 > > > Baremetal - Have an out of the box Isolated network offering with PXE & DHCP > services provided by VR slong with all other services from default isolated > network offering for baremetal instances. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7746) Baremetal related script erros seen on router console
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219020#comment-14219020 ] Kishan Kavala commented on CLOUDSTACK-7746: --- Template with flask installed is available here: http://jenkins.buildacloud.org/job/build-systemvm64-master/443/ > Baremetal related script erros seen on router console > - > > Key: CLOUDSTACK-7746 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7746 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: Build from master >Reporter: Sangeetha Hariharan >Assignee: Harikrishna Patnala >Priority: Critical > Fix For: 4.5.0 > > Attachments: router.png > > > Baremetal related script erros seen on router console. > Advanced zone set up with 3 xenserver hosts in a cluster. > When logging into the console view of router , following script errors are > seen: > /opt/cloud/bin/baremetal-vr.py:159: SyntaxWarning : name 'server' is assigned > to before glocal declaration. .. > Attached is the screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7746) Baremetal related script erros seen on router console
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishan Kavala resolved CLOUDSTACK-7746. --- Resolution: Fixed > Baremetal related script erros seen on router console > - > > Key: CLOUDSTACK-7746 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7746 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.5.0 > Environment: Build from master >Reporter: Sangeetha Hariharan >Assignee: Harikrishna Patnala >Priority: Critical > Fix For: 4.5.0 > > Attachments: router.png > > > Baremetal related script erros seen on router console. > Advanced zone set up with 3 xenserver hosts in a cluster. > When logging into the console view of router , following script errors are > seen: > /opt/cloud/bin/baremetal-vr.py:159: SyntaxWarning : name 'server' is assigned > to before glocal declaration. .. > Attached is the screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7632) Automation for volume life cycle testPath
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra closed CLOUDSTACK-7632. - > Automation for volume life cycle testPath > - > > Key: CLOUDSTACK-7632 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7632 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Reporter: prashant kumar mishra >Assignee: prashant kumar mishra > > write automation for volume life cycle testcPath1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7949) test_base_image_updation.TestBaseImageUpdate.test_04_reoccuring_snapshot_rules fails while rebooting VM
Ashutosk Kelkar created CLOUDSTACK-7949:
---
Summary:
test_base_image_updation.TestBaseImageUpdate.test_04_reoccuring_snapshot_rules
fails while rebooting VM
Key: CLOUDSTACK-7949
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7949
Project: CloudStack
Issue Type: Test
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Ashutosk Kelkar
Assignee: Ashutosk Kelkar
Fix For: 4.5.0
The test case fails with below error:
Failed to reboot the virtual machine. Error: Job failed: {jobprocstatus : 0,
created : u'2014-11-19T16:58:28+', jobresult : {errorcode : 431, errortext
: u"Cannot restore the vm as the template be9df80c-a064-4056-a30e-01746a448513
isn't available in the zone"}, cmd :
u'org.apache.cloudstack.api.command.admin.vm.RebootVMCmdByAdmin', userid :
u'8c733998-6fe7-11e4-adbc-aa7a894c001b', jobstatus : 2, jobid :
u'8cc1d543-ad32-4fcf-b85d-7a234edcd089', jobresultcode : 530, jobinstanceid :
u'21ad3213-7383-433a-9bd2-d998c383b920', jobresulttype : u'object',
jobinstancetype : u'VirtualMachine', accountid :
u'8c732caa-6fe7-11e4-adbc-aa7a894c001b'}
Reboot Vm fails because the template used by the VM is deleted in earlier test
case. Instead the template should be cleaned up after execution of all the test
cases
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-5426) Cannot deploy instance having multiple volumes that use different storage tags for storage pools in same cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219070#comment-14219070 ] Rohit Yadav commented on CLOUDSTACK-5426: - Does this apply for 4.3 branch as well? And, was your fix tested? > Cannot deploy instance having multiple volumes that use different storage > tags for storage pools in same cluster > > > Key: CLOUDSTACK-5426 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5426 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0, 4.2.1, 4.3.0 >Reporter: Prachi Damle >Assignee: Prachi Damle >Priority: Critical > Fix For: 4.3.0 > > > This issue can be observed when VM being deployed has multiple volumes (>=2) > where 2 adjacent volumes are to be created with 2 different disk offerings > with different storage tags. > Ex: > 1. VM1 has 2 volumes root volume & 1 data volume. > 2. root volume is to be created using a disk offering with storage tag > 'root_disk' > 3. data volume is to be created using a disk offering with storage tag > 'data_disk' > 4. There exists a cluster wide storage pool suitable for root volume with > storage tag 'root_disk' > 5. There exists a cluster wide storage pool suitable for data volume with > storage tag 'data_disk' > The deploy VM fails in this case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7950) AttachIsoCmd shoud give correct messge when trying to attach vmwaretools installer iso on non supported guestvm deployed by ISO
Saksham Srivastava created CLOUDSTACK-7950: -- Summary: AttachIsoCmd shoud give correct messge when trying to attach vmwaretools installer iso on non supported guestvm deployed by ISO Key: CLOUDSTACK-7950 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7950 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Saksham Srivastava Assignee: Saksham Srivastava Fix For: 4.5.0 Deploy vm from iso say centos 6.4 Try attach vmware iso tools from cloudstack The log message/UI is not clear about the failure. INFO [c.c.h.v.m.HostMO] (DirectAgent-341:ctx-2492ca8c 10.102.192.14, job-79, cmd: AttachCommand) VM i-2-8-VM not found in host cache ERROR [c.c.s.r.VmwareStorageProcessor] (DirectAgent-341:ctx-2492ca8c 10.102.192.14, job-79, cmd: AttachCommand) AttachIsoCommand(attach) failed due to Exception: javax.xml.ws.soap.SOAPFaultException Message: The required VMware Tools ISO image does not exist or is inaccessible. javax.xml.ws.soap.SOAPFaultException: The required VMware Tools ISO image does not exist or is inaccessible. at com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) at com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) Message should contain info about non supported gues os. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7950) AttachIsoCmd shoud give correct messge when trying to attach vmwaretools installer iso on non supported guestvm deployed by ISO
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219102#comment-14219102 ] ASF subversion and git services commented on CLOUDSTACK-7950: - Commit 4ff3130becd50ab8d44864b651c1b1e235d67e6f in cloudstack's branch refs/heads/master from [~saksham] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4ff3130 ] CLOUDSTACK-7950: AttachIsoCmd shoud give correct messge when trying to attach vmwaretools installer iso on non supported guestvm deployed by ISO > AttachIsoCmd shoud give correct messge when trying to attach vmwaretools > installer iso on non supported guestvm deployed by ISO > --- > > Key: CLOUDSTACK-7950 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7950 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Saksham Srivastava >Assignee: Saksham Srivastava > Fix For: 4.5.0 > > > Deploy vm from iso say centos 6.4 > Try attach vmware iso tools from cloudstack > The log message/UI is not clear about the failure. > INFO [c.c.h.v.m.HostMO] (DirectAgent-341:ctx-2492ca8c 10.102.192.14, job-79, > cmd: AttachCommand) VM i-2-8-VM not found in host cache > ERROR [c.c.s.r.VmwareStorageProcessor] (DirectAgent-341:ctx-2492ca8c > 10.102.192.14, job-79, cmd: AttachCommand) AttachIsoCommand(attach) failed > due to Exception: javax.xml.ws.soap.SOAPFaultException > Message: The required VMware Tools ISO image does not exist or is > inaccessible. > javax.xml.ws.soap.SOAPFaultException: The required VMware Tools ISO image > does not exist or is inaccessible. > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > Message should contain info about non supported gues os. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7951) cloudstack-agent jsvc gets too large virtual memory space.
Keiichi Yusa created CLOUDSTACK-7951:
Summary: cloudstack-agent jsvc gets too large virtual memory space.
Key: CLOUDSTACK-7951
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7951
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM
Affects Versions: 4.3.0
Environment: - Builds up with 155 physical machines and a cloudstack
server.
- Each physical machine equips these.
+ Xeon E5-2680 (10 cores, 20 threads)
+ 128GB memory (and is not set swap space).
+ 600GB Solid State Drive.
- All physical machines are networked by InfiniBand and 10GBase-T.
- Using CentOS6.6 (64bit)
Reporter: Keiichi Yusa
Priority: Critical
cloudstack-agent jsvc gets too large virtual memory space on huge
memory equipped machine.
We have 155 physical machines that each is equipped 128GB RAM and
is installed CentOS6.6 (64bit). On these physical machines, I use
KVM as hypervisor.
I create Compute Offering with 120GB RAM and I deploy VM with this
Compute Offering on this environment.
Now, I have a problem that qemu-kvm process often fails deploying VM
in the above conditions. I confirm that the following message is
outputted in /var/log/libvirt/qemu/i-X-X-VM.log.
{noformat}
"Cannot set up guest memory 'pc.ram': Cannot allocate memory"
{noformat}
I find that cloudstack-agent jsvc gets virtual memory about 35GB.
{noformat}
$ top -a
(snip)
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
5787 root 20 0 34.9g 667m 18m S 0.0 0.5 8:45.20 jsvc
(snip)
{noformat}
I suspect that this failure is caused by what cloudstack-agent jsvc
gets too large virtual memory.
I try to patch /etc/init.d/cloudstack-agent as follows:
{noformat}
@@ -66,7 +66,7 @@
start() {
echo -n $"Starting $PROGNAME: "
if hostname --fqdn >/dev/null 2>&1 ; then
-$JSVC -cp "$CLASSPATH" -pidfile "$PIDFILE" \
+$JSVC -Xms1024m -Xmx2048m -cp "$CLASSPATH" -pidfile "$PIDFILE" \
-errfile $LOGDIR/cloudstack-agent.err -outfile
$LOGDIR/cloudstack-agent.out $CLASS
RETVAL=$?
echo
{noformat}
Then, I restart cloudstack-agent.
As a result, cloudstack agent jsvc reduces virtual memory about 6GB.
Also, qemu-kvm process does not fail deploying VM for now.
{noformat}
$ top -a
(snip)
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
141405 root 20 0 6290m 393m 18m S 0.0 0.3 1:11.44 jsvc
(snip)
{noformat}
If that helps, our CloudStack environment is as follows:
{noformat}
- Builds up with 155 physical machines and a cloudstack server.
- Each physical machine equips these.
+ Xeon E5-2680 (10 cores, 20 threads)
+ 128GB memory (and is not set swap space).
+ 600GB Solid State Drive.
- All physical machines are networked by InfiniBand and 10GBase-T.
- Using CentOS6.6 (64bit)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7950) AttachIsoCmd shoud give correct messge when trying to attach vmwaretools installer iso on non supported guestvm deployed by ISO
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saksham Srivastava resolved CLOUDSTACK-7950. Resolution: Fixed > AttachIsoCmd shoud give correct messge when trying to attach vmwaretools > installer iso on non supported guestvm deployed by ISO > --- > > Key: CLOUDSTACK-7950 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7950 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Saksham Srivastava >Assignee: Saksham Srivastava > Fix For: 4.5.0 > > > Deploy vm from iso say centos 6.4 > Try attach vmware iso tools from cloudstack > The log message/UI is not clear about the failure. > INFO [c.c.h.v.m.HostMO] (DirectAgent-341:ctx-2492ca8c 10.102.192.14, job-79, > cmd: AttachCommand) VM i-2-8-VM not found in host cache > ERROR [c.c.s.r.VmwareStorageProcessor] (DirectAgent-341:ctx-2492ca8c > 10.102.192.14, job-79, cmd: AttachCommand) AttachIsoCommand(attach) failed > due to Exception: javax.xml.ws.soap.SOAPFaultException > Message: The required VMware Tools ISO image does not exist or is > inaccessible. > javax.xml.ws.soap.SOAPFaultException: The required VMware Tools ISO image > does not exist or is inaccessible. > at > com.sun.xml.internal.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:178) > at > com.sun.xml.internal.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:119) > at > com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:108) > Message should contain info about non supported gues os. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7951) cloudstack-agent jsvc gets too large virtual memory space.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keiichi Yusa updated CLOUDSTACK-7951:
-
Environment:
Builds up with 155 physical machines and a cloudstack server.
Each physical machine equips these.(Xeon E5-2680 (10 cores, 20 threads), 128GB
memory (and is not set swap space), 600GB Solid State Drive)
All physical machines are networked by InfiniBand and 10GBase-T.
Using CentOS6.6 (64bit)
was:
- Builds up with 155 physical machines and a cloudstack server.
- Each physical machine equips these.
+ Xeon E5-2680 (10 cores, 20 threads)
+ 128GB memory (and is not set swap space).
+ 600GB Solid State Drive.
- All physical machines are networked by InfiniBand and 10GBase-T.
- Using CentOS6.6 (64bit)
> cloudstack-agent jsvc gets too large virtual memory space.
> --
>
> Key: CLOUDSTACK-7951
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7951
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.3.0
> Environment: Builds up with 155 physical machines and a cloudstack
> server.
> Each physical machine equips these.(Xeon E5-2680 (10 cores, 20 threads),
> 128GB memory (and is not set swap space), 600GB Solid State Drive)
> All physical machines are networked by InfiniBand and 10GBase-T.
> Using CentOS6.6 (64bit)
>Reporter: Keiichi Yusa
>Priority: Critical
>
> cloudstack-agent jsvc gets too large virtual memory space on huge
> memory equipped machine.
> We have 155 physical machines that each is equipped 128GB RAM and
> is installed CentOS6.6 (64bit). On these physical machines, I use
> KVM as hypervisor.
> I create Compute Offering with 120GB RAM and I deploy VM with this
> Compute Offering on this environment.
> Now, I have a problem that qemu-kvm process often fails deploying VM
> in the above conditions. I confirm that the following message is
> outputted in /var/log/libvirt/qemu/i-X-X-VM.log.
> {noformat}
> "Cannot set up guest memory 'pc.ram': Cannot allocate memory"
> {noformat}
> I find that cloudstack-agent jsvc gets virtual memory about 35GB.
> {noformat}
> $ top -a
> (snip)
>PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 5787 root 20 0 34.9g 667m 18m S 0.0 0.5 8:45.20 jsvc
> (snip)
> {noformat}
>
> I suspect that this failure is caused by what cloudstack-agent jsvc
> gets too large virtual memory.
> I try to patch /etc/init.d/cloudstack-agent as follows:
> {noformat}
> @@ -66,7 +66,7 @@
> start() {
> echo -n $"Starting $PROGNAME: "
> if hostname --fqdn >/dev/null 2>&1 ; then
> -$JSVC -cp "$CLASSPATH" -pidfile "$PIDFILE" \
> +$JSVC -Xms1024m -Xmx2048m -cp "$CLASSPATH" -pidfile "$PIDFILE" \
> -errfile $LOGDIR/cloudstack-agent.err -outfile
> $LOGDIR/cloudstack-agent.out $CLASS
> RETVAL=$?
> echo
> {noformat}
> Then, I restart cloudstack-agent.
> As a result, cloudstack agent jsvc reduces virtual memory about 6GB.
> Also, qemu-kvm process does not fail deploying VM for now.
> {noformat}
> $ top -a
> (snip)
>PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 141405 root 20 0 6290m 393m 18m S 0.0 0.3 1:11.44 jsvc
> (snip)
> {noformat}
> If that helps, our CloudStack environment is as follows:
> {noformat}
> - Builds up with 155 physical machines and a cloudstack server.
> - Each physical machine equips these.
> + Xeon E5-2680 (10 cores, 20 threads)
> + 128GB memory (and is not set swap space).
> + 600GB Solid State Drive.
> - All physical machines are networked by InfiniBand and 10GBase-T.
> - Using CentOS6.6 (64bit)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7951) cloudstack-agent jsvc gets too large virtual memory space.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keiichi Yusa updated CLOUDSTACK-7951:
-
Environment:
- Builds up with 155 physical machines and a cloudstack server.
- Each physical machine equips these.
+ Xeon E5-2680 (10 cores, 20 threads).
+ 128GB memory (and is not set swap space).
+ 600GB Solid State Drive.
- All physical machines are networked by InfiniBand and 10GBase-T.
- Using CentOS6.6 (64bit)
was:
Builds up with 155 physical machines and a cloudstack server.
Each physical machine equips these.(Xeon E5-2680 (10 cores, 20 threads), 128GB
memory (and is not set swap space), 600GB Solid State Drive)
All physical machines are networked by InfiniBand and 10GBase-T.
Using CentOS6.6 (64bit)
> cloudstack-agent jsvc gets too large virtual memory space.
> --
>
> Key: CLOUDSTACK-7951
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7951
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: KVM
>Affects Versions: 4.3.0
> Environment: - Builds up with 155 physical machines and a cloudstack
> server.
> - Each physical machine equips these.
> + Xeon E5-2680 (10 cores, 20 threads).
> + 128GB memory (and is not set swap space).
> + 600GB Solid State Drive.
> - All physical machines are networked by InfiniBand and 10GBase-T.
> - Using CentOS6.6 (64bit)
>Reporter: Keiichi Yusa
>Priority: Critical
>
> cloudstack-agent jsvc gets too large virtual memory space on huge
> memory equipped machine.
> We have 155 physical machines that each is equipped 128GB RAM and
> is installed CentOS6.6 (64bit). On these physical machines, I use
> KVM as hypervisor.
> I create Compute Offering with 120GB RAM and I deploy VM with this
> Compute Offering on this environment.
> Now, I have a problem that qemu-kvm process often fails deploying VM
> in the above conditions. I confirm that the following message is
> outputted in /var/log/libvirt/qemu/i-X-X-VM.log.
> {noformat}
> "Cannot set up guest memory 'pc.ram': Cannot allocate memory"
> {noformat}
> I find that cloudstack-agent jsvc gets virtual memory about 35GB.
> {noformat}
> $ top -a
> (snip)
>PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 5787 root 20 0 34.9g 667m 18m S 0.0 0.5 8:45.20 jsvc
> (snip)
> {noformat}
>
> I suspect that this failure is caused by what cloudstack-agent jsvc
> gets too large virtual memory.
> I try to patch /etc/init.d/cloudstack-agent as follows:
> {noformat}
> @@ -66,7 +66,7 @@
> start() {
> echo -n $"Starting $PROGNAME: "
> if hostname --fqdn >/dev/null 2>&1 ; then
> -$JSVC -cp "$CLASSPATH" -pidfile "$PIDFILE" \
> +$JSVC -Xms1024m -Xmx2048m -cp "$CLASSPATH" -pidfile "$PIDFILE" \
> -errfile $LOGDIR/cloudstack-agent.err -outfile
> $LOGDIR/cloudstack-agent.out $CLASS
> RETVAL=$?
> echo
> {noformat}
> Then, I restart cloudstack-agent.
> As a result, cloudstack agent jsvc reduces virtual memory about 6GB.
> Also, qemu-kvm process does not fail deploying VM for now.
> {noformat}
> $ top -a
> (snip)
>PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 141405 root 20 0 6290m 393m 18m S 0.0 0.3 1:11.44 jsvc
> (snip)
> {noformat}
> If that helps, our CloudStack environment is as follows:
> {noformat}
> - Builds up with 155 physical machines and a cloudstack server.
> - Each physical machine equips these.
> + Xeon E5-2680 (10 cores, 20 threads)
> + 128GB memory (and is not set swap space).
> + 600GB Solid State Drive.
> - All physical machines are networked by InfiniBand and 10GBase-T.
> - Using CentOS6.6 (64bit)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
