On Tue, Mar 22, 2016 at 1:57 PM, Kevin Ross <sedecim at 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 // -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20160324/38c7fb8c/attachment-0005.html>