All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Dietmar Maurer <dietmar@proxmox.com>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] [RFC] qmp interface for save vmstate to image
Date: Mon, 18 Mar 2013 18:47:57 +0800	[thread overview]
Message-ID: <5146F0DD.6060008@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130318090430.GB2476@dhcp-200-207.str.redhat.com>

于 2013-3-18 17:04, Kevin Wolf 写道:
> Am 18.03.2013 um 07:40 hat Wenchao Xia geschrieben:
>> 于 2013-3-15 22:51, Stefan Hajnoczi 写道:
>>> On Fri, Mar 15, 2013 at 03:24:38PM +0800, Wenchao Xia wrote:
>>>>     I'd like to add a new way to save vmstate, which will based on the
>>>> migration thread, but will write contents to block images, instead
>>>> of fd as stream. Following is the method to add API:
>>>
>>> Hi Wenchao,
>>> What use cases are there besides saving vmstate to a raw image?
>>>
>>> I'm curious if you're proposing this since there is no "file:" URI or
>>> because you really want to do things like saving vmstate into a qcow2
>>> file or over NBD.
>>>
>>> Stefan
>>>
>> Hi, Stefan
>>    Most used cases would be "raw" and "qcow2", which is flex and can be
>> chosen by user. In this way, existing block layer feature in qemu can
>> be used, such as tagging zeros. I haven't check the buffer/cache status
>> in qemu block layer, but if there is, it can also benefit.
>>    User can specify "raw" or "qcow2" according to host configuration, If
>> there is dedicated storage components underlining, he can use "raw" to
>> skip qemu's block layer.
>
> Oh, seems I misread this then. I thought this was about internal live
> snapshots, which is a feature that I consider really useful. I'm not so
> sure if saving the VM state as the disk contents of a qcow2 image is
> really helpful.
>
   Actually I am leaving internal live snapshot as 2nd step since there
are a bit more work to do when using migration thread, since SPICE
is handled in migration but not in internal snapshot.
   The main purpose is getting a standalone vmstate saving file with
limited size, since internal snapshot lacks a API now to drop vmstate
at any time.(better to have API to export vmstate/delta block data).

> If zero clusters help a lot, then there's clearly something to improve
> in the migration protocol, because it shouldn't send so many zeros in
> the first place.
>
  In streaming case, zero are good encoded now I think, but when it uses
fseek(), there may be some zeros inside, and small writes. Handling
those are likely block layer's job, by using image I can directly use
qemu's block layer with qcow2 format, or using raw if underline
component there, make it flex.

> Kevin
>


-- 
Best Regards

Wenchao Xia

  parent reply	other threads:[~2013-03-18 10:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-15  7:24 [Qemu-devel] [RFC] qmp interface for save vmstate to image Wenchao Xia
2013-03-15 14:51 ` Stefan Hajnoczi
2013-03-18  6:40   ` Wenchao Xia
2013-03-18  9:04     ` Kevin Wolf
2013-03-18 10:08       ` Paolo Bonzini
2013-03-18 10:50         ` Wenchao Xia
2013-03-18 10:47       ` Wenchao Xia [this message]
2013-03-18 10:09     ` Stefan Hajnoczi
2013-03-18 13:28 ` Pavel Hrdina
2013-03-21  6:43   ` Wenchao Xia
2013-03-21 11:48     ` Pavel Hrdina
2013-03-21 13:38       ` Stefan Hajnoczi
2013-03-21 13:42         ` Paolo Bonzini
2013-03-21 13:53           ` Pavel Hrdina
2013-03-21 14:56           ` Stefan Hajnoczi
2013-03-21 15:08             ` Eric Blake
2013-03-23  4:36               ` Wenchao Xia
2013-03-27  3:35                 ` Wenchao Xia
2013-03-21 13:43         ` Pavel Hrdina

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=5146F0DD.6060008@linux.vnet.ibm.com \
    --to=xiawenc@linux.vnet.ibm.com \
    --cc=dietmar@proxmox.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.