Red Hat Bugzilla – Bug 881480
virDomainUpdateDeviceFlags fails when interface type is 'network'
Last modified: 2014-12-07 19:50:44 EST
Created attachment 653838 [details] script that executes the steps that reproduce the issue. Description of problem: When two host bridges are defined and mapped as libvirt networks and a vnic with interface of type 'network', moving the source from one network to another using virDomainUpdateDeviceFlags fails. Version-Release number of selected component (if applicable): libvirt-0.10.2-7.el6.x86_64 How reproducible: 100% Steps to Reproduce: Use attached bash script (requires python and libvirt python bindings). Actual results: libvirtError: this function is not supported by the connection driver: unable to change config on 'network' network type Expected results: vnet4 is part of bridge bar instead of bridge foo. Additional info: This refers to a feature found in: https://bugzilla.redhat.com/show_bug.cgi?id=805071
Fix pushed to upstream libvirt: commit 3738cf41f1012eca419e8fa0fa0575cb1e0552e3 Author: Laine Stump <laine@laine.org> Date: Mon Dec 3 12:24:46 2012 -0500 conf: fix virDomainNetGetActualDirect*() and BridgeName() This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=881480 These three functions: virDomainNetGetActualBridgeName virDomainNetGetActualDirectDev virDomainNetGetActualDirectMode return attributes that are in a union whose contents are interpreted differently depending on the actual->type and so they should only return non-0 when actual->type is 'bridge' (in the first case) or 'direct' (in the other two cases, but I had neglected to do that, so ...DirectDev() was returning bridge.brname (which happens to share the same spot in the union with direct.linkdev) if actual->type was 'bridge', and ...BridgeName was returning direct.linkdev when actual->type was 'direct'. How does this involve Bug 881480 (which was about the inability to switch between two networks that both have "<forward mode='bridge'/> <bridge name='xxx'/>"? Whenever the return value of virDomainNetGetActualDirectDev() for the new and old network definitions doesn't match, qemuDomainChangeNet() requires a "complete reconnect" of the device, which qemu currently doesn't support. ...DirectDev() *should* have been returning NULL for old and new, but was instead returning the old and new bridge names, which differ. (The other two functions weren't causing any behavioral problems in virDomainChangeNet(), but their problem and fix was identical, so I included them in this same patch).
# rpm -q libvirt libvirt-0.10.2-11.el6.x86_64 # sh libvirt_updateDevice.sh Network foo created from foo.xml Network bar created from bar.xml 512+0 records in 512+0 records out 536870912 bytes (537 MB) copied, 0.373643 s, 1.4 GB/s 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 vnet0 0 This should show vnet4 in bar bridge bridge name bridge id STP enabled interfaces bar 8000.fe5400a2b450 no vnet0 foo 8000.000000000000 no Cleaning up Domain foobar destroyed Network foo destroyed Network bar destroyed -------------------------- The result is correct(vnet0 change from bridge foo to bar). But one more question is, there's an error in libvirtd.log when running the reproducing script, so need your confirm. # tail -f /var/log/libvirt/libvirtd.log 2012-12-07 07:13:26.523+0000: 6311: warning : virCgroupMoveTask:885 : no vm cgroup in controller 3 2012-12-07 07:13:26.523+0000: 6311: warning : virCgroupMoveTask:885 : no vm cgroup in controller 4 2012-12-07 07:13:26.523+0000: 6311: warning : virCgroupMoveTask:885 : no vm cgroup in controller 6 2012-12-07 07:13:26.623+0000: 6314: error : qemuDomainNetGetBridgeName:1277 : internal error Network type 6 is not supported 2012-12-07 07:13:26.623+0000: 6314: error : qemuDomainNetGetBridgeName:1277 : internal error Network type 6 is not supported Thanks!
Yes, that is a problem with an error message being logged in a non-error situation. I just posted a fix upstream: https://www.redhat.com/archives/libvir-list/2012-December/msg00431.html
I filed Bug 885838 for the extra log message. In the meantime the operation does complete successfully, so this bug can be moved to VERIFY.
(In reply to comment #9) > I filed Bug 885838 for the extra log message. In the meantime the operation > does complete successfully, so this bug can be moved to VERIFY. OK, thanks. I will move this bug to VERIFY.
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