----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Gilad Chaplik" <gchaplik(a)redhat.com>
> Cc: "Jorick Astrego" <j.astrego(a)netbulae.eu>, "users"
<users(a)ovirt.org>
> Sent: Sunday, April 6, 2014 7:06:51 PM
> Subject: Re: [Users] scheduling storage migration
>
> On 04/06/2014 06:16 PM, Gilad Chaplik wrote:
>> ----- Original Message -----
>>> From: "Itamar Heim" <iheim(a)redhat.com>
>>> To: "Jorick Astrego" <j.astrego(a)netbulae.eu>
>>> Cc: "users" <users(a)ovirt.org>
>>> Sent: Friday, April 4, 2014 3:52:01 PM
>>> Subject: Re: [Users] scheduling storage migration
>>>
>>> On 04/04/2014 03:34 PM, Jorick Astrego wrote:
>>>>
>>>> On Fri, 2014-04-04 at 15:02 +0300, Itamar Heim wrote:
>>>>> On 04/04/2014 10:51 AM, Jorick Astrego wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I don't know if it's possible yet but can we schedule the
(live)
>>>>>> storage
>>>>>> migration?
>>>>>>
>>>>>> It would be awesome to have for example some VM data on SSD
storage
>>>>>> that
>>>>>> migrates to HDD storage when the VM is shutdown. Or have VM's
with high
>>>>>> IO load during specific times migrate to a high IO storage
domain
>>>>>> during
>>>>>> these hours.
>>>>>
>>>>> if the VM is down, you can move it, not (live) storage migration.
>>>>>>
>>>>>> I realize it will generate extra load while migrating but this
can be
>>>>>> planned for. Maybe the guys from glusterfs could enable storage
>>>>>> migration on their side so the migration can execute on the
storage
>>>>>> server triggered by ovirt, that would be even better performance
wise.
>>>>>
>>>>> in any case, you can script anything with the API...
>>>>>
>>>>
>>>> I was being lazy... So I can use the
>>>>
http://www.ovirt.org/Features/oVirtSchedulerAPI for this? Or do I have
>>>> to hack around with the engine api. I will spend some time diving into
>>>> it.
>>>
>>> you can use the scheduler api, but I don't remember it having an event
>>> for OnVmStop.
>>> you can also use it for a periodic "balancing" call, but for that,
you
>>> can also just use cron.
>>> in either case you will need to do the relevant api calls for moving the
>>> disks around. i'd go with the cron approach.
>>
>> What about a vdsm hook?
>
> you can't move things around not via engine or you will lose the sync
> between them
>
sure, meant using the python SDK within the hook (the trigger).