<br><br><div class="gmail_quote">On Mon, Feb 20, 2012 at 1:46 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Sat, Feb 18, 2012 at 10:07:45PM -0500, Laine Stump wrote:<br>
> On 02/17/2012 02:51 PM, Ansis Atteka wrote:<br>
> ><br>
> ><br>
> > On Fri, Feb 17, 2012 at 10:55 AM, Laine Stump <<a href="mailto:laine@laine.org">laine@laine.org</a><br>
> > <mailto:<a href="mailto:laine@laine.org">laine@laine.org</a>>> wrote:<br>
> ><br>
> > On 02/16/2012 06:49 PM, Ansis Atteka wrote:<br>
> > > Currently libvirt sets the attached-mac to altered MAC address<br>
> > that has<br>
> > > first byte set to FE. This patch will change that behavior by<br>
> > using the<br>
> > > original (unaltered) MAC address from the domain XML<br>
> > configuration file.<br>
> ><br>
> > Maybe I didn't read thoroughly enough, but I don't see where it<br>
> > changes<br>
> > the behavior - in the cases where previously the first byte was set to<br>
> > 0xFE, now you send discourage=true, and in the cases where it didn't,<br>
> > now you send discourage=false.<br>
> ><br>
> > "discourage" means whether bridge should be discouraged to use the<br>
> > newly added<br>
> > TAP device's MAC address. Libvirt does that by setting the first MAC<br>
> > address byte<br>
> > high enough.<br>
> ><br>
> > And here is how this patch works:<br>
> ><br>
> > 1. Now in virNetDevTapCreateInBridgePort() function we always pass<br>
> > exactly the same MAC address that was defined in XML.<br>
> > 2. If "discourage" flag was set to true, then we create a copy of MAC<br>
> > address and set its first byte to 0xFE<br>
> > 3. virNetDevSetMAC() function would use the MAC address that was<br>
> > product of #2<br>
> > 4. while virNetDevOpenvswitchAddPort() function would use the<br>
> > original MAC address that was passed in #1 (this code did not need<br>
> > to be changed so most likely that was the reason why you did not<br>
> > notice behavior changes)<br>
> ><br>
><br>
><br>
> Right. That's what I missed - all I saw was every occurrence of creating<br>
> a temporary mac address with 0xFE in the first byte replaced with adding<br>
> "discourage=true" to the args. I didn't notice that<br>
> virNetDevOpenvswitchAddPort() takes the macaddr (while<br>
> virNetDevBridgeAddPort() doesn't).<br>
><br>
> But that means that the tap device has been created with an<br>
> 0xFE-initiated MAC address, and then you attach to the bridge using the<br>
> unmodified address. Is the issue that the mac address used during the<br>
> attach needs to match the MAC address that will be in the traffic? Do<br>
> connections to an openvswitch bridge have an implied MAC filter on them,<br>
> such that only that MAC address gets through?<br>
><br>
> (Also, the only time discourage is false is for libvirt's virtual<br>
> network bridges. I'm wondering if they could also use the modified MAC<br>
> address for the tap devices - if that was the case we could just always<br>
> create the temporary MAC address in virNetDevTapCreateInBridgePort()<br>
> (and always set the tap device's mac to that).)<br>
><br>
> Let's let this sit over the weekend and see if anyone else has a<br>
> brilliant idea/insight.<br>
<br>
</div></div>The reason for setting the top byte to 0xFE, was that the bridge<br>
device will initialize its own MAC address, to the numerically<br>
lowest MAC address of all interfaces that are attached. Every<br>
time the bridge MAC address changes, we got a network blackout<br>
of something like 30-60 seconds IIRC. Setting the guest MAC<br>
address to 0xFE ensured that the bridge acquired the MAC address<br>
of a physical NIC, and ignored the guest NICs.<br></blockquote><div>This behavior applies to OVS as well. So we must set MAC address top</div><div>byte to 0xFE also for TAP devices that get attached to OVS bridges.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So before we can go with this patch we need to determine what<br>
the OpenVSwitch behaviour is wrt bridge MAC addresses, otherwise<br>
this patch could be just reintroducing the problem we solved<br>
with this 0xFE byte setting.<br></blockquote><div>Sorry for the confusion. I think I needed to to make it clear that this</div><div>"attached-mac" address has nothing to do with MAC address that</div><div>gets assigned to the TAP devices.</div>
<div><br></div><div><div>After applying this patch the TAP devices would still get the same</div><div>FE:XX:XX:XX:XX:XX MAC addresses (irrelevant whether Linux</div><div>Bridge or OVS bridge). The only thing that would change after</div>
<div>applying this patch would be that "attached-mac" (see where</div><div>we invoke ovs-vsctl command) would match the original MAC</div><div>address that was defined in Domain XML file.</div></div><div><br></div>
<div>By the way, the only consumer of this "attached-mac" is OpenFlow</div><div>Controller, which must see the MAC address that is being used by</div><div>the guest and not the one that gets assigned to the TAP device with</div>
<div>highest byte set to 0xFE.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><br><font color="#888888">
Daniel</font><br><font color="#888888">
--</font><br><font color="#888888">
|: </font><a href="http://berrange.com" target="_blank" style="color:rgb(136,136,136)">http://berrange.com</a><font color="#888888"> -o- </font><a href="http://www.flickr.com/photos/dberrange/" target="_blank" style="color:rgb(136,136,136)">http://www.flickr.com/photos/dberrange/</a><font color="#888888"> :|</font><br>
<font color="#888888">
|: </font><a href="http://libvirt.org" target="_blank" style="color:rgb(136,136,136)">http://libvirt.org</a><font color="#888888"> -o- </font><a href="http://virt-manager.org" target="_blank" style="color:rgb(136,136,136)">http://virt-manager.org</a><font color="#888888"> :|</font><br>
<font color="#888888">
|: </font><a href="http://autobuild.org" target="_blank" style="color:rgb(136,136,136)">http://autobuild.org</a><font color="#888888"> -o- </font><a href="http://search.cpan.org/~danberr/" target="_blank" style="color:rgb(136,136,136)">http://search.cpan.org/~danberr/</a><font color="#888888"> :|</font><br>
<font color="#888888">
|: </font><a href="http://entangle-photo.org" target="_blank" style="color:rgb(136,136,136)">http://entangle-photo.org</a><font color="#888888"> -o- </font><a href="http://live.gnome.org/gtk-vnc" target="_blank" style="color:rgb(136,136,136)">http://live.gnome.org/gtk-vnc</a><font color="#888888"> :|</font><br>
</span><div class="HOEnZb"><div class="h5"><br>
--<br>
libvir-list mailing list<br>
<a href="mailto:libvir-list@redhat.com">libvir-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/libvir-list" target="_blank">https://www.redhat.com/mailman/listinfo/libvir-list</a><br>
</div></div></blockquote></div><br>