So back to your original question - is the current VirtualBox bridge impl 'correct'. If it is doing ethernet layer bridging, then I think there is a strong argument that it is reasonably compliant. If there is a way todo bridging with VirtualBox + a bridge + TAP device (or equivalent), then that would definitely want to use type=bridge.
Thus the main question is whether to allow both modes to use type=bridge, or to change the existing mode to use type=ethernet. If we did the former, then one option is to add an extra attribute to the <source> device so you can indicate whether the source is a real bridge device, or a NIC with bridging done by magic inside the kernel.
I think I'd have a slight preference for the latter, since I like the fact that type=bridge is explicitly about layer-2 bridging, while type=ethernet is pretty much a generic catch-all, do-anything network mode.
Thank you for taking the time to clarify. Ok now I get it. I would agree, type=bridge is compliant with what it does. What got me confused is I assumed type bridge meant "use of a brctl kinda of bridge" where in libvirt it really means "bridge between the VM and the LAN".
It is probably best if you just go ahead and implement your idea for doing Virtualbox bridging with a real bridge + tap device, while we consider the XML modelling problem in parallel.
Well I did a version for my app, so my need is taken care of. As I don't think anyone has a need for it apart from me, and that it would take me much longer to do a clean patch for libvirt, I'll probably keep my non-libvirt version (which really is a workaround to some annoying VirtualBox behaviour anyway), and concentrate the little time I can find to work on libvirt on more useful patches :) so I guess you can drop the patch. Thanks again, Florian