[libvirt] [PATCH] Give other software a fair chance

Libvirt's so good, so solid that it almost feels like other software stand no chance. Other applications are buggy, unstable, crashing, etc. But not libvirt. Therefore, it seems only fair that we introduce some bugs so developers of the other applications don't feel that bad. Signed-off-by:

Re: [libvirt] [PATCH 01/11] hyperv: fixed typo in function name.

2017-03-30 18:47 GMT+02:00 Dawid Zamirski : > that is: s/hyperyVerifyresponse/hypervVerifyResponse/ s/hyperyVerifyresponse/hyperyVerifyResponse/ I'll fix that before pushing it :) ACK and pushed. Unfortunately, that's as far as I got today. I had to spend the better part

Re: [libvirt] [PATCH] Document virDomainAbortJob behavior for post-copy migration

On Fri, Mar 31, 2017 at 21:32:32 +0200, Martin Kletzander wrote: > On Fri, Mar 31, 2017 at 08:44:08PM +0200, Jiri Denemark wrote: > >https://bugzilla.redhat.com/show_bug.cgi?id=1389313 > > > >Signed-off-by: Jiri Denemark > >--- > > src/libvirt-domain.c | 7 +-- > > 1 file

Re: [libvirt] [PATCH] Document virDomainAbortJob behavior for post-copy migration

On Fri, Mar 31, 2017 at 08:44:08PM +0200, Jiri Denemark wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1389313 Signed-off-by: Jiri Denemark --- src/libvirt-domain.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) Makes perfect sense. ACK. Do comments

[libvirt] [PATCH] Document virDomainAbortJob behavior for post-copy migration

https://bugzilla.redhat.com/show_bug.cgi?id=1389313 Signed-off-by: Jiri Denemark --- src/libvirt-domain.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index 26da0e7f3..4670c54e5 100644 ---

[libvirt] [PATCH 7/7] cpu: Drop feature filtering from virCPUUpdate

Because of the changes done in the previous commit, @host is already a migratable CPU and there's no need to do any additional filtering. Signed-off-by: Jiri Denemark --- src/cpu/cpu_x86.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git

[libvirt] [PATCH 6/7] qemu: Pass migratable host model to virCPUUpdate

This will allow us to drop feature filtering from virCPUUpdate where it was just a hack. Signed-off-by: Jiri Denemark --- src/qemu/qemu_capabilities.c | 19 ++- src/qemu/qemu_capabilities.h | 3 ++- src/qemu/qemu_command.c | 2 +-

[libvirt] [PATCH 2/7] qemu: Move common code in virQEMUCapsInitCPUModel one layer up

Signed-off-by: Jiri Denemark --- src/qemu/qemu_capabilities.c | 25 ++--- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index b1245ad5d..1a15750a3 100644 ---

[libvirt] [PATCH 4/7] qemu: Move qemuCaps->{kvm, tcg}CPUModel into a struct

We will need to store two more host CPU models and nested structs look better than separate items with long complicated names. Signed-off-by: Jiri Denemark --- src/qemu/qemu_capabilities.c | 65 ++-- 1 file changed, 39 insertions(+),

[libvirt] [PATCH 1/7] cpu: Introduce virCPUCopyMigratable

This new internal API makes a copy of virCPUDef while removing all features which would block migration. It uses cpu_map.xml as a database of such features, which should only be used as a fallback when we cannot get the data from a hypervisor. The main goal of this API is to decouple this

[libvirt] [PATCH 3/7] qemu: Add migratable parameter to virQEMUCapsInitCPUModel

The caller can ask for a migratable CPU model by passing true for the new parameter. Signed-off-by: Jiri Denemark --- src/qemu/qemu_capabilities.c | 36 +--- src/qemu/qemu_capspriv.h | 3 ++- tests/cputest.c | 2 +- 3 files

[libvirt] [PATCH 0/7] qemu: Use migratable host CPU model from QEMU

Current libvirt makes a migratable host CPU model by removing features marked in cpu_map.xml with migratable='no'. This is not ideal because cpu_map.xml is a static database while feature migrtability may differ depending on a hypervisor or its version. Thus we should preferably use the data we

[libvirt] [PATCH 5/7] qemu: Store migratable host CPU model in qemuCaps

Signed-off-by: Jiri Denemark --- src/qemu/qemu_capabilities.c | 91 ++-- 1 file changed, 71 insertions(+), 20 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index c75aa570c..b426a5abc 100644 ---

