From: Vjaceslavs Klimovs <1913969@bugs.launchpad.net>
To: qemu-devel@nongnu.org
Subject: [Bug 1913969] [NEW] unable to migrate non shared storage when TLS is used
Date: Sun, 31 Jan 2021 21:56:18 -0000 [thread overview]
Message-ID: <161213017826.4056.12759150225792580313.malonedeb@soybean.canonical.com> (raw)
Public bug reported:
Operating system: Gentoo
Architecture: x86_64
kernel version: 5.4.72, 5.10.11
libvirt version: at least 6.9.0, 6.10.0, 7.0.0
Hypervisor and version: qemu 5.1.0, 5.2.0
With software versions described above and following configurations:
libvirt:
key_file = "/etc/ssl/libvirt/server.lan.key"
cert_file = "/etc/ssl/libvirt/server.lan.crt"
ca_file = "/etc/ssl/libvirt/ca.crt"
log_filters="3:remote 4:event 3:util.json 3:rpc 1:*"
log_outputs="1:file:/var/log/libvirt/libvirtd.log"
qemu:
default_tls_x509_cert_dir = "/etc/ssl/qemu"
default_tls_x509_verify = 1
migration with tls:
virsh # migrate vm1 qemu+tls://server2.lan/system --persistent --undefinesource --copy-storage-all --verbose --tls
never succeeds. Progress stops typically at high progress amounts (95%-98%), and network traffic drastically drops as well (from 1 gbps+ to nothing). domjobinfo progress also stops. Without --tls migrations succeed without issues without any other changes to hosts or configurations.
Note: I reported this originally as libvirt bug:
https://gitlab.com/libvirt/libvirt/-/issues/108.
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1913969
Title:
unable to migrate non shared storage when TLS is used
Status in QEMU:
New
Bug description:
Operating system: Gentoo
Architecture: x86_64
kernel version: 5.4.72, 5.10.11
libvirt version: at least 6.9.0, 6.10.0, 7.0.0
Hypervisor and version: qemu 5.1.0, 5.2.0
With software versions described above and following configurations:
libvirt:
key_file = "/etc/ssl/libvirt/server.lan.key"
cert_file = "/etc/ssl/libvirt/server.lan.crt"
ca_file = "/etc/ssl/libvirt/ca.crt"
log_filters="3:remote 4:event 3:util.json 3:rpc 1:*"
log_outputs="1:file:/var/log/libvirt/libvirtd.log"
qemu:
default_tls_x509_cert_dir = "/etc/ssl/qemu"
default_tls_x509_verify = 1
migration with tls:
virsh # migrate vm1 qemu+tls://server2.lan/system --persistent --undefinesource --copy-storage-all --verbose --tls
never succeeds. Progress stops typically at high progress amounts (95%-98%), and network traffic drastically drops as well (from 1 gbps+ to nothing). domjobinfo progress also stops. Without --tls migrations succeed without issues without any other changes to hosts or configurations.
Note: I reported this originally as libvirt bug:
https://gitlab.com/libvirt/libvirt/-/issues/108.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1913969/+subscriptions
next reply other threads:[~2021-01-31 22:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-31 21:56 Vjaceslavs Klimovs [this message]
2021-05-12 18:02 ` [Bug 1913969] Re: unable to migrate non shared storage when TLS is used Thomas Huth
2021-05-12 20:22 ` Vjaceslavs Klimovs
2021-05-13 9:40 ` Dr. David Alan Gilbert
2021-05-14 19:29 ` Thomas Huth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=161213017826.4056.12759150225792580313.malonedeb@soybean.canonical.com \
--to=1913969@bugs.launchpad.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).