Commit 39015a6f3 modified the test to be more reliable/realistic,
but without checking the return status of virEventRunDefaultImpl
it's possible that the test could run infinitely.
Found by Coverity
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 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>
All backingStore XML definitions have a XML tag with the timestamp. This
timestamp is not defined insinde RNG volume storage schema and it is
causing some problems to validate and check volume XMLs.
https://bugzilla.redhat.com/show_bug.cgi?id=1594266
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
When libvirtd is started, initialize domain objects state with its real
state, not only RUNNING/SHUTOFF.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Replace the long dead 'xenner' with 'xenfv'.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.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>
Attempting to use a chardev definition like
<serial type='unix'>
<target type='isa-serial'/>
</serial>
correctly results in an error being reported, since the source
path - a required piece of information - is missing; however,
the very similar
<serial type='unix'>
<target type='pci-serial'/>
</serial>
was happily accepted by libvirt, only to result in libvirtd
crashing as soon as the guest was started.
The issue was caused by checking the chardev's targetType
against whitelisted values from virDomainChrChannelTargetType
without first checking the chardev's deviceType to make sure
it is actually a channel, for which the check makes sense,
rather than a different type of chardev.
The only reason this wasn't spotted earlier is that the
whitelisted values just so happen to correspond to USB and
PCI serial devices and Xen and UML consoles respectively,
all of which are fairly uncommon.
https://bugzilla.redhat.com/show_bug.cgi?id=1609720
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since its introduction in commit 2e37bf42 the naming of the arguments
between the prototype and the definition does not match.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
To add CMT/MBM feature and let code be consistent in later patches,
renaming variable name from 'controlBuf' to 'childrenBuf', locates
in functions 'virCapabilitiesFormatCaches' and
'virCapabilitiesFormatMemoryBandwidth'.
Signed-off-by: Wang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
nlmsg_append from the libnl library provides exactly the same
functionality, so we should rely on that instead. This also allows us to
drop the aforementioned function completely.
Signed-off-by: Shi Lei <shi_lei@massclouds.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
@resp is allocated by virNetlinkCommand and the caller is responsible
for freeing the buffer. Since we already converted this module to use
VIR_AUTO{FREE,PTR} macros, let's resolve the problem by using them.
Signed-off-by: Shi Lei <shi_lei@massclouds.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
These two functions (virSecurityDACSetOwnership and
virSecurityDACRestoreFileLabelInternal) do not really change
@src. Make it const.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This function is going call security manager APIs and therefore
it needs pointer to it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This function is going call security manager APIs and therefore
it needs pointer to it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@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>
https://bugzilla.redhat.com/show_bug.cgi?id=1608275
Instantiation of an nwfilter binding is only allowed when
the net->filter is defined for the network; however, the
teardown of the binding does not make this check. This
leaves open the possibility that the teardown could be
called during guest shutdown/teardown in session mode
resulting in the following error being logged:
error : nwfilterConnectOpen:383 : internal error: unexpected
nwfilter URI path '/session', try nwfilter:///system
So before going through the teardown processing, let's
be sure the network had a filter and then attempt to
get a connection. For session mode it's not even possible
create an nwfilter binding.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Similar to nwfilterDefineXML, let's be sure the a filter binding
creation is not attempted in session mode and generate the proper
error message.
Failure to open nwfilter in session mode (nwfilterConnectOpen)
fails already, but that doesn't stop the free thinker from using
a different connection in order to attempt to attempt to create
the binding. Although even doing that would result in a failure:
$ virsh nwfilter-binding-create QEMUGuest1-binding.xml
error: Failed to create network filter from QEMUGuest1-binding.xml
error: internal error: Could not get access to ACL tech driver 'ebiptables'
$
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@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>
A few qemuxml2xml tests for virtio-input devices are
missing the capabilities used for the corresponding
qemuxml2argv tests: this wasn't a problem until now
because capabilities were only checked at command line
generation time, but we're going to change that later.
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>
QEMU-GA supports get geust hostname command. This commit includes a
specific entry to inform this new feature for QEMU driver to 4.8.0
release.
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 new tests use DO_TEST_CAPS_ARCH_LATEST() with an input
XML describing a very simple headless guest and cover most
architectures and machine types we care about.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We can add aarch64, ppc64 and riscv64 to the list of
supported architectures for the macro, since we have
capabilities data for all of them.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virtio-serial is an alias for virtio-serial-pci, which
should not have been used for a PCIe-less aarch64/virt
guest but it ended up being used anyway because the
virtio-mmio capability was missing and the algorithm
is buggy.
Fix the test case so that we can fix the algorithm next.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There's a single user for it which takes an existing
virPCIDeviceAddress, passes its various bits to the
function which in turn constructs a virPCIDevice and
then copies the string representation for the caller
to use: we can use virPCIDeviceAddressAsString()
instead and avoid creating the virPCIDevice in the
first place. Since the function ends up having no
users after the change, we can just drop it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@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>
This will help in future expansions of the code when it is be
harder to track if @newName and/or @newLockspace were already
allocated or not and thus whether it is safe to 'return' or we
need to 'goto error'. By using the 'cleanup' label those two
cases merge into a single one.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
If drvNew callback fails, nobody calls drvFree and thus private
data of the driver might leak.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