Re: [libvirt] libvirtd not responding to virsh, results in virsh hanging

On 03/31/2017 11:30 AM, Chris Friesen wrote: On 03/31/2017 11:21 AM, Chris Friesen wrote: I ran tcpdump looking for TCP traffic between the two libvirtd processes, and was unable to see any after several minutes. So it doesn't look like there is any regular keepalive messaging going on

Re: [libvirt] libvirtd not responding to virsh, results in virsh hanging -- correction

On 03/31/2017 11:21 AM, Chris Friesen wrote: I ran tcpdump looking for TCP traffic between the two libvirtd processes, and was unable to see any after several minutes. So it doesn't look like there is any regular keepalive messaging going on (/etc/libvirt/libvirtd.conf doesn't specify any

Re: [libvirt] libvirtd not responding to virsh, results in virsh hanging

Hi, I finally got a chance to take another look at this issue. We've reproduced it in another test lab. New information below. On 03/18/2017 12:41 AM, Michal Privoznik wrote: On 17.03.2017 23:21, Chris Friesen wrote: Hi, We've recently run into an issue with libvirt 1.2.17 in the context

Re: [libvirt] [PATCH v2 2/2] Introduce and use virDomainDiskEmptySource

On 03/31/2017 04:17 PM, Peter Krempa wrote: On Fri, Mar 31, 2017 at 16:02:14 +0200, Michal Privoznik wrote: Currently, if we want to zero out disk source (e,g, due to startupPolicy when starting up a domain) we use virDomainDiskSetSource(disk, NULL). This works well for file based storage

Re: [libvirt] [PATCH 15/16] tests: Add tests for caches into vircaps2xmltest

On Fri, Mar 31, 2017 at 09:23:39PM +0800, Eli Qiao wrote: > > How about for l3: > > Well, yes, kind of what you had in your patches. Wasn't it without the 'cbm_len' and 'avail'? The 'cbm_len' is avail/min, so it's redundant and avail is the same as the size of the whole cache, right? Also

Re: [libvirt] [PATCH 1/2] networkUpdateState: Create virMacMap module more frequently

On 03/31/2017 03:41 PM, Laine Stump wrote: On 03/31/2017 07:20 AM, Michal Privoznik wrote: On 03/30/2017 06:00 PM, Laine Stump wrote: On 03/28/2017 05:08 AM, Michal Privoznik wrote: On 03/28/2017 02:22 AM, Laine Stump wrote: On 03/22/2017 10:43 AM, Michal Privoznik wrote:

Re: [libvirt] [PATCH v2 2/2] Introduce and use virDomainDiskEmptySource

On Fri, Mar 31, 2017 at 16:02:14 +0200, Michal Privoznik wrote: > Currently, if we want to zero out disk source (e,g, due to > startupPolicy when starting up a domain) we use > virDomainDiskSetSource(disk, NULL). This works well for file > based storage (storage type file, dir, or block). But it

[libvirt] [PATCH v2 2/2] Introduce and use virDomainDiskEmptySource

Currently, if we want to zero out disk source (e,g, due to startupPolicy when starting up a domain) we use virDomainDiskSetSource(disk, NULL). This works well for file based storage (storage type file, dir, or block). But it doesn't work at all for other types like volume and network. So imagine

Re: [libvirt] [PATCH 1/2] networkUpdateState: Create virMacMap module more frequently

On 03/31/2017 07:20 AM, Michal Privoznik wrote: > On 03/30/2017 06:00 PM, Laine Stump wrote: >> On 03/28/2017 05:08 AM, Michal Privoznik wrote: >>> On 03/28/2017 02:22 AM, Laine Stump wrote: On 03/22/2017 10:43 AM, Michal Privoznik wrote: >>> > > Signed-off-by: Michal Privoznik

Re: [libvirt] [PATCH 2/2] Introduce and use virDomainDiskZeroSource

