Feature #1712
Support for multiple system datastores
| Status: | Closed | Start date: | 12/31/2012 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: |  Carlos Martín | % Done: | 0% | |
| Category: | Core & System | |||
| Target version: | Release 4.4 | |||
| Resolution: | fixed | Pull request: |
Description
Add support for multiple system datastores, that could be assigned to different user groups.
The use case is the following:
- Admin wants support for live migration, so it needs (expensive) shared storage for system ds
- Multiple user groups exist with different service requirements
- Admin defines gold, silver and bronze system ds offerings, that are served by SSD, SAS and SATA. The DS are available for all the hosts.
- Admin then defines who can use gold, silver and bronze and OpenNebula places the instances accordingly
Associated revisions
feature #1712: Generic match-making functions. It can be used with any Resource and not just hosts
feature #1712: DatastoreXML class for the scheduler
feature #1712: DatastorePoolXML for scheduler. Load Datastore information to perform storage scheduling
feature #1712: Make Scheduler class more general to accomodate Storage Policies
feature #1712: Restructured scheduler main functions
feature #1712: Changed Match Resources Interface to accomodate Datastore scheduling
feature #1712: Fix memory leak
feature #1712: Basic DS scheduling in place
feature #1712: Rank for Datastores
feature #1712: Fix bug when scheduler template does not include policy attributes
feature #1712: Default for DEFAULT_DS_SCHED
feature #1712: Deployment and Migration API calls accept target system DS
feature #1712: Make use of datastore selection
feature #1712: Use constant for Cluster none
feature #1712: Couple host and system DS schedule
feature #1712: Use cluster system DS. If no DS is specified in onevm.deploy the default SYSTEM_DS will be used.
Feature #1712: Add Ds id to deploy action, cli, ruby & java oca
Feature #1712: Fix sched.conf syntax error
Feature #1712: If the ds_id is not defined, the first cluster system DS is used
Feature #1712 CLI: Show DS id in VM history, remove system_ds from cluster output
Feature #1712: Fix comments in sched.conf
Feature #1712: Fix resched. It was planning migrations to hosts using different system DS
feature #1712: Default DS selection code moved to Cluster class
Feature #1712: Fix scheduler to not add VM storage capacity for migrations
feature #1712: Add SCHED_DS_REQUIREMENTS and SCHED_DS_RANK to Sunstone
feature #1712: Add enforce and datastore option to deploy dialog
Feature #1712: Fix scheduler resched migration
Feature #1712: Allow to change DS type even if the DS is in a cluster
History
#1
Updated by Ruben S. Montero over 8 years ago
- Tracker changed from Request to Feature
This is interesting, moving it as feature to schedule for a future release...
#2
Updated by Ruben S. Montero about 8 years ago
- Category set to Core & System
- Target version set to Release 4.2
#3
Updated by Ruben S. Montero about 8 years ago
- Priority changed from Normal to High
#4
Updated by Ruben S. Montero almost 8 years ago
- Target version changed from Release 4.2 to Release 4.4
#5
Updated by Ruben S. Montero over 7 years ago
- Assignee set to Carlos Martín
#6
Updated by Carlos Martín over 7 years ago
- Status changed from New to Closed
- Resolution set to fixed