← Back to team overview

openstack team mailing list archive

Re: Live migration with mult_host - only ugly approach?

 

Alternate approach:

Give all hosts the .1 gateway address:

diff --git a/nova/network/manager.py b/nova/network/manager.py
index 2d62581..e6a0ba8 100644
--- a/nova/network/manager.py
+++ b/nova/network/manager.py
@@ -477,8 +477,7 @@ class NetworkManager(manager.SchedulerDependentManager):
     def _get_dhcp_ip(self, context, network_ref, host=None):
         """Get the proper dhcp address to listen on."""
         # NOTE(vish): this is for compatibility
-        if not network_ref['multi_host']:
-            return network_ref['gateway']
+        return network_ref['gateway']
 
         if not host:
             host = self.host

and make sure to create ebtables/iptables rules on every host that blocks traffic from that address and broadcast traffic on that network between the hosts.  That way all of the hosts will have the .1 address on the bridge so migrated instances will still use the local ip as the gateway.

Note: there is potential for some odd failures due to the mac address of the .1 address changing through migration and the vm having a different mac address in its arp cache, but theoretically it should be able to do a broadcast dhcp request to continue to dhcp.

Vish

On Dec 26, 2011, at 1:23 AM, 이준원 (Joonwon Lee) wrote:

> Dear all.
> 
> We want to use Kei's live migration feature while adopting Vish’s
> multi_host network configuration, but there are problems as noted below by
> Vish.
> http://etherpad.openstack.org/live-migration-with-multi-host
> 
> Is there any way to change the gateway of a VM instance?
> (i.e. is it possible to force a VM instance to request DHCP server again?)
> 
> As I found no clue on this, it may be better to implement storing the
> history of live migration in DB. And we should keep the iptables rules and
> DHCP entries(in nova-br100.conf) for VM instances migrated in two or more
> hosts. I'm going to take this *ugly* approach without a good idea.
> 
> The common gateway cannot be set for us because the network of
> VMs(10.x.x.x) is different from the network of external
> switches/routers(public IPs).
> Also the minimum DHCP expiration time is 120 seconds according to the man
> page. Two minutes are too long. Even worse, a VM instance won't change the
> gateway set by DHCP until rebooting with my test.
> 
> Please help me finding a better approach, if any.
> Thanks in advance.
> 
> Joonwon Lee
> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp



References