<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><base href="x-msg://1130/"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I would favour a field for the type of migration which allows future expansion… we’ve already got migrate, live migrate and block migrate but hypervisors may have further different flavours too in the future and the API should support the full set of options while encouraging convergence when there are common functionalities.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>How about we move the API flag to a text field for the migration type ?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>For private clouds without billing concerns, a snapshot/restart option may be more attractive…<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Tim<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'> openstack-bounces+tim.bell=cern.ch@lists.launchpad.net [mailto:openstack-bounces+tim.bell=cern.ch@lists.launchpad.net] <b>On Behalf Of </b>David Kranz<br><b>Sent:</b> 31 May 2012 20:29<br><b>To:</b> openstack@lists.launchpad.net<br><b>Subject:</b> Re: [Openstack] [OpenStack][Nova] deference between live-migration and migrate<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>On 5/31/2012 2:10 PM, Vishvananda Ishaya wrote: <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On May 25, 2012, at 2:36 AM, John Garbutt wrote:<o:p></o:p></p></div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I have been meaning to draft a blueprint around this.</span><span lang=EN-US><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span lang=EN-US><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>What we have today:</span><span lang=EN-US><o:p></o:p></span></p></div><div style='margin-left:36.0pt'><p class=MsoNormal style='text-indent:-18.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:Symbol;color:#1F497D'>·</span><span lang=EN-US style='font-size:7.0pt;color:#1F497D'> <span class=apple-converted-space> </span></span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Migrate: move a VM from one server to another, reboots across the move (I think) and destination is picked by scheduler</span><span lang=EN-US><o:p></o:p></span></p></div><div style='margin-left:36.0pt'><p class=MsoNormal style='text-indent:-18.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:Symbol;color:#1F497D'>·</span><span lang=EN-US style='font-size:7.0pt;color:#1F497D'> <span class=apple-converted-space> </span></span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>LiveMigration: move a VM form one server to another, VM doesn’t appear to reboot, need to specify the destination</span><span lang=EN-US><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><span lang=EN-US><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I propose we extent the Migrate API (thinking about nova CLI here really) to include:</span><span lang=EN-US><o:p></o:p></span></p></div><div style='margin-left:36.0pt'><p class=MsoNormal style='text-indent:-18.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:Symbol;color:#1F497D'>·</span><span lang=EN-US style='font-size:7.0pt;color:#1F497D'> <span class=apple-converted-space> </span></span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Optional Flag to force non-live migration, default to live migration</span><span lang=EN-US><o:p></o:p></span></p></div><div style='margin-left:36.0pt'><p class=MsoNormal style='text-indent:-18.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:Symbol;color:#1F497D'>·</span><span lang=EN-US style='font-size:7.0pt;color:#1F497D'> <span class=apple-converted-space> </span></span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Optional destination host, by default let the scheduler choose</span><span lang=EN-US><o:p></o:p></span></p></div><div style='margin-left:36.0pt'><p class=MsoNormal style='text-indent:-18.0pt'><span lang=EN-US style='font-size:11.0pt;font-family:Symbol;color:#1F497D'>·</span><span lang=EN-US style='font-size:7.0pt;color:#1F497D'> <span class=apple-converted-space> </span></span><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Deprecate the existing live migration API and CLI calls</span><span lang=EN-US><o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>What do people think?</span><span lang=EN-US><o:p></o:p></span></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>+1<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Keep in mind that we actually have three options:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>live migration on shared storage<o:p></o:p></p></div><div><p class=MsoNormal>live migration without shared storage (block migration)<o:p></o:p></p></div><div><p class=MsoNormal>resize/migrate<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Yun actually suggested that resize/migrate be simplified to do the following instead of scping the file over:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal> * snapshot to glance<o:p></o:p></p></div><div><p class=MsoNormal> * boot new image from snapshot<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>This would definitely simplify the code, unfortunately it could have billing/metering repercussions.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Vish<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I don't think it is documented that you need to set up ssh with credentials between compute nodes to make resize and block migration work. I also heard something<br>about there being a more secure way to do this than setting up ssh in this way. What is the "officially recommended" way to configure compute nodes for these operations?<br><br> -David<o:p></o:p></p></div></div></body></html>