On Wed, Aug 25, 2010 at 02:30:01PM +0300, Avi Kivity wrote:
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.
Yes, it can on latest Fedora/RHEL6, using the netcf library. This is the new 'virsh iface-XXX' command set (and equivalent APIs). I've not updated the docs to cover this functionality yet though. It also does bonding, and vlans, etc Daniel -- |: 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 :|