Re: [Users] scheduling storage migration

From: "Itamar Heim" <iheim(a)redhat.com&gt; To: "Gilad Chaplik" <gchaplik(a)redhat.com&gt; Cc: "Jorick Astrego" <j.astrego(a)netbulae.eu&gt;, "users" <users(a)ovirt.org&gt; 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&gt; >> To: "Jorick Astrego" <j.astrego(a)netbulae.eu&gt; >> Cc: "users" <users(a)ovirt.org&gt; >> 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