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