Re: [Qemu-devel] [RFC] qmp interface for save vmstate to image

[Wenchao Xia]

于 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