qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Chris Wright <chrisw@redhat.com>, Kevin Wolf <kwolf@redhat.com>,
	kvm-devel <kvm@vger.kernel.org>,
	armbru@redhat.com, qemu-devel@nongnu.org,
	Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] Re: KVM call minutes for June 8
Date: Wed, 9 Jun 2010 17:29:55 +0100	[thread overview]
Message-ID: <20100609162955.GG28326@redhat.com> (raw)
In-Reply-To: <4C0FBFDF.5050009@codemonkey.ws>

On Wed, Jun 09, 2010 at 11:22:55AM -0500, Anthony Liguori wrote:
> On 06/09/2010 10:31 AM, Daniel P. Berrange wrote:
> >>  However, libvirt was counting on this feature and on the snapshot 
> >>  commands
> >>to switch from the text Monitor. We have two options:
> >>
> >>  1. Ask them to wait one more release (not so good for us)
> >>  2. Try to find a way to have those features in for 0.13
> >>
> >>  Daniel has commented to me that making the snapshot commands synchronous
> >>for 0.13 wouldn't be that bad, what do you think?
> >>     
> >The thought is that changing a command from synchronous to asynchronous is
> >not an ABI incompatible change. An existing app simply won't know to take
> >advantage of the new possibilities that async commands offer.
> >   
> 
> It's not QMP that's the major issue with savevm.  The major issue is 
> actually the way snapshots are saved in qcow2.  You need to know the 
> size of the snapshot prior to creating the snapshot which is not 
> possible if you want to make snapshots live.  In order to support this 
> functionality, we'll probably have to introduce a new snapshot format in 
> qcow2.
> 
> Honestly, I would recommend not supporting snapshots in libvirt until we 
> did the work to make snapshots live.  Snapshots can cause guests to 
> generate errors as it stands today and fixing that will almost certainly 
> result in backwards compatibility considerations.

Libvirt already supports savevm in the text mode monitor, hence the desire
to have it work in QMP too.

> If we did put savevm in QMP today, we would need to provide an interface 
> that let applications detect when we eventually fix this.

The problem you describe sounds like an internal qcow2 implementation
detail. The savevm related commands & their parameters don't have anything
that's inherantly tied to qcow2, so why would it affect QMP if qcow2 format
changed internally ?

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

  reply	other threads:[~2010-06-09 16:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-08 15:05 [Qemu-devel] KVM call minutes for June 8 Chris Wright
2010-06-08 16:01 ` [Qemu-devel] " Anthony Liguori
2010-06-08 20:59   ` Luiz Capitulino
2010-06-08 21:13     ` Anthony Liguori
2010-06-09 15:18       ` Luiz Capitulino
2010-06-09 15:31         ` Daniel P. Berrange
2010-06-09 16:22           ` Anthony Liguori
2010-06-09 16:29             ` Daniel P. Berrange [this message]
2010-06-10  9:43             ` Kevin Wolf
2010-06-10 12:53               ` Anthony Liguori
2010-06-10 13:08                 ` Kevin Wolf
2010-06-10 14:11                   ` Avi Kivity
2010-06-10 14:22                     ` Kevin Wolf
2010-06-10 14:27                   ` Anthony Liguori
2010-06-11 12:55                     ` Luiz Capitulino
2010-06-11 13:48                       ` Anthony Liguori
2010-06-09 16:26         ` Anthony Liguori

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=20100609162955.GG28326@redhat.com \
    --to=berrange@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=armbru@redhat.com \
    --cc=chrisw@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwolf@redhat.com \
    --cc=lcapitulino@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).