Re: Network interface element not working
On 4/5/22 10:12, Laine Stump wrote: Umm That's how it was intended to *not* work :-P. The whole point of the self-managed libvirt virtual networks is to setup a separate subnet that has all traffic routed via IP to the physical network. I'm impressed you've found a hack that works for you[*], but just be prepared to "pick up the pieces" if it breaks :-) This is a lab setup. It only has to work for a few days. (I hope you've removed the DHCP service, DNS service, and for that matter even the IP address from the libvirt network definition. Also, is the host ethernet being used (i.e. does it have an IP address) prior to attaching it to the bridge? Normally when an ethernet is attached to a bridge, its IP configuration is moved to the bridge device, and the ethernet has no IP. I'm not sure what kind of connectivity oddities would show up if you left the IP address on the ethernet itself) Actually, the physical interface is connected to a VLAN that I'm using extend the existing virtual environment to some physical machines, so I want to leave the virtual network otherwise unchanged, but have the ability to add physical machines to the virtual network (if that makes sense). -- Google Where SkyNet meets Idiocracy
Re: Network interface element not working
On 4/5/22 10:28 AM, Ian Pilcher wrote: On 4/4/22 21:10, Laine Stump wrote: That's not what the element in a is used for. It's actual use is (in my opinion) not all that useful, which has led to people assuming other functionality for it that doesn't exist. Ah. Thanks for clarifying that. Anyway, if you want to have a bridge device that is directly attached to a physical ethernet, then you should set up a bridge in the host OS outside the scope of libvirt, with the physical ethernet attached to it, and then configure your libvirt guests to use that bridge with, e.g. That is how I normally do things. In this case, I'm "piggy backing" on a pre-existing automation setup that uses libvirt to set up the bridges. I'm using a hook script to add the physical interface to the bridge when the virtual network is started, which seems to be working. Umm That's how it was intended to *not* work :-P. The whole point of the self-managed libvirt virtual networks is to setup a separate subnet that has all traffic routed via IP to the physical network. I'm impressed you've found a hack that works for you[*], but just be prepared to "pick up the pieces" if it breaks :-) (I hope you've removed the DHCP service, DNS service, and for that matter even the IP address from the libvirt network definition. Also, is the host ethernet being used (i.e. does it have an IP address) prior to attaching it to the bridge? Normally when an ethernet is attached to a bridge, its IP configuration is moved to the bridge device, and the ethernet has no IP. I'm not sure what kind of connectivity oddities would show up if you left the IP address on the ethernet itself)
Re: Network interface element not working
On 4/4/22 21:10, Laine Stump wrote: That's not what the element in a is used for. It's actual use is (in my opinion) not all that useful, which has led to people assuming other functionality for it that doesn't exist. Ah. Thanks for clarifying that. Anyway, if you want to have a bridge device that is directly attached to a physical ethernet, then you should set up a bridge in the host OS outside the scope of libvirt, with the physical ethernet attached to it, and then configure your libvirt guests to use that bridge with, e.g. That is how I normally do things. In this case, I'm "piggy backing" on a pre-existing automation setup that uses libvirt to set up the bridges. I'm using a hook script to add the physical interface to the bridge when the virtual network is started, which seems to be working. Thanks! -- Google Where SkyNet meets Idiocracy
Re: Network interface element not working
On 4/4/22 2:08 PM, Ian Pilcher wrote: I've added an interface element to a libvirt network, but it isn't working. The interface is not being added to the bridge, even after the system is rebooted. That's not what the element in a is used for. It's actual use is (in my opinion) not all that useful, which has led to people assuming other functionality for it that doesn't exist. The *actual* use of the element is simply to add an extra iptables rule that will drop all traffic originating from a guest and outbound to the real network if the interface it uses for egress doesn't match the one listed in the element. It doesn't attach this egress interface to the network's bridge, and it doesn't modify the next-hop routing of the traffic (which is the more common mistaken belief of its function). Anyway, if you want to have a bridge device that is directly attached to a physical ethernet, then you should set up a bridge in the host OS outside the scope of libvirt, with the physical ethernet attached to it, and then configure your libvirt guests to use that bridge with, e.g. ... # virsh net-dumpxml ocp4-net ocp4-net b5852945-9889-4d22-ba61-879125316cec # brctl show bridge name bridge id STP enabled interfaces virbr-ocp4 8000.52540099 yes vnet0 virbr0 8000.525400a7ce7f yes virbr1 8000.52540051eb1f yes vnet1 # rpm -q libvirt libvirt-8.0.0-2.module_el8.6.0+1087+b42c8331.x86_64 Any ideas?
Network interface element not working
I've added an interface element to a libvirt network, but it isn't working. The interface is not being added to the bridge, even after the system is rebooted. # virsh net-dumpxml ocp4-net ocp4-net b5852945-9889-4d22-ba61-879125316cec # brctl show bridge name bridge id STP enabled interfaces virbr-ocp4 8000.52540099 yes vnet0 virbr0 8000.525400a7ce7f yes virbr1 8000.52540051eb1f yes vnet1 # rpm -q libvirt libvirt-8.0.0-2.module_el8.6.0+1087+b42c8331.x86_64 Any ideas? -- Google Where SkyNet meets Idiocracy
