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>
