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>
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).