roots/wiki
1
0
Fork 0
Code Pull Requests Activity

Various clean-ups, additions

Browse Source 
Refactoring of the home page. Adding a page for virtual machine monitors.
This commit is contained in:
lukas
2024-01-28 17:21:40 +01:00
parent b0827ec21a
commit fb251ea7ef
11 changed files with 165 additions and 106 deletions
Download Patch File Download Diff File Expand all files Collapse all files

179
virt/vm/display.md
View File

@@ -1,179 +0,0 @@
---
title: Display
description: How to access a virtual machine's display
published: true
date: 2023-10-15T15:11:00.161Z
tags:
editor: markdown
dateCreated: 2022-07-31T09:22:05.854Z
---
# Display
A virtual display can be attached to a virtual machine. It is a must-have for non-headless scenarios.
## Display types
### SDL display
The [Simple DirectMedia Layer](https://www.libsdl.org/) (SDL)-powered display is a local-only low-latency display.
> The SDL display is only avalable with virtual machines created using the QEMU/KVM **User Session**.
{.is-info}
> Mouse grab does not currently work with the SDL display
{.is-warning}
> The display resolution of your guest display should not exceed that of your physical screen
{.is-info}
#### SELinux-related configuration
By default, SELinux will block access to X Windows Server for the virtualization stack. An exception has to be set.
* Set new rule
```
sudo setsebool -P virt_use_xserver 1
```
* Do some magic trick
```
sudo ausearch -c 'qemu-system-x86' --raw | audit2allow -M my-qemusystemx86
k
```
* And another one
```
sudo semodule -X 300 -i my-qemusystemx86.pp
```
#### SDL XML configuration
* The default display can be identified using `echo $DISPLAY`.
```
$ echo $DISPLAY
:0
```
The same applies to `xauth`. On Wayland, it would look like that.
```
$ echo $XAUTHORITY
/run/user/1000/.mutter-Xwaylandauth.ARIY51
```
* Example of an XML SDL configuration, with OpenGL enabled. This example requires a 3D-capable graphic card to be attached to the guest computer, such as `virtio-gpu`.
```
<graphics type="sdl" display=":0" xauth="/run/user/1000/.mutter-Xwaylandauth.ARIY51" fullscreen="yes">
<gl enable="yes"/>
</graphics>
```
> The fullscreen attribute is not honored at the moment
{.is-warning}
### D-Bus display
[D-Bus](https://www.freedesktop.org/wiki/Software/dbus/) is a desktop-oriented middleware that can be used to create a display for a virtual machine.
#### Libvirt
* Add a D-Bus video backend and add enable for OpenGL:
```
<graphics type="dbus">
<gl enable="yes"/>
</graphics>
```
> This equates to `-display dbus,gl=on` in QEMU
>
{.is-info}
When the virtual machine is launched, a specific D-Bus address will be choosen, as well as a rendering device:
```
<graphics type="dbus" address="unix:path=/run/user/1000/libvirt/qemu/run/dbus/8-user-d-bus-dbus.sock">
<gl enable="yes" rendernode="/dev/dri/renderD128"/>
</graphics>
```
* Add a D-Bus audio backend:
```
<graphics type="dbus">
<audio id="1">
</graphics>
```
#### Connect to the D-Bus display
A third-party tool is required to interact to the D-Bus display.
[Libmks](https://gitlab.gnome.org/GNOME/libmks), which is under development, is such a tool.
> Due to [a bug](https://gitlab.gnome.org/GNOME/libmks/-/issues/16), it is currenlty only possible to connect a D-Bus display with plain QEMU
{.is-warning}
Libmks has to be built from source.
- Clone the repository
```
git clone https://gitlab.gnome.org/GNOME/libmks
```
- Change directory
```
cd libmks
```
- Build it
```
meson setup build
cd build
ninja
```
- Launch a diskless virtual machine
```
qemu-system-x86_64 \
-enable-kvm \
-machine q35 \
-drive if=pflash,format=raw,readonly=on,file=/usr/share/edk2-ovmf/x64/OVMF_CODE.fd \
-cpu host \
-device virtio-vga-gl \
-m 4G \
-smp 2,sockets=1,dies=1,cores=2,threads=1 \
-display dbus,gl=on \
-device virtio-tablet-pci \
-device virtio-keyboard-pci \
```
- From another terminal tab or window, launch the previously built MKS using the following command
```
./build/tools/mks
```
As there is no Live ISO or disk attached to the virtual machine, you will eventually land in the UEFI shell.
## Resources
* [Detailed presentation](https://bootlin.com/pub/conferences/2016/meetup/dbus/josserand-dbus-meetup.pdf) on D-Bus
* [Official resource](https://libvirt.org/formatdomain.html#graphical-framebuffers) for libvirt-compatible displays, including various XML examples
* [Libmks](https://gitlab.gnome.org/chergert/libmks) provides a "Mouse, Keyboard, and Screen" to QEMU using the D-Bus device support in QEMU and GTK 4.
* [QEMU D-Bus display experiment](https://gitlab.com/marcandre.lureau/qemu-display/) is a WIP Rust crates to interact with a -display dbus QEMU
* [SDL graphics](https://fedoraproject.org/wiki/How_to_debug_Virtualization_problems#SDL_Graphics)
---
*[**Go to parent page**](https://wiki.phyllo.me/)*

27
virt/vm/firmware.md
View File

@@ -10,34 +10,37 @@ dateCreated: 2022-01-25T14:50:10.751Z
# Platform firmware
Virtual devices, including virtual chipsets, are shipping alongside platform firmware.
Virtual devices, including virtual chipsets, are shipping alongside platform firmware.
> ***Definition**: Firmware are software that are tightly integrated with the hardware. Almost every devices are shipping with some kind of firmware associated to it. For instance, motherboards include such programs, which in their case is tasked to properly boot hardware devices such as RAM modules, check their state and make them ready-to-use by an operating system*
{.is-info}
## Available platform firmware for virtual machines
## Common platform firmware for virtual machines
### SeaBIOS
[SeaBIOS](https://www.seabios.org/SeaBIOS) is an implementation of a x86 BIOS which relies on [Coreboot](https://www.coreboot.org/) and can be used to boot virtual machines. It is incompatible with UEFI. It is also simpler.
[SeaBIOS](https://www.seabios.org/SeaBIOS) is an implementation of an x86 BIOS which relies on [coreboot](https://www.coreboot.org/). It is used for legacy systems, but also to specialized and cloud optimized guests systems which don't require UEFI.
### OVMF
[OVMF](https://github.com/tianocore/tianocore.github.io/wiki/OVMF), which stands for Open Virtual Machine Firmware, is a UEFI-compatible firmware. It is based on the larger [TianoCore](https://www.tianocore.org/) project, which provides an open-source implementation of a platform firmware that follows UEFI specifications. It is the default method to boot UEFI-based operating systems in a virtual machine.
[OVMF](https://github.com/tianocore/tianocore.github.io/wiki/OVMF), which stands for Open Virtual Machine Firmware, is a UEFI-compatible firmware.
It is based on the [TianoCore](https://www.tianocore.org/) project, which provides an open-source implementation of a platform firmware that follows UEFI specifications.
It is the default method to boot UEFI-based operating systems in a virtual machine.
### Rust Hypervisor Firmware
The [Rust Hypervisor Firmware](https://github.com/cloud-hypervisor/rust-hypervisor-firmware) (RHF) is a UEFI-compatible firmware. It is focused on simplicity and performance and is designed for virtual workloads. It is tightly integrated with the Cloud Hypervisor.
The [Rust Hypervisor Firmware](https://github.com/cloud-hypervisor/rust-hypervisor-firmware) (RHF) is a UEFI-compatible firmware. It is focused on simplicity and performance and is designed to run cloud-centric operating systems.
## Comparison
It is developed alongside the Cloud Hypervisor.
## Supported features
| | SeaBIOS | OVMF | RHF |
| :-- | :-: | :-: | :-: |
| *BIOS* | **Yes** | No | No |
| *UEFI* | No | **Yes** | **Yes** |
| *Secureboot* | No | **Yes** | **Yes** |
| *Chipset support* | [`i440fx`](/virt/vm/chipset#i440fx) / [`Q35`](/virt/vm/chipset#q35) | [`i440fx`](/virt/vm/chipset#i440fx) / [`Q35`](/virt/vm/chipset#q35) | [`Q35`](/virt/vm/chipset#q35)? / [`virt`](/virt/vm/chipset#virt) |
| *Guest support* | **Linux** / **Windows** | **Linux** / **Darwin** / **Windows** | **Linux** / **Windows** |
| *Secure Boot* | No | **Yes** | ? |
| *Chipset* | [i440fx](/virt/vm/chipset#i440fx), [Q35](/virt/vm/chipset#q35) | [i440f](/virt/vm/chipset#i440fx), [Q35](/virt/vm/chipset#q35) | [virt](/virt/vm/chipset#virt) |
| *Guests* | **Linux**, **Windows** | **Linux**, **Darwin**, **Windows** | **Linux**, **Windows** |
| *Virtual Function I/O (VFIO)* | No | **Yes** | **Yes** |
---

14
virt/vm/graphic-card.md
View File

@@ -10,19 +10,19 @@ dateCreated: 2021-11-13T17:52:22.554Z
# Graphic cards
Phyllome leverages 3D acceleration within guest operating systems extensively, in three different modes depending on the situation.
Phyllome leverages 3D acceleration within guest operating systems extensively, in three different modes depending on the context.
* **vfio-pci** : Passing through a complete physical Graphical Processing Unit (GPU) to the guest via the `vfio-pci` driver
* **vfio-mdev** : Sharing a fraction of a compatible physical GPU such as those using [single-root input/output virtualization](https://en.wikipedia.org/wiki/Single-root_input/output_virtualization) (SR-IOV), via the `vfio-mdev` driver
* **vfio-gpu** : Using some capabilities of the host GPU, via the `vfio-gpu` driver, which creates a virtual GPU as is used in Chromium OS and Spectrum OS
* **vfio-pci** : Passing through a physical Graphical Processing Unit (GPU) to the guest via the `vfio-pci` driver
* **vfio-mdev** : Create multiple vGPUs that can then be passed through to multiple guests. It does require a compatible GPU
* **virtio-gpu** : Expose capabilities of the host GPU to the guest via the `virtio-gpu` driver. Compatible with most GPUs but not many guests
| Description | `vfio-pci` | `vfio-mdev` | `vfio-gpu` |
| Description | vfio-pci | vfio-mdev | vfio-gpu |
|---|---|---|---|
| *Performance* | Near-native performance and full features set | Near-native performance and full features set | Degraded performance and limited features set |
| *Guests support* | UNIX and non-UNIX guests | UNIX and non-UNIX guests | Works only on selected UNIX guests |
| *Driver* | No special driver in the guest | No special driver in the guest | Requires a special driver in the guest |
| *Driver* | No specialized driver in the guest | No specialized driver in the guest | A special driver in the guest is required |
| *Number of host GPUs* | Two GPUs in most situations | A single GPU | A single GPU |
| *GPU support* | Mostly GPU agnostic | Recent Intel integrated GPUs and some professional grade Nvidia GPUs | Mostly GPU agnostic |
| *GPU support* | Mostly GPU agnostic | Recent Intel integrated GPUs and some professional-grade Nvidia GPUs. Some consumer GPUs can be unlocked | Mostly GPU agnostic |
---

6
virt/vm/virtio.md
View File

@@ -21,12 +21,12 @@ In this section, the focus is oriented towards Virtual I/O Devices (VIRTIO), bet
### Graphical frame buffer
* [`virtio-gpu`](/virt/virtio/snd)
* [`virtio-gpu`](/virt/virtio/gpu)
* Paravirtual GPU that provides a subset of the host GPU capabilities to a guest virtual machine
### Video decoding/encoding
* [`virtio-video`](/virt/virtio/snd)
* [`virtio-video`](/virt/virtio/video)
* Paravirtual video device that provides encoding and decoding capabilities to a guest virtual machine
### Sound
@@ -77,7 +77,7 @@ In this section, the focus is oriented towards Virtual I/O Devices (VIRTIO), bet
| *`virtio-wayland`* | No | No | ? |
| *`virtio-console`* | **Yes** | **Yes** | **Yes** |
## Resourcess
## Resources
* Specifications
* [Version 1.0](https://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.html) of the specification for Virtual I/O Devices