[jira] [Created] (CLOUDSTACK-8607) As an Operator I want to be able to change the host password on the host itself via the updateHostPassword API
Wilder Rodrigues created CLOUDSTACK-8607: Summary: As an Operator I want to be able to change the host password on the host itself via the updateHostPassword API Key: CLOUDSTACK-8607 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8607 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: KVM, XenServer Reporter: Wilder Rodrigues Assignee: Wilder Rodrigues Fix For: 4.6.0 1. Change the API to offer a flag to decide to update the host or not - The default should be false - The flag is not mandatory 2. When the flag is informed and true, in case of communication error with the host we have to rollback the DB changes 3. In case of XenServer, do not allow single host update - Update shall be done only when the cluster ID is informed - It doesn't apply for KVM -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8606) DB performance impacted due to VM sync.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611614#comment-14611614 ] ASF GitHub Bot commented on CLOUDSTACK-8606: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/553#issuecomment-117946484 Nice one! LGTM DB performance impacted due to VM sync. --- Key: CLOUDSTACK-8606 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8606 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Upgrade Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 VM sync. generates a lot of queries on vm_instance table with 'instance_name' as filter. Since the field is not indexed, these kind of queries will impact DB performance. The issue is visible with deployments having more than 4000 VMs. VM sync. runs every 'ping.interval' and in each run generates individual queries for all VMs. If the MS is left running for a few hours, its response deteriorates drastically. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8484) Hosts without tag are not listed while listing the hosts for migration for instance with tag
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611629#comment-14611629 ] ASF GitHub Bot commented on CLOUDSTACK-8484: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/335#issuecomment-117951281 Code looks good, although I didn't test it yet. Before I do, I'd like to understand why do you want to push this to 4.5 and not to master? Hosts without tag are not listed while listing the hosts for migration for instance with tag Key: CLOUDSTACK-8484 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8484 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: Sudhansu Sahu Assignee: Sudhansu Sahu Hosts without tag are not listed while listing the hosts for migration for instance with tag. Ideally system should list all available hosts with not suitable suffix. Steps to reproduce: 1) Create a compute offering with a host tag eg: 'tag-1' 2) Tag a host in your cluster as 'tag-1' 3) Deploy an instance using this offering. 4) Instance will get deployed to the tagged host 5) Try listing the hosts for migration,it would return no host is available for migration. 6) Tag other hosts with 'tag-1' and they would start appearing in the list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8606) DB performance impacted due to VM sync.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611563#comment-14611563 ] ASF GitHub Bot commented on CLOUDSTACK-8606: GitHub user koushik-das opened a pull request: https://github.com/apache/cloudstack/pull/553 CLOUDSTACK-8606: DB performance impacted due to VM sync. VM sync. generates a lot of queries on vm_instance table with 'instance_name' as filter. Since the field is not indexed, these kind of queries will impact DB performance. Added an index for instance_name field. You can merge this pull request into a Git repository by running: $ git pull https://github.com/koushik-das/cloudstack CLOUDSTACK-8606 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/553.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #553 commit 47e005db533cbd9b2e40efc0adb276b677e228e2 Author: Koushik Das kous...@apache.org Date: 2015-07-02T06:41:53Z CLOUDSTACK-8606: DB performance impacted due to VM sync. VM sync. generates a lot of queries on vm_instance table with 'instance_name' as filter. Since the field is not indexed, these kind of queries will impact DB performance. Added an index for instance_name field. DB performance impacted due to VM sync. --- Key: CLOUDSTACK-8606 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8606 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Upgrade Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 VM sync. generates a lot of queries on vm_instance table with 'instance_name' as filter. Since the field is not indexed, these kind of queries will impact DB performance. The issue is visible with deployments having more than 4000 VMs. VM sync. runs every 'ping.interval' and in each run generates individual queries for all VMs. If the MS is left running for a few hours, its response deteriorates drastically. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8439) Automation for feature CPU/Memory overcommit
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611655#comment-14611655 ] ASF GitHub Bot commented on CLOUDSTACK-8439: Github user remibergsma commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/226#discussion_r33756445 --- Diff: test/integration/component/test_overcommit.py --- @@ -0,0 +1,458 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# License); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. + + test for feature CPU and MEM OVERCOMMIT + + +from marvin.cloudstackTestCase import cloudstackTestCase +from marvin.lib.base import (Account, + Capacities, + Cluster, + Configurations, + FAILED, + Host, + PASS, + ServiceOffering, + time, + VirtualMachine,) +from marvin.lib.utils import cleanup_resources, validateList +from marvin.lib.common import (get_zone, + get_domain, + get_template) +from marvin.sshClient import SshClient +from nose.plugins.attrib import attr + + +def ssh_xen_host(password, ipaddr, instance_name): +Ssh into xen host and get vm mem details +mem = [] +sshClient = SshClient( +ipaddr, +22, +root, +password +) +command = xe vm-list params=all name-label=%s % instance_name +vm_detail = sshClient.execute(command) +max_str = vm_detail[17].split(:) +min_str = vm_detail[20].split(:) +max = int(max_str[1]) +min = int(min_str[1]) +mem.append(max) +mem.append(min) +return mem + + +def ssh_kvm_host(password, ipaddr, instance_name): +Ssh into kvm host and get vm mem details +mem = [] +sshClient = SshClient( +ipaddr, +22, +root, +password +) + +command = virsh dominfo %s % instance_name +vm_detail = sshClient.execute(command) +max = vm_detail[7].split() +min = vm_detail[8].split() +mem.append(int(max[2])) +mem.append(int(min[2])) +return mem + + +def capacity_parser(capacity): +cpu = [] +mem = [] +cpu.append(capacity[0].capacitytotal) +cpu.append(capacity[0].capacityused) +cpu.append(capacity[0].percentused) +mem.append(capacity[1].capacitytotal) +mem.append(capacity[1].capacityused) +mem.append(capacity[1].percentused) +return cpu, mem + + +class Overcommit (cloudstackTestCase): + +@classmethod +def setUpClass(cls): +testClient = super(Overcommit, cls).getClsTestClient() +cls.apiclient = testClient.getApiClient() +cls.testdata = testClient.getParsedTestDataConfig() +# Get Zone,Domain and templates +cls.domain = get_domain(cls.apiclient) +cls.zone = get_zone(cls.apiclient) +cls.testdata[mode] = cls.zone.networktype +cls.testdata[configurableData][password] = xenroot +cls.hypervisor = testClient.getHypervisorInfo() + +cls.template = get_template( +cls.apiclient, +cls.zone.id, +cls.testdata[ostype]) +cls.testdata[template][ostypeid] = cls.template.ostypeid +list_conf = Configurations.list(cls.apiclient, +name=capacity.check.period +) +cls.wait_time = 5 + int(list_conf[0].value) / 1000 +if cls.template == FAILED: +cls.fail( +get_template() failed to return template with description \ +%s % +
[jira] [Commented] (CLOUDSTACK-7472) Change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611813#comment-14611813 ] ASF GitHub Bot commented on CLOUDSTACK-7472: GitHub user kishankavala opened a pull request: https://github.com/apache/cloudstack/pull/557 BUG-ID:CLOUDSTACK-7472: kvmclock fix for LXC is not required after fixing CLOUDSTACK-8177 kvmclock fix for LXC is not required after fixing CLOUDSTACK-8177 You can merge this pull request into a Git repository by running: $ git pull https://github.com/kishankavala/cloudstack CLOUDSTACK-7472 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/557.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #557 commit 34e4e9a79cb90dd56bc89f59fcbd0ec0dee82287 Author: Kishan Kavala kis...@apache.org Date: 2015-07-02T11:22:46Z BUG-ID:CLOUDSTACK-7472: kvmclock fix for LXC is not required after fixing CLOUDSTACK-8177 Change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true --- Key: CLOUDSTACK-7472 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7472 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.2 We need to minimize manual steps that needs to be done after agent installation so change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8611) CS waits indefinitely for CheckS2SVpnConnectionsCommand to return
Likitha Shetty created CLOUDSTACK-8611: -- Summary: CS waits indefinitely for CheckS2SVpnConnectionsCommand to return Key: CLOUDSTACK-8611 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8611 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 On one instance, CS began to execute CheckS2SVpnConnectionsCommand command on a router but the command result was never returned to the MS. If a command never returns, then 'DirectAgent' thread executing this command is blocked indefinitely and cannot pick up any other request. Now since this command is designed to execute in sequence on a host and is run regularly, every execution of that command thereafter on that particular host ended up picking up a DirectAgent thread and waiting for the previous execution to complete. And hence overtime, the host ended up using and blocking all 'DirectAgent' threads indefinitely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8582) Fix test cases failing on simulator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611701#comment-14611701 ] ASF GitHub Bot commented on CLOUDSTACK-8582: Github user runseb commented on the pull request: https://github.com/apache/cloudstack/pull/532#issuecomment-117977659 @gauravaradhye if you answer my questions I can give a LGTM :) Fix test cases failing on simulator --- Key: CLOUDSTACK-8582 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8582 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.6.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.6.0 Fix the test cases failing on simulator -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8610) [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611767#comment-14611767
]
ASF GitHub Bot commented on CLOUDSTACK-8610:
GitHub user likitha opened a pull request:
https://github.com/apache/cloudstack/pull/554
CLOUDSTACK-8610. Unable to attach 7th Disk to Windows Server 2012 R2 …
…instance.
During disk attach, while trying to obtain the controller key for SCSI
controller, look for device with the generic SCSI controller type i.e.
VirtualSCSIController.
While trying to obtain the SCSI id to attach a disk to, CS should ignore
the reserved SCSI id 7. But this is not being honored in case of VMs with SCSI
controller of type 'VirtualLsiLogicSASController'. And so in case of Windows
2012 R2 VMs, CS chooses to attach the 7th disk on the reserved SCSI id and this
fails on vCenter.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8610
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/554.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #554
commit cbfcf7cccf75c54decdcfa0c1185c42cb69d0a7a
Author: Likitha Shetty likitha.she...@citrix.com
Date: 2015-06-01T08:53:56Z
CLOUDSTACK-8610. Unable to attach 7th Disk to Windows Server 2012 R2
instance.
During disk attach, while trying to obtain the controller key for SCSI
controller, look for device with the generic SCSI controller type i.e.
VirtualSCSIController.
[VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
--
Key: CLOUDSTACK-8610
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8610
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Fix For: 4.6.0
+Steps to reproduce+
1. Set global config vmware.root.disk.controller to 'osdefault'.
2. Deploy a VM and attach 6 disks to the VM.
3. Try to attach a 7th disk to the VM.
Step 3 will fail with the below error
{noformat}
2015-06-22 11:03:22,673 ERROR [c.c.s.r.VmwareStorageProcessor]
(DirectAgent-636:ctx-8e72c2d9 s1p-z1-esxic-001.es.local, job-9286/job-9287,
cmd: AttachCommand) (logid:6372e940) Failed to attach volume: Failed to add
disk scsi0:7.
java.lang.RuntimeException: Failed to add disk scsi0:7.
at
com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:336)
at
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.attachDisk(VirtualMachineMO.java:1206)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8484) Hosts without tag are not listed while listing the hosts for migration for instance with tag
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611831#comment-14611831 ] ASF GitHub Bot commented on CLOUDSTACK-8484: Github user sudhansu7 commented on the pull request: https://github.com/apache/cloudstack/pull/335#issuecomment-118007318 @remibergsma @runseb This issue exists in 4.5 , hence fixed it in 4.5. this can me merged to master as well. Hosts without tag are not listed while listing the hosts for migration for instance with tag Key: CLOUDSTACK-8484 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8484 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: Sudhansu Sahu Assignee: Sudhansu Sahu Hosts without tag are not listed while listing the hosts for migration for instance with tag. Ideally system should list all available hosts with not suitable suffix. Steps to reproduce: 1) Create a compute offering with a host tag eg: 'tag-1' 2) Tag a host in your cluster as 'tag-1' 3) Deploy an instance using this offering. 4) Instance will get deployed to the tagged host 5) Try listing the hosts for migration,it would return no host is available for migration. 6) Tag other hosts with 'tag-1' and they would start appearing in the list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8612) [VMware] Make vCenter session timeout configurable for volume snapshot
Likitha Shetty created CLOUDSTACK-8612: -- Summary: [VMware] Make vCenter session timeout configurable for volume snapshot Key: CLOUDSTACK-8612 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8612 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 +Issue+ Taking a volume snapshot involves the below steps in case of VMware - 1. Create a VM snapshot for the VM that the volume is attached to. 2. Create a VM (clone) from the snapshot disk chain of the volume to be snapshot'ed. 3. Export the VM created in step 2 to secondary storage. 4. Destroy the cloned VM. 5. Delete the VM snapshot taken in step 1 (This step involves VM consolidation in vCenter). If any of the above steps (except VM export) takes more than 20 minutes to complete, snapshot backup operation will fail and the snapshot will be moved to 'Error' state. 20 minutes because the session between CS and vCenter times out in 20 minutes. In case of VM's with large volumes (most production environments) because of the size of the volumes and the fact that vCenter takes too long to consolidate VMs this large (step 5), snapshot operation on the volume attached to this VM takes too long to complete even going beyond a day. Snapshot consolidation taking too long is a known issue with vCenter - [http://kb.vmware.com/selfservice/search.do?cmd=displayKCdocType=kcdocTypeID=DT_KB_1_1externalId=1023657] +Solution+ To work around this, CS’s session to vCenter during snapshot operation needs to be set to a value higher than the time taken to consolidate for the operation to successfully complete. But setting the existing global configuration to this high a value could affect all operations in the cloud and hence is not considered an ideal workaround. Hence we need to split the existing vCenter session timeout configuration into two configurations, 1. To tune timeout value for CCP’s session vCenter during snapshot backup operation - _vmware.snapshot.backup.session.timeout_ (new; default: 20 minutes) 2. For all other operations - _vmware.vcenter.session.timeout_ (existing; default: 20 minutes) This way setting a high timeout value for snapshot backup operation will not be applicable to vCenter connections made for any other operations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8439) Automation for feature CPU/Memory overcommit
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611710#comment-14611710 ] ASF GitHub Bot commented on CLOUDSTACK-8439: Github user runseb commented on the pull request: https://github.com/apache/cloudstack/pull/226#issuecomment-117979269 @sanju1010 can you OK this now ? Automation for feature CPU/Memory overcommit Key: CLOUDSTACK-8439 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8439 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.5.0 Reporter: prashant kumar mishra Assignee: prashant kumar mishra Fix For: 4.5.2 FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/CPU+and+Memory+OverCommit test cases: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Over+commit+CPU+and+Memory -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8483) Private template not visible in project
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611825#comment-14611825
]
ASF GitHub Bot commented on CLOUDSTACK-8483:
Github user sudhansu7 commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/334#discussion_r33769718
--- Diff:
api/src/org/apache/cloudstack/api/command/user/template/CreateTemplateCmd.java
---
@@ -215,33 +221,39 @@ public long getEntityOwnerId() {
if (volumeId != null) {
Volume volume = _entityMgr.findById(Volume.class, volumeId);
if (volume != null) {
-accountId = volume.getAccountId();
--- End diff --
I will make this change
Private template not visible in project
---
Key: CLOUDSTACK-8483
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8483
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Projects
Affects Versions: 4.5.0
Reporter: Sudhansu Sahu
Assignee: Sudhansu Sahu
Private template get created outside the project context. These templates are
not visible in project view.
STEPS TO REPRODUCE:
1 Select a project view, and go into volumes view
2 Create a template from a Volume and wait until the process is complete
3 The template cannot be found in the project
4 Navigate back to the Default view The template can be found in the
templates screen in this view
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8483) Private template not visible in project
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611824#comment-14611824 ] ASF GitHub Bot commented on CLOUDSTACK-8483: Github user sudhansu7 commented on the pull request: https://github.com/apache/cloudstack/pull/334#issuecomment-118006807 @karuturi When a user switches to project view the ownership changes to project account. So any resource created inside project view should be mapped to project account. Private template not visible in project --- Key: CLOUDSTACK-8483 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8483 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Projects Affects Versions: 4.5.0 Reporter: Sudhansu Sahu Assignee: Sudhansu Sahu Private template get created outside the project context. These templates are not visible in project view. STEPS TO REPRODUCE: 1 Select a project view, and go into volumes view 2 Create a template from a Volume and wait until the process is complete 3 The template cannot be found in the project 4 Navigate back to the Default view The template can be found in the templates screen in this view -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8609) [VMware] VM is not accessible after a migration across clusters.
Likitha Shetty created CLOUDSTACK-8609: -- Summary: [VMware] VM is not accessible after a migration across clusters. Key: CLOUDSTACK-8609 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8609 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 +Steps to reproduce+ 1. Deploy a VMware zone with 2 clusters (a host each, H1 and H2) and one zone-wide primary storage spanning the two clusters. 2. Deploy a VM (VM1) on one of the hosts (H1). 3. Stop VM1. 4. Make the host that contains the VM unsuitable for further VM deployments - host runs out of capacity (cpu/memory) - host has maximum VMs deployed on it 5. Start VM1. 6. VM will be powered on H2 but will not be accessible because the .vmx and other VM files associated with the VM have been deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8483) Private template not visible in project
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611707#comment-14611707 ] ASF GitHub Bot commented on CLOUDSTACK-8483: Github user runseb commented on the pull request: https://github.com/apache/cloudstack/pull/334#issuecomment-117978565 @sudhansu7 can you reply to @karuturi ? thanks. Otherwise this will stay stuck waiting for your answer. Private template not visible in project --- Key: CLOUDSTACK-8483 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8483 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Projects Affects Versions: 4.5.0 Reporter: Sudhansu Sahu Assignee: Sudhansu Sahu Private template get created outside the project context. These templates are not visible in project view. STEPS TO REPRODUCE: 1 Select a project view, and go into volumes view 2 Create a template from a Volume and wait until the process is complete 3 The template cannot be found in the project 4 Navigate back to the Default view The template can be found in the templates screen in this view -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7566) Many jobs getting stuck in pending state and cloud is unusable
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611743#comment-14611743 ] Andrija Panic commented on CLOUDSTACK-7566: --- Rohit, is this maybe backported to 4.3.x ? I have this issue on 4.3.2 release... Thanks Many jobs getting stuck in pending state and cloud is unusable -- Key: CLOUDSTACK-7566 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7566 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Reporter: Min Chen Assignee: Min Chen Priority: Blocker Fix For: 4.5.0 Many jobs are getting stuck with errors like: 2014-09-09 18:55:41,964 WARN [jobs.impl.AsyncJobMonitor] (Timer-1:ctx-1e7a8a7e) Task (job-355415) has been pending for 690 seconds Even jobs that apparently succeed are getting the same error. Async job table is not updated with complete even though job is completed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8484) Hosts without tag are not listed while listing the hosts for migration for instance with tag
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611705#comment-14611705 ] ASF GitHub Bot commented on CLOUDSTACK-8484: Github user runseb commented on the pull request: https://github.com/apache/cloudstack/pull/335#issuecomment-117978306 @sudhansu7 there is a question here from @remibergsma , can you answer it so it can get merged. Hosts without tag are not listed while listing the hosts for migration for instance with tag Key: CLOUDSTACK-8484 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8484 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: Sudhansu Sahu Assignee: Sudhansu Sahu Hosts without tag are not listed while listing the hosts for migration for instance with tag. Ideally system should list all available hosts with not suitable suffix. Steps to reproduce: 1) Create a compute offering with a host tag eg: 'tag-1' 2) Tag a host in your cluster as 'tag-1' 3) Deploy an instance using this offering. 4) Instance will get deployed to the tagged host 5) Try listing the hosts for migration,it would return no host is available for migration. 6) Tag other hosts with 'tag-1' and they would start appearing in the list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8608) Fix unpleasant admin experience with VMware fresh installs/upgrades - System VM's failed to start due to permissions issue
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611769#comment-14611769 ] ASF GitHub Bot commented on CLOUDSTACK-8608: GitHub user likitha opened a pull request: https://github.com/apache/cloudstack/pull/555 CLOUDSTACK-8608. System VM's failed to start due to permissions issue. …instance. You can merge this pull request into a Git repository by running: $ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8608 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/555.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #555 commit 7b87e8a4184c046917f71627db9a20871ae981b4 Author: Likitha Shetty likitha.she...@citrix.com Date: 2015-04-20T12:59:55Z CLOUDSTACK-8608. System VM's failed to start due to permissions issue. Provide permissions to template folder when mounted on management server. Fix unpleasant admin experience with VMware fresh installs/upgrades - System VM's failed to start due to permissions issue -- Key: CLOUDSTACK-8608 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8608 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 VMware uses a folder in machine where management server is running to mount secondary storage. This is a bootstrap phase to start system vm, because unlike KVM, Xenserver, management server cannot directly access VMWare ESXI host to download systemvm template from secondary storage to primary storage. The secondary storage is usually managed by SSVM that uses root account to download templates. However, management server is using account 'cloud' to manipulate templates after secondary storage is mounted. After admin registers new systemvm template in CS as a normal upgrade procedure, the old SSVM will download the template using account root, but management server will create new SSVM from the new template using account 'cloud'. Then a permission denied error will raise. Prior to 4.4, CS used to handle this by running 'chmod -R' to the folder to which secondary storage is mounted every time management server mounts secondary storage. Unfortunately, this method is slow because we are trying to give permissions to the entire folder. So in 4.4, we stopped automatically providing the permissions and asked admin to manually run 'chmod -R' to the folder 'templates' on secondary storage, after registering new systemvm template. We can avoid this manual admin step by only providing permissions for the /templates folder instead of the entire folder. This way we will avoid the snapshots folder which could be very large in upgrade setups. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8439) Automation for feature CPU/Memory overcommit
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611658#comment-14611658 ] ASF GitHub Bot commented on CLOUDSTACK-8439: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/226#issuecomment-117956396 Apart from the typo it LGTM Automation for feature CPU/Memory overcommit Key: CLOUDSTACK-8439 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8439 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.5.0 Reporter: prashant kumar mishra Assignee: prashant kumar mishra Fix For: 4.5.2 FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/CPU+and+Memory+OverCommit test cases: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Over+commit+CPU+and+Memory -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8610) [VMWARE] Unable to attach 7th Disk to a Windows server 2012R2 instance
Likitha Shetty created CLOUDSTACK-8610:
--
Summary: [VMWARE] Unable to attach 7th Disk to a Windows server
2012R2 instance
Key: CLOUDSTACK-8610
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8610
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Likitha Shetty
Assignee: Likitha Shetty
Fix For: 4.6.0
+Steps to reproduce+
1. Set global config vmware.root.disk.controller to 'osdefault'.
2. Deploy a VM and attach 6 disks to the VM.
3. Try to attach a 7th disk to the VM.
Step 3 will fail with the below error
{noformat}
2015-06-22 11:03:22,673 ERROR [c.c.s.r.VmwareStorageProcessor]
(DirectAgent-636:ctx-8e72c2d9 s1p-z1-esxic-001.es.local, job-9286/job-9287,
cmd: AttachCommand) (logid:6372e940) Failed to attach volume: Failed to add
disk scsi0:7.
java.lang.RuntimeException: Failed to add disk scsi0:7.
at
com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:336)
at
com.cloud.hypervisor.vmware.mo.VirtualMachineMO.attachDisk(VirtualMachineMO.java:1206)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8379) add support to marvin to enable deployed zone based on the value provided in config file
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611713#comment-14611713
]
ASF GitHub Bot commented on CLOUDSTACK-8379:
Github user runseb commented on the pull request:
https://github.com/apache/cloudstack/pull/158#issuecomment-117979550
@gauravaradhye can you review this ? @srikanteswartalluri looks like Travis
failed.
add support to marvin to enable deployed zone based on the value provided in
config file
Key: CLOUDSTACK-8379
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8379
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: marvin
Affects Versions: 4.6.0
Reporter: Srikanteswararao Talluri
Assignee: Srikanteswararao Talluri
Fix For: 4.6.0
add support to marvin to enable deployed zone based on the value provided in
config file
if under zone section, if the 'enabled' element is not mentioned, then zone
will be enabled otherwise zone will be enabled/disabled based on value
provided ('false' or 'true') for 'enabled'
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8608) Fix unpleasant admin experience with VMware fresh installs/upgrades - System VM's failed to start due to permissions issue
Likitha Shetty created CLOUDSTACK-8608: -- Summary: Fix unpleasant admin experience with VMware fresh installs/upgrades - System VM's failed to start due to permissions issue Key: CLOUDSTACK-8608 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8608 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 VMware uses a folder in machine where management server is running to mount secondary storage. This is a bootstrap phase to start system vm, because unlike KVM, Xenserver, management server cannot directly access VMWare ESXI host to download systemvm template from secondary storage to primary storage. The secondary storage is usually managed by SSVM that uses root account to download templates. However, management server is using account 'cloud' to manipulate templates after secondary storage is mounted. After admin registers new systemvm template in CS as a normal upgrade procedure, the old SSVM will download the template using account root, but management server will create new SSVM from the new template using account 'cloud'. Then a permission denied error will raise. Prior to 4.4, CS used to handle this by running 'chmod -R' to the folder to which secondary storage is mounted every time management server mounts secondary storage. Unfortunately, this method is slow because we are trying to give permissions to the entire folder. So in 4.4, we stopped automatically providing the permissions and asked admin to manually run 'chmod -R' to the folder 'templates' on secondary storage, after registering new systemvm template. We can avoid this manual admin step by only providing permissions for the /templates folder instead of the entire folder. This way we will avoid the snapshots folder which could be very large in upgrade setups. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8609) [VMware] VM is not accessible after a migration across clusters.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611771#comment-14611771 ] ASF GitHub Bot commented on CLOUDSTACK-8609: GitHub user likitha opened a pull request: https://github.com/apache/cloudstack/pull/556 CLOUDSTACK-8609. [VMware] VM is not accessible after a migration acro… …ss clusters. Once a VM is successfully started, don't delete the files associated with the unregistered VM, if the files are in a storage that is being used by the new VM. Attempt to unregister a VM in another DC, only if there is a host associated with a VM. You can merge this pull request into a Git repository by running: $ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8609 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/556.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #556 commit a97a402f304303af78552777d5fde56abab902e5 Author: Likitha Shetty likitha.she...@citrix.com Date: 2015-05-15T08:44:37Z CLOUDSTACK-8609. [VMware] VM is not accessible after a migration across clusters. Once a VM is successfully started, don't delete the files associated with the unregistered VM, if the files are in a storage that is being used by the new VM. Attempt to unregister a VM in another DC, only if there is a host associated with a VM. [VMware] VM is not accessible after a migration across clusters. Key: CLOUDSTACK-8609 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8609 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.6.0 +Steps to reproduce+ 1. Deploy a VMware zone with 2 clusters (a host each, H1 and H2) and one zone-wide primary storage spanning the two clusters. 2. Deploy a VM (VM1) on one of the hosts (H1). 3. Stop VM1. 4. Make the host that contains the VM unsuitable for further VM deployments - host runs out of capacity (cpu/memory) - host has maximum VMs deployed on it 5. Start VM1. 6. VM will be powered on H2 but will not be accessible because the .vmx and other VM files associated with the VM have been deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8590) Refactoring NiciraNVP resource
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611864#comment-14611864 ] ASF GitHub Bot commented on CLOUDSTACK-8590: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/546#issuecomment-118011859 @remibergsma and @karuturi You are right. I believe both @bhaisaab and I forgot that. Once he said go ahead with the merge I just merged the thing. Apologies. Cheers, Wilder Refactoring NiciraNVP resource -- Key: CLOUDSTACK-8590 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8590 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Reporter: Wilder Rodrigues Assignee: Wilder Rodrigues Fix For: 4.6.0 Apply the same technique that was used for the refactoring of the Libvirt and XenServer hypervisors. All the commands will be wrapped by a ResourceWrapper annotated class. This will reduce the amount of private methods in the NiciraNvpResource class and also increase its testability, maintainability, extensibility and readability -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8484) Hosts without tag are not listed while listing the hosts for migration for instance with tag
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611899#comment-14611899 ] ASF GitHub Bot commented on CLOUDSTACK-8484: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/335#issuecomment-118020313 @sudhansu7 Let's first merge this to master, then it can go to 4.5. I just tried to merge your PR on master and that seems to work just fine so that is nice. There were two other questions: about unit tests and one about the commit message. If you could respond to that please? In the mean time, I'll go ahead and give it a test run. Hosts without tag are not listed while listing the hosts for migration for instance with tag Key: CLOUDSTACK-8484 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8484 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: Sudhansu Sahu Assignee: Sudhansu Sahu Hosts without tag are not listed while listing the hosts for migration for instance with tag. Ideally system should list all available hosts with not suitable suffix. Steps to reproduce: 1) Create a compute offering with a host tag eg: 'tag-1' 2) Tag a host in your cluster as 'tag-1' 3) Deploy an instance using this offering. 4) Instance will get deployed to the tagged host 5) Try listing the hosts for migration,it would return no host is available for migration. 6) Tag other hosts with 'tag-1' and they would start appearing in the list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8590) Refactoring NiciraNVP resource
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14611844#comment-14611844 ] ASF GitHub Bot commented on CLOUDSTACK-8590: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/546#issuecomment-118009819 @karuturi I agree, we should only proceed after two LGTMs. Let met give the second LGTM, after the fact. Refactoring NiciraNVP resource -- Key: CLOUDSTACK-8590 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8590 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Network Controller Reporter: Wilder Rodrigues Assignee: Wilder Rodrigues Fix For: 4.6.0 Apply the same technique that was used for the refactoring of the Libvirt and XenServer hypervisors. All the commands will be wrapped by a ResourceWrapper annotated class. This will reduce the amount of private methods in the NiciraNvpResource class and also increase its testability, maintainability, extensibility and readability -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8606) DB performance impacted due to VM sync.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14612481#comment-14612481 ] ASF GitHub Bot commented on CLOUDSTACK-8606: Github user wilderrodrigues commented on the pull request: https://github.com/apache/cloudstack/pull/553#issuecomment-118159861 Just had a look. LGTM. Please proceed with the merge. Cheers, Wilder DB performance impacted due to VM sync. --- Key: CLOUDSTACK-8606 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8606 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Upgrade Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 VM sync. generates a lot of queries on vm_instance table with 'instance_name' as filter. Since the field is not indexed, these kind of queries will impact DB performance. The issue is visible with deployments having more than 4000 VMs. VM sync. runs every 'ping.interval' and in each run generates individual queries for all VMs. If the MS is left running for a few hours, its response deteriorates drastically. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8606) DB performance impacted due to VM sync.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14612825#comment-14612825 ] ASF GitHub Bot commented on CLOUDSTACK-8606: Github user asfgit closed the pull request at: https://github.com/apache/cloudstack/pull/553 DB performance impacted due to VM sync. --- Key: CLOUDSTACK-8606 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8606 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Upgrade Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 VM sync. generates a lot of queries on vm_instance table with 'instance_name' as filter. Since the field is not indexed, these kind of queries will impact DB performance. The issue is visible with deployments having more than 4000 VMs. VM sync. runs every 'ping.interval' and in each run generates individual queries for all VMs. If the MS is left running for a few hours, its response deteriorates drastically. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8606) DB performance impacted due to VM sync.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14612824#comment-14612824 ] ASF subversion and git services commented on CLOUDSTACK-8606: - Commit f138192c946d45ca5982ec012f65a8b83c97422c in cloudstack's branch refs/heads/master from [~koushikd] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f138192 ] CLOUDSTACK-8606: DB performance impacted due to VM sync. VM sync. generates a lot of queries on vm_instance table with 'instance_name' as filter. Since the field is not indexed, these kind of queries will impact DB performance. Added an index for instance_name field. This closes #553 DB performance impacted due to VM sync. --- Key: CLOUDSTACK-8606 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8606 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Upgrade Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 VM sync. generates a lot of queries on vm_instance table with 'instance_name' as filter. Since the field is not indexed, these kind of queries will impact DB performance. The issue is visible with deployments having more than 4000 VMs. VM sync. runs every 'ping.interval' and in each run generates individual queries for all VMs. If the MS is left running for a few hours, its response deteriorates drastically. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8606) DB performance impacted due to VM sync.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koushik Das resolved CLOUDSTACK-8606. - Resolution: Fixed DB performance impacted due to VM sync. --- Key: CLOUDSTACK-8606 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8606 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Upgrade Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 VM sync. generates a lot of queries on vm_instance table with 'instance_name' as filter. Since the field is not indexed, these kind of queries will impact DB performance. The issue is visible with deployments having more than 4000 VMs. VM sync. runs every 'ping.interval' and in each run generates individual queries for all VMs. If the MS is left running for a few hours, its response deteriorates drastically. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7472) Change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14612254#comment-14612254 ] ASF GitHub Bot commented on CLOUDSTACK-7472: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/557#issuecomment-118099285 LGTM Change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true --- Key: CLOUDSTACK-7472 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7472 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.2 We need to minimize manual steps that needs to be done after agent installation so change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8606) DB performance impacted due to VM sync.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14612409#comment-14612409 ] ASF GitHub Bot commented on CLOUDSTACK-8606: Github user remibergsma commented on the pull request: https://github.com/apache/cloudstack/pull/553#issuecomment-118141634 @wilderrodrigues Could you please have a look at this PR? DB performance impacted due to VM sync. --- Key: CLOUDSTACK-8606 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8606 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, Upgrade Affects Versions: 4.5.0 Reporter: Koushik Das Assignee: Koushik Das Fix For: 4.6.0 VM sync. generates a lot of queries on vm_instance table with 'instance_name' as filter. Since the field is not indexed, these kind of queries will impact DB performance. The issue is visible with deployments having more than 4000 VMs. VM sync. runs every 'ping.interval' and in each run generates individual queries for all VMs. If the MS is left running for a few hours, its response deteriorates drastically. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
