qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] savevm/loadvm
Date: Wed, 16 Oct 2013 17:51:24 +1100	[thread overview]
Message-ID: <525E376C.1080303@ozlabs.ru> (raw)
In-Reply-To: <525623ED.70208@ozlabs.ru>

On 10/10/2013 02:50 PM, Alexey Kardashevskiy wrote:
> On 10/09/2013 06:47 PM, Paolo Bonzini wrote:
>> Il 09/10/2013 09:15, Alexey Kardashevskiy ha scritto:
>>> Sorry for my ignorance (I never ever touched this part of qemu) but how can
>>> you possibly avoid block.c while doing savevm? The qcow2 driver must not
>>> use posix read()/write(), right? So no matter how, all writes end up in
>>> bdrv_co_do_writev() which changes blocks number. Or use
>>> raw_aio_readv()/raw_aio_writev() API directly? Please give some more hints.
>>> Thanks.
>>
>> I think Kevin was suggesting using qcow_aio_writev directly, or
>> something like that.  But it is not trivial, especially because
>> save_vm_state takes byte offsets instead of sectors.  So for now I'd
>> still go for the more hacky solution.
> 
> I failed to find qcow_aio_writev() or anything like that. qcow2_co_writev()
> uses block.c. And I tried this:
> 
> diff --git a/block/qcow2.c b/block/qcow2.c
> index 4a9888c..17faf8b 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
> @@ -1837,10 +1837,16 @@ static int qcow2_save_vmstate(BlockDriverState *bs,
> QEMUIOVector *qiov,
>      BDRVQcowState *s = bs->opaque;
>      int growable = bs->growable;
>      int ret;
> +    int64_t total_sectors = bs->total_sectors;
> 
>      BLKDBG_EVENT(bs->file, BLKDBG_VMSTATE_SAVE);
>      bs->growable = 1;
>      ret = bdrv_pwritev(bs, qcow2_vm_state_offset(s) + pos, qiov);
> +    /*
> +     * Setting @growable may cause underlying bdrv_co_do_writev()
> +     * to increase bs->total_sectors and we do not want this to happen.
> +     */
> +    bs->total_sectors = total_sectors;
>      bs->growable = growable;
> 
>      return ret;
> 
> 
> It breaks loadvm in a different (weird) way, the error is something like
> "ram" or "spapr/htab" (streams registered with register_savevm_live())
> chunk cannot be read. Need to debug more...


Just to keep the conversation going :) The patch below helps while the
patch above creates snapshots which cannot be loaded.

And there is no qcow_aio_writev-like API to fix it, what did you mean?

Why not just revert the breaking patch?

Thanks.

diff --git a/savevm.c b/savevm.c
index e0c8aee..aeda0d1 100644
--- a/savevm.c
+++ b/savevm.c
@@ -42,6 +42,7 @@
 #include "qemu/iov.h"
 #include "block/snapshot.h"
 #include "block/qapi.h"
+#include "block/block_int.h"

 #define SELF_ANNOUNCE_ROUNDS 5

@@ -2389,6 +2390,7 @@ void do_savevm(Monitor *mon, const QDict *qdict)
     qemu_timeval tv;
     struct tm tm;
     const char *name = qdict_get_try_str(qdict, "name");
+    int64_t total_sectors;

     /* Verify if there is a device that doesn't support snapshots and is
writable */
     bs = NULL;
@@ -2442,6 +2444,7 @@ void do_savevm(Monitor *mon, const QDict *qdict)
     }

     /* save the VM state */
+    total_sectors = bs->total_sectors;
     f = qemu_fopen_bdrv(bs, 1);
     if (!f) {
         monitor_printf(mon, "Could not open VM state file\n");
@@ -2450,6 +2453,11 @@ void do_savevm(Monitor *mon, const QDict *qdict)
     ret = qemu_savevm_state(f);
     vm_state_size = qemu_ftell(f);
     qemu_fclose(f);
+    /*
+     * Setting @growable may cause underlying bdrv_co_do_writev()
+     * to increase bs->total_sectors and we do not want this to happen.
+     */
+    bs->total_sectors = total_sectors;
     if (ret < 0) {
         monitor_printf(mon, "Error %d while writing VM\n", ret);
         goto the_end;




-- 
Alexey

  reply	other threads:[~2013-10-16  6:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-08  8:40 [Qemu-devel] savevm/loadvm Alexey Kardashevskiy
2013-10-08  9:04 ` Paolo Bonzini
2013-10-08  9:23   ` Kevin Wolf
2013-10-08  9:33     ` Paolo Bonzini
2013-10-09  7:15       ` Alexey Kardashevskiy
2013-10-09  7:47         ` Paolo Bonzini
2013-10-10  3:50           ` Alexey Kardashevskiy
2013-10-16  6:51             ` Alexey Kardashevskiy [this message]
2013-11-01 13:22               ` Alexey Kardashevskiy
2013-11-01 14:16 ` Max Reitz
2013-11-03  0:34   ` Alexey Kardashevskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=525E376C.1080303@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).