When shutdown vm, the qemuProcessStop cleanup virtual interface in two steps:
1. qemuProcessKill kill qemu process, and vif disappeared
2. ovs-vsctl del-port from the ovs bridge
If start a vm in the middle of the two steps, the new vm will reused the vif,
but removed from ovs bridge by step 2
Thanks for your detailed analysis, I will remake a patch
发件人: Laine Stump
发送时间: Wednesday, June 17, 2020 7:46 AM
收件人: libvir-list@redhat.com
抄送: Daniel Henrique Barboza; Bingsong Si; Wei Gong
主题: Re: [PATCH] network: Fix a race condition when shutdown & start vm at the
same time
(BTW, this
On 6/17/20 4:54 AM, Paulo de Rezende Pinatti wrote:
On 17/06/20 06:01, Laine Stump wrote:
On 6/16/20 10:32 AM, Paulo de Rezende Pinatti wrote:
No default model should be added to the interface
entry at post parse when its actual network type is hostdev
as doing so might cause a mismatch
On 6/15/20 12:09 PM, Peter Krempa wrote:
There will be multiple places where we'll need to print nodenames from a
GSList of virStorageSource for testing purposes. Extract the code into a
function.
Signed-off-by: Peter Krempa
---
tests/qemublocktest.c | 27 ++-
1 file
On 6/15/20 12:09 PM, Peter Krempa wrote:
They will be replaced by a different set which will test scenarios
relevant for the new semantics.
Signed-off-by: Peter Krempa
---
tests/qemublocktest.c | 3 -
.../bitmap/snapshots-synthetic-broken.json| 837
Until recently, an would automatically be
assigned model "rtl8139" (the default on x86 machinetypes), which in
turn would lead to the device being assigned a PCI address on a
conventional PCI controller (i.e. a pcie-to-pci-bridge). If the
network was a typical Linux host bridge-based network that
On 6/15/20 12:09 PM, Peter Krempa wrote:
Upcoming patches are going to rewrite and semantically modify how
bitmaps are handled during blockjobs. This is possible as incremental
backup is not yet fully enabled.
As the changes are going to be incompatible with any current test data
remove all
On 6/15/20 12:09 PM, Peter Krempa wrote:
Signed-off-by: Peter Krempa
---
tests/qemublocktest.c | 2 ++
tests/qemublocktestdata/bitmapblockcommit/empty | 2 ++
2 files changed, 4 insertions(+)
create mode 100644 tests/qemublocktestdata/bitmapblockcommit/empty
On 6/15/20 12:09 PM, Peter Krempa wrote:
Signed-off-by: Peter Krempa
---
tests/qemublocktest.c | 3 +++
tests/qemublocktestdata/bitmapblockcopy/empty-deep-out.json| 0
tests/qemublocktestdata/bitmapblockcopy/empty-shallow-out.json | 0
3 files
On 6/15/20 12:09 PM, Peter Krempa wrote:
Use the new test data for checkpoint deletion testing. This test also
requires modification of the internals to allow checking for test
failure.
Signed-off-by: Peter Krempa
---
tests/qemublocktest.c | 13 +++--
On 6/15/20 12:09 PM, Peter Krempa wrote:
Use the new test data when calculating incremental backup operations. As
incremental backup fails with no bitmap the test code is modified to
allow testing this case too.
Signed-off-by: Peter Krempa
---
tests/qemublocktest.c |
On 6/15/20 12:09 PM, Peter Krempa wrote:
Add test data for an image without bitmaps.
Signed-off-by: Peter Krempa
---
tests/qemublocktest.c | 4 ++
tests/qemublocktestdata/bitmap/empty.json | 70 +++
tests/qemublocktestdata/bitmap/empty.out | 1 +
On 6/15/20 12:09 PM, Peter Krempa wrote:
Fetch the checkpoint list for every disk specifically based on the new
per-disk 'incremental' field.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_backup.c | 108 -
1 file changed, 52 insertions(+), 56
On 6/17/20 4:19 PM, Michal Privoznik wrote:
On 6/10/20 8:35 PM, Daniel Henrique Barboza wrote:
changes in v2:
- removed patch 5/5
Gitlab link: https://gitlab.com/danielhb/libvirt/-/tree/vcpus_numa_v2
v1 link: https://www.redhat.com/archives/libvir-list/2020-June/msg00016.html
Daniel
On 6/15/20 12:09 PM, Peter Krempa wrote:
In preparation to allow heterogenous backups store the 'incremental'
field per-disk and fill it by default from the per-backup field.
Having this will be important once we'll want to allow incremental
backup working while hotplugging a new disk.
On 6/10/20 8:35 PM, Daniel Henrique Barboza wrote:
changes in v2:
- removed patch 5/5
Gitlab link: https://gitlab.com/danielhb/libvirt/-/tree/vcpus_numa_v2
v1 link: https://www.redhat.com/archives/libvir-list/2020-June/msg00016.html
Daniel Henrique Barboza (4):
numa_conf.c: add helper
On 6/15/20 12:09 PM, Peter Krempa wrote:
If a disk is not captured by one of the intermediate checkpoints the
code would fail, but we can easily calculate the bitmaps to merge
correctly by skipping over checkpoints which don't describe the disk.
If I'm understanding the setup, you can hit this
On 6/15/20 12:09 PM, Peter Krempa wrote:
The algorithm is getting quite complex. Split out the lookup of range of
backing chain storage sources and bitmaps contained in them which
correspond to one checkpoint.
Signed-off-by: Peter Krempa
---
src/qemu/qemu_backup.c | 111
The sandbox build needs to validate one axis
- A variety of libvirt versions
We test a variety of libvirt versions by running a build against the
distro provided libvirt packages. All that is then missing is a build
against the latest libvirt git master, which only needs to be run on
a single
On Wed, 2020-06-17 at 15:51 +0100, Daniel P. Berrangé wrote:
> The glib build needs to validate two axis
>
> - A variety of libvirt versions
> - Native and mingw
>
> We test a variety of libvirt versions by running a build against the
> distro provided libvirt packages. All that is then
On Wed, 2020-06-17 at 17:27 +0200, Erik Skultety wrote:
> On Wed, Jun 17, 2020 at 04:56:28PM +0200, Andrea Bolognani wrote:
> > On Wed, 2020-06-17 at 16:17 +0200, Erik Skultety wrote:
> > > +++ b/ci/Makefile
> > > @@ -266,4 +266,6 @@ ci-help:
> > > @echo "CI_CLEAN=0 - do not delete
On 6/17/20 12:55 PM, Boris Fiuczynski wrote:
Hi Laine,
do you plan to push this patch?
Already did, about an hour ago.
On 6/17/20 6:01 AM, Laine Stump wrote:
On 6/16/20 10:32 AM, Paulo de Rezende Pinatti wrote:
No default model should be added to the interface
entry at post parse when its actual network type is hostdev
as doing so might cause a mismatch between the interface
definition and its actual device
+libvir-list
On Wed, Jun 17, 2020 at 05:04:12PM +0100, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > On Wed, Jun 17, 2020 at 02:46:52PM +0100, Dr. David Alan Gilbert wrote:
> > > * Laszlo Ersek (ler...@redhat.com) wrote:
> > > > On 06/16/20 19:14, Guilherme
+libvir-list
On Wed, Jun 17, 2020 at 05:04:12PM +0100, Dr. David Alan Gilbert wrote:
> * Eduardo Habkost (ehabk...@redhat.com) wrote:
> > On Wed, Jun 17, 2020 at 02:46:52PM +0100, Dr. David Alan Gilbert wrote:
> > > * Laszlo Ersek (ler...@redhat.com) wrote:
> > > > On 06/16/20 19:14, Guilherme
On Wed, Jun 17, 2020 at 04:51:50PM +0100, Daniel P. Berrangé wrote:
> Given our platform support matrix we can cull many conditionally
> defined constants and rely on system headers
>
> Daniel P. Berrangé (3):
> lxc: drop compat code for mount constants
> lxc: drop compat code for clone
Given our supported platform matrix, we can safely assume that
all the capability constants we need are defined by the system
headers.
Signed-off-by: Daniel P. Berrangé
---
src/lxc/lxc_container.c | 114
1 file changed, 114 deletions(-)
diff --git
Given our supported platform matrix, we can safely assume that
all the clone constants we need are defined by the system
headers.
Signed-off-by: Daniel P. Berrangé
---
src/lxc/lxc_container.c | 20
1 file changed, 20 deletions(-)
diff --git a/src/lxc/lxc_container.c
Given our supported platform matrix, we can safely assume that
all the mount constants we need are defined by the system
headers.
Signed-off-by: Daniel P. Berrangé
---
src/lxc/lxc_container.c | 17 -
src/lxc/lxc_controller.c | 8
2 files changed, 25 deletions(-)
diff
Given our platform support matrix we can cull many conditionally
defined constants and rely on system headers
Daniel P. Berrangé (3):
lxc: drop compat code for mount constants
lxc: drop compat code for clone constants
lxc: drop compat code for capability constants
src/lxc/lxc_container.c
On Wed, Jun 17, 2020 at 04:56:28PM +0200, Andrea Bolognani wrote:
> On Wed, 2020-06-17 at 16:17 +0200, Erik Skultety wrote:
> > +++ b/ci/Makefile
> > @@ -266,4 +266,6 @@ ci-help:
> > @echo "CI_CLEAN=0 - do not delete '$(CI_SCRATCHDIR)' after
> > completion"
> > @echo "
On Wed, Jun 17, 2020 at 04:42:00PM +0200, Andrea Bolognani wrote:
> On Wed, 2020-06-17 at 16:05 +0200, Erik Skultety wrote:
> > On Wed, Jun 17, 2020 at 03:18:48PM +0200, Andrea Bolognani wrote:
> > > On Wed, 2020-06-17 at 12:00 +0200, Erik Skultety wrote:
> > > > +ci-distcheck@%:
> > > > +
KVM Forum 2020 is becoming a virtual experience this year in light of
the COVID-19 situation and will take place online on October 28-30, as
planned.
The virtual event will continue to deliver the same content you would
have received in-person (keynotes, conference sessions, BoFs, co-located
On Wed, 2020-06-17 at 16:17 +0200, Erik Skultety wrote:
> +++ b/ci/Makefile
> @@ -266,4 +266,6 @@ ci-help:
> @echo "CI_CLEAN=0 - do not delete '$(CI_SCRATCHDIR)' after
> completion"
> @echo "CI_REUSE=1 - re-use existing '$(CI_SCRATCHDIR)' content"
> @echo "
The glib build needs to validate two axis
- A variety of libvirt versions
- Native and mingw
We test a variety of libvirt versions by running a build against the
distro provided libvirt packages. All that is then missing is a build
against the latest libvirt git master, which only needs to
On Wed, 2020-06-17 at 16:05 +0200, Erik Skultety wrote:
> On Wed, Jun 17, 2020 at 03:18:48PM +0200, Andrea Bolognani wrote:
> > On Wed, 2020-06-17 at 12:00 +0200, Erik Skultety wrote:
> > > +ci-distcheck@%:
> > > + $(MAKE) -C $(CI_ROOTDIR) ci-build@$* CI_MAKE_ARGS="distcheck"
> >
> > I'm not sure
On a Tuesday in 2020, wangjian wrote:
We used asan to find some memory leaks in virtlogd. In the virThreadPoolFree
function,
When job->data is of type virNetServerJobPtr, the following memory leak problem
exists.
1. job->data is not released
Direct leak of 24 byte(s) in 1 object(s) allocated
On Wed, 2020-06-17 at 14:35 +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 17, 2020 at 12:54:56PM +0200, Andrea Bolognani wrote:
> > On Thu, 2020-06-11 at 17:42 +0100, Daniel P. Berrangé wrote:
> > > +.script_variables: _variables |
> > > + export MAKEFLAGS="-j$(getconf _NPROCESSORS_ONLN)"
> > >
Signed-off-by: Jiri Denemark
---
src/cpu_map/x86_features.xml| 6 ++
tests/cputestdata/x86_64-cpuid-Cooperlake-enabled.xml | 2 +-
tests/cputestdata/x86_64-cpuid-Cooperlake-json.xml | 1 +
Signed-off-by: Jiri Denemark
---
src/cpu_map/x86_features.xml | 32 +++
.../x86_64-cpuid-A10-5800K-disabled.xml | 1 +
.../x86_64-cpuid-A10-5800K-enabled.xml| 1 +
.../x86_64-cpuid-A10-5800K-guest.xml | 10 ++
The CPUID data in *-{disabled,enabled}.xml convert feature names from
the corresponding *.json file into raw CPUID and MSR data and thus some
of them may need to be updated when new features are added into the CPU
map.
Signed-off-by: Jiri Denemark
---
src/cpu_map/x86_features.xml
Signed-off-by: Jiri Denemark
---
src/cpu_map/x86_features.xml | 12
.../x86_64-cpuid-Ice-Lake-Server-disabled.xml| 2 +-
.../x86_64-cpuid-Ice-Lake-Server-guest.xml | 1 +
.../x86_64-cpuid-Ice-Lake-Server-host.xml| 1 +
The features were added to QEMU long ago.
Jiri Denemark (4):
cpu_map: Request test files update when adding x86 features
cpu_map: Add missing x86 features in 0x7 CPUID leaf
cpu_map: Add missing x86 features in 0x8008 CPUID leaf
cpu_map: Add missing AMD SVM features
Document the CI_MAKE_ARGS and CI_CONFIGURE_ARGS so that users don't have
to skim through the Makefile to be able to pass arbitrary recognized
make targets to the build system.
Signed-off-by: Erik Skultety
---
ci/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ci/Makefile
On Wed, Jun 17, 2020 at 03:18:48PM +0200, Andrea Bolognani wrote:
> On Wed, 2020-06-17 at 12:00 +0200, Erik Skultety wrote:
> > +ci-distcheck@%:
> > + $(MAKE) -C $(CI_ROOTDIR) ci-build@$* CI_MAKE_ARGS="distcheck"
>
> I'm not sure we want to have such a proxy for all possible make
> targets,
On a Wednesday in 2020, Peter Krempa wrote:
On Wed, Jun 17, 2020 at 14:52:38 +0200, Ján Tomko wrote:
On a Wednesday in 2020, Peter Krempa wrote:
> When a block copy job fails prior to reaching the synchronized phase
> while we are waiting for the job to finish virsh would print the
> following:
On Wed, Jun 17, 2020 at 14:52:38 +0200, Ján Tomko wrote:
> On a Wednesday in 2020, Peter Krempa wrote:
> > When a block copy job fails prior to reaching the synchronized phase
> > while we are waiting for the job to finish virsh would print the
> > following:
> >
> > $ virsh blockcopy
On Wed, Jun 17, 2020 at 12:54:56PM +0200, Andrea Bolognani wrote:
> On Thu, 2020-06-11 at 17:42 +0100, Daniel P. Berrangé wrote:
> > ci/libvirt-centos-7.Dockerfile| 88 +++
> > ci/libvirt-centos-8.Dockerfile| 64 +
> > ci/libvirt-centos-stream.Dockerfile
On Wed, 2020-06-17 at 12:00 +0200, Erik Skultety wrote:
> +ci-distcheck@%:
> + $(MAKE) -C $(CI_ROOTDIR) ci-build@$* CI_MAKE_ARGS="distcheck"
I'm not sure we want to have such a proxy for all possible make
targets, especially since CI_MAKE_ARGS exists and is specifically
intended for the
On a Wednesday in 2020, Peter Krempa wrote:
When a block copy job fails prior to reaching the synchronized phase
while we are waiting for the job to finish virsh would print the
following:
$ virsh blockcopy backup-test vda /tmp/dst.qcow2 --wait --reuse-external
--transient-job
error:
Copy
On 6/17/20 2:24 PM, Peter Krempa wrote:
When a block copy job fails prior to reaching the synchronized phase
while we are waiting for the job to finish virsh would print the
following:
$ virsh blockcopy backup-test vda /tmp/dst.qcow2 --wait --reuse-external
--transient-job
error:
Copy
When a block copy job fails prior to reaching the synchronized phase
while we are waiting for the job to finish virsh would print the
following:
$ virsh blockcopy backup-test vda /tmp/dst.qcow2 --wait --reuse-external
--transient-job
error:
Copy failed
The above message looks like we've
On a Wednesday in 2020, Bihong Yu wrote:
From 099707463944faeae75da640b0d1d780cb675406 Mon Sep 17 00:00:00 2001
From: Bihong Yu
Date: Tue, 16 Jun 2020 22:08:55 +0800
Subject: [PATCH] utils: check flags and errno before reporting errno
There are races condiction to make
On 6/17/20 12:00 PM, Erik Skultety wrote:
From time to time we see failures in our gitlab pipelines that we as
developers don't see locally, simply because we don't run "make
distcheck" that often which is what the gitlab containers run and which
can indeed reveal mistakes like not shipping the
On 6/17/20 9:58 AM, wangjian (AN) wrote:
1. Yes, our testers opened some compilation options, such as -fsanitizer=leak.
2. The version of libvirt we are using is 3.2.0. Our tester deployed a
long-lived environment and did many operations (he didn't remember what he did),
such as restarting
In a few cases we might set seclabels on a path outside of
namespaces. For instance, when restoring a domain from a file,
the file is opened, relabelled and only then the namespace is
created and the FD is passed to QEMU (see v6.3.0-rc1~108 for more
info). Therefore, when restoring the label on
After previous commit this function is used no more.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_security.c | 31 ---
src/qemu/qemu_security.h | 4
2 files changed, 35 deletions(-)
diff --git a/src/qemu/qemu_security.c b/src/qemu/qemu_security.c
index
The new name is virSecurityManagerDomainRestorePathLabel().
Signed-off-by: Michal Privoznik
---
src/libvirt_private.syms | 2 +-
src/qemu/qemu_security.c | 2 +-
src/security/security_apparmor.c | 9 +++
src/security/security_dac.c | 26 +++---
After previous commit this function is used no more.
Signed-off-by: Michal Privoznik
---
src/libvirt_private.syms | 1 -
src/security/security_apparmor.c | 9 -
src/security/security_dac.c | 20
src/security/security_driver.h | 4
When restoring a domain from a block device a harmless error is
reported. See 6/6 for explanation. But anyway, still worth fixing.
Michal Prívozník (6):
qemu: Use qemuSecurityDomainSetPathLabel() to set seclabes on not
saved state files
qemu: Drop unused qemuSecuritySetSavedStateLabel()
There are two places within qemu driver that misuse
qemuSecuritySetSavedStateLabel() to set seclabels on tempfiles
that are not state files: qemuDomainScreenshot() and
qemuDomainMemoryPeek(). They are doing so because of lack of
qemuSecurityDomainSetPathLabel() at the time of their
introduction.
The function calls virSecurityManagerDomainRestorePathLabel()
after all.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_driver.c | 2 +-
src/qemu/qemu_security.c | 8
src/qemu/qemu_security.h | 4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git
On Thu, 2020-06-11 at 17:42 +0100, Daniel P. Berrangé wrote:
> ci/libvirt-centos-7.Dockerfile| 88 +++
> ci/libvirt-centos-8.Dockerfile| 64 +
> ci/libvirt-centos-stream.Dockerfile | 58 +
> ci/libvirt-debian-10.Dockerfile |
On Wed, Jun 17, 2020 at 10:04:34AM +0200, Andrea Bolognani wrote:
> Fedora 30 has been EOL for almost a month now.
>
> Signed-off-by: Andrea Bolognani
> ---
> libvirt.spec.in | 2 +-
> mingw-libvirt.spec.in | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Pavel
>From time to time we see failures in our gitlab pipelines that we as
developers don't see locally, simply because we don't run "make
distcheck" that often which is what the gitlab containers run and which
can indeed reveal mistakes like not shipping the necessary test data.
Since most of us
Signed-off-by: Erik Skultety
---
Pushed as trivial.
ci/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ci/Makefile b/ci/Makefile
index a6a65bdc0f..7840cc8d89 100644
--- a/ci/Makefile
+++ b/ci/Makefile
@@ -48,7 +48,7 @@ CI_PREPARE_SCRIPT = $(CI_ROOTDIR)/prepare.sh
On 17/06/20 06:01, Laine Stump wrote:
On 6/16/20 10:32 AM, Paulo de Rezende Pinatti wrote:
No default model should be added to the interface
entry at post parse when its actual network type is hostdev
as doing so might cause a mismatch between the interface
definition and its actual device
Fedora 30 has been EOL for almost a month now.
Signed-off-by: Andrea Bolognani
---
libvirt.spec.in | 2 +-
mingw-libvirt.spec.in | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 262e66f3cc..450c97b46d 100644
---
1. Yes, our testers opened some compilation options, such as -fsanitizer=leak.
2. The version of libvirt we are using is 3.2.0. Our tester deployed a
long-lived environment and did many operations (he didn't remember what he
did),
such as restarting virtlogd, restarting libvirtd, creating
Hi,
I know that it is a busy time, but is there any chance anyone could take a
look at this?
Best regards,
Slavka Peleva
On Fri, May 22, 2020 at 2:36 PM Slavka Peleva wrote:
> Hello,
>
> The Apache CloudStack project is using Maven libvirt java bindings in KVM
> code. In libvirt-java project
70 matches
Mail list logo
