<HTML><HEAD> <META content="text/html; charset=utf-8" http-equiv=Content-Type> <META name=GENERATOR content="MSHTML 8.00.7601.19038"></HEAD> <BODY style="MARGIN: 4px 4px 1px; FONT: 10pt 微软雅黑"> >>> Cole Robinson <crobinso@redhat.com> 2017/2/6 星期一上午 5:39 >>> >On 01/20/2017 02:42 AM, Lin Ma wrote: >> Because a bridge xml doesn't include its own mac item, what it contains >> are the slave devices's mac, It causes the get_xmlobj().macaddr can't >> return the mac address of bridge. >> >> So while showing host details, The bridge's mac address is displayed as >> 'Unknown' in tab 'Network Interfaces'. Say virbr0, We known a dummp tap >> was already connected to it to maintain a fixed mac address for virbr0, >> But its mac is displayed as 'Unknown' in tab 'Network Interfaces'. >> >> The patch fixed the issue by returning mac from backend instead of xml. >> >> Signed-off-by: Lin Ma <lma@suse.com> >> --- >> virtManager/interface.py | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/virtManager/interface.py b/virtManager/interface.py >> index 3af5974..626465e 100644 >> --- a/virtManager/interface.py >> +++ b/virtManager/interface.py >> @@ -81,7 +81,7 @@ class vmmInterface(vmmLibvirtObject): >> ################ >> >> def get_mac(self): >> - return self.get_xmlobj().macaddr >> + return self._backend.MACString() >> >> def is_bridge(self): >> typ = self.get_type() >> > >Sorry for the review delay. This seems like a libvirt or netcf bug, it should >be showing that mac address in the XML, we shouldn't need to resort to an API >call for this info. > >Plus we try really hard to avoid sprinkling around API calls like this, since >it really slows down the app on remote connections. If the libvirt fix doesn't >happen, we probably want to cache this info rather than look it up on demand >all the time. <DIV>OK, Thanks for your review.</DIV> <DIV> </DIV> <DIV>Lin</DIV></BODY></HTML>