Mailing List Archive: OpenStack: Dev

Re: [OpenStack][Nova] deference between live-migration and migrate

Index | Next | Previous | View Threaded

John.Garbutt at citrix

May 25, 2012, 2:36 AM

Post #1 of 5 (297 views)
Permalink

Re: [OpenStack][Nova] deference between live-migration and migrate

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?

I am in the process of adding Live migration support to XenServer:
https://blueprints.launchpad.net/nova/+spec/xenapi-live-migration

If people like the idea, I should get chance to draft and implement this for Folsom, but I am happy for others to do this if they are also interested.

Cheers,
John

From: openstack-bounces+john.garbutt=eu.citrix.com [at] lists [mailto:openstack-bounces+john.garbutt=eu.citrix.com [at] lists] On Behalf Of Eric Luo
Sent: 25 May 2012 09:55
To: openstack [at] lists
Subject: [Openstack] [OpenStack][Nova] deference between live-migration and migrate

Hello ,all
I saw there are tow commands in nova

live-migration Migrates a running instance to a new machine.
migrate Migrate a server.

I know that live-migration means "live migration" of an instance.

But what is this "migrate " for ? And what does "Migrate a server." mean here :) Does it mean "Migrates a non-running instance to a new machine" here?

Thank you!

Best regards!

Eric Luo
2012-05-25

vishvananda at gmail

May 31, 2012, 11:10 AM

Post #2 of 5 (305 views)
Permalink

Re: [OpenStack][Nova] deference between live-migration and migrate [In reply to]

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 am in the process of adding Live migration support to XenServer:
> https://blueprints.launchpad.net/nova/+spec/xenapi-live-migration
>
> If people like the idea, I should get chance to draft and implement this for Folsom, but I am happy for others to do this if they are also interested.
>
> Cheers,
> John

david.kranz at qrclab

May 31, 2012, 11:29 AM

Post #3 of 5 (291 views)
Permalink

Re: [OpenStack][Nova] deference between live-migration and migrate [In reply to]

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

Tim.Bell at cern

May 31, 2012, 12:03 PM

Post #4 of 5 (293 views)
Permalink

Re: [OpenStack][Nova] deference between live-migration and migrate [In reply to]

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 [at] lists
[mailto:openstack-bounces+tim.bell=cern.ch [at] lists] On Behalf Of
David Kranz
Sent: 31 May 2012 20:29
To: openstack [at] lists
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

Attachments:

smime.p7s (5.08 KB)

John.Garbutt at citrix

Jun 1, 2012, 2:26 AM

Post #5 of 5 (294 views)
Permalink

Re: [OpenStack][Nova] deference between live-migration and migrate [In reply to]

> From: Vishvananda Ishaya [mailto:vishvananda [at] gmail]
> Keep in mind that we actually have three options
Good point, I forgot about resize.

I guess we have:
- Live Migrate (with/without block migrate)
- (Non-live) Migrate
- Resize

I guess the more general way of looking at this is having an "optional scheduler hint":
- user might want to live-migrate to a different availability zone
- user might want to resize to same availability zone
- admin might what to migrate (live or otherwise) to a specific server

> 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.
Forgot about that, I like that too. To get the same semantics, I guess it would be:
stop VM, snapshot VM, start new VM, destroy old VM, allow user to delete snapshot.
Rollback just resumes VM and deletes snapshot.

I guess you could have something like "this will use data" warning you get on mobiles, but something like:
"This operation involves you being billed for a snapshot. You may delete the snapshot once the operation has completed"

What do people think about the billing issues from this change?

Cheers,
John

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack [at] lists
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads