10 Guest installation #
A VM Guest consists of an image containing an operating system and data files and a configuration file describing the VM Guest's virtual hardware resources. VM Guests are hosted on and controlled by the VM Host Server. This section provides generalized instructions for installing a VM Guest. For a list of supported VM Guests refer to Chapter 7, Virtualization limits and support.
Virtual machines have few if any requirements above those required to run the operating system. If the operating system has not been optimized for the virtual machine host environment, it can only run on hardware-assisted virtualization computer hardware, in full virtualization mode, and requires specific device drivers to be loaded. The hardware that is presented to the VM Guest depends on the configuration of the host.
You should be aware of any licensing issues related to running a single licensed copy of an operating system on multiple virtual machines. Consult the operating system license agreement for more information.
10.1 GUI-based guest installation #
You can change default values that are applied when creating new virtual machines. For example, to set UEFI as the default firmware type for new virtual machines, select
› from Virtual Machine Manager's main menu, click and set as the firmware default.The
wizard helps you through the steps required to create a virtual machine and install its operating system. To start it, open the Virtual Machine Manager and select › . Alternatively, start YaST and select › .Start the
wizard either from YaST or Virtual Machine Manager.Choose an installation source—either a locally available media or a network installation source. To set up your VM Guest from an existing image, choose
.On a VM Host Server running the Xen hypervisor, you can choose whether to install a paravirtualized or a fully virtualized guest. The respective option is available under
. Depending on this choice, not all installation options may be available.Depending on your choice in the previous step, you need to provide the following data:
Specify the path on the VM Host Server to an ISO image containing the installation data. If it is available as a volume in a libvirt storage pool, you can also select it using Chapter 13, Advanced storage topics.
. For more information, seeAlternatively, choose a physical CD-ROM or DVD inserted in the optical drive of the VM Host Server.
Provide the
pointing to the installation source. Valid URL prefixes are, for example,ftp://
,http://
, andhttps://
.Under
, provide a path to an auto-installation file (AutoYaST or Kickstart, for example) and kernel parameters. Having provided a URL, the operating system should be automatically detected correctly. If this is not the case, deselect and manually select the and .To set up the VM Guest from an existing image, you need to specify the path on the VM Host Server to the image. If it is available as a volume in a libvirt storage pool, you can also select it using Chapter 13, Advanced storage topics.
. For more information, seeThis installation method is suitable to create a virtual machine, manually configure its components, and install its OS later. To adjust the VM to a specific product version, start typing its name—for example,
sles
—and select the desired version when a match appears.
Choose the memory size and number of CPUs for the new virtual machine.
This step is omitted when
is chosen in the first step.Set up a virtual hard disk for the VM Guest. Either create a new disk image or choose an existing one from a storage pool (for more information, see Chapter 13, Advanced storage topics). If you choose to create a disk, a
qcow2
image is created and stored under/var/lib/libvirt/images
by default.Setting up a disk is optional. If you are running a live system directly from CD or DVD, for example, you can omit this step by deactivating
.On the last screen of the wizard, specify the name for the virtual machine. To be offered the possibility to review and make changes to the virtualized hardware selection, activate
. Specify the network device under . When using , the first bridge found on the host is pre-filled. To use a different bridge, manually update the text box with its name.Click
.(Optional) If you kept the defaults in the previous step, the installation starts. If you selected , a VM Guest configuration dialog opens. For more information about configuring VM Guests, see Chapter 14, Configuring virtual machines with Virtual Machine Manager.
When you are done configuring, click
.
The installation starts in a Virtual Machine Manager console window. Some key combinations, such as Ctrl–Alt–F1, are recognized by the VM Host Server but are not passed to the virtual machine. To bypass the VM Host Server, Virtual Machine Manager provides the “sticky key” functionality. Pressing Ctrl, Alt, or Shift three times makes the key sticky, then you can press the remaining keys to pass the combination to the virtual machine.
For example, to pass Ctrl–Alt–F2 to a Linux virtual machine, press Ctrl three times, then press Alt–F2. You can also press Alt three times, then press Ctrl–F2.
The sticky key functionality is available in the Virtual Machine Manager during and after installing a VM Guest.
10.1.1 Configuring the virtual machine for PXE boot #
PXE boot enables your virtual machine to boot from the installation media via the network, instead of from a physical medium or an installation disk image. Refer to Kapitel 17, Vorbereiten der Netzwerk-Boot-Umgebung for more details about setting up a PXE boot environment.
To let your VM boot from a PXE server, follow these steps:
Start the installation wizard as described in Section 10.1, “GUI-based guest installation”.
Select the
method.Proceed to the last step of the wizard and activate
. Confirm with .On the
screen, select .Inspect
and activate the box next to .Under
, activate and confirm with .Start the installation by clicking
. If a PXE server is properly configured, the PXE menu screen appears.
10.2 Installing from the command line with virt-install
#
virt-install
is a command-line tool that helps you
create new virtual machines using the libvirt
library. It is useful if
you cannot use the graphical user interface, or need to automatize the
process of creating virtual machines.
virt-install
is a complex script with a lot of command
line switches. The following are required. For more information, see the
man page of virt-install
(1).
- General options
--name VM_GUEST_NAME
: Specify the name of the new virtual machine. The name must be unique across all guests known to the hypervisor on the same connection. It is used to create and name the guest’s configuration file and you can access the guest with this name fromvirsh
. Alphanumeric and_-.:+
characters are allowed.--memory REQUIRED_MEMORY
: Specify the amount of memory to allocate for the new virtual machine in megabytes.--vcpus NUMBER_OF_CPUS
: Specify the number of virtual CPUs. For best performance, the number of virtual processors should be less than or equal to the number of physical processors.
- Virtualization type
--paravirt
: set up a paravirtualized guest. This is the default if the VM Host Server supports paravirtualization and full virtualization.--hvm
: set up a fully virtualized guest.--virt-type HYPERVISOR
: Specify the hypervisor. Supported values arekvm
orxen
.
- Guest storage
Specify one of
--disk
,--filesystem
or--nodisks
the type of the storage for the new virtual machine. For example,--disk size=10
creates 10 GB disk in the default image location for the hypervisor and uses it for the VM Guest.--filesystem /export/path/on/vmhost
specifies the directory on the VM Host Server to be exported to the guest. And--nodisks
sets up a VM Guest without a local storage (good for Live CDs).- Installation method
Specify the installation method using one of
--location
,--cdrom
,--pxe
,--import
, or--boot
.- Accessing the installation
Use the
--graphics VALUE
option to specify how to access the installation. SUSE Linux Enterprise Server supports the valuesvnc
ornone
.If using VNC,
virt-install
tries to launchvirt-viewer
. If it is not installed or cannot be run, connect to the VM Guest manually with your preferred viewer. To explicitly preventvirt-install
from launching the viewer, use--noautoconsole
. To define a password for accessing the VNC session, use the following syntax:--graphics vnc,password=PASSWORD
.In case you are using
--graphics none
, you can access the VM Guest through operating system supported services, such as SSH or VNC. Refer to the operating system installation manual on how to set up these services in the installation system.- Passing kernel and initrd files
It is possible to directly specify the Kernel and Initrd of the installer, for example, from a network source. To set up a network source, see Abschnitt 16.4, „Manuelles Einrichten eines HTTP-Repositorys“.
To pass additional boot parameters, use the
--extra-args
option. This can be used to specify a network configuration. For details, see Kapitel 7, Boot-Parameter.Example 10.1: Loading kernel and initrd from HTTP server ##
virt-install
--location "http://example.tld/REPOSITORY/DVD1/" \ --extra-args="textmode=1" --name "SLES15" --memory 2048 --virt-type kvm\ --connect qemu:///system --disk size=10 --graphics vnc \ --network network=vnet_nated- Enabling the console
By default, the console is not enabled for new virtual machines installed using
virt-install
. To enable it, use--extra-args="console=ttyS0 textmode=1"
as in the following example:>
virt-install --virt-type kvm --name sles12 --memory 1024 \ --disk /var/lib/libvirt/images/disk1.qcow2 --os-variant sles12 --extra-args="console=ttyS0 textmode=1" --graphics noneAfter the installation finishes, the
/etc/default/grub
file in the VM image is updated with theconsole=ttyS0
option on theGRUB_CMDLINE_LINUX_DEFAULT
line.- Using UEFI Secure Boot
- Note
SUSE supports UEFI Secure Boot on AMD64/Intel 64 KVM guests only. Xen HVM guests support booting with UEFI firmware, but they do not support UEFI Secure Boot.
By default, new virtual machines installed using
virt-install
are configured with a legacy BIOS. They can be configured to use UEFI with--boot firmware=efi
. A firmware that supports UEFI Secure Boot and has Microsoft keys enrolled will be selected. If secure boot is undesirable, the option--boot firmware=efi,firmware.feature0.name=secure-boot,firmware.feature0.enabled=no
can be used to select a UEFI firmware without secure boot support.It is also possible to explicitly specify a UEFI firmware image. See Section 10.3.1, “Advanced UEFI Configuration” for advanced information and examples on using UEFI with virtual machines.
virt-install
command line #The following command line example creates a new SUSE Linux Enterprise 15 SP2 virtual machine with a virtio accelerated disk and network card. It creates a new 10 GB qcow2 disk image as a storage, the source installation media being the host CD-ROM drive. It uses VNC graphics, and it automatically launches the graphical client.
- KVM
>
virt-install --connect qemu:///system --virt-type kvm \ --name sle15sp2 --memory 1024 --disk size=10 --cdrom /dev/cdrom --graphics vnc \ --os-variant sle15sp2- Xen
>
virt-install --connect xen:// --virt-type xen --hvm \ --name sle15sp2 --memory 1024 --disk size=10 --cdrom /dev/cdrom --graphics vnc \ --os-variant sle15sp2
10.3 Advanced guest installation scenarios #
This section provides instructions for operations exceeding the scope of a normal installation, such as manually configuring UEFI firmware, memory ballooning and installing add-on products.
10.3.1 Advanced UEFI Configuration #
The UEFI firmware used by virtual machines is provided by OVMF (Open Virtual Machine Firmware). The qemu-ovmf-x86_64 package contains firmwares for AMD64/Intel 64 VM Guests. Firmwares for AArch64 VM Guests are provided by the qemu-uefi-aarch64 package. Both packages contain several firmwares, each supporting a different set of features and capabilities. The packages also include JSON firmware descriptor files, which describe the features and capabilities of the various firmwares.
libvirt
supports two methods of selecting virtual machine UEFI
firmware: automatic and manual. With automatic selection, libvirt
will
select a firmware based on an optional set of features specified by the
user. If no explicit features are specified, libvirt
will select a
firmware with secure boot enabled and Microsoft keys enrolled. When using
manual selection, the full path of the firmware and any optional settings
must be explicitly specified. Users can reference the JSON descriptor
files to find a firmware that satisfies their requirements.
When using virt-install
, automatic firmware selection
is enabled by specifying the firmware=efi parameter
to the boot option, for example
--boot firmware=efi
. The selection process can be
influenced by requesting the presence or absence of firmware features.
The following example illustrates automatic firmware selection with
UEFI Secure Boot disabled.
>
virt-install --connect qemu:///system --virt-type kvm \
--name sle15sp5 --memory 1024 --disk size=10 --cdrom /dev/cdrom --graphics vnc \
--boot firmware=efi,firmware.feature0.name=secure-boot,firmware.feature0.enabled=no \
--os-variant sle15sp5
To ensure persistent VM Guests use the same firmware and variable
store throughout their lifetime, libvirt
will record automatically
selected firmware in the VM Guest XML configuration. Automatic
firmware selection is a one-time activity. Once firmware has been
selected, it will only change if the VM Guest administrator
explicitly does so using the manual firmware selection method.
The loader and nvram parameters are used for manual firmware selection. loader is required, and nvram defines an optional UEFI variable store. The following example illustrates manual firmware selection with secure boot enabled.
>
virt-install --connect qemu:///system --virt-type kvm \
--name sle15sp5 --memory 1024 --disk size=10 --cdrom /dev/cdrom --graphics vnc \
--boot loader=/usr/share/qemu/ovmf-x86_64-smm-code.bin,loader.readonly=yes,loader.type=pflash,loader.secure=yes,nvram.template=/usr/share/qemu/ovmf-x86_64-smm-vars.bin \
--os-variant sle15sp5
libvirt
cannot modify any characteristics of the UEFI firmwares. For
example, it cannot disable UEFI Secure Boot in a firmware that has
UEFI Secure Boot enabled, even when specifying loader.secure=no.
libvirt
will ensure the specified firmware can satisfy any specified
features. For example, it will reject configuration that disables secure
boot with loader.secure=no, but specifies a
firmware that has UEFI Secure Boot enabled.
The qemu-ovmf-x86_64 package contains several UEFI firmware images. For example, the following subset supports SMM, UEFI Secure Boot, and has either Microsoft, openSUSE, or SUSE UEFI CA keys enrolled:
#
rpm -ql qemu-ovmf-x86_64
[...] /usr/share/qemu/ovmf-x86_64-smm-ms-code.bin /usr/share/qemu/ovmf-x86_64-smm-ms-vars.bin /usr/share/qemu/ovmf-x86_64-smm-opensuse-code.bin /usr/share/qemu/ovmf-x86_64-smm-opensuse-vars.bin /usr/share/qemu/ovmf-x86_64-smm-suse-code.bin /usr/share/qemu/ovmf-x86_64-smm-suse-vars.bin [...]
For the AArch64 architecture, the package is named qemu-uefi-aarch32:
#
rpm -ql qemu-uefi-aarch32
[...] /usr/share/qemu/aavmf-aarch32-code.bin /usr/share/qemu/aavmf-aarch32-vars.bin /usr/share/qemu/firmware /usr/share/qemu/firmware/60-aavmf-aarch32.json /usr/share/qemu/qemu-uefi-aarch32.bin
The *-code.bin
files are the UEFI firmware files.
The *-vars.bin
files are corresponding variable
store images that can be used as a template for a per-VM non-volatile
store. libvirt
copies the specified vars
template
to a per-VM path under /var/lib/libvirt/qemu/nvram/
when first creating the VM. Files without code
or
vars
in the name can be used as a single UEFI image.
They are not as useful since no UEFI variables persist across power
cycles of the VM.
The *-ms*.bin
files contain UEFI CA keys as found
on real hardware. Therefore, they are configured as the default in
libvirt
. Likewise, the *-suse*.bin
files contain
preinstalled SUSE keys. There is also a set of files with no
preinstalled keys.
For more details on OVMF, see http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt.
10.3.2 Memory ballooning with Windows guests #
Memory ballooning is a method to change the amount of memory used by VM Guest at runtime. Both the KVM and Xen hypervisors provide this method, but it needs to be supported by the guest as well.
While openSUSE and SLE-based guests support memory ballooning, Windows guests need the Virtual Machine Driver Pack (VMDP) to provide ballooning. To set the maximum memory greater than the initial memory configured for Windows guests, follow these steps:
Install the Windows guest with the maximum memory equal or less than the initial value.
Install the Virtual Machine Driver Pack in the Windows guest to provide required drivers.
Shut down the Windows guest.
Reset the maximum memory of the Windows guest to the required value.
Start the Windows guest again.
10.3.3 Including add-on products in the installation #
Some operating systems, such as SUSE Linux Enterprise Server, offer to include add-on products in the installation process. If the add-on product installation source is provided via SUSE Customer Center, no special VM Guest configuration is needed. If it is provided via CD/DVD or ISO image, it is necessary to provide the VM Guest installation system with both the standard installation medium image and the image of the add-on product.
If you are using the GUI-based installation, select
in the last step of the wizard and add the add-on product ISO image via › . Specify the path to the image and set the to .
If you are installing from the command line, you need to set up the
virtual CD/DVD drives with the --disk
parameter rather
than with --cdrom
. The device that is specified first
is used for booting. The following example installs SUSE Linux Enterprise Server 15
together with SUSE Enterprise Storage extension:
>
virt-install \
--name sles15+storage \
--memory 2048 --disk size=10 \
--disk /path/to/SLE-15-SP5-Full-ARCH-GM-media1.iso-x86_64-GM-DVD1.iso,device=cdrom \
--disk /path/to/SUSE-Enterprise-Storage-VERSION-DVD-ARCH-Media1.iso,device=cdrom \
--graphics vnc --os-variant sle15