openstack team mailing list archive

[Alex Glikson <GLIKSON@xxxxxxxxxx>]

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.513@xxxxxxxxx>
To:     chris@xxxxxxxxxxxxxxxxxxxxxx, 
Cc:     Alex Glikson/Haifa/IBM@IBMIL, openstack@xxxxxxxxxxxxxxxxxxx
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 <chris@xxxxxxxxxxxxxxxxxxxxxx>
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:GLIKSON@xxxxxxxxxx] 
Sent: Friday, May 31, 2013 7:34 AM
To: chris@xxxxxxxxxxxxxxxxxxxxxx
Cc: openstack@xxxxxxxxxxxxxxxxxxx
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" <chris@xxxxxxxxxxxxxxxxxxxxxx> 
To:        <openstack@xxxxxxxxxxxxxxxxxxx>, 
Date:        31/05/2013 02:12 PM 
Subject:        [Openstack] VM disk affinity during live migration 
Sent by:        "Openstack" <
openstack-bounces+glikson=il.ibm.com@xxxxxxxxxxxxxxxxxxx> 




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@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp