All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Luiz Capitulino <lcapitulino@redhat.com>,
	Chris Wright <chrisw@redhat.com>,
	qemu-devel@nongnu.org, kvm-devel <kvm@vger.kernel.org>,
	armbru@redhat.com, Kevin Wolf <kwolf@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 :|

WARNING: multiple messages have this Message-ID (diff)
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: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-08 15:05 KVM call minutes for June 8 Chris Wright
2010-06-08 15:05 ` [Qemu-devel] " Chris Wright
2010-06-08 16:01 ` Anthony Liguori
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 15:31           ` Daniel P. Berrange
2010-06-09 16:22           ` Anthony Liguori
2010-06-09 16:22             ` Anthony Liguori
2010-06-09 16:29             ` Daniel P. Berrange [this message]
2010-06-09 16:29               ` Daniel P. Berrange
2010-06-10  9:43             ` Kevin Wolf
2010-06-10  9:43               ` Kevin Wolf
2010-06-10 12:53               ` Anthony Liguori
2010-06-10 12:53                 ` Anthony Liguori
2010-06-10 13:08                 ` Kevin Wolf
2010-06-10 13:08                   ` Kevin Wolf
2010-06-10 14:11                   ` Avi Kivity
2010-06-10 14:11                     ` Avi Kivity
2010-06-10 14:22                     ` Kevin Wolf
2010-06-10 14:22                       ` Kevin Wolf
2010-06-10 14:27                   ` Anthony Liguori
2010-06-10 14:27                     ` Anthony Liguori
2010-06-11 12:55                     ` Luiz Capitulino
2010-06-11 12:55                       ` Luiz Capitulino
2010-06-11 13:48                       ` Anthony Liguori
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 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.