On Tue, Mar 22, 2016 at 1:57 PM, Kevin Ross sedecim@gmail.com wrote:
Hi Mike,
Thanks for the info. I'd rather run monitoring such as tcpdump from the VM if possible and not the host as a simulation of a network
Then run tcpdump on the VM. Same command or commands you'd have ran on the host node.
appliance and with the intent eventually of giving others access to the VM and not the host. Here is the xml file for the private network:
<!-- WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: virsh net-edit virbr1 or other application using the libvirt API. -->
<network> <name>virbr1</name> <uuid>####</uuid> <forward mode='nat'/> <bridge name='virbr1' stp='on' delay='0' /> <mac address='52:54:00:##:##:##'/> <ip address='192.168.100.1' netmask='255.255.255.0'> </ip> </network>
There are two VMs connected to this interface, and the monitoring or "appliance" VM is connected to both this and the external interface.
I take it you've tried testing basic connectivity from the VMs to whatever default gateway is in place?
I see Spanning Tree is enabled, so you might check that an interface isn't in the blocking state. brctl showstp <BRIDGE_INT> | egrep '^(em|eth|vnet)|state'
I don't use the NAT network mode for KVM, so hopefully someone else can chime in on that piece.