Difference between revisions of "Nova/EucalyptusMigrationSpec"
(Add more info on networking (still wip)) |
(Fixed the horribly broken formatting from my last "commit".) |
||
| Line 57: | Line 57: | ||
== Implementation == | == Implementation == | ||
| − | === SYSTEM network mode == | + | === SYSTEM network mode === |
Dead simple networking mode where VM's are simply attached to a bridge. | Dead simple networking mode where VM's are simply attached to a bridge. | ||
To support this, We need a new [[NetworkManager]]: [[NoOpManager]]. | To support this, We need a new [[NetworkManager]]: [[NoOpManager]]. | ||
| − | * It will not do any network configuration, other than perhaps sanity checking | + | * It will not do any network configuration, other than perhaps sanity checking (making sure that the given bridge exists and actually is a bridge). |
| − | + | * allocate_fixed_ip will return some sort of NULL value (0.0.0.0 or `::` or something), and have no side effects. | |
| − | * allocate_fixed_ip will return some sort of NULL value (0.0.0.0 or :: or | + | * allocate_floating_ip will raise an exception ([[NotSupportedException]] or something). This should bubble up to the API. |
| − | |||
| − | * allocate_floating_ip will raise an exception ([[NotSupportedException]] or something). | ||
| − | |||
* Pretty much everything else should be no-ops. | * Pretty much everything else should be no-ops. | ||
Revision as of 12:37, 18 November 2010
- Launchpad Entry: NovaSpec:bexar-eucalyptus-migration
- Created: 2010-11-17
- Contributors: SorenHansen
Summary
Provide a migration path from Eucalyptus to Nova
Release Note
We added a tool that lets you import users, images, volumes, etc. from an existing Eucalyptus installation into Nova, making it easy to migrate.
Rationale
I'm guessing there's some number of Eucalyptus installations out there. They may have already spent a lot of time setting up users, uploaded lots of images, etc. Removing that obstacle for migration seems like a really good thing to do.
User stories
Dave runs Eucalyptus now, but wants to test out Nova to see how it compares. He plays around with Nova for a little bit, decides it's awesome and wants to switch. He fires up nova-import-from-eucalyptus, points it at his Eucalyptus installation which proceeds to migrate all his settings over. Once it's done, he stops Eucalyptus, starts Nova, and none of the users notice the difference.
Design
The data that needs migrating is:
- Users
- Volumes
- Images
- Image metadata
- Elastic IP's
- Security Groups
- Keypairs
- Fixed IP's
- Instances (only if we attempt a live migration)
A lot of this (everything except users, we think) can be extracted using the EC2 API with admin privileges from Eucalyptus. We'll have to put them in the database directly (since going through the API to write this will assign new ID's to everything).
The project concept is unique to Nova, so the migration process should just add a project for each user.
Images may not already have been assembled by Eucalyptus (this doesn't happen until it's requested the first time). It is believed this will happen when it's fetched using a plain HTTP GET.
We also need to support the network models that Eucalyptus supports:
- System
- Managed
- Managed-novlan
- Static
See the docs at http://open.eucalyptus.com/wiki/EucalyptusNetworkConfiguration_v2.0
Implementation
SYSTEM network mode
Dead simple networking mode where VM's are simply attached to a bridge.
To support this, We need a new NetworkManager: NoOpManager.
- It will not do any network configuration, other than perhaps sanity checking (making sure that the given bridge exists and actually is a bridge).
- allocate_fixed_ip will return some sort of NULL value (0.0.0.0 or `::` or something), and have no side effects.
- allocate_floating_ip will raise an exception (NotSupportedException or something). This should bubble up to the API.
- Pretty much everything else should be no-ops.
The virt drivers need to be extended to understand this mode. For the libvirt driver, for instance, this means that it has to realise we don't actually know the IP of the guest and not attempt to set up the nwfilter stuff.
