{"id":177,"date":"2013-09-26T14:01:14","date_gmt":"2013-09-26T12:01:14","guid":{"rendered":"http:\/\/www.opencloudblog.com\/?p=177"},"modified":"2013-11-09T21:47:05","modified_gmt":"2013-11-09T20:47:05","slug":"kvm-using-the-openvswitch","status":"publish","type":"post","link":"https:\/\/www.opencloudblog.com\/?p=177","title":{"rendered":"KVM using the Openvswitch"},"content":{"rendered":"<p>Running KVM using the Openvswitch one way to attach VMs to the network. When using libvirt 1.02 and higher, several configuration options are available. The virt-manager can only use openvswitch fake bridges, so the virt-manager is not the best tool to configure the network interfaces for VM&#8217;s.<\/p>\n<p>There are two ways to define libvirt networks:<\/p>\n<ul>\n<li>define the whole network configuration in the xml file of the VM (virsh edit &lt;VM&gt;)<\/li>\n<li>define the forwarding part using net-* commands of virsh<\/li>\n<\/ul>\n<h1>Edit the VM xml file<\/h1>\n<p>The configuration can be split info different parts. One part is the generic part covering the basic interface configuration. The extended part convers the type of the link (untagged or tagged) and the assignment to one or more vlans.<\/p>\n<p>The configuration should be added using &#8222;<strong>virsh edit &lt;vmname&gt;<\/strong>&#8222;. For the examples here, I will use the name <em>vmtest<\/em>.<\/p>\n<h2>The generic part<\/h2>\n<p>The generic part looks like the following section:<\/p>\n<pre class=\"lang:xhtml decode:true\" title=\"network interface configuration\">    &lt;interface type='bridge'&gt;\r\n      &lt;virtualport type='openvswitch'&gt;\r\n      &lt;\/virtualport&gt;\r\n      &lt;target dev='veth0-vmtest'\/&gt;\r\n      &lt;model type='virtio'\/&gt;\r\n      &lt;address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'\/&gt;\r\n    &lt;\/interface&gt;<\/pre>\n<p>The parameters are:<\/p>\n<ul>\n<li>the <em>interface type<\/em> is always a <strong>bridge<\/strong>.<\/li>\n<li>no need to specify the mac address &#8211; a host unique address will be added by libvirt<\/li>\n<li>the virtualport line marks the interface a an openvswitch port<\/li>\n<li>I <strong>strongly<\/strong> <strong>recommend<\/strong> to set the target device name. This is the name of the network interface seen on the openvswitch. I always start the name with &#8222;veth&#8220;. The number following is the interface number on the guest. And I add the name of the VM. So veth0-vmtest corresponds to eth0 on the guest vmtest. If you do not set the interface name, they will get vnet&lt;some number&gt;. If you have to troubleshoot something on the virtual network, predefined interface names help a lot.<\/li>\n<li>the <em>model type<\/em> should be <strong>virtio<\/strong>. This gives the bst performance without emulation a physical network card.<\/li>\n<li>The line with address defines the virtual pci slot. Be sure to use unique numbers per VM. domain, bus and function are zero by default. The slot number increases per card in the VM. The card with the lowest slot number will be eth0! This entry should be synchronized with the target device name.<\/li>\n<\/ul>\n<h2>An untagged port<\/h2>\n<p>If you want to stick the VM to one vlan on the openvswitch, the generic configuration must be extended by four lines lines:<\/p>\n<pre class=\"lang:xhtml decode:true\" title=\"Untagged link of a port\">      &lt;source bridge='brtest'\/&gt;\r\n      &lt;vlan&gt;\r\n        &lt;tag id='2001'\/&gt;\r\n      &lt;\/vlan&gt;<\/pre>\n<p>The parameters are:<\/p>\n<ul>\n<li>The <strong>source bridge<\/strong> is the name openvswitch bridge, you created using &#8222;ovs-vsctl add-br brtest&#8220;<\/li>\n<li>The next three lines will ensure, that the openvswitch port will be put into vlan 2001<\/li>\n<\/ul>\n<p>The openvswitch will drop all tagged packets. This is the default setup, that you want to use, when running VMs.<\/p>\n<h2>A tagged port with a restricted vlan list<\/h2>\n<p>If you want the VM to access multiple vlans on the openvswitch, the generic configuration must be extended by the following lines:<\/p>\n<pre class=\"lang:xhtml decode:true\" title=\"tagged port\">      &lt;source bridge='brtest-ext'\/&gt;\r\n      &lt;vlan trunk='yes'&gt;\r\n        &lt;tag id='2102'\/&gt;\r\n        &lt;tag id='2103'\/&gt;\r\n        &lt;tag id='2110'\/&gt;\r\n        &lt;tag id='2999'\/&gt;\r\n        &lt;tag id='3000'\/&gt;\r\n      &lt;\/vlan&gt;<\/pre>\n<p>The parameters are:<\/p>\n<ul>\n<li>The <strong>source bridge<\/strong> is the name openvswitch bridge, you created using &#8222;ovs-vsctl add-br brtest-ext&#8220;<\/li>\n<li>The <strong>vlan<\/strong> line contains now the additional parameter &#8218;trunk=yes&#8216;. This tells the openvswitch to accept tagged packets.<\/li>\n<li>The <strong>tag<\/strong> lines contain one allowed vlan tag per line. If you need multiple tags, you must add one line per tag. In the example, 5 tags are used on the link.<\/li>\n<\/ul>\n<p>If you omit the vlan and tag lines, you are creating a link, which transports untagged packets AND tagged packets allowing ALL vlans.<\/p>\n<h2>The complete configuration<\/h2>\n<p>The complete configuration for our VM is now:<\/p>\n<pre class=\"lang:xhtml decode:true\" title=\"Conplete configuration (one untagged interface and one tagged interface)\">    &lt;interface type='bridge'&gt;\r\n      &lt;source bridge='brtest'\/&gt;\r\n      &lt;vlan&gt;\r\n        &lt;tag id='2001'\/&gt;\r\n      &lt;\/vlan&gt;      \r\n      &lt;virtualport type='openvswitch'&gt;\r\n      &lt;\/virtualport&gt;\r\n      &lt;target dev='veth0-vmtest'\/&gt;\r\n      &lt;model type='virtio'\/&gt;\r\n      &lt;address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'\/&gt;\r\n    &lt;\/interface&gt;\r\n\r\n    &lt;interface type='bridge'&gt;\r\n      &lt;source bridge='brtest-ext'\/&gt;\r\n      &lt;vlan trunk='yes'&gt;\r\n        &lt;tag id='2102'\/&gt;\r\n        &lt;tag id='2103'\/&gt;\r\n        &lt;tag id='2110'\/&gt;\r\n        &lt;tag id='2999'\/&gt;\r\n        &lt;tag id='3000'\/&gt;\r\n      &lt;\/vlan&gt;\r\n      &lt;virtualport type='openvswitch'&gt;\r\n      &lt;\/virtualport&gt;\r\n      &lt;target dev='veth1-vmtest'\/&gt;\r\n      &lt;model type='virtio'\/&gt;\r\n      &lt;address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'\/&gt;\r\n    &lt;\/interface&gt;<\/pre>\n<h2>Native vlan<\/h2>\n<p>As with libvirt 1.02, it is not possible to use one vlan as the native vlan. Later libvirt versions support this. When a version is available for Ubuntu, I&#8217;ll add the necessaty section.<\/p>\n<h1>Define libvirt networks<\/h1>\n<p>The other method is to split the network configuration. The global part, which is the same for many VMs, can be defined using the virsh net-* commands. For the first network the procedure would be:<\/p>\n<p>Create an xml file (example name here mgmt.xml) using an editor of your choice. The file for the untagged interface should look like:<\/p>\n<pre class=\"lang:xhtml decode:true\" title=\"untagged network \">&lt;network&gt;\r\n  &lt;name&gt;Mgmt-2001&lt;\/name&gt;\r\n  &lt;forward mode='bridge'\/&gt;\r\n  &lt;bridge name='brtest' \/&gt;\r\n  &lt;virtualport type='openvswitch'&gt;\r\n  &lt;\/virtualport&gt;\r\n  &lt;vlan&gt;\r\n     &lt;tag id='2001'\/&gt;\r\n &lt;\/vlan&gt;\r\n&lt;\/network&gt;<\/pre>\n<p>The parameters are:<\/p>\n<ul>\n<li>The <strong>name<\/strong> of the network<\/li>\n<li>The <strong>forward mode<\/strong> is set to bridge &#8212; in the VM config, this is the <em>interface type<\/em><\/li>\n<li>The <strong>bridge name<\/strong> &#8212; in the VM config, this is the <em>source bridge<\/em><\/li>\n<li>The <strong>virtualport<\/strong> entry is the same as in the Vm config<\/li>\n<li>The <strong>vlan<\/strong> and <strong>tag<\/strong> entries are the same as in the VM config<\/li>\n<\/ul>\n<p>Then you must &#8222;import&#8220; the network definition to libvirt using the commands:<\/p>\n<pre class=\"lang:sh decode:true\" title=\"\" import=\"\" a=\"\" network=\"\" definition=\"\" to=\"\" libvirt=\"\">#\r\n# import the net config to libvirt\r\nvirsh net-define mgmt.xml\r\n#\r\n# start the new network - necessary to use it in libvirt\r\n# this DOES NOT create or touch the bridge!\r\n# this is only for the internal libvirt management\r\nvirsh net-start Mgmt-2001\r\n#\r\n# do not forget to set autostart for the network\r\n# if you forget this, the network will not be available after\r\n# the next system boot or libvirt restart\r\nvirsh net-autostart Mgmt-2001\r\n#\r\n# verify the status of the network\r\nvirsh net-list<\/pre>\n<p>The interface configuration for the VM should be changed to use the created network<\/p>\n<pre class=\"lang:sh decode:true\" title=\"Interface definition of the VM\">    &lt;interface type='network'&gt;\r\n      &lt;source network='Mgmt-2001'\/&gt;\r\n      &lt;target dev='veth0-test1'\/&gt;\r\n      &lt;model type='virtio'\/&gt;\r\n    &lt;\/interface&gt;<\/pre>\n<p>This looks much simpler now compared to the section above. The parameters are:<\/p>\n<ul>\n<li><strong>interface type<\/strong>\u00a0= network tells libvirt to use a predefined network<\/li>\n<li><strong>source network<\/strong> is the name of the predefined network<\/li>\n<li><strong>target dev<\/strong> ist the name of the interface as seen by the openvswitch (see my comments for this in the above section)<\/li>\n<li><strong>model<\/strong> should be set to virtio to get the best performance<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Running KVM using the Openvswitch one way to attach VMs to the network. When using libvirt 1.02 and higher, several configuration options are available. The virt-manager can only use openvswitch fake bridges, so the virt-manager is not the best tool to configure the network interfaces for VM&#8217;s. There are two ways to define libvirt networks: [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7,4],"tags":[],"_links":{"self":[{"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/posts\/177"}],"collection":[{"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=177"}],"version-history":[{"count":11,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/posts\/177\/revisions"}],"predecessor-version":[{"id":234,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=\/wp\/v2\/posts\/177\/revisions\/234"}],"wp:attachment":[{"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=177"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=177"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.opencloudblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=177"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}