Backlog #3249
VM scheduling classes
| Status: | Pending | Start date: | 10/18/2014 | ||
|---|---|---|---|---|---|
| Priority: | High | Due date: | 10/23/2014 | ||
| Assignee: |  军卫 刘 | % Done: | 50% | ||
| Category: | Scheduler | Estimated time: | 40.00 hours | ||
| Target version: | - |
Description
We have re-defined this issue as scheduling classes. The scheduler will be able to include specific policies for a VM class:
SCHED_POLICY = [
VM_CLASS = "production"
SCHED_REQUIREMENTS=...
SCHED_RANK=...
SCHED_DS_REQUIREMENTS=...
SCHED_DS_RANK=...
]
VMs can be tagged with a class (by adding it to the template) and it will get the scheduling attributes for the class. For example, a given VM class would be set to use a specific system ds.
Original Request:
In opennebula 3.8 or later version， one cluster has only one system datastore. we specify system datastore number in the cluster template by SYSTEM_DS="id". What's more, system datastore has a TM_MAD attribute that specifies the transfer driver type - ssh or shared. Based on the above description, One cluster can either deploy local virtual machine or share storage virtual machine.If we want to improve the utilization of host, we can deploy local vm and shared vm in the same cluster, even in the same host!
History
#1
Updated by Carlos Martín over 6 years ago
- Status changed from Pending to Closed
- Resolution set to duplicate
Hi,
What you describe is already available in more recent versions, 3.8 is from 2 year ago!
Clusters can have more than one system DS (e.g. shared and ssh), even the scheduler is aware and can choose the most appropriate storage to deploy the VMs.
Regards.
#2
Updated by Carlos Martín over 6 years ago
- File 1.jpg added
- File 2.jpg added
- Tracker changed from Feature to Request
- Status changed from Closed to Pending
- Priority changed from High to Normal
Comments copied from an email:
Hi, I think our ideas are a little different. In your design, your different system datastore are in different storage, for example, two system datastore 100 (/var/lib/one/datastores/100) and 101 (/var/lib/one/datastores/101), 100's whole storage space maybe in shared storage (NFS, or LUN) and this is a big and consecutive storage. 101's whole storage space maybe in the local filesystem.
My idea is the shared datastore is not a nfs datastore, for example, datastore 124 is a shared system datastore. virtual machine' disk in datastore 124 is a volume in shared storage.
I think the difference between us is here.
[See screenshots 1 & 2.jpg]
#3
Updated by 军卫 刘 over 6 years ago
After i read the system datastore docs of opennebula 4.8, I found one cluster can support multiple system datastores at the same time. These system datastores in one clusters has the same attribute of "SYS_DS=YES", we can chose by vm template attribute "SCHED_DS_REQUIREMENTS". I think my idea is very familiar with that. There alse support multiple system datastores but these datastores have different attribute, for example, ssh system datastore has attribute "SYS_DS_SSH = YES" and shared system datastore has "SYS_DS_SHARED = YES", and I chose datastore by the type of virtual machine in the virtual machine template as well, for example, I add a "VM_TYPE" attribute, VM_TYPE=0 is local storage virtual machine , VM_TYPE=1 is shared storage virtual machine. so when I get a system datatore id, i use VM_TYPE to select the system datastore of "SYS_DS_XX".
I think we are the same in the theory, dou you suggest whether or not i shoud submit the patch?
#4
Updated by Ruben S. Montero over 6 years ago
军卫 刘 wrote:
After i read the system datastore docs of opennebula 4.8, I found one cluster can support multiple system datastores at the same time. These system datastores in one clusters has the same attribute of "SYS_DS=YES", we can chose by vm template attribute "SCHED_DS_REQUIREMENTS". I think my idea is very familiar with that. There alse support multiple system datastores but these datastores have different attribute, for example, ssh system datastore has attribute "SYS_DS_SSH = YES" and shared system datastore has "SYS_DS_SHARED = YES", and I chose datastore by the type of virtual machine in the virtual machine template as well, for example, I add a "VM_TYPE" attribute, VM_TYPE=0 is local storage virtual machine , VM_TYPE=1 is shared storage virtual machine. so when I get a system datatore id, i use VM_TYPE to select the system datastore of "SYS_DS_XX".
I think we are the same in the theory, dou you suggest whether or not i shoud submit the patch?
Let me re-word this to see if I'm getting it:
0.- You have implemented a multiple system-ds feature on top of OpenNebula 3.8
1.- Now we have multiple system ds, and storage can be scheduled using SCHED_DS_REQUIREMENTS and SCHED_DS_RANK
2.- System Datastores are tagged with custom attributes SYS_DS_TYPE=SSH or SYS_DS_TYPE=SHARED and those used to setup a SCHED_DS_REQUIREMENTS expression.
3.- You need a way to translate VM types to specific scheduling policies, right? So VM of class 0 will automatically get SCHED_DS_REQUIREMENTS="SYS_DS_TYPE = SSH"
So, we can reformulate this issue as scheduling classes, as a way to assgin a scheduling policy to a set of VMs. Currently we have a global scheduling policy in sched.conf, but we could add sched classes like this
SCHED_POLICY [
VM_CLASS = "type_shred"
SCHED_DS_REQUIREMENTS="SYS_DS_TYPE=SHARED"
]
If that fits your use case, I see this change as described above, an extension of the default policies for VMs.
#5
Updated by Ruben S. Montero over 6 years ago
- Tracker changed from Request to Backlog
- Subject changed from Deploy local vm and shared vm in the same cluster and in the same host to VM scheduling classes
- Description updated (diff)
- Category changed from Core & System to Scheduler
- Priority changed from Normal to High