4 files changed, 759 insertions, 6 deletions

diff --git a/doc/book-enea-nfv-access-platform-guide/doc/benchmarks.xml b/doc/book-enea-nfv-access-platform-guide/doc/benchmarks.xml
index 0db4fa4..5d6e268 100644
--- a/doc/book-enea-nfv-access-platform-guide/doc/benchmarks.xml
+++ b/doc/book-enea-nfv-access-platform-guide/doc/benchmarks.xml
@@ -1,7 +1,7 @@
 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-<chapter id="workflow">
+<chapter condition="hidden" id="benchmarks">
   <title>Benchmarks</title>
 
   <para></para>
diff --git a/doc/book-enea-nfv-access-platform-guide/doc/container_virtualization.xml b/doc/book-enea-nfv-access-platform-guide/doc/container_virtualization.xml
index 6f74061..c6ce223 100644
--- a/doc/book-enea-nfv-access-platform-guide/doc/container_virtualization.xml
+++ b/doc/book-enea-nfv-access-platform-guide/doc/container_virtualization.xml
@@ -1,8 +1,138 @@
-<?xml version="1.0" encoding="UTF-8"?>
+<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-<chapter condition="hidden" id="workflow">
+<chapter id="container-virtualization">
   <title>Container Virtualization</title>
 
-  <para></para>
+  <section id="docker">
+    <title>Docker</title>
+
+    <para>Docker is an open-source project that automates the deployment of
+    applications inside software containers, by providing an additional layer
+    of abstraction and automation of operating-system-level virtualization on
+    Linux.</para>
+
+    <para>The software container mechanism uses resource isolation features
+    inside the Linux kernel, such as cgroups and kernel namespaces to allow
+    multiple containers to run within a single Linux instance, avoiding the
+    overhead of starting and maintaining virtual machines. </para>
+
+    <para>Containers are lightweight and include everything needed to run
+    themselves: code, runtime, system tools, system libraries and settings.
+    The main advantage provided by containers is that the encapsulated
+    software is isolated from its surroundings. For example, differences
+    between development and staging environments can be kept separate in order
+    to reduce conflicts between teams running different software on the same
+    infrastructure. </para>
+
+    <para>For a better understanding of what Docker is and how it works, the
+    official documentation provided on the Docker website should be consulted:
+    <ulink
+    url="https://docs.docker.com/">https://docs.docker.com/</ulink>.</para>
+
+    <section id="launch-docker-container">
+      <title>Launching a Docker container</title>
+
+      <para>Docker provides a hello-world container which checks whether your
+      system is running the daemon correctly. This container can be launched
+      by simply running:</para>
+
+      <programlisting>&gt;docker run hello-world
+
+Hello from Docker!</programlisting>
+
+      <para>This message shows that your installation appears to be working
+      correctly.</para>
+    </section>
+
+    <section id="run-enfv-guest-image">
+      <title>Run an Enea NFV Access Platform guest image</title>
+
+      <para>Enea NFV Access Platform guest images can run inside Docker as any
+      other container can. Before starting an Enea NFV Access Platform guest
+      image, a root filesystem has to be imported in Docker:</para>
+
+      <programlisting>&gt;docker import enea-linux-virtualization-guest-x86-64.tar.gz el7guest</programlisting>
+
+      <para>To check that the Docker image has been imported successfully,
+      run:</para>
+
+      <programlisting>&gt;docker images</programlisting>
+
+      <para>Finally, start an Enea NFV Access Platform container with
+      <literal>bash</literal> running as the shell, by running:</para>
+
+      <programlisting>&gt;docker run -it el7guest /bin/bash</programlisting>
+    </section>
+
+    <section id="attach-ext-resources-docker-containers">
+      <title>Attach external resources to Docker containers</title>
+
+      <para>Any system resource present on the host machine can be attached or
+      accessed by a Docker container.</para>
+
+      <para>Typically, if a file or folder on the host machine needs to be
+      attached to a container, that container should be launched with the
+      <literal>-v</literal> parameter. For example, to attach the
+      <literal>roots</literal> home folder to a container, the command line
+      for Docker should have the following format:</para>
+
+      <programlisting>&gt;docker run -it -v /home/root:/home/host_root/ el7guest /bin/bash</programlisting>
+
+      <para>To check that folders have been properly passed from the host to
+      the container, create a file in the source folder on the host root
+      filesystem and check for its existence inside the containers destination
+      location.</para>
+
+      <section id="attach-vhost-descriptors">
+        <title>Attach vhost file descriptors</title>
+
+        <para>If OVS is running on the host and vhost file descriptors need to
+        be passed to the container, this can be done by either mapping the
+        folder where all the file descriptors are located or mapping the file
+        descriptor itself:</para>
+
+        <itemizedlist>
+          <listitem>
+            <para>Mapping the folder can be done as exemplified above:</para>
+
+            <programlisting>docker run -it --rm -v /var/run/openvswitch/:/var/run/openvswitch/ el7guest /bin/bash</programlisting>
+          </listitem>
+
+          <listitem>
+            <para>Mapping a file descriptor is done in a similar way, but the
+            <literal>-v</literal> flag needs to point directly to it:</para>
+
+            <programlisting>&gt;docker run -it --rm -v /var/run/openvswitch/vhost-user1 el7guest /bin/bash</programlisting>
+          </listitem>
+        </itemizedlist>
+      </section>
+
+      <section id="attach-hugepages-mount-folders">
+        <title>Attach hugepages mount folders</title>
+
+        <para>Hugepages mount folders can also be accessed by a container
+        similarly to how a plain folder is mapped, as shown in 1.3.</para>
+
+        <para>For example, if the host system has hugepages mounted in the
+        <literal>/mnt/huge</literal> location, a container can also access
+        hugepages by being launched with:</para>
+
+        <programlisting>&gt;docker run -it -v /mnt/huge el7guest /bin/bash</programlisting>
+      </section>
+
+      <section id="access-pci-bus">
+        <title>Access the PCI bus</title>
+
+        <para>If the host machine has multiple SRIOV instances created, a
+        container can access the instances by being given privileged access to
+        the host system. Unlike folders, PCI devices do not have to be mounted
+        explicitly in order to be accessed and will be available to the
+        container if the <literal>--privileged</literal> flag is passed to the
+        command line:</para>
+
+        <programlisting>&gt;docker run --privileged -it el7guest /bin/bash</programlisting>
+      </section>
+    </section>
+  </section>
 </chapter>
