Red Hat Bugzilla – Bug 885838
improper errors logged when changing the bridge device used by a domain <interface type='bridge'>
Last modified: 2013-02-21 02:28:27 EST
This was found during testing of Bug 881480. If an interface is updated (e.g. with virsh update-device) from *or* to an <interface type='bridge'> (or type='network' pointing to a network that itself is <forward mode='bridge'/>), the update will complete successfully, but an error will be logged in syslog: 2012-12-07 07:13:26.623+0000: 6314: error : qemuDomainNetGetBridgeName:1277 : internal error Network type 6 is not supported This is not an actual error, but only happens because the successful code path drops through to the error case. A patch to fix this problem has already been pushed upstream: commit e5577872cba7f88305e9e0b1ee26b37b4be790df Author: Laine Stump <laine@laine.org> Date: Mon Dec 10 11:21:39 2012 -0500 qemu: eliminate bogus error log when changing netdev's bridge This fixes a problem that showed up during testing of: https://bugzilla.redhat.com/show_bug.cgi?id=881480 Due to a logic error in the function that gets the name of the bridge an interface connects to, any time a bridge was specified directly (type='bridge') rather than indirectly (type='network'), An error would be logged (although the operation would then complete successfully): Network type 6 is not supported The final virReportError() in the function qemuDomainNetGetBridgeName() was apparently avoided in the past with a "goto cleanup" at the end of each case, but the case of bridge somehow no longer has that final goto cleanup. The proper solution is anyway to not rely on goto's, but put the error log inside an else {} clause, so that it's executed only if the type is neither bridge nor network (in reality, this function should only ever be called for those two types, that's why this is an internal error). While making this change, the error message was also tuned to be more correct (since it's not really the type of the network, but the type of the interface, and it *is* otherwise supported, it's just that the interface type in question doesn't *have* a bridge device associated with it, or at least we don't know how to get it).
# rpm -q libvirt libvirt-0.10.2-12.el6.x86_64 Get the reproduce script from Bug 881480. # sh libvirt_updateDevice.sh Network foo created from foo.xml Network bar created from bar.xml Domain foobar created from vm.xml This should show vnet4 in foo bridge bridge name bridge id STP enabled interfaces bar 8000.000000000000 no foo 8000.fe5400a2b450 no vnet2 switch 8000.0022193020ec no eth0 virbr0 8000.5254006141c3 yes virbr0-nic vnet0 vnet1 0 This should show vnet4 in bar bridge bridge name bridge id STP enabled interfaces bar 8000.fe5400a2b450 no vnet2 foo 8000.000000000000 no switch 8000.0022193020ec no eth0 virbr0 8000.5254006141c3 yes virbr0-nic vnet0 vnet1 Cleaning up Domain foobar destroyed Network foo destroyed Network bar destroyed And check the libvirtd.log, not error log. Move to VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0276.html