In order to fully understand and learn more about the KVM technology, I need to manage and run VMs with just the command line stuff, that's the kvm command.

So far I've done everything I need, but the networking part.

I mean, on the CLI I have defined the ethernet interface for the guest as

-device virtio-net-pci,mac=02:01:01:01:01:01

but then I cannot find enough documentation in order to attach it to the host networking interface (which is a LACP ethernet bond interface). That should be done with the -netdev CLI option.

I need to let each VM talk to each other and to the guest and to the other hosts on the host LAN.

I have found a number of (possibly outdated) documents about bridging and the likes, but in the end they are all based upon libvirt.

While it's a very powerful tool, it

  1. hides too many details to the user and

  2. sometimes requires you to download an XML files crafted by someone else and to customize it accordingly to your needs.

Is there any documentation on how the -netdev is to be used under the various scenarios, possibly with the pros and cons in the case of multiple strategies?

  • Did you know about virsh? While it uses libvirt, it is entirely command line only.
    – shodanshok
    Oct 7 '16 at 15:04
  • 2
    You really should explain your reasons for not using libvirt. You may have missed something important. Oct 7 '16 at 18:23
  • 2
    You use virsh to manage VMs, networking stacks, storage pools, hypervisor capabilities, etc. However, defining a VM can be easily accomplished with virt-install. Higher level toolstacks are not hiding the details, they are providing a universal structure that can be interacted with. Going with the idea that we're "hiding details" with higher level languages, one could say that anything other than assembly is black magic - it is not. That's a highly unproductive way of thinking about toolstacks.
    – Spooler
    Oct 8 '16 at 8:06
  • 2
    The bare truth? On a well configured VM the command line can run to dozens of lines on the terminal. 36 lines, 37, even more. You can understand it all if you spend the time to do so, but most of us are too busy getting work done, and only worry about this when there's a real reason to do so. And trying to put together a command line like that by yourself is utter madness. Oct 8 '16 at 8:29
  • 1
    I still believe the question makes sense as it really has at least one answer. Moreover none ever explained why labelling it as off-topic: which topic was this question off? Unless you label as off-topic something you cannot answer this question makes a lot of sense. Finally, I have found the solution and would like to publish it here.
    – EnzoR
    Dec 10 '16 at 7:39

@shodanskok brings up a very valid point in the comments, and that is: why not use libvirt via virsh? It's a fantastic command line abstraction of QEMU / KVM, as well as ESXi and Xen. You can use XML snippets to manage device attachments and it's a great way to standardize your toolstack no matter which hypervisor runs underneath it. OpenStack uses it directly for this very reason, and it offers the kind of flexibility that even a heterogeneous cloud requires.

All of that aside, if you have to use qemu-kvm commands directly, you will need to manage your own networking stack. Specifically, you lack a bridge in this scenario.

You will need to create a bridge interface that all VMs attach to. This will afford you complete intercommunication between all machines. A bridge in this case is a virtual forwarding switch. Your bond will be connected to this switch as well, connecting the outside network to this virtual switch.

You will need to use your distribution's networking scripts to create such an interface and attach your bond to it. You haven't mentioned your distribution, so I will offer the "ephemeral" solution to this problem (which is universal in GNU / Linux). These changes will be lost on reboot, so do make sure to add your bridge to your interface configuration files.

One side node, libvirt is capable of setting these interfaces up via the virsh command line persistently (persistence being granted by XML files), rather than having to worry about distribution specific interface configuration files. Strikes again, the effective higher level toolstack.

To create a bridge:

# brctl addbr br0 (The bridge name is br0 in this example. The name is arbitrary).

To add an underlying interface to that bridge:

# brctl addif bond0 br0 (In this case, we're adding bond0 to br0)

After this is done, your link layer host networking is finished. If you require to address your host via an IP address, you may put that address on the bridge. Do NOT put it one layer below, on the bond for example. That simply won't work.

To add an IP to this bridge (This too will be ephemeral if you do not create an interface file for your bridge, but will immediately work):

# ip a add dev br0 (the IP given is merely an example.)

As a potential help, here are links for setting up persistent bridges on both CentOS and Debian.

For CentOS: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-networkscripts-interfaces_network-bridge.html

For Debian: https://wiki.debian.org/NetworkConfiguration#Bridging

Once that is set up, you need merely modify your -device switch as follows:

-device virtio-net-pci,netdev=br0,mac=02:01:01:01:01:01

  • 2
    If I was to use libvirt, than the question would have been completely different. But the question reads "without libvirt stuff", so the points made by others are pointless to me.Thank you for the answer that starts after the very first paragraph.
    – EnzoR
    Oct 8 '16 at 13:08
  • 1
    It seems there's something missing. The attempts fail with failed to parse default acl file '/etc/qemu/bridge.conf'. The solution seems to be here.
    – EnzoR
    Oct 9 '16 at 13:30

Well, libvirt would be a lot easier to manage; you can use configurations stored in XML-format and it also has a CLI (virsh). However, it works without it, it's just a monstrosity of a command if you start the vm with all the parameters.

If you want to share the physical host interface with your guests you have to use a bridge but that is not much of a problem nowadays, except for WLAN-interfaces (most of them don't support bridging). Depending on your distribution you have to set up a bridge interface. For example in Debian-based systems (e.g. Debian, Ubuntu) you have to install bridge-utils and edit the /etc/network/interfaces:

# Replace the auto entry for your old interface with br0
auto br0

# Use old interface config config for br0, plus bridge options
iface br0 inet dhcp
    bridge_ports    eth0 #The interface you want to bridge
    bridge_stp      off
    bridge_maxwait  0
    bridge_fd       0

For static this would be something like:

iface br0 inet static
    bridge_ports    eth0
    bridge_stp      off
    bridge_maxwait  0
    bridge_fd       0

Then you basically just start your VM with the following options added:

-netdev bridge,id=hn0 -device virtio-net-pci,netdev=hn0,id=nic1

The mac-parameter is optional but you can add it to the -device option.

  • I don't see how the command line relates to the br0 host bridge. Maybe you wrote hn0 instead of br0?
    – EnzoR
    Oct 11 '16 at 7:17
  • No, it takes the first bridge per default. You create the bridge connection with hn0 (or any name you give it) and connect the device with it (in the -device parameters)
    – Broco
    Oct 11 '16 at 15:17

You can try: http://www.linux-kvm.org/page/Simple_shell_script_to_manage_your_virtual_machine_with_bridged_networking

Or feel free to checkout this page: http://www.linux-kvm.org/page/Management_Tools there are some management tools, that you can use even without libvirt.

Not the answer you're looking for? Browse other questions tagged or ask your own question.