This is a v2 of:
https://listman.redhat.com/archives/libvir-list/2023-June/240351.html
Hopefully, I've implemented all Dan's suggestions.
Michal Prívozník (5):
virfile: Introduce virCloseRange()
virfile: Introduce virCloseFrom()
vircommand: Unify mass FD closing
vircommand: Introduce
It is handy to close all FDs from given FD to infinity. On
FreeBSD the libc even has a function for that: closefrom(). It
was ported to glibc too, but not musl. At least glibc
implementation falls back to calling:
close_range(from, ~0U, 0);
Now that we have a wrapper for close_range() we
The whole purpose of virCloseRangeInit() is to be called
somewhere during initialization (ideally before first virExec()
or virCommandRun()), so that the rest of the code already knows
kernel capabilities. While I can put the call somewhere into
remote_daemon.c (when a daemon initializes), we
We have two version of mass FD closing: one for FreeBSD (because
it has closefrom()) and the other for everything else. But now
that we have closefrom() wrapper even for Linux, we can unify
these two.
Signed-off-by: Michal Privoznik
---
src/util/vircommand.c | 85
This is brand new way of closing FDs before exec(). We need to
close all FDs except those we want to explicitly pass to avoid
leaking FDs into the child. Historically, we've done this by
either iterating over all opened FDs and closing them one by one
(or preserving them), or by iterating over an
Linux gained new close_range() syscall (in v5.9) that allows
closing a range of FDs in a single syscall. Ideally, we would use
it to close FDs when spawning a process (e.g. via virCommand
module).
Glibc has close_range() wrapper over the syscall, which falls
back to iterative closing of all FDs
On Mon, Aug 14, 2023 at 11:35:52 +0200, Pavel Hrdina wrote:
> This implements virDomainRevertToSnapshot to work with external
> snapshots. In addition it modifies virDomainSnapshotDelete to work
> correctly when we revert to non-leaf snapshot or when there is
> non-linear snapshot tree with
On Thu, Jul 20, 2023 at 17:20:02 -0500, Jonathon Jongsma wrote:
> When running libvirt from the build directory with the 'run' script, it
> will run as unconfined_t. This can result in unexpected behavior when
> selinux is enforcing due to the fact that the selinux policies are
> written assuming
On Thu, Jul 20, 2023 at 17:20:03 -0500, Jonathon Jongsma wrote:
> Require libnbd-devel when building the qemu driver, recommend nbdkit
> packages.
>
> Signed-off-by: Jonathon Jongsma
> ---
> libvirt.spec.in | 8
> 1 file changed, 8 insertions(+)
Reviewed-by: Peter Krempa
Since commit baca59a5384 the NUMA definition is automatically fixed if
the vCPU count mismatches the NUMA cpu count so that this warning will
never be triggered.
Additionally VIR_WARN of a misconfiguration of a VM would not really
be seen in most cases as it's only simply logged.
Signed-off-by:
On Mon, Aug 21, 2023 at 15:16:54 +0100, Daniel P. Berrangé wrote:
> On Mon, Aug 21, 2023 at 02:57:09PM +0200, Ján Tomko wrote:
> > On a Thursday in 2023, Peter Krempa wrote:
> > > VIR_WARN of a misconfiguration of a VM is not really going to be seen in
> > > most cases as it's simply logged, and
On Tue, Aug 22, 2023 at 01:26:47PM +0200, Erik Skultety wrote:
> On Mon, Aug 21, 2023 at 10:32:42AM +0200, Michal Prívozník wrote:
> > It's been a while since libvirt-snmp was actively developed. Now it
> > receives only libvirt-ci related commits. The code compiles with
> > net-snmp-5.9.3 but the
On Mon, Aug 21, 2023 at 10:32:42AM +0200, Michal Prívozník wrote:
> It's been a while since libvirt-snmp was actively developed. Now it
> receives only libvirt-ci related commits. The code compiles with
> net-snmp-5.9.3 but the freshly released net-snmp-5.9.4 [1] breaks
> compilation [2]. Now,
On Tue, Aug 22, 2023 at 11:46:43AM +0200, Erik Skultety wrote:
> Each respective project that lcitool knows about and currently
> maintains its list of package dependencies knows best what packages
> they actually depend on. If a new dependency is currently needed, first
> a change in lcitool is
Each respective project that lcitool knows about and currently
maintains its list of package dependencies knows best what packages
they actually depend on. If a new dependency is currently needed, first
a change in lcitool is necessary before GitLab jobs and containers can
be updated. Provided a
15 matches
Mail list logo