\ No newline at end of file
diff --git a/doc/book-enea-nfv-access-platform-guide/doc/getting_started.xml b/doc/book-enea-nfv-access-platform-guide/doc/getting_started.xml
index b534e20..aa0dcb5 100644
--- a/doc/book-enea-nfv-access-platform-guide/doc/getting_started.xml
+++ b/doc/book-enea-nfv-access-platform-guide/doc/getting_started.xml
@@ -120,8 +120,218 @@
   </section>
 
   <section id="prebuilt-artifacts">
-    <title>How to use Prebuilt Artifacts</title>
+    <title>How to use the Prebuilt Artifacts</title>
 
-    <para></para>
+    <section id="boot-ramdisk">
+      <title>Booting Enea NFV Access Platform using RAMDISK</title>
+
+      <para>There may be use cases, especially at first target ramp-up, where
+      the HDD/SDD has no partitions and you need to prepare the disks for
+      boot. Booting from ramdisk can help with this task.</para>
+
+      <para>The prerequisites needed to proceed:</para>
+
+      <itemizedlist>
+        <listitem>
+          <para>Enea Linux ext4 rootfs image -
+          enea-image-virtualization-host-inteld1521.ext4</para>
+        </listitem>
+
+        <listitem>
+          <para>Enea Linux kernel image - bzImage</para>
+        </listitem>
+
+        <listitem>
+          <para>BIOS has PXE boot enabled</para>
+        </listitem>
+
+        <listitem>
+          <para>PXE/tftp server configured and connected (ethernet) to
+          target.</para>
+        </listitem>
+      </itemizedlist>
+
+      <para>Copy bzImage and enea-image-virtualization-host-inteld1521.ext4.gz
+      images to the tftpserver configured for PXE boot.</para>
+
+      <para>Use the following as an example for the PXE configuration
+      file:</para>
+
+      <programlisting>default vesamenu.c32
+prompt 1
+timeout 0
+
+label el_ramfs
+    menu label ^EneaLinux_RAMfs
+    kernel bzImage
+    append root=/dev/ram0 initrd=enea-image-virtualization-host-inteld1521.ext4 /
+    ramdisk_size=1200000 console=ttyS0,115200 eralyprintk=ttyS0,115200</programlisting>
+
+      <para>Restart the target. Then enter (F11) in the Boot Menu and select
+      the Ethernet interface used for PXE boot. From the PXE Boot Menu select
+      <emphasis role="bold">Enea Linux_RAMfs</emphasis>. Once the Enea NFV
+      Access Platform is started you can partition the HDD/SDD and install
+      GRUB as described in in the following section.s</para>
+    </section>
+
+    <section id="install-grub">
+      <title>Partitioning a new harddisk and installing GRUB</title>
+
+      <para>The prerequisites needed:</para>
+
+      <itemizedlist>
+        <listitem>
+          <para>grub (<literal>grub-efi-bootx64.efi</literal>) - availalble as
+          a pre-built artifact under
+          <literal>inteld1521/images/enea-image-virtualization-host</literal>.</para>
+        </listitem>
+
+        <listitem>
+          <para><literal>e2fsprogs-mke2fs_1.43.4-r0.0_amd64.deb,
+          dosfstools_4.1-r0.0_amd64.deb</literal> - available under
+          <literal>inteld1521/deb</literal>.</para>
+        </listitem>
+      </itemizedlist>
+
+      <para>Proceed using the following steps:</para>
+
+      <orderedlist>
+        <listitem>
+          <para>Boot target with Enea NFV Access Platform from RAMDISK</para>
+        </listitem>
+
+        <listitem>
+          <para>Install prerequisite packages:</para>
+
+          <programlisting>&gt; dpkg -i e2fsprogs-mke2fs_1.43.4-r0.0_amd64.deb
+&gt; dpkg -i dosfstools_4.1-r0.0_amd64.deb</programlisting>
+        </listitem>
+
+        <listitem>
+          <para>Partition the disk:</para>
+
+          <programlisting>&gt; fdisk /dev/sda
+fdisk&gt; g   {GPT partition type}
+fdisk&gt; n
+fdisk&gt; 1
+fdisk&gt;     {default start part}
+fdisk&gt; +512M
+fdisk&gt; t
+fdisk&gt; 1 {ESP/EFI partition}
+fdisk&gt; n
+fdisk&gt; 2
+fdisk&gt;    {default start part}
+fdisk&gt; +18G
+fdisk&gt; 3
+fdisk&gt;    {default start part}
+fdisk&gt; +20G
+...
+fdisk&gt; 7
+fdisk&gt;  {default start part}
+fdisk&gt;  {default end end part}
+
+fdisk&gt; p  {print partion table}
+fdisk&gt; w   {write to disk}
+fdisk&gt; q</programlisting>
+        </listitem>
+
+        <listitem>
+          <para>Format the partitions:</para>
+
+          <programlisting>&gt; mkfs.fat -F32 -nEFI /dev/sda1
+&gt; mkfs.ext4 -LROOT /dev/sda2
+&gt; mkfs.ext4 -LROOT /dev/sda3
+&gt; mkfs.ext4 -LROOT /dev/sda4
+&gt; mkfs.ext4 -LROOT /dev/sda5
+&gt; mkfs.ext4 -LROOT /dev/sda6
+&gt; mkfs.ext4 -LROOT /dev/sda7</programlisting>
+        </listitem>
+
+        <listitem>
+          <para>Create a GRUB partition:</para>
+
+          <programlisting>&gt; mkdir /mnt/boot
+&gt; mount /dev/sda1 /mnt/boot
+&gt; mkdir -p /mnt/boot/EFI/boot
+
+&gt; cp grub-efi-bootx64.efi /mnt/boot/EFI/boot/bootx64.efi
+&gt; vi /mnt/boot/EFI/boot/grub.cfg
+default=1
+
+menuentry "Linux Reference Image" {
+  linux (hd0,gpt2)/boot/bzImage root=/dev/sda2 ip=dhcp
+}
+
+menuentry "Linux sda3" {
+  linux (hd0,gpt3)/boot/bzImage root=/dev/sda3 ip=dhcp
+}
+
+menuentry "Linux sda4" {
+  linux (hd0,gpt4)/boot/bzImage root=/dev/sda4 ip=dhcp
+}
+
+menuentry "Linux sda5" {
+  linux (hd0,gpt5)/boot/bzImage root=/dev/sda5 ip=dhcp
+}
+
+menuentry "Linux sda6" {
+  linux (hd0,gpt6)/boot/bzImage root=/dev/sda6 ip=dhcp
+}
+
+menuentry "Linux sda7" {
+  linux (hd0,gpt7)/boot/bzImage root=/dev/sda7 ip=dhcp
+}</programlisting>
+        </listitem>
+      </orderedlist>
+    </section>
+
+    <section id="boot-hdd">
+      <title>Installing and booting Enea NFV Access Platform on the
+      harddisk</title>
+
+      <para>After partitioning the harddisk, boot Enea NFV Access Platform
+      from RAMFS or from a reference image installed on one of the
+      partitions.</para>
+
+      <para>To install Enea Linux image on a partition follow these
+      steps:</para>
+
+      <orderedlist>
+        <listitem>
+          <para>Copy your platform image on target:</para>
+
+          <programlisting>server&gt; scp ./enea-image-virtualization-host-inteld1521.tar.gz /
+root@&lt;target_ip&gt;:/home/root/</programlisting>
+        </listitem>
+
+        <listitem>
+          <para>Extract image onto the desired partition:</para>
+
+          <programlisting>target&gt; mount /dev/sda3 /mnt/sda
+target&gt; tar -pzxf /home/root/enea-image-virtualization-host-inteld1521.tar.gz /
+-C /mnt/sda</programlisting>
+
+          <para>Alternately, you can do both steps in one command from the
+          server:</para>
+
+          <programlisting>server&gt; cat ./enea-image-virtualization-host-inteld1521.tar.gz | /
+ssh root@&lt;target_ip&gt; "cd /mnt/sda6; tar -zxf -"</programlisting>
+        </listitem>
+
+        <listitem>
+          <para>Reboot</para>
+        </listitem>
+
+        <listitem>
+          <para>From the GRUB menu select your partition</para>
+        </listitem>
+      </orderedlist>
+
+      <note>
+        <para>In order to change kernel boot parameters you need to mount the
+        GRUB partition (i.e. <literal>/dev/sda1</literal>) and change the
+        <literal>EFI/boot/grub.cfg</literal> file.</para>
+      </note>
+    </section>
   </section>
 </chapter>
