mirror of
https://github.com/libvirt/libvirt.git
synced 2026-10-02 12:20:06 -05:00
Peter Krempa
38c970f641
Historically 'virtio-vga' was always picked as the first '<video>' (virtio) device and any sub-sequent ones were 'virtio-gpu'. When support for aarch64 VMs was being added an exception to use 'virtio-gpu' for the primary device was added as aarch64 doesn't have anything resembling the "legacy" 'VGA' interface. At this point this exception was only for aarch64. The distinction between 'virtio-vga' and 'virtio-gpu' was *not* recorded in the VM XML as it was a new feature (for aarch64) and it didn't make sense to pick 'virtio-vga'. Some time later the following commit: commit4c029e8cfaAuthor: Pavel Hrdina <phrdina@redhat.com> Date: Fri Sep 30 14:41:37 2016 +0200 qemu_command: properly detect which model to use for video device This improves commit706b5b6277in a way that we check qemu capabilities instead of what architecture we are running on to detect whether we can use *virtio-vga* model or not. This is not a case only for arm/aarch64. modified the code to do this picking by checking presence of 'virtio-vga' device instead. That approach didn't consider the fact that the modular deployment of qemu allows for the 'virtio-vga' device to be missing in certain cases, thus introducing a latent bug as we'll pick 'virtio-gpu' in such case but don't record it anywhere. Now this creates a problem, if the deployments differ, because you can have two *incompatible* (at migration stream level) setups which are based on the same identical XML without the possibility for the destination libvirt instance during migration to pick which is the correct one. To prevent this and actually fix any existing such deployment (which allows upgrade of libvirt daemons on the source) we will record the picked device frontend at post-parse time into the XML. This luckily properly handles running VMs even if 'virtio-vga' were already installed since we record the actual qemuCaps we've started the VM with. Now 'virtio-vga' vs 'virtio-gpu' is not the only broken piece of logic. In fact 'virtio-vga-gl' could have been downgraded to 'virtio-vga' based on some very weird logic (see comments in code for explanation). The logic in 'qemuDomainDeviceVideoDefPostParse' re-creates the logic used to setup virtio-vga vs. virtio-gpu, and 'vhost-user-vga' vs. 'vhost-user-gpu' as those still make sense. For the 'gl' variants two versions exist, one meant to recover running VMs and one for new VMs where the broken logic makes no sense. Now this patch just records what was selected into the XML, but doesn't yet modify the commandline to actually use that value verbatim (e.g. if the user specified an actual non-default value already). Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
.. image:: https://gitlab.com/libvirt/libvirt/badges/master/pipeline.svg
:target: https://gitlab.com/libvirt/libvirt/pipelines
:alt: GitLab CI Build Status
.. image:: https://bestpractices.coreinfrastructure.org/projects/355/badge
:target: https://bestpractices.coreinfrastructure.org/projects/355
:alt: CII Best Practices
.. image:: https://translate.fedoraproject.org/widgets/libvirt/-/libvirt/svg-badge.svg
:target: https://translate.fedoraproject.org/engage/libvirt/
:alt: Translation status
==============================
Libvirt API for virtualization
==============================
Libvirt provides a portable, long term stable C API for managing the
virtualization technologies provided by many operating systems. It
includes support for QEMU, KVM, Xen, LXC, bhyve, Virtuozzo, VMware
vCenter and ESX, VMware Desktop, Hyper-V, VirtualBox and the POWER
Hypervisor.
For some of these hypervisors, it provides a stateful management
daemon which runs on the virtualization host allowing access to the
API both by non-privileged local users and remote users.
Layered packages provide bindings of the libvirt C API into other
languages including Python, Perl, PHP, Go, Java, OCaml, as well as
mappings into object systems such as GObject, CIM and SNMP.
Further information about the libvirt project can be found on the
website:
https://libvirt.org
License
=======
The libvirt C API is distributed under the terms of GNU Lesser General
Public License, version 2.1 (or later). Some parts of the code that are
not part of the C library may have the more restrictive GNU General
Public License, version 2.0 (or later). See the files ``COPYING.LESSER``
and ``COPYING`` for full license terms & conditions.
Installation
============
Instructions on building and installing libvirt can be found on the website:
https://libvirt.org/compiling.html
Contributing
============
The libvirt project welcomes contributions in many ways. For most components
the best way to contribute is to send patches to the primary development
mailing list. Further guidance on this can be found on the website:
https://libvirt.org/contribute.html
Contact
=======
The libvirt project has two primary mailing lists:
* users@lists.libvirt.org (**for user discussions**)
* devel@lists.libvirt.org (**for development only**)
Further details on contacting the project are available on the website:
https://libvirt.org/contact.html