openstack team mailing list archive

[Tim Bell <Tim.Bell@xxxxxxx>]

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.

 

How about we move the API flag to a text field for the migration type ?

 

For private clouds without billing concerns, a snapshot/restart option may
be more attractive.

 

Tim

 

From: openstack-bounces+tim.bell=cern.ch@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-bounces+tim.bell=cern.ch@xxxxxxxxxxxxxxxxxxx] On Behalf Of
David Kranz
Sent: 31 May 2012 20:29
To: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] [OpenStack][Nova] deference between live-migration
and migrate

 

On 5/31/2012 2:10 PM, Vishvananda Ishaya wrote: 

 

On May 25, 2012, at 2:36 AM, John Garbutt wrote:





I have been meaning to draft a blueprint around this.

 

What we have today:

.         Migrate: move a VM from one server to another, reboots across the
move (I think) and destination is picked by scheduler

.         LiveMigration: move a VM form one server to another, VM doesn't
appear to reboot, need to specify the destination

 

I propose we extent the Migrate API (thinking about nova CLI here really) to
include:

.         Optional Flag to force non-live migration, default to live
migration

.         Optional destination host, by default let the scheduler choose

.         Deprecate the existing live migration API and CLI calls

What do people think?

 

+1

 

Keep in mind that we actually have three options:

 

live migration on shared storage

live migration without shared storage (block migration)

resize/migrate

 

Yun actually suggested that resize/migrate be simplified to do the following
instead of scping the file over:

 

 * snapshot to glance

 * boot new image from snapshot

 

This would definitely simplify the code, unfortunately it could have
billing/metering repercussions.

 

Vish

 

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
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?

 -David

Attachment: smime.p7s
Description: S/MIME cryptographic signature