I added new driver functions to handle creating network with
given flags. I also replaced definitions of the functions without
flags with function calls to the new ones.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This new API creates network with given flags.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The ACPI index of a device in a running guest can't be modified, and
libvirt doesn't actually attempt to modify it, but it was possible for
a user to request such a modification, and libvirt wouldn't complain,
thus misleading the user into thinking that it had actually been changed.
Resolves: https://bugzilla.redhat.com/1998920
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The next patch will add another check similar to the existing check
for a change in alias name. This patch reformats the code in
preparation so that the next patch's purpose will be clear.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
I think these functions look much more readable with just simple
if conditions.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Rename the temp variable that is being returned and use automatic
pointer clearing for it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
In case the specific VCPU states are not present in the XML we were
taking a fallback code path just noting that all cpus of the VM are
enabled.
This was broken by a mistake in a recent refactor where a 'goto cleanup'
was mistakenly replaced by a 'return NULL'. This broke reporting of cpus
and also caused a memory leak.
Return the fallback cpu map.
Fixes: bd1f40fe7d
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2004429
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
In fact keeping the VM around for debugging is a desirable configuration
and actually the implementation has no code as we keep the VM around.
Remove the validation and add a note that it's actually used.
Fixes: b1b85a475f
Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
These are no longer referenced by any existing test as of:
os-firmware-invalid-type -> a9b1375d7d
tseg-explicit-size -> 604990a175
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Launch swtpm(8) with the --terminate switch, which guarantees that
the daemon will shut itself down when QEMU dies (current behavior).
We had so far been getting this "for free" (i.e. without --terminate)
due to a defect in upstream's connection handling logic [1], on which
libvirt should not rely since it will eventually be fixed. Adding
--terminate preserves and guarantees the current behavior.
[1] https://github.com/stefanberger/swtpm/pull/509
Signed-off-by: Nick Chevsky <nchevsky@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The array of virtual functions @vfs in
virNodeDeviceGetPCISRIOVCaps() is allocated twice: the first time
during its declaration and the second time inside
virPCIGetVirtualFunctions() which leads to a memleak:
==16691== 1,128 bytes in 47 blocks are definitely lost in loss record 1,771 of 1,803
==16691== at 0x4844CC1: calloc (vg_replace_malloc.c:1117)
==16691== by 0x4E50070: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6800.3)
==16691== by 0x4A7B034: virNodeDeviceGetPCISRIOVCaps (node_device_conf.c:2649)
==16691== by 0x4A7B5E2: virNodeDeviceGetPCIDynamicCaps (node_device_conf.c:2762)
==16691== by 0xA7F6E18: udevProcessPCI (node_device_udev.c:418)
Fixes: c97518d9b8
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When documenting our public API in some places we use '@' to
refer to the variable. For instance:
* This API tries to set guest time to the given value. The time
* to set (@seconds and @nseconds) should be in seconds relative
* to the Epoch of 1970-01-01 00:00:00 in UTC.
However, when generating HTML documentation these tokens are
copied verbatim. What we can do is drop the '@' character and
wrap the variable in <code/> so that it is formatted properly.
Due to the way we 'parse' docs a token might actually be slightly
more than just '@variable'. For instance in the example above we
will have the following tokens: '(@seconds' and '@nseconds)'.
Thus we need to handle possible substring before and after
variable.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is currently the only way to view the 'autostart' property for a
node device in virsh.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Implement these new API functions in the nodedev driver.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
These two public APIs are implemented for almost all other objects that
have a concept of persistent definition and activatability. Now that we
have node devices (mdevs) that can be defined and inactive, it will be
useful to query the persistent/active state of node devices as well.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add ability to set node devices to autostart on boot or parent device
availability.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This will allow persistent mediated devices to be configured to be
restarted automatically when the host reboots.
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When libxlAutostartDomain was introduced with commit fb92307f0d, one hunk
mistakenly added a call site in libxlStateReload. Domains should not be
autostarted when reloading the driver, so remove the offending hunk.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
On reload, the libxl driver calls virDomainObjListLoadAllConfigs to load
all configs from /etc/libvirt/libxl/ but incorrectly passes 'true' for
the liveStatus parameter, resulting in error messages such as
libvirtd[21053]: XML error: unexpected root element <domain>, expecting <domstatus>
libvirtd[21053]: Failed to load config for domain 'sles15sp3'
Fix by not requesting live status when re-reading the persistent VM config
files.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
On Xen, libvirt runs in a VM (typically dom0) and does not have an accurate
picture of numa and cpu topology of the underlying physical machine using
the "usual" mechanisms. numa info and cpu toplogy are retrieved from libxl
and used to populate the libvirt conterparts. Commit 7b79ee2f78 introduced
support for reporting die_id in capabilities, but did not account for
special handling of numa and cpu topology in libxl.
Currently, Xen does not report die_id in the libxl_cputopology structure.
In the meantime, set die_id to 0, which was suggested by the Xen developers
and is slightly better than random garbage such as
<cpu id='1' socket_id='0' die_id='-1073069552' core_id='0' siblings='0-1'/>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The armv7l and ppc64le cross-builds as well as the Clang build
are adopted from Debian 10, while the mips64el build is adopted
from Debian sid. As always, the way jobs are distributed across
Debian versions is fairly arbitrary.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The value 3 is the length of the "ci-" prefix, which is present
in the items returned by get_registry_images() but not in those
returned by get_dockerfiles().
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Beraldo Leal <bleal@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
These were removed along with the outdated information on how
to regenerate the Dockerfiles contained in the repository, but
this part is still relevant.
Reverts: 30856d2865 (partially)
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In the example for <memory model='dimm'/> we show how to
configure hugepages as backend. In the example we show 4MiB
hugepages which are non-standard and thus at the first glance may
mislead users thinking that a regular sized pages (4K) will be
used. Use 2MiB as the value instead.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We don't need to propagate all public flags, only the information
about the presence of the validation one, which can differ from
function to function. This patch makes it easier and more
readable in case of a future additions of validation flags.
This change was suggested by Daniel.
Signed-off-by: Kristina Hanicova <khanicov@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We don't support all startup policies with all source types so to
correctly allow switching from a 'file' based cdrom with 'optional'
startup policy to a 'block' based one which doesn't support optional we
must update the startup policy field first. Obviously we need to have
fallback if the update fails.
Reported-by: Vojtech Juranek <vjuranek@redhat.com>
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
'-qmp' in this case behaves the same as '-chardev' so it should have
been converted the same way as others were in 43c9c0859f since
short options are deprecated.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We now use lcitool's manifest feature to generate files. The logic
for checking for stale containers in the registry, however, is still
relevant so that is propagated to a standalone command.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We now use lcitool's manifest feature to generate files.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This uses the command "lcitool manifest ci/manifest.yml" to re-generate
all existing dockerfiles and gitlab CI config.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The sanitizer jobs run in ubuntu 20.04 containers and thus overlap with
testing already done for the regular ubuntu 20.04 build job. Fold the
sanitizer run for GCC into the regular build job and add a second
ubuntu 20.04 build job for CLang sanitizers.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
It was in the build stage previously to let it run in parallel with
other build jobs, but with the "needs" clause this is not required.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In the documentation to virDomainAttachDevice() we refer to a
non-existent virDomainUpdateDeviceFlag() function. The correct
name is virDomainUpdateDeviceFlags().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
