On 08/25/2010 02:15 PM, Daniel P. Berrange wrote:
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]
Yes, of course.
Can't libvirt also create a non-NAT bridge? Looks like it would prevent
a lot of manual work and opportunity for misconfiguration.
--
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
