> 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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list