Page MenuHomeFreeBSD
Files F165073934

D10774.id28464.diff
No OneTemporary
Actions

D10774.id28464.diff
View Options

Index: en_US.ISO8859-1/books/handbook/virtualization/chapter.xml
===================================================================
--- en_US.ISO8859-1/books/handbook/virtualization/chapter.xml
+++ en_US.ISO8859-1/books/handbook/virtualization/chapter.xml
@@ -1367,4 +1367,349 @@
</sect2>
-->
</sect1>
+
+ <sect1 xml:id="virtualization-host-xen">
+ <title>&os; as a &xen;-Host</title>
+
+ <para><application>Xen</application> is a GPLv2-licensed type 1
+ hypervisor for &intel; and &arm; architectures. &os; has
+ included &i386; and &amd;&nbsp;64-Bit DomU and Amazon EC2
+ unprivileged domain (virtual machine) support since
+ &os;&nbsp;8.0 and includes Dom0 control domain (host) support in
+ &os;&nbsp;11.0. Support for para-virtualized (PV) domains has
+ been removed from &os;&nbsp;11 in favor of hardware virtualized
+ (HVM) domains.</para>
+
+ <para>Xen is a baremetal hypervisor, which means that it is the
+ first program loaded after the BIOS. A special privileged guest
+ called the Domain-0 (<literal>Dom0</literal> for short) is then
+ started. The Dom0 uses its special privileges to directly
+ access the underlying physical hardware, which makes it such a
+ high performance solution. That way, it is able to use device
+ drivers for accessing the disk controllers and network adapters.
+ The Xen management tools to manage and control the Xen
+ hypervisor are also used by the Dom0. Dom0 provides virtual
+ disks and networking for unprivileged domains, often called
+ <literal>domU</literal>. Xen Dom0 can be compared to the
+ service console of other hypervisor solutions, while the domU
+ perform the role of individual guest VMs.</para>
+
+ <para>Features of &xen; include GPU passthrough from the host
+ running the Dom0 into a DomU guest machine. This requires VT-D
+ capable hardware (in the CPU, chipset, and BIOS) and may not
+ work with all graphics cards or requires extra patches to work.
+ A list of adapters can be found in the <link
+ xlink:href="https://wiki.xenproject.org/wiki/Xen_VGA_Passthrough_Tested_Adapters">Xen
+ Wiki</link>. Note that not all GPUs listed there are
+ supported on &os;. The &xen; hypervisor also supports
+ PCI-passthrough to assign a PCI device (NIC, disk controller,
+ soundcard, etc.) into a domU guest VM with full and direct
+ access to it.</para>
+
+ <para>Xen can migrate VMs between different &xen; servers. When
+ the two xen hosts share the same underlying storage, the
+ migration can be done without having to shut the VM down first.
+ Instead, the migration is performed live while the domU is
+ running and there is no need to restart it or plan a downtime.
+ This is useful in maintenance scenarios or upgrade windows to
+ ensure that the services provided by the domU are still
+ provided. Many more features of Xen are listed on the <link
+ xlink:href="https://wiki.xenproject.org/wiki/Category:Overview">Xen
+ Wiki Overview page</link>. Note that not all features are
+ supported on &os; yet.</para>
+
+ <sect2 xml:id="virtualization-host-xen-requirements">
+ <title>Hardware Requirements for &xen; Dom0</title>
+
+ <para>To run the &xen; hypervisor on a host, certain hardware
+ functionality is required. Hardware virtualized domains
+ require Extended Page Table (<link
+ xlink:href="http://en.wikipedia.org/wiki/Extended_Page_Table">EPT</link>)
+ and Input/Output Memory Management Unit (<link
+ xlink:href="http://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware">IOMMU</link>)
+ support in the host processor.</para>
+ </sect2>
+
+ <sect2 xml:id="virtualization-host-xen-dom0-setup">
+ <title>Xen Dom0 Control Domain Setup</title>
+
+ <para>The <package>emulators/xen</package> metapackage including
+ the <package>emulators/xen-kernel</package> and
+ <package>emulators/xen-tools</package> packages is supported
+ by &os;&nbsp;11 amd64 binary snapshots and equivalent systems
+ built from source. This example will assume VNC output for
+ unprivileged domains which will be accessed from a another
+ system using a tool such as
+ <package>net/tightvnc</package>.</para>
+
+ <para>The <package>emulators/xen</package> metapackage must be
+ installed:</para>
+
+ <screen>&prompt.root; <userinput>pkg install xen</userinput></screen>
+
+ <para>Once the package has been installed successfully, a couple
+ of configuration files need to be edited to prepare the host
+ for the Dom0 integration. An entry to
+ <filename>/etc/sysctl.conf</filename> must be made to disable
+ the limit on how many pages of memory are allowed to be wired
+ at the same time:</para>
+
+ <screen>&prompt.root; <userinput>sysrc -f /etc/sysctl.conf vm.max_wired=-1</userinput></screen>
+
+ <para>Another memory-related setting involves changing
+ <filename>/etc/login.conf</filename> and setting the
+ <literal>memorylocked</literal> option to
+ <literal>unlimited</literal>. Otherwise, creating domU
+ domains may fail with <literal>Cannot allocate
+ memory</literal> errors. After making the change to
+ <filename>/etc/login.conf</filename>, make sure to run
+ <command>cap_mkdb</command>; to update the capability
+ database. See <xref linkend="security-resourcelimits"/> for
+ details.</para>
+
+ <screen>&prompt.root; <userinput>sed -i '' -e 's/memorylocked=64K/memorylocked=unlimited/' /etc/login.conf</userinput>
+&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>
+
+ <para>An entry for the Xen console needs to be added to
+ <filename>/etc/ttys</filename>:</para>
+
+ <screen>&prompt.root; <userinput>echo 'xc0 "/usr/libexec/getty Pc" xterm on secure' >> /etc/ttys</userinput></screen>
+
+ <para>In <filename>/boot/loader.conf</filename>, the Dom0 is
+ specified in terms of which Xen kernel to boot. &xen; also
+ requires some resources like CPU and memory from the host
+ machine to run itself and other domU domains. How much CPU
+ and memory depends on the individual requirements and
+ hardware capabilities. In this example, 8&nbsp;GB of memory
+ and 4 virtual CPUs are made available for the Dom0. The
+ serial console is also activated and logging options are
+ defined.</para>
+
+ <screen>&prompt.root; <userinput>sysrc -f /boot/loader.conf hw.pci.mcfg=0</userinput>
+&prompt.root; <userinput>xen_kernel="/boot/xen"</userinput>
+&prompt.root; <userinput>xen_cmdline="dom0_mem=<replaceable>2048M</replaceable> dom0_max_vcpus=<replaceable>4</replaceable> dom0pvh=1 console=com1,vga com1=115200,8n1 guest_loglvl=all loglvl=all"</userinput></screen>
+
+ <para>Log files that Xen creates for the Dom0 and DomU VMs are
+ being stored in <filename>/var/log/xen</filename>. This
+ directory does not exist by default and must be
+ created.</para>
+
+ <screen>&prompt.root; <userinput>mkdir -p /var/log/xen</userinput></screen>
+
+ <para>Xen provides its own boot menu to activate and
+ de-activate the hypervisor on demand in
+ <filename>/boot/menu.rc.local</filename>:</para>
+
+ <screen>&prompt.root; <userinput>echo "try-include /boot/xen.4th" >> /boot/menu.rc.local</userinput></screen>
+
+ <para>The last step involves activating the
+ <literal>xendriverdomain</literal> and
+ <literal>xencommons</literal> services during system
+ startup:</para>
+
+ <screen>&prompt.root; <userinput>sysrc xendriverdomain_enable=yes</userinput>
+&prompt.root; <userinput>sysrc xencommons_enable=yes</userinput></screen>
+
+ <para>The above settings are enough to start a Dom0-enabled
+ system. However, it lacks network functionality for the
+ domU machines. To fix that, define a bridged interface with
+ the main NIC of the system that the DomU VMs can use to
+ connect to the network. Replace
+ <replaceable>igb0</replaceable> with the network interface
+ name.</para>
+
+ <screen>&prompt.root; <userinput>sysrc autobridge_interfaces=bridge0</userinput>
+&prompt.root; <userinput>sysrc autobridge_bridge0=<replaceable>igb0</replaceable></userinput>
+&prompt.root; <userinput>echo 'ifconfig_bridge0="addm <replaceable>igb0</replaceable> SYNCDHCP"' >> /etc/rc.conf</userinput></screen>
+
+ <para>Now that these changes have been made, it is time to
+ reboot the machine to load the xen kernel and start the
+ Dom0.</para>
+
+ <screen>&prompt.root; <userinput>reboot</userinput></screen>
+
+ <para>After successfully booting the &xen; kernel and logging
+ into the system again, the Xen management tool
+ <command>xl</command> is used to print information about the
+ domains.</para>
+
+ <screen>&prompt.root; <userinput>xl list</userinput>
+Name ID Mem VCPUs State Time(s)
+Domain-0 0 8192 4 r----- 962.0</screen>
+
+ <para>The output confirms that the Dom0 (called
+ <literal>Domain-0</literal>) as the ID <literal>0</literal>
+ and is in the running state. It also has the memory and
+ virtual CPUs available that were defined in
+ <filename>/boot/loader.conf</filename> earlier. More
+ information can be found in the <link
+ xlink:href="https://www.xenproject.org/help/documentation.html">Xen
+ Documentation</link>. Now it is time to create the first
+ domU guest VM.</para>
+ </sect2>
+
+ <sect2 xml:id="virtualization-host-xen-domu-setup">
+ <title>Xen DomU Unprivileged Domain Configuration</title>
+
+ <para>Unprivileged Domains consist of a configuration file and
+ logical or physical hard disks. Hard disks providing the
+ storage to the DomU can be files created by &man.truncate.1;
+ or ZFS volumes, as described in <xref
+ linkend="zfs-zfs-volume"/>. In this example, the latter
+ is used to create a 20&nbsp;GB volume with a &os; ISO image
+ to create a VM with 1&nbsp;GB of RAM and 2 virtual CPUs.
+ First, the ISO installation file is retrieved using
+ &man.fetch.1; and saved locally in a file called
+ <filename>freebsd.iso</filename>.</para>
+
+ <screen>&prompt.root; <userinput>fetch <replaceable>ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.3/FreeBSD-10.3-RELEASE-amd64-bootonly.iso</replaceable> -o <replaceable>freebsd.iso</replaceable></userinput></screen>
+
+ <para>A ZFS volume of 20&nbsp;GB called
+ <filename>xendisk0</filename> is created to serve as the disk
+ space for the VM.</para>
+
+ <screen>&prompt.root; <userinput>zfs create -V20G -o volmode=dev zroot/xendisk0</userinput></screen>
+
+ <para>A new file will hold the definition of the new domU,
+ according to the virtual hardware defined above. Some
+ specific definitions like name, keymap, and VNC connection
+ details are also defined. The following
+ <filename>freebsd.cfg</filename> contains a minimum domU
+ configuration for our example:</para>
+
+ <screen>&prompt.root; <userinput>cat freebsd.cfg</userinput>
+builder = "hvm" <co xml:id="co-xen-builder"/>
+name = "freebsd" <co xml:id="co-xen-name"/>
+memory = 1024 <co xml:id="co-xen-memory"/>
+vcpus = 1 <co xml:id="co-xen-vcpus"/>
+vif = [ 'bridge=bridge0' ] <co xml:id="co-xen-vif"/>
+disk = [
+'/dev/zvol/tank/xendisk0,raw,hda,rw', <co xml:id="co-xen-disk"/>
+'/root/freebsd.iso,raw,hdc:cdrom,r' <co xml:id="co-xen-cdrom"/>
+ ]
+vnc = 1 <co xml:id="co-xen-vnc"/>
+vnclisten = "0.0.0.0"
+serial="pty"
+usbdevice="tablet"</screen>
+
+ <para>The following lines are explained in more detail:</para>
+
+
+
+ <calloutlist>
+ <callout arearefs="co-xen-builder">
+ <para>This defines what kind of virtualization to use. In
+ this case, <literal>hvm</literal> refers to
+ hardware-assisted virtualization or hardware virtual
+ machine. For CPUs that support virtualization with
+ special extension, this means that guest operating systems
+ can run unmodified and very close to physical hardware
+ performance.</para>
+ </callout>
+
+ <callout arearefs="co-xen-name">
+ <para>An arbitrary name can be provided for this domU to
+ distinguish it from others running on the same Dom0. If no
+ name is provided, then the id is used to identify the
+ VM.</para>
+ </callout>
+
+ <callout arearefs="co-xen-memory">
+ <para>The available main memory (in MB) for the VM to use.
+ This amount is subtracted from the Dom0's total available
+ memory and cannot exceed (sum of all VM's memory) that
+ value.</para>
+ </callout>
+
+ <callout arearefs="co-xen-vcpus">
+ <para>The amount of virtual CPUs that the guest machine can
+ use. It must not exceed the total available CPUs for the
+ Dom0 across all virtual machines.</para>
+ </callout>
+
+ <callout arearefs="co-xen-vif">
+ <para>The virtual network adapter to use for this virtual
+ machine. This is the bridge defined earlier connected to
+ the hosts main NIC.</para>
+ </callout>
+
+ <callout arearefs="co-xen-disk">
+ <para>The full path to the disk serving as the VM's storage
+ space. In this case, it is the path to the ZFS volume
+ defined earlier. Options are separated by commas and
+ multiple disk defintions are also separated that
+ way.</para>
+ </callout>
+
+ <callout arearefs="co-xen-cdrom">
+ <para>Defines the boot medium from which the initial
+ operating system is installed. In this example, it is the
+ ISO imaged downloaded earlier. Consult the Xen
+ documentation for other kinds of devices and options to
+ set.</para>
+ </callout>
+
+ <callout arearefs="co-xen-vnc">
+ <para>Defines various options for VNC connectivity to the
+ serial console of the DomU. These are (in order):
+ activating VNC support, defining which IP address range to
+ listen at, the device node for the serial console, and the
+ input method for precise positioning for mouse and other
+ input methods. Additionally, the option
+ <literal>keymap</literal> defines what keymap to use
+ (english by default).</para>
+ </callout>
+ </calloutlist>
+
+ <para>After the file has been created with all the necessary
+ options, the domU can be created by passing it to <command>xl
+ create</command> as a parameter.</para>
+
+ <screen>&prompt.root; <userinput>xl create freebsd.cfg</userinput></screen>
+
+ <note>
+ <para>Each time the Dom0 is restarted, the configuration file
+ needs to be passed to <command>xl create</command> again to
+ re-create the domU. By default, only the Dom0 is created
+ after a reboot, not the individual VMs. The VMs can
+ continue where they left off as they stored the operating
+ system on the virtual disk. The virtual machine
+ configuration can change over time (for example, when adding
+ more memory). The virtual machine configuration files must
+ be properly backed up and kept available to be able to
+ re-create the domU when needed.</para>
+ </note>
+
+ <para>The output of <command>xl list</command> confirms that the
+ domU has been created.</para>
+
+ <screen>&prompt.root; <userinput>xl list</userinput>
+Name ID Mem VCPUs State Time(s)
+Domain-0 0 8192 4 r----- 1653.4
+freebsd 1 1024 1 -b---- 663.9</screen>
+
+ <para>To begin the installation of the base operating system,
+ start the VNC viewer and direct it to the hosts main network
+ interface address (or the one defined in the
+ <literal>vnclisten</literal> line in
+ <filename>freebsd.cfg</filename>. After the operating system
+ has been installed, shut down the domU and disconnect the VNC
+ viewer. Edit <filename>freebsd.cfg</filename> and remove (or
+ comment using the <literal>#</literal> character at the
+ beginning) the line with the <literal>cdrom</literal>
+ definition. To load this new configuration, it is necessary
+ to remove the old domU with <command>xl destroy</command>,
+ passing either the name or the id as the parameter.
+ Afterwards, recreate it using the modified
+ <filename>freebsd.cfg</filename>.</para>
+
+ <screen>&prompt.root; <userinput>xl destroy freebsd</userinput>
+&prompt.root; <userinput>xl create freebsd.cfg</userinput></screen>
+
+ <para>The machine can then be accessed again using the VNC
+ viewer. This time, it will boot from the virtual disk where
+ the operating system has been installed and can be used as a
+ virtual machine.</para>
+ </sect2>
+ </sect1>
</chapter>

File Metadata

Mime Type
text/plain
Expires
Thu, Aug 6, 7:25 PM (16 h, 58 m)
Storage Engine
blob
Storage Format
Raw Data
Storage Handle
36130131
Default Alt Text
D10774.id28464.diff (16 KB)

Event Timeline