Hello, As far as i know, you can fix the vm's interfaces on the host. I'm using libvirt and you can do it there as described in here : http://libvirt.org/formatdomain.html#elementsNICSBridge ( What you're looking for is <target dev='vnet0'/> directive ). If you don't do this, vnet interfaces will be assigned to vm's in the order they start - the first one getting vnet0, the second one vnet1 etc. ----- Original Message ----- From: "Neil Aggarwal" <neil@xxxxxxxxxxxxxxxxxx> To: kvm@xxxxxxxxxxxxxxx Sent: Saturday, October 24, 2009 4:52:59 PM Subject: Using snmpd on host to monitor guest bandwidth usage Hello: I am using Cacti to monitor traffic usage on my network. According to what I am reading, snmpd can report traffic stats to Cacti. Running netstat -in on the host, I see this output: Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg br0 1500 0 237609 0 0 0 13615 0 0 0 BMRU eth0 1500 0 967594 0 0 0 354576 0 0 0 BMRU lo 16436 0 63 0 0 0 63 0 0 0 LRU virbr0 1500 0 0 0 0 0 32 0 0 0 BMRU vnet0 1500 0 29802 0 0 0 306940 0 0 0 BMRU vnet1 1500 0 311556 0 0 0 789331 0 0 0 BMRU Each guest runs a bridge interface with a static IP address. Looking at the firewall logs vnet1 is connected to guestA and vnet0 is connected to guestB. Will that ever change if I reboot the host or the guests? If it does, that would be a problem. Are there any pitfalls of using this approach? I am looking for a solution where I do not need to run anything on the guests. Thanks, Neil -- Neil Aggarwal, (281)846-8957, www.JAMMConsulting.com Will your e-commerce site go offline if you have a DB server failure, fiber cut, flood, fire, or other disaster? If so, ask about our geographically redundant database system. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
