Some rewording and rewraping was needed to accomodate the new local
references.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The surrounding paragraph around the only fixed use was rewrapped.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The one local link addition prompted rewrapping of the whole paragraph.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All local links were reformulated to make sense with local references.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Two paragraphs containing local links were reformulated and rewrapped.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Make sure that more users understand that without HW virtualization you cannot
have KVM working.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2086677
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are two functions declared in qemu_capspriv.h:
1) virQEMUCapsInitHostCPUModel() which is not used anywhere but
qemu_capabilities.c,
2) virQEMUCapsSetSEVCapabilities() which is my personal favorite
but despite that it's never implemented nor called.
Drop them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
We already allow users to provide TFTP root path in network XML
and not specify any DHCP. This makes sense, because dnsmasq is
not only DHCP server but also TFTP server and users might have
a DHCP server configured on their own, outside of libvirt's
control and want just the TFTP part.
By moving TFTP config generator out of DHCP generator and calling
it for every IPv4 range, users can finally enable just TFTP.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2026765
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Generating configuration file for dnsmasq is done in
networkDnsmasqConfContents() which is this big, self-contained
function. Separate at least DHCP part into its own function for
better readability.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In networkDnsmasqConfContents() there's a for() loop which
initializes some variables in its initialization block. This
makes both the loop() statement and variable declaration block
look needlessly ugly. Speaking of variable declaration, also move
some variables which are used only within blocks into their
respective blocks.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The virDomainObj struct has @pid member where the domain's
hypervisor PID is stored (e.g. QEMU/bhyve/libvirt_lxc/... PID).
However, we are not consistent when it comes to shutoff state.
Initially, because virDomainObjNew() uses g_new0() the @pid is
initialized to 0. But when domain is shut off, some functions set
it to -1 (virBhyveProcessStop, virCHProcessStop, qemuProcessStop,
..).
In other places, the @pid is tested to be 0, on some other places
it's tested for being negative and in the rest for being
positive.
To solve this inconsistency we can stick with either value, -1 or
0. I've chosen the latter as it's safer IMO. For instance if by
mistake we'd kill(vm->pid, SIGTERM) we would kill ourselves
instead of init's process group.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
We currently build cross-arch containers for all three Debian
releases (10, 11, Sid), and do libvirt builds covering each
arch. This is overkill in terms of the number of problems it
identifies. The most important aspect of cross arch builds is
to find problems with 32-bit builds and problems with big
endian builds.
With this in mind the cross arch jobs are altered as follows
- Debian 10
- build the containers by default
- build armv7 (32-bit) & s390x (big endian)
- other arch builds manual
- Debian 11 / Sid
- container builds all optional
- arch builds all optional
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
We currently build on Ubuntu 22.04 twice, for GCC and CLang
with santizers turned on. Moving the GCC santizers build
to 20.04 lets us cull one of the 22.04 jobs
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Currently we do native builds on all distros that are covered
by the support matrix. This reduces that such that we mostly
only run builds on the newest (ie bleeding edge non-released)
version and the oldest version. The effect is that cut out
builds on the newest release version. This is acceptable,
because that version is sandwiched between two versions we
do still test, so unlikely to have failures not already
identified by other jobs.
This has the effect of disabling:
- AlmaLinux 8 GCC - still has a CLang build
and CentOS 8 Stream also gives coverage
- Debian 11 - still has a Debian 10 and Sid
build
- Alpine 3.15 - still has a Alpine 3.14 and Edge
build
Ideally Fedora 35 would be disabled too, but we rely on that
for the integration tests.
The Ubuntu jobs will be handled in the next patch.
The containers are still built since this is cheap-ish.
The build jobs can also be triggered manually if desired.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This refreshes the containers bringing in new behaviour when
builds/containers are disabled.
Instead of deleting the job entirely, the job still exists
but is set to be a manual job. It won't affect the pipeline
result, but can be triggered by the developer if they wish
to test a specific scenario.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
