|
Before anything else, a request -
please don't top-post responses on technical lists. It is much
easier to follow the details of the conversation if you respond
inline with the part of the message you are replying to.
On 09/01/2015 11:37 AM, Daniel Sanabria wrote:
There is some misinformation/confusion going on here. firewalld manages iptables and ebtables rules. iptables/ebtables rules on the host do not apply to macvtap interfaces (i.e. the data path doesn't even go through iptables or ebtables on the host), so it shouldn't matter what the state of the host's firewall is. Also, there are no "forwarding rules" of any type needed anywhere for a macvtap connection.
"direct" means macvtap, and macvtap operates in 4 different modes: * vepa (only applicable when connecting to certain IBM switches) * bridge (multiple guests using the same physdev can communicate directly) * private (multiple guests, but all traffic must go out the physdev and back for inter-guest communication) * passthrough (only one guest is allowed, and it effectively takes over the physdev) So you are using the most permissive mode of macvtap - other guests could connect to that physdev and they sould be able to talk to the router guest (as long as the firewall *inside the guest* It really looks to me, at first glance, that there aren't any problems with the guest's network config. So some random questions/ideas that may or may not lead to better understanding and possibly a solution: 1) Does the cable modem setup NAT in front of a private network, and allow multiple dhcp clients to get an IP address for that network? Or is is a "passthrough" type of device that only responds to the first device that has sent a DHCP request since it was booted? If the latter: a) what is the config of enp5s0f0 on the host? Is it getting an IP address from the cable modem (thus preventing the Sophos guest from getting one)? b) Or possibly have you not rebooted the cable modem after shutting down the ESXi-based guest, and that guest's traffic isn't actually arriving at the cable modem with the 00:0c:.... MAC address, but with the MAC address of the physical interface on the ESXi host? 2) Have you rebooted the cable modem after shutting down the Sophos guest on the ESXi host? Have you shutdown the ESXi host completely? 3) try using tcpdump on the host to monitor traffic on the macvtapX (probably macvtap0) device that is created for the guest to see if the dhcp request is actually making it out of the guest. After that, check if it is seen on enp5s0f0 and, if you can, see if the cable modem is receiving it. If all of those are positive, try looking for the DHCP response packets at the same locations (in reverse order) - basically the idea is to see where the break in communications is, then you can drill in to see why that would happen.
I'm not sure exactly what you mean by this, but if you're using macvtap, it doesn't matter which mode you are using, all traffic from the physical network should be seen by the guest. The macvtap mode only makes a difference in communication with other guests, and in whether or not the host can simultaneously use the physical device (in passthrough mode, the physdev is completely unusable by the host).
For future reference, what is most helpful in the first pass of debugging libvirt-related networking problems is the <interface> sections from the domain xml of the guest, and sometimes the output of "ip -d link show" from the host. (The diagram was also helpful, but the first thing I always want to see is the <interface> XML)
|
_______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users
