We're only ever passing a single binary when calling this
function, so we can remove all code dealing with the
possibility of a second binary being specified.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
When the guest is native, we are currently looking at
potential KVM binaries regardless of whether or not we have
already located a QEMU binary suitable to run the guest.
This made sense back when KVM support was not part of QEMU
proper, but these days the KVM binaries are in most cases
just trivial wrapper scripts around the native QEMU binary
so it doesn't make sense to poke at them unless they're
the only binaries on the system, such as when running on
RHEL.
This will allow us to simplify both virQEMUCapsInitGuest()
and virQEMUCapsInitGuestFromBinary().
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
When running an armv7l guest on an aarch64 hosts, the
qemu-system-aarch64 binary should be our first choice instead
of qemu-system-arm since the former can take advantage of KVM
acceleration.
Move the special case to virQEMUCapsFindBinaryForArch() so
that it's handled along with all other cases rather than on
its own later on.
Doing so will also make further refactoring easier.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
virCapabilitiesAddGuestDomain() takes an optional binary
name: this is intended for cases where a certain domain
type can't use the default one registered for the guest
architecture, but has to use a special binary instead.
The current code, however, will pass 'binary' again when
'kvmbin' is not defined, which is unnecessary as 'binary'
has been registered as default earlier, and will result
in capabilities output such as
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<domain type='qemu'/>
<domain type='kvm'>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
</domain>
with the second <emulator> element providing no additional
information.
Change it so that, when 'kvmbin' is not defined, NULL is
passed and so the default emulator will be used instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The function performing the checks, rather than its callers,
should contain comments explaining the rationale behind said
checks.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1630164
Since 2a13a0a103 we are querying the vhostuser's interface name
when building qemu command line. However, we forgot to do so on
hotplug.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
There seems to be no need to add the ignore_value wrapper or
caste with (void) to the unlink() calls, so let's just remove
them. I assume at one point in time Coverity complained. So,
let's just be consistent - those that care to check the return
status can and those that don't can just have the naked unlink.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@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>
All of the ones being removed are pulled in by internal.h. The only
exception is sanlock which expects the application to include <stdint.h>
before sanlock's headers, because sanlock prototypes use fixed width
int, but they don't include stdint.h themselves, so we have to leave
that one in place.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
It doesn't really make sense for us to have stdlib.h and string.h but
not stdio.h in the internal.h header.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
When restoring a domain from a compressed image, we launch an
intermediate process for decompressing the saved data. If QEMU fails to
load the data for some reason, we force close the stdin/stdout file
descriptors of the intermediate process and wait for it to die. However,
virCommandWait can report various errors which would overwrite the real
error from QEMU. Thus instead of getting something useful:
internal error: process exited while connecting to monitor:
2018-09-17T15:17:29.998910Z qemu-system-x86_64: can't apply global
Skylake-Client-x86_64-cpu.osxsave=off: Property '.osxsave' not found
we could get an irrelevant error message:
internal error: Child process (lzop -dc --ignore-warn) unexpected
fatal signal 13
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Now that we know what metadata lock manager user wishes to use we
can load it when initializing security driver. This is achieved
by adding new argument to virSecurityManagerNewDriver() and
subsequently to all functions that end up calling it.
The cfg.mk change is needed in order to allow lock_manager.h
inclusion in security driver without 'syntax-check' complaining.
This is safe thing to do as locking APIs will always exist (it's
only backend implementation that changes). However, instead of
allowing the include for all other drivers (like cpu, network,
and so on) allow it only for security driver. This will still
trigger the error if including from other drivers.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This config option allows users to set and enable lock manager
for domain metadata. The lock manager is going to be used by
security drivers to serialize each other when changing a file
ownership or changing the SELinux label. The only supported lock
manager is 'lockd' for now.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The file being present doesn't necessarily mean anything these
days, as it's created independently of whether the kvm module
has been loaded[1]; moreover, we're already gathering all the
information we need through QMP, so poking the filesystem at
all is entirely unnecessary.
[1] https://github.com/systemd/systemd/commit/d35d6249d5a7ed3228
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
This capability is documented as having one meaning (whether
KVM is enabled by default) but is actually assigned two other
meanings over its life: whether the query-kvm QMP command is
available at first, and later on whether KVM is usable / was
used during probing.
Since the query-kvm QMP command was available in 1.5.0, we
can avoid probing for it; additionally, we can simplify the
logic by setting the flag when it applies instead of initially
setting it and then clearing it when it doesn't.
The flag's description is also updated to reflect reality.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
A side effect of recent changes is that we would always try
to regenerate the capabilities cache for non-native QEMU
binaries based on /dev/kvm availability, which is of course
complete nonsense. Make sure that doesn't happen.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
It was already available in 1.5.0.
Moreover, we're not even formatting it on the QEMU command
line, ever: we just use it as part of some logic that decides
whether KVM support should be advertised, and as it turns out
that logic is actually buggy and dropping this capability
fixes it.
https://bugzilla.redhat.com/show_bug.cgi?id=1628469
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Now that committing transactions using pid == -1 means that we're
not fork()-ing to run the transaction in a specific namespace, we
can utilize the transaction processing semantics in order to
start, run a or multiple commands, and then commit the
transaction without being concerned with other interactions or
transactions interrupting the processing. This will eventually
allow us to have a single place where all the paths can be
locked, followed by relabeling and unlocking again.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
In the future, the transactions are not going to be optional and
they will be run regardless of domain using namespace to collect
list of paths to be relabeled.
To make sure there won't be an API that goes behind transaction
code back update the comment that serves as decision manual
whether an API must be fully implemented or plain #define is
sufficient.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Even though the current use of the functions does not require full
implementation with transactions (none of the callers passes 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>
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>
It is not a problem at all if the `tss` user/group does not exist, the code
fallbacks to the `root` user/group. However we report a warning for no reason
on every start-up. Fix this by checking if the user/group actually exists.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
After removing the host CPU model re-computation,
this function is no longer necessary.
This reverts commits:
commit d0498881a0
virQEMUCapsFreeHostCPUModel: Don't always free host cpuData
commit 5276ec712a
testUpdateQEMUCaps: Don't leak host cpuData
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Commit 82327038 moved a couple of checks out of the XML parser
into the domain validation; however, those checks seem to be more
useful as hypervisor specific checks rather than the more general
domain conf checks (nothing in the docs indicate a specific error).
Fortunately only QEMU was processing the memoryBacking, thus
add the changes to qemuDomainDefValidateMemory and change the
code a bit to make usage of the similar deref to def->mem and
the mem->nhugepages filter.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
We require QEMU 1.5.0 these days, so checking for versions
older than that is pointless.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The capability was introduced in QEMU 1.5.0, which is our
minimum supported QEMU version these days.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The capability was introduced in QEMU 1.3.1 and we require
QEMU 1.5.0 these days.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In some cases we are checking if the mount namespace is enabled
at two places: one is at the beginning of exported function (e.g.
qemuDomainNamespaceSetupDisk()) and the other is at the beginning
of qemuDomainNamespaceMknodPaths() which is called from the
former function anyway. Then we have some other functions which
rely on the later check solely.
In order to compensate for possibly needless function call,
qemuDomainNamespaceMknodPaths() returns early if @npaths is zero.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Commit 5b3492fadb moved qemuAgentCheckError calls into
qemuAgentCommand for various reasons; however, subsequent
commit 0977b8aa0 adding a new command made call again
So let's just remove the duplicitous call from
qemuAgentGetInterfaces.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Commit 5b3492fadb moved qemuAgentCheckError calls into
qemuAgentCommand for various reasons; however, subsequent
commit b1aa91e14 restored the call. So let's just remove
the duplicitous call from qemuAgentSetVCPUsCommand.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@redhat.com>
Previous commits removed all capabilities from per-device property
probing for:
pci-assign
kvm-pci-assign
usb-host
scsi-generic
Remove them from the virQEMUCapsDeviceProps list and get rid of the
redundant device-list-properties QMP calls.
Note that 'pci-assign' was already useless, because the QMP version
of the device is called 'kvm-pci-assign', see libvirt commit 7257480
from 2012.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Introduced by QEMU commit 28b77657 in v1.0-rc4~21^2~8.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Introduced by QEMU commit c29029d which was included in 1.5.0
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
At the time of the addition of 'pci-assign' in QEMU commit
v1.3.0-rc0~572^2 the bootindex argument was already supported.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
At the time of the addition of 'pci-assign' in QEMU commit
v1.3.0-rc0~572^2 the configfd argument was already supported.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Added by commit fc66c1603c and not used since.
Also, the device was present in QEMU 1.5.0 so this capability
will not be needed if we ever decide to implement usb-net support.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@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>
There is no need to check if @npaths is not zero. Let's
qemuDomainNamespaceUnlinkPaths() handle that.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
A virtio device such as
<controller type='scsi' model='virtio-scsi'/>
will be translated to one of four different QEMU devices
based on the address type. This behavior is the same for
all virtio devices, but unfortunately we have separate
ad-hoc code dealing with each and every one of them: not
only this is pointless duplication, but it turns out
that most of that code is not robust against new address
types being introduced and some of it is outright buggy.
Introduce a new function, qemuBuildVirtioDevStr(), which
deals with the issue in a generic fashion, and rewrite
all existing code to use it.
This fixes a bunch of issues such as virtio-serial-pci
being used with virtio-mmio addresses and virtio-gpu
not being usable at all with virtio-mmio addresses.
It also introduces a couple of minor regressions,
namely no longer erroring out when attempting to
use virtio-balloon and virtio-input devices with
virtio-s390 addresses; that said, virtio-s390 has
been superseded by virtio-ccw such a long time ago
that recent QEMU releases have dropped support for
the former entirely, so re-implementing such
device-specific validation is not worth it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The appropriate time to ensure the required capabilities are
present is validate rather than command line generation: add
a new qemuDomainDeviceDefValidateInput() function and move
all existing checks there.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
So far we've only formatted it for virtio-blk-pci and
virtio-blk-ccw, but other virtio-blk devices also support
the corresponding option; moreover, we've always formatted
it for all virtio-scsi devices.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are several functions where we pointlessly duplicate
parts of the format string and pass the same arguments:
refactor them so that the common parts are formatted separately
from the variable parts.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1622455
If a domain is configured to use <source type='file'/> under
<memoryBacking/> we have to honour that setting and produce
-mem-path on the command line. We are not doing so if domain has
no guest NUMA nodes nor hugepages.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The function to retrieve the file system info using QEMU-GA is using
some conditionals to retrieve the info. This is wrong because the error
of some conditionals will be raised if VIR_STRDUP return errors and not
if some problem occurred with JSON.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This commit adds support to use the function qemuAgentGetHostname()
to obtain the domain hostname using QEMU-GA command.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This commit implements the function qemuAgentGetHostname() that uses
the QEMU guest agent command 'guest-get-host-name' to retrieve the
guest hostname of virtual machine running the QEMU-GA.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The struct is called virPCIDeviceAddress and the
functions operating on it should be named accordingly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Commit f7b5566 added 'save_error' even though the function
already has 'originalError' used in the 'try_remove' section.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The size/capacity stats gathered in qemuDomainBlocksStatsGather when
using -blockdev would be overwritten by assigning/copying the transfered
data statistics at the end. Fix it by moving the assignment prior to
fetching the capacity data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
S390 is aware of both vfio-pci and vfio-ccw devices, so
on S390 the capability QEMU_CAPS_VFIO_PCI_DISPLAY will be
available. Add an extra check to make sure we only set the
display to off for vfio-pci mediated devices. Otherwise we
add display for vfio-ccw device and this breaks vfio-ccw
device qemu command line.
Fixes: d54e45b6e conf: Introduce new <hostdev> attribute 'display'
Signed-off-by: Farhan Ali <alifm@linux.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Commit 6534b3c4 tried to raise an error when there is no numa
nodes by setting access='shared' in the domain config, but added
a helper called from qemuDomainDeviceDefValidate instead of a
helper called from qemuDomainDefValidate for XML:
<memoryBacking>
<hugepages/>
<access mode='shared'/>
</memoryBacking>
Since there are no memory devices in the test XML, there would
be no validation failure, but the test added was still failing.
Investigating that it turns out that unnecessary XML elements
were causing the failure (no need for <video>, <graphics>,
<pm>, usb controller model "piix3-uhci", disk attribute for
"discard='unmap'", <serial>, <console>, <channel> and a
memballoon model). Removing all those before moving the method
caused the test to succeed.
So this patch moves the validation to the right place and
removes all the unnecessary XML pieces that were causing
a false validation failure.
https://bugzilla.redhat.com/show_bug.cgi?id=1448149#c14
Signed-off-by: Luyao Huang <lhuang@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We would have used virtio for networking anyway, but it's
better to be explicit; for graphics, none of the existing
models work right now but virtio is the only one which
has a non-PCI variant, so it's as good a default as any
Spotted-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
None of the existing models is suitable for use with
RISC-V virt guests, and we don't want information about
the serial console to be missing from the XML.
The name is based on comments in qemu/hw/riscv/virt.c:
RISC-V machine with 16550a UART and VirtIO MMIO
and in qemu/hw/char/serial.c:
QEMU 16550A UART emulation
along with the output of dmesg in the guest:
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
10000000.uart: ttyS0 at MMIO 0x10000000 (irq = 13,
base_baud= 230400) is a 16550A
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The architecture is new enough that we don't need to
concern ourselves with backwards compatibility in any
capacity.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 6700062 introduced a jump to error which skipped the
initialization of def:
qemu/qemu_parse_command.c:1870:9: error: variable 'def' is
used uninitialized whenever 'if' condition is true
[-Werror,-Wsometimes-uninitialized]
if (!(qemuCaps = virQEMUCapsCacheLookup(capsCache, progargv[0])))
Initialize def to fix this warning and qemuCaps, to prevent
a future error like this.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Historically the argv -> xml convertor wanted the same default machine
as we'd set when parsing xml. The latter has now changed, however, to
use a default defined by libvirt. The former needs fixing to again
honour the default QEMU machine.
This exposed a bug in handling for the aarch64 target, as QEMU does not
define any default machine. Thus we should not having been accepting
argv without a -machine provided.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virQEMUCapsGetDefaultMachine() method doesn't get QEMU's default
machine any more, instead it gets the historical default that libvirt
prefers for each arch. Rename it, so that the old name can be used for
getting QEMU's default.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We don't honour the QEMU default machine type anymore, always using the
libvirt chosen default instead. The QEMU argv parser, however, will need
to know the exacty QEMU default, so we must record that info.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The affected functions are
virDeviceInfoPCIAddressWanted()
virDeviceInfoPCIAddressPresent()
which get renamed to
virDeviceInfoPCIAddressIsWanted()
virDeviceInfoPCIAddressIsPresent()
to comply with the naming convention used for other
predicates.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This patch ensures that changes in attributes of interfaces will emit
errors except if they are missing from the XML.
Previously we were falsely reporting successful updates, because some
changed attributes got overwritten before the validity checks.
https://bugzilla.redhat.com/show_bug.cgi?id=1599513
Signed-off-by: Katerina Koukiou <kkoukiou@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>
The capability was usable since qemu 1.3 so we can remove all the
detection code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Allow mocking of the file descriptor numbers used for the TPM
passthrough mode by extracting the relevant code into an exported
function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
For versions where we can probe that the arguments are optional we can
perform the probing by a schema query rather than sending a separate
command to do so.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Add a new modifier character '*' which will select given schema entry
only when it is optional (denoted by the presence of the 'default' key).
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Split it into a function that returns the whole schema entry so that we
can do additional checks and a helper getting the type string from the
schema entry.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Introduce a few variables so that we can easily access the modifier
character and also don't have to do pointer arithmetic when selecting
the schema entries. This will simplify adding of new modifier
characters.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Extract the code used to probe for the functionality so that it does not
litter the code used for actual work.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Starting from qemu 2.7 the 'device' argument is in fact a name of the
job itself. Change our APIs accordingly and adjust the error message.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The API deals with a block job so use the common error reporting
function for it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Move all relevant APIs dealing with existing jobs together.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The API does not report any special job-related error so the generic
error function should be used.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Now that the job name is used in single place in the respective
functions remove the temporary strings.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Report the generic errors using the existing function so that we don't
reimplement the same functionality multiple times.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Both were removed prior to qemu v1.2.0-rc0 when switching to the new
error format where almost all error types were converted to GenericError.
Relevant qemu commits are <de253f14912e> and <df1e608a01eb0>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We're going to need to assign virtio-mmio addresses to non-ARM
guests soon, so let's create a generic wrapper that calls to
the architecture-specific implementation.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
With the current implementation, adding a new architecture
and not updating preferredMachines accordingly will not
cause a build failure, making it very likely that subtle
bugs will be introduced in the process. Rework the code
so that such issues will be caught by the compiler.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
We should compare the alias/qdev id only when it was provided by the
caller and when it was found in the reply. Otherwise we could
dereference a NULL pointer. STRNEQ_NULLABLE is not appropriate since
it would return 'true' if the string was not present in the JSON output.
Found by Coverity.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
qemuDomainDiskGetBackendAlias allocates a copy of the nodename string so
we need to free it at the end.
Found by Coverity.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
qemuDomainDetachControllerDevice contained code which implied that alias
might be NULL when detaching the disk and tried to generate it. This is
no longer possible so we can remove the code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@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>
Add code paths which call into the new functions to gather the data on a
per-node-name basis and tweak the aliases used for extracting the data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the 'qdev' instead of the disk alias to lookup the stats and
transfer the capacity from the appropriate node name so that the
function works with -blockdev.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.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>
With -blockdev qemu will not report any useful "device" for the data
returned by 'query-block'. We need to start using the 'qdev' field to do
so in cases when "device" is empty or it does not match the entry name.
This patch adds data for the 'qdev' field into the returned data
structure.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Data relevant for the storage of a backing chain member will need to be
reported separately when switching to blockdev. Prepare a function that
extracts the appropriate data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When reporting stats for the backing chain some of them make sense only
for the topmost entry as they are actually tied to the frontend device.
We unfortunately can't change that fact, but we can stop reporting all
zero stats for the backing chain members where they don't make any
sense.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While we report the read and written byte stats for every single layer
of the backing chain, qemu in fact reports them only for the frontend.
Split out the relevant stats into a separate function so that we can
later fix this bug and stop reporting it for backing chain entries where
they don't make sense.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Split out the header so that the loop can be refactored later.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Split out the code which converts the stats gathered in
qemuDomainGetStatsBlock into typed parameters so that it will look
less ugly when extending it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In cases when -blockdev is used we need to use 'query-named-block-nodes'
instead of 'query-block'. This means that we can extract the
write-threshold variable right away.
To keep compatibility with old VMs modify the code which was extracting
the value previously so that it updates the stats structure and a single
code path then can be used to extract the data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Allow reuse of qemuDomainGetStatsOneBlock to work with nodenames by
removing the code that looks up the stats data to the caller.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Disk image size data are not contained in the reply of query-blockstats
but need to be gathered from query-block. For use with -blockdev we
really need to call 'query-named-block-nodes' and process it to retrieve
the correct data.
This patch introduces qemuMonitorBlockStatsUpdateCapacityBlockdev which
updates the capacity data by nodename rather than device name.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
For use with -blockdev we need to be able to retrieve the stats by
'qdev' for the frontend device stats since 'device' will be empty. Note
that for non-blockdev case qdev and 'device' with 'drive-' skipped would
be the same.
Additionally so that we can report the highest written offset we need to
also be able to access them by node-name for backing chain purposes.
In cases when 'device' is empty it does not make sense to gather them.
Allow arranging the stats simultaneously in all the above dimensions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rather than totalling every entry from 'query-block' for stats provided
by qemuDomainBlocksStatsGather total only stats for known disks. This
will allow to return data for nodenames and qdevs in the same hash so
that we can use them with -blockdev.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The string is not modified so it does not make sense to have a copy.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the new APIs which allow to manipulate the tray and media separately
and also allow using a nodename to refer to a media to implement media
changing.
With the new approach we don't have to call eject twice as the media is
removed by calling qemuMonitorBlockdevMediumRemove.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
With blockdev we can use the full range of commands to manipulate the
tray and the medium separately. Implement monitor code for this.
Schema testing done in the qemumonitorjsontest allows us to verify that
we generate the commands correctly.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Initialize data for the whole backing chain when plugging in or removing
disks when a machine supports -blockdev.
Similarly to startup we need to prepare the structures for the whole
backing chain and take care of the copy-on-read feature.
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>
Use the nodename to resize the device rather than the drive alias.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
With -blockdev the drive alias can't be used any more so we need to
switch to the QOM name.
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>
Add a helper which will use a collection of other helpers to determine
whether a disk requires throttling to be enabled.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Format the backing chain onto the commandline using the 'json' syntax
with -blockdev.
The command line formatter needs only minor tweaks to add the new
entries but we now need to initialize the structures that are used for
every layer of the backing chain.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Pass in the node name as the backend alias when -blockdev is used. As
copy-on-read is expressed by a separate -blockdev backing chain member
we need to decide which node name to use here.
For empty cdroms when using -blockdev there is no backend at all so NULL
is returned.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The copy on read functionality is done using a separate layer in the
backing chain. Add function to generate properties for it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Prepare the full backing chain by instantiating authentication and TLS
transport secrets and other necessary objects so that we can add the
full backing chain explicitly to qemu. This also includes allocation of
nodenames for the individual backing chain members.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The copy-on-read feature is expressed by adding a new node layer in
qemu when using -blockdev. Since we will keep these per-disk (as opposed
to per storage source) we need to store the appropriate node names in
the disk definition.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To allow referring to the drives via the QOM id we need to setup the
floppy drives with a proper ID. This means that -device should be used
for them.
There are the following quirks:
- FDC needs to be instantiated prior to any floppy device
- floppy drive specified via -device does not support 'bootindex'
(hacked around by passing bootindexA=1 to the FDC)
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When we stop using -drive qemu stops reporting it in some of the monitor
commands. To allow referring the disk frontends and the corresponding
block backends we need to know these names. Unfortunately different
buses require different names.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When using -blockdev you need to use the qom path to refer to the disk
fronends. Add means for storing the path and getting it after restart.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the index stored in virStorageSource struct rather than
recalculating it. Currently we'd report proper numbers but that will
change with blockdev.
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>
The capability currently is not enabled so that we can add individual
bits first.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It should be impossible to lack an alias in the domain definition. Other
disk types don't generate it so remove it here as well.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'device' field reported by 'query-block' is empty when -blockdev is
used. Add an argument which will allow matching disk by using the qdev
id so we can use this code with -blockdev.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'device' argument matches only the legacy drive alias. For blockdev
we need to set the throttling for a QOM id and thus we'll need to use
the 'id' field.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The wrapper executes the command and does error detection so there's no
need to open-code all of those things.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Move the preparation steps from qemuDomainAttachDiskGeneric up into
qemuDomainAttachDeviceDiskLive so that also media changing can use the
prepared file.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use qemuDomainAttachDeviceDiskLive to change the media in
qemuDomainChangeDiskLive as the former function already does all the
necessary steps to prepare the new medium.
This also allows us to turn qemuDomainChangeEjectableMedia static.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Turns out that 'query-nodes' is not what we want and the
'query-blockstats' command was in fact buggy. Revert the new field since
it's not needed.
This reverts commit 50edca1331.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We don't use it for anything useful so it does not make much sense to
extract it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU supports 'block_resize' since 0.14 so we don't need to do explicit
checking. Additionally the caller did not use the different value at
all.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove the pointless "empty path" check and use a better error message
if the disk was not found.
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>
Since we're not saving the platform-specific data into a cache, we're
not going to populate the structure, which in turn will cause a crash
upon calling virNodeGetSEVInfo because of a NULL pointer dereference.
Ultimately, we should start caching this data along with host-specific
capabilities like NUMA and SELinux stuff into a separate cache, but for
the time being, this is a semi-proper fix for a potential crash.
Backtrace (requires libvirtd restart to load qemu caps from cache):
#0 qemuGetSEVInfoToParams
#1 qemuNodeGetSEVInfo
#2 virNodeGetSEVInfo
#3 remoteDispatchNodeGetSevInfo
#4 remoteDispatchNodeGetSevInfoHelper
#5 virNetServerProgramDispatchCall
#6 virNetServerProgramDispatch
#7 virNetServerProcessMsg
#8 virNetServerHandleJob
#9 virThreadPoolWorker
#10 virThreadHelper
https: //bugzilla.redhat.com/show_bug.cgi?id=1612009
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
So the procedure to detect SEV support works like this:
1) we detect that sev-guest is among the QOM types and set the cap flag
2) we probe the monitor for SEV support
- this is tricky, because QEMU with compiled SEV support will always
report -object sev-guest and query-sev-capabilities command, that
however doesn't mean SEV is supported
3) depending on what the monitor returned, we either keep or clear the
capability flag for SEV
Commit a349c6c21c added an explicit check for "GenericError" in the
monitor reply to prevent libvirtd to spam logs about missing
'query-sev-capabilities' command. At the same time though, it returned
success in this case which means that we didn't clear the capability
flag afterwards and happily formatted SEV into qemuCaps. Therefore,
adjust all the relevant callers to handle -1 on errors, 0 on SEV being
unsupported and 1 on SEV being supported.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Keep with the recent effort of replacing as many explicit *Free
functions with their automatic equivalents.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
commit 5c81c342a7 forgot to skip the detaching of the shmem backend
when async unplug is requested which meant that we've tried to unplug
the backend prior to delivery of the DEVICE_DELETED event.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1618622
Signed-off-by: Peter Krempa <pkrempa@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>
There are some path where the buffer is not passed to
virCommandAddArgBuffer and therefore the buffer might leak.
==191201== 1,010 bytes in 1 blocks are definitely lost in loss record 826 of 836
==191201== at 0x4C2CE3F: malloc (vg_replace_malloc.c:298)
==191201== by 0x4C2F1BF: realloc (vg_replace_malloc.c:785)
==191201== by 0x5D39E82: virReallocN (viralloc.c:245)
==191201== by 0x5D3E8F2: virBufferGrow (virbuffer.c:150)
==191201== by 0x5D3E9C8: virBufferAdd (virbuffer.c:185)
==191201== by 0x56EAC98: qemuBuildFloppyCommandLineControllerOptions (qemu_command.c:2162)
==191201== by 0x56EB3E1: qemuBuildDisksCommandLine (qemu_command.c:2370)
==191201== by 0x570055E: qemuBuildCommandLine (qemu_command.c:10315)
==191201== by 0x575EA7F: qemuProcessCreatePretendCmd (qemu_process.c:6777)
==191201== by 0x113DAB: testCompareXMLToArgv (qemuxml2argvtest.c:598)
==191201== by 0x13A75B: virTestRun (testutils.c:180)
==191201== by 0x138BE8: mymain (qemuxml2argvtest.c:2975)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@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>
If a domain has hugepages configured and we're currently building
memory-backend-file for a nvdimm device that domain has we will
put hugepages path onto the command line. It should have been
nvdimm path configured in the XML.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
This reverts commit 9cf38263d0.
Jansson cannot parse QEMU's quirky JSON.
Revert back to yajl.
https://bugzilla.redhat.com/show_bug.cgi?id=1614569
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When a domain is killed on the source host while it is being migrated
and libvirtd is waiting for the migration to finish (waiting for the
domain condition in qemuMigrationSrcWaitForCompletion), the run-time
state including priv->job.current may already be freed once
virDomainObjWait returns with -1. Thus the priv->job.current pointer
cached in jobInfo is no longer valid and setting jobInfo->status may
crash the daemon.
https://bugzilla.redhat.com/show_bug.cgi?id=1593137
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We can safely validate the hugepage nodeset attribute at a define time.
This validation is not done for already existing domains when the daemon
is restarted.
All the changes to the tests are necessary because we move the error
from domain start into XML parse.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Starting from pc-q35-2.4 the floppy controller is not enabled by
default. Fix the version check so that it does not match 2.11 as being
2.1.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Fix regression introduced in <42fd5a58adb>. With q35 machine type which
requires the explicitly specified FDC we'd format twoisa-fdc
controllers to the command line as the code was moved to a place where
it's called per-disk.
Move the call back after formatting all disks and reiterate the disks to
find the floppy controllers.
This also moves the '-global' directive which sets up the default
ISA-FDC to the end after all the disks but since we are modifying the
properties it is safe to do so.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that the argument is unused we can remove it transitively from all
the call graphs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The capability was never set except for (stale) tests. Remove it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The field was added in qemu v0.13.0-rc0-731-g1ca4d09ae0 so all supported
qemu versions now use it.
There's a LOT of test fallout as we did not use capabilities close
enough to upstream for many of our tests.
Several tests had a 'bootindex' variant. Since they'd become redundant
they are also removed here.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The rest of blkiotune parameters are not updatable through UpdateDeviceFlags API.
https://bugzilla.redhat.com/show_bug.cgi?id=1601677
Signed-off-by: Katerina Koukiou <kkoukiou@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It is increasingly likely that some distro is going to change the
default "x86" machine type in QEMU from "pc" to "q35". This will
certainly break existing applications which write their XML on the
assumption that it is using a "pc" machine by default. For example they'll
lack a IDE CDROM and get PCIe instead of PCI which changes the topology
radically.
Libvirt promises to isolate applications from hypervisor changes that
may cause incompatibilities, so we must ensure that we always use the
"pc" machine type if it is available. Only use QEMU's own reported
default machine type if "pc" does not exist.
This issue is not x86-only, other arches are liable to change their
default machine, while some arches don't report any default at all
causing libvirt to pick the first machine in the list. Thus to
guarantee stability to applications, declare a preferred default
machine for all architectures we currently support with QEMU.
Note this change assumes there will always be a "pc" alias as long as a
versioned "pc-XXX" machine type exists. If QEMU were to ship a "pc-XXX"
machine type but not provide the "pc" alias, it is too hard to decide
which to default so. Versioned machine types are supposed to be
considered opaque strings, so we can't apply any sensible ordering
ourselves and QEMU isn't reporting the list of machines in any sensible
ordering itself.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
commit 8d9ca6cdb3 refactored qemuMonitorJSONBlockStatsCollectData so
that the number of stats is passed back via a pointer. The commit failed
to fix the macro which increments the number of stats to increment the
actual pointee.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Commit d48813e8 made sure we wouldn't get one for i440fx, but not for Q35
machine type. If the primary video didn't get the assumed 0:0:1.0 PCI
address, the evaluation then failed with: "Cannot automatically add a
new PCI bus for a device with connect flags 00"
https://bugzilla.redhat.com/show_bug.cgi?id=1609087
Signed-off-by: Erik Skultety <eskultet@redhat.com>
This reverts commit 0f80c71822.
Turns out, our code relies on virCgroupFree(&var) setting
var = NULL.
Conflicts:
src/util/vircgroup.c: context because 94f1855f09 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>
In dbf990fd31 the qemuMonitorJSONBlockStatsUpdateCapacityOne()
was split. However, due to a bug the return value was never set
to something meaningful.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@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 8e2982b576
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>
https://bugzilla.redhat.com/show_bug.cgi?id=1559867
When attaching a device to the domain we need to be sure
to use the correct domain definition (vm->def or vm->newDef)
when calling virDomainDeviceDefParse because the post parse
processing algorithms that may assign an address for the
device will use whatever domain definition was passed in.
Additionally, some devices (SCSI hostdev and SCSI disk) use
algorithms that rely on knowing what already exists of the
other type when generating the new device's address. Using
the wrong VM definition could result in duplicated addresses.
In the case of the bz, two hostdev's with no domain address
provided were added to the running domain's config only.
However, the parsing algorithm used the live domain in
order to figure out the host device address resulting in
the same address being used and a subsequent start failing
due to duplicate address.
Fix this by separating the checks/code into CONFIG and LIVE
processing using the correct definition for each block and
performing cleanup for both options as necessary.
Signed-off-by: John Ferlan <jferlan@redhat.com>
ACKed-by: Michal Privoznik <mprivozn@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>
https://bugzilla.redhat.com/show_bug.cgi?id=1589115
When doing a memory snapshot qemuOpenFile() is used. This means
that the file where memory is saved is firstly attempted to be
created under root:root (because that's what libvirtd is running
under) and if this fails the second attempt is done under
domain's uid:gid. This does not make much sense - qemu is given
opened FD so it does not need to access the file. Moreover, if
dynamicOwnership is set in qemu.conf and the file lives on a
squashed NFS this is deadly combination and very likely to fail.
The fix consists of using:
qemuOpenFileAs(fallback_uid = cfg->user,
fallback_gid = cfg->group,
dynamicOwnership = false)
In other words, dynamicOwnership is turned off for memory
snapshot (chown() will still be attempted if the file does not
live on NFS) and instead of using domain DAC label, configured
user:group is set as fallback.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
If we'd fail to enter or exit the monitor the saved error would be
leaked. Introduced in 8498a1e222 .
Pointed out by coverity.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Currently, the functions return a pointer to the
destination buffer on success or NULL on failure.
Not only does this kind of error handling look quite
alien in the context of libvirt, where most functions
return zero on success and a negative int on failure,
but it's also somewhat pointless because unless there's
been a failure the returned pointer will be the same
one passed in by the user, thus offering no additional
value.
Change the functions so that they return an int
instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Now that we have a saner replacement for checking if the disk source is
the same use it instead of formatting qemu command-line chunks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code is useful also when gathering statistics per node name, so
extract it to a separate functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The 'query-blockstats' command does not return statistics for the
explicitly named nodes unless the new argument is specified. Add
infrastrucuture that will allow us to use the new approach if desired.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use the proper backend for the block device both when using -drive and
when -blockdev will be used for disk drives and floppy disks.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The disk backend alias was historically the alias of the -drive backing
the storage. For setups with -blockdev this will become more complex as
it will depend on other configs and generally will differ.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@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>
Allow updating capacity for the block devices returned by
qemuDomainBlocksStatsGather and replace the open-coded call to
qemuMonitorGetAllBlockStatsInfo by the helper.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When changing cdrom media we did not handle the managed PR objects thus
we'd either have a stale PR object left behind or the media change would
fail.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Remove the issue of the monitor command to the caller so that the
function can be used with the modern approach.
Additionally improve the error message.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Prepare for the -blockdev implementation of ejectable media changing by
splitting up the old bits.
Additionally since both callers make sure that the device is a cdrom or
floppy the check is no longer necessary.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to qemuDomainDiskRemoveManagedPR make it enter monitor on
its own so that it can be reused. Future users will be in the snapshot
code and in removable media change code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Extract the (possible) removal of the PR backend and daemon into a
separate helper which enters monitor on its own. This simplifies the
code and allows reuse of this function in the future e.g. for blockjobs
where removing a image with PR may result into PR not being necessary.
Since the PR is not used often the overhead of entering monitor again
should be negligible.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add code which will convert a disk definition into
qemuHotplugDiskSourceData and then reuse qemuHotplugDiskSourceRemove to
remove all the backend related objects.
This unifies the detach code as much as possible with the already
existing helpers and will allow reuse this infrastructure when changing
removable disk media.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuDomainRemoveDiskDevice would leak the disk to be removed if the VM
crashed since it was removed from the definition but not freed.
Broken in commit 105bcdde76 which moved the removal from the definition
earlier.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similarly to how we've intergrated data belonging to a single
virStorageSource for purposes of attaching it to a qemu instance we will
need to agregate data relevant for the whole disk. With blockdev there
will be some disk-wide backing chain members such as the copy-on-read
handler.
Introduce qemuHotplugDiskSourceData which agregates the backing chain
and other data relevant for the disk and functions which generate it
and apply and rollback it.
In addition to disk hotplug this will also be reused for media changing
where we need to exchange the full disk backend.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The warning messages which include the disk source could potentially
format NULL using %s as virDomainDiskGetSource may return NULL for e.g.
NBD disks. As most of the APIs are NOOP for remote disks the usage of
the source string only should be fine for now.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that there's only one use of it, replace it directly by the code
filling it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemuHotplugPrepareDiskAccess can be used to tear down disk access so we
can replace the open-coded version collecting the same function calls.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