On 03/31/2017 03:23 PM, Peter Krempa wrote: On Fri, Mar 31, 2017 at 15:03:35 +0200, Michal Privoznik wrote: On 03/31/2017 02:18 PM, Peter Krempa wrote: On Fri, Mar 31, 2017 at 13:13:51 +0200, Michal Privoznik wrote: Currently, if we want to zero out disk source (e,g, due to startupPolicy when

Re: [libvirt] [PATCH 2/2] Introduce and use virDomainDiskZeroSource

On Fri, Mar 31, 2017 at 15:03:35 +0200, Michal Privoznik wrote: > On 03/31/2017 02:18 PM, Peter Krempa wrote: > > On Fri, Mar 31, 2017 at 13:13:51 +0200, Michal Privoznik wrote: > > > Currently, if we want to zero out disk source (e,g, due to > > > startupPolicy when starting up a domain) we use >

Re: [libvirt] [PATCH 15/16] tests: Add tests for caches into vircaps2xmltest

> > > > How about for l3: > > > reserved=“2816"/> > > > > > Well, yes, kind of what you had in your patches. Wasn't it without the > 'cbm_len' and 'avail'? The 'cbm_len' is avail/min, so it's redundant > and avail is the same as the size of the whole cache, right? Also > 'reserved'

Re: [libvirt] [PATCH 15/16] tests: Add tests for caches into vircaps2xmltest

On Fri, Mar 31, 2017 at 08:33:12PM +0800, Eli Qiao wrote: On Friday, 31 March 2017 at 7:19 PM, Martin Kletzander wrote: On Fri, Mar 31, 2017 at 09:56:32AM +0800, Eli Qiao wrote: > > > > Okay, cool, this comes better than my patches and have some differences. > I am open with this as long as

Re: [libvirt] [PATCH 2/2] Introduce and use virDomainDiskZeroSource

On 03/31/2017 02:18 PM, Peter Krempa wrote: On Fri, Mar 31, 2017 at 13:13:51 +0200, Michal Privoznik wrote: Currently, if we want to zero out disk source (e,g, due to startupPolicy when starting up a domain) we use virDomainDiskSetSource(disk, NULL). This works well for file based storage

Re: [libvirt] [PATCH 10/16] util: Add virSysfsGetCPUCache* functions

On Friday, 31 March 2017 at 7:39 PM, Martin Kletzander wrote: > On Fri, Mar 31, 2017 at 05:32:16PM +0800, Eli Qiao wrote: > > > > > > On Thursday, 30 March 2017 at 10:03 PM, Martin Kletzander wrote: > > > > > Signed-off-by: Martin Kletzander > >

Re: [libvirt] [PATCH 15/16] tests: Add tests for caches into vircaps2xmltest

On Friday, 31 March 2017 at 7:19 PM, Martin Kletzander wrote: > On Fri, Mar 31, 2017 at 09:56:32AM +0800, Eli Qiao wrote: > > > > > > > Okay, cool, this comes better than my patches and have some differences. > > I am open with this as long as that it can meet cache allocation requires > >

Re: [libvirt] [PATCH 2/2] Introduce and use virDomainDiskZeroSource

On Fri, Mar 31, 2017 at 13:13:51 +0200, Michal Privoznik wrote: > Currently, if we want to zero out disk source (e,g, due to > startupPolicy when starting up a domain) we use > virDomainDiskSetSource(disk, NULL). This works well for file > based storage (storage type file, dir, or block). But it

Re: [libvirt] [PATCH 2/2] Introduce and use virDomainDiskZeroSource

On Fri, Mar 31, 2017 at 01:13:51PM +0200, Michal Privoznik wrote: Currently, if we want to zero out disk source (e,g, due to startupPolicy when starting up a domain) we use virDomainDiskSetSource(disk, NULL). This works well for file based storage (storage type file, dir, or block). But it

[libvirt] [PATCH 4/5] qemu: hotplug: Add validation for coldplug of individual vcpus

Validate that users don't try to disable vcpu 0 and reject attempt to modify a vcpu to the state it is currently in. --- src/qemu/qemu_hotplug.c | 36 1 file changed, 36 insertions(+) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index

[libvirt] [PATCH 5/5] qemu: hotplug: Validate that vcpu-hotplug does not break config

Make sure that non-hotpluggable vcpus stay clustered at the beginning after modifying persistent definition. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1437010 --- src/qemu/qemu_hotplug.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/src/qemu/qemu_hotplug.c

[libvirt] [PATCH 2/5] qemu: hotplug: Fix formatting strings in qemuDomainFilterHotplugVcpuEntities

'next' is declared as 'ssize_t' so use '%zd' --- src/qemu/qemu_hotplug.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index b5b520d8c..48de6b815 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@

[libvirt] [PATCH 0/5] qemu: fix individual vcpu hotplug code

Resolve a few corner cases which would create invalid configurations or produce bad error messages. Peter Krempa (5): qemu: hotplug: Iterate over vcpu 0 in individual vcpu hotplug code qemu: hotplug: Fix formatting strings in qemuDomainFilterHotplugVcpuEntities qemu: hotplug: Clear vcpu

[libvirt] [PATCH 1/5] qemu: hotplug: Iterate over vcpu 0 in individual vcpu hotplug code

Buggy condition meant that vcpu0 would not be iterated in the checks. Since it's not hotpluggable anyways we would not be able to break the configuration of a live VM. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1437013 --- src/qemu/qemu_hotplug.c | 6 +++--- 1 file changed, 3

[libvirt] [PATCH 3/5] qemu: hotplug: Clear vcpu ordering for coldplug of vcpus

Vcpu order is required to stay sequential. Clear the order on cpu coldplug to avoid issues with removing vcpus out of sequence. --- src/qemu/qemu_hotplug.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index

Re: [libvirt] [PATCH 1/2] virDomainDiskDefForeachPath: Prefer virStorageSourceIsLocalStorage

On Fri, Mar 31, 2017 at 01:13:50PM +0200, Michal Privoznik wrote: Signed-off-by: Michal Privoznik --- src/conf/domain_conf.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) ACK and safe for freeze. diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c

