The Peer Reviewed Version Of The Numbers Behind Kickstart With Info Graphic

0 views

Skip to first unread message

Message has been deleted

Melva Simons

unread,

Jul 15, 2024, 10:56:17 AM7/15/24

to wattholsproppis

This section describes the XML format used to represent domains, there arevariations on the format based on the kind of domains run and the options usedto launch them. For hypervisor specific details consult the driverdocs

The root element required for all virtual machines is named domain. It hastwo attributes, the type specifies the hypervisor used for running thedomain. The allowed values are driver specific, but include "xen", "kvm","hvf" (since 8.1.0 and QEMU 2.12), "qemu"and "lxc". The second attribute is id which is a unique integer identifierfor the running guest machine. Inactive machines have no id value.

The Peer Reviewed version of the Numbers behind kickstart with info graphic

DOWNLOAD https://psfmi.com/2yLvm6

The content of the name element provides a short name for the virtualmachine. This name should consist only of alphanumeric characters and isrequired to be unique within the scope of a single host. It is often used toform the filename for storing the persistent configuration file.Since 0.0.1

Since 4.4.0, the genid element can be used to add a VirtualMachine Generation ID which exposes a 128-bit, cryptographically random,integer value identifier, referred to as a Globally Unique Identifier (GUID)using the same format as the uuid. The value is used to help notify theguest operating system when the virtual machine is re-executing somethingthat has already executed before, such as:

The libvirt XML parser will accept both a provided GUID value or just in which case a GUID will be generated and saved in the XML. For thetransitions such as above, libvirt will change the GUID before re-executing.

The content of the description element provides a human readabledescription of the virtual machine. This data is not used by libvirt in anyway, it can contain any information the user wants. Since 0.7.2

The metadata node can be used by applications to store custom metadata inthe form of XML nodes/trees. Applications must use custom namespaces on theirXML nodes/trees, with only one top-level element per namespace (if theapplication needs structure, they should have sub-elements to their namespaceelement). Since 0.9.10

Booting via the BIOS is available for hypervisors supporting fullvirtualization. In this case the BIOS has a boot order priority (floppy,harddisk, cdrom, network) determining where to obtain/find the boot image.

The firmware attribute allows management applications to automaticallyfill and elements and possibly enable somefeatures required by selected firmware. Accepted values are bios andefi.The selection process scans for files describing installed firmware images inspecified location and uses the most specific one which fulfills domainrequirements. The locations in order of preference (from generic to mostspecific one) are:

For more information refer to firmware metadata specification as described indocs/interop/firmware.json in QEMU repository. Regular users do not needto bother. Since 5.2.0 (QEMU and KVM only)For VMware guests, this is set to efi when the guest uses UEFI, and it isnot set when using BIOS.Since 5.3.0 (VMware ESX and Workstation/Player)

The content of the type element specifies the type of operating system tobe booted in the virtual machine. hvm indicates that the OS is onedesigned to run on bare metal, so requires full virtualization. linux(badly named!) refers to an OS that supports the Xen 3 hypervisor guest ABI.There are also two optional attributes, arch specifying the CPUarchitecture to virtualization, and machine referring to the machinetype. The Capabilities XML provides details on allowedvalues for these. If arch is omitted then for most hypervisor drivers,the host native arch will be chosen. For the test, ESX and VMWarehypervisor drivers, however, the i686 arch will always be chosen even onan x86_64 host. Since 0.0.1

When using firmware auto-selection there are different features enabled inthe firmwares. The list of features can be used to limit what firmware shouldbe automatically selected for the VM. The list of features can be specifiedusing zero or more feature elements. Libvirt will take into considerationonly the listed features and ignore the rest when selecting the firmware.

enrolled-keys whether the selected nvram template has defaultcertificate enrolled. Firmware with Secure Boot feature but withoutenrolled keys will successfully boot non-signed binaries as well.Valid only for firmwares with Secure Boot feature.

The optional loader tag refers to a firmware blob, which is specified byabsolute path, used to assist the domain creation process. It is used by Xenfully virtualized domains as well as setting the QEMU BIOS file path forQEMU/KVM domains. Xen since 0.1.0, QEMU/KVM since 0.9.12 Then,since 1.2.8 it's possible for the element to have two optionalattributes: readonly (accepted values are yes and no) to reflectthe fact that the image should be writable or read-only. The second attributetype accepts values rom and pflash. It tells the hypervisor wherein the guest memory the file should be mapped. For instance, if the loaderpath points to an UEFI image, type should be pflash. Moreover, somefirmwares may implement the Secure boot feature. Attribute secure can beused to tell the hypervisor that the firmware is capable of Secure Boot feature.It cannot be used to enable or disable the feature itself in the firmware.Since 2.1.0. If the loader is marked as read-only, then with UEFI itis assumed that there will be a writable NVRAM available. In some cases,however, it may be desirable for the loader to run without any NVRAM, discardingany config changes on shutdown. The stateless flag (Since 8.6.0)can be used to control this behaviour, when set to yes NVRAM will neverbe created.

