1 files changed, 0 insertions, 774 deletions
diff --git a/doc/book-enea-nfv-access-guide/doc/hypervisor_virtualization.xml b/doc/book-enea-nfv-access-guide/doc/hypervisor_virtualization.xml
deleted file mode 100644
index 3f14719..0000000
--- a/doc/book-enea-nfv-access-guide/doc/hypervisor_virtualization.xml
+++ /dev/null
@@ -1,774 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-<chapter id="hypervisor_virt">
-  <title>Hypervisor Virtualization</title>
-  <para>The Kernel-based Virtual Machine (KVM), is a virtualization
-  infrastructure for the Linux kernel, which turns it into a hypervisor. KVM
-  requires a processor with a hardware virtualization extension.</para>
-  <para>KVM uses QEMU, an open source machine emulator and virtualizer, to
-  virtualize a complete system. With KVM it is possible to run multiple guests
-  of a variety of operating systems, each with a complete set of virtualized
-  hardware.</para>
-  <section id="launch_virt_machine">
-    <title>Launching a Virtual Machine</title>
-    <para>QEMU can make use of KVM when running a target architecture that is
-    the same as the host architecture. For instance, when running
-    <filename>qemu-system-aarch64</filename> on an <literal>aarch64</literal>
-    compatible processor with Hardware Virtualization support enabled, you can
-    take advantage of the KVM acceleration, an added benefit for your host and
-    guest system.</para>
-    <para>Enea NFV Access includes an optimized version of QEMU with KVM-only
-    support. To use KVM pass <command>--enable-kvm</command> to QEMU.</para>
-    <para>The following is an example of starting a guest system:</para>
-    <programlisting>taskset -c 0,1 qemu-system-aarch64 \
-cpu host -machine virt,gic_version=3 -smp cores=2,sockets=1 \
-vcpu 0,affinity=0 -vcpu 1,affinity=1  \
-enable-kvm -nographic \
-kernel Image \
-drive file=enea-nfv-access-guest-qemuarm64.ext4,if=virtio,format=raw \
-append 'root=/dev/vda console=ttyAMA0,115200' \
-m 4096 \
-object memory-backend-file,id=mem,size=4096M,mem-path=/dev/hugepages,share=on \
-numa node,memdev=mem -mem-prealloc</programlisting>
-  </section>
-  <section id="qemu_boot">
-    <title>Primary QEMU boot options</title>
-    <para>Below are detailed all the pertinent boot options for the QEMU
-    emulator:</para>
-    <itemizedlist>
-      <listitem>
-        <para>SMP - at least 2 cores should be enabled in order to isolate the
-        application(s) running in the virtual machine(s), on specific cores,
-        for better performance:</para>
-        <programlisting>-smp cores=2,threads=1,sockets=1 \</programlisting>
-      </listitem>
-      <listitem>
-        <para>CPU affinity - associate virtual CPUs with physical CPUs, and
-        optionally assign a default realtime priority to the virtual CPU
-        process in the host kernel. This option allows you to start QEMU vCPUs
-        on isolated physical CPUs:</para>
-        <programlisting>-vcpu 0,affinity=0   \</programlisting>
-      </listitem>
-      <listitem>
-        <para>Hugepages - KVM guests can be deployed with hugepage memory
-        support to reduce memory consumption and improve performance, by
-        reducing CPU cache usage. By using hugepages for a KVM guest, less
-        memory is used for page tables and TLB (Translation Lookaside Buffer)
-        misses are reduced, significantly increasing performance, especially
-        for memory-intensive situations.</para>
-        <programlisting>-object memory-backend-file,id=mem,size=4096M,mem-path=/dev/hugepages,share=on \</programlisting>
-      </listitem>
-      <listitem>
-        <para>Memory preallocation - preallocate hugepages at startup to
-        improve performance. This may affect QEMU boot time.</para>
-        <programlisting>-mem-prealloc \</programlisting>
-      </listitem>
-      <listitem>
-        <para>Enable realtime characteristics - run QEMU with realtime
-        features.</para>
-        <para>In this case, "realtime" is just an identifier for options that
-        are partially realtime. If you're running in a realtime or low latency
-        environment, and you don't want your pages to be swapped out, this can
-        be ensured by using <command>mlock=on</command>. If you want VM
-        density, then you may want swappable VMs, this can be done with
-        <command>mlock=off</command>.</para>
-        <programlisting>-realtime mlock=on \</programlisting>
-      </listitem>
-    </itemizedlist>
-    <para>If the hardware does not have an IOMMU, it will not be possible to
-    assign devices in KVM.</para>
-  </section>
-  <section id="net_in_guest">
-    <title>Networking in guest</title>
-    <section id="vhost-user-support">
-      <title>Using vhost-user support</title>
-      <para>The goal of <literal>vhost-user</literal> is to implement a Virtio
-      transport, staying as close as possible to the <literal>vhost</literal>
-      paradigm of using: shared memory, <literal>ioeventfds</literal> and
-      <literal>irqfds</literal>. A UNIX domain socket based mechanism, allows
-      for the set up of resources used by various <literal>Vrings</literal>
-      shared between two userspace processes, and will be placed in shared
-      memory.</para>
-      <para>To run QEMU with the <literal>vhost-user</literal> backend, you
-      have to provide the named UNIX domain socket, which needs to already be
-      opened by the backend:</para>
-      <programlisting>-object memory-backend-file,id=mem,size=4096M,mem-path=/dev/hugepages,share=on \
-chardev socket,id=char0,path=/var/run/openvswitch/vhost-user1 \
-netdev type=vhost-user,id=mynet1,chardev=char0,vhostforce \
-device virtio-net-pci,netdev=mynet1,mac=52:54:00:00:00:01  \</programlisting>
-      <para>The vHost User standard uses a client-server model. The server
-      creates and manages the vHost User sockets and the client connects to
-      the sockets created by the server. It is recommended to use QEMU as the
-      server, so that the <literal>vhost-user</literal> client can be
-      restarted without affecting the server, otherwise if the server side
-      dies, all clients need to be restarted.</para>
-      <para>Using <literal>vhost-user</literal> in QEMU will offer the
-      flexibility to stop and start the virtual machine with no impact on the
-      virtual switch from the host
-      (<literal>vhost-user-client</literal>).</para>
-      <programlisting>-chardev socket,id=char0,path=/var/run/openvswitch/vhost-user1,server \</programlisting>
-    </section>
-    <section id="tap-interface">
-      <title>Using TAP Interfaces</title>
-      <para>QEMU can use TAP interfaces to provide full networking capability
-      for the guest OS:</para>
-      <programlisting>-netdev tap,id=net0,ifname=tap0,script=no,downscript=no \
-device virtio-net-pci,netdev=net0,mac=22:EA:FB:A8:25:AE \</programlisting>
-    </section>
-    <section id="vfio-passthrough">
-      <title>VFIO passthrough VF (SR-IOV) to guest</title>
-      <para>KVM hypervisor support for attaching PCI devices on the host
-      system to guests. PCI passthrough allows guests to have exclusive access
-      to PCI devices for a range of tasks. PCI passthrough allows PCI devices
-      to appear and behave as if they were physically attached to the guest
-      operating system.</para>
-      <para>Create guest with direct passthrough via VFIO framework like
-      so:</para>
-      <programlisting>-device vfio-pci,host=0001:01:00.1 \</programlisting>
-      <para>On the host, there are Virtual Functions for each physical
-      Ethernet port. The primary VF has to be used for a guest network to
-      access, before starting QEMU:</para>
-      <programlisting>$ modprobe vfio_pci
-$ dpdk-devbind.py --bind=vfio-pci 0001:01:00.1</programlisting>
-      <para>For more details related to Virtual Functions, see: <ulink
-      url="http://dpdk.org/doc/guides/nics/thunderx.html">http://dpdk.org/doc/guides/nics/thunderx.html</ulink>.</para>
-    </section>
-    <section>
-      <title>Enable VFIO-NOIOMMU mode</title>
-      <para>In order to run a DPDK application in VM, the VFIO-NOIOMMU needs
-      to be set: <programlisting>echo 1 &gt; /sys/module/vfio/parameters/enable_unsafe_noiommu_mode</programlisting></para>
-    </section>
-    <section id="multiqueue">
-      <title>Multi-queue</title>
-      <para>In order to ensure that network performance scales as the number
-      of vCPUs increases, multi-queue support can be used in QEMU.</para>
-      <section id="qemu-multiqueue-support">
-        <title>QEMU multi-queue support configuration</title>
-        <para>Below is an example of how to set up the QEMU multi-queue
-        support configuration:</para>
-        <programlisting>-chardev socket,id=char0,path=/var/run/openvswitch/vhost-user1 \
-netdev type=vhost-user,id=net0,chardev=char0,queues=2 \
-device virtio-net-pci,netdev=net0,mac=22:EA:FB:A8:25:AE,mq=on,vectors=6
-where vectors is calculated as: 2 + 2 * queues number.</programlisting>
-      </section>
-      <section id="inside-guest">
-        <title>Inside guest</title>
-        <para>The Linux kernel <filename>virtio-net</filename> driver, where
-        one queue is enabled by default:</para>
-        <programlisting>$ ethtool -L combined 2 eth0
-DPDK Virtio PMD
-$ testpmd -c 0x7 -- -i --rxq=2 --txq=2 --nb-cores=2 ...</programlisting>
-        <para>For QEMU documentation, see: <ulink
-        url="https://qemu.weilnetz.de/doc/qemu-doc.html">QEMU User
-        Documentation</ulink>.</para>
-      </section>
-    </section>
-  </section>
-  <section id="libvirt">
-    <title>Libvirt</title>
-    <para>One way to manage guests in Enea NFV Access is by using
-    <literal>libvirt</literal>. Libvirt is used in conjunction with a daemon
-    (<literal>libvirtd</literal>) and a command line utility
-    (<literal>virsh</literal>) to manage virtualized environments.</para>
-    <para>The <literal>libvirt</literal> library is a hypervisor-independent
-    virtualization API and toolkit that is able to interact with the
-    virtualization capabilities of a range of operating systems.
-    <literal>Libvirt</literal> provides a common, generic and stable layer to
-    securely manage domains on a node. As nodes may be remotely located, it
-    provides all methods required to provision, create, modify, monitor,
-    control, migrate and stop the domains, within the limits of hypervisor
-    support for these operations.</para>
-    <para>The <literal>libvirt</literal> daemon runs on the Enea NFV Access
-    host. All tools built upon the libvirt API, connect to the daemon to
-    request the desired operation, and to collect information about the
-    configuration and resources of the host system and guests.
-    <literal>virsh</literal> is a command line interface tool for managing
-    guests and the hypervisor. The <literal>virsh</literal> tool is built upon
-    the libvirt management API.</para>
-    <para><emphasis role="bold">Major functionality provided by
-    libvirt</emphasis></para>
-    <para>The following is a summary from the libvirt <ulink
-    url="http://wiki.libvirt.org/page/FAQ#What_is_libvirt.3F">home
-    page</ulink> describing the major libvirt features:</para>
-    <itemizedlist>
-      <listitem>
-        <para><emphasis role="bold">VM management:</emphasis> Various domain
-        lifecycle operations such as start, stop, pause, save, restore, and
-        migrate. Hotplug operations for many device types including disk and
-        network interfaces, memory, and CPUs.</para>
-      </listitem>
-      <listitem>
-        <para><emphasis role="bold">Remote machine support:</emphasis> All
-        libvirt functionality is accessible on any machine running the libvirt
-        daemon, including remote machines. A variety of network transports are
-        supported for connecting remotely, with the simplest being
-        <literal>SSH</literal>, which requires no extra explicit
-        configuration. For more information, see: <ulink
-        url="http://libvirt.org/remote.html">http://libvirt.org/remote.html</ulink>.</para>
-      </listitem>
-      <listitem>
-        <para><emphasis role="bold">Network interface management:</emphasis>
-        Any host running the libvirt daemon can be used to manage physical and
-        logical network interfaces. Enumerate existing interfaces, as well as
-        configure (and create) interfaces, bridges, vlans, and bond devices.
-        For more details see: <ulink
-        url="https://fedorahosted.org/netcf/">https://fedorahosted.org/netcf/</ulink>.</para>
-      </listitem>
-      <listitem>
-        <para><emphasis role="bold">Virtual NAT and Route based
-        networking:</emphasis> Any host running the libvirt daemon can manage
-        and create virtual networks. Libvirt virtual networks use firewall
-        rules to act as a router, providing VMs transparent access to the host
-        machines network. For more information, see: <ulink
-        url="http://libvirt.org/archnetwork.html">http://libvirt.org/archnetwork.html</ulink>.</para>
-      </listitem>
-      <listitem>
-        <para><emphasis role="bold">Storage management:</emphasis> Any host
-        running the libvirt daemon can be used to manage various types of
-        storage: create file images of various formats (raw, qcow2, etc.),
-        mount NFS shares, enumerate existing LVM volume groups, create new LVM
-        volume groups and logical volumes, partition raw disk devices, mount
-        iSCSI shares, and much more. For more details, see: <ulink
-        url="http://libvirt.org/storage.html">http://libvirt.org/storage.html</ulink>.</para>
-      </listitem>
-      <listitem>
-        <para><emphasis role="bold">Libvirt Configuration:</emphasis> A
-        properly running libvirt requires that the following elements be in
-        place:</para>
-        <itemizedlist>
-          <listitem>
-            <para>Configuration files, located in the directory
-            <literal>/etc/libvirt</literal>. They include the daemon's
-            configuration file <literal>libvirtd.conf</literal>, and
-            hypervisor-specific configuration files, like
-            <literal>qemu.conf</literal> for the QEMU.</para>
-          </listitem>
-          <listitem>
-            <para>A running libvirtd daemon. The daemon is started
-            automatically in Enea NFV Access host.</para>
-          </listitem>
-          <listitem>
-            <para>Configuration files for the libvirt domains, or guests, to
-            be managed by the KVM host. The specifics for guest domains shall
-            be defined in an XML file of a format specified at <ulink
-            url="http://libvirt.org/formatdomain.html">http://libvirt.org/formatdomain.html</ulink>.
-            XML formats for other structures are specified at <ulink type=""
-            url="http://libvirt.org/format.html">http://libvirt.org/format.html</ulink>.</para>
-          </listitem>
-        </itemizedlist>
-      </listitem>
-    </itemizedlist>
-    <section id="boot-kvm-guest">
-      <title>Booting a KVM Guest</title>
-      <para>There are several ways to boot a KVM guest. Here we describe how
-      to boot using a raw image. A direct kernel boot can be performed by
-      transferring the guest kernel and the file system files to the host and
-      specifying a <literal>&lt;kernel&gt;</literal> and an
-      <literal>&lt;initrd&gt;</literal> element inside the
-      <literal>&lt;os&gt;</literal> element of the guest XML file, as in the
-      following example:</para>
-      <programlisting>&lt;os&gt;
-  &lt;kernel&gt;Image&lt;/kernel&gt;
-&lt;/os&gt;
-&lt;devices&gt;
-  &lt;disk type='file' device='disk'&gt;
-    &lt;driver name='qemu' type='raw' cache='none'/&gt;
-    &lt;source file='enea-nfv-access-guest-qemuarm64.ext4'/&gt;
-    &lt;target dev='vda' bus='virtio'/&gt;
-  &lt;/disk&gt;
-&lt;/devices&gt;</programlisting>
-    </section>
-    <section id="start-guest">
-      <title>Starting a Guest</title>
-      <para>Command <command>virsh create</command> starts a guest:</para>
-      <programlisting>virsh create example-guest-arm.xml</programlisting>
-      <para>If further configurations are needed before the guest is reachable
-      through <literal>ssh</literal>, a console can be started using command
-      <command>virsh console</command>. The example below shows how to start a
-      console where kvm-example-guest is the name of the guest defined in the
-      guest XML file:</para>
-      <programlisting>virsh console kvm-example-guest</programlisting>
-      <para>This requires that the guest domain has a console configured in
-      the guest XML file:</para>
-      <programlisting>&lt;os&gt;
-  &lt;cmdline&gt;console=ttyAMA0,115200&lt;/cmdline&gt;
-&lt;/os&gt;
-&lt;devices&gt;
-  &lt;console type='pty'&gt;
-     &lt;target type='serial' port='0'/&gt;
-  &lt;/console&gt;
-&lt;/devices&gt;</programlisting>
-    </section>
-    <section id="isolation">
-      <title>Isolation</title>
-      <para>It may be desirable to isolate execution in a guest, to a specific
-      guest core. It might also be desirable to run a guest on a specific host
-      core.</para>
-      <para>To pin the virtual CPUs of the guest to specific cores, configure
-      the <literal>&lt;cputune&gt;</literal> contents as follows:</para>
-      <orderedlist>
-        <listitem>
-          <para>First explicitly state on which host core each guest core
-          shall run, by mapping <literal>vcpu</literal> to
-          <literal>cpuset</literal> in the <literal>&lt;vcpupin&gt;</literal>
-          tag.</para>
-        </listitem>
-        <listitem>
-          <para>In the <literal>&lt;cputune&gt;</literal> tag it is further
-          possible to specify on which CPU the emulator shall run by adding
-          the <literal>cpuset</literal> to the
-          <literal>&lt;emulatorpin&gt;</literal> tag.</para>
-          <programlisting>&lt;vcpu placement='static'&gt;2&lt;/vcpu&gt;
-&lt;cputune&gt;
-  &lt;vcpupin vcpu='0' cpuset='2'/&gt;
-  &lt;vcpupin vcpu='1' cpuset='3'/&gt;
-  &lt;emulatorpin cpuset="2"/&gt;
-&lt;/cputune&gt;</programlisting>
-          <para><literal>libvirt</literal> will group all threads belonging to
-          a QEMU instance into cgroups that will be created for that purpose.
-          It is possible to supply a base name for those cgroups using the
-          <literal>&lt;resource&gt;</literal> tag:</para>
-          <programlisting>&lt;resource&gt;
-  &lt;partition&gt;/rt&lt;/partition&gt;
-&lt;/resource&gt;</programlisting>
-        </listitem>
-      </orderedlist>
-    </section>
-    <section id="network-libvirt">
-      <title>Networking using libvirt</title>
-      <para>Command <command>virsh net-create</command> starts a network. If
-      any networks are listed in the guest XML file, those networks must be
-      started before the guest is started. As an example, if the network is
-      defined in a file named <filename>example-net.xml</filename>, it will be
-      started as such:</para>
-      <programlisting>virsh net-create example-net.xml
-&lt;network&gt;
-   &lt;name&gt;sriov&lt;/name&gt;
-   &lt;forward mode='hostdev' managed='yes'&gt;
-     &lt;pf dev='eno3'/&gt;
-   &lt;/forward&gt;
-&lt;/network&gt;</programlisting>
-      <para><literal>libvirt</literal> is a virtualization API that supports
-      virtual network creation. These networks can be connected to guests and
-      containers by referencing the network in the guest XML file. It is
-      possible to have a virtual network persistently running on the host by
-      starting the network with command <command>virsh net-define</command>
-      instead of the previously mentioned <command>virsh
-      net-create</command>.</para>
-      <para>An example for the sample network defined in
-      <literal>meta-vt/recipes-example/virt-example/files/example-net.xml</literal>:</para>
-      <programlisting>virsh net-define example-net.xml</programlisting>
-      <para>Command <command>virsh net-autostart</command> enables a
-      persistent network to start automatically when the libvirt daemon
-      starts:</para>
-      <programlisting>virsh net-autostart example-net</programlisting>
-      <para>The guest configuration file (xml) must be updated to access the
-      newly created network like so:</para>
-      <programlisting>    &lt;interface type='network'&gt;
-      &lt;source network='sriov'/&gt;
-    &lt;/interface&gt;</programlisting>
-      <para>The following are a few ways of network access from a guest while
-      using <command>virsh</command>:</para>
-      <itemizedlist>
-        <listitem>
-          <para><emphasis role="bold">vhost-user interface</emphasis></para>
-          <para>See the Open vSwitch chapter on how to create a
-          <literal>vhost-user</literal> interface using Open vSwitch(OVS).
-          Currently there is no Open vSwitch(OVS) support for networks that
-          are managed by <literal>libvirt </literal>(e.g. NAT). Until further
-          notice, only bridged networks are supported (those where the user
-          has to manually create the bridge). In order to pass Open vSwitch
-          configuration the &lt;qemu:commandline&gt; is used.</para>
-          <programlisting>    &lt;qemu:commandline&gt;
-      &lt;qemu:arg value='-chardev'/&gt;
-      &lt;qemu:arg value='socket,id=charnet0,path=/var/run/openvswitch/vhost-user1'/&gt;
-      &lt;qemu:arg value='-netdev'/&gt;
-      &lt;qemu:arg value='type=vhost-user,id=hostnet0,chardev=charnet0'/&gt;
-      &lt;qemu:arg value='-device'/&gt;
-      &lt;qemu:arg value='virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:00:00:00:01,/
-      bus=pcie.0,addr=0x2'/&gt;
-    &lt;/qemu:commandline&gt;</programlisting>
-        </listitem>
-        <listitem>
-          <para><emphasis role="bold">PCI passthrough
-          (SR-IOV)</emphasis></para>
-          <para>KVM hypervisor support for attaching PCI devices on the host
-          system to guests. PCI passthrough allows guests to have exclusive
-          access to PCI devices for a range of tasks. PCI passthrough allows
-          PCI devices to appear and behave as if they were physically attached
-          to the guest operating system.</para>
-          <para>Preparing a system for PCI passthrough is done like so:</para>
-          <itemizedlist>
-            <listitem>
-              <para>Change the owner of the
-              <literal>/dev/vfio/&lt;group&gt;</literal> to QEMU and edit
-              <literal>/etc/libvirt/qemu.conf</literal> to explicitly allow
-              permission to it:</para>
-              <para><programlisting>$ chown qemu:qemu /dev/vfio/66
-$ ls -l /dev/vfio/66
-crw------- 1 qemu qemu 244, 0 Dec  4 08:24 /dev/vfio/66
-$ cat /etc/libvirt/qemu.conf
-...
-cgroup_device_acl = [
-    "/dev/null", "/dev/full", "/dev/zero",
-    "/dev/random", "/dev/urandom",
-    "/dev/ptmx", "/dev/kvm", "/dev/kqemu",
-    "/dev/rtc","/dev/hpet", "/dev/vfio/vfio",
-    <command>"/dev/vfio/66"</command>,
-]
-...</programlisting></para>
-            </listitem>
-            <listitem>
-              <para>Increase the locked memory limits within the libvirtd
-              service file:</para>
-              <para><programlisting>$ cat /lib/systemd/system/libvirtd.service
-...
-[Service]
-Type=forking
-PIDFile=/var/run/libvirtd.pid
-EnvironmentFile=-/etc/sysconfig/libvirtd
-<command>LimitMEMLOCK=infinity</command>
-ExecStart=/usr/sbin/libvirtd $LIBVIRTD_ARGS
-ExecReload=/bin/kill -HUP $MAINPID
-KillMode=process
-Restart=on-failure
-# Override the maximum number of opened files
-#LimitNOFILE=2048
-...</programlisting></para>
-            </listitem>
-            <listitem>
-              <para>VFs must be created on the host before starting the
-              guest:</para>
-              <programlisting>$ modprobe vfio_pci
-$ dpdk-devbind.py --bind=vfio-pci 0001:01:00.1
-   &lt;qemu:commandline&gt;
-     &lt;qemu:arg value='-device'/&gt;
-     &lt;qemu:arg value='vfio-pci,host=0001:01:00.1'/&gt;
-   &lt;/qemu:commandline&gt;</programlisting>
-            </listitem>
-          </itemizedlist>
-        </listitem>
-        <listitem>
-          <para><emphasis role="bold">Bridge interface</emphasis></para>
-          <para>In case an OVS bridge exists on host, it can be used to
-          connect the guest:</para>
-          <programlisting>    &lt;interface type='bridge'&gt;
-      &lt;mac address='52:54:00:71:b1:b6'/&gt;
-      &lt;source bridge='ovsbr0'/&gt;
-      &lt;model type='rtl8139'/&gt;
-      &lt;virtualport type='openvswitch'/&gt;
-    &lt;/interface&gt;</programlisting>
-          <para>For further details on the network XML format, see <ulink
-          url="http://libvirt.org/formatnetwork.html">http://libvirt.org/formatnetwork.html</ulink>.</para>
-        </listitem>
-      </itemizedlist>
-    </section>
-    <section id="libvirt-guest-config-ex">
-      <title>Libvirt guest configuration examples</title>
-      <note>
-        <para>Currently used Libvirt version has some limitations for aarch64
-        which are bypassed using the qemu:commandline option.</para>
-      </note>
-      <example>
-        <title>Guest configuration with vhost-user interface</title>
-        <programlisting>&lt;domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'&gt;
-  &lt;name&gt;vm_vhost&lt;/name&gt;
-  &lt;uuid&gt;ed204646-1ad5-11e7-93ae-92361f002671&lt;/uuid&gt;
-  &lt;memory unit='KiB'&gt;4194304&lt;/memory&gt;
-  &lt;currentMemory unit='KiB'&gt;4194304&lt;/currentMemory&gt;
-  &lt;memoryBacking&gt;
-    &lt;hugepages&gt;
-      &lt;page size='512' unit='M' nodeset='0'/&gt;
-    &lt;/hugepages&gt;
-  &lt;/memoryBacking&gt;
-  &lt;os&gt;
-    &lt;type arch='aarch64' machine='virt,gic_version=3'&gt;hvm&lt;/type&gt;
-    &lt;kernel&gt;/mnt/qemu/Image&lt;/kernel&gt;
-    &lt;cmdline&gt;root=/dev/vda console=ttyAMA0,115200n8&lt;/cmdline&gt;
-    &lt;boot dev='hd'/&gt;
-  &lt;/os&gt;
-  &lt;features&gt;
-    &lt;acpi/&gt;
-    &lt;apic/&gt;
-  &lt;/features&gt;
-  &lt;vcpu placement='static'&gt;2&lt;/vcpu&gt;
-  &lt;cpu mode='host-model'&gt;
-    &lt;model fallback='allow'/&gt;
-    &lt;topology sockets='1' cores='2' threads='1'/&gt;
-    &lt;numa&gt;
-      &lt;cell id='0' cpus='0' memory='4194304' unit='KiB' memAccess='shared'/&gt;
-    &lt;/numa&gt;
-  &lt;/cpu&gt;
-  &lt;cputune&gt;
-     &lt;vcpupin vcpu="0" cpuset="4"/&gt;
-     &lt;vcpupin vcpu="1" cpuset="5"/&gt;
-  &lt;/cputune&gt;
-  &lt;on_poweroff&gt;destroy&lt;/on_poweroff&gt;
-  &lt;on_reboot&gt;restart&lt;/on_reboot&gt;
-  &lt;on_crash&gt;destroy&lt;/on_crash&gt;
-  &lt;devices&gt;
-    &lt;emulator&gt;/usr/bin/qemu-system-aarch64&lt;/emulator&gt;
-    &lt;disk type='file' device='disk'&gt;
-      &lt;driver name='qemu' type='raw' cache='none'/&gt;
-      &lt;source file='/mnt/qemu/enea-nfv-access-guest-qemuarm64.ext4'/&gt;
-      &lt;target dev='vda' bus='virtio'/&gt;
-    &lt;/disk&gt;
-    &lt;serial type='pty'&gt;
-      &lt;target port='0'/&gt;
-    &lt;/serial&gt;
-    &lt;console type='pty'&gt;
-      &lt;target type='serial' port='0'/&gt;
-    &lt;/console&gt;
-  &lt;/devices&gt;
-  &lt;qemu:commandline&gt;
-     &lt;qemu:arg value='-chardev'/&gt;
-     &lt;qemu:arg value='socket,id=charnet0,path=/var/run/openvswitch/vhost-user1'/&gt;
-     &lt;qemu:arg value='-netdev'/&gt;
-     &lt;qemu:arg value='type=vhost-user,id=hostnet0,chardev=charnet0'/&gt;
-     &lt;qemu:arg value='-device'/&gt;
-     &lt;qemu:arg value='virtio-net-pci,netdev=hostnet0,id=net0,mac=00:00:00:00:00:01,/
-     bus=pcie.0,addr=0x2'/&gt;
-  &lt;/qemu:commandline&gt;
-&lt;/domain&gt;</programlisting>
-      </example>
-      <example>
-        <title>Guest configuration with PCI passthrough</title>
-        <programlisting>&lt;domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'&gt;
-  &lt;name&gt;vm_sriov&lt;/name&gt;
-  &lt;uuid&gt;ed204646-1ad5-11e7-93ae-92361f002671&lt;/uuid&gt;
-  &lt;memory unit='KiB'&gt;4194304&lt;/memory&gt;
-  &lt;currentMemory unit='KiB'&gt;4194304&lt;/currentMemory&gt;
-  &lt;memoryBacking&gt;
-    &lt;hugepages&gt;
-      &lt;page size='512' unit='M' nodeset='0'/&gt;
-    &lt;/hugepages&gt;
-  &lt;/memoryBacking&gt;
-  &lt;os&gt;
-    &lt;type arch='aarch64' machine='virt,gic_version=3'&gt;hvm&lt;/type&gt;
-    &lt;kernel&gt;/mnt/qemu/Image&lt;/kernel&gt;
-    &lt;cmdline&gt;root=/dev/vda console=ttyAMA0,115200n8&lt;/cmdline&gt;
-    &lt;boot dev='hd'/&gt;
-  &lt;/os&gt;
-  &lt;features&gt;
-    &lt;acpi/&gt;
-    &lt;apic/&gt;
-  &lt;/features&gt;
-  &lt;vcpu placement='static'&gt;2&lt;/vcpu&gt;
-  &lt;cpu mode='host-model'&gt;
-    &lt;model fallback='allow'/&gt;
-    &lt;topology sockets='1' cores='2' threads='1'/&gt;
-    &lt;numa&gt;
-      &lt;cell id='0' cpus='0' memory='4194304' unit='KiB' memAccess='shared'/&gt;
-    &lt;/numa&gt;
-  &lt;/cpu&gt;
-  &lt;cputune&gt;
-     &lt;vcpupin vcpu="0" cpuset="4"/&gt;
-     &lt;vcpupin vcpu="1" cpuset="5"/&gt;
-  &lt;/cputune&gt;
-  &lt;on_poweroff&gt;destroy&lt;/on_poweroff&gt;
-  &lt;on_reboot&gt;restart&lt;/on_reboot&gt;
-  &lt;on_crash&gt;destroy&lt;/on_crash&gt;
-  &lt;devices&gt;
-    &lt;emulator&gt;/usr/bin/qemu-system-aarch64&lt;/emulator&gt;
-    &lt;disk type='file' device='disk'&gt;
-      &lt;driver name='qemu' type='raw' cache='none'/&gt;
-      &lt;source file='/mnt/qemu/enea-nfv-access-guest-qemuarm64.ext4'/&gt;
-      &lt;target dev='vda' bus='virtio'/&gt;
-    &lt;/disk&gt;
-    &lt;serial type='pty'&gt;
-      &lt;target port='0'/&gt;
-    &lt;/serial&gt;
-    &lt;console type='pty'&gt;
-      &lt;target type='serial' port='0'/&gt;
-    &lt;/console&gt;
-  &lt;/devices&gt;
-  &lt;qemu:commandline&gt;
-     &lt;qemu:arg value='-device'/&gt;
-     &lt;qemu:arg value='vfio-pci,host=0001:01:00.1'/&gt;
-  &lt;/qemu:commandline&gt;
-&lt;/domain&gt;</programlisting>
-      </example>
-      <example>
-        <title>Guest configuration with bridge interface</title>
-        <programlisting>&lt;domain type='kvm'&gt;
-  &lt;name&gt;vm_bridge&lt;/name&gt;
-  &lt;uuid&gt;4a9b3f53-fa2a-47f3-a757-dd87720d9d1d&lt;/uuid&gt;
-  &lt;memory unit='KiB'&gt;4194304&lt;/memory&gt;
-  &lt;currentMemory unit='KiB'&gt;4194304&lt;/currentMemory&gt;
-  &lt;memoryBacking&gt;
-    &lt;hugepages&gt;
-      &lt;page size='1' unit='G' nodeset='0'/&gt;
-    &lt;/hugepages&gt;
-  &lt;/memoryBacking&gt;
-  &lt;vcpu placement='static'&gt;2&lt;/vcpu&gt;
-  &lt;cputune&gt;
-    &lt;shares&gt;4096&lt;/shares&gt;
-    &lt;vcpupin vcpu='0' cpuset='4'/&gt;
-    &lt;vcpupin vcpu='1' cpuset='5'/&gt;
-    &lt;emulatorpin cpuset='4,5'/&gt;
-  &lt;/cputune&gt;
-  &lt;os&gt;
-    &lt;type arch='x86_64' machine='q35'&gt;hvm&lt;/type&gt;
-    &lt;kernel&gt;/mnt/qemu/bzImage&lt;/kernel&gt;
-    &lt;cmdline&gt;root=/dev/vda console=ttyS0,115200&lt;/cmdline&gt;
-    &lt;boot dev='hd'/&gt;
-  &lt;/os&gt;
-  &lt;features&gt;
-    &lt;acpi/&gt;
-    &lt;apic/&gt;
-  &lt;/features&gt;
-  &lt;cpu mode='host-model'&gt;
-    &lt;model fallback='allow'/&gt;
-    &lt;topology sockets='2' cores='1' threads='1'/&gt;
-    &lt;numa&gt;
-      &lt;cell id='0' cpus='0-1' memory='4194304' unit='KiB' memAccess='shared'/&gt;
-    &lt;/numa&gt;
-  &lt;/cpu&gt;
-  &lt;on_poweroff&gt;destroy&lt;/on_poweroff&gt;
-  &lt;on_reboot&gt;restart&lt;/on_reboot&gt;
-  &lt;on_crash&gt;destroy&lt;/on_crash&gt;
-  &lt;devices&gt;
-    &lt;emulator&gt;/usr/bin/qemu-system-x86_64&lt;/emulator&gt;
-    &lt;disk type='file' device='disk'&gt;
-      &lt;driver name='qemu' type='raw' cache='none'/&gt;
-      &lt;source file='/mnt/qemu/enea-nfv-access-guest-qemux86-64.ext4'/&gt;
-      &lt;target dev='vda' bus='virtio'/&gt;
-    &lt;/disk&gt;vi
-    &lt;interface type='bridge'&gt;
-      &lt;mac address='52:54:00:71:b1:b6'/&gt;
-      &lt;source bridge='ovsbr0'/&gt;
-      &lt;model type='rtl8139'/&gt;
-      &lt;virtualport type='openvswitch'/&gt;
-    &lt;/interface&gt;
-    &lt;serial type='pty'&gt;
-      &lt;target port='0'/&gt;
-    &lt;/serial&gt;
-    &lt;console type='pty'&gt;
-      &lt;target type='serial' port='0'/&gt;
-    &lt;/console&gt;
-  &lt;/devices&gt;
-&lt;/domain&gt;</programlisting>
-      </example>
-    </section>
-  </section>
-</chapter>
-\ No newline at end of file