Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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).
# 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