[jira] [Commented] (CLOUDSTACK-4787) Allow selection of scsi controller type in vSphere
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14265743#comment-14265743 ] Sateesh Chodapuneedi commented on CLOUDSTACK-4787: -- Using branch *vmware-disk-controllers* for code changes of this feature. Allow selection of scsi controller type in vSphere -- Key: CLOUDSTACK-4787 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4787 Project: CloudStack Issue Type: New Feature Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, UI, VMware Affects Versions: 4.2.0, 4.3.0 Environment: vSphere 5.1 Reporter: Chris Sciarrino Assignee: Sateesh Chodapuneedi Priority: Critical Fix For: 4.6.0 When adding an OVA template for a vSphere environment allow the selection of the scsi controller type. Currently the instances are deployed with the the LSI Parallel controller type. This results in a blue screen on boot when attempting to deploy templates that use the LSI SAS controller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8143) Correct the test case test_03_restart_network_cleanup
Ashutosk Kelkar created CLOUDSTACK-8143: --- Summary: Correct the test case test_03_restart_network_cleanup Key: CLOUDSTACK-8143 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8143 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 is restarting the network with cleanup=True and verifying that the linklocalip of the new router should be different than the linklocalip of the old router. However this may not be true as the linklocalip is assigned randomly and hence can be same for the new router. The test case should instead check that the publicip of the new router should be the same as publicip of the old router. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7449) CloudRuntimeException: Can not see storage pool after trying to add a new host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264445#comment-14264445 ] ChunFeng commented on CLOUDSTACK-7449: -- Dusan Batas, Your xenserver was apply any patch ? Such as : XS62E014 XS62E015 XS62ESP1 XS62ESP1002 XS62ESP1003 XS62ESP1005 XS62ESP1008 XS62ESP1009 XS62ESP1011 XS62ESP1013 XS62ESP1014 XS62ESP1015 CloudRuntimeException: Can not see storage pool after trying to add a new host Key: CLOUDSTACK-7449 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7449 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, XenServer Affects Versions: 4.4.1 Environment: XenServer 6.2, CentOS 6.4 Reporter: Dusan Batas - performed upgrade from 4.3 to 4.4 - upgraded XenServer hosts from 6.0.2 to 6.2 - adding a new host to cluster results with the error INFO [c.c.n.s.SecurityGroupListener] (catalina-exec-4:ctx-7cb01020 ctx-027ba5b4) Received a host startup notification INFO [c.c.n.s.SecurityGroupListener] (catalina-exec-4:ctx-7cb01020 ctx-027ba5b4) Scheduled network rules cleanup, interval=2524 INFO [c.c.n.s.SecurityGroupListener] (catalina-exec-4:ctx-7cb01020 ctx-027ba5b4) Received a host startup notification INFO [c.c.v.VirtualMachinePowerStateSyncImpl] (catalina-exec-4:ctx-7cb01020 ctx-027ba5b4) Reset VM power state sync for host: 78 WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-3:ctx-ede0dd1c) ModifyStoragePoolCommand add XenAPIException:Can not see storage pool: 614cda04-67ce-3f18-9721-99b8473b1ff0 from on host:e2cd9dda-8bfe-4cdf-831a-be7d5a26737f host:e2cd9dda-8bfe-4cdf-831a-be7d5a26737f pool: 10.168.12.20/vol1/cluster com.cloud.utils.exception.CloudRuntimeException: Can not see storage pool: 614cda04-67ce-3f18-9721-99b8473b1ff0 from on host:e2cd9dda-8bfe-4cdf-831a-be7d5a26737f at com.cloud.hypervisor.xen.resource.CitrixResourceBase.getStorageRepository(CitrixResourceBase.java:6848) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:5166) at com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:476) at com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:61) at com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102) at com.cloud.hypervisor.xen.resource.XenServer620SP1Resource.executeRequest(XenServer620SP1Resource.java:65) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) WARN [o.a.c.alerts] (catalina-exec-4:ctx-7cb01020 ctx-027ba5b4) alertType:: 7 // dataCenterId:: 1 // podId:: 1 // clusterId:: null // message:: Unable to attach storage pool214 to the host78 WARN [c.c.s.l.StoragePoolMonitor] (catalina-exec-4:ctx-7cb01020 ctx-027ba5b4) Unable to connect host 78 to pool Pool[214|NetworkFilesystem] due to com.cloud.utils.exception.CloudRuntimeException: Unable establish connection from storage head to storage pool 214 due to ModifyStoragePoolCommand add XenAPIException:Can not see storage pool: 614cda04-67ce-3f18-9721-99b8473b1ff0 from on host:e2cd9dda-8bfe-4cdf-831a-be7d5a26737f host:e2cd9dda-8bfe-4cdf-831a-be7d5a26737f pool: 10.168.12.20/vol1/cluster214 com.cloud.utils.exception.CloudRuntimeException: Unable establish
[jira] [Resolved] (CLOUDSTACK-8140) secstorage.service.offering in GS set to service offering ID Webui fails to start
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei Zhou resolved CLOUDSTACK-8140.
--
Resolution: Not a Problem
Assignee: Wei Zhou
This is because the management server was still in Starting.
secstorage.service.offering in GS set to service offering ID Webui fails to
start
-
Key: CLOUDSTACK-8140
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8140
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.2.1
Reporter: Nuno Tavares
Assignee: Wei Zhou
Hi. I'm using CS 4.2.1, and wanted to make sure that this has been corrected
in next versions:
It seems secstorage.service.offering setting in GS is expecting an integer ID
instead of the typical GUID. According to Nitin Mehta it's a bug, and here is
the bug report.
I kept the subject line from the CS thread I came across:
http://markmail.org/thread/jbdg544zmnye6kui#query:+page:1+mid:ifpbo3nivmpojtm3+state:results
Not sure why/if it is directly related, if I set any value with
update configuration set value = X where name =
'secstorage.service.offering';
the management server will not launch properly. After restarting, this is
what I get:
{code}
list capabilities
Error: The given command:listCapabilities does not exist or it is not
available for user with id:null
list templates templatefilter=all
Error: The given command:listTemplates does not exist or it is not available
for user with id:null
{code}
(mgt server logs complain about listCapabilites as well).
After setting the value to NULL everything comes back well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8063) list secondary Ips information in VM response
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264459#comment-14264459 ] ASF subversion and git services commented on CLOUDSTACK-8063: - Commit 93429443d50eabd5c6e73a412b8935120e13c42d in cloudstack's branch refs/heads/master from Wei Zhou [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9342944 ] CLOUDSTACK-8063: list secondary Ips information on non-default nics in VM response list secondary Ips information in VM response - Key: CLOUDSTACK-8063 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8063 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Reporter: Wei Zhou Assignee: Wei Zhou Priority: Minor Fix For: 4.6.0 and display it on UI -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8038) Create a new reusable tinylinux appliance for all hypervisors
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264392#comment-14264392 ] Erik Weber commented on CLOUDSTACK-8038: Isn't root disk resize only supported by KVM? -- Erik Create a new reusable tinylinux appliance for all hypervisors - Key: CLOUDSTACK-8038 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8038 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Rohit Yadav Assignee: Rohit Yadav Fix For: Future, 4.6.0 Using our systemvm build infra/scripts, create a tiny linux appliance (10-20 MB in size) that has the reset password/ssh-public-key scripts for testing purposes. Make this available for everyone for various hypervisors - Xen, VMWare, KVM, HyperV, OVM (LXC). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8130) Fix test_escalations_tempaltes.py - Remove test cases dependenency on each other
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264573#comment-14264573 ] ASF subversion and git services commented on CLOUDSTACK-8130: - Commit 17da2e9ce9894b67c32306fb36d02786d34ad0d0 in cloudstack's branch refs/heads/master from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=17da2e9 ] CLOUDSTACK-8130: Fixed test_escalations_templates.py - Removed test case dependency on each other Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org Fix test_escalations_tempaltes.py - Remove test cases dependenency on each other Key: CLOUDSTACK-8130 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8130 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 Labels: automation Fix For: 4.5.0 The test cases in this test suite use common account. Instead create a separate account for each test case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8135) component.test_escalations_instances.TestInstances.test_13_attach_detach_iso fails in cleanup operation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264575#comment-14264575 ] ASF subversion and git services commented on CLOUDSTACK-8135: - Commit 1ee41888353d87f4972e6ccb492817133805a88e in cloudstack's branch refs/heads/master from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1ee4188 ] CLOUDSTACK-8135: Fixed cleanup issue in test_escalations_instances.py Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org component.test_escalations_instances.TestInstances.test_13_attach_detach_iso fails in cleanup operation --- Key: CLOUDSTACK-8135 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8135 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 Labels: automation Fix For: 4.5.0 The test case fails in cleanup operation because the VM gets cleaned up as a part of account cleanup. Hence no need to add the VM in to cleanup list explicitly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8137) component.test_escalations_instances.TestInstances.test_23_deploy_vm_multiple_securitygroups fails in clenaup operation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264576#comment-14264576 ] ASF subversion and git services commented on CLOUDSTACK-8137: - Commit eae9f0f0b0904a9dad025d4278b5e9b4fdf02b5e in cloudstack's branch refs/heads/master from k...@clogeny.com [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=eae9f0f ] CLOUDSTACK-8137: Fixed cleanup issue in sec group tests in test_escalations_instances.py Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org component.test_escalations_instances.TestInstances.test_23_deploy_vm_multiple_securitygroups fails in clenaup operation --- Key: CLOUDSTACK-8137 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8137 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 Labels: automation Fix For: 4.5.0 The test case failed while deleting the security groups in cleanup operation because those were deleted as part of account cleanup. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8132) component.test_ss_limits.TestSecondaryStorageLimits.test_01_register_template_2_child_domain_admin Fails while comparing the secondary storage counts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14264574#comment-14264574 ] ASF subversion and git services commented on CLOUDSTACK-8132: - Commit f938a5e1c352971aa61e75a60935c735c3d3920c in cloudstack's branch refs/heads/master from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f938a5e ] CLOUDSTACK-8132: Fixed issue related to secondary storage count of template Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org component.test_ss_limits.TestSecondaryStorageLimits.test_01_register_template_2_child_domain_admin Fails while comparing the secondary storage counts - Key: CLOUDSTACK-8132 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8132 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 Labels: automation Fix For: 4.5.0 The test case fails because template is registered with root admin apiclient. It should be registered with respective account's api client. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (CLOUDSTACK-8140) secstorage.service.offering in GS set to service offering ID Webui fails to start
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei Zhou reopened CLOUDSTACK-8140:
--
reopen since management server can not start if set secstorage.service.offering
to uuid (not id)
secstorage.service.offering in GS set to service offering ID Webui fails to
start
-
Key: CLOUDSTACK-8140
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8140
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.2.1
Reporter: Nuno Tavares
Assignee: Wei Zhou
Hi. I'm using CS 4.2.1, and wanted to make sure that this has been corrected
in next versions:
It seems secstorage.service.offering setting in GS is expecting an integer ID
instead of the typical GUID. According to Nitin Mehta it's a bug, and here is
the bug report.
I kept the subject line from the CS thread I came across:
http://markmail.org/thread/jbdg544zmnye6kui#query:+page:1+mid:ifpbo3nivmpojtm3+state:results
Not sure why/if it is directly related, if I set any value with
update configuration set value = X where name =
'secstorage.service.offering';
the management server will not launch properly. After restarting, this is
what I get:
{code}
list capabilities
Error: The given command:listCapabilities does not exist or it is not
available for user with id:null
list templates templatefilter=all
Error: The given command:listTemplates does not exist or it is not available
for user with id:null
{code}
(mgt server logs complain about listCapabilites as well).
After setting the value to NULL everything comes back well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8142) [Hyper-V] While creating system vms attach systemvm.iso directly from sec storage folder instead from host local path
Rajesh Battala created CLOUDSTACK-8142: -- Summary: [Hyper-V] While creating system vms attach systemvm.iso directly from sec storage folder instead from host local path Key: CLOUDSTACK-8142 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8142 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Hypervisor Controller Affects Versions: 4.6.0 Reporter: Rajesh Battala Assignee: Devdeep Singh Fix For: 4.6.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
