----- "Cole Robinson" crobinso@redhat.com wrote:
On 11/15/2009 04:10 PM, Dale Bewley wrote:
...
[root@tofu2 network-scripts]# virsh iface-define br0.xml error: Failed to define interface from br0.xml error: invalid argument in virGetInterface
It did work however.
...
But now eth0 is missing from iface-list
[root@tofu2 network-scripts]# virsh iface-list Name State MAC Address
lo active 00:00:00:00:00:00
Presumably, that's because from the libvirt / netcf perspective
(which is just looking at the ifcfg files) I have replaced it with the br0 interface. However, br0 is not started, so presumably that's why it isn't listed either. After a 'service network restart' things look sane again.
[root@tofu2 network-scripts]# virsh iface-list Name State MAC Address
br0 active 00:24:e8:30:20:e7 lo active 00:00:00:00:00:00
Probably want to try iface-list --all here, should list inactive interfaces.
That's what I would expect, but I recreated the situation and tried that. With and without --all, only lo showed up until a network restart.
= Network = And finally, after creating this bridge, it would be nice to create
a network which utilizes it as follows. That fails the way I attempted to do it.
[root@tofu2 ~]# cat net-bridged.xml
<network> <name>bridged</name> <forward mode='route'/> <bridge name='br0' /> </network>
Physical device bridges are referenced directly in the VM xml, not via the virtual network XML. Example interface device block to add to your VM:
<interface type='bridge'> <source bridge='br0'/> <mac address="11:22:33:44:55:66"/> </interface>
- Cole
I understand that, but I did lose track of that in my mind. It doesn't make much sense to refer to it as a 'network'. I do see that br0 shows up in the network/interface selection dialog of the VM creation wizard.
One thing I just noticed is that NetworkManager is taking ownership of eth0 and preventing the br0 from being created. One fix is to
chkconfig NetworkManager off chkconfig network on service NetworkManager stop service network restart
I suppose the other solution would be to educate NetworkManager about the new configuration, but I've never really used paid much attention to NM. I'd have to look into how to do that properly.
Ooops. Sorry, that was the wrong attachment which lacked br0. It does show up as expected. It wasn't that illuminating anyway, I won't bother sending the good screenshot.
On 11/16/2009 01:51 PM, Dale Bewley wrote:
----- "Cole Robinson" crobinso@redhat.com wrote:
= Network = And finally, after creating this bridge, it would be nice to create
a network which utilizes it as follows. That fails the way I attempted to do it.
[root@tofu2 ~]# cat net-bridged.xml
<network> <name>bridged</name> <forward mode='route'/> <bridge name='br0' /> </network>
Physical device bridges are referenced directly in the VM xml, not via the virtual network XML. Example interface device block to add to your VM:
<interface type='bridge'> <source bridge='br0'/> <mac address="11:22:33:44:55:66"/> </interface>
- Cole
I understand that, but I did lose track of that in my mind. It doesn't make much sense to refer to it as a 'network'. I do see that br0 shows up in the network/interface selection dialog of the VM creation wizard.
One thing I just noticed is that NetworkManager is taking ownership of eth0 and preventing the br0 from being created. One fix is to
chkconfig NetworkManager off chkconfig network on service NetworkManager stop service network restart
I suppose the other solution would be to educate NetworkManager about the new configuration, but I've never really used paid much attention to NM. I'd have to look into how to do that properly.
Yes, this NetworkManager pain is a long known deficiency. NM and bridges just don't play well together.
- Cole
On Mon, 2009-11-16 at 10:51 -0800, Dale Bewley wrote:
One thing I just noticed is that NetworkManager is taking ownership of eth0 and preventing the br0 from being created. One fix is to
chkconfig NetworkManager off chkconfig network on service NetworkManager stop service network restart
I suppose the other solution would be to educate NetworkManager about the new configuration
That's the long-term plan, but for now, your 'fix' above is as good as it gets.
David