Right. A slightly different approach (requiring admin effort) would be to define two host aggregates -- one reporting SSD as one of the capabilities of its hosts, and another one reporting SAS. Then the admin can attach the corresponding capability as a an extra spec of an instance flavor, and use Filter Scheduler with AggregateInstanceExtraSpecsFilter to make sure instances would not be placed on a hosts which belong to a wrong aggregate. All this can be done already (see http://docs.openstack.org/trunk/openstack-compute/admin/content/host-aggregates.html ). The missing piece (which is, I believe, going to be resolved in Havana) would be to prevent admin from live-migrating an instance to a wrong location manually (but this wouldn't be an issue if the admin live-migrates without explicitly specifying destination, as Jay pointed out).
Regards, Alex From: Lau Jay <jay.lau....@gmail.com> To: ch...@christopherbartels.com, Cc: Alex Glikson/Haifa/IBM@IBMIL, openstack@lists.launchpad.net Date: 01/06/2013 07:39 AM Subject: Re: [Openstack] VM disk affinity during live migration Hi Chris, I think that you are using live migration without specifying target host, right? OpenStack cannot handle your case for now, but it has very flexible framework to enable you DIY your migration logic. 1) Make sure SSD or SAS can be reported by nova compute, you might want to update nova compute driver to report those metrics? 2) Add a new scheduler filter to do your logic checking for SSD and SAS. Thanks, Jay 2013/6/1 Chris Bartels <ch...@christopherbartels.com> Thanks for your reply. Your reply implies that its possible to ensure that the disks stay on the right target manually. What would you have to do to make sure this happened? The SAS space is 228GB & the SSD space is only 64GB. So the SAS disk image wouldn?t fit on the SSD, but the SSD image would fit on the SAS, so the migration system I imagine wouldn?t be able to screw it up since it would have to keep the large SAS image on the SAS target, and would then only be able to place the smaller SSD image on the SSD. But you say it?s a work in progress so that could mean anything could happen. What does the actual process look like when I would migrate a VM from one server to another? What exactly would I have to do to make sure it went right? Thanks. From: Alex Glikson [mailto:glik...@il.ibm.com] Sent: Friday, May 31, 2013 7:34 AM To: ch...@christopherbartels.com Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] VM disk affinity during live migration There is an ongoing work to refactor live migration code, including use of scheduler to find/validate placement. At the moment the admin would need to make sure he/she is doing the right thing. Regards, Alex From: "Chris Bartels" <ch...@christopherbartels.com> To: <openstack@lists.launchpad.net>, Date: 31/05/2013 02:12 PM Subject: [Openstack] VM disk affinity during live migration Sent by: "Openstack" < openstack-bounces+glikson=il.ibm....@lists.launchpad.net> Hi, Please forgive me if I?ve asked already here on the list- I didn?t get a reply & I really need an answer, so I?m asking again in simpler terms this time. If I have a cluster of servers, each with spindle drives & SSDs, how can I be sure VM disks which reside on spindle drives migrate to spindle drives & those which reside on SSDs stay on SSDs as they migrate between servers? Thanks, Chris_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
