nbd0: 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,
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-
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
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, bandwid
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 thi
o point to different migration protocols on either end but they
>>> are
>>> both running the same version of qemu-kvm I built. Does this ring any bells
>>> for
>>> anyone?
>>
>> Command line mismatch. But, what is your platform?
>
> CentOS5.6. Now running the VMs through qemu-kvm 0.14.1, unloaded migrations
> take
> about half the time but with memory I/O load now both VMs never complete the
> migration. In practical terms I'm writing about 50MB/s into memory and we
> have a
> 10Gbps network (and I've seen real speeds up to 8-9Gbps on the wire) so there
> should be enough capacity to sync up the dirty pages.
>
> So now the 32GB and 4GB VMs have matching behaviour (which makes more sense)
> but
> I'm not any closer to figuring out what 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/
CentOS5.6. Now running the VMs through qemu-kvm 0.14.1, unloaded migrations
> take
> about half the time but with memory I/O load now both VMs never complete the
> migration. In practical terms I'm writing about 50MB/s into memory and we
> have a
> 10Gbps network (and I've seen real speeds up to 8-9Gbps on the wire) so there
> should be enough capacity to sync up the dirty pages.
>
> So now the 32GB and 4GB VMs have matching behaviour (which makes more sense)
> but
> I'm not any closer to figuring out what is going on.
You say you write 50 MB/s in memory, but this does not provide enough
information to analyze the problem.
How distributed in memory are these writes? If your writes are not restricted
to a small memory region, they could dirty many pages. In this case, live
migration would have to transfer 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/
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
---
block-migration.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/block
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
> ---
> block-migration.c |
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.
>>
>
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
---
This v2 fixes a line that was going beyond 80 characters.
block-migration.c |7 ++-
1 files
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 wi
On 20 janv. 2011, at 03:06, Yoshiaki Tamura wrote:
> 2011/1/19 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 m
Le 20 janv. 2011 à 17:18, Yoshiaki Tamura a
écrit :
> 2011/1/20 Pierre Riteau :
>> On 20 janv. 2011, at 03:06, Yoshiaki Tamura wrote:
>>
>>> 2011/1/19 Pierre Riteau :
>>>> b02bea3a85cc939f09aa674a3f1e4f36d418c007 added a check on the return
>>>>
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 migr
with the correct size of the last block.
Signed-off-by: Pierre Riteau
---
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 (comment from
On 21 janv. 2011, at 13:36, Yoshiaki Tamura wrote:
> 2011/1/21 Kevin Wolf :
>> Am 21.01.2011 13:15, schrieb Yoshiaki Tamura:
>>> 2011/1/21 Pierre Riteau :
>>>> Le 20 janv. 2011 à 17:18, Yoshiaki Tamura
>>>> a écrit :
>>>>
>>>
On 21 janv. 2011, at 14:59, Yoshiaki Tamura wrote:
> 2011/1/21 Pierre Riteau :
>> On 21 janv. 2011, at 13:36, Yoshiaki Tamura wrote:
>>
>>> 2011/1/21 Kevin Wolf :
>>>> Am 21.01.2011 13:15, schrieb Yoshiaki Tamura:
>>>>> 2011/1/21 Pierre Riteau
On 21 janv. 2011, at 15:21, Yoshiaki Tamura wrote:
> 2011/1/21 Pierre Riteau :
>> On 21 janv. 2011, at 14:59, Yoshiaki Tamura wrote:
>>
>>> 2011/1/21 Pierre Riteau :
>>>> On 21 janv. 2011, at 13:36, Yoshiaki Tamura wrote:
>>>>
>>>>
On 21 janv. 2011, at 15:30, Yoshiaki Tamura wrote:
> 2011/1/21 Pierre Riteau :
>> On 21 janv. 2011, at 15:21, Yoshiaki Tamura wrote:
>>
>>> 2011/1/21 Pierre Riteau :
>>>> On 21 janv. 2011, at 14:59, Yoshiaki Tamura wrote:
>>>>
>>>>&
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 QE
ed?
>
> Best Regards,
>
> Stefan
>
> [1]
> http://62.149.240.97/uploads/Training/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/
improve this by measuring the time spent between two calls
to ram_save_live instead.
Signed-off-by: Pierre Riteau
---
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
--- a/arch_init.c
+++ b
/
> +
> +return 1;
> +}
> +}
> +
> +return 0;
> }
>
> static void blk_mig_cleanup(Monitor *mon)
> @@ -490,7 +614,9 @@ static int block_save_live(Monitor *mon, QEMUFile *f, int
> stage, void *opaque)
> }
>
> if (stage == 3) {
> -/* we now for sure that save bulk is completed */
> +/* we know for sure that save bulk is completed and
> + all async read completed */
> +assert(block_mig_state.submitted == 0);
>
> while(blk_mig_save_dirty_block(mon, f, 0) != 0);
> blk_mig_cleanup(mon);
> @@ -580,4 +706,6 @@ void blk_mig_init(void)
>
> register_savevm_live("block", 0, 1, block_set_params, block_save_live,
> NULL, block_load, &block_mig_state);
> +
> +init_get_clock();
> }
> --
> 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/
On 25 janv. 2010, at 09:57, Liran Schour wrote:
>
>
> Pierre Riteau 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.
>>>
>>> C
hanges from the last patch submission should
be part of the commit message.
--
Pierre Riteau -- PhD student, Myriads team, IRISA, Rennes, France
http://perso.univ-rennes1.fr/pierre.riteau/
len = read(fd, buffer, sizeof(buffer));
> } while ((len == -1 && errno == EINTR) || len == sizeof(buffer));
> @@ -3246,7 +3247,7 @@ static int qemu_event_init(void)
> int err;
> int fds[2];
>
> -err = qemu_pipe(fds);
> +err = qemu_eventfd(fds);
> if (err == -1)
> return -errno;
>
> --
> 1.6.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" 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/
Signed-off-by: Pierre Riteau
---
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, int stage,
void
downtime estimation, more precise.
Signed-off-by: Pierre Riteau
---
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 +108,7 @@ static int
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 o
via http://.
>
> Sure. I'd prefer people didn't use http because it's pretty inefficient but
> I understand it's the only option for people being proxies.
In recent versions Git as a so-called "Smart HTTP" protocol which is much more
efficient. However
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
---
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 0f621a2..e4
On 24 nov. 2009, at 11:05, Mark McLoughlin wrote:
> Hi Pierre,
>
> 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.
>
> Thanks for the patch
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
&g
g, n=copy everything,
>>>> 1=copy the last level (equivalent to -d blk inc) I think we'll have
>>>> covered everything.
>>>>
>>> I propose the following syntax:
>>> migrate [-d] [-b [ ...]]
>>> tcp::
>>> Where device will be the name o
"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.
--
n 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 R
On 24 nov. 2009, at 17:27, Ryan Harper wrote:
> * Pierre Riteau [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
On 24 nov. 2009, at 17:46, Juan Quintela wrote:
> Pierre Riteau 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.
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
This avoids the "TUNSETOFFLOAD ioctl() failed: Invalid argument" message
on kernels without TUNSETOFFLOAD support.
Signed-off-by: Pierre Riteau
---
net/tap-linux.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/tap-linux.c b/net/tap-linux.c
ind
guest to
> the destination. When the guest starts to run on the destination all writes
> should be finished, so anyhow we need to wait synchronously 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
---
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
@@ -1,8 +1,9
Signed-off-by: Pierre Riteau
---
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/block-migration.c
Signed-off-by: Pierre Riteau
---
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 void
Signed-off-by: Pierre Riteau
---
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 @@ static void flush_blks
Signed-off-by: Pierre Riteau
---
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
--- a/block
Signed-off-by: Pierre Riteau
---
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-migration.c
index 09771ed
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
---
qemu-img.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/qemu-img.c b/qemu-img.c
index 972843a..5123f98
to monitor instead of stdout, report
>> sum of multiple disks
>> - Report disk migration 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 to
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 &
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. Bes
io, 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/
otype to their headers to avoid warnings.
Other assume that fdatasync could be a noop and fall back to fsync.
I would go with the second second: the function is not defined, there is no man
page, let's assume it doesn't work.
To fix the configure check we can simply add -Werror to t
On 8 déc. 2009, at 19:35, Blue Swirl wrote:
> On Tue, Dec 8, 2009 at 4:35 PM, Pierre Riteau wrote:
>> On 1 oct. 2009, at 18:13, Blue Swirl wrote:
>>
>>> On Thu, Oct 1, 2009 at 6:30 PM, G 3 wrote:
>>>> On Sep 30, 2009, at 3:16 PM, Anthony Liguori wrote:
&
On 9 déc. 2009, at 00:01, Alexander Graf wrote:
>
> Am 08.12.2009 um 19:35 schrieb Blue Swirl :
>
>> On Tue, Dec 8, 2009 at 4:35 PM, Pierre Riteau wrote:
>>> On 1 oct. 2009, at 18:13, Blue Swirl wrote:
>>>
>>>> On Thu, Oct 1, 2009 at 6:30 PM,
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
> /* no more dirty blocks */
> break;
> }
> -} else {
> -/* if we got here stop the loop */
> -break;
> }
> }
>
> @@ -507,9 +527,12 @@ static int block
59 matches
Mail list logo
