From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yosuke Iwamatsu Subject: Re: [PATCH] incompatibility of netfront driver with bonding module Date: Thu, 10 Apr 2008 21:05:24 +0900 Message-ID: <47FE0284.7030400@ab.jp.nec.com> References: <78C9135A3D2ECE4B8162EBDCE82CAD77034D3337@nekter> <47F4794C.2040707@ab.jp.nec.com> <78C9135A3D2ECE4B8162EBDCE82CAD7703563BAF@nekter> <47F9C7D4.6050108@ab.jp.nec.com> <78C9135A3D2ECE4B8162EBDCE82CAD77035ED4C2@nekter> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <78C9135A3D2ECE4B8162EBDCE82CAD77035ED4C2@nekter> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Masroor Vettuparambil Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Thank you. Now I'm curious if you really succeeded the live migration of passthrough domains, using pci-hotplug and bonding. (Currently I have one testing machine and can only try local migration.) -- Yosuke Masroor Vettuparambil wrote: > The attached patch provides the arp link monitoring support for > netfront. > Also it prevents setting the mac while the interface is up. > > Regards > Masroor > > -----Original Message----- > From: Yosuke Iwamatsu [mailto:y-iwamatsu@ab.jp.nec.com] > Sent: Monday, April 07, 2008 12:36 PM > To: Masroor Vettuparambil > Cc: xen-devel@lists.xensource.com > Subject: incompatibility of netfront driver with bonding module > > Masroor Vettuparambil wrote: >> Thanks for your work. >> I could manage the live migration using a simple check in netfront >> while resuming on destination. >> >> if (!(netdev->flags & IFF_SLAVE)) >> memcpy(netdev->dev_addr, info->mac, ETH_ALEN); But this will > work >> only if the interface is enslaved. >> >> In your patch, should we let to change the MAC while interface is up? > > It might be desirable, but I don't know for now if we can achieve it > easily. > >> I need to include the support for arp link monitoring to netfront. > > Is link monitoring really necessary? > If you mean you use link monitoring to change the active slave of the > bond0, I think we can do that using ifenslave command inside domU. > #ifenslave bond0 eth1 -> enslave new netif(eth1) to bonding device > #ifenslave -d bond0 eth0 -> release old netif(eth0) from bonding > > Regards, > Yosuke > >> Regards >> Masroor, >> >> >> -----Original Message----- >> From: Yosuke Iwamatsu [mailto:y-iwamatsu@ab.jp.nec.com] >> Sent: Thursday, April 03, 2008 12:00 PM >> To: Masroor Vettuparambil >> Cc: xen-devel@lists.xensource.com >> Subject: incompatibility of netfront driver with bonding module >> >> Hi, >> >> Masroor Vettuparambil wrote: >>> 1. Normally, bonding will inherit the mac from the first slave and >>> assign it to all the other slaves added later. So the mac of vif will > >>> be updated. But during migration, the mac of vif is getting updated >>> from xenstore(/vm/). So how about having a set_mac_address entry in >>> netfront that update the xenstore? >>> So I need help, especially on #1. Is it ok to update the xenstore >>> /vm/ >>> keys from domU? how to do this? >> I tried a bit to find out the way to update /vm/ keys from frontend, >> but didn't succeed. Either way, I don't think it is a good idea to >> update the xenstore key of the vif mac address, because the original >> mac will be lost and we won't be able to reset it e.g. after the guest > reboot. >> So the attached patch adds set mac_address() support to netfront. >> It doesn't touch xenstore at all, but just preserves the modified mac >> address in netfront_info structure and keeps using it after migration. >> >> Thanks, >> ----------------------- >> Yosuke Iwamatsu >> NEC Corporation >