On Mon, Apr 02, 2018 at 02:27 PM +0200, John Ferlan wrote:
> For all @dom's fetched from a testDomObjFromDomain because
> virDomainObjListRemove will return an unlocked domain object
> we should relock it prior to the cleanup label which will use
> virDomainObjEndAPI which would Unlock and Unref t
On Mon, Apr 02, 2018 at 02:27 PM +0200, John Ferlan wrote:
> Rather than using virDomainObjListFindByID, let's be more consistent
> and return a reffed and locked object. Since we're using the Ref API,
> use virDomainObjEndAPI on @dom and not just virObjectUnlock.
>
> Signed-off-by: John Ferlan
>
On Mon, Apr 02, 2018 at 02:27 PM +0200, John Ferlan wrote:
> Rather than using virDomainObjListFindByUUID, let's be more consistent
> and return a reffed and locked object. Since we're using the Ref API,
> use virDomainObjEndAPI on @dom and not just virObjectUnlock.
>
> Signed-off-by: John Ferlan
On 04/03/2018 07:12 PM, John Ferlan wrote:
>
> On 03/28/2018 10:06 AM, Andrea Bolognani wrote:
>> I haven't been able to come up with a single scenario in which
>> the code in question would be executed; even if there was one,
>> it would be due to the user specifying a *partial* PCI topology
>> in
On 03/28/2018 10:06 AM, Andrea Bolognani wrote:
> Signed-off-by: Andrea Bolognani
> ---
> docs/news.xml | 9 +
> 1 file changed, 9 insertions(+)
>
Just make sure there isn't any wierd placement by merges or loss of
patch 10 before this series finally gets pushed...
Reviewed-by: John
On 03/28/2018 10:06 AM, Andrea Bolognani wrote:
> Signed-off-by: Andrea Bolognani
> ---
> docs/news.xml | 8
> 1 file changed, 8 insertions(+)
>
Unnecessary now...
John
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On 03/28/2018 10:06 AM, Andrea Bolognani wrote:
> Now that support for the pcie-to-pci-bridge controller has
> been implemented, adding the QEMU_CAPS_DEVICE_PCIE_PCI_BRIDGE
> capability to the existing test is enough to cause the guest
> to use pcie-to-pci-bridge instead of dmi-to-pci-bridge.
>
On 03/28/2018 10:06 AM, Andrea Bolognani wrote:
> This capability will be set when the pcie-pci-bridge device
> is available in the QEMU binary.
>
> Signed-off-by: Andrea Bolognani
> ---
> src/qemu/qemu_capabilities.c | 2 ++
> src/qemu/qemu_capabilities.h
On 03/28/2018 10:06 AM, Andrea Bolognani wrote:
> The new controller will not yet be used automatically by
> libvirt, but at this point it's already possible to configure
> a guest to use it.
>
> Signed-off-by: Andrea Bolognani
> ---
> docs/formatdomain.html.in | 3 ++-
> docs/schemas/do
On 03/28/2018 10:06 AM, Andrea Bolognani wrote:
> Both pcie-to-pci-bridge and dmi-to-pci-bridge can be used to
> create a traditional PCI topology in a pure PCIe guest such as
> those using the x86_64/q35 or aarch64/virt machine type;
> however, the former should be preferred, as it doesn't need
On 03/28/2018 10:06 AM, Andrea Bolognani wrote:
> Just like the existing areMultipleRootsSupported, this will
> allow us to change the results of the driver-agnostic PCI
> address allocation logic based on whether the QEMU binary
> supports certain features.
>
> Signed-off-by: Andrea Bolognani
On 03/28/2018 10:06 AM, Andrea Bolognani wrote:
> We're going to add a similarly-named attribute later, and we'd
> like to be consistent.
>
> Signed-off-by: Andrea Bolognani
> ---
> src/conf/domain_addr.c | 2 +-
> src/conf/domain_addr.h | 2 +-
> src/qemu/qemu_domain_address.c
On 03/28/2018 10:06 AM, Andrea Bolognani wrote:
> I haven't been able to come up with a single scenario in which
> the code in question would be executed; even if there was one,
> it would be due to the user specifying a *partial* PCI topology
> in the guest XML, which is of course entirely unsup
On 03/28/2018 10:06 AM, Andrea Bolognani wrote:
> This test shows what happens when you add a traditional PCI
> device such as pci-serial to a pure PCIe machine type such
> as aarch64/virt.
>
> Signed-off-by: Andrea Bolognani
> ---
> .../qemuxml2argvdata/aarch64-traditional-pci.args | 26
On 03/28/2018 10:06 AM, Andrea Bolognani wrote:
> Instead of first listing the models on their own, and then
> listing them again grouped by the libvirt release they were
> introduced in, have a single list.
>
> Signed-off-by: Andrea Bolognani
> ---
> docs/formatdomain.html.in | 20 ---
On Tue, Apr 03, 2018 at 17:23:50 +0200, Ján Tomko wrote:
> From: Christophe Fergeau
>
> This commit adds a 'spice_tls_ciphers' parameter in
> qemu.conf which allows to configure which TLS ciphers
> SPICE will be using for its TLS connections.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=15620
On Tue, Apr 03, 2018 at 15:56:11 +0100, Daniel P. Berrangé wrote:
> Describe how we decide which host platforms to support for libvirt,
> which in turn makes it easier to decide when a platform / software
> version can be dropped.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> docs/index.html.in
On Tue, Apr 03, 2018 at 06:35:06PM +0200, Pino Toscano wrote:
> On Tuesday, 3 April 2018 18:28:46 CEST John Ferlan wrote:
> > Could we add some sort of table where we could keep track of "known" and
> > supported OS versions, what libvirt version was used, what QEMU version
> > was used?
>
> Do yo
On Tue, Apr 03, 2018 at 12:28:46PM -0400, John Ferlan wrote:
>
>
> On 04/03/2018 10:56 AM, Daniel P. Berrangé wrote:
> > Describe how we decide which host platforms to support for libvirt,
> > which in turn makes it easier to decide when a platform / software
> > version can be dropped.
> >
> >
On Tuesday, 3 April 2018 18:28:46 CEST John Ferlan wrote:
> Could we add some sort of table where we could keep track of "known" and
> supported OS versions, what libvirt version was used, what QEMU version
> was used?
Do you mean like what repology does?
https://repology.org/metapackage/qemu/ver
On 04/03/2018 10:56 AM, Daniel P. Berrangé wrote:
> Describe how we decide which host platforms to support for libvirt,
> which in turn makes it easier to decide when a platform / software
> version can be dropped.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> docs/index.html.in | 2 +-
>
On Tue, 2018-04-03 at 15:56 +0100, Daniel P. Berrangé wrote:
> Describe how we decide which host platforms to support for libvirt,
> which in turn makes it easier to decide when a platform / software
> version can be dropped.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> docs/index.html.in |
[...]
>> I understand QEMU is just but one variable in the complex equation.
>> Listing QEMU was just an example for this series based on the 8 years
>> since 0.12 which is the minimum we support now vs. 5 years since 1.3
>> which is where this series was headed. Using the 2-3 years you responded
On Sat, Mar 31, 2018 at 10:15:03PM +0200, Ján Tomko wrote:
> If QEMU uses a seccomp blacklist (since 2.11), -sandbox on
> no longer tries to whitelist all the calls, but uses sets
> of blacklists:
> default (always blacklisted with -sandbox on)
> obsolete (defaults to deny)
Perhaps list that anywa
On Tue, Apr 03, 2018 at 05:29:52PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-03 at 15:59 +0100, Daniel P. Berrangé wrote:
> > On Tue, Apr 03, 2018 at 04:43:41PM +0200, Andrea Bolognani wrote:
> > > Most of the compelling features introduced by any libvirt release
> > > require the correspond
On Tue, 2018-04-03 at 15:59 +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 03, 2018 at 04:43:41PM +0200, Andrea Bolognani wrote:
> > Most of the compelling features introduced by any libvirt release
> > require the corresponding QEMU feature to be available. And, as
> > I've argued elsewhere in the
From: Christophe Fergeau
This commit adds a 'spice_tls_ciphers' parameter in
qemu.conf which allows to configure which TLS ciphers
SPICE will be using for its TLS connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1562032
Signed-off-by: Christophe Fergeau
Signed-off-by: Ján Tomko
---
Th
On Tue, Apr 03, 2018 at 03:56:11PM +0100, Daniel P. Berrangé wrote:
> Describe how we decide which host platforms to support for libvirt,
> which in turn makes it easier to decide when a platform / software
> version can be dropped.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> docs/index.html.i
On Tue, Apr 03, 2018 at 10:57:44AM -0400, John Ferlan wrote:
>
>
> On 04/03/2018 10:04 AM, Daniel P. Berrangé wrote:
> > On Tue, Apr 03, 2018 at 09:29:01AM -0400, John Ferlan wrote:
> >> Looking at git history and considering adjustments to the VERSION file
> >> in the QEMU tree, I get:
> >
> >
On Tue, Apr 03, 2018 at 04:43:41PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-03 at 15:00 +0100, Daniel P. Berrangé wrote:
> > On Tue, Apr 03, 2018 at 01:23:15PM +0200, Andrea Bolognani wrote:
> > > Bumping our minimum QEMU version wouldn't affect that kind of
> > > scenario, as long as we ke
On 04/03/2018 10:04 AM, Daniel P. Berrangé wrote:
> On Tue, Apr 03, 2018 at 09:29:01AM -0400, John Ferlan wrote:
>>
>>
>> On 04/03/2018 07:23 AM, Andrea Bolognani wrote:
>>> On Tue, 2018-04-03 at 12:57 +0200, Peter Krempa wrote:
On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
Describe how we decide which host platforms to support for libvirt,
which in turn makes it easier to decide when a platform / software
version can be dropped.
Signed-off-by: Daniel P. Berrangé
---
docs/index.html.in | 2 +-
docs/platforms.html.in | 74 +++
> > +},
> > +{.name = NULL}
> > +};
> > +
> > +static const vshCmdOptDef opts_launch_security[] = {
> > +VIRSH_COMMON_OPT_DOMAIN_FULL(0),
> > +{.name = "get",
> > + .type = VSH_OT_STRING,
> > + .help = N_("Show the launch-security info")
> > +},
> > +VIRSH_COMMON_OPT
On Tue, 2018-04-03 at 15:00 +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 03, 2018 at 01:23:15PM +0200, Andrea Bolognani wrote:
> > Bumping our minimum QEMU version wouldn't affect that kind of
> > scenario, as long as we keep making sure libvirt itself builds on
> > RHEL 6 - which we already do a
On Mon, Apr 02, 2018 at 09:18:55AM -0500, Brijesh Singh wrote:
> Add new 'launch-security' command, the command can be used to get or set
> the launch security information when booting encrypted VMs.
>
> Signed-off-by: Brijesh Singh
> ---
> tools/virsh-domain.c | 84
> +++
On Tue, 2018-04-03 at 09:29 -0400, John Ferlan wrote:
> Maybe we need to formulate some sort of "annual processing" to declare
> minimal version support and declare certain non-maintained drivers to be
> dead. I believe it becomes harder and harder to support a policy of must
> keep support for som
On Tue, Apr 03, 2018 at 02:49:34PM +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 03, 2018 at 12:57:45PM +0200, Peter Krempa wrote:
> > On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
> > > On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
> > > > It's been a while since we
On Wed, Mar 28, 2018 at 08:58:25PM -0600, Jim Fehlig wrote:
> Long overdue first cut at remove the old xen driver. The first 3 patches
> move existing tests to WITH_LIBXL since we'll want to continue supporting
> conversion of the various xen config formats. The remain patches remove
> the cruft.
>
From: Wim ten Have
When tools like virt-install request to create a fully allocated
filesystem object storage by setting the parameter sparse=no, libvirt
doesn't allow that to happen for qcow2 formatted files.
Regardless of its XML instuction request libvirt always targets its
filesystem object
From: Wim ten Have
This patch adds support to qcow2 formatted filesystem object storage by
instructing qemu-img to build them with preallocation=falloc whenever the
XML described storage matches its . For all other
cases the filesystem stored objects are built with preallocation=metadata.
Sign
Similarly to 3506f1ecfde, the contents of 'cmpcontent' may be an empty
string so the following code would access memory out of the array.
Signed-off-by: Peter Krempa
---
tests/testutils.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/testutils.c b/tests/testutils.c
From: Wim ten Have
Signed-off-by: Wim ten Have
---
tests/storagevolxml2argvdata/qcow2-nocapacity-convert-prealloc.argv | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/tests/storagevolxml2argvdata/qcow2-nocapacity-convert-prealloc.argv
b/tests/storagevolxml2argvdata/qcow2-n
On Tue, Apr 03, 2018 at 09:29:01AM -0400, John Ferlan wrote:
>
>
> On 04/03/2018 07:23 AM, Andrea Bolognani wrote:
> > On Tue, 2018-04-03 at 12:57 +0200, Peter Krempa wrote:
> >> On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
> >>> On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tom
On Tue, Apr 03, 2018 at 01:23:15PM +0200, Andrea Bolognani wrote:
> On Tue, 2018-04-03 at 12:57 +0200, Peter Krempa wrote:
> > On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
> > > On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
> > > > It's been a while since we last bump
...
> >
> > typedef enum {
> > +VIR_DOMAIN_LAUNCH_SECURITY_NONE,
> > +VIR_DOMAIN_LAUNCH_SECURITY_SEV,
> > +
> > +VIR_DOMAIN_LAUNCH_SECURITY_LAST,
> > +} virDomainLaunchSecurity;
> > +
> > +typedef struct _virDomainSevDef virDomainSevDef;
> > +typedef virDomainSevDef *virDomainSevDefPt
On Tue, Apr 03, 2018 at 12:57:45PM +0200, Peter Krempa wrote:
> On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
> > On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
> > > It's been a while since we last bumped the minimum QEMU version.
> > > Let's get rid of -help parsing a
On Tue, Apr 03, 2018 at 02:05 PM +0200, "Daniel P. Berrangé"
wrote:
> On Tue, Apr 03, 2018 at 01:46:13PM +0200, Marc Hartmayer wrote:
>> On Wed, Mar 21, 2018 at 07:57 AM +0100, Marc Hartmayer
>> wrote:
>> > On Mon, Mar 19, 2018 at 04:06 PM +0100, "Daniel P. Berrangé"
>> > wrote:
>> >> On Thu,
On 04/03/2018 07:23 AM, Andrea Bolognani wrote:
> On Tue, 2018-04-03 at 12:57 +0200, Peter Krempa wrote:
>> On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
>>> On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
It's been a while since we last bumped the minimum QEMU ve
Signed-off-by: Daniel P. Berrangé
---
Pushed as trivial change.
setup.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/setup.py b/setup.py
index c40908b..eff9d54 100755
--- a/setup.py
+++ b/setup.py
@@ -334,7 +334,7 @@ class my_clean(clean):
_c_modules, _py_modules = get_
On Tue, 2018-04-03 at 13:42 +0100, Daniel P. Berrangé wrote:
> Since RPC support moved out of glibc we need to have explicit deps on
> the new packages providing this functionality
>
> Signed-off-by: Daniel P. Berrangé
> ---
> libvirt.spec.in | 5 +
> 1 file changed, 5 insertions(+)
>
> dif
Up until now we have only formatted non-default GIC versions on
the command line, in order to maintain compatibility with older
QEMU versions that didn't implement the gic-version option to
begin with; however, doing so is entirely unnecessary for newer
QEMU versions, where the option is available.
Since RPC support moved out of glibc we need to have explicit deps on
the new packages providing this functionality
Signed-off-by: Daniel P. Berrangé
---
libvirt.spec.in | 5 +
1 file changed, 5 insertions(+)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index b55a947ec9..97143c68ae 100644
On Tue, Apr 03, 2018 at 01:46:13PM +0200, Marc Hartmayer wrote:
> On Wed, Mar 21, 2018 at 07:57 AM +0100, Marc Hartmayer
> wrote:
> > On Mon, Mar 19, 2018 at 04:06 PM +0100, "Daniel P. Berrangé"
> > wrote:
> >> On Thu, Mar 08, 2018 at 01:20:25PM +0100, Marc Hartmayer wrote:
> >>> Don't assume t
Hi, all.
This is another RFC on pull backup API. This API provides means to read domain
di
On Tue, Mar 20, 2018 at 11:25 AM +0100, Marc Hartmayer
wrote:
> Hi,
>
> there is a race condition between 'qemuDomainCreate' and
> 'qemuDomainDestroy' causing a NULL pointer segmentation fault when
> accessing priv->monConfig. The race condition can be easily reproduced
> using gdb.
>
> (gdb) set
On Wed, Mar 21, 2018 at 07:57 AM +0100, Marc Hartmayer
wrote:
> On Mon, Mar 19, 2018 at 04:06 PM +0100, "Daniel P. Berrangé"
> wrote:
>> On Thu, Mar 08, 2018 at 01:20:25PM +0100, Marc Hartmayer wrote:
>>> Don't assume that the feature VIR_DRV_FEATURE_REMOTE_CLOSE_CALLBACK is
>>> available for e
On Wed, Mar 28, 2018 at 03:13:35PM +0100, Daniel P. Berrangé wrote:
On Wed, Mar 28, 2018 at 08:10:34AM -0600, Jim Fehlig wrote:
On 03/28/2018 07:28 AM, Daniel P. Berrangé wrote:
> On Wed, Mar 28, 2018 at 10:03:51AM +0100, Daniel P. Berrangé wrote:
> > On Tue, Mar 27, 2018 at 04:31:29PM -0600, Ji
On Tue, Apr 03, 2018 at 12:23:13 +0100, Daniel Berrange wrote:
> On Sat, Mar 31, 2018 at 11:01:15AM +0200, Peter Krempa wrote:
> > Rather than depending on yajl bits for creating the JSON structure
> > replace it by few virBuffer bits. This will make the JSON formatter
> > libary agnostic.
>
> I d
On Tue, 2018-04-03 at 12:57 +0200, Peter Krempa wrote:
> On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
> > On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
> > > It's been a while since we last bumped the minimum QEMU version.
> > > Let's get rid of -help parsing and brin
On Sat, Mar 31, 2018 at 11:01:15AM +0200, Peter Krempa wrote:
> Rather than depending on yajl bits for creating the JSON structure
> replace it by few virBuffer bits. This will make the JSON formatter
> libary agnostic.
I don't think this is a good idea as it means we have to reinvent the
wheel to
On Tue, Apr 03, 2018 at 01:07:29PM +0200, Peter Krempa wrote:
> On Tue, Apr 03, 2018 at 13:01:48 +0200, Peter Krempa wrote:
> > On Tue, Apr 03, 2018 at 11:56:33 +0100, Daniel Berrange wrote:
> > > On Fri, Mar 30, 2018 at 12:59:07PM +0200, Peter Krempa wrote:
> > > > Coverity was not wrong about the
On Tue, Apr 03, 2018 at 13:01:48 +0200, Peter Krempa wrote:
> On Tue, Apr 03, 2018 at 11:56:33 +0100, Daniel Berrange wrote:
> > On Fri, Mar 30, 2018 at 12:59:07PM +0200, Peter Krempa wrote:
> > > Coverity was not wrong about the usage of 'a'/'A' modifiers for
> > > virJSONValueObjectAddVArgs as no
On Tue, Apr 03, 2018 at 11:56:33 +0100, Daniel Berrange wrote:
> On Fri, Mar 30, 2018 at 12:59:07PM +0200, Peter Krempa wrote:
> > Coverity was not wrong about the usage of 'a'/'A' modifiers for
> > virJSONValueObjectAddVArgs as noted in [1]. Fix the possible
> > leak/double-free, and add test to m
On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
> On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
> > It's been a while since we last bumped the minimum QEMU version.
> > Let's get rid of -help parsing and bring our test suite closer
> > to real world usage by implying lot
On Fri, Mar 30, 2018 at 12:59:07PM +0200, Peter Krempa wrote:
> Coverity was not wrong about the usage of 'a'/'A' modifiers for
> virJSONValueObjectAddVArgs as noted in [1]. Fix the possible
> leak/double-free, and add test to make sure it works as expected.
Do you have any idea how to trigger the
On Tue, Apr 03, 2018 at 12:45:28PM +0200, Peter Krempa wrote:
> On Tue, Apr 03, 2018 at 11:39:20 +0100, Daniel Berrange wrote:
> > On Sat, Mar 31, 2018 at 11:13:13AM +0200, Peter Krempa wrote:
> > > On Thu, Mar 29, 2018 at 01:09:57 +0200, Ján Tomko wrote:
> > > > Check for the presence of Jansson l
On Tue, Apr 03, 2018 at 11:39:20 +0100, Daniel Berrange wrote:
> On Sat, Mar 31, 2018 at 11:13:13AM +0200, Peter Krempa wrote:
> > On Thu, Mar 29, 2018 at 01:09:57 +0200, Ján Tomko wrote:
> > > Check for the presence of Jansson library and prefer it to yajl
> > > if possible.
> > >
> > > The minim
On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
> It's been a while since we last bumped the minimum QEMU version.
> Let's get rid of -help parsing and bring our test suite closer
> to real world usage by implying lots of capabilities.
NACK, this is effectively dropping support for RHEL
On Sat, Mar 31, 2018 at 11:13:13AM +0200, Peter Krempa wrote:
> On Thu, Mar 29, 2018 at 01:09:57 +0200, Ján Tomko wrote:
> > Check for the presence of Jansson library and prefer it to yajl
> > if possible.
> >
> > The minimum required version is 2.7.
> >
> > Internally, virJSONValue still stores
On Sat, Mar 31, 2018 at 03:16:55PM +0200, Ján Tomko wrote:
> On Sat, Mar 31, 2018 at 11:05:38AM +0200, Peter Krempa wrote:
> > On Thu, Mar 29, 2018 at 01:09:56 +0200, Ján Tomko wrote:
> > > I have no idea how it builds without and switching to Jansson
> > > exposes this.
> > >
> > > Signed-off-by:
Implied by QEMU >= 1.2.0.
Signed-off-by: Ján Tomko
---
src/qemu/qemu_capabilities.c | 1 -
src/qemu/qemu_capabilities.h | 2 +-
src/qemu/qemu_command.c | 19 +--
tests/qemucapabilitiesdata/caps_1.3.
Implied by QEMU >= 1.2.0.
Delete this one first, because QEMU_CAPS_NODEFCONFIG is only used
when QEMU_CAPS_NO_USER_CONFIG is unsupported.
Signed-off-by: Ján Tomko
---
src/qemu/qemu_capabilities.c | 1 -
src/qemu/qemu_capabilities.h
Implied by QEMU >= 1.2.0.
Signed-off-by: Ján Tomko
---
src/qemu/qemu_capabilities.c | 1 -
src/qemu/qemu_capabilities.h | 2 +-
src/qemu/qemu_command.c| 41 --
tests/qemucapabilitiesdata/caps_1.3.1.x86_
Implied by QEMU >= 1.2.0.
Signed-off-by: Ján Tomko
---
src/qemu/qemu_capabilities.c | 1 -
src/qemu/qemu_capabilities.h | 2 +-
src/qemu/qemu_command.c | 4 +---
src/qemu/qemu_driver.c
Implied by QEMU >= 1.2.0.
Signed-off-by: Ján Tomko
---
src/qemu/qemu_capabilities.c | 1 -
src/qemu/qemu_capabilities.h | 2 +-
src/qemu/qemu_command.c| 317 +
tests/qemucapabilitiesdata/caps_1.3.1.x8
Implied by QEMU >= 1.2.0.
Signed-off-by: Ján Tomko
---
src/qemu/qemu_capabilities.c | 12
src/qemu/qemu_capabilities.h | 2 +-
src/qemu/qemu_command.c | 8 ++--
tests/qemucapab
Implied by QEMU >= 1.3.0.
Signed-off-by: Ján Tomko
---
src/qemu/qemu_capabilities.c | 4
src/qemu/qemu_capabilities.h | 2 +-
src/qemu/qemu_command.c | 3 +--
test
We require QEMU >= 0.15.0, assume every QEMU supports it.
Sadly that does not let us trivially drop qemuMonitor's
priv->monJSON bool, because of qemuDomainQemuAttach.
Signed-off-by: Ján Tomko
---
src/qemu/qemu_capabilities.c | 1 -
src/qemu/qemu_capabilities.h
On 04/02/2018 09:55 AM, Radostin Stoyanov wrote:
> Signed-off-by: Radostin Stoyanov
> ---
> src/lxc/lxc_container.c | 2 +-
> src/lxc/lxc_container.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
ACKed and pushed.
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://w
The vmware driver wants to execute vmware-vmx from the same directory in
which vmrun was found. However, on VMware Fusion 10 vmrun at
/Applications/VMware Fusion.app/Contents/Public/vmrun is a symlink
pointing to ../Library/vmrun. vmware-vmx cannot be found, as
it is not in PATH, but only in this L
These changes were required to get VMware Fusion working at all.
I tested with VMware Fusion 10.1.1 on macOS 10.12 Sierra.
I am not sure whether calling virCapabilitiesInitCaches() makes sense at
all on macOS. This function looks highly specific to Linux as it relies
on /sys/devices/system, so it
This is also not fatal on other drivers.
Signed-off-by: Rainer Müller
---
src/vmware/vmware_conf.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/vmware/vmware_conf.c b/src/vmware/vmware_conf.c
index 891d9a47f..b9f18e6ac 100644
--- a/src/vmware/vmware_conf.c
+++ b/
The saga continues.
Turns out, this is bug in both libvirt AND kernel. Firstly, kernel uses
different CGroup for checking open() than for ioctl() [1]. However,
libvirt needs to allow all targets in the CGroup too. Not only it's
logical, kernel devel says it never worked. QEMU was able to open the
Signed-off-by: Michal Privoznik
---
docs/news.xml | 10 ++
1 file changed, 10 insertions(+)
diff --git a/docs/news.xml b/docs/news.xml
index 87f52e83ef..065b60b6eb 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -49,6 +49,16 @@
+
+
+ Improve h
This helper fetches dependencies for given device mapper target.
At the same time, we need to provide a dummy log function because
by default libdevmapper prints out error messages to stderr which
we need to suppress.
Signed-off-by: Michal Privoznik
---
src/libvirt_private.syms | 4 +
src/uti
https://bugzilla.redhat.com/show_bug.cgi?id=1557769
Problem with device mapper targets is that there can be several
other devices 'hidden' behind them. For instance, /dev/dm-1 can
consist of /dev/sda, /dev/sdb and /dev/sdc. Therefore, when
setting up devices CGroup and namespaces we have to take t
On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
It's been a while since we last bumped the minimum QEMU version.
Let's get rid of -help parsing and bring our test suite closer
to real world usage by implying lots of capabilities.
Ján Tomko (44):
The following patches were > 300 kB:
Since the introduction of log tuning capabilities to virt-admin by
@06b91785, this has been a much needed missing improvement on the way to
deprecate the global 'log_level'.
Signed-off-by: Erik Skultety
---
src/remote/libvirtd.conf | 4 +++-
src/util/virlog.c| 44 +++
First, 2 tiny fixes along the way, then the actual change, which lets you do
the following for example during runtime:
virt-admin daemon-log-filters "1:* 4:remote 4:json"
which previously, given the default config setting log_level=3, translated into
virt-admin daemon-log-filters \
"1:acce
Signed-off-by: Erik Skultety
---
docs/news.xml | 12
1 file changed, 12 insertions(+)
diff --git a/docs/news.xml b/docs/news.xml
index 87f52e83e..6dab4844d 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -47,6 +47,18 @@
supported. In fact, kernel has been supporting thi
On Tue, Apr 03, 2018 at 10:29:55AM +0200, Katerina Koukiou wrote:
> * Implemented Suspend and Resume APIs.
> * Reused virsh functions for taking the Event Strings names from ENUM.
> * Merged all Domain Lifecycle events signals into one signal.
>
> Changes from v3:
> * s/arg2/arg1/ since Event Type
This was some copy-paste leftover.
Signed-off-by: Erik Skultety
---
src/util/virlog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/virlog.c b/src/util/virlog.c
index dd927f0ba..5810643e1 100644
--- a/src/util/virlog.c
+++ b/src/util/virlog.c
@@ -1699,7 +1699,7 @@
When applying the log filters, one has to define the more specific
filters before the generic ones, because the first filter that matches
will be applied. However, we've been missing this information in the
config, so it always has been a trial-error scenario figuring out that
e.g. '4:util 1:util.p
On Tue, Apr 03, 2018 at 10:30:00AM +0200, Katerina Koukiou wrote:
> Instead of having multiple signals regarding to domain events,
> like DomainStarted, DomainUndefined etc, we will have only one
> called DomainEvents, and the specific event type will be specified in
> the signals arguments.
>
> T
On Tue, Apr 03, 2018 at 10:29:59AM +0200, Katerina Koukiou wrote:
> This function replaces the manual translation of Event ENUMS.
>
> Signed-off-by: Katerina Koukiou
> ---
> src/events.c | 55 +--
> 1 file changed, 21 insertions(+), 34 deletion
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.Domain.xml | 4
src/domain.c| 21 +
test/test_domain.py | 15 +++
3 files changed, 40 insertions(+)
diff --git a/data/org.libvirt.Domain.xml b/data/org.libvirt.Domain.xml
index 3921
Instead of having multiple signals regarding to domain events,
like DomainStarted, DomainUndefined etc, we will have only one
called DomainEvents, and the specific event type will be specified in
the signals arguments.
The domain name argument in not needed in the signal since we can
fetch it from
The functions were copied from src/util/virutil.* files from
libvirt project
Signed-off-by: Katerina Koukiou
---
src/util.c | 27 +++
src/util.h | 28
2 files changed, 55 insertions(+)
diff --git a/src/util.c b/src/util.c
index d6c27f3..be651
This function replaces the manual translation of Event ENUMS.
Signed-off-by: Katerina Koukiou
---
src/events.c | 55 +--
1 file changed, 21 insertions(+), 34 deletions(-)
diff --git a/src/events.c b/src/events.c
index dada55f..1877115 100644
-
Signed-off-by: Katerina Koukiou
---
data/org.libvirt.Domain.xml | 4
src/domain.c| 21 +
test/test_domain.py | 17 +
3 files changed, 42 insertions(+)
diff --git a/data/org.libvirt.Domain.xml b/data/org.libvirt.Domain.xml
index f3
1 - 100 of 108 matches
Mail list logo
