On Mon, Oct 19, 2020 at 10:58:38 +0200, Peter Krempa wrote:
> On Mon, Oct 19, 2020 at 09:36:15 +0200, Tim Wiederhake wrote:
> > Usage was mixed.
> >
> > Signed-off-by: Tim Wiederhake
> > ---
> > src/cpu_map/arm_vendors.xml| 24 ++---
> > src/cpu_map/index.xml | 140 +---
On Mon, Oct 19, 2020 at 09:36:16 +0200, Tim Wiederhake wrote:
> This script is intended to help in synchronizing i386 QEMU cpu model
> definitions with libvirt.
>
> As the QEMU cpu model definitions are post processed by QEMU and not
> meant to be consumed by third parties directly, parsing this
>
On Tue, Nov 03, 2020 at 11:11:48 +0100, Andrea Bolognani wrote:
> On Mon, 2020-11-02 at 19:35 +0100, Jiri Denemark wrote:
> > On Mon, Nov 02, 2020 at 12:09:13 +0100, Andrea Bolognani wrote:
> > > On Mon, 2020-11-02 at 11:20 +0100, Jiri Denemark wrote:
> > > [
On Mon, Nov 02, 2020 at 12:09:13 +0100, Andrea Bolognani wrote:
> On Mon, 2020-11-02 at 11:20 +0100, Jiri Denemark wrote:
> [...]
> > * Improvements
> >
> > * Bug fixes
>
> It would have been nice if you had removed the empty "Improvement"
> section
On Mon, Nov 02, 2020 at 12:05:59 +0100, Erik Skultety wrote:
> This is just a warning, but because we're invoking rst2html5 with
> --strict, it will fail at encountering a single minor issue.
>
> Signed-off-by: Erik Skultety
> ---
>
> Pushed as trivial.
>
> NEWS.rst | 2 +-
> 1 file changed, 1
The 6.9.0 release of both libvirt and libvirt-python is tagged and
signed tarballs and source RPMs are available at
https://libvirt.org/sources/
https://libvirt.org/sources/python/
Thanks everybody who helped with this release by sending patches,
reviewing, testing, or providing any other
I have just tagged v6.9.0-rc2 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make
I have just tagged v6.9.0-rc1 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make
We are getting close to the next release of libvirt. To aim for the
release on Nov 02 I suggest entering the freeze on Monday Oct 26 and
tagging RC2 on Thursday Oct 29.
I hope this works for everyone.
Jirka
On Wed, Oct 14, 2020 at 17:28:54 +0200, Erik Skultety wrote:
> On Wed, Oct 14, 2020 at 01:38:41PM +0200, Jiri Denemark wrote:
> > Signed-off-by: Jiri Denemark
> > ---
> >
> > Notes:
> > Should we also make the key available for download?
>
> Now that
Signed-off-by: Jiri Denemark
---
Notes:
Should we also make the key available for download?
docs/downloads.html.in | 14 ++
1 file changed, 14 insertions(+)
diff --git a/docs/downloads.html.in b/docs/downloads.html.in
index 43366b3694..aa0bb23d45 100644
--- a/docs
| 4 ++--
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> --
> 2.26.2
>
>
Reviewed-by: Jiri Denemark
and pushed, thanks.
On Wed, Oct 07, 2020 at 12:29:42 +0200, Jiri Denemark wrote:
> On Wed, Oct 07, 2020 at 11:08:21 +0200, Peter Krempa wrote:
> > On Wed, Oct 07, 2020 at 10:54:54 +0200, Tim Wiederhake wrote:
> > > This element is not always present, see e.g.
> > > x86_64-cpuid-Xeon-X
The main spec file was missing basictypes.rng and mingw does not install
cpu.rng. Let's just install all *.rng files in the schemas directory.
Signed-off-by: Jiri Denemark
---
libvirt.spec.in | 24 +---
mingw-libvirt.spec.in | 24 ++--
2
EPYC-Rome.
Signed-off-by: Jiri Denemark
---
src/cpu_map/x86_EPYC-Rome.xml | 1 -
tests/cputestdata/x86_64-cpuid-EPYC-7502-32-Core-guest.xml | 1 +
tests/cputestdata/x86_64-cpuid-EPYC-7502-32-Core-host.xml | 1 +
tests/cputestdata/x86_64-cpuid-EPYC-7502-32
The CPU should be identified as EPYC-Rome, but the QEMU binary used to
gather the original test data did not support this model. Let's update
the supported models to QEMU 5.1.0.
Signed-off-by: Jiri Denemark
---
tests/cputest.c | 2 +-
...6_64-cpuid-Ryzen-9-
On Wed, Oct 07, 2020 at 15:56:31 +0200, Markus Schade wrote:
> Am 06.10.20 um 16:50 schrieb Jiri Denemark:
> > But, since I don't really like going through the CPU model definition
> > again (even though it would be just a diff), I can do these trivial
> > changes just b
On Wed, Oct 07, 2020 at 15:54:50 +0200, Markus Schade wrote:
> Am 06.10.20 um 15:44 schrieb Jiri Denemark:
> > QEMU definition of EPYC-Rome also contains 'npt' (CPUID_SVM_NPT),
> > 'nrip-save' (CPUID_SVM_NRIPSAVE), and 'umip' (CPUID_7_0_ECX_UMIP). Any
def->cores && def->threads). The question
is whether caps->host.cpu would even be allocated when the topology is
unknown. In any case, I think it's fine to mark it as optional in the
schema. Another option would be to mock some topology in cputest to make
sure the host CPU definitions contain the corresponding element.
Reviewed-by: Jiri Denemark
On Thu, Oct 01, 2020 at 12:22:00 +0200, Markus Schade wrote:
> this patch series adds testdata from an AMD EPYC 7502 system,
> defines and enables the qemu EPYC-Rome model and changes
> the existing Ryzen 9 host definition to the new model
>
> Markus Schade (4):
> Add testdata for AMD EPYC 7502
On Thu, Oct 01, 2020 at 12:22:02 +0200, Markus Schade wrote:
> Signed-off-by: Markus Schade
> ---
> src/cpu_map/index.xml | 1 +
> src/cpu_map/meson.build | 1 +
> src/cpu_map/x86_EPYC-Rome.xml | 81 +++
> 3 files changed, 83 insertions(+)
> create
_64-cpuid-EPYC-7502-32-Core.json
> create mode 100644 tests/cputestdata/x86_64-cpuid-EPYC-7502-32-Core.sig
> create mode 100644 tests/cputestdata/x86_64-cpuid-EPYC-7502-32-Core.xml
Reviewed-by: Jiri Denemark
The 6.8.0 release of both libvirt and libvirt-python is tagged and
signed tarballs and source RPMs are available at
https://libvirt.org/sources/
https://libvirt.org/sources/python/
Thanks everybody who helped with this release by sending patches,
reviewing, testing, or providing any other
On Mon, Sep 28, 2020 at 13:17:22 +0200, Markus Schade wrote:
> Signed-off-by: Markus Schade
> ---
Thanks, I'm sorry I didn't say it last time (as I didn't realize it
would be needed in this case), but it's better to split the patch in
two. First add the new data files for EPYC-7502, i.e.,
> tes
On Mon, Sep 28, 2020 at 13:20:06 +0200, Markus Schade wrote:
> Okay, that did not go as expected. Anyway
I'm not sure what did not go as expected...
> This patch add the qemu EPYC-Rome model and includes cpuid data from an
> EPYC 7502 system
Great.
> as well as updated cpuid information from a
I have just tagged v6.8.0-rc2 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make
> In some cases, the QMP capabilities processes possible residue. So we need to
> clear the residual QMP caps processes during starting libvirt.
I agree with you that leaving processes behind is more serious than
leaving temporary files and thus we should try to kill such processes
when libvirtd s
7;rst2html5-3',
> 'rst2html', 'rst2html.py', 'rst2html-3']},
> + {'name':'rst2html', 'prog':['rst2html5', 'rst2html5.py', 'rst2html5-3']},
>{'name':'rst2man', 'prog':['rst2man', 'rst2man.py', 'rst2man-3']},
> ]
>
Reviewed-by: Jiri Denemark
ption caused unpredictable behavior, often resulting in a libvirtd
> crash.
>
> Signed-off-by: Jim Fehlig
For 6.8.0:
Reviewed-by: Jiri Denemark
On Thu, Sep 24, 2020 at 18:38:18 +0200, Andrea Bolognani wrote:
> On Thu, 2020-09-24 at 15:13 +0200, Jiri Denemark wrote:
> > I have just tagged v6.8.0-rc1 in the repository and pushed signed
> > tarballs and source RPMs to https://libvirt.org/sources/
>
> Can we pleas
I have just tagged v6.8.0-rc1 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make
On Thu, Sep 24, 2020 at 12:25:23 +0200, Markus Schade wrote:
> Hi everyone,
>
> I'd like to add support for the EPYC-Rome CPU model from qemu.
>
> The following patch adds the model to cpu_map. While this allows to use
> the model, I am aware that some tests are required as well.
>
> However I a
On Wed, Sep 23, 2020 at 22:26:29 -0400, Collin Walling wrote:
> When executing the hypervisor-cpu-baseline command and if there is only
> a single CPU definition present in the XML file, then libvirt will
> print an unhelpful message:
>
> "error: An error occurred, but the cause is unknown"
>
> T
On Wed, Sep 23, 2020 at 22:26:28 -0400, Collin Walling wrote:
> When executing the hypervisor-cpu-compare/baseline commands and
> the XML file contains a CPU definition using host-passthrough
> and no model name, the commands will fail and return an error
> message from the QMP response.
That's th
On Wed, Sep 23, 2020 at 18:29:54 -0400, Collin Walling wrote:
> On 9/23/20 5:01 PM, Jiri Denemark wrote:
> > On Wed, Sep 23, 2020 at 16:17:04 -0400, Collin Walling wrote:
> >> On 9/23/20 2:52 PM, Collin Walling wrote:
> >> Actually, it might help to extend this fu
On Wed, Sep 23, 2020 at 16:17:04 -0400, Collin Walling wrote:
> On 9/23/20 2:52 PM, Collin Walling wrote:
> > On 9/23/20 10:18 AM, Jiri Denemark wrote:
> >> On Wed, Sep 23, 2020 at 09:26:58 +0200, Tim Wiederhake wrote:
> >>> From: Collin Walling
> >
On Mon, Sep 21, 2020 at 10:51:16 +0300, Nikolay Shirokovskiy wrote:
> Currently virDomainMigrate3 reports "this function is not supported by the
> connection driver: virDomainMigrate3" if connection to destination for example
> is broken. This is a bit misleading.
>
> This is a result of we treat
On Wed, Sep 16, 2020 at 16:58:03 +0800, Zhenyu Zheng wrote:
> Modify virCPUarmCompare in cpu_arm.c to perform compare action.
> This patch only adds host to host CPU compare, the rest cases
> remains the same. This is useful for source and destination host
> compare during migrations to avoid migra
_("cpu parameter is missing a model name"));
> +goto cleanup;
> +}
> +}
> ret = qemuConnectCPUModelComparison(qemuCaps, cfg->libDir,
> cfg->user, cfg->group,
> hvCPU, cpu, failIncompatible);
Reviewed-by: Jiri Denemark
I'll wait some time for Collin to add Signed-of-by tag before pushing
this.
Collin, I apologize for not getting to you earlier.
On Wed, Sep 16, 2020 at 12:11:08 -0400, Collin Walling wrote:
> On 9/16/20 3:03 AM, Michal Privoznik wrote:
> > On 9/15/20 10:25 PM, Collin Walling wrote:
> >> One more ping in attempt to get this in the right direction. Otherwise
> >> I'll post
On Mon, Sep 21, 2020 at 14:38:55 +0200, Ján Tomko wrote:
> [please don't top-post on technical mailing lists]
>
> On a Monday in 2020, Alexander Wels wrote:
> >Which version would that be? 6.7.0?
> >
>
> No, 6.7.0 is already out:
> https://www.redhat.com/archives/libvirt-announce/2020-September/
We are getting close to the next release of libvirt. To aim for the
release on Oct 01 I suggest entering the freeze on Thursday Sep 24 and
tagging RC2 on Tuesday Sep 29.
I hope this works for everyone.
Jirka
On Mon, Sep 07, 2020 at 20:15:59 +0800, Zhenyu Zheng wrote:
> So the suitable way of doing this will be checking for `VIR_CPU_TYPE_HOST`
> and perform a comparison in this case and still return IDENTICAL for all
> other cases right?
Yes.
> Then the upper layer caller(like OpenStack Nova) will hav
On Mon, Sep 07, 2020 at 09:21:02 +0800, Zhenyu Zheng wrote:
> Thanks alot for the reply,
>
> This sounds like a valid use case (not sure it is that useful), but we
> > need to be careful. But we should make sure implementing this does not
> > break anything. This means, we need to do different thi
T_CONNECT_HOST) {
> +host = spec->dest.host.name;
> +}
> +
> +
One empty line would be enough :-)
> /* Currently libvirt does not support setting up of the NBD
> * non-shared storage migration with TLS. As we need to honour
> the
> * VIR_MIGRATE_TLS flag, we need to reject such migration until
...
Reviewed-by: Jiri Denemark
On Thu, Sep 03, 2020 at 19:50:13 +0800, Zhenyu Zheng wrote:
> Hi,
>
> Thanks alot for the review and feedback. As for host-passthrough cases, I
> have some other understandings,
> if I understand correctly, what you mean is that if a vm uses
> host-passthrough, it can migrate to any other
> host,
he mistaken config.
>
> Signed-off-by: Daniel P. Berrangé
> ---
> src/meson.build | 11 ++
> src/remote/libvirtd.conf.in | 40 ++-
> src/remote/libvirtd.socket.in | 2 +-
> 3 files changed, 42 insertions(+), 11 deletions(-)
Reviewed-by: Jiri Denemark
On Wed, Sep 02, 2020 at 11:53:37 +0200, Jiri Denemark wrote:
> On Tue, Sep 01, 2020 at 16:36:59 +0200, Martin Kletzander wrote:
> > This allows:
> >
> > a) migration without access to network
> >
> > b) complete control of the migration stream
> >
>
On Tue, Sep 01, 2020 at 16:36:59 +0200, Martin Kletzander wrote:
> This allows:
>
> a) migration without access to network
>
> b) complete control of the migration stream
>
> c) easy migration between containerised libvirt daemons on the same host
>
> Resolves: https://bugzilla.redhat.com/16
On Tue, Sep 01, 2020 at 21:34:30 +0200, Ján Tomko wrote:
> On a Tuesday in 2020, Martin Kletzander wrote:
> >Signed-off-by: Martin Kletzander
> >---
> > NEWS.rst | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> >diff --git a/NEWS.rst b/NEWS.rst
> >index 302b7f477904..52781b7e1677 100644
> >--
-
> src/remote/remote_driver.c | 8 ++--
> src/util/viruri.c | 30 ++
> src/util/viruri.h | 2 ++
> tests/virmigtest.c | 2 +-
> 6 files changed, 55 insertions(+), 4 deletions(-)
Reviewed-by: Jiri Denemark
performed completely over UNIX sockets. This is
> +useful for containerised scenarios and can be used in both peer2peer and
> +direct migrations.
> +
> * **Bug fixes**
>
>* virdevmapper: Deal with kernels without DM support
Reviewed-by: Jiri Denemark
_("nbd port must be in range 0-65535"));
> return -1;
...
> diff --git a/src/qemu/qemu_migration_cookie.c
> b/src/qemu/qemu_migration_cookie.c
> index cef255598854..c1295b32fc27 100644
> --- a/src/qemu/qemu_migration_cookie.c
> +++ b/src/qemu/qemu_migration_cookie.c
> @@ -91,6 +91,7 @@ qemuMigrationCookieNBDFree(qemuMigrationCookieNBDPtr nbd)
> while (nbd->ndisks)
> VIR_FREE(nbd->disks[--nbd->ndisks].target);
> VIR_FREE(nbd->disks);
> +
> VIR_FREE(nbd);
> }
>
> @@ -992,7 +993,7 @@ qemuMigrationCookieNBDXMLParse(xmlXPathContextPtr ctxt)
> if (port && virStrToLong_i(port, NULL, 10, &ret->port) < 0) {
> virReportError(VIR_ERR_INTERNAL_ERROR,
> _("Malformed nbd port '%s'"),
> - port);
> + port);
> goto error;
> }
>
I don't think you wanted to touch qemu_migration_cookie.c at all. You
can just drop both hunks.
...
With the small fixups
Reviewed-by: Jiri Denemark
tions(+), 2 deletions(-)
> create mode 100644 tests/virmigtest.c
Reviewed-by: Jiri Denemark
u_migration.c | 37 +++--
> 1 file changed, 23 insertions(+), 14 deletions(-)
Reviewed-by: Jiri Denemark
On Tue, Sep 01, 2020 at 16:36:54 +0200, Martin Kletzander wrote:
> Signed-off-by: Martin Kletzander
> ---
> tools/virsh-domain.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
Reviewed-by: Jiri Denemark
uture commit(s).
>
> Signed-off-by: Martin Kletzander
> ---
> src/qemu/qemu_migration.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
Reviewed-by: Jiri Denemark
tofree char *port = NULL;
> int ret = -1;
>
> host = spec->dest.host.name;
> @@ -3400,7 +3400,6 @@ qemuMigrationSrcConnect(virQEMUDriverPtr driver,
> ret = 0;
>
> cleanup:
> -VIR_FREE(port);
> if (ret < 0)
> VIR_FORCE_CLOSE(spec->dest.fd.qemu);
> return ret;
Reviewed-by: Jiri Denemark
On Fri, Aug 21, 2020 at 10:20:15 +0800, Zhenyu Zheng wrote:
> Modify virCPUarmCompare in cpu_arm.c to perform
> actual compare actions. Compare host cpu vendor
> and model info with guest cpu as initial implementation,
> as most ARM clouds uses host-passthrogh mode.
In addition to the low-level co
On Thu, Aug 27, 2020 at 08:50:15 +, Wangxin (Alexander) wrote:
> Hi, Jiri
>
> I just compared the cpu features between the 'x86_Cooperlake.xml ' and
> 'x86_Cascadelake-Server.xml',
> the feature 'mpx' seems removed from the Cooperlake model. Is there a reason?
mpx was not removed from Coope
ptember/msg0.html
>
> Fixes: c74268705557a6781788ba011492c15df2e3df11
> Reported-by: Roman Bogorodskiy
> Signed-off-by: Michal Privoznik
> ---
> tools/nss/libvirt_nss.c | 6 +++---
> tools/nss/libvirt_nss.h | 4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
Reviewed-by: Jiri Denemark
EL 7 and older macro _vpath_builddir is not defined.
> -%if 0%{?rhel} <= 7
> +%if 0%{?rhel} && 0%{?rhel} <= 7
> %define _vpath_builddir %{_target_platform}
> %endif
>
Reviewed-by: Jiri Denemark
The 6.7.0 release of both libvirt and libvirt-python is tagged and
signed tarballs and source RPMs are available at
https://libvirt.org/sources/
https://libvirt.org/sources/python/
Thanks everybody who helped with this release by sending patches,
reviewing, testing, or providing any other
I have just tagged v6.7.0-rc2 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make
I have just tagged v6.7.0-rc1 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
The is the first release using meson and ninja which replaced autotools
and make so please give the release candidate some testing and in case
you find a serious issue which s
On Tue, Aug 25, 2020 at 17:12:59 +0100, Daniel P. Berrangé wrote:
> On Tue, Aug 25, 2020 at 05:53:32PM +0200, Jiri Denemark wrote:
> > On Tue, Aug 25, 2020 at 07:47:14 +0200, Martin Kletzander wrote:
> > > -/* RDMA and multi-fd migration requires QEMU to connect to the
migration can now be performed completely over UNIX sockets. This is
> +useful for containerised scenarios and can be used in both peer2peer and
> +direct migrations.
> +
> * **Bug fixes**
>
> * virdevmapper: Deal with kernels without DM support
Reviewed-by
On Tue, Aug 25, 2020 at 16:28:12 +0100, Daniel P. Berrangé wrote:
> On Tue, Aug 25, 2020 at 07:47:12AM +0200, Martin Kletzander wrote:
> > Adds new typed param for migration and uses this as a UNIX socket path that
> > should be used for the NBD part of migration. And also adds virsh support.
> >
+} else {
> + /* RDMA and multi-fd migration requires QEMU to connect to the
> destination
> + * itself.
> + */
> +if (STREQ(uribits->scheme, "rdma") || (flags & VIR_MIGRATE_PARALLEL))
> +spec.destType = MIGRATION_DEST_HOST;
> +else
> +spec.destType = MIGRATION_DEST_CONNECT_HOST;
> +
> +spec.dest.host.protocol = uribits->scheme;
> +spec.dest.host.name = uribits->server;
> +spec.dest.host.port = uribits->port;
> +}
> +
> spec.fwdType = MIGRATION_FWD_DIRECT;
>
> ret = qemuMigrationSrcRun(driver, vm, persist_xml, cookiein,
> cookieinlen, cookieout,
Reviewed-by: Jiri Denemark
a proxy or not.
> +{
> +size_t i = 0;
> +
> +if (!uri->scheme)
> +return false;
> +
> +if (STRNEQ_NULLABLE(strchr(uri->scheme, '+'), "+unix"))
> +return false;
> +
> +for (i = 0; i < uri->paramsCount; i++) {
> +if (STREQ(uri->params[i].name, "socket"))
> +return true;
> +}
> +
> +return false;
> +}
Reviewed-by: Jiri Denemark
nbd_dest = g_strdup_printf("nbd:[%s]:%d:exportname=%s", host, port,
> diskAlias);
> } else {
...
> @@ -2329,6 +2357,8 @@ qemuMigrationDstPrepare(virDomainObjPtr vm,
>
> if (tunnel) {
> migrateFrom = g_strdup("stdio");
> +} else if (g_strcmp0(protocol, "unix") == 0) {
> +migrateFrom = g_strdup_printf("%s:%s", protocol, listenAddress);
> } else {
> bool encloseAddress = false;
> bool hostIPv6Capable = false;
Looks like this hunk would better fit in 8/9 (qemu: Allow migration over
UNIX socket).
...
With the small issues addressed and if all I said is correct
Reviewed-by: Jiri Denemark
On Tue, Aug 25, 2020 at 09:43:28 +0100, Daniel P. Berrangé wrote:
> On Tue, Aug 25, 2020 at 12:11:30AM +0200, Jiri Denemark wrote:
> > On Fri, Aug 21, 2020 at 12:30:09 +0100, Daniel P. Berrangé wrote:
> > > The logic to disable Ceph on 32-bit was protected by a Fedora
> >
t; +struct MigLocalData {
Eh, we never start a type with upper case.
> +const char *uri;
> +bool fail;
> +};
> +
> +extern int virDomainMigrateCheckNotLocal(const char *dconnuri);
Hmm, why is this needed? Looks like a leftover.
> +
> +static int testMigNotLocal(const void *args)
^
|_
|
Break the line here ---'
> +{
> +int ret = -1;
> +const struct MigLocalData *data = args;
...
With the nits addressed:
Reviewed-by: Jiri Denemark
u_migration.c | 37 +++--
> 1 file changed, 23 insertions(+), 14 deletions(-)
Reviewed-by: Jiri Denemark
On Tue, Aug 25, 2020 at 07:47:09 +0200, Martin Kletzander wrote:
> Signed-off-by: Martin Kletzander
> ---
> tools/virsh-domain.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
Reviewed-by: Jiri Denemark
uture commit(s).
>
> Signed-off-by: Martin Kletzander
> ---
> src/qemu/qemu_migration.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
Reviewed-by: Jiri Denemark
tofree char *port = NULL;
> int ret = -1;
>
> host = spec->dest.host.name;
> @@ -3400,7 +3400,6 @@ qemuMigrationSrcConnect(virQEMUDriverPtr driver,
> ret = 0;
>
> cleanup:
> -VIR_FREE(port);
> if (ret < 0)
> VIR_FORCE_CLOSE(spec->dest.fd.qemu);
> return ret;
Reviewed-by: Jiri Denemark
On Fri, Aug 21, 2020 at 12:30:09 +0100, Daniel P. Berrangé wrote:
> The logic to disable Ceph on 32-bit was protected by a Fedora
> conditional. This is redundant as RHEL doesn't build on 32-bit
> platforms for years.
But libvirt is still built on i686 even on RHEL for 32b libraries. And
this inc
tion_params.c | 18 ++
> 1 file changed, 6 insertions(+), 12 deletions(-)
Reviewed-by: Jiri Denemark
amespaces disabled for domain %s", vm->def->name);
> +return 0;
> +}
> +
> if (qemuDomainPopulateDevices(cfg, &paths) < 0)
> return -1;
Reviewed-by: Jiri Denemark
I'm sending this quite early this month as I'm on vacation tomorrow and
next week and I wanted to make sure the plan for the release is
advertised earlier than just a day or two before the freeze.
To aim for the release on Sep 01 I suggest entering the freeze in two
weeks on Wednesday Aug 26 and t
When COW is not explicitly requested to be disabled or enabled, the
function is supposed to do nothing on non-BTRFS file systems.
Fixes commit 7230bc95aa78379c9ee20cf59394c5fc4305b75b.
https://bugzilla.redhat.com/show_bug.cgi?id=1866157
Signed-off-by: Jiri Denemark
---
src/util/virfile.c | 2
The 6.6.0 release of both libvirt and libvirt-python is tagged and
signed tarballs and source RPMs are available at
https://libvirt.org/sources/
https://libvirt.org/sources/python/
Thanks everybody who helped with this release by sending patches,
reviewing, testing, or providing any other
I have just tagged v6.6.0-rc1 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make
Signed-off-by: Jiri Denemark
---
src/qemu/qemu_driver.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index b8ba2e3fb9..8e81c30a93 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -13150,7
On Fri, Jul 17, 2020 at 18:15:55 -0300, Daniel Henrique Barboza wrote:
> Use g_auto* on pointers to avoid using the 'cleanup' label.
>
> In theory the 'ret' variable can also be discarded if the flow
> of the logic is reworked. Perhaps another time.
Doing so would actually be pretty easy, mostly
utoptr() in virQEMUCapsInitQMPSingle()
>
> src/qemu/qemu_capabilities.c | 3 +--
> src/qemu/qemu_driver.c | 41 ++--
> src/qemu/qemu_process.c | 13
> src/qemu/qemu_process.h | 1 +
> 4 files changed, 22 insertions(+), 36 deletions(-)
Reviewed-by: Jiri Denemark
And pushed.
Hi all,
We are getting close to the next release of libvirt. Because I am on
vacation next week, I think we will have a little bit longer freeze
period (although mainly extended by a weekend).
So to aim for the release at the beginning of August I suggest entering
the freeze just before the upcom
On Thu, Jul 16, 2020 at 22:08:48 +0200, Jiri Denemark wrote:
> Commit v6.4.0-61-g201bd5db63 started to fill the default value for
> //cpu/@migratable attribute according to QEMU support. However, active
> domains either have the migratable attribute already set or the
> capabilitie
x27;t probe for this specific capability.
https://bugzilla.redhat.com/show_bug.cgi?id=1857967
Reported-by: Mark Mielke
Signed-off-by: Jiri Denemark
---
src/qemu/qemu_domain.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
Signed-off-by: Jiri Denemark
---
src/qemu/qemu_monitor.c | 18 ++
src/qemu/qemu_monitor.h | 4
src/qemu/qemu_monitor_json.c | 27 +++
src/qemu/qemu_monitor_json.h | 4
4 files changed, 53 insertions(+)
diff --git a/src/qemu
Mielke
Signed-off-by: Jiri Denemark
---
src/qemu/qemu_process.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 70fc24b993..d5ac8af37e 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu
Fixes a regression in libvirt 6.5.0 caused by commit 201bd5db63. See
patches 2 and 3 for details.
Jiri Denemark (3):
qemu_monitor: Add API for checking CPU migratable property
qemu: Do not set //cpu/@migratable for running domains in post-parse
qemu: Properly set //cpu/@migratable default
x27;t probe for this specific capability. Thus we should
leave active domains alone when parsing their XMLs.
https://bugzilla.redhat.com/show_bug.cgi?id=1857967
Reported-by: Mark Mielke
Signed-off-by: Jiri Denemark
---
src/qemu/qemu_domain.c | 8 ++--
1 file changed, 6 insertions(+), 2 dele
On Thu, Jul 16, 2020 at 15:47:48 +0200, Pavel Hrdina wrote:
> On Thu, Jul 16, 2020 at 02:01:34PM +0100, Daniel P. Berrangé wrote:
> > On Thu, Jul 16, 2020 at 11:53:56AM +0200, Pavel Hrdina wrote:
> > > Patches are available in my Gitlab repo as well:
> > >
> > > git clone -b meson https://git
On Mon, Jul 13, 2020 at 14:04:25 +0200, Jiri Denemark wrote:
> On Sat, Jul 11, 2020 at 13:44:19 -0400, Mark Mielke wrote:
> > On Sat, Jul 11, 2020 at 6:04 AM Mark Mielke wrote:
> >
> > > On Fri, Jul 10, 2020 at 7:48 AM Mark Mielke wrote:
> > >
> >
On Tue, Jul 14, 2020 at 11:20:00 +0800, Bihong Yu wrote:
> >From c7ee36417b88df7dcfe5e18d1eb72b6d7c175268 Mon Sep 17 00:00:00 2001
> From: Bihong Yu
> Date: Tue, 14 Jul 2020 11:17:46 +0800
> Subject: [PATCH] qemu: use a fixed directory for saving qmp capabilities
> process
>
> In some case, the
On Sat, Jul 11, 2020 at 13:44:19 -0400, Mark Mielke wrote:
> On Sat, Jul 11, 2020 at 6:04 AM Mark Mielke wrote:
>
> > On Fri, Jul 10, 2020 at 7:48 AM Mark Mielke wrote:
> >
> >> On Fri, Jul 10, 2020 at 7:14 AM Jiri Denemark
> >> wrote:
> >>
>
On Fri, Jul 10, 2020 at 07:48:26 -0400, Mark Mielke wrote:
> On Fri, Jul 10, 2020 at 7:14 AM Jiri Denemark wrote:
>
> > On Sun, Jul 05, 2020 at 12:45:55 -0400, Mark Mielke wrote:
> > > With 6.4.0, live migration was working fine with Qemu 5.0. After trying
> > out
&
On Fri, Jul 10, 2020 at 05:53:47 -0400, Mark Mielke wrote:
> Hi all:
>
> Any thoughts on this, or not time enough to look?
>
> I'm trying to decide what the right solution is on my end to deal with this
> breaking change, before more widely deploying it. If I know what the fix
> will be, I would
901 - 1000 of 7327 matches
Mail list logo
