The only place where VIR_DOMAIN_EVENT_RESUMED should be generated is the
RESUME event handler to make sure we don't generate duplicate events or
state changes. In the worse case the duplicity can revert or cover
changes done by other event handlers.
For example, after QEMU sent RESUME, BLOCK_IO_ERROR, and STOP events
we could happily mark the domain as running and report
VIR_DOMAIN_EVENT_RESUMED to registered clients.
https://bugzilla.redhat.com/show_bug.cgi?id=1612943
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Thanks to the previous commit the RESUME event handler knows what reason
should be used when changing the domain state to VIR_DOMAIN_RUNNING, but
the emitted VIR_DOMAIN_EVENT_RESUMED event still uses a generic
VIR_DOMAIN_EVENT_RESUMED_UNPAUSED detail. Luckily, the event detail can
be easily deduced from the running reason, which saves us from having to
pass one more value to the handler.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Whenever we get the RESUME event from QEMU, we change the state of the
affected domain to VIR_DOMAIN_RUNNING with VIR_DOMAIN_RUNNING_UNPAUSED
reason. This is fine if the domain is resumed unexpectedly, but when we
sent "cont" to QEMU we usually have a better reason for the state
change. The better reason is used in qemuProcessStartCPUs which also
sets the domain state to running if qemuMonitorStartCPUs reports
success. Thus we may end up with two state updates in a row, but the
final reason is correct.
This patch is a preparation for dropping the state change done in
qemuMonitorStartCPUs for which we need to pass the actual running reason
to the RESUME event handler and use it there instead of
VIR_DOMAIN_RUNNING_UNPAUSED.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This patch replaces some rather generic VIR_DOMAIN_RUNNING_UNPAUSED
reasons when changing domain state to running with more specific ones.
All of them are done when libvirtd reconnects to an existing domain
after being restarted and sees an unfinished migration or save.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Once we introduce cgroup v2 support we need to handle processes and
threads differently.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
In cgroup v2 we need to handle processes and threads differently,
following patch will introduce virCgroupAddThread.
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
In a following case:
virsh start $domain
service libvirtd stop
<shutdown> the guest from within the $domain
service libvirtd start
Notice that PCI devices which have been assigned to the $domain will
still be bound to stub drivers instead rebound to host drivers.
In that case the call stack is like below:
libvirtd start
qemuProcessReconnect
qemuProcessStop (because $domain was shutdown without
libvirtd event to process that)
qemuHostdevReAttachDomainDevices
qemuHostdevReAttachPCIDevices
virHostdevReAttachPCIDevices
However, because qemuHostdevUpdateActiveDomainDevices was called
after the qemuConnectMonitor, the setup of the tracking of each
host device in the $domain on either the activePCIHostdevs list
or inactivePCIHostdev list will not occur in an orderly manner.
Therefore, virHostdevReAttachPCIDevices just neglects these host PCI
devices which are bound to stub drivers and doesn't rebind them to
host drivers.
This patch fixs that by moving qemuHostdevUpdateActiveDomainDevices before
qemuConnectMonitor during libvirtd reconnection processing.
Signed-off-by: Wu Zongyong <cordius.wu@huawei.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Use the new qemuDomainRemoveInactiveJobLocked to remove the
@obj during the virDomainObjListForEach call which holds a
lock on the domain object list.
Signed-off-by: Wang Yechao <wang.yechao255@zte.com.cn>
Reviewed-by: John Ferlan <jferlan@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1607202
It's essentially stated in the nwfilterBindingDelete that we
will allow the admin to shoot themselves in the foot by deleting
the nwfilter binding which then allows them to undefine the
nwfilter that is in use for the running guest...
However, by allowing this we cause a problem for libvirtd
restart reconnect processing which would then try to recreate
the missing binding attempting to use the deleted filter
resulting in an error and thus shutting the guest down.
So rather than keep adding virDomainConfNWFilterInstantiate
flags to "ignore" specific error conditions, modify the logic
to ignore, but VIR_WARN errors other than ignoreExists. This
will at least allow the guest to not shutdown for only nwfilter
binding errors that we can now perhaps recover from since we
have the binding create/delete capability.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Even though the current use of the function does not require full
implementation with transactions (none of the callers pass a path
somewhere under /dev), it doesn't hurt either. Moreover, in
future patches the paradigm is going to shift so that any API
that touches a file is required to use transactions.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The qemuSecurityDomainSetPathLabel() function reports perfect
error itself. Do not overwrite it to something less meaningful.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuProcessInitCpuAffinity prevents a VM from getting started on a
platform that uses cpu affinity wrapper stubs e.g. macOS.
The patch adds qemuProcessInitCpuAffinity stub on all platforms without
HAVE_SCHED_GETAFFINITY or HAVE_BSD_CPU_AFFINITY.
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
It was found that in cases with host devices virProcessKillPainfully
might be able to send signal zero to the target PID for quite a while
with the process already being gone from /proc/<PID>.
That is due to cleanup and reset of devices which might include a
secondary bus reset that on top of the actions taken has a 1s delay
to let the bus settle. Due to that guests with plenty of Host devices
could easily exceed the default timeouts.
To solve that, this adds an extra delay of 2s per hostdev that is associated
to a VM.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Switch to using the QOM/qdev handles in all calls to
qemuMonitorGetBlockInfo when using -blockdev. The callers also need to
make sure to use the correct handle afterwards to extract the data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the 'node-name' provided in the event if 'device' is empty to look
up the disk.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add handling of the 'id' field in the event which corresponds to the
QDEV id of the device.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Allow looking up also via QOM id and rename the function accordingly.
Also add documentation of the specifics.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The proper way to do this would be to use the 'throttle' driver but
unfortunately it can't change the 'throttle_group' so we can't provide
feature parity. This hack uses the block_set_io_throttle command to do
so until we can properly replace it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Node names for block objects in qemu need to be unique for an instance
of the qemu process. Add a counter to generate objects sequentially and
store it in the status XML so that we can restore it.
The helpers added allow to create new node names and reset the counter
after the VM process terminates.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We'll specify them ourselves so it's pointless to attempt to redetect
them.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We need to load the backing chain from the XML when using -blockdev.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
SD cards are currently passed by using -drive only which would not be
compatible with using -blockdev fully.
Clear QEMU_CAPS_BLOCKDEV if the VM has such devices.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently we'd report the alias of the drive which is backing the cdrom
rather than the device itself:
$ virsh event ds tray-change --loop
event 'tray-change' for domain ds disk drive-ide0-0-1: opened
event 'tray-change' for domain ds disk drive-ide0-0-1: closed
Report the disk device alias as we document in the API docs:
https://libvirt.org/html/libvirt-libvirt-domain.html#virConnectDomainEventTrayChangeCallback
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Qemu-3.0 supports Hyper-V-style PV TLB flush, Windows guests can benefit
from this feature as KVM knows which vCPUs are not currently scheduled (and
thus don't require any immediate action).
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Qemu-3.0 supports so-called 'Reenlightenment' notifications and this (in
conjunction with 'hv-frequencies') can be used make Hyper-V on KVM pass
stable TSC page clocksource to L2 guests.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Qemu-2.12 gained 'hv-frequencies' cpu flag to enable Hyper-V frequency
MSRs. These MSRs are required (but not sufficient) to make Hyper-V on
KVM pass stable TSC page clocksource to L2 guests.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Resctrl not only supports cache tuning, but also memory bandwidth
tuning. Renaming cachetune to resctrl to reflect that. With resctrl,
all allocation for different resources (cache, memory bandwidth) are
aggregated and represented by a virResctrlAllocPtr inside
virDomainResctrlDef.
Signed-off-by: Bing Niu <bing.niu@intel.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This reverts commit 0f80c71822d82465d558d697d3be9af2d21e3675.
Turns out, our code relies on virCgroupFree(&var) setting
var = NULL.
Conflicts:
src/util/vircgroup.c: context because 94f1855f099445d is not
reverted.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Modify virCgroupFree function signature to take a value of type
virCgroupPtr instead of virCgroupPtr * as the parameter.
Change the argument type in all calls to virCgroupFree function
from virCgroupPtr * to virCgroupPtr. This is a step towards
having consistent function signatures for Free helpers so that
they can be used with VIR_AUTOPTR cleanup macro.
Signed-off-by: Sukrit Bhatnagar <skrtbhtngr@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Use of enum types for struct fields is generally avoided since it causes
warnings if the compiler assumes the enum is unsigned. For example
commit 8e2982b5767a25e5da6533c65bfdc648c95b3c69
Author: Cole Robinson <crobinso@redhat.com>
Date: Tue Jul 24 16:27:54 2018 -0400
conf: Clean up virDomainDefParseCaps
Introduced a line:
if ((def->virtType = virDomainVirtTypeFromString(virttype)) < 0) {
which causes a build failure with CLang
conf/domain_conf.c:19143:65: error: comparison of unsigned enum expression < 0 is always false [-Werror,-Wtautological-compare]
as the compiler is free to optimize away the "< 0" check due to the
assumption that the enum type is unsigned and always in range.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
With 'switch' we can utilize the compile time enum checks which we can't
rely on with plain 'if' conditions.
Signed-off-by: Shi Lei <shilei.massclouds@gmx.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
In some cases backing chain needs to be cleared prior to re-detection.
Move this step out of qemuDomainDetermineDiskChain as only certain
places need it and the function itself is able to skip to the end of the
chain to perform detection.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since 2.10 QEMU supports a new display type egl-headless which uses the
drm nodes for OpenGL rendering copying back the rendered bits back to
QEMU into a dma-buf which can be accessed by standard "display" apps
like VNC or SPICE. Although this display type can be used on its own,
for any practical use case it makes sense to pair it with either VNC or
SPICE display. The clear benefit of this display is that VNC gains
OpenGL support, which it natively doesn't have, and SPICE gains remote
OpenGL support (native OpenGL support only works locally through a UNIX
socket, i.e. listen type=socket/none).
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
If qemu-pr-helper process died while libvirtd was not running no
event is emitted. Therefore, when reconnecting to the monitor we
must check the qemu-pr-helper process status and act accordingly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This event is emitted on the monitor if one of pr-managers lost
connection to its pr-helper process. What libvirt needs to do is
restart the pr-helper process iff it corresponds to managed
pr-manager.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Users have possibility to disable qemu namespace feature (e.g.
because they are running on *BSD which lacks Linux NS support).
If that's the case we should not try to move qemu-pr-helper into
the same namespace as qemu is in.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When using domxml-to-native, we must generate CLI args that can be used
in a standalone scenario. This means no FD passing can be used. To
achieve this we must clear the QEMU_CAPS_CHARDEV_FD_PASS capability bit.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Remove the callbacks that the nwfilter driver registers with the domain
object config layer. Instead make the current helper methods call into
the public API for creating/deleting nwfilter bindings.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The UNIX socket FDs were we passing to QEMU inherited a label based on
libvirtd's context. QEMU is thus denied ability to access the UNIX
socket. We need to use the security manager to change our current
context temporarily when creating the UNIX socket FD.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Be more consistent and use 'preparing' instead of 'prepare' here.
Signed-off-by: Luyao Huang <lhuang@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
When commit 6718132d enforced usage of the cleanup label, it forgot to
set the @ret variable to 0 on "success" exit path.
Signed-off-by: Luyao Huang <lhuang@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Some identifiers use Sev, some SEV. Prefer the latter.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
A common cleanup path for both the success and the error case.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Make the function prefix match the file it's in.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
And replace all calls with virObjectEventStateQueue such that:
qemuDomainEventQueue(driver, event);
becomes:
virObjectEventStateQueue(driver->domainEventState, event);
And remove NULL checking from all callers.
Signed-off-by: Anya Harter <aharter@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
QEMU >= 2.12 provides 'sev-guest' object which is used to launch encrypted
VMs on AMD platform using SEV feature. The various inputs required to
launch SEV guest is provided through the <launch-security> tag. A typical
SEV guest launch command line looks like this:
-object sev-guest,id=sev0,cbitpos=47,reduced-phys-bits=5 ...\
-machine memory-encryption=sev0 \
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Add the external swtpm to the emulator cgroup so that upper limits of CPU
usage can be enforced on the emulated TPM.
To enable this we need to have the swtpm write its process id (pid) into a
file. We then read it from the file to configure the emulator cgroup.
The PID file is created in /var/run/libvirt/qemu/swtpm:
[root@localhost swtpm]# ls -lZ /var/run/libvirt/qemu/swtpm/
total 4
-rw-r--r--. 1 tss tss system_u:object_r:qemu_var_run_t:s0 5 Apr 10 12:26 1-testvm-swtpm.pid
srw-rw----. 1 qemu qemu system_u:object_r:svirt_image_t:s0:c597,c632 0 Apr 10 12:26 1-testvm-swtpm.sock
The swtpm command line now looks as follows:
root@localhost testvm]# ps auxZ | grep swtpm | grep socket | grep -v grep
system_u:system_r:virtd_t:s0:c597,c632 tss 18697 0.0 0.0 28172 3892 ? Ss 16:46 0:00 /usr/bin/swtpm socket --daemon --ctrl type=unixio,path=/var/run/libvirt/qemu/swtpm/1-testvm-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/485d0004-a48f-436a-8457-8a3b73e28568/tpm1.2/ --log file=/var/log/swtpm/libvirt/qemu/testvm-swtpm.log --pid file=/var/run/libvirt/qemu/swtpm/1-testvm-swtpm.pid
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