\ No newline at end of file
diff --git a/doc/book-enea-nfv-access-platform-guide/doc/hypervisor_virtualization.xml b/doc/book-enea-nfv-access-platform-guide/doc/hypervisor_virtualization.xml
index 092b52f..6242de4 100644
--- a/doc/book-enea-nfv-access-platform-guide/doc/hypervisor_virtualization.xml
+++ b/doc/book-enea-nfv-access-platform-guide/doc/hypervisor_virtualization.xml
@@ -324,5 +324,418 @@ $ testpmd -c 0x7 -- -i --rxq=2 --txq=2 --nb-cores=2 ...</programlisting>
         </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;bzImage&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-image-virtualization-guest-qemux86-64.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-x86.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=ttyS0,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 cpuset 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 example-net.xml, it is started as
+      follows:</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>Guest configuration file (xml) must be updated to access newly
+      created network like so:</para>
+
+      <programlisting>    &lt;interface type='network'&gt;
+      &lt;source network='sriov'/&gt;
+    &lt;/interface&gt;</programlisting>
+
+      <para>The following presented here are a few modes of network access
+      from guest using virsh:</para>
+
+      <itemizedlist>
+        <listitem>
+          <para><emphasis role="bold">vhost-user interface</emphasis></para>
+
+          <para>See Openvswitch chapter on how to create vhost-user interface
+          using OpenVSwitch. Currently there is no Open vSwitch support for
+          networks that are managed by libvirt (e.g. NAT). As of now, only
+          bridged networks are supported (those where the user has to manually
+          create the bridge).</para>
+
+          <programlisting>    &lt;interface type='vhostuser'&gt;
+      &lt;mac address='00:00:00:00:00:01'/&gt;
+      &lt;source type='unix' path='/var/run/openvswitch/vhost-user1' mode='client'/&gt;
+       &lt;model type='virtio'/&gt;
+      &lt;driver queues='1'&gt;
+        &lt;host mrg_rxbuf='off'/&gt;
+      &lt;/driver&gt;
+    &lt;/interface&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 an Intel system for PCI passthrough is done like
+          so:</para>
+
+          <itemizedlist>
+            <listitem>
+              <para>Enable the Intel VT-d extensions in BIOS</para>
+            </listitem>
+
+            <listitem>
+              <para>Activate Intel VT-d in the kernel by using
+              <literal>intel_iommu=on</literal> as a kernel boot
+              parameter</para>
+            </listitem>
+
+            <listitem>
+              <para>Allow unsafe interrupts in case the system doesn't support
+              interrupt remapping. This can be done using
+              <literal>vfio_iommu_type1.allow_unsafe_interrupts=1</literal> as
+              a boot kernel parameter.</para>
+            </listitem>
+          </itemizedlist>
+
+          <para>VFs must be created on the host before starting the
+          guest:</para>
+
+          <programlisting>$ echo 2 &gt; /sys/class/net/eno3/device/sriov_numvfs
+$ modprobe vfio_pci
+$ dpdk-devbind.py --bind=vfio-pci 0000:03:10.0
+   &lt;interface type='hostdev' managed='yes'&gt;
+     &lt;source&gt;
+       &lt;address type='pci' domain='0x0' bus='0x03' slot='0x10' function='0x0'/&gt;
+     &lt;/source&gt;
+     &lt;mac address='52:54:00:6d:90:02'/&gt;
+   &lt;/interface&gt;</programlisting>
+        </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;virtualport type='openvswitch'/&gt;
+      &lt;address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/&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>
+
+      <section id="guest-config-vhost-user-interface">
+        <title>Guest configuration with vhost-user interface</title>
+
+        <programlisting>&lt;domain type='kvm'&gt;
+  &lt;name&gt;vm_vhost&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='pc'&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-image-virtualization-guest-qemux86-64.ext4'/&gt;
+      &lt;target dev='vda' bus='virtio'/&gt;
+    &lt;/disk&gt;
+    &lt;interface type='vhostuser'&gt;
+      &lt;mac address='00:00:00:00:00:01'/&gt;
+      &lt;source type='unix' path='/var/run/openvswitch/vhost-user1' mode='client'/&gt;
+       &lt;model type='virtio'/&gt;
+      &lt;driver queues='1'&gt;
+        &lt;host mrg_rxbuf='off'/&gt;
+      &lt;/driver&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>
+      </section>
+
+      <section id="guest-config-pci-passthrough">
+        <title>Guest configuration with PCI passthrough</title>
+
+        <programlisting>&lt;domain type='kvm'&gt;
+  &lt;name&gt;vm_sriov1&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&gt;2&lt;/vcpu&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='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;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-image-virtualization-guest-qemux86-64.ext4'/&gt;
+      &lt;target dev='vda' bus='virtio'/&gt;
+    &lt;/disk&gt;
+   &lt;interface type='hostdev' managed='yes'&gt;
+     &lt;source&gt;
+       &lt;address type='pci' domain='0x0' bus='0x03' slot='0x10' function='0x0'/&gt;
+     &lt;/source&gt;
+     &lt;mac address='52:54:00:6d:90:02'/&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>
+      </section>
+
+      <section id="guest-config-bridge-interface">
+        <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-image-virtualization-guest-qemux86-64.ext4'/&gt;
+      &lt;target dev='vda' bus='virtio'/&gt;
+    &lt;/disk&gt;
+    &lt;interface type='bridge'&gt;
+      &lt;mac address='52:54:00:71:b1:b6'/&gt;
+      &lt;source bridge='ovsbr0'/&gt;
+      &lt;virtualport type='openvswitch'/&gt;
+      &lt;address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/&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>
+      </section>
+    </section>
   </section>
 </chapter>
\ No newline at end of file