Create an integration child pipeline in this stage which will trigger a
multi-project CI build of Perl bindings which are required by the TCK
test suite.
In general, this stage will install all the necessary build artifacts
and configure logging on the worker node prior to executing the actual
Signed-off-by: Erik Skultety
---
ci/containers/centos-stream-9.Dockerfile | 87
ci/gitlab.yml| 14
ci/manifest.yml | 3 +
3 files changed, 104 insertions(+)
create mode 100644
The meson version provided by the package managing system satisfies our
minimum requirement.
Signed-off-by: Erik Skultety
---
ci/gitlab.yml | 1 -
ci/manifest.yml | 2 --
2 files changed, 3 deletions(-)
diff --git a/ci/gitlab.yml b/ci/gitlab.yml
index 120ece8fb7..8e27bca812 100644
---
We're already building libvirt in the containers already, if we publish
the build in form of, say, RPMs, later stages of the pipeline can
consume the RPMs instead of re-building libvirt from scratch.
Signed-off-by: Erik Skultety
---
.gitlab-ci.yml | 3 ++-
ci/gitlab.yml | 18
I'd like to propose a PoC of a GitLab-driven functional CI based on GitLab's
custom executor runner feature.
** TL;DR **
- there's some RH owned HW that can be utilized for upstream functional CI
running workloads on Red Hat-sponsored distros (see the pipeline)
- the PoC utilizes GitLab's
On 1/28/22 19:41, Ján Tomko wrote:
> Since its introduction in
> commit 907a39e735d256b8428ed4c77009d1f713aea19b
> Add a test suite for validating SELinux labelling
>
> this function did not return NULL on OOM.
>
> Since we abort on OOM now, switch testSELinuxMungePath to void,
> return NULL
On 1/28/22 20:19, Ján Tomko wrote:
> We still were checking for some that were introduced before Xen 4.9
>
> Ján Tomko (4):
> libxl: assume LIBXL_HAVE_DEVICE_BACKEND_DOMNAME
> libxl: remove LIBXL_ATTR_UNUSED
> libxl: assume LIBXL_HAVE_SRM_V2
> libxl: assume LIBXL_HAVE_PVUSB
>
>
On 1/28/22 21:26, Ján Tomko wrote:
> Instead of listing the sites that surely support HTTPS,
> list the ones that don't.
>
> Signed-off-by: Ján Tomko
> ---
> build-aux/syntax-check.mk | 66 ---
> 1 file changed, 54 insertions(+), 12 deletions(-)
>
> diff
On Mon, Jan 31, 2022 at 03:35:02PM +, Daniel P. Berrangé wrote:
> On Mon, Jan 31, 2022 at 04:21:36PM +0100, Kashyap Chamarthy wrote:
> > On Mon, Jan 31, 2022 at 02:36:46PM +, Daniel P. Berrangé wrote:
[...]
> > > The firmware can be provided in qcow2 format too, so if really
> > >
On Mon, Jan 31, 2022 at 04:21:36PM +0100, Kashyap Chamarthy wrote:
> On Mon, Jan 31, 2022 at 02:36:46PM +, Daniel P. Berrangé wrote:
> > On Mon, Jan 31, 2022 at 03:00:33PM +0100, Kashyap Chamarthy wrote:
> > > On Mon, Jan 31, 2022 at 12:55:09PM +, Daniel P. Berrangé wrote:
>
> [...]
>
>
On Mon, Jan 31, 2022 at 03:55:03PM +0100, Pavel Hrdina wrote:
> On Mon, Jan 31, 2022 at 03:45:18PM +0100, Michal Prívozník wrote:
> > On 1/31/22 15:38, Daniel P. Berrangé wrote:
> >
> > >
> > > Oh, I hadn't checked how number prioritization affects it. So you're
> > > saying that we stop parsing
On Mon, Jan 31, 2022 at 02:36:46PM +, Daniel P. Berrangé wrote:
> On Mon, Jan 31, 2022 at 03:00:33PM +0100, Kashyap Chamarthy wrote:
> > On Mon, Jan 31, 2022 at 12:55:09PM +, Daniel P. Berrangé wrote:
[...]
> > I briefly wondered if in this "combined" mode whether the no. of
> >
On Mon, Jan 31, 2022 at 03:45:18PM +0100, Michal Prívozník wrote:
> On 1/31/22 15:38, Daniel P. Berrangé wrote:
>
> >
> > Oh, I hadn't checked how number prioritization affects it. So you're
> > saying that we stop parsing the firmware file as soon as we find a
> > valid match. That does indeed
There are few places where the g_steal_pointer() is open coded.
Switch them to calling the g_steal_pointer() function instead.
Generated by the following spatch:
@ rule1 @
expression a, b;
@@
<...
- b = a;
... when != b
- a = NULL;
+ b = g_steal_pointer();
...>
There are a few places where a variable is VIR_FREE()-d and then
explicitly set to NULL. This is not necessary since VIR_FREE()
does that for us.
Signed-off-by: Michal Privoznik
---
src/conf/domain_conf.c| 1 -
src/conf/nwfilter_conf.c | 1 -
tests/virtypedparamtest.c | 1 -
3 files
In testDomainSetBlockIoTune() the info.group_name is strdup()-ed
and just after the whole @info structure is passed to
virDomainDiskSetBlockIOTune() the @group_name member is set to
NULL. This creates a memleak, because
virDomainDiskSetBlockIOTune() creates its own copy of the string.
Inside the testPCIVPDResourceCustomCompareIndex() function we
have two variables @a and @b, both marked as g_autoptr(). Then,
towards the end of the function b->value is freed and set to
a->value. This is to make sure
virPCIVPDResourceCustomCompareIndex() works correctly even if
->value member is
*** BLURB HERE ***
Michal Prívozník (4):
test_driver: Don't leak @group_name
lib: Don't set variable to NULL after VIR_FREE()
virpcivpdtest: Fix potential double-free()
src: Use g_steal_pointer() more
src/conf/domain_conf.c| 1 -
src/conf/nwfilter_conf.c |
On a Monday in 2022, Peter Krempa wrote:
On Mon, Jan 31, 2022 at 13:40:34 +0100, Ján Tomko wrote:
Any active domain has a copy in the privateData, filled in
qemuProcessInit.
Move the qemu capability check below the activeness check and remove
the extra lookup.
What's worse is that you can
On 1/31/22 15:38, Daniel P. Berrangé wrote:
>
> Oh, I hadn't checked how number prioritization affects it. So you're
> saying that we stop parsing the firmware file as soon as we find a
> valid match. That does indeed limit the impact of the change.
Ah, my memory is failing me. We don't do
On Mon, Jan 31, 2022 at 03:19:46PM +0100, Michal Prívozník wrote:
> On 1/31/22 14:18, Daniel P. Berrangé wrote:
> > On Mon, May 10, 2021 at 03:16:11PM +0200, Pavel Hrdina wrote:
> >> When QEMU introduces new firmware features libvirt will fail until we
> >> list that feature in our code as well
On Mon, Jan 31, 2022 at 03:00:33PM +0100, Kashyap Chamarthy wrote:
> On Mon, Jan 31, 2022 at 12:55:09PM +, Daniel P. Berrangé wrote:
> > The current firmware descriptor schema for flash requires that both the
> > executable to NVRAM template paths be provided. This is fine for the
> > most
On 1/31/22 14:18, Daniel P. Berrangé wrote:
> On Mon, May 10, 2021 at 03:16:11PM +0200, Pavel Hrdina wrote:
>> When QEMU introduces new firmware features libvirt will fail until we
>> list that feature in our code as well which doesn't sound right.
>>
>> We should simply ignore the new feature
On Mon, Jan 31, 2022 at 12:55:09PM +, Daniel P. Berrangé wrote:
> The current firmware descriptor schema for flash requires that both the
> executable to NVRAM template paths be provided. This is fine for the
> most common usage of EDK2 builds in virtualization where the separate
> _CODE and
On Mon, May 10, 2021 at 03:16:11PM +0200, Pavel Hrdina wrote:
> When QEMU introduces new firmware features libvirt will fail until we
> list that feature in our code as well which doesn't sound right.
>
> We should simply ignore the new feature until we add a proper support
> for it.
>
>
On Mon, Jan 31, 2022 at 14:06:38 +0100, Michal Prívozník wrote:
> On 1/31/22 13:36, Peter Krempa wrote:
> > Outline information commonly logged which users could consider
> > sensitive.
> >
> > Add a note that VNC/SPICE passwords are logged in plaintext.
> >
> > Signed-off-by: Peter Krempa
> >
On 1/31/22 13:36, Peter Krempa wrote:
> Outline information commonly logged which users could consider
> sensitive.
>
> Add a note that VNC/SPICE passwords are logged in plaintext.
>
> Signed-off-by: Peter Krempa
> ---
> docs/kbase/debuglogs.rst | 24
> 1 file changed,
The current firmware descriptor schema for flash requires that both the
executable to NVRAM template paths be provided. This is fine for the
most common usage of EDK2 builds in virtualization where the separate
_CODE and _VARS files are provided.
With confidential computing technology like AMD
On Mon, Jan 31, 2022 at 13:40:34 +0100, Ján Tomko wrote:
> Any active domain has a copy in the privateData, filled in
> qemuProcessInit.
>
> Move the qemu capability check below the activeness check and remove
> the extra lookup.
What's worse is that you can get caps for a different emulator
Any active domain has a copy in the privateData, filled in
qemuProcessInit.
Move the qemu capability check below the activeness check and remove
the extra lookup.
Signed-off-by: Ján Tomko
---
src/qemu/qemu_driver.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
Outline information commonly logged which users could consider
sensitive.
Add a note that VNC/SPICE passwords are logged in plaintext.
Signed-off-by: Peter Krempa
---
docs/kbase/debuglogs.rst | 24
1 file changed, 24 insertions(+)
diff --git a/docs/kbase/debuglogs.rst
When we are about to spawn QEMU, we validate the domain
definition against qemuCaps. Except when domain is/was already
running before (i.e. on incoming migration, snapshots, resume
from a file). However, especially on incoming migration it may
happen that the destination QEMU is different to the
On a Sunday in 2022, Laine Stump wrote:
On 1/27/22 4:33 PM, Ján Tomko wrote:
We used to validate that the first character of the hostname is a
letter. Later, RFC1123 relaxed the requirements to allow a number
as well.
Drop the validation completely, since we do not care about the
following
On Mon, Jan 31, 2022 at 3:12 PM Michal Privoznik wrote:
>
> Apparently, some of '&*variable' slipped in. Drop '&*' and access
> the variable directly.
>
> Signed-off-by: Michal Privoznik
Reviewed-by: Ani Sinha
> ---
> src/qemu/qemu_domain.c | 2 +-
> src/qemu/qemu_driver.c
On 1/31/22 11:01, Peter Krempa wrote:
> On Mon, Jan 31, 2022 at 10:42:28 +0100, Michal Privoznik wrote:
>> There is plenty of places where a domain XML is parsed using
>> VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE flag, but not all are
>> warranted. The flag usage is okay when parsing an XML produced by
On Mon, Jan 31, 2022 at 10:42:28 +0100, Michal Privoznik wrote:
> There is plenty of places where a domain XML is parsed using
> VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE flag, but not all are
> warranted. The flag usage is okay when parsing an XML produced by
> us (e.g. when copying virDomainDef). In
There is plenty of places where a domain XML is parsed using
VIR_DOMAIN_DEF_PARSE_SKIP_VALIDATE flag, but not all are
warranted. The flag usage is okay when parsing an XML produced by
us (e.g. when copying virDomainDef). In the rest of places
(especially when the XML might come from user) we need
Apparently, some of '&*variable' slipped in. Drop '&*' and access
the variable directly.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_domain.c | 2 +-
src/qemu/qemu_driver.c | 2 +-
src/qemu/qemu_migration_cookie.c | 2 +-
src/rpc/virnetclientstream.c | 8
Hey, ping here :)
Any thoughts or suggestions about the proposed patch series?
On 13/01/2022 13:42, Vasiliy Ulyanov wrote:
> v2 of
> https://listman.redhat.com/archives/libvir-list/2022-January/msg8.html
>
> The v2 series introduces the new approach following the previous review
>
39 matches
Mail list logo