When firmware autoselection is enabled, the format attribute can beused to tell libvirt to only consider firmware builds that are in aspecific format. Supported values are raw and qcow2.Since 9.2.0 (QEMU only)

Some UEFI firmwares may want to use a non-volatile memory to store somevariables. In the host, this is represented as a file and the absolute pathto the file is stored in this element. Moreover, when the domain is startedup libvirt copies so called master NVRAM store file defined in qemu.conf.If needed, the template attribute can be used to per domain override mapof master NVRAM stores from the config file. Note, that for transient domainsif the NVRAM file has been created by libvirt it is left behind and it ismanagement application's responsibility to save and remove file (if needed tobe persistent). Since 1.2.8

Since 8.5.0, it's possible for the element to have type attribute(accepts values file, block and network) in that case the NVRAMstorage is described by a sub-element with the same syntax asdisk's source. See Hard drives, floppy disks, CDROMs.

The dev attribute takes one of the values "fd", "hd", "cdrom" or"network" and is used to specify the next boot device to consider. Theboot element can be repeated multiple times to setup a priority list ofboot devices to try in turn. Multiple devices of the same type are sortedaccording to their targets while preserving the order of buses. Afterdefining the domain, its XML configuration returned by libvirt (throughvirDomainGetXMLDesc) lists devices in the sorted order. Once sorted, thefirst device is marked as bootable. Thus, e.g., a domain configured to bootfrom "hd" with vdb, hda, vda, and hdc disks assigned to it will boot from vda(the sorted list is vda, vdb, hda, hdc). Similar domain with hdc, vda, vdb,and hda disks will boot from hda (sorted disks are: hda, hdc, vda, vdb). Itcan be tricky to configure in the desired way, which is why per-device bootelements (see Hard drives, floppy disks, CDROMs, Network interfaces,and Host device assignment sections below) were introduced and they arethe preferred way providing full control over booting order.The boot element and per-device boot elements are mutually exclusive.Since 0.1.3, per-device boot since 0.8.8

How to populate SMBIOS information visible in the guest. The modeattribute must be specified, and is either "emulate" (let the hypervisorgenerate all values), "host" (copy all of Block 0 and Block 1, except for theUUID, from the host's SMBIOS values; thevirConnectGetSysinfocall can be used to see what values are copied), or "sysinfo" (use the valuesin the SMBIOS System Information element). If not specified, thehypervisor default is used. Since 0.8.7

Up till here the BIOS/UEFI configuration knobs are generic enough to beimplemented by majority (if not all) firmwares out there. However, from now onnot every single setting makes sense to all firmwares. For instance,rebootTimeout doesn't make sense for UEFI, useserial might not be usablewith a BIOS firmware that doesn't produce any output onto serial line, etc.Moreover, firmwares don't usually export their capabilities for libvirt (orusers) to check. And the set of their capabilities can change with every newrelease. Hence users are advised to try the settings they use before relying onthem in production.

Whether or not to enable an interactive boot menu prompt on guest startup.The enable attribute can be either "yes" or "no". If not specified, thehypervisor default is used. Since 0.8.3 Additional attributetimeout takes the number of milliseconds the boot menu should wait untilit times out. Allowed values are numbers in range [0, 65535] inclusive and itis ignored unless enable is set to "yes". Since 1.2.8

This element has attribute useserial with possible values yes orno. It enables or disables Serial Graphics Adapter which allows users tosee BIOS messages on a serial port. Therefore, one needs to have Serial portdefined. Since 0.9.4.The rebootTimeout attribute (since 0.10.2 (QEMU only))controls whether and after how long the guest should start booting again incase the boot fails (according to BIOS). The value is in milliseconds withmaximum of 65535 and special value -1 disables the reboot.

Hypervisors employing paravirtualization do not usually emulate a BIOS, andinstead the host is responsible to kicking off the operating system boot. Thismay use a pseudo-bootloader in the host to provide an interface to choose akernel for the guest. An example is pygrub with Xen. The Bhyve hypervisoralso uses a host bootloader, either bhyveload or grub-bhyve.