[jira] [Commented] (CLOUDSTACK-8266) Automatic workload Management in the clusters Managed by CloudStack for efficient host Management.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328666#comment-14328666 ] Marcus Sorensen commented on CLOUDSTACK-8266: - Hi, FYI I think the metrics you need are not in the DB but available live already in StatsCollector. You can probably create a scheduled service that pulls the current host stats from memory in StatsCollector variables and tracks which ones are loaded for how long and redistributes load. I've looked into implementing this myself and actually have a basic reporting service working right now. It would be useful to implement different strategies, one to distribute load, one to consolidate and save power, etc. You probably want to start with writing up a functional spec (here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.6+Design+Documents) that outlines the ideas in this ticket and starts to solidify an implementation that the community agrees upon. > Automatic workload Management in the clusters Managed by CloudStack for > efficient host Management. > -- > > Key: CLOUDSTACK-8266 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8266 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server >Affects Versions: 4.5.0 > Environment: Java, Linux, Hypervisor >Reporter: Rajesh Battala > Labels: gsoc2015 > Fix For: 4.5.0 > > > CloudStack manages hypervisor hosts as clusters. It will deploy the vm's to > ensure proper hosts capacity are used max. > Due to some operations by user on vm's like stop/migrate/destroy hosts usage > in the clusters will be in inefficient state. > To solve this issue we can have a new Manager who will regularly checks host > capacity and implement Server Consolidtion by taking the actions: > 1. Live migrate the vm's if possible along with storage. Migrate them such > that hosts are fully utilized. > 2. After redistributing the vm's Shutdown the hosts which are empty. > 3. When load is getting increased,power-on the hosts remotely by WOL(Wake On > Lan) mechanisam. > This idea is discussed and presented in Collab Conference 2014. > Here is the youtube link > https://www.youtube.com/watch?v=hJKdZcSpGNQ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8272) Improve password serving script by making it non-blocking non-locking concurrent server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328694#comment-14328694 ] Abhinandan Prateek commented on CLOUDSTACK-8272: Python will be easier to maintain. > Improve password serving script by making it non-blocking non-locking > concurrent server > --- > > Key: CLOUDSTACK-8272 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8272 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0, 4.6.0, 4.4.2, 4.3.2 >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Labels: virtualrouter > > The current reset password server serves one user VM at a time, uses a global > lock per VR and slows up VM starting process for a VM that is created by a > template with reset password scripts. No only reset password option, but when > the VM starts for the first time this happens. The way it serves password > uses forking the process/scripts which eats up resources in both process > table and memory. For a concurrent launch of 30+ VM the VR hangs/fails. > Possible solution in the past includes increase the VR memory. > The solution would be to implement a concurrent single-process multi-threaded > password server that works both in basic/isolated network and in VPCs. It's > hard to do this in bash, so we can either implement a backward compatible > python script that replaces the present bash script, or a compiled program > (like a native tool) in C/C++/Go/Rust. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8266) Automatic workload Management in the clusters Managed by CloudStack for efficient host Management.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328700#comment-14328700 ] Rajesh Battala commented on CLOUDSTACK-8266: Thanks for Nice Suggestions > Automatic workload Management in the clusters Managed by CloudStack for > efficient host Management. > -- > > Key: CLOUDSTACK-8266 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8266 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server >Affects Versions: 4.5.0 > Environment: Java, Linux, Hypervisor >Reporter: Rajesh Battala > Labels: gsoc2015 > Fix For: 4.5.0 > > > CloudStack manages hypervisor hosts as clusters. It will deploy the vm's to > ensure proper hosts capacity are used max. > Due to some operations by user on vm's like stop/migrate/destroy hosts usage > in the clusters will be in inefficient state. > To solve this issue we can have a new Manager who will regularly checks host > capacity and implement Server Consolidtion by taking the actions: > 1. Live migrate the vm's if possible along with storage. Migrate them such > that hosts are fully utilized. > 2. After redistributing the vm's Shutdown the hosts which are empty. > 3. When load is getting increased,power-on the hosts remotely by WOL(Wake On > Lan) mechanisam. > This idea is discussed and presented in Collab Conference 2014. > Here is the youtube link > https://www.youtube.com/watch?v=hJKdZcSpGNQ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8266) Automatic workload Management in the clusters Managed by CloudStack for efficient host Management.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328770#comment-14328770 ] Tilak Raj Singh commented on CLOUDSTACK-8266: - Hi Marcus...Thanks for your suggestion..I have starting looking at the code of StatsCollector at https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/server/StatsCollector.java and trying to understand it. Could you please share the code of the basic reporting service you have implemented so that I have have some further insights with perspective to this issue. Regards > Automatic workload Management in the clusters Managed by CloudStack for > efficient host Management. > -- > > Key: CLOUDSTACK-8266 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8266 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server >Affects Versions: 4.5.0 > Environment: Java, Linux, Hypervisor >Reporter: Rajesh Battala > Labels: gsoc2015 > Fix For: 4.5.0 > > > CloudStack manages hypervisor hosts as clusters. It will deploy the vm's to > ensure proper hosts capacity are used max. > Due to some operations by user on vm's like stop/migrate/destroy hosts usage > in the clusters will be in inefficient state. > To solve this issue we can have a new Manager who will regularly checks host > capacity and implement Server Consolidtion by taking the actions: > 1. Live migrate the vm's if possible along with storage. Migrate them such > that hosts are fully utilized. > 2. After redistributing the vm's Shutdown the hosts which are empty. > 3. When load is getting increased,power-on the hosts remotely by WOL(Wake On > Lan) mechanisam. > This idea is discussed and presented in Collab Conference 2014. > Here is the youtube link > https://www.youtube.com/watch?v=hJKdZcSpGNQ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-8266) Automatic workload Management in the clusters Managed by CloudStack for efficient host Management.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328770#comment-14328770 ] Tilak Raj Singh edited comment on CLOUDSTACK-8266 at 2/20/15 10:59 AM: --- Hi Marcus...Thanks for your suggestion..I have starting looking at the code of StatsCollector at https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/server/StatsCollector.java and trying to understand it. Could you please share the code of the basic reporting service you have implemented so that I have have some further insights with perspective to this issue. Meanwhile I will discuss with Rajesh and bring up the functional specs for the ticket on the link you provided. Regards was (Author: tillu): Hi Marcus...Thanks for your suggestion..I have starting looking at the code of StatsCollector at https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/server/StatsCollector.java and trying to understand it. Could you please share the code of the basic reporting service you have implemented so that I have have some further insights with perspective to this issue. Regards > Automatic workload Management in the clusters Managed by CloudStack for > efficient host Management. > -- > > Key: CLOUDSTACK-8266 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8266 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server >Affects Versions: 4.5.0 > Environment: Java, Linux, Hypervisor >Reporter: Rajesh Battala > Labels: gsoc2015 > Fix For: 4.5.0 > > > CloudStack manages hypervisor hosts as clusters. It will deploy the vm's to > ensure proper hosts capacity are used max. > Due to some operations by user on vm's like stop/migrate/destroy hosts usage > in the clusters will be in inefficient state. > To solve this issue we can have a new Manager who will regularly checks host > capacity and implement Server Consolidtion by taking the actions: > 1. Live migrate the vm's if possible along with storage. Migrate them such > that hosts are fully utilized. > 2. After redistributing the vm's Shutdown the hosts which are empty. > 3. When load is getting increased,power-on the hosts remotely by WOL(Wake On > Lan) mechanisam. > This idea is discussed and presented in Collab Conference 2014. > Here is the youtube link > https://www.youtube.com/watch?v=hJKdZcSpGNQ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8270) Bug in terminal display while waiting for completion of asynchronous job
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328867#comment-14328867 ] Rohit Yadav commented on CLOUDSTACK-8270: - I kind of disliked the period (.) based completer/waiting view. So, I've not implemented a spinner which basically spins in place (like old-school DOS antiviruses :D). Please close if that solves the UX for you. > Bug in terminal display while waiting for completion of asynchronous job > - > > Key: CLOUDSTACK-8270 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8270 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Cloudmonkey > Environment: Python 2.7, cloudmonkey install by pip >Reporter: Phillip Kent >Priority: Minor > > When asyncblock=true, cloudmonkey waits for a job to finish and prints a > period '.' every few seconds. > When the . . . output rolls over to a second line on the terminal, a whole > line of . . . is incorrectly printed at each time step. > If I resize to a wider terminal screen, the correct behaviour is restored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8270) Bug in terminal display while waiting for completion of asynchronous job
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav resolved CLOUDSTACK-8270. - Resolution: Fixed Assignee: Rohit Yadav Fixed on master. Checkout gif here: https://twitter.com/_bhaisaab/status/568751981524701184 > Bug in terminal display while waiting for completion of asynchronous job > - > > Key: CLOUDSTACK-8270 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8270 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Cloudmonkey > Environment: Python 2.7, cloudmonkey install by pip >Reporter: Phillip Kent >Assignee: Rohit Yadav >Priority: Minor > > When asyncblock=true, cloudmonkey waits for a job to finish and prints a > period '.' every few seconds. > When the . . . output rolls over to a second line on the terminal, a whole > line of . . . is incorrectly printed at each time step. > If I resize to a wider terminal screen, the correct behaviour is restored. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8264) Add missing change in test_data.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328974#comment-14328974 ] ASF subversion and git services commented on CLOUDSTACK-8264: - Commit ba08229ff9a8246eddfc9e373dd4efdf35268013 in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ba08229 ] CLOUDSTACK-8264: Code improvement - test_stopped_vm.py Signed-off-by: SrikanteswaraRao Talluri > Add missing change in test_data.py > -- > > Key: CLOUDSTACK-8264 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8264 > 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: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > Add the change overwritten inadvertently by commit > 500baea9b6c816caae93ab2f8d0ba31f99c3f8fc -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8269) Changes in primary storage limits test cases according product behavior change
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328976#comment-14328976 ] ASF subversion and git services commented on CLOUDSTACK-8269: - Commit 53bae00801235c104f73a56501ff417209154546 in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=53bae00 ] CLOUDSTACK-8269: Code changes in primary storage test cases as per recent change in product behavior Signed-off-by: SrikanteswaraRao Talluri > Changes in primary storage limits test cases according product behavior change > -- > > Key: CLOUDSTACK-8269 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8269 > 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: Gaurav Aradhye > Labels: automation > Fix For: 4.5.0 > > > 1. Earlier volume would get deleted when vm is deleted, now the volume does > not get deleted and it remains in detached state unless account is removed. > This volume gets counted in primary storage count of the account. > 2. Earlier when volume was detached from VM, the primary storage count of the > account would get reduced by the volume size. Now the primary storage count > does not get reduced unless the volume is deleted. > Make appropriate changes in the test case as per new behavior. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7594) [Task] Add test path test cases for Stopped VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328975#comment-14328975 ] ASF subversion and git services commented on CLOUDSTACK-7594: - Commit 04409609336f3aee1bc91c875dd3c3badcc71ae5 in cloudstack's branch refs/heads/master from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0440960 ] CLOUDSTACK-7594: Adding automation test cases for stopped VM test path Signed-off-by: SrikanteswaraRao Talluri > [Task] Add test path test cases for Stopped VM > -- > > Key: CLOUDSTACK-7594 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7594 > 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: Ashutosk Kelkar >Assignee: Ashutosk Kelkar > Labels: automation > Fix For: 4.5.0 > > > Add automation test cases for Stopped VM test path. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7414) SSVM 4.4.0-6 fails to connect to NFS v3 and v4.1 shares
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329201#comment-14329201 ] Remi Bergsma commented on CLOUDSTACK-7414: -- Disable NFSv4 on Windows, it will then work with NFSv3 just fine. > SSVM 4.4.0-6 fails to connect to NFS v3 and v4.1 shares > --- > > Key: CLOUDSTACK-7414 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7414 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.4.0 > Environment: CloudStack v4.4 with SystemTemplate 4.4.0-6 > Deafult SSVM over Debian > Windows Storage Server 2012 with NFS running ver 3 or 4.1 > VMWare 5.5 >Reporter: Gaur Sunder >Priority: Critical > Labels: NFSv3, NFSv4.1, secondary_storage, ssvm > Original Estimate: 24h > Remaining Estimate: 24h > > Secondary Storage is provided on Windows Storage Server 2012. NFS Service is > installed and working. Note that WSS 2012 supports NFS v3 and v4.1 but not v4 > (for whatever reason they may have) > Able to add Secondary Storage using CS UI. > SSVM starts but fails to load the Secondary Storage. Checked with > ssvm-check.sh saying Error: "NFS is not currently mounted" and "NFS Server is > 0.0.0.0" > Manually mounting NFS location with "mount -t nfs -o vers=3" or "mount -t nfs > -o minorversion=1" successfully loads the storage location. > Tried setting /etc/nfsmount.conf with Defaultvers=3 or Defaultvers=4.1 but > appears SSVM ignores nfsmount.conf file. > Can add manual entry in /etc/fstab but not sure if that is going to work in > SSVM as while mounting it creates a uuid location dynamically. > There is no way to supply mount options to SSVM and SSVM is not automatically > degrading to v3 if v4 is not successful. > There should be a way to either pass mount options to SSVM or some > script/setting that can be edited/provided to work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
