Daniel P. Berrange wrote:
On Wed, Nov 19, 2008 at 11:20:08PM -0700, Jim Fehlig wrote:
Hi All,
I wanted to get folks thoughts on relaxing the requirement for bridge source device in network interface of domain XML, e.g. allowing
<interface type="bridge"> <mac address="aa:bb:cc:cc:ee:ff"/> </interface>
Currently, virDomainNetDefParseXML() in src/domain_conf.c will fail such configuration. Since this is common code between backends I'm not sure how allowing this config will affect the various virtualizers.
Xen's vif-bridge script will try to find a bridge if one is not specified, which perhaps is dubious behavior, but nonetheless convenient in migration scenarios where the target host may have a different bridge name (br1 vs br0 for example). IIRC, qemu's qemu-ifup script is not as forgiving in the absence of a bridge name.
I don't particularly like this idea. While letting it automatically pick the bridge devices may happen to work in some cases, it'll quietly go wrong horribly in other scenarios. Xen's vif-bridge has caused real bugs through this behaviour even on a single machine. eg, its happily automatically picking br0 for months, then someone adds a new completely unrelated bridge to the machin, say br4, and the next reboot vif-bridge suddenly decides it prefers br4 for your guest.
Yep, have seen this behavior when leaving source unspecified.
I think it is not unreasonable in the case of migraiton to require that the bridge names are configured the same on source and destination machine, and explicitly including bridge names will let apps using libvirt query the source & destination host before doing migraiton and verify that br0 on the source is configured to use the same network as br0 on the destination.
Agreed. Thanks for the feedback Daniel. Jim