[libvirt] Relax requirement of bridge source device

Jim Fehlig jfehlig at novell.com
Thu Nov 20 21:34:22 UTC 2008


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




More information about the libvir-list mailing list