These three fields are cached values that do not reflect reality unless
the caller refreshes them. 'allocation' is in addition ultra-unreliable:
any guest write into a previously unallocated part of a sparse image
invalidates it, even right after a refresh.
Document this on the struct so new callers do not trust the values.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add VIR_DOMAIN_SETVCPU_ASYNC_UNPLUG for virDomainSetVcpu().
Define a dedicated virDomainSetVcpuBehaviour flag type and wire the
new flag through the QEMU driver. As with setvcpus async unplug,
success indicates request acceptance while final completion is
reported by the vcpu-removed event.
Update the API documentation and add virsh support for the async path to
the setvcpu subcommand.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add VIR_DOMAIN_VCPU_ASYNC_UNPLUG for virDomainSetVcpusFlags().
With this flag, success indicates that QEMU accepted the unplug
request, while final completion is reported by the vcpu-removed
event. Rejected requests continue to be reported by the
device-removal-failed event.
Wire the flag through the QEMU driver, document its semantics, and
add virsh support for the async path in the setvcpus subcommand.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Thread an async_unplug flag through the internal QEMU vCPU unplug
helpers.
When set, the unplug path returns after QEMU accepts the device
deletion request and leaves final completion to the existing
DEVICE_DELETED handling routines.
All callers still pass false, so this does not change behaviour yet.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Emit the vcpu-removed event when QEMU vCPU unplug completes.
Hook this into qemuDomainRemoveVcpu(), which covers both the
synchronous completion path and the DEVICE_DELETED-driven alias
removal path.
Some architectures may have multiple vcpus grouped under a single qemu
vcpu object; on those platforms a `vcpu-removed` event will be emitted
for each vcpu that is removed from this group.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Add a new domain event for completed vCPU removal.
Wire the event through the internal event framework and extend the
remote protocol so remote clients can receive it. Update virsh and
the event-test example accordingly.
The event is not emitted anywhere yet.
Signed-off-by: Akash Kulhalli <akash.kulhalli@oracle.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The 'new->fds' array is not yet initialized at the point where the check
if the FD is occupied happens so the error would always report that FD
'0' is in use. Use 'new->testfds' instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Since VIR_WARN doesn't use translatable messages, the
'sc_prohibit_error_message_on_multiple_lines' check doesn't catch those.
Introduce another check for VIR_WARN.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
The 'warn' level messages are logged in the default settings so may end
up in something which the user looks for. Random line breaks prevent
grepping for the message.
Similarly to 'error' level messages remove the arbitrary line breaks in
the source to make the messages greppable in the source.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Soon the minimal version is going to be bumped to QEMU-7.2. Drop
older capabilities, which are unused anyways, thanks to previous
cleanups.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The sgx-epc test case is currently pinned to capabilities of that
QEMU-7.0. Well, soon the minimal version of QEMU is going to be
bumped. But thanks to previous commit the capabilities of 11.0.0
version support SGX too. Switch the test case to the newer
capabilities.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Detecting SGX support is done in two ways and both have to
succeed in order for caps to have the capability:
1) the sgx-epc device needs to be present,
2) the query-sgx-capabilities command needs to return data
instead of an error.
So far, the only caps file that meets both requirements is
caps_7.0.0_x86_64. Soon the minimal version is going to be bumped
to QEMU-7.2. But caps_11.0.0_x86_64 has the device and the only
thing missing is the proper reply to the monitor command.
Therefore, create new qemu_11.0.0_x86_64+sgx capabilities with
reply to query-sgx-capabilities command copied from caps_7.0.0.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Both ppc64-default-cpu-kvm-pseries-2.7 and
ppc64-default-cpu-tcg-pseries-2.7 test cases rely on pseries-2.7
machine type. It was removed in QEMU-7.2. Soon the minimal
version is going to be bumped to QEMU-7.2 rendering those tests
obsolete. Drop them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Soon the minimal version is going to be bumped to QEMU-7.2. Drop
older cpu model expansion test cases (6.2.0, 7.0.0, 7.1.0).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Setting TLS hostname for NBD disks was introduced in QEMU-7.0.0.
Soon the minimal version is going to be bumped to QEMU-7.2. Drop
old test.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Toggling PS/2 state is available from QEMU-7.0 onwards. Soon the
minimal version is going to be bumped to QEMU-7.2. Drop old
tests.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
In qemuxmlconftest there's a section which aim on testing
'host-model' cpu mode expansion. Since this depends on what QEMU
reports (and thus can change with its version) we have a test
case for each QEMU version supported. Unfortunately, when adding
capabilities for new QEMUs this section was forgotten. Add
missing test cases (10.2.0 and 11.0.0).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Invoke the 'connHandler' without checking return value. 'virsh complete'
can provide useful completions even when the daemon connection is
broken.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The completer closes stderr to suppress anything polluting the shell
when completion would cause any errors.
Since 'virshReconnect' would call 'vshError' on connection failure this
causes vshError to be killed by SIGPIPE and not provide any completions
if the connection is not possible.
To avoid this add a flag called 'stderr_closed' to vshControl and use it
to suppress output in 'vshPrintStderr'. Keep only the log.
Prior to this patch, attempt to run completion on a host with all
daemons shut down would result in:
# virsh complete -- "start" "--doma" ; echo $?
141
#
With this patch the completion will still fail but the return code will
be 1. Further patch will allow completion.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Label the 'pid'/'tid' field. Use proper typecast also for 'tid'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
CPU stats for inactive VM make no sense. In this case it's especially
misleading because 'vm->pid' of an inactive VM is '0' so
virProcessGetStat returns stats for virtqemud itself.
Fixes: 044b8744d6
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add sections describing usage of the virtio-console device
and about block I/O tuning.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Some VMware guests specify NVRAM storage using the 'nvram' parameter.
If found, parse it and store it in the domain's os.loader.nvram field,
which gets formatted as:
<os>
<type arch='x86_64'>hvm</type>
<nvram>[datastore] directory/dokuwiki.nvram</nvram>
</os>
The NVRAM path uses the same transformation functions as disk paths
(ctx->parseFileName and ctx->formatFileName) to ensure consistent
handling of datastore-qualified paths.
The NVRAM is stored as a virStorageSource with type VIR_STORAGE_TYPE_FILE
to ensure compatibility with libvirt's existing firmware handling
infrastructure.
Signed-off-by: Surya Gupta <surygupt@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Here's the deal: the 'devices' controller as such does not exist
in CGroupsV2. The alternative is to load eBPF program that mimics
the controller's behavior from CGroupsV1. But, only privileged
user can load such program. This means that virt-host-validate
(when ran as a regular user) claims 'devices' controller missing
(rightfully so), and suggests enabling it in Kconfig. This last
bit might be misleading to users [1].
Now, to fix this ideally, all three conditions should be checked
(CGroupsV2, 'devices' controller and regular user), but our
virCgroup module deliberately hides the version of CGroups. So
check for the other two conditions.
1: https://lists.libvirt.org/archives/list/users@lists.libvirt.org/thread/USDFFRJK74GYHRGMXOE2FSAA4PQD23RE/
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <pavel@hrdina.info>
With CGroupsV2 the freezer controller is split into two files:
1) cgroup.freeze where an integer is written to thaw(0)/freeze(1)
processes within the cgroup, and
2) cgroup.events where the frozen status can be read.
Now, freezing/thawing a cgroup is as simple as writing
corresponding integer into cgroup.freeze. But similarly to
CGroupsV1, it may take some time to actually freeze all processes
inside the cgroup. So read both file and map combination of their
values according to this table:
| frozen from cgroup.events
cgroup.freeze | 0 | 1
--------------+------------+-------------
0 | THAWED | N/A
--+------------+-------------
1 | FREEZING | FROZEN
Resolves: https://gitlab.com/libvirt/libvirt/-/work_items/870
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <pavel@hrdina.info>
The freezer controller in CGroupsV2 is always present (under
cgroup.freeze file). Make our vircgroupv2 backend aware of it.
NB, because of the way our backends are ordered (v2 is prefered)
the v1 freezer is never going to be used when CGroupsV2 are
detected. Hence the change to tests.
NB2, this also fixes output of virt-host-validate which complains
that the 'freezer' controller is not present for LXC driver.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <pavel@hrdina.info>
So far, only vircgroupv1 implements freezer controller related
callbacks and both work with strings ("THAWED", "FROZEN",
"FREEZING"). This works well with v1 but with CGroupsV2 there are
just two states and they are represented by a number.
Therefore, introduce an enum and implement enum <-> string
conversion for each backend separately.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <pavel@hrdina.info>
Report error in case when incorrect index is specified for
the ISA controller.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Bhyve supports virtio-console devices using the following syntax:
-s 2:0,virtio-console,org.qemu.guest_agent.0=/path/to/unix/socket,other.port=/other/socket,...
There are two details about that to consider.
The first one is that only up to 16 ports per console is supported. This
is different from the default (31), so update the code to manually add
the virtio-serial controllers with 16 ports. For the existing
controllers, make sure to set max ports to 16 or error out if ports
count greater than 16 was specified.
The second one is that bhyve does not clean up UNIX sockets for these
devices. So update virBhyveProcessStop() to remove leftover sockets.
Not adding capabilities probing as the virtio-console device is
available on all supported FreeBSD versions and on all supported arches.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Currently, there are two (at least) issues in virBhyveProcessStop().
Before going into details, a quick overview of the bhyve shutdown
process. It is a two stage process: first, the main bhyve
process gets destroyed (either via an external command or within the
guest), then the resources need to be cleaned up using the bhyvectl(8)
tool.
The first issue is that if virCommandRun() for bhyvectl(8) fails,
virBhyveProcessStop() jumps to the 'cleanup' label and misses cleaning
of some resources.
The second issue is more serious. Currently, monitor is closed only
after running of the bhyvectl(8) command. That means that the monitor
could catch the domain destroy event and try to run
virBhyveProcessStop() on the same domain again, resulting in trying
to release already released resources, such as the monitor itself.
Address by:
* Making virCommandRun() on bhyvectl(8) non-critical. Even if it
fails, we try to clean up all resources. We consider the function
failed (return value 1) though.
* Close monitor before running bhyvectl(8)
Additionally, do not verify that virBhyveProcessBuildDestroyCmd()
returns non-NULL, there could be only allocation errors.
And with 'glib' they result in an abort() so no need
to worry about those.
Reported-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
There are some features/improvements/bug fixes I've either
contributed or reviewed/merged. Document them for upcoming
release.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
virPCIDeviceReset() and virPCIDeviceIsBehindSwitchLackingACS() both
used a hardcoded check for bus != 0 to determine if a device is
attached directly to a "root bus". This breaks on systems with more
than one root bus, where at least one of the buses is necessarily
not 0! (for example Intel Arrow Lake based systems
where the CPU's root complex is bus 0x00 and the PCH root complex is
bus 0x80).
Update both functions to use virPCIDeviceIsOnRootBus(), which detects
root bus attachment via the canonicalized sysfs device link in
/sys/devices/*, making it work correctly for all root buses, not just
those numbered 0.
Discussion of the issue here:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/NE62XCNHTWTFN4SFNTTSLI2W6BGGM64W/
Resolves: https://github.com/QubesOS/qubes-issues/issues/10393
Signed-off-by: Bruno Martins <ehanoc@protonmail.com>
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Bruno Martins <ehanoc@protonmail.com>
Tested-by: Bruno Martins <ehanoc@protonmail.com>
When libvirtd reconnects to a running QEMU process that had an
in-progress migration, qemuProcessReconnect first connects the
monitor and only later recovers the migration job. During this window
the async job is VIR_ASYNC_JOB_NONE, so any MIGRATION status events
from QEMU are silently dropped by qemuProcessHandleMigrationStatus.
If the migration was already cancelled or completed by QEMU during
this window, no further events will be emitted. When
qemuMigrationSrcCancelUnattended later restores the async job and
calls qemuMigrationSrcCancel with wait=true, the wait loop calls
qemuDomainObjWait (virCondWait with no timeout) and blocks forever
waiting for an event that will never arrive.
qemuProcessRecoverMigration already queries QEMU for the current
migration state via qemuMigrationAnyRefreshStatus and passes the
result to qemuProcessRecoverMigrationOut as migStatus. Plumb that
value one level further into qemuMigrationSrcCancelUnattended and,
when it indicates the migration has already reached a terminal
state (VIR_DOMAIN_JOB_STATUS_CANCELED), skip restoring the async
job and the qemuMigrationSrcCancel/virDomainObjEndAsyncJob pair
entirely.
Signed-off-by: Denis V. Lunev <den@openvz.org>
Suggested-by: Jiri Denemark <jdenemar@redhat.com>
CC: Peter Krempa <pkrempa@redhat.com>
CC: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Denis V. Lunev
Akash Kulhalli via Devel
Peter Krempa
Paolo Bonzini
Michal Privoznik
Shalini Chellathurai Saroja
Roman Bogorodskiy
George Melikov
Jiri Denemark
Bruno Martins