You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Feature Reference

CLOUDSTACK-10024 - Getting issue details... STATUS

Feature Specifications

As a Cloud Owner
I want to migrate my existing guest networks to another physical network infrastructure
In order to make use of the extra features SDN provides.

Hypervisors:

  1. Vmware

  2. KVM

Network Types

  1. Isolated

  2. VPC

  3. Shared

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, so that the right physical network can be selected.

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

  • Migrating a network will keep the VM running on the same host, so there are no issues for multinic VM's, when you would migrate all networks one by one.

  • VR will be recreated. The new VR will get a new guest IP, if it is no longer the gateway (target Network offering doesn’t specify VR as provider of source nat)
    New VR will get the first free IP i.s.o. Gateway IP

  • We will update the DB object with the details of the new implementation.
    To be able to correctly cleanup the old implementation, we make a copy of the network.

API Changes:

New API’s:

  • migrateNetwork

    • Parameter: networkId (UUID)

    • Parameter: networkOfferingId (UUID)

  • migrateVpc

    • Parameter: vpcId (UUID)

    • Parameter: vpcOfferingId (UUID)

    • Parameter: networkOfferingId[] for each tier

    • Parameter: resume (boolean)

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

  • By default indicate the error and fail

  • Unless “resume” is explicitly set to True, then try to resume as much as possible from the corrupt entry state.

 

Manager Implementation

Migrate Network

  • Make copy for original network (moving along VR and nics).

  • Implement on new Physical network using guest network guru,
    Found by looking up the tag of the offering.

  • Implement services (Dhcp, static nat, source nat, …)

    • Deploy VR if needed

  • Migrate vnics to new physical network

    • Prepare Nic on Guru (add vport, vm interface, vm)

    • Prepare Nic on Element (apply acl rules, …)

    • Send ReplugNicCommand to host.

    • Remove nic on native element and guru

  • Shutdown network services on old physical network.

    • Undeploy VR if needed

  • Shutdown network infrastructure on old physical network.

  • Delete original network

Migrate VPC

  • Make copy for original VPC.

  • Implement VPC on new Physical network using guest network guru,
    Found by looking up the tag of the network offerings

  • Migrate Tiers

    • Make copy for original network (moving along VR and nics).

    • Implement network on new Physical network using guest network guru,

    • Implement services (Dhcp, static nat, source nat, …)

      1. Deploy VR if needed

    • Migrate vnics to new physical network

      1. Prepare Nic on Guru (add vport, vm interface, vm)

      2. Prepare Nic on Element (apply acl rules, …)

      3. Send ReplugNicCommand to host.

      4. Release nic on native element and guru.

    • Shutdown network services on old physical network.

      1. Undeploy VR if needed

    • Shutdown network infrastructure on old physical network.

    • Delete original network

  • Shutdown vpc on old physical network.

  • Delete original vpc

Hypervisor Changes

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

Agent API

ReplugNicCommand

KVM

Allow both OVS and LinuxBridge on one host at the same time.

Currently only one VifProvider can be specified.

(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: 

  •   US-1-1 : Migrating from non-persistent (no VR deployed) to non-persistent offfering 
  •   US-1-2 : Migrating from persistent to non-persistent offering (with removal of VR) 
  •   US-1-3 : Migrating from non-persistent (no VR deployed) to persistent offering 
    • Without VR contained in destination offering  
    • With VR contained in destination offering (we would need to deploy the VR) 
  • US-1-4 : Migrating from persistent to persistent offering  
    • Without VR contained in destination offering (undeploy VR) 
    • With VR contained in destination offering  (redeploy VR)

 

 

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 :

  • US-2-1 : Migrating from non-persistent Isolated Network offering to Nuage based offering without VR in offering or non-persistent Nuage based offeri
  • US-2-2 : Migrating from non-persistent Isolated Network offering to persistent Nuage based offering with VR in offering  (deploy VR)
  • US-2-3 : Migrating from persistent Isolated Network offering to Nuage based offering without VR in offering or to non-persistent Nuage based offering (undeploy VR) 
  • US-2-4 : Migrating from persistent Isolated Network offering to persistent Nuage based offering with VR in offering  (redeploy VR)

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 : 

  • US-3-1 : Migrating to an offering without VR providing any service (VR to be undeployed)
  • US-3-2 : Migrating to an offering with VR  providing services (VR to be redeployed)




  • No labels