Or: migrate networks to new physical network

Feature Reference

Feature Specifications

As a Cloud Owner
I want to migrate my existing guest networks to another physical network infrastructure
In order to leverage new network technologies, e.g. leverage SDN.

Hypervisors:

  1. KVM

  2. Vmware

Network Types

  1. Isolated

  2. VPC


Shared networks are not supported at this stage.

Architecture and Design

CloudStack supports multiple physical networks with guest traffic, but only when the guest traffic is given a tag. The network offering then also needs to specify the tag, in order to correlate it to a matching physical network.

CloudStack Core will be extended to support moving networks to another Physical Network, by adding API commands.

API Changes:

New API’s:

The networkOfferingId/vpcOfferingId specifies the target network/vpc offering, which as mentioned, uniquely determines the target physical network using its associated tag.

The API implementation will be made as re-entrant as possible.
E.g. if 2 network objects are found in the db for the specified networkId (UUID), it will

Manager Implementation

Migrate Network

During migration of a network the UUID of objects are swapped so that external system (like NuageVsp) will perceive the migration as a delete of the network on the old physical network followed by a reimplement on the new physical network. Because of this, orchestration systems can still use the same UUID's as before (the resulted objects in CloudStack will have the same UUID's except for the VR.).

Migrate VPC

During migration of a network the UUID of objects are swapped so that external system (like NuageVsp) will perceive the migration as a delete of the network on the old physical network followed by a reimplement on the new physical network. Because of this, orchestration systems can still use the same UUID's as before (the resulted objects in CloudStack will have the same UUID's except for the VR.).

Hypervisor Changes

Provide Agent command to change the bridge of a nic in one call.

Agent API

ReplugNicCommand

KVM

We need to allow both OVS and LinuxBridge on one host at the same time. This is not possible in the current implementation (only one VifProvider can be specified).
We changed the code  to look for the correct VifDriver, by asking each one to see, if a bridge with the given name exists, and let the default create the bridge if it isn’t found.

You can load both VifDrivers by having the following lines in /etc/cloudstack/agent/agent.properties

 

network.bridge.type=native

libvirt.vif.driver.Vpn=com.cloud.hypervisor.kvm.resource.OvsVifDriver

Resume support

Resume support is implemented for operators to have the ability to finish off a previously submitted migration command which halfway failed during its new network implementation. After correcting the cause of that failure, the operator can re-issue the same migration command, now with a resume parameter set to True.

The resume logic follows below table :

resume parameter value \ Network migration "state"

Good

Bad (but error resolved)

False (default)

Success

Fail (again)

True

Success

>> Success <<


Based on the resume parameter and the related field in the networks table, we “force” migration of a network even if the network offering of the network is already the same as the current network offering. In that case, we will use the network that is stored in the related field (DB table) as the already generated copy. Otherwise we follow the normal migration procedure.

The creation and migration of the network copy happens in a transaction block. The same happens for each nic that needs to be reassigned. The use of those transactions allow us to mark critical sections and never leave the DB in an unrecoverable state.

(TL;DR) Use cases

1: Migration of Isolated Network on Vmware 6.0, without VM’s deployed

Given a VMware host setup, prepared for migration
And
a physical network with VLAN encapsulation providing guest, management and storage networking
And
a new physical network providing guest traffic tagged as “target”
And
an isolated guest network in the VLAN physical network
And
a network offering equivalent to the offering of the guest network tagged with “target”,
When
I migrate the network using the target network offering
Then
the network is configured on the new physical network

This can be refined to: 

Note: US-1-3 and US-1-4 need persistent isolated network offering support with Nuage  (upstream PR is available)

2: Migration of Isolated Network on Vmware 6.0, with only stopped VM(‘s)

Given a VMware host setup
And
a physical network with VLAN encapsulation providing guest, management and storage traffic
And
a new physical network providing guest traffic tagged as “target”
And
an isolated guest network in the VLAN physical network
And
a network offering equivalent to the offering of the guest network tagged with “target”,
And
2 stopped vms in the guest network
When
I migrate the network using the target network offering
Then
the network is configured on the new physical network
And
the VMs and their interfaces are configured on the new physical network

This can be refined to :

3: Migration of Isolated Network on Vmware 6.0, with running VM(‘s)

Given a VMware host setup
And
a physical network with VLAN encapsulation providing guest, management and storage networking
And
a new physical network with Guest Traffic tagged as “target”
And
an isolated guest network in the VLAN physical network
And
a network offering equivalent to the offering of the guest network with tag “target”
And
2 vms in the guest network
When
I migrate the network using the target network offering
Then
the network is configured on the new physical network
And
the VMs and their interfaces are configured on the new physical network
And
the VMs can reach each other

This can be refined to :