Re: [libvirt PATCH 0/4] cgroup cpu period and quota fixes

On 11/25/20 11:37 AM, Pavel Hrdina wrote: Pavel Hrdina (4): qemu: move cgroup cpu period and quota defines to vircgroup.h vircgroupv1: use defines for cpu period and quota limits vircgroupv2: use defines for cpu period and quota limits vircgroup: fix cpu quota maximum limit

Re: [libvirt PATCH 1/2] remote: make ssh-helper massively faster

On 11/25/20 7:04 PM, Daniel P. Berrangé wrote: It was reported that the performance of tunnelled migration and volume upload/download regressed in 6.9.0, when the virt-ssh-helper is used for remote SSH tunnelling instead of netcat. When seeing data available to read from stdin, or the socket,

Re: [libvirt PATCH 2/2] util: avoid glib event loop workaround where possible

On 11/25/20 7:04 PM, Daniel P. Berrangé wrote: I previously did a workaround for a glib event loop race that causes crashes: commit 0db4743645b7a0611a3c0687f834205c9956f7fc Author: Daniel P. Berrangé Date: Tue Jul 28 16:52:47 2020 +0100 util: avoid crash due to race in glib

Re: [libvirt PATCH 0/2] fix regression in SSH tunnelling performance

On 11/25/20 3:04 PM, Daniel P. Berrangé wrote: In testing the "vol-download" command in virsh, downloading a 1G file takes a ridiculous amount of time (minutes) with the new SSH helper. After the first patch is applied the time gets down to a much more reasonable 5.5 seconds on my test

Re: Migration with "--p2p --tunnelled" hanging in v6.9.0

On Wed, Nov 25, 2020 at 05:20:41PM +, Daniel P. Berrangé wrote: > On Wed, Nov 25, 2020 at 05:00:20PM +, Daniel P. Berrangé wrote: > > On Wed, Nov 25, 2020 at 04:36:39PM +, Daniel P. Berrangé wrote: > > > On Wed, Nov 25, 2020 at 04:49:14PM +0100, Christian Ehrhardt wrote: > > > > I

[libvirt PATCH 1/2] remote: make ssh-helper massively faster

It was reported that the performance of tunnelled migration and volume upload/download regressed in 6.9.0, when the virt-ssh-helper is used for remote SSH tunnelling instead of netcat. When seeing data available to read from stdin, or the socket, the current code will allocate at most 1k of extra

[libvirt PATCH 2/2] util: avoid glib event loop workaround where possible

I previously did a workaround for a glib event loop race that causes crashes: commit 0db4743645b7a0611a3c0687f834205c9956f7fc Author: Daniel P. Berrangé Date: Tue Jul 28 16:52:47 2020 +0100 util: avoid crash due to race in glib event loop code it turns out that the workaround has a

[libvirt PATCH 0/2] fix regression in SSH tunnelling performance

In testing the "vol-download" command in virsh, downloading a 1G file takes a ridiculous amount of time (minutes) with the new SSH helper. After the first patch is applied the time gets down to a much more reasonable 5.5 seconds on my test machine. By comparison netcat achieved 4 seconds. After

Re: Migration with "--p2p --tunnelled" hanging in v6.9.0

On Wed, Nov 25, 2020 at 05:00:20PM +, Daniel P. Berrangé wrote: > On Wed, Nov 25, 2020 at 04:36:39PM +, Daniel P. Berrangé wrote: > > On Wed, Nov 25, 2020 at 04:49:14PM +0100, Christian Ehrhardt wrote: > > > Thanks for the hint Daniel, it is indeed not migration specific - it > > > seems

Re: Migration with "--p2p --tunnelled" hanging in v6.9.0

On Wed, Nov 25, 2020 at 04:36:39PM +, Daniel P. Berrangé wrote: > On Wed, Nov 25, 2020 at 04:49:14PM +0100, Christian Ehrhardt wrote: > > Thanks for the hint Daniel, it is indeed not migration specific - it > > seems that virs-ssh-helper is just very slow. > > > > rm testfile; virsh -c > >

Re: Migration with "--p2p --tunnelled" hanging in v6.9.0

On Wed, Nov 25, 2020 at 04:49:14PM +0100, Christian Ehrhardt wrote: > Thanks for the hint Daniel, it is indeed not migration specific - it > seems that virs-ssh-helper is just very slow. > > rm testfile; virsh -c > qemu+ssh://testkvm-hirsute-to/system?proxy=netcat vol-download --pool > uvtool

Re: Migration with "--p2p --tunnelled" hanging in v6.9.0

On Wed, Nov 25, 2020 at 2:47 PM Daniel P. Berrangé wrote: > > On Wed, Nov 25, 2020 at 02:33:44PM +0100, Christian Ehrhardt wrote: > > On Wed, Nov 25, 2020 at 1:38 PM Daniel P. Berrangé > > wrote: > > > > > > On Wed, Nov 25, 2020 at 01:28:09PM +0100, Christian Ehrhardt wrote: > > > > On Wed, Nov

[libvirt PATCH 2/4] vircgroupv1: use defines for cpu period and quota limits

Signed-off-by: Pavel Hrdina --- src/util/vircgroupv1.c | 23 --- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/src/util/vircgroupv1.c b/src/util/vircgroupv1.c index 984cd50409..06849efd38 100644 --- a/src/util/vircgroupv1.c +++ b/src/util/vircgroupv1.c @@

