Nova/EucalyptusMigrationSpec
- Launchpad Entry: NovaSpec:bexar-eucalyptus-migration
- Created: 2010-11-17
- Contributors: SorenHansen
Contents
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 (which is usually connected to the same LAN as the host's primary interface). Assigning IP's is not Nova's job, but rather that of an existing dhcp server on the LAN or some other mechanism.
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.
MANAGED network mode
The bells-and-whistles networking mode. Should be identical to what VlanManager provides, I believe.
MANAGED-NOVLAN network mode
The slightly amputated bells-and-whistles networking mode (useful if you can't use VLAN's for some reason). It does not use vlans to keep VM's separate from one another and from the "real LAN", so a dhcp server on the LAN will mess things up (as it will conflict with the one provided by Eucalyptus). Not sure yet how to map this to Nova.
STATIC network mode
Should be identical to what FlatManager (or FlatDHCP?) provides, if I understand it correctly.
