is going on.
Did you modify the max downtime? The default is 30 ms. At 8 Gbps, this only
allows to send 30 MB of data on the wire.
--
Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France
http://perso.univ-rennes1.fr/pierre.riteau/
much more than 50 MB/s of pages to the
destination.
--
Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France
http://perso.univ-rennes1.fr/pierre.riteau/
Thanks a lot Paolo, I confirm this patchset fixes the bug!
--
Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France
http://perso.univ-rennes1.fr/pierre.riteau/
On 28 oct. 2011, at 12:17, Paolo Bonzini wrote:
Forking and threading do not behave very well together. With qemu-nbd
On 28 oct. 2011, at 13:57, Paolo Bonzini wrote:
On 10/28/2011 01:56 PM, Pierre Riteau wrote:
Thanks a lot Paolo, I confirm this patchset fixes the bug!
Do you believe the limitation on error reporting to be too strong?
Paolo
Yes, it would be better if we could have error output on stderr
: Attempted send on closed socket
[18467.849025] end_request: I/O error, dev nbd0, sector 0
[18467.864446] nbd0: Attempted send on closed socket
[18467.878572] end_request: I/O error, dev nbd0, sector 0
[18467.893985] unable to read partition table
--
Pierre Riteau -- PhD student, Myriads team, IRISA
There is some discussion today on migration downtime so I try again: anyone
with comments on this patch?
On 2 mai 2011, at 14:19, Pierre Riteau wrote:
Any comment on this patch?
On 31 mars 2011, at 22:30, Pierre Riteau wrote:
In the current migration code, bandwidth is estimated
Any comment on this patch?
On 31 mars 2011, at 22:30, Pierre Riteau wrote:
In the current migration code, bandwidth is estimated by measuring the
time spent in the ram_save_block loop and dividing by the number of sent
bytes. However, because of buffering, the time spent in this loop
to improve this by measuring the time spent between two calls
to ram_save_live instead.
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
arch_init.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index 0c09f91..7b822fe 100644
Le 20 janv. 2011 à 17:18, Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp a
écrit :
2011/1/20 Pierre Riteau pierre.rit...@irisa.fr:
On 20 janv. 2011, at 03:06, Yoshiaki Tamura wrote:
2011/1/19 Pierre Riteau pierre.rit...@irisa.fr:
b02bea3a85cc939f09aa674a3f1e4f36d418c007 added a check
On 21 janv. 2011, at 10:16, Kevin Wolf wrote:
Am 19.01.2011 15:59, schrieb Pierre Riteau:
b02bea3a85cc939f09aa674a3f1e4f36d418c007 added a check on the return
value of bdrv_write and aborts migration when it fails. However, if the
size of the block device to migrate is not a multiple
with the correct size of the last block.
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
This v2 has the following changes:
- use error_report instead of fprintf (comment from Yoshiaki Tamura)
- don't recompute total_sectors when the device hasn't changed since the
previous iteration
On 21 janv. 2011, at 13:36, Yoshiaki Tamura wrote:
2011/1/21 Kevin Wolf kw...@redhat.com:
Am 21.01.2011 13:15, schrieb Yoshiaki Tamura:
2011/1/21 Pierre Riteau pierre.rit...@irisa.fr:
Le 20 janv. 2011 à 17:18, Yoshiaki Tamura tamura.yoshi...@lab.ntt.co.jp
a écrit :
2011/1/20 Pierre
On 21 janv. 2011, at 14:59, Yoshiaki Tamura wrote:
2011/1/21 Pierre Riteau pierre.rit...@irisa.fr:
On 21 janv. 2011, at 13:36, Yoshiaki Tamura wrote:
2011/1/21 Kevin Wolf kw...@redhat.com:
Am 21.01.2011 13:15, schrieb Yoshiaki Tamura:
2011/1/21 Pierre Riteau pierre.rit...@irisa.fr:
Le 20
On 21 janv. 2011, at 15:21, Yoshiaki Tamura wrote:
2011/1/21 Pierre Riteau pierre.rit...@irisa.fr:
On 21 janv. 2011, at 14:59, Yoshiaki Tamura wrote:
2011/1/21 Pierre Riteau pierre.rit...@irisa.fr:
On 21 janv. 2011, at 13:36, Yoshiaki Tamura wrote:
2011/1/21 Kevin Wolf kw...@redhat.com
On 21 janv. 2011, at 15:30, Yoshiaki Tamura wrote:
2011/1/21 Pierre Riteau pierre.rit...@irisa.fr:
On 21 janv. 2011, at 15:21, Yoshiaki Tamura wrote:
2011/1/21 Pierre Riteau pierre.rit...@irisa.fr:
On 21 janv. 2011, at 14:59, Yoshiaki Tamura wrote:
2011/1/21 Pierre Riteau pierre.rit
b02bea3a85cc939f09aa674a3f1e4f36d418c007 added a check on the return
value of bdrv_write and aborts migration when it fails. However, if the
size of the block device to migrate is not a multiple of BLOCK_SIZE
(currently 1 MB), the last bdrv_write will fail with -EIO.
Fixed by calling bdrv_write
On 20 janv. 2011, at 03:06, Yoshiaki Tamura wrote:
2011/1/19 Pierre Riteau pierre.rit...@irisa.fr:
b02bea3a85cc939f09aa674a3f1e4f36d418c007 added a check on the return
value of bdrv_write and aborts migration when it fails. However, if the
size of the block device to migrate is not a multiple
On 11 janv. 2011, at 12:54, Kevin Wolf wrote:
Am 25.12.2010 21:52, schrieb Pierre Riteau:
When block migration is requested and no read-write block device is
present, a divide by zero exception is triggered because
total_sector_sum equals zero.
Signed-off-by: Pierre Riteau pierre.rit
When block migration is requested and no read-write block device is
present, a divide by zero exception is triggered because
total_sector_sum equals zero.
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
This v2 fixes a line that was going beyond 80 characters.
block-migration.c |7
On 25 déc. 2010, at 21:52, Pierre Riteau wrote:
When block migration is requested and no read-write block device is
present, a divide by zero exception is triggered because
total_sector_sum equals zero.
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
block-migration.c |6
When block migration is requested and no read-write block device is
present, a divide by zero exception is triggered because
total_sector_sum equals zero.
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
block-migration.c |6 +-
1 files changed, 5 insertions(+), 1 deletions
/RESERVOIR_Framework_Guide_Website.pdf
[2] http://wiki.qemu.org/ChangeLog
It has been integrated in QEMU 0.12, back in December IIRC.
--
Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France
http://perso.univ-rennes1.fr/pierre.riteau/
Fixed by ae6b2c4ed956c17456e70efefe13ad0ab7db31de
** Changed in: qemu
Status: New = Fix Committed
--
cirrus_vga display is buggy after migration
https://bugs.launchpad.net/bugs/494486
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to
Anyone interested by this diff?
On 12 mai 2010, at 15:12, Pierre Riteau wrote:
When a page with all identical bytes is transferred, it is counted
as a full page (TARGET_PAGE_SIZE) although only one byte is actually
sent. Fix this by changing ram_save_block() to return the number of
bytes
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
arch_init.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index cfc03ea..cf6b7b0 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -235,7 +235,7 @@ int ram_save_live(Monitor *mon, QEMUFile *f
downtime estimation, more precise.
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
arch_init.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch_init.c b/arch_init.c
index cf6b7b0..76317af 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -108,7
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France
http://perso.univ-rennes1.fr/pierre.riteau/
On 25 janv. 2010, at 09:57, Liran Schour wrote:
Pierre Riteau pierre.rit...@irisa.fr wrote on 21/01/2010 20:03:32:
On 21 janv. 2010, at 16:24, Liran Schour wrote:
Move to stage3 only when remaining work can be done below max downtime.
Changes from v1: remove max iterations. Try
message.
--
Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France
http://perso.univ-rennes1.fr/pierre.riteau/
();
}
--
1.6.0.4
I haven't read the patch in detail but I think we should be able to avoid
duplicating code from vl.c by using qemu_get_clock.
Also, is floating point really necessary?
--
Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France
http://perso.univ-rennes1.fr/pierre.riteau/
(blk_mig_save_dirty_block(mon, f, 0) != 0);
+
blk_mig_cleanup(mon);
/* report completion */
--
1.5.2.4
--
Pierre Riteau -- http://perso.univ-rennes1.fr/pierre.riteau/
On 31 déc. 2009, at 00:14, Nikola Ciprich wrote:
Hi,
few months ago Pierre Riteau reported regression of exec migration in qemu.
(http://lists.gnu.org/archive/html/qemu-devel/2009-08/msg01557.html)
There was some discussion, but there is no clear conclusion.
Today, I tried qemu-kvm-0.12.1.2
On 9 déc. 2009, at 00:01, Alexander Graf wrote:
Am 08.12.2009 um 19:35 schrieb Blue Swirl blauwir...@gmail.com:
On Tue, Dec 8, 2009 at 4:35 PM, Pierre Riteau pierre.rit...@irisa.fr wrote:
On 1 oct. 2009, at 18:13, Blue Swirl wrote:
On Thu, Oct 1, 2009 at 6:30 PM, G 3 programmingk
On 8 déc. 2009, at 19:35, Blue Swirl wrote:
On Tue, Dec 8, 2009 at 4:35 PM, Pierre Riteau pierre.rit...@irisa.fr wrote:
On 1 oct. 2009, at 18:13, Blue Swirl wrote:
On Thu, Oct 1, 2009 at 6:30 PM, G 3 programmingk...@gmail.com wrote:
On Sep 30, 2009, at 3:16 PM, Anthony Liguori wrote:
G 3
, but the next phase, sending dirty blocks, can
be quite long too if the guest does a lot of I/O.
Won't it give a wrong impression to the user when qemu says Completed 100%
but disk migration continues catching up for a while?
--
Pierre Riteau -- http://perso.univ-rennes1.fr/pierre.riteau/
progress via 'info migrate'
- Progress report during restore
One patch is directly taken from Pierre Riteau queue [1] who happend to
work on the some topic the last days, two more are derived from his
commits.
These patches make block migration usable for us. Still, there are two
more major
On 30 nov. 2009, at 19:50, Pierre Riteau wrote:
I'm currently testing these patches. Here are a few issues I noticed, before
I forget about them.
- migrate -d -b tcp:dest:port works, but migrate -b -d tcp:dest:port
doesn't, although help migrate doesn't really specify ordering
On 30 nov. 2009, at 20:25, Jan Kiszka wrote:
Pierre Riteau wrote:
On 30 nov. 2009, at 19:34, Anthony Liguori wrote:
Jan Kiszka wrote:
This series is a larger rework of the block migration support qemu
recently gained. Besides lots of code refactorings the major changes
are:
- Faster
Valid description taken from qemu-img.texi, although it would be better
to have this information recorded in only one place.
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
qemu-img.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/qemu-img.c b/qemu-img.c
to the writes.
I will look on this further next week.
You second patchset for this feature (around September 10) was much faster than
the others.
Do you remember what was different?
--
Pierre Riteau -- http://perso.univ-rennes1.fr/pierre.riteau/
Hi,
While reading the block migration code I couldn't resist cleaning it up.
Among other things I replaced the lists by simple queues from NetBSD
(it can probably be useful for other subsystems).
block-migration.c | 486 ++---
block-migration.h |
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
qemu-queue.h | 109 +++--
1 files changed, 105 insertions(+), 4 deletions(-)
diff --git a/qemu-queue.h b/qemu-queue.h
index 8877efd..1d07745 100644
--- a/qemu-queue.h
+++ b/qemu-queue.h
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
block-migration.c | 138
1 files changed, 43 insertions(+), 95 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index e09db78..558890b 100644
--- a/block-migration.c
+++ b
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
block-migration.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index aff4c20..e09db78 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -313,7 +313,8 @@ static
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
block-migration.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index 1626168..aff4c20 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -352,8 +352,9
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
block-migration.c | 53 +++--
block-migration.h |2 +-
2 files changed, 20 insertions(+), 35 deletions(-)
diff --git a/block-migration.c b/block-migration.c
index 0cb162a..1626168 100644
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
block-migration.c | 366 ++---
block-migration.h |2 +-
savevm.c | 41 +++---
3 files changed, 200 insertions(+), 209 deletions(-)
diff --git a/block-migration.c b/block
This avoids the TUNSETOFFLOAD ioctl() failed: Invalid argument message
on kernels without TUNSETOFFLOAD support.
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
net/tap-linux.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/tap-linux.c b/net/tap-linux.c
vnet_hdr is initialized at 1 by default. We need to reset it to 0 if
the kernel doesn't support IFF_VNET_HDR.
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
---
net/tap-linux.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/tap-linux.c b/net/tap-linux.c
index
On 24 nov. 2009, at 11:28, Mark McLoughlin wrote:
On Tue, 2009-11-24 at 10:06 +0100, Pierre Riteau wrote:
vnet_hdr is initialized at 1 by default. We need to reset it to 0 if
the kernel doesn't support IFF_VNET_HDR.
Signed-off-by: Pierre Riteau pierre.rit...@irisa.fr
Thanks Pierre, I see
out? Will it be in time for qemu-0.12?
Jan
It was committed to the master branch a week ago.
--
Pierre Riteau -- http://perso.univ-rennes1.fr/pierre.riteau/
load of
migration failed and the VM is stopped.
This is because the origin closed the connexion, so qemu_fill_buffer reads a
buffer with len == 0, which is treated as an error later (f-has_error = 1).
Reverting e482dc3eaac43f88beea133843ae38c661262e97 fixes the problem.
--
Pierre Riteau
in and see the cursor moving
at the prompt position for example.
Reverting the hw/cirrus_vga.c part of 7e72abc382b700a72549e8147bdea413534eeedc
resolves the problem.
The setup is the same as for the e1000 bug: origin host is Debian Lenny
32-bits, destination host is Fedora 12 32-bit.
--
Pierre Riteau
On 24 nov. 2009, at 17:27, Ryan Harper wrote:
* Pierre Riteau pierre.rit...@irisa.fr [2009-11-24 09:35]:
e482dc3eaac43f88beea133843ae38c661262e97 breaks migration of a VM using an
e1000 device (which is the default...).
Origin host is Debian Lenny 32-bits, destination host is Fedora 12 32
On 24 nov. 2009, at 17:46, Juan Quintela wrote:
Pierre Riteau pierre.rit...@irisa.fr wrote:
e482dc3eaac43f88beea133843ae38c661262e97 breaks migration of a VM using an
e1000 device (which is the default...).
Origin host is Debian Lenny 32-bits, destination host is Fedora 12 32-bit.
Guest
On 24 nov. 2009, at 12:22, Mark McLoughlin wrote:
On Tue, 2009-11-24 at 12:17 +0100, Pierre Riteau wrote:
On 24 nov. 2009, at 11:28, Mark McLoughlin wrote:
On Tue, 2009-11-24 at 10:06 +0100, Pierre Riteau wrote:
vnet_hdr is initialized at 1 by default. We need to reset it to 0
56 matches
Mail list logo