On 13/08/2015 07:46, Liang Li wrote:
> Some cleanup operations take long time during the pause and copy stage,
> especially with the KVM patch 3ea3b7fa9af067, do these operations after
> the completion of live migration can help to reduce VM downtime.
>
> Ony the first patch changes the behavior
The function qemu_savevm_state_cancel is called after the migration
in migration_thread, it seems strange to 'cancel' it after completion,
rename it to qemu_savevm_state_cleanup looks better.
Signed-off-by: Liang Li
---
include/sysemu/sysemu.h | 2 +-
migration/migration.c | 2 +-
migration/sa
Just clean up code, no behavior change.
Signed-off-by: Liang Li
---
migration/block.c | 9 ++---
migration/ram.c | 9 ++---
2 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/migration/block.c b/migration/block.c
index 55442bd..869798c 100644
--- a/migration/block.c
+++ b/
Because of the patch 3ea3b7fa9af067982f34b of kvm, now the migration_end()
is a time consuming operation, which takes about dozens of milliseconds, and
will prolong VM downtime. Such an operation should be done after migration
completion.
For a VM with 8G RAM, this patch can reduce the VM downtime
Some cleanup operations take long time during the pause and copy stage,
especially with the KVM patch 3ea3b7fa9af067, do these operations after
the completion of live migration can help to reduce VM downtime.
Ony the first patch changes the behavior, the rest 3 patches are for code
cleanup.
Chang
'cleanup' seems more appropriate than 'cancel'.
Signed-off-by: Liang Li
---
include/migration/vmstate.h | 2 +-
migration/block.c | 2 +-
migration/ram.c | 2 +-
migration/savevm.c | 4 ++--
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/mig
Split the part which actually refreshes the BlockDriverState.filename
field off of bdrv_refresh_filename() into a more generic function
bdrv_filename(), which first calls bdrv_refresh_filename() and then
stores a qemu-usable filename into the given buffer instead of
BlockDriverState.filename.
Sinc
After drive-mirror replacing a Quorum child, the filename of the Quorum
BDS should reflect the change. This patch replaces the existing test for
whether the operation did actually exchange the BDS (which simply tested
whether the new BDS existed) by a test which examines the children list
contained
That field is now only used during initialization of BlockDriverStates
(opening images) and for error or warning messages. Performance is not
that much of an issue here, so we can drop the field and replace its use
by a call to bdrv_filename() or bdrv_filename_alloc(). By doing so we
can ensure the
In places which directly pass a filename to the OS, we should not use
the filename field at all but exact_filename instead (although the
former currently equals the latter if that is set).
In qemu-img's map command, we should be using the filename field; but
since this commit prepares to remove th
Instead of returning a pointer to the filename, copy it into a buffer
specified by the caller.
Signed-off-by: Max Reitz
---
block.c | 25 ++---
include/block/block.h | 2 +-
monitor.c | 6 +-
3 files changed, 24 insertions(+), 9 deletions(-)
d
This series depends on
"[PATCH] block/raw-posix: Use raw_normalize_devicepath()".
The BDS filename field is generally only used when opening disk images
or emitting error or warning messages, the only exception to this rule
is the map command of qemu-img. However, using exact_filename there
inste
The filename given to qemu_open() in block/raw-posix.c should generally
have been processed by raw_normalize_devicepath(); unless we are only
probing (in which case the caller often checks whether the file is a
block device or not, and this property will be changed by
raw_normalize_devicepath() on
>
> On 12/08/2015 23:04, Liang Li wrote:
> > @@ -1008,8 +1009,10 @@ static void *migration_thread(void *opaque)
> > }
> >
> > qemu_mutex_lock_iothread();
> > +end_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
> > +qemu_savevm_state_cancel();
> > +
>
> You can remove the qemu_sa
On 12/08/2015 23:04, Liang Li wrote:
> @@ -1008,8 +1009,10 @@ static void *migration_thread(void *opaque)
> }
>
> qemu_mutex_lock_iothread();
> +end_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
> +qemu_savevm_state_cancel();
> +
You can remove the qemu_savevm_state_cancel()
On 12/08/2015 23:04, Liang Li wrote:
> Some cleanup operations take long time during the pause and copy stage,
> especially with the KVM patch 3ea3b7fa9af067, do these operation after
> the completion of live migration can help to reduce VM downtime.
>
>
> Liang Li (2):
> migration: do cleanu
Because of the patch 3ea3b7fa9af067982f34b of kvm, now the migration_end()
is a time consuming operation, which takes about dozens of milliseconds, and
will prolong VM downtime. Such an operation should be done after migration
completion.
For a VM with 8G RAM, this patch can reduce the VM downtime
Some cleanup operations take long time during the pause and copy stage,
especially with the KVM patch 3ea3b7fa9af067, do these operation after
the completion of live migration can help to reduce VM downtime.
Liang Li (2):
migration: do cleanup operation after completion
migration: rename qemu
The function qemu_savevm_state_cancel is called after the migration
in migration_thread, it seems strange to 'cancel' it after completion,
rename it to qemu_savevm_state_cleanup looks better.
Signed-off-by: Liang Li
---
include/sysemu/sysemu.h | 2 +-
migration/migration.c | 4 ++--
migration/
On Fri, Jul 24, 2015 at 01:33:08PM +0100, Peter Maydell wrote:
> Use the utility function pow2ceil() for rounding up to the next
> largest power of 2, rather than inline calculation.
>
> Signed-off-by: Peter Maydell
Reviewed-by: Michael S. Tsirkin
> ---
> hw/virtio/virtio-pci.c | 4 +---
> 1
On Fri, Jul 24, 2015 at 01:33:07PM +0100, Peter Maydell wrote:
> A couple of places in hw/pci use an inline calculation to round a
> size up to the next largest power of 2. We have a utility routine
> for this, so use it.
>
> (The behaviour of the old code is different if the size value
> is 0 --
21 matches
Mail list logo
