[Qemu-devel] kvm binary is deprecated

[Alexander Binun]

Stefan , great thanks! We are setting up the scene for experiments...

Unfortunately, we ran into yet one trouble. The configuration: Ubuntu 13.04, 
internal KVM, Qemu 1.4.0. VMs are created using virt-manager.

When we try to create a VM the following error message appears:
     --- kvm binary is deprecated, please use qemu-system-x86_64 instead

The same message appears when I try to run kvm --version.

Question: how must be upgrade/degrade KVM oro Qemu in order to make them 
collaborate properly ?

Thanks, 
    Mark, Martin, Alex




On Thu 10 Oct 11:02 2013 Stefan Hajnoczi wrote:
> On Mon, Oct 07, 2013 at 05:47:46PM +0300, Alexander Binun wrote:
> > Our first task is to trace the traffic between individual VMs and between 
> > VMs and the VMM (the KVM driver). So we are searching for proper places to 
> > insert "sniffer code". We suspect that some functions in qemu/hw/virtio 
> > should be targeted. And we will appreciate any hints on this places.
> 
> My blog post about -netdev pcap in QEMU is useful for QEMU network code
> development setups.  But the simplest way to sniff traffic in a
> production x86 KVM configuration is using tcpdump on the host.
> 
> The common networking setup on the host is a Linux software bridge (e.g.
> virbr0) and one tap device per guest (e.g. vm001-tap, vm002-tap).  The
> tap devices are added to the bridge so guests can communicate with each
> other.
> 
> When a guest sends a packet, the vhost_net host kernel driver injects
> the packet into the guest's tap device.  The Linux network stack then
> hands the packet from the tap device to the bridge.
> 
> The bridge will forward the packet as appropriate.  In guest<->guest
> communication this means the packet is forwarded to the destination
> guest's tap device.
> 
> The vhost_net driver instance for the destination guest then reads the
> packet from its tap device and places it into the guest's virtio-net
> receive buffer.
> 
> This configuration means you have 3 places where you can run tcpdump on
> the host:
> 
> 1. On the source guest's tap device (e.g. vm001-tap).
> 2. On the bridge interface (e.g. virbr0).
> 3. On the destination guest's tap device (e.g. vm002-tap).
> 
> There are other options too like using openvswitch or macvtap.
> Openvswitch might be interesting because I think it allows you to add
> filtering rules into the kernel and send packets that match the rules up
> to a userspace process for inspection.
> 
> Stefan
>