Added the following new libvirt conf option to the release note to
indicate their availability with the next release:
Signed-off-by: Ani Sinha
---
NEWS.rst | 21 +
1 file changed, 21 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 65fb112d11..85e796f274
This change adds backend qemu command line support for new libvirt
global feature 'acpi-bridge-hotplug'. This option can be used as
following:
The '' sub-element under '' is also newly introduced.
'acpi-bridge-hotplug' turns on the following command line option to
qemu for x86
This change introduces a new libvirt sub-element under
that can be used to configure all pci related features.
Currently the only sub-sub element supported by this sub-element is
'acpi-bridge-hotplug' as shown below:
The above option is only available for the QEMU driver, for x86
qemu added support for i440fx specific global boolean flag
PIIX4_PM.acpi-pci-hotplug-with-bridge-support
around version 2.1. This flag is enabled by default. When disabled, it
turns off acpi pci hotplug for cold plugged pci bridges in i440fx
machine types.
Very recently,
I am re-introducing the patchset for which got
reverted here few months back:
https://www.spinics.net/linux/fedora/libvir/msg224089.html
The reason for the reversal was that there seemed to be some
instability/issues around the use of the qemu commandline which this
patchset tries to support.
On Mon, Feb 28, 2022 at 11:24:07AM -0500, Laine Stump wrote:
> On 2/25/22 10:30 AM, Daniel P. Berrangé wrote:
> > Now that the virNWFilterBinding APIs are using the nwfilter
> > update lock directly, there is no need for the virt drivers
> > to do it themselves.
>
> I'm always nervous when the
On 2/25/22 10:30 AM, Daniel P. Berrangé wrote:
The virNWFilterTechDriverForName & virNWFilterUpdateInstantiateFilter
methods are only used within the same source file, so don't need to
be exported.
Signed-off-by: Daniel P. Berrangé
Reviewed-by: Laine Stump
(again, I didn't even look to the
On 2/25/22 10:30 AM, Daniel P. Berrangé wrote:
This method doesn't exist since
commit d1a7c08eb145d8b9d9c4a268f43b1590049a
Author: Daniel P. Berrangé
Date: Thu Apr 26 12:26:51 2018 +0100
nwfilter: convert the gentech driver code to use virNWFilterBindingDefPtr
On 2/25/22 10:30 AM, Daniel P. Berrangé wrote:
Now that the virNWFilterBinding APIs are using the nwfilter
update lock directly, there is no need for the virt drivers
to do it themselves.
I'm always nervous when the ordering of locks is changed, and that's
what is happening with the
On 2/25/22 10:30 AM, Daniel P. Berrangé wrote:
The nwfilter update lock is historically acquired by the virt
drivers in order to achieve serialization between nwfilter
define/undefine, and instantiation/teardown of filters.
When running in the modular daemons, however, the mutex that
the virt
On Mon, Feb 28, 2022 at 11:05:09AM -0500, Laine Stump wrote:
> On 2/25/22 10:30 AM, Daniel P. Berrangé wrote:
> > The virNWFilterLockIface method is only called from one place,
> > the learnIPAddressThread method.
>
> nwfilter_gentech_driver.c:virNWFilterDoInstantiate() and
>
On 2/25/22 10:30 AM, Daniel P. Berrangé wrote:
The virNWFilterLockIface method is only called from one place,
the learnIPAddressThread method.
nwfilter_gentech_driver.c:virNWFilterDoInstantiate() and
_virNWFilterTeardownFilter() also call virNWFilterLockIface.
And there is this call chain
On Mon, Feb 21, 2022 at 11:53 AM Wim de With wrote:
>
> > Since the intent of libvirt using LGPL was explicitly to allow non-GPL
> > compatible applications to use libvirt, it is a mistake to be using
> > a license that breaks this ability for Rust.
> >
> > In Golang we've used MIT license
> >
>
It makes no sense to have 'started' variable in the
libxlDomainJobObj as the same one is already in virDomainJobData,
but never used.
Signed-off-by: Kristina Hanicova
---
src/libxl/libxl_domain.c | 10 +-
src/libxl/libxl_domain.h | 1 -
2 files changed, 5 insertions(+), 6 deletions(-)
14 matches
Mail list logo