Re: [libvirt] [PATCH 10/16] util: Add virSysfsGetCPUCache* functions

On Fri, Mar 31, 2017 at 05:32:16PM +0800, Eli Qiao wrote: On Thursday, 30 March 2017 at 10:03 PM, Martin Kletzander wrote: Signed-off-by: Martin Kletzander --- src/libvirt_private.syms | 5 +++ src/util/virsysfs.c | 102

Re: [libvirt] libvirt 2.3.0 and later versions hanging

On 03/30/2017 01:40 PM, Paul Gildea wrote: Hi, I am starting a libvritd process when booting up an embedded networking system via python, like so: subprocess.Popen(["libvirtd","-d"],stdout=subprocess.PIPE,stderr=subprocess.PIPE) This runs and works fine for version 1.2.20. However after I

[libvirt] [PATCH 2/2] Introduce and use virDomainDiskZeroSource

Currently, if we want to zero out disk source (e,g, due to startupPolicy when starting up a domain) we use virDomainDiskSetSource(disk, NULL). This works well for file based storage (storage type file, dir, or block). But it doesn't work at all for other types like volume and network. So imagine

Re: [libvirt] [PATCH 15/16] tests: Add tests for caches into vircaps2xmltest

On Fri, Mar 31, 2017 at 09:56:32AM +0800, Eli Qiao wrote: Okay, cool, this comes better than my patches and have some differences. I am open with this as long as that it can meet cache allocation requires and everyone will be happy. I am ++ for this. But I am not sure expose all of cache

Re: [libvirt] [PATCH 1/2] networkUpdateState: Create virMacMap module more frequently

On 03/30/2017 06:00 PM, Laine Stump wrote: On 03/28/2017 05:08 AM, Michal Privoznik wrote: On 03/28/2017 02:22 AM, Laine Stump wrote: On 03/22/2017 10:43 AM, Michal Privoznik wrote: Signed-off-by: Michal Privoznik --- src/network/bridge_driver.c | 21

[libvirt] [PATCH 1/2] virDomainDiskDefForeachPath: Prefer virStorageSourceIsLocalStorage

Signed-off-by: Michal Privoznik --- src/conf/domain_conf.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 1b0a55b..01553b5 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@

Re: [libvirt] [PATCH 06/16] util: Add virSysfsDirOpen

On Fri, Mar 31, 2017 at 09:32:06AM +0800, Eli Qiao wrote: On Thursday, 30 March 2017 at 10:03 PM, Martin Kletzander wrote: Signed-off-by: Martin Kletzander --- src/libvirt_private.syms | 1 + src/util/virsysfs.c | 17 -

[libvirt] [PATCH 0/2] Don't kill domains on daemon restart

Patch 1/2 is just a cleanup; patch 2/2 fixes the actual issue. Michal Privoznik (2): virDomainDiskDefForeachPath: Prefer virStorageSourceIsLocalStorage Introduce and use virDomainDiskZeroSource src/conf/domain_conf.c | 27 --- src/conf/domain_conf.h | 1 +

Re: [libvirt] [PATCH V2 1/2] util: Add more virsysfs functions for handling resctrl sysfs

