[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] KVM doesn't send an arp announce after live migrating a domain



On Wed, Aug 25, 2010 at 02:05:45PM +0300, Avi Kivity wrote:
>  On 08/25/2010 01:52 PM, Daniel P. Berrange wrote:
> >
> >>I think libvirt is doing something about this, copying list for further
> >>info.
> >libvirt doesn't set a policy for this. It provides an API for
> >configuring host networking, but we don't override the kernel's
> >forward delay policy, since we don't presume that all bridges
> >are going to have VMs attached. In any case the API isn't available
> >for Debian yet, since no one has ported netcf to Debian, so I
> >assume the OP set bridging up manually. The '15' second default is
> >actually a kernel level default IIRC.
> >
> >The two main host network configs recommended for use with libvirt+KVM
> >(either NAT or bridging) are documented here:
> >
> >   http://wiki.libvirt.org/page/Networking
> 
> From that page:
> 
> # virsh net-define /usr/share/libvirt/networks/default.xml
> 
> From my copy of that file:
> 
> <network>
>   <name>default</name>
>   <bridge name="virbr0" />
>   <forward/>
>   <ip address="192.168.122.1" netmask="255.255.255.0">
>     <dhcp>
>       <range start="192.168.122.2" end="192.168.122.254" />
>     </dhcp>
>   </ip>
> </network>
> 
> So it looks like the default config uses the kernel default?  If libvirt 
> uses an existing bridge I agree it shouldn't hack it, but if it creates 
> its own can't it use a sensible default?

That is the NAT virtual network. That one *does* default to a forward
delay of 0, but since it is NAT, it is fairly useless for migration
in anycase. If you do 'virsh net-dumpxml default' you should see that
delay='0' was added

The OP was using bridging rather than NAT though, so this XML example
doesn't apply. My comments about libvirt not overriding kenrel policy
for forward delay were WRT full bridging mode, not the NAT mode[1]

Regards,
Daniel

[1] Yes, the NAT mode uses a bridge as an implementation detail, but
    there's no physical NIC in that bridge - it is merely to connect
    the TAP devices together. Connection to the LAN is forwarded + NAT.
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]