Bug 881480

Fix pushed to upstream libvirt:

commit 3738cf41f1012eca419e8fa0fa0575cb1e0552e3
Author: Laine Stump <laine>
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