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.

--
---~~.~~---
Mike
//  SilverTip257  //