[libvirt PATCH 0/4] cgroup cpu period and quota fixes

Pavel Hrdina (4): qemu: move cgroup cpu period and quota defines to vircgroup.h vircgroupv1: use defines for cpu period and quota limits vircgroupv2: use defines for cpu period and quota limits vircgroup: fix cpu quota maximum limit src/qemu/qemu_driver.c | 21 -

[libvirt PATCH 4/4] vircgroup: fix cpu quota maximum limit

Kernel commit added proper check for cpu quota maximum limit to prevent internal overflow. Even though this change is not present in all kernels it makes sense to enforce the same limit in libvirt. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1750315 Signed-off-by: Pavel Hrdina ---

[libvirt PATCH 1/4] qemu: move cgroup cpu period and quota defines to vircgroup.h

Signed-off-by: Pavel Hrdina --- src/qemu/qemu_driver.c | 21 - src/util/vircgroup.h | 5 + 2 files changed, 13 insertions(+), 13 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 391596ba11..0e0a165e76 100644 --- a/src/qemu/qemu_driver.c

[libvirt PATCH 3/4] vircgroupv2: use defines for cpu period and quota limits

Signed-off-by: Pavel Hrdina --- src/util/vircgroupv2.c | 25 + 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/src/util/vircgroupv2.c b/src/util/vircgroupv2.c index 2b32f614e4..22da3a5c6a 100644 --- a/src/util/vircgroupv2.c +++ b/src/util/vircgroupv2.c @@

Re: Migration with "--p2p --tunnelled" hanging in v6.9.0

On Wed, Nov 25, 2020 at 02:33:44PM +0100, Christian Ehrhardt wrote: > On Wed, Nov 25, 2020 at 1:38 PM Daniel P. Berrangé > wrote: > > > > On Wed, Nov 25, 2020 at 01:28:09PM +0100, Christian Ehrhardt wrote: > > > On Wed, Nov 25, 2020 at 10:55 AM Christian Ehrhardt > > > wrote: > > > > > > > > On

Re: Migration with "--p2p --tunnelled" hanging in v6.9.0

On Wed, Nov 25, 2020 at 1:38 PM Daniel P. Berrangé wrote: > > On Wed, Nov 25, 2020 at 01:28:09PM +0100, Christian Ehrhardt wrote: > > On Wed, Nov 25, 2020 at 10:55 AM Christian Ehrhardt > > wrote: > > > > > > On Tue, Nov 24, 2020 at 4:30 PM Peter Krempa wrote: > > > > > > > > On Tue, Nov 24,

Re: Migration with "--p2p --tunnelled" hanging in v6.9.0

On Wed, Nov 25, 2020 at 01:28:09PM +0100, Christian Ehrhardt wrote: > On Wed, Nov 25, 2020 at 10:55 AM Christian Ehrhardt > wrote: > > > > On Tue, Nov 24, 2020 at 4:30 PM Peter Krempa wrote: > > > > > > On Tue, Nov 24, 2020 at 16:05:53 +0100, Christian Ehrhardt wrote: > > > > Hi, > > > > > >

Re: Migration with "--p2p --tunnelled" hanging in v6.9.0

On Wed, Nov 25, 2020 at 10:55 AM Christian Ehrhardt wrote: > > On Tue, Nov 24, 2020 at 4:30 PM Peter Krempa wrote: > > > > On Tue, Nov 24, 2020 at 16:05:53 +0100, Christian Ehrhardt wrote: > > > Hi, > > > > [...] > > BTW to reduce the scope what to think about - I have rebuilt 6.8 as > well it

[PATCH 3/3] domain_conf: Allow to look up scsi disks when controller uses a CCW address

On s390x, devices are attached to the channel IO subsytem by default, so we need to look up scsi controllers via their CCW address there instead of using PCI. This fixes "virsh domfsinfo" on s390x for virtio-scsi devices (the first attempt from commit f8333b3b0a7 did it in the wrong way,

[PATCH 2/3] domain_conf: Allow to look up virtio-block devices by their CCW address

On s390x, devices are attached to the channel IO subsytem by default, so we need to look up the devices via their CCW address there instead of using PCI. This fixes "virsh domfsinfo" on s390x for virtio-block devices (the first attempt from commit f8333b3b0a7 did it in the wrong way, reporting

[RFC PATCH 0/3] Fix "virsh domfsinfo" on s390x (again)

My previous attempts to fix "virsh domfsinfo" on s390x were unfortunately wrong due to some misunderstandings on my side. To correctly list the "Target" device in the output of "virsh domfsinfo", we need to search through the available devices using their CCW address on s390x. For this the QEMU

[PATCH 1/3] qemu: agent: Store CCW address in qemuAgentDiskInfo if provided by the guest

Newer versions of the QEMU guest agent will provide the CCW address of devices on s390x. Store this information in the qemuAgentDiskInfo so that we can use this later. We also map the CSSID 0 from the guest to the value 0xfe on the host, see https://www.qemu.org/docs/master/system/s390x/css.html

Re: Migration with "--p2p --tunnelled" hanging in v6.9.0

On Tue, Nov 24, 2020 at 4:30 PM Peter Krempa wrote: > > On Tue, Nov 24, 2020 at 16:05:53 +0100, Christian Ehrhardt wrote: > > Hi, > > [...] BTW to reduce the scope what to think about - I have rebuilt 6.8 as well it works. Thereby I can confirm that the offending change should be in between