[libvirt-users] Do not attempt to add physical NIC to virbr0
Hi, I got this NOTE on most of the link. But I am not getting reason for this. Why someone should not add physical NIC to virbr0. I tried to add my eth1 to virbr0 and it get added. So whether it affects to some functionality of NAT network? -- Sagar Dilip Shedge, Pune. With Regards.
On 11/12/2014 08:21 AM, Sagar Shedge wrote:
Hi,
I got this NOTE on most of the link. But I am not getting reason for this. Why someone should not add physical NIC to virbr0.
Well, for a start, if you do that then the dhcp server that is running on virbr0 will be exposed to the physical network and begin answering DHCP requests from devices out in the real world. And then you will have some people *very* angry with you (conversely, any DHCP server listening on the physical network will also be responding to DHCP requests from your guests). Beyond that, why would you even want to do that? The entire point of the NATed network is to isolate the guests from the physical network. That is done by forcing all traffic to pass through the host's IP routing stack in order to get beyond the host, and if you have a physical device attached to the bridge, the host's IP stack can be bypassed - if a guest gets configured with an IP address that is on the physical network, all of its traffic will go directly via the attached physdev without ever going through the host's IP stack, or being NATed by iptables. If you really want your guests directly visible on the physical network, separately create a host bridge in the host's network config using the directions that are available in many places (including the libvirt wiki), and connect the guest interfaces to that bridge, rather than to libvirt's default network.
I tried to add my eth1 to virbr0 and it get added.
Just because something can be done with no immediate error does not mean that it should be done, nor that it is not going to cause a lot of other problems that aren't immediately visible.
So whether it affects to some functionality of NAT network?
See above.
Hi Laine, Ok. Got the point that how it will affect my network and NATed functionality. Thanks a lot for this description. Regards, Sagar On Sat, Nov 15, 2014 at 9:11 AM, Laine Stump <laine@laine.org> wrote:
Hi,
I got this NOTE on most of the link. But I am not getting reason for
On 11/12/2014 08:21 AM, Sagar Shedge wrote: this.
Why someone should not add physical NIC to virbr0.
Well, for a start, if you do that then the dhcp server that is running on virbr0 will be exposed to the physical network and begin answering DHCP requests from devices out in the real world. And then you will have some people *very* angry with you (conversely, any DHCP server listening on the physical network will also be responding to DHCP requests from your guests).
Beyond that, why would you even want to do that? The entire point of the NATed network is to isolate the guests from the physical network. That is done by forcing all traffic to pass through the host's IP routing stack in order to get beyond the host, and if you have a physical device attached to the bridge, the host's IP stack can be bypassed - if a guest gets configured with an IP address that is on the physical network, all of its traffic will go directly via the attached physdev without ever going through the host's IP stack, or being NATed by iptables.
If you really want your guests directly visible on the physical network, separately create a host bridge in the host's network config using the directions that are available in many places (including the libvirt wiki), and connect the guest interfaces to that bridge, rather than to libvirt's default network.
I tried to add my eth1 to virbr0 and it get added.
Just because something can be done with no immediate error does not mean that it should be done, nor that it is not going to cause a lot of other problems that aren't immediately visible.
So whether it affects to some functionality of NAT network?
See above.
-- Sagar Dilip Shedge, Pune. With Regards.
participants (2)
-
Laine Stump -
Sagar Shedge