This fixes representation of the 'acpi_firmware' config in the Xen
driver, which repesents a concatenation of tables of any type.
Use of 'type=slic' is accepted on input for backwards compatibility.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This allows passing a single ACPI table of any type through to QEMU with
the signture autodetected from the header.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The QEMU driver has only accepted type=slic even though QEMU is able to
accept individual tables of any type, without needing to specify a
signature. Introduce type=raw to address this usage scenario. Contrary
to other types, this one may appear multiple times.
The Xen driver has mistakenly accepted type=slic and use it to set the
Xen acpi_firmware setting, which performs a simple passthrough of
multiple concatenated data table. Introduce type=rawset to address
this usage scenario.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The combination of italics and the since tag does not work together.
Remove it from the paragraph about using passt with vhostuser,
as well as the parentheses around it.
Signed-off-by: Yalan Zhang <yalzhang@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Commit af1b89d1d for some reason changed a perfectly fine statement to
one that I could not understand. Let's revert it.
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Using host CPU definition with hypervisor-cpu-baseline is possible, but
it provide incorrect results and thus it should not be documented the
same way we describe the correct usage. Also using host-model CPU from
domain capabilities was not described clearly enough.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Using host CPU definition with hypervisor-cpu-compare is possible, but
it provide incorrect results and thus it should not be documented the
same way we describe the correct usage. Also using host-model CPU from
domain capabilities was not described clearly enough.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When starting a VM with a vhost-user interface in server mode qemu will
wait for the incoming connection without running CPUs. This isn't really
documented in our XML. Additionally when hotplugging the same interface
the above will not happen.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Note that 'block' backed NVRAM may need to use 'qcow2' images to work
properly and that populating from template may not support format
conversion.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Almost everything is already there (in the section for using passt
with type='user'), so we just need to point to that from the
type='vhostuser' section (and vice versa), and add a bit of glue.
Also updated a few related details that have changed (e.g. default
model type for vhostuser is now 'virtio', and source type/mode are now
optional), and changed "vhost-user interface" to "vhost-user
connection" because the interface is a virtio interface, and
vhost-user is being used to connect that interface to the outside.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add the group membership information to a CCW device. Allow to filter
CCW devices based on a group membership.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The fields are in nanoseconds, not microseconds. Also fixes the
description of `vcpu.<num>.wait`, as it does not actually represent the
time waiting on I/O.
Signed-off-by: Fabricio Duarte <fabricio.duarte.jr@gmail.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Since we supported 'product' parameter for SCSI, just expanded existing
solution makes IDE/SATA parameter works too. QEMU requires parameter 'model'
in case of IDE/SATA (instead of 'product'), so the process of making JSON
object is slightly modified. Length of the 'product' parameter is
different in SCSI (16 chars) and ATA/SATA (40 chars).
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/697
Signed-off-by: Adam Julis <ajulis@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
This feature is implemented as a string that can range from "none",
"aplic" and "aplic-imsic".
If the feature isn't present in the domain XML the hypervisor default
will be used. For QEMU, at least up to 9.2, the default is "none".
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Update domain XML and network XML documentation to describe how
standard linux bridges support the VLAN configuration.
Signed-off-by: Leigh Brown <leigh@solinno.co.uk>
Reviewed-by: Laine Stump <laine@redhat.com>
The host-model CPU mode was described as similar to copying the host CPU
definition from capabilities, which has not been the case for ages. The
host-model definition from domain capabilities is used instead.
Only the first sentence changed, but it required reformatting
essentially the whole paragraph so I used this as an opportunity to
reformat it a little bit more and split the long paragraph into several
smaller ones for better readability.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to stimer-direct these are subelements of <tlbflush/> in the
domain XML.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add a new flag, --disable-deprecated-features, to the domcapabilities
command. This will modify the output to show the 'host-model' CPU
with features flagged as deprecated paired with the 'disable' policy.
virsh domcapabilities --disable-deprecated-features
Signed-off-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
When external swtpm support was added back in 9.0.0, I omitted
the update of the XML docs.
Add it now, especially since the 'emulator' backend can now
also use the <source> element.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Some models are just aliases to other models. Make this relation
available to users via domain capabilities.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The previous example will cause the error like:
error: Options --file and --base64 are mutually exclusive
Reported-by: Yanqiu Zhang <yanqzhan@redhat.com>
Signed-off-by: Han Han <hhan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When a VM is being migrated to a destination host it can be made
persistent on the destination by using '--persistent'. That may not
work as intended if '--xml' is used as well as that allows overriding
certain aspects of the VM xml, but does not involve the persistent
definition. In most cases users will need to supply also
'--persistent-xml' with the same set of modification.
Modify the man page to clarify the above so that users don't end up with
broken VM after migrating and restarting it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When virtio-(non-)transitional models were introduced, the
documentation was updated to include them; at the same time,
language was introduced indicating that using the existing
virtio model is no longer recommended.
This is unnecessarily harsh, and has resulted in people
incorrectly believing (through no fault of their own) that the
virtio model has been deprecated.
In reality, it's perfectly fine to use the virtio model as the
stress-free option that, while often not producing the ideal
PCI topology, will generally get the job done and work reliably
across libvirt versions and machine types.
Tweak the documentation so that it hopefully carries the
desired message across.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Get the JSON profile that the swtpm instance was created with from the
output of 'swtpm socket --tpm2 --print-info 0x20 --tpmstate ...'. Get the
name of the profile from the JSON and set it in the current and persistent
emulator descriptions as 'name' attribute and have the persistent
description stored with this update. The user should avoid setting this
'name' attribute since it is meant to be read-only. The following is
an example of how the XML could look like:
<profile source='local:restricted' name='custom:restricted'/>
If the user provided no profile node, and therefore swtpm_setup picked its
default profile, the XML may now shows the 'name' attribute with the name
of the profile. This makes the 'source' attribute now optional.
<profile name='default-v1'/>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Add documentation for the TPM backend profile node and point the reader to
further documentation about TPM profiles available in the swtpm man page.
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
virtiofs 1.11 contains support for migration so update the 'Note' which
states that migration is not supported.
Additionally mention that VM snapshots don't save state of the files
shared via virtiofs so reverting is not a good idea.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently the qemu firmware code weirdly depends on the 'format' field
of the nvram image itself to do the auto-selection process as well as
then uses it to declare the actual type to qemu.
As it's not technically required that the template and the on disk image
share the type introduce a 'templateFormat' field which will split off
from the shared purpose of the type and will be used for the selection
and instantiation process, while 'format' will be left for the actual
type of the on disk image.
This patch introduces the field, adds XML infrastructure as well as
plumbs it to the firmware bits.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The NVRAM template file may be autoselected same as the loader/firmware
image. Add a hint that this can occur and also that it doesn't
necessarily need to be from the 'qemu.conf' configured files.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When using recent Fedora and RHEL versions, the manual setup that
is otherwise necessary to enable the module can be replaced with
executing a single command.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The page contains some confusing information, especially around
limitations that supposedly only affect one of the two variants,
and goes into what is arguably an unnecessary amount of detail
when it comes to its inner workings.
We can make the page a lot shorter and snappier without
affecting its usefulness, so let's do just that.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
As requested on the libvirt users list I am adding this mention to the
apps page.
Reported-by: Erik Huelsmann <ehuels@gmail.com>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Domain capabilities include information about support for various
devices and models.
Panic devices are not included in the output which means that management
applications need to include the logic for choosing the right device
model or request a default model and try defining such a domain.
Add reporting of panic device models into the domain capabilities based
on the logic in qemuValidateDomainDefPanic() and also report whether
panic devices are supported based on whether at least one model is
supported. That way consumers of the domain capability XML can
differentiate between libvirt not reporting the panic device models or
no model being supported.
Resolves: https://issues.redhat.com/browse/RHEL-65187
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The support for the 'sgio' attribute for SCSI-backed devices was dropped
as there wasn't really ever any upstream support for it.
The docs do state that support for this depends on the hypervisor
itself, but we can be more clear that there is no hypervisor which does
support it.
There is also a suggestion to use 'sgio' instead of 'rawio' as being
more "secure" but since it no longer works drop this suggestion.
Resolves: https://issues.redhat.com/browse/RHEL-65268
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The docs for submitting a patch describe using your "Legal Name" with
the Signed-off-by line.
In recent times, there's been a general push back[1] against the notion
that use of Signed-off-by in a project automatically requires / implies
the use of legal ("real") names and greater awareness of the downsides.
Full discussion of the problems of such policies is beyond the scope of
this commit message, but at a high level they are liable to marginalize,
disadvantage, and potentially result in harm, to contributors.
TL;DR: there are compelling reasons for a person to choose distinct
identities in different contexts & a decision to override that choice
should not be taken lightly.
A number of key projects have responded to the issues raised by making
it clear that a contributor is free to determine the identity used in
SoB lines:
* Linux has clarified[2] that they merely expect use of the
contributor's "known identity", removing the previous explicit
rejection of pseudonyms.
* CNCF has clarified[3] that the real name is simply the identity
the contributor chooses to use in the context of the community
and does not have to be a legal name, nor birth name, nor appear
on any government ID.
Since we have no intention of ever routinely checking any form of ID
documents for contributors[4], realistically we have no way of knowing
anything about the name they are using, except through chance, or
through the contributor volunteering the information. IOW, we almost
certainly already have people using pseudonyms for contributions.
This proposes to accept that reality and eliminate unnecessary friction,
by following Linux & the CNCF in merely asking that a contributors'
commonly known identity, of their choosing, be used with the SoB line.
[1] Raised in many contexts at many times, but a decent overall summary
can be read at https://drewdevault.com/2023/10/31/On-real-names.html
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4563201f33a022fc0353033d9dfeb1606a88330
[3] https://github.com/cncf/foundation/blob/659fd32c86dc/dco-guidelines.md
[4] Excluding the rare GPG key signing parties for regular maintainers
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Daniel P. Berrangé
Yalan Zhang
Cleber Rosa
Peter Krempa
Martin Kletzander
Ján Tomko
Jiri Denemark
Laine Stump
Boris Fiuczynski
Fabricio Duarte
Adam Julis
Assaf Admi
Daniel Henrique Barboza
Leigh Brown
Collin Walling
Nikolai Barybin
Han Han
Andrea Bolognani
Stefan Berger
Marc-André Lureau