: Permission denied
The corresponding denial is
AVC apparmor="DENIED" operation="umount" profile="libvirtd"
name="/dev/" pid=70036 comm="rpc-libvirtd"
Extend the AppArmor configuration for virtqemud and libvirtd so
that this operation is a
Signed-off-by: Andrea Bolognani
---
Pushed as trivial.
docs/formatdomain.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 8fc8aeb928..f76c7c3d81 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -2703,7
making the
change visible in a very obvious way. We can then drop the master
branch for good after a Reasonable Amount of Time™ has passed.
At this point, most of the projects that I interact with outside of
the libvirt organization have switched away from having a "master"
branch, mostly adopting "main" as the new name. So making the change
would make things more consistent on my side, and I'm for it.
--
Andrea Bolognani / Red Hat / Virtualization
> the virtqemud systemd service file has a hard dependency on
> virtlogd.socket.
>
> Signed-off-by: Jim Fehlig
> ---
> libvirt.spec.in | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
Reviewed-by: Andrea Bolognani
--
Andrea Bolognani / Red Hat / Virtualization
3 files changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Andrea Bolognani
--
Andrea Bolognani / Red Hat / Virtualization
On Fri, Jan 13, 2023 at 07:05:36PM +0200, Andrea Bolognani wrote:
> Overall things look good. Let me actually test this a bit :)
Some quick testing (QEMU only) revealed no issues.
So I just need you to clarify the lxc virtlogd bit above and weigh in
on the other nits I mentioned, but otherwis
in the same way at that time.
It's true that you'll never not have virtlockd available if the
monolithic daemon is present, but still it's preferable to keep
things consistent.
Overall things look good. Let me actually test this a bit :)
--
Andrea Bolognani / Red Hat / Virtualization
ee to ignore this suggestion and leave things as they are :)
--
Andrea Bolognani / Red Hat / Virtualization
On Wed, Jan 11, 2023 at 02:11:13PM -0700, Jim Fehlig wrote:
> On 1/11/23 11:21, Andrea Bolognani wrote:
> > Should we keep relationship with virtlockd.socket for the time being,
> > turning it from a Requires to a Wants, and only drop it once we are
> > confident that the pres
On Thu, Jan 12, 2023 at 12:10:21PM +0800, Han Han wrote:
> Fixes: a677ea92
>
> Signed-off-by: Han Han
> ---
> docs/drvqemu.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Andrea Bolognani
and pushed.
--
Andrea Bolognani / Red Hat / Virtualization
On Wed, Jan 11, 2023 at 04:04:37PM +0100, Ján Tomko wrote:
> Signed-off-by: Ján Tomko
> ---
> NEWS.rst | 5 +
> 1 file changed, 5 insertions(+)
Reviewed-by: Andrea Bolognani
--
Andrea Bolognani / Red Hat / Virtualization
On Wed, Jan 11, 2023 at 05:35:01PM +, Daniel P. Berrangé wrote:
> On Wed, Jan 11, 2023 at 09:24:09AM -0800, Andrea Bolognani wrote:
> > Based on the fact that virtlogd is opt-out and virtlockd is opt-in,
> > can we leave the Requires=virtlogd.socket relationship alone and add
&
On Wed, Jan 11, 2023 at 04:42:49PM +, Daniel P. Berrangé wrote:
> On Wed, Jan 11, 2023 at 08:24:08AM -0800, Andrea Bolognani wrote:
> > I think we might need to weaken these relationship from Requires to
> > Wants, as that should still ensure that the corresponding sockets ar
hout making more specialized
ones (e.g. without virtlockd) impossible.
Similarly, I think we're missing Wants for virtstoraged.socket,
virtnetworkd.socket, virtsecretd.socket and so on.
Dan?
--
Andrea Bolognani / Red Hat / Virtualization
On Mon, Jan 09, 2023 at 09:49:04AM -0700, Jim Fehlig wrote:
> On 1/9/23 07:54, Andrea Bolognani wrote:
> > Jim, can you please respin while reverting these changes that I had
> > suggested? Sorry :(
>
> No problem, will send a V7. BTW, what is the list preference for su
irtlockd.
Okay, the fact that we're explicitly documenting these packages as
the "every possible feature for the driver" option means that I have
no choice but to agree with you :)
Jim, can you please respin while reverting these changes that I had
suggested? Sorry :(
--
Andrea Bolognani / Red Hat / Virtualization
On Mon, Jan 09, 2023 at 01:19:58PM +, Daniel P. Berrangé wrote:
> On Mon, Jan 02, 2023 at 10:26:13AM -0500, Andrea Bolognani wrote:
> > * storage locking is not the default behavior and needs to be
> > turned on explicitly, so it's not a big deal if part of the setup
&
On Thu, Jan 05, 2023 at 11:07:17AM -0700, Jim Fehlig wrote:
> Signed-off-by: Jim Fehlig
> ---
> NEWS.rst | 6 ++
> 1 file changed, 6 insertions(+)
Reviewed-by: Andrea Bolognani
Dan, can you please take one last look at the series, just to be on
the safe side? It would be a bi
On Thu, Jan 05, 2023 at 10:05:01AM -0700, Jim Fehlig wrote:
> On 1/4/23 02:14, Andrea Bolognani wrote:
> > On Tue, Jan 03, 2023 at 02:22:14PM -0700, Jim Fehlig wrote:
> > > Remove the libvirt-daemon dependency from the various
> > > libvirt-daemon- subpackag
ployments will be leaner, as storage locking support is no
longer included by default. This is consistent with the fact that
it always needed to be turned on manually after installation.
for completeness' sake.
Whether or not the commit message gets updated
Reviewed-by: Andrea Bolognani
Ideally yo
On Tue, Jan 03, 2023 at 10:57:21AM -0700, Jim Fehlig wrote:
> On 1/3/23 10:27, Jim Fehlig wrote:
> > On 1/2/23 08:26, Andrea Bolognani wrote:
> > > This version is fine, but as explained elsewhere I think it would be
> > > better to have
> > >
> > >
On Tue, Jan 03, 2023 at 10:07:45AM -0700, Jim Fehlig wrote:
> On 1/2/23 07:53, Andrea Bolognani wrote:
> > Remote clients can connect to modular daemons directly as long as
> > virt-ssh-helper is available on the server side. As a fallback, nc
> > will be used and the conne
happening in qemuBuildMemoryBackendProps(), which is skipped when
using mode=restrictive.
Make sure virNumaNodesetIsAvailable() is called whenever a
nodeset has been provided by the user, regardless of the mode.
https://bugzilla.redhat.com/show_bug.cgi?id=2156289
Signed-off-by: Andrea Bolognani
The one for mode=strict fails, as expected, while the one for
mode=restrictive currently doesn't even though it should. The
next commit will address the issue.
Signed-off-by: Andrea Bolognani
---
...unavailable-restrictive.x86_64-latest.args | 32 +++
...matune-memnode
Behave more consistently when presented with an invalid configuration.
Andrea Bolognani (2):
tests: Add cases for numatune with unavailable nodes
qemu: Always check nodeset provided to numatune
src/qemu/qemu_command.c | 6 --
...-unavailable-restrictive.x86_64
These files, utilities, and dependecies are used by other
> core libvirt daemons
>
> Signed-off-by: Jim Fehlig
> ---
> libvirt.spec.in | 77 ++---
> 1 file changed, 48 insertions(+), 29 deletions(-)
Reviewed-by: Andrea Bolognani
aemon-plugin-lockd, libvirt-daemon-log, and libvirt-daemon-proxy.
This paragraph could be skipped entirely.
With it gone,
Reviewed-by: Andrea Bolognani
--
Andrea Bolognani / Red Hat / Virtualization
on explicitly, so it's not a big deal if part of the setup
involves installing a couple extra packages in addition to
editing some configuration files, and everyone else gets a leaner
installation.
Thoughts?
--
Andrea Bolognani / Red Hat / Virtualization
.
>
> Signed-off-by: Jim Fehlig
> Reviewed-by: Daniel P. Berrangé
> ---
> libvirt.spec.in | 22 ++
> 1 file changed, 10 insertions(+), 12 deletions(-)
Reviewed-by: Andrea Bolognani
--
Andrea Bolognani / Red Hat / Virtualization
> 1 file changed, 6 insertions(+), 3 deletions(-)
Reviewed-by: Andrea Bolognani
--
Andrea Bolognani / Red Hat / Virtualization
Daniel P. Berrangé
> ---
> libvirt.spec.in | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
Reviewed-by: Andrea Bolognani
--
Andrea Bolognani / Red Hat / Virtualization
On Fri, Dec 23, 2022 at 10:57:34AM -0700, Jim Fehlig wrote:
> On 12/23/22 03:52, Andrea Bolognani wrote:
> > One more thing. After your changes, libvirt-daemon still has
> >
> ># netcat is needed on the server side so that clients that have
> ># libvirt <
root) %{_libdir}/libvirt/lock-driver/
Oh, this is where you should have dropped the dependency on
libvirt-daemon, as hinted in the commit message.
With that fixed,
Reviewed-by: Andrea Bolognani
--
Andrea Bolognani / Red Hat / Virtualization
++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
Reviewed-by: Andrea Bolognani
--
Andrea Bolognani / Red Hat / Virtualization
.
>
> Signed-off-by: Jim Fehlig
> Reviewed-by: Daniel P. Berrangé
> ---
> libvirt.spec.in | 22 ++
> 1 file changed, 10 insertions(+), 12 deletions(-)
libvirt-daemon-plugin-sanlock still has an unnecessary dependency on
libvirt-daemon.
--
Andrea Bolognani / Red Hat / Virtualization
On Fri, Dec 23, 2022 at 04:30:32AM -0500, Andrea Bolognani wrote:
> On Thu, Dec 22, 2022 at 11:03:37AM -0700, Jim Fehlig wrote:
> > -Requires: polkit >= 0.112
> > %if %{with_dmidecode}
> > # For virConnectGetSysinfo
> > Requires: dmidecode
> > %endif
> &g
ver
> Requires: module-init-tools
> +%if %{with_numad}
> +Requires: numad
> +%endif
Same comment as the previous patch: I think you should be able to
drop the dependency on numad from the libvirt-daemon package at this
point.
--
Andrea Bolognani / Red Hat / Virtualization
calls modprobe, so a deployment where the
daemon is installed but neither of these drivers is doesn't need the
module-init-tools package to be present.
--
Andrea Bolognani / Red Hat / Virtualization
On Fri, Dec 23, 2022 at 04:42:08AM -0500, Andrea Bolognani wrote:
> On Thu, Dec 22, 2022 at 11:03:41AM -0700, Jim Fehlig wrote:
> > %package daemon-qemu
> > Summary: Server side daemon & driver required to run QEMU guests
> >
> > +%if %{with_modular_daemons
e lxc and vbox drivers
don't use locking either? It's nice that we're making some of the
deployments leaner by default :)
I wonder if we could leave the locking part out for *all* of the
above, with the rationale that it's something that you have to
explicitly enable at the configuration file level anyway. But I guess
that wouldn't work too well when it comes to updates. Maybe after
Enough Time™ has passed?
--
Andrea Bolognani / Red Hat / Virtualization
;= 37
> Requires: gettext-runtime
> %else
> Requires: gettext
> %endif
> +# libvirtd depends on 'messagebus' service
> +Requires: dbus
> +# For uid creation during pre
> +Requires(pre): shadow-utils
This looks like pure noise - AFAICT you could have left the requires
for po
On Wed, Dec 14, 2022 at 02:55:30PM -0700, Jim Fehlig wrote:
> On 12/14/22 11:08, Andrea Bolognani wrote:
> > On Tue, Dec 13, 2022 at 05:31:02PM -0700, Jim Fehlig wrote:
> > > +* libvirt-daemon-plugin-lockd
> > > + This package provides the lockd.so module, a daemon plug
On Thu, Dec 15, 2022 at 09:22:34AM +, Daniel P. Berrangé wrote:
> On Wed, Dec 14, 2022 at 09:50:47AM -0800, Andrea Bolognani wrote:
> > Actually, adding the libvirt-daemon-lock dependency to the sanlock
> > package should happen in this patch instead of in 5/9.
>
> No we s
On Wed, Dec 14, 2022 at 07:53:05AM -0700, Jim Fehlig wrote:
> On 12/14/22 04:25, Andrea Bolognani wrote:
> > On Tue, Dec 13, 2022 at 04:37:34PM -0700, Jim Fehlig wrote:
> > > On 12/13/22 03:58, Andrea Bolognani wrote:
> > > >%dir %attr(0755, root, root) %{_li
On Wed, Dec 14, 2022 at 10:08:38AM -0800, Andrea Bolognani wrote:
> Looking at the page in its entirety, I think it would make sense to
> have the "Deployment choices" section first and the "RPM packages"
> section after it. That is, provide the quick recipes upfront,
Users are likely more interested in the main deployment
scenarios than in the detailed list of every existing RPM
package. Reorder sections accordingly.
Signed-off-by: Andrea Bolognani
---
docs/kbase/rpm-deployment.rst | 134 +-
1 file changed, 67 insertions
Andrea Bolognani (2):
kbase: Reorder sections
kbase: Reorder deployments
docs/kbase/rpm-deployment.rst | 134 +-
1 file changed, 67 insertions(+), 67 deletions(-)
--
2.38.1
List the various options so that the most likely ones come
first.
Signed-off-by: Andrea Bolognani
---
docs/kbase/rpm-deployment.rst | 52 +--
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/docs/kbase/rpm-deployment.rst b/docs/kbase/rpm
On Wed, Dec 14, 2022 at 09:56:28AM -0800, Andrea Bolognani wrote:
> On Tue, Dec 13, 2022 at 05:30:59PM -0700, Jim Fehlig wrote:
> > @@ -450,7 +446,6 @@ Requires: module-init-tools
> > Requires: iproute
> > # for /sbin/tc
> > Requires: iproute-tc
>
On Wed, Dec 14, 2022 at 09:59:41AM -0800, Andrea Bolognani wrote:
> On Tue, Dec 13, 2022 at 05:31:01PM -0700, Jim Fehlig wrote:
> > %package daemon-qemu
> > Summary: Server side daemon & driver required to run QEMU guests
> >
> > -Requires: libvirt-daemon = %{ve
gin-sanlock
> + This package provides the sanlock.so module, a daemon plugin for
> communicating
> + with a virtlockd configured to use sanlock.
Based on Dan's explanation, these descriptions are not accurate: the
lockd.so module is used by the hypervisor driver to manage locks via
virtlockd, while the sanlock.so to do the same via sanlock.
--
Andrea Bolognani / Red Hat / Virtualization
now it's a
hard dependency. I'm not sure we want that.
--
Andrea Bolognani / Red Hat / Virtualization
route dependency would have
to be moved to the libvirt-daemon-driver-network package and so on.
Some of them might even need to be duplicated to ensure that a pure
split daemon scenario works correctly.
--
Andrea Bolognani / Red Hat / Virtualization
%{version}-%{release}
> +Requires: libvirt-daemon-lock = %{version}-%{release}
> +Obsoletes: libvirt-lock-sanlock < 8.10.0
The version number should be 9.0.0 here.
--
Andrea Bolognani / Red Hat / Virtualization
On Wed, Dec 14, 2022 at 09:31:31AM -0800, Andrea Bolognani wrote:
> On Tue, Dec 13, 2022 at 05:30:54PM -0700, Jim Fehlig wrote:
> > Signed-off-by: Jim Fehlig
> > Reviewed-by: Daniel P. Berrangé
> > ---
> > libvirt.spec.in | 61 ++
tlockd
> +Requires: libvirt-libs = %{version}-%{release}
I think you should have a dependency on libvirt-daemon-lock here,
since the lockd.so plugin requires virtlockd in order to work.
--
Andrea Bolognani / Red Hat / Virtualization
On Tue, Dec 13, 2022 at 05:30:56PM -0700, Jim Fehlig wrote:
> Signed-off-by: Jim Fehlig
> Reviewed-by: Daniel P. Berrangé
> ---
> libvirt.spec.in | 56 ++---
> 1 file changed, 39 insertions(+), 17 deletions(-)
Reviewed-by: A
On Tue, Dec 13, 2022 at 05:30:55PM -0700, Jim Fehlig wrote:
> Signed-off-by: Jim Fehlig
> Reviewed-by: Daniel P. Berrangé
> ---
> libvirt.spec.in | 53 +++--
> 1 file changed, 38 insertions(+), 15 deletions(-)
Reviewed-by: A
On Tue, Dec 13, 2022 at 05:30:54PM -0700, Jim Fehlig wrote:
> Signed-off-by: Jim Fehlig
> Reviewed-by: Daniel P. Berrangé
> ---
> libvirt.spec.in | 61 +++--
> 1 file changed, 44 insertions(+), 17 deletions(-)
Reviewed-by: A
On Tue, Dec 13, 2022 at 04:37:34PM -0700, Jim Fehlig wrote:
> On 12/13/22 03:58, Andrea Bolognani wrote:
> > %dir %attr(0755, root, root) %{_libdir}/libvirt/
> > %dir %attr(0755, root, root) %{_libdir}/libvirt/connection-driver/
> > %dir %attr(0755, root, root) %{_libdir
reason to split things
further at the moment.
--
Andrea Bolognani / Red Hat / Virtualization
The storage-backend/ and storage-file/ directories are currently
considered unowned by RPM. Have the libvirt-daemon package take
ownership of them, just as it already owns the connection-driver/
and lock-driver/ directories.
Signed-off-by: Andrea Bolognani
---
libvirt.spec.in | 2 ++
1 file
%blurb
Andrea Bolognani (2):
spec: Add trailing backslash
spec: List more directories
libvirt.spec.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
2.38.1
Signed-off-by: Andrea Bolognani
---
libvirt.spec.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 31ff8ea01e..cf619e1b59 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1761,7 +1761,7 @@ exit 0
%dir %attr(0711, root, root
On Tue, Dec 13, 2022 at 09:57:31AM +, Daniel P. Berrangé wrote:
> On Sun, Dec 11, 2022 at 10:22:00AM -0800, Andrea Bolognani wrote:
> > Both packages should depend on libvirt-daemon-lock too, instead of
> > just the libraries.
>
> Nope, they shouldn't - that's the vi
ds good. It is already going to own the
connection-driver directory. But libvirt-daemon-lock will need a
dependency on it, which otherwise it wouldn't have.
--
Andrea Bolognani / Red Hat / Virtualization
On Mon, Dec 12, 2022 at 03:19:31PM -0700, Jim Fehlig wrote:
> On 12/11/22 10:46, Andrea Bolognani wrote:
> > I think we should just have a libvirt-daemon-common package that
> > includes what you currently have put into the libvirt-daemon-client
> > package plus thes
root) %{_libdir}/libvirt/lock-driver
I believe this directory belongs to either the libvirt-daemon-lock
package (more likely) or possibly the libvirt-daemon-common package.
--
Andrea Bolognani / Red Hat / Virtualization
age, and after
this change the same would be true except for the monolithic daemon
not coming along for the ride.
--
Andrea Bolognani / Red Hat / Virtualization
n't achieve this way is to install libvirtd and
> > > QEMU, without having the module daemons present. I'm not sure that
> > > matters though, if we aim to discontinue shipping libvirtd long term.
That's already the case today, so I'd say there's no need to worry
about it.
--
Andrea Bolognani / Red Hat / Virtualization
On Thu, Dec 08, 2022 at 05:09:39PM +, Daniel P. Berrangé wrote:
> On Thu, Dec 08, 2022 at 06:06:23PM +0100, Andrea Bolognani wrote:
> > The script had an incorrect interpreter line until commit
> > f6a19d7264bb, so the flake8 check would not realize it needed
> > to pick i
The script had an incorrect interpreter line until commit
f6a19d7264bb, so the flake8 check would not realize it needed
to pick it up and these issues, some of which were present it
the very first version that was committed, were not being
reported.
Signed-off-by: Andrea Bolognani
---
tools
Spotted by Lintian (typo-in-manual-page tag).
Signed-off-by: Andrea Bolognani
---
docs/manpages/virt-qemu-sev-validate.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/manpages/virt-qemu-sev-validate.rst
b/docs/manpages/virt-qemu-sev-validate.rst
index f5f928603a
Andrea Bolognani (2):
docs: Fix typo in virt-qemu-sev-validate(1)
tools: Fix interpreter for virt-qemu-sev-validate
docs/manpages/virt-qemu-sev-validate.rst | 2 +-
tools/virt-qemu-sev-validate | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
2.38.1
Go through env(1) instead of hardcoding the path to the Python
interpreter, as we already do for all other Python scripts.
Signed-off-by: Andrea Bolognani
---
tools/virt-qemu-sev-validate | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/virt-qemu-sev-validate b/tools
On Tue, Dec 06, 2022 at 05:15:43PM +, Daniel P. Berrangé wrote:
> On Mon, Nov 28, 2022 at 08:33:27AM -0800, Andrea Bolognani wrote:
> > It appears to me that the primary reason to want this (and now
> > virt-qemu-sev-validate) to be in a separate package is really the
> >
Signed-off-by: Andrea Bolognani
---
examples/systemtap/meson.build | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/examples/systemtap/meson.build b/examples/systemtap/meson.build
index f31187e187..e9874846e6 100644
--- a/examples/systemtap/meson.build
+++ b/examples
Andrea Bolognani (2):
examples: Sort list
examples: Install amd-sev-es-vmsa.stp
examples/systemtap/meson.build | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--
2.38.1
Fixes: d154b49a7e813245ff2ef1061c89edff9db0e119
Signed-off-by: Andrea Bolognani
---
examples/systemtap/meson.build | 1 +
1 file changed, 1 insertion(+)
diff --git a/examples/systemtap/meson.build b/examples/systemtap/meson.build
index e9874846e6..865df3bff9 100644
--- a/examples/systemtap
On Mon, Nov 28, 2022 at 08:33:27AM -0800, Andrea Bolognani wrote:
> On Wed, Oct 05, 2022 at 11:51:05AM +0100, Daniel P. Berrangé wrote:
> > Since this tool introduces a python dependency it is not desirable
> > to include it in any of the existing RPMs in libvirt. This tool i
On Wed, Nov 09, 2022 at 06:14:58PM +, Daniel P. Berrangé wrote:
> On Fri, Nov 04, 2022 at 02:56:51PM -0400, Andrea Bolognani wrote:
> > IIUC a specific profile (cri-containerd.apparmor.d) is used for
> > unprivileged containers such as virt-launcher, but a privileged one
&
On Tue, Nov 29, 2022 at 09:05:33AM -0800, Andrea Bolognani wrote:
> Hi,
>
> this is a proposal for introducing a new family of APIs in libvirt,
> with the goal of improving integration with management applications.
>
> KubeVirt is intended to be the primary consumer of these AP
nail those down, I want to gather feedback on
the high-level idea, both from the libvirt and KubeVirt side.
Credits
---
Thanks to Michal and Martin for helping shape and polish the idea
from its initial rough state.
--
Andrea Bolognani / Red Hat / Virtualization
Suppose later we introduce a tool that's QEMU-specific but written in
C, or a tool that's not specific to any hypervisor driver but written
in Python. Where would those go?
--
Andrea Bolognani / Red Hat / Virtualization
On Thu, Nov 10, 2022 at 08:57:25AM +, Daniel P. Berrangé wrote:
> On Wed, Nov 09, 2022 at 09:17:08PM +0100, Olaf Hering wrote:
> > Wed, 9 Nov 2022 09:04:12 -0800 Andrea Bolognani :
> > > Olaf, can you please remind me why the files we dropped were
> > > problemati
ind me why the files we dropped were
problematic but these ones apparently aren't?
--
Andrea Bolognani / Red Hat / Virtualization
ere will show up when running 'systemctl
edit libvirt-guests', which makes them fairly discoverable IMO.
That's really the key point, because even today you can change the
behavior both with a defaults file and a systemd unit override.
What do you think? Would that work for you?
--
Andrea Bolognani / Red Hat / Virtualization
t-client package.
I think the Recommends is the right way to go, and to be honest even
a hard Depends wouldn't feel unreasonable: the main reason to split
the client bits from the server bits is so that *clients* can be very
lightweight, but the server is going to be heavyweight by definition
an
On Thu, Nov 03, 2022 at 05:23:27PM +, Daniel P. Berrangé wrote:
> On Thu, Nov 03, 2022 at 12:35:15PM -0400, Andrea Bolognani wrote:
> > On Thu, Nov 03, 2022 at 03:39:44PM +0100, Peter Krempa wrote:
> > > On Thu, Nov 03, 2022 at 12:13:53 +0100, Andrea Bolognani wrote:
> &
On Fri, Nov 04, 2022 at 08:23:52PM +0600, Oleg Vasilev wrote:
> On 04.11.2022 20:19, Andrea Bolognani wrote:
> > Additionally, after this change it would be impossible to create a
> > q35 VM *without* the additional bridge. Most users of the q35 machine
> > type are like
440fx, doesn't support hotplugging of any
kind out of the box, so it's up to the user / management application
to ensure that the necessary controllers are added. This is not
ideal, but there's no way around it, and it's still preferable to
forcing unavoidable, potentially useless extra controllers on
everybody.
--
Andrea Bolognani / Red Hat / Virtualization
On Thu, Nov 03, 2022 at 03:39:44PM +0100, Peter Krempa wrote:
> On Thu, Nov 03, 2022 at 12:13:53 +0100, Andrea Bolognani wrote:
> > Distros that use AppArmor, such as Debian and Ubuntu, install
> > QEMU under /usr/bin/qemu-system-*, and our AppArmor profile is
> > written
On Thu, Nov 03, 2022 at 08:24:37AM -0600, Jim Fehlig wrote:
> On 11/3/22 05:13, Andrea Bolognani wrote:
> > + # Needed when running the RHEL/CentOS version of libvirt and QEMU
> > + # inside a privileged container on a Debian/Ubuntu host
> > + /usr/libexec/qemu-kvm PUx,
On Thu, Nov 03, 2022 at 12:13:53PM +0100, Andrea Bolognani wrote:
> Distros that use AppArmor, such as Debian and Ubuntu, install
> QEMU under /usr/bin/qemu-system-*, and our AppArmor profile is
> written with that assumption in mind.
>
> If you try to run the RHEL or CentOS ver
details.
Signed-off-by: Andrea Bolognani
---
src/security/apparmor/usr.sbin.libvirtd.in | 4
src/security/apparmor/usr.sbin.virtqemud.in | 4
2 files changed, 8 insertions(+)
diff --git a/src/security/apparmor/usr.sbin.libvirtd.in
b/src/security/apparmor/usr.sbin.libvirtd.in
index
85f79e5c3ae330d6
>
> https://listman.redhat.com/archives/libvir-list/2022-June/232487.html
>
> guess we forgot to actually follow up that time.
>
> Reviewed-by: Daniel P. Berrangé
Yup, my bad (twice over). Thanks Jano for taking care of it!
--
Andrea Bolognani / Red Hat / Virtualization
e archive as a starting point instead of using
dh_make to create one from scratch. It's currently a couple of
versions behind upstream, but should be pretty solid otherwise.
dh_make is intended to create a very basic skeleton for a package,
and you're expected to make significant changes to the files it
produces before being able to build a working package.
--
Andrea Bolognani / Red Hat / Virtualization
Signed-off-by: Andrea Bolognani
---
ci/containers/centos-stream-9.Dockerfile | 5 +
ci/containers/opensuse-leap-153.Dockerfile | 2 +-
ci/containers/ubuntu-2004.Dockerfile | 2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/ci/containers/centos-stream-9.Dockerfile
Signed-off-by: Andrea Bolognani
---
ci/cirrus/{macos-11.vars => macos-12.vars} | 0
ci/gitlab/builds.yml | 6 +++---
ci/manifest.yml| 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
rename ci/cirrus/{macos-11.vars => macos-12.vars
Test pipeline: https://gitlab.com/abologna/libvirt/-/pipelines/620665364
Now that the test suite issues that were blocking the switch have
been addressed, we can finally jump on the current macOS release.
Andrea Bolognani (2):
ci: Refresh generated files
ci: Switch from macOS 11 to macOS 12
501 - 600 of 8356 matches
Mail list logo
