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?
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
