[one-dev] Scheduler decisions regarding storage

Stuart Longland stuartl at vrt.com.au
Wed Jun 4 19:32:28 PDT 2014


Hi all,

I've decided to pull my finger out and clone a copy of the OpenNebula
git repository and actually dive right into the core of it.

The plan is to try and implement a caching back-end, rather than having
it bolted onto the storage driver the way it is presently in our
'cephcache' driver.

The thought is that the host has a portion of disk allocated using LVM
that is used for local cache for central storage.  This helps speed up
the disk access on VMs running there, whilst still allowing live
migration and hot backups to take place with central storage.

Our specific use case will be LVM local storage, FlashCache as the
caching interface and Ceph as the central storage, but ideally, these
parts should be interchangeable.

A first step I figured, would be to get the scheduler to consider
storage in terms of datastore storage, and cache, as being separate
resources.

So the host would, via its monitor script, advertise a quantity of cache
storage as being available, and the host template would specify how that
storage is divvied up (i.e. LVM), and what cache mechanism is in use
(i.e. FlashCache, bcache, …)

In order to make a decision on this, the system needs to know how much
cache the VM needs.  I went digging in the OpenNebula code and came
across VirtualMachine::get_requirements in src/vm/VirtualMachine.cc:

> void VirtualMachine::get_requirements (int& cpu, int& memory, int& disk)
> {
>     istringstream   iss;
>     float           fcpu;
> 
>     if ((get_template_attribute("MEMORY",memory) == false) ||
>         (get_template_attribute("CPU",fcpu) == false))
>     {
>         cpu    = 0;
>         memory = 0;
>         disk   = 0;
> 
>         return;
>     }
> 
>     cpu    = (int) (fcpu * 100);//now in 100%
>     memory = memory * 1024;     //now in Kilobytes
>     disk   = 0;
> 
>     return;
> }

What I observe though, is that the disk storage always returns 0.  My
plan was to expand on this by adding an extra parameter (int& cache),
and I'd use whatever code is present to calculate disk requirements to
figure out how much to cache and thus, calculate the cache output.

Is this 'disk' parameter a future expansion in the API or something that
is being phased out?
-- 
Stuart Longland
Systems Engineer
     _ ___
\  /|_) |                           T: +61 7 3535 9619
 \/ | \ |     38b Douglas Street    F: +61 7 3535 9699
   SYSTEMS    Milton QLD 4064       http://www.vrt.com.au




More information about the Dev mailing list