diff options
Diffstat (limited to 'documentation/content/en/books/handbook/virtualization/_index.adoc')
| -rw-r--r-- | documentation/content/en/books/handbook/virtualization/_index.adoc | 78 |
1 files changed, 39 insertions, 39 deletions
diff --git a/documentation/content/en/books/handbook/virtualization/_index.adoc b/documentation/content/en/books/handbook/virtualization/_index.adoc index aa264bc80d..bd9dc39007 100644 --- a/documentation/content/en/books/handbook/virtualization/_index.adoc +++ b/documentation/content/en/books/handbook/virtualization/_index.adoc @@ -55,7 +55,7 @@ endif::[] Virtualization software allows multiple operating systems to run simultaneously on the same computer. Such software systems for PCs often involve a host operating system which runs the virtualization software and supports any number of guest operating systems. -After reading this chapter, you will know: +Read this chapter to learn: * The difference between a host operating system and a guest operating system. * How to install FreeBSD on the following virtualization platforms: @@ -66,7 +66,7 @@ After reading this chapter, you will know: ** bhyve(FreeBSD) * How to tune a FreeBSD system for best performance under virtualization. -Before reading this chapter, you should: +Before reading this chapter: * Understand the crossref:basics[basics,basics of UNIX(R) and FreeBSD]. * Know how to crossref:bsdinstall[bsdinstall,install FreeBSD]. @@ -424,7 +424,7 @@ All users that need access to VirtualBox(TM) will have to be added as members of [source,shell] .... -# pw groupmod vboxusers -m yourusername +# pw groupmod vboxusers -m username .... The default permissions for [.filename]#/dev/vboxnetctl# are restrictive and need to be changed for bridged networking: @@ -463,7 +463,7 @@ For VirtualBox(TM) to be aware of USB devices attached to the machine, the user [source,shell] .... -# pw groupmod operator -m yourusername +# pw groupmod operator -m username .... Then, add the following to [.filename]#/etc/devfs.rules#, or create this file if it does not exist yet: @@ -747,7 +747,7 @@ After a successful installation, QEMU will boot the operating system installed o [NOTE] ==== QEMU supports a ```-runas``` option. -For added security, include the option "-runas your_user_name" in the script listing above. +For added security, include the option "-runas user_name" in the script listing above. See man:qemu[1] for details. ==== @@ -1170,7 +1170,7 @@ image::qemu-freebsd16.png[] Reboot the system, and before FreeBSD starts up, switch to the monitor and enter `stop`. The VM will stop. -Enter `loadvm` with the tag you used above (here `original_install`). +Enter `loadvm` with the tag used above (here `original_install`). [source, shell] .... @@ -1413,7 +1413,7 @@ Now the guest can be started from the virtual disk: [[virtualization-bhyve-linux]] === Creating a Linux(R) Guest -Linux guests can be booted either like any other regular crossref:virtualization[virtualization-bhyve-uefi,"UEFI-based guest"] virtual machine, or alternatively, you can make use of the package:sysutils/grub2-bhyve[] port. +Linux guests can be booted either like any other regular crossref:virtualization[virtualization-bhyve-uefi,"UEFI-based guest"] virtual machine, or alternatively, use the package:sysutils/grub2-bhyve[] port. To do this, first ensure that the port is installed, then create a file to use as the virtual disk for the guest machine: @@ -1503,9 +1503,9 @@ Boot the virtual machine: -s 3:0,virtio-blk,./linux.img -l com1,stdio -c 4 -m 1024M linuxguest .... -Linux(R) will now boot in the virtual machine and eventually present you with the login prompt. +Linux(R) will now boot in the virtual machine and eventually presents the login prompt. Login and use the virtual machine. -When you are finished, reboot the virtual machine to exit bhyve. +When finished, reboot the virtual machine to exit bhyve. Destroy the virtual machine instance: [source,shell] @@ -1522,7 +1522,7 @@ This option may support guest operating systems that are not supported by the ot To make use of the UEFI support in bhyve, first obtain the UEFI firmware images. This can be done by installing package:sysutils/bhyve-firmware[] port or package. -With the firmware in place, add the flags `-l bootrom,_/path/to/firmware_` to your bhyve command line. +With the firmware in place, add the flags `-l bootrom,_/path/to/firmware_` to the bhyve command line. The actual bhyve command may look like this: [source,shell] @@ -1534,7 +1534,7 @@ The actual bhyve command may look like this: guest .... -To allow a guest to store UEFI variables, you can use a variables file appended to the `-l` flag. +To allow a guest to store UEFI variables, use a variables file appended to the `-l` flag. Note that bhyve will write guest modifications to the given variables file. Therefore, be sure to first create a per-guest-copy of the variables template file: @@ -1543,7 +1543,7 @@ Therefore, be sure to first create a per-guest-copy of the variables template fi # cp /usr/local/share/uefi-firmware/BHYVE_UEFI_VARS.fd /path/to/vm-image/BHYVE_UEFI_VARS.fd .... -Then, add that variables file into your bhyve arguments: +Then, add that variables file to the bhyve arguments: [source,shell] .... @@ -1641,7 +1641,7 @@ A detailed description for this process can be found on the link:https://wiki.fr [WARNING] ==== Modifying Windows installation media and running Windows guests without a TPM module are unsupported by the manufacturer. -Consider your application and use case before implementing such approaches. +Consider the application and use case before implementing such approaches. ==== [[virtualization-bhyve-zfs]] @@ -1664,7 +1664,7 @@ When starting the VM, specify the ZFS volume as the disk drive: -l com1,stdio -c 4 -m 1024M linuxguest .... -If you are using ZFS for the host as well as inside a guest, keep in mind the competing memory pressure of both systems caching the virtual machine's contents. +When using ZFS for the host as well as inside a guest, keep in mind the competing memory pressure of both systems caching the virtual machine's contents. To alleviate this, consider setting the host's ZFS filesystems to use metadata-only cache. To do this, apply the following settings to ZFS filesystems on the host, replacing `<name>` with the name of the specific zvol dataset name of the virtual machine. @@ -1762,7 +1762,7 @@ To verify successful activation of the snapshot feature, enter and check if the output lists a `--suspend` flag. If the flag is missing, the feature did not activate correctly. -Then, you can snapshot and suspend a running virtual machine of your choice: +Then, snapshot and suspend a running virtual machine of choice: [source,shell] .... @@ -1877,7 +1877,7 @@ add path 'tap10*' unhide [NOTE] ==== -If there's another devfs rule with the numeric ID 100 in your [.filename]#/etc/devfs.rules# file, replace the one in the listing with another yet unused ID number. +If there's another devfs rule with the numeric ID 100 in the [.filename]#/etc/devfs.rules# file, replace the one in the listing with another yet unused ID number. ==== [NOTE] @@ -1907,8 +1907,8 @@ Those rules can be expanded and varied with different guest and interface names [NOTE] ==== -If you intend to use bhyve on the host as well as in a one or more jails, remember that [.filename]#tap# and [.filename]#nmdm# interface names will operate in a shared environment. -For example, you can use [.filename]#/dev/nmdmbhyve0# only either for bhyve on the host or in a jail. +When intending to use bhyve on the host as well as in a one or more jails, remember that [.filename]#tap# and [.filename]#nmdm# interface names will operate in a shared environment. +For example, use [.filename]#/dev/nmdmbhyve0# only either for bhyve on the host or in a jail. ==== Restart devfs for the changes to be loaded: @@ -1918,8 +1918,8 @@ Restart devfs for the changes to be loaded: # service devfs restart .... -Then add a definition for your new jail into [.filename]#/etc/jail.conf# or [.filename]#/etc/jail.conf.d#. -Replace the interface number [.filename]#$if# and IP address with your personal variations. +Then add a definition for the new jail into [.filename]#/etc/jail.conf# or [.filename]#/etc/jail.conf.d#. +Replace the interface number [.filename]#$if# and IP address with personal variations. .Using NAT or routed traffic with a firewall [example] @@ -1937,7 +1937,7 @@ bhyve { exec.clean; - host.hostname = "your-hostname-here"; + host.hostname = "the-hostname-here"; vnet; vnet.interface = "jail${if}"; path = "/jails/${name}"; @@ -1955,7 +1955,7 @@ bhyve { } .... -This example assumes use of a firewall like `pf` or `ipfw` to NAT your jail traffic. +This example assumes use of a firewall like `pf` or `ipfw` to NAT the jail traffic. See the crossref:firewalls[,Firewalls] chapter for more details on the available options to implement this. ==== .Using a bridged network connection @@ -1974,7 +1974,7 @@ bhyve { exec.clean; - host.hostname = "your-hostname-here"; + host.hostname = "the-hostname-here"; vnet; vnet.interface = "jail${if}"; path = "/jails/${name}"; @@ -1995,7 +1995,7 @@ bhyve { [NOTE] ==== -If you previously replaced the devfs ruleset ID 100 in [.filename]#/etc/devfs.rules# with your own unique number, remember to replace the numeric ID also in your [.filename]#jails.conf# too. +Having previously replaced the devfs ruleset ID 100 in [.filename]#/etc/devfs.rules# with a custom unique number, remember to replace the numeric ID also in the [.filename]#jails.conf# too. ==== [[virtualization-bhyve-jailed-config]] @@ -2023,7 +2023,7 @@ Restart and enable the jail: # service jail restart bhyve .... -Afterwards, you can create a virtual machine within the jail. +Afterwards, create a virtual machine within the jail. For a FreeBSD guest, download an installation ISO first: [source,shell] @@ -2052,7 +2052,7 @@ Skipping this step may cause the following error message when starting `bhyve`: `vm_open: vm-name could not be opened. No such file or directory` ==== -Finally, use your preferred way of starting the guest. +Finally, use the preferred way of starting the guest. .Starting with `vmrun.sh` and ZFS [example] @@ -2083,7 +2083,7 @@ Using `vmrun.sh` on a UFS filesystem: .Starting bhyve for an UEFI guest with ZFS [example] ==== -If instead you want to use an UEFI guest, remember to first install the required firmware package package:sysutils/bhyve-firmware[] in the jail: +When wanting to use an UEFI guest, remember to first install the required firmware package package:sysutils/bhyve-firmware[] in the jail: [source,shell] .... @@ -2106,7 +2106,7 @@ Then use `bhyve` directly: bhyvevm0 .... -This will allow you to connect to your virtual machine `bhyvevm0` through VNC as well as a serial console at [.filename]#/dev/nmdbbhyve0B#. +This allows connecting to the virtual machine `bhyvevm0` through VNC as well as a serial console at [.filename]#/dev/nmdbbhyve0B#. ==== [[virtualization-bhyve-nmdm]] @@ -2139,7 +2139,7 @@ For security reasons, it's therefore recommended to logout before disconnecting. The number in the [.filename]#nmdm# device path must be unique for each virtual machine and must not be used by any other processes before bhyve starts. The number can be chosen arbitrarily and does not need to be taken from a consecutive sequence of numbers. The device node pair (i.e. [.filename]#/dev/nmdm0a# and [.filename]#/dev/nmdm0b#) are created dynamically when bhyve connects its console and destroyed when it shuts down. -Keep this in mind when creating scripts to start your virtual machines: you need to make sure that all virtual machines are assigned unique [.filename]#nmdm# devices. +Keep this in mind when creating scripts to start the virtual machines: make sure that all virtual machines are assigned unique [.filename]#nmdm# devices. [[virtualization-bhyve-managing]] === Managing Virtual Machines @@ -2225,7 +2225,7 @@ In order to configure the system to start bhyve guests at boot time, some config [.procedure] . [.filename]#/etc/sysctl.conf# + -When using [.filename]#tap# interfaces as network backend, you either need to manually set each used [.filename]#tap# interface to UP or simply set the following sysctl: +When using [.filename]#tap# interfaces as network backend, either manually set each used [.filename]#tap# interface to UP or simply set the following sysctl: + [.programlisting] .... @@ -2234,9 +2234,9 @@ net.link.tap.up_on_open=1 . [.filename]#/etc/rc.conf# + -To connect your virtual machine's [.filename]#tap# device to the network via a [.filename]#bridge#, you need to persist the device settings in [.filename]#/etc/rc.conf#. -Additionally, you can load the necessary kernel modules `vmm` for bhyve and `nmdm` for [.filename]#nmdm# devices through the `kld_list` configuration variable. -When configuring `ifconfig_bridge0`, make sure to replace `<ipaddr>/<netmask>` with the actual IP address of your physical interface ([.filename]#igb0# in this example) and remove IP settings from your physical device. +To connect the virtual machine's [.filename]#tap# device to the network via a [.filename]#bridge#, persisting the device settings in [.filename]#/etc/rc.conf# is needed. +Additionally, load the necessary kernel modules `vmm` for bhyve and `nmdm` for [.filename]#nmdm# devices through the `kld_list` configuration variable. +When configuring `ifconfig_bridge0`, make sure to replace `<ipaddr>/<netmask>` with the actual IP address of the physical interface ([.filename]#igb0# in this example) and remove IP settings from the physical device. + [source,shell] .... @@ -2250,7 +2250,7 @@ When configuring `ifconfig_bridge0`, make sure to replace `<ipaddr>/<netmask>` w .Setting the IP for a bridge device [example] ==== -For a host with an _igb0_ interface connected to the network with IP `10.10.10.1` and netmask `255.255.255.0`, you would use the following commands: +For a host with an _igb0_ interface connected to the network with IP `10.10.10.1` and netmask `255.255.255.0`, use the following commands: [source,shell] .... @@ -2263,7 +2263,7 @@ For a host with an _igb0_ interface connected to the network with IP `10.10.10.1 [WARNING] ==== -Modifying the IP address configuration of a system may lock you out if you are executing these commands while you are connected remotely (i.e. via SSH)! +Modifying the IP address configuration of a system may terminate the current remote connection (e.g., via SSH), causing a lock out. Take precautions to maintain system access or make those modifications while logged in on a local terminal session. ==== @@ -2509,9 +2509,9 @@ This section contains basic information in order to help troubleshoot issues fou ==== Host Boot Troubleshooting Please note that the following troubleshooting tips are intended for Xen(TM) 4.11 or newer. -If you are still using Xen(TM) 4.7 and having issues, consider migrating to a newer version of Xen(TM). +When still using Xen(TM) 4.7 and having issues, consider migrating to a newer version of Xen(TM). -In order to troubleshoot host boot issues, you will likely need a serial cable, or a debug USB cable. +In order to troubleshoot host boot issues, a serial cable or a debug USB cable is needed. Verbose Xen(TM) boot output can be obtained by adding options to the `xen_cmdline` option found in [.filename]#loader.conf#. A couple of relevant debug options are: @@ -2555,6 +2555,6 @@ libxl: debug: libxl_dom.c:988:libxl__load_hvm_firmware_module: Loading BIOS: /us .... If the verbose output does not help diagnose the issue, there are also QEMU and Xen(TM) toolstack logs in [.filename]#/var/log/xen#. -Note that the name of the domain is appended to the log name, so if the domain is named `freebsd` you should find a [.filename]#/var/log/xen/xl-freebsd.log# and likely a [.filename]#/var/log/xen/qemu-dm-freebsd.log#. +Note that the name of the domain is appended to the log name, so if the domain is named `freebsd` find a [.filename]#/var/log/xen/xl-freebsd.log# and likely a [.filename]#/var/log/xen/qemu-dm-freebsd.log#. Both log files can contain useful information for debugging. -If none of this helps solve the issue, please send the description of the issue you are facing and as much information as possible to mailto:freebsd-xen@FreeBSD.org[freebsd-xen@FreeBSD.org] and mailto:xen-devel@lists.xenproject.org[xen-devel@lists.xenproject.org] in order to get help. +If none of this helps solve the issue, please send the description of the issue and as much information as possible to mailto:freebsd-xen@FreeBSD.org[freebsd-xen@FreeBSD.org] and mailto:xen-devel@lists.xenproject.org[xen-devel@lists.xenproject.org] to get help. |