On Fri, Mar 31, 2017 at 09:26:34AM +0800, Eli Qiao wrote: > +# util/virresctrl.h > +virResCtrlAvailable; > +virResCtrlInit; > + > This has nothing to do in the patch Okay, this should be involved by mistake while rebasing. > # util/virrotatingfile.h > virRotatingFileReaderConsume; >

Re: [libvirt] [PATCH V3] util: Add more virsysfs functions for handling resctrl sysfs

On Fri, Mar 31, 2017 at 12:28:26PM +0200, Erik Skultety wrote: #define VIR_SYSFS_VALUE_MAXLEN 8192 #define SYSFS_SYSTEM_PATH "/sys/devices/system" +#define SYSFS_RESCTRL_PATH "/sys/fs/resctrl" static const char *sysfs_system_path = SYSFS_SYSTEM_PATH; +static const char *sysfs_resctrl_path =

Re: [libvirt] [PATCH V3] util: Add more virsysfs functions for handling resctrl sysfs

> #define VIR_SYSFS_VALUE_MAXLEN 8192 > #define SYSFS_SYSTEM_PATH "/sys/devices/system" > +#define SYSFS_RESCTRL_PATH "/sys/fs/resctrl" > > static const char *sysfs_system_path = SYSFS_SYSTEM_PATH; > +static const char *sysfs_resctrl_path = SYSFS_RESCTRL_PATH; > > > void

Re: [libvirt] [PATCH] admin: Throw a system error when 'open' fails on user-provided output

> ACK and safe for freeze. > > Jirka Thanks, I pushed the patch. Erik -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH V3] util: Add more virsysfs functions for handling resctrl sysfs

Extended /sys/fs/resctrl sysfs handling such as: Read string/uint. Write string. Create/remove directory. All these operations will be while we are enabled CAT feature later. Signed-off-by: Eli Qiao --- src/libvirt_private.syms | 9 +++ src/util/virsysfs.c

Re: [libvirt] [PATCH 10/16] util: Add virSysfsGetCPUCache* functions

On Thursday, 30 March 2017 at 10:03 PM, Martin Kletzander wrote: > Signed-off-by: Martin Kletzander (mailto:mklet...@redhat.com)> > --- > src/libvirt_private.syms | 5 +++ > src/util/virsysfs.c | 102 +++ > src/util/virsysfs.h |

Re: [libvirt] [PATCH] admin: Throw a system error when 'open' fails on user-provided output

On Fri, Mar 31, 2017 at 10:29:25 +0200, Erik Skultety wrote: > There was an unhandled 'open' call which resulted in: > > "error: Library function returned error but did not set virError" > > Even if this happens during the daemon's start when we still don't have > any set of outputs defined yet,

[libvirt] [PATCH] admin: Throw a system error when 'open' fails on user-provided output

There was an unhandled 'open' call which resulted in: "error: Library function returned error but did not set virError" Even if this happens during the daemon's start when we still don't have any set of outputs defined yet, we can safely report an error, since we automatically fallback to stderr

Re: [libvirt] [GSOC] project libvirt fuzzing

On Thu, Mar 16, 2017 at 1:29 PM, Daniel P. Berrange wrote: > On Tue, Mar 07, 2017 at 12:27:58AM -0500, D L wrote: > > On Sun, Mar 5, 2017 at 2:47 AM, Michal Privoznik > wrote: > > Regarding fuzzing, I think we can try several fuzzing tools to run in > >

Re: [libvirt] How about fuzz testing on oss-fuzz?

On Fri, Mar 31, 2017 at 03:57:41 -0400, Dan wrote: > Hi all, > > I have seen libxml2 has already been added as a project in oss-fuzz [1]. > Any idea about libvirt? While we could do our own fuzzing of some form, do > we want to also try it out using google's free resource? The oss-fuzz project

[libvirt] How about fuzz testing on oss-fuzz?

Hi all, I have seen libxml2 has already been added as a project in oss-fuzz [1]. Any idea about libvirt? While we could do our own fuzzing of some form, do we want to also try it out using google's free resource? Dan [1] https://github.com/google/oss-fuzz -- libvir-list mailing list

Re: [libvirt] [PATCH v2 4/4] news: Add template for a section

On Wed, Mar 29, 2017 at 16:30:41 +0200, Ján Tomko wrote: > On Wed, Mar 29, 2017 at 09:28:16AM +0200, Peter Krempa wrote: > > After the release it's necessary to add a new section for the > > upcoming release. Add a template so that it does not have to be > > compiled over and over again. > >