[PATCH Libvirt 0/4] Support for dirty-limit live migration

In qemu>=8.1, the dirty-limit functionality for live migration was included. In the live migration scenario, it implements the force convergence using the dirty-limit approach, which results in better reliable read performance. A straightforward dirty-limit capability for live migration is added

[PATCH Libvirt 2/4] qemu_migration: Implement VIR_MIGRATE_DIRTY_LIMIT flag

From: Hyman Huang Signed-off-by: Hyman Huang --- src/qemu/qemu_migration.c| 8 src/qemu/qemu_migration.h| 1 + src/qemu/qemu_migration_params.c | 6 ++ src/qemu/qemu_migration_params.h | 1 + 4 files changed, 16 insertions(+) diff --git a/src/qemu/qemu_migration.c

[PATCH Libvirt 1/4] Add VIR_MIGRATE_DIRTY_LIMIT flag

From: Hyman Huang The flag can be used to enable dirty-limit capability for live migration. Signed-off-by: Hyman Huang --- include/libvirt/libvirt-domain.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h index

[PATCH Libvirt 3/4] virsh: Add support for VIR_MIGRATE_DIRTY_LIMIT flag

From: Hyman Huang Introudce option to enable dirty-limit convergence algorithim during live migration. Signed-off-by: Hyman Huang --- docs/manpages/virsh.rst | 10 +- src/libvirt-domain.c| 8 tools/virsh-domain.c| 10 ++ 3 files changed, 27 insertions(+), 1

[PATCH Libvirt 4/4] NEWS: document support for dirty-limit live migration

From: Hyman Huang Signed-off-by: Hyman Huang --- NEWS.rst | 8 1 file changed, 8 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index fbdd9674a3..dd0dda923e 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -25,6 +25,14 @@ v9.9.0 (unreleased) guest features to see if the current libvirt

[PATCH v3 2/4] migration: migrate 'blk' command option is deprecated.

Set the 'block' migration capability to 'true' instead. Signed-off-by: Juan Quintela Reviewed-by: Thomas Huth --- docs/about/deprecated.rst | 7 +++ qapi/migration.json | 10 +++--- migration/migration.c | 5 + 3 files changed, 19 insertions(+), 3 deletions(-) diff

[PATCH v3 4/4] migration: Deprecate old compression method

Signed-off-by: Juan Quintela Acked-by: Peter Xu --- docs/about/deprecated.rst | 8 +++ qapi/migration.json | 102 -- migration/options.c | 13 + 3 files changed, 86 insertions(+), 37 deletions(-) diff --git a/docs/about/deprecated.rst

[PATCH v3 3/4] migration: Deprecate block migration

It is obsolete. It is better to use driver-mirror with NBD instead. CC: Kevin Wolf CC: Eric Blake CC: Stefan Hajnoczi CC: Hanna Czenczek Signed-off-by: Juan Quintela --- docs/about/deprecated.rst | 10 ++ qapi/migration.json | 30 +-

[PATCH v3 1/4] migration: migrate 'inc' command option is deprecated.

Set the 'block_incremental' migration parameter to 'true' instead. Reviewed-by: Thomas Huth Signed-off-by: Juan Quintela --- docs/about/deprecated.rst | 7 +++ qapi/migration.json | 12 ++-- migration/migration.c | 6 ++ 3 files changed, 23 insertions(+), 2

Re: [libvirt RFCv11 00/33] multifd save restore prototype

On Wed, Oct 11, 2023 at 04:56:12PM +0200, Claudio Fontana wrote: > > On 10/11/23 16:05, Daniel P. Berrangé wrote: > > > > Instead of using 'getfd' though we have to use 'add-fd'. > > > > Anyway, this lets us do FD passing as normal, whle also > > letting us specify the offset. > > > >

Re: [libvirt RFCv11 00/33] multifd save restore prototype

Hi Daniel, thanks for your answer, On 10/11/23 16:05, Daniel P. Berrangé wrote: > On Wed, Oct 11, 2023 at 03:46:59PM +0200, Claudio Fontana wrote: >> In terms of our use case, we would need to trigger these migrations from >> virsh save, restore, managedsave / start. >> >> 1) Can you confirm

[PATCH 1/1] Checking the value returned by the function

In version 0.10.0-rc0 (https://github.com/libvirt/libvirt/blob/v0.10.0-rc0/src/security/security_selinux.c ) 11 years ago, the virSecuritySELinuxSetFileconHelper function appeared, which returned 1 if the optional is true. Considering that at the moment the virSecuritySELinuxSetFilecon function

[PATCH 0/1] Dead code in the virSecuritySELinuxSetImageLabelInternal function

The virSecuritySELinuxSetFilecon function (by definition) always return values 0 or -1. Sergey Mironov (1): Checking the value returned by the function src/security/security_selinux.c | 11 --- 1 file changed, 11 deletions(-) -- 2.31.1

Re: [libvirt RFCv11 00/33] multifd save restore prototype

On Wed, Oct 11, 2023 at 03:46:59PM +0200, Claudio Fontana wrote: > In terms of our use case, we would need to trigger these migrations from > virsh save, restore, managedsave / start. > > 1) Can you confirm this is still a good target? IIRC the 'dump' command also has a codepath that can

Re: [libvirt RFCv11 00/33] multifd save restore prototype

Hello Daniel and all @libvirt, reviving this old thread for multifd save/restore (for high performance migration of a large VM to an nvme disk and viceversa), now that we have made substantial progress on point b) below :-) There is a lot of ongoing work in QEMU spearheaded by Fabiano to

Re: [PATCH 1/1] Checking the value returned by the function

On Wed, Oct 11, 2023 at 15:24:17 +0300, Sergey Mironov wrote: > The virSecuritySELinuxSetFilecon function (by definition) always returns > values 0 or -1. > The result of this function is written to 'ret'. > The code compares the value of the variable 'ret' with 1. > > Signed-off-by: Sergey

[PATCH 1/1] Checking the value returned by the function

The virSecuritySELinuxSetFilecon function (by definition) always returns values 0 or -1. The result of this function is written to 'ret'. The code compares the value of the variable 'ret' with 1. Signed-off-by: Sergey Mironov --- src/security/security_selinux.c | 2 +- 1 file changed, 1

[PATCH 0/1] Checking the value returned by the function

The code compares the value of the variable 'ret' with 1. I assume that it is necessary to compare the value of 'ret' with -1 in this code fragment. Sergey Mironov (1): Checking the value returned by the function src/security/security_selinux.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCHv2 1/1] Changes from [v1]:

OK, thanks Peter. I will show this when sending patches later. От: Peter Krempa Отправлено: 11 октября 2023 г. 11:30:48 Кому: Миронов Сергей Владимирович Копия: libvir-list@redhat.com Тема: Re: [PATCHv2 1/1] Changes from [v1]: On Wed, Oct 11, 2023 at 11:19:08

[PATCHv2 0/1] qemu: added additional devAlias check

Now checked devAlias and making the code more robust in case when qemu stop sending a devAlias Sergey Mironov (1): Changes from [v1]: src/qemu/qemu_monitor_json.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.31.1

Re: [PATCHv2 1/1] Changes from [v1]:

On Wed, Oct 11, 2023 at 11:19:08 +0300, Sergey Mironov wrote: > - now checked devAlias and making the code more robust in case when qemu stop > sending a devAlias > > [v1] https://listman.redhat.com/archives/libvir-list/2023-October/242544.html When this is commited to the repository the

[PATCHv2 1/1] Changes from [v1]:

- now checked devAlias and making the code more robust in case when qemu stop sending a devAlias [v1] https://listman.redhat.com/archives/libvir-list/2023-October/242544.html Signed-off-by: Sergey Mironov --- v2: devAlias pointer was checked --- src/qemu/qemu_monitor_json.c | 2 +- 1 file

Re: [PATCH libvirt v1 0/3] Ensure full early console access with libvirt

On Thu, Sep 28, 2023 at 05:37 PM +0200, Marc Hartmayer wrote: > Currently, early console output may be lost, e.g. if starting a guest with > `virsh start --console` guest, which can make debugging of early failures very > difficult > (like zipl messages or disabled wait conditions happening