KVM call minutes for June 8

KVM call minutes for June 8

[Chris Wright]

Accelerating counters (aka moving PIT to userspace, keeping HPET in
userspace)
- PIT (in-kernel, userspace, or split)
- userspace PIT, too slow
- kernel PIT (already seen bugs)
- split PIT, not realistic w/out a sane interface (see bugs above)
- exit to userspace is a base cost, add MSR save/restore, add qemu
  overhead...and exit to userspace is expensive
- hpet in userspace (at least minimal counter reading)
- ioapic 
  - less than half is architectural, more than half endds of being
     interrupt reinjection

Live migration + hotplug
- start a machine, hotplug device, allocate ram...can't migrate
  - last_offset and ramblock sections coming from cmdline may not be
    compatible w/ hotplug
  - worst case is different ramblock order and data corruption
- alex has patches to convert ramblocks into queuelist
  - give name, offset
  - will clean up and send out today

migration events?
- QMP (wire protocol) has nice async events
  - QError reasonable
  - migration is async command, can complete w/ error or success
- QMP broken for error
  - need context for error, default is monitor, but async command
  - redo qerror_report, propagate error (or always have error context
    available)
- monitor and qmp done w/ same dispatch functions
  - should do monitor in terms of qmp
    - every qerror replacing monitor printf error
      - ends up not sharing enough ($foo not found, where $foo is contextual)
- async command (pass in command completion)
- may have to do limited (throw away for 0.13 and redo properly for 0.14)
- anthony has a (not fully working) tree, and will document direction on wiki

migration subsections.
- stable IDE version 3 is different for <= 0.12.2  than > 0.12.2
- for stable could bump to version 4, blacklist version 3
- unstable IDE version 4, works

APIC wiring problems (attached slides)
- postponed until tomorrow's code overview slot

[Qemu-devel] KVM call minutes for June 8

[Chris Wright]

Accelerating counters (aka moving PIT to userspace, keeping HPET in
userspace)
- PIT (in-kernel, userspace, or split)
- userspace PIT, too slow
- kernel PIT (already seen bugs)
- split PIT, not realistic w/out a sane interface (see bugs above)
- exit to userspace is a base cost, add MSR save/restore, add qemu
  overhead...and exit to userspace is expensive
- hpet in userspace (at least minimal counter reading)
- ioapic 
  - less than half is architectural, more than half endds of being
     interrupt reinjection

Live migration + hotplug
- start a machine, hotplug device, allocate ram...can't migrate
  - last_offset and ramblock sections coming from cmdline may not be
    compatible w/ hotplug
  - worst case is different ramblock order and data corruption
- alex has patches to convert ramblocks into queuelist
  - give name, offset
  - will clean up and send out today

migration events?
- QMP (wire protocol) has nice async events
  - QError reasonable
  - migration is async command, can complete w/ error or success
- QMP broken for error
  - need context for error, default is monitor, but async command
  - redo qerror_report, propagate error (or always have error context
    available)
- monitor and qmp done w/ same dispatch functions
  - should do monitor in terms of qmp
    - every qerror replacing monitor printf error
      - ends up not sharing enough ($foo not found, where $foo is contextual)
- async command (pass in command completion)
- may have to do limited (throw away for 0.13 and redo properly for 0.14)
- anthony has a (not fully working) tree, and will document direction on wiki

migration subsections.
- stable IDE version 3 is different for <= 0.12.2  than > 0.12.2
- for stable could bump to version 4, blacklist version 3
- unstable IDE version 4, works

APIC wiring problems (attached slides)
- postponed until tomorrow's code overview slot

Re: KVM call minutes for June 8

[Anthony Liguori]

On 06/08/2010 10:05 AM, Chris Wright wrote:
> Accelerating counters (aka moving PIT to userspace, keeping HPET in
> userspace)
> - PIT (in-kernel, userspace, or split)
> - userspace PIT, too slow
> - kernel PIT (already seen bugs)
> - split PIT, not realistic w/out a sane interface (see bugs above)
> - exit to userspace is a base cost, add MSR save/restore, add qemu
>    overhead...and exit to userspace is expensive
> - hpet in userspace (at least minimal counter reading)
> - ioapic
>    - less than half is architectural, more than half endds of being
>       interrupt reinjection
>
> Live migration + hotplug
> - start a machine, hotplug device, allocate ram...can't migrate
>    - last_offset and ramblock sections coming from cmdline may not be
>      compatible w/ hotplug
>    - worst case is different ramblock order and data corruption
> - alex has patches to convert ramblocks into queuelist
>    - give name, offset
>    - will clean up and send out today
>
> migration events?
> - QMP (wire protocol) has nice async events
>    - QError reasonable
>    - migration is async command, can complete w/ error or success
> - QMP broken for error
>    - need context for error, default is monitor, but async command
>    - redo qerror_report, propagate error (or always have error context
>      available)
> - monitor and qmp done w/ same dispatch functions
>    - should do monitor in terms of qmp
>      - every qerror replacing monitor printf error
>        - ends up not sharing enough ($foo not found, where $foo is contextual)
> - async command (pass in command completion)
> - may have to do limited (throw away for 0.13 and redo properly for 0.14)
> - anthony has a (not fully working) tree, and will document direction on wiki
>    

http://wiki.qemu.org/Features/QMP2

Includes a pointer to the current tree I'm working out of.

Regards,

Anthony Liguori

[Qemu-devel] Re: KVM call minutes for June 8

[Anthony Liguori]

On 06/08/2010 10:05 AM, Chris Wright wrote:
> Accelerating counters (aka moving PIT to userspace, keeping HPET in
> userspace)
> - PIT (in-kernel, userspace, or split)
> - userspace PIT, too slow
> - kernel PIT (already seen bugs)
> - split PIT, not realistic w/out a sane interface (see bugs above)
> - exit to userspace is a base cost, add MSR save/restore, add qemu
>    overhead...and exit to userspace is expensive
> - hpet in userspace (at least minimal counter reading)
> - ioapic
>    - less than half is architectural, more than half endds of being
>       interrupt reinjection
>
> Live migration + hotplug
> - start a machine, hotplug device, allocate ram...can't migrate
>    - last_offset and ramblock sections coming from cmdline may not be
>      compatible w/ hotplug
>    - worst case is different ramblock order and data corruption
> - alex has patches to convert ramblocks into queuelist
>    - give name, offset
>    - will clean up and send out today
>
> migration events?
> - QMP (wire protocol) has nice async events
>    - QError reasonable
>    - migration is async command, can complete w/ error or success
> - QMP broken for error
>    - need context for error, default is monitor, but async command
>    - redo qerror_report, propagate error (or always have error context
>      available)
> - monitor and qmp done w/ same dispatch functions
>    - should do monitor in terms of qmp
>      - every qerror replacing monitor printf error
>        - ends up not sharing enough ($foo not found, where $foo is contextual)
> - async command (pass in command completion)
> - may have to do limited (throw away for 0.13 and redo properly for 0.14)
> - anthony has a (not fully working) tree, and will document direction on wiki
>    

http://wiki.qemu.org/Features/QMP2

Includes a pointer to the current tree I'm working out of.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Luiz Capitulino]

On Tue, 08 Jun 2010 11:01:19 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 06/08/2010 10:05 AM, Chris Wright wrote:

[...]

> > migration events?
> > - QMP (wire protocol) has nice async events
> >    - QError reasonable
> >    - migration is async command, can complete w/ error or success
> > - QMP broken for error
> >    - need context for error, default is monitor, but async command
> >    - redo qerror_report, propagate error (or always have error context
> >      available)
> > - monitor and qmp done w/ same dispatch functions
> >    - should do monitor in terms of qmp
> >      - every qerror replacing monitor printf error
> >        - ends up not sharing enough ($foo not found, where $foo is contextual)
> > - async command (pass in command completion)
> > - may have to do limited (throw away for 0.13 and redo properly for 0.14)
> > - anthony has a (not fully working) tree, and will document direction on wiki
> >   

 Nice summary. 
> 
> http://wiki.qemu.org/Features/QMP2

 Nice page, except that its original name raised the question whether
current QMP was going to be thrown away and done from scratch :-)

 I agree on most points and yes, we have issues with QError and async
commands. However, as we talked by IRC, I think we should define what's
blocker for 0.13 and what's ok to be postponed.

 IMO, there are two classes of problems that have to be fixed for 0.13:

 1. Client visible changes
 2. Any issue that makes QMP not work as specified by its documentation

 Async commands is item 2, but it doesn't look that serious to me provided
that, as you said, we ensure that commands don't run in parallel and that
query-balloon (our only async command) doesn't hit the issue.

 The decoupling of QMP and HMP is something I really wanted to do, but this
is clearly not 0.13 material. Also note that the monitor state before QMP
was quite horrible, it's slightly better now, but main point is: we would
not have QMP today if we would fix/cleanup all the problems we've found,
specially because some problems span the monitor code base.

 Now, QError.

 This is something I think we should fix for 0.13. However, I still don't
know how to get it right: most of what you say in the wiki page has already
been discussed before.

 For example, you suggest the error object should be returned, this is
probably a requirement to have async commands working, but this thread
explains the problems we had with that:

 http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00818.html

 Another issue is that QErrors are getting too specific. I see two problems
here, first how errors should be done and how to map errno properly, also
already discussed:

 http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg00314.html

 Finally, sometimes handler A and handler B can share the error class but not
the error context. I can't locate a good example right now, but this becomes
evident if you have a 1:1 mapping between QError and errno (eg, EINVAL can be
anything), so it's hard to share errors in this case and we end up creating
new ones.

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Anthony Liguori]

On 06/08/2010 03:59 PM, Luiz Capitulino wrote:
>   Now, QError.
>
>   This is something I think we should fix for 0.13. However, I still don't
> know how to get it right: most of what you say in the wiki page has already
> been discussed before.
>
>   For example, you suggest the error object should be returned, this is
> probably a requirement to have async commands working, but this thread
> explains the problems we had with that:
>
>   http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00818.html
>    

Sometimes we have to make difficult changes and touch a lot of code.  
There's really no other way and we're just going to have to grit our 
teeth and do it.  Honestly, it's not that bad though having gone through 
much of the code at this point.

>   Another issue is that QErrors are getting too specific. I see two problems
> here, first how errors should be done and how to map errno properly, also
> already discussed:
>
>   http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg00314.html
>    

We're going to have to basically drop most of the QErrors we have today 
for 0.14 after we straighten out the error mess.

Errors are pretty easy to deprecate and replace.  All clients have to 
handle new types of errors so the worst thing that will happen is that 
they have less specific errors.

The big problem is things like the block io error events.  I don't see 
how we can support that given what we have in 0.13.  Putting errno on 
the wire is a bad idea.  We need to marshal a QError object using the 
__class__ memory to identify it as QError and pass that with the event.  
It could potentially be made to work for 0.13 but it'll be ugly.

>   Finally, sometimes handler A and handler B can share the error class but not
> the error context. I can't locate a good example right now, but this becomes
> evident if you have a 1:1 mapping between QError and errno (eg, EINVAL can be
> anything), so it's hard to share errors in this case and we end up creating
> new ones.
>    

But handler A and handler B have the context that they are A and B so 
they can display the error differently.  That's the whole point.

There should be a 1:1 mapping between QError and errno.  That's the 
problem with QErrors today.  Instead of ENOENT, we have BusNotFound, 
CommandNotFound, DeviceNotFound, FdNotFound, PropertyNotFound, and 
PropertyValueNotFound.

All we really need is a single ItemNotFound event that takes a 'context' 
and 'item' data.  A generic way to dump the error would be '%(context) 
named "%(item)" not found".  The advantage of QErrors over errno is that 
we can add a little bit more data to it to make error inspection a bit 
friendlier.  But regardless of that extra info, we should still be using 
the equivalent of just ENOENT, not EBUSNOENT, ECOMMANDNOENT, 
EDEVICENOENT, etc.

If you want to display more custom text, then you have to be able to 
inspect the QError object, get the info from it, and then decide based 
on the context the error was generated, how to display it.  The ability 
to work with QErrors in a meaningful way in handlers is keeping us from 
doing this today.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Luiz Capitulino]

On Tue, 08 Jun 2010 16:13:37 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 06/08/2010 03:59 PM, Luiz Capitulino wrote:
> >   Now, QError.
> >
> >   This is something I think we should fix for 0.13. However, I still don't
> > know how to get it right: most of what you say in the wiki page has already
> > been discussed before.
> >
> >   For example, you suggest the error object should be returned, this is
> > probably a requirement to have async commands working, but this thread
> > explains the problems we had with that:
> >
> >   http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00818.html
> >    
> 
> Sometimes we have to make difficult changes and touch a lot of code.  
> There's really no other way and we're just going to have to grit our 
> teeth and do it.  Honestly, it's not that bad though having gone through 
> much of the code at this point.

 Let's see, we should start working on this as soon as 0.13 is out.

> >   Another issue is that QErrors are getting too specific. I see two problems
> > here, first how errors should be done and how to map errno properly, also
> > already discussed:
> >
> >   http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg00314.html
> >    
> 
> We're going to have to basically drop most of the QErrors we have today 
> for 0.14 after we straighten out the error mess.
> 
> Errors are pretty easy to deprecate and replace.  All clients have to 
> handle new types of errors so the worst thing that will happen is that 
> they have less specific errors.

 Another problem is that a client might be waiting for a specific error
that would never arrive. For example, say you wrote a shell and the
CommandNotFound error is something expected to happen, this will break.

 Yes, well written clients should check the 'error' key first and won't
panic if what they expect is not there. Even then, it's an annoying
issue.

 What we can do to minimize the damage is:

 1. Clearly state somewhere that errors are going to be removed
 2. Keep errors undocumented (this turned out to be a feature!)

> The big problem is things like the block io error events.  I don't see 
> how we can support that given what we have in 0.13.  Putting errno on 
> the wire is a bad idea.  We need to marshal a QError object using the 
> __class__ memory to identify it as QError and pass that with the event.  
> It could potentially be made to work for 0.13 but it'll be ugly.

 Yes, that's the main problem of the whole thing I think.

 From QEMU pov, the best thing to do would be to let this event as it's
today and wait for the new QError (it's a compatible change, anyway).

 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?

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Daniel P. Berrange]

On Wed, Jun 09, 2010 at 12:18:20PM -0300, Luiz Capitulino wrote:
> On Tue, 08 Jun 2010 16:13:37 -0500
> Anthony Liguori <anthony@codemonkey.ws> wrote:
> 
> > On 06/08/2010 03:59 PM, Luiz Capitulino wrote:
> > >   Now, QError.
> > >
> > >   This is something I think we should fix for 0.13. However, I still don't
> > > know how to get it right: most of what you say in the wiki page has already
> > > been discussed before.
> > >
> > >   For example, you suggest the error object should be returned, this is
> > > probably a requirement to have async commands working, but this thread
> > > explains the problems we had with that:
> > >
> > >   http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00818.html
> > >    
> > 
> > Sometimes we have to make difficult changes and touch a lot of code.  
> > There's really no other way and we're just going to have to grit our 
> > teeth and do it.  Honestly, it's not that bad though having gone through 
> > much of the code at this point.
> 
>  Let's see, we should start working on this as soon as 0.13 is out.
> 
> > >   Another issue is that QErrors are getting too specific. I see two problems
> > > here, first how errors should be done and how to map errno properly, also
> > > already discussed:
> > >
> > >   http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg00314.html
> > >    
> > 
> > We're going to have to basically drop most of the QErrors we have today 
> > for 0.14 after we straighten out the error mess.
> > 
> > Errors are pretty easy to deprecate and replace.  All clients have to 
> > handle new types of errors so the worst thing that will happen is that 
> > they have less specific errors.
> 
>  Another problem is that a client might be waiting for a specific error
> that would never arrive. For example, say you wrote a shell and the
> CommandNotFound error is something expected to happen, this will break.
> 
>  Yes, well written clients should check the 'error' key first and won't
> panic if what they expect is not there. Even then, it's an annoying
> issue.

libvirt is even more paranoid than this. It checks for 'error' key
being present, and if that's not present, it then also for the 'return'
key not being present.

>  What we can do to minimize the damage is:
> 
>  1. Clearly state somewhere that errors are going to be removed
>  2. Keep errors undocumented (this turned out to be a feature!)
> 
> > The big problem is things like the block io error events.  I don't see 
> > how we can support that given what we have in 0.13.  Putting errno on 
> > the wire is a bad idea.  We need to marshal a QError object using the 
> > __class__ memory to identify it as QError and pass that with the event.  
> > It could potentially be made to work for 0.13 but it'll be ugly.
> 
>  Yes, that's the main problem of the whole thing I think.
> 
>  From QEMU pov, the best thing to do would be to let this event as it's
> today and wait for the new QError (it's a compatible change, anyway).

FYI, in terms of errors, libvirt currently relies on very little.

When dealing with 'balloon' and 'query-balloon' we check for
two explicit errors:

   class=DeviceNotActive 
   class=KVMMissingCap

in order to detect whether ballooning is supported in this guest.

In all other cases, we simply pass the 'class' and 'desc' field back up to
the libvirt error reporting code, and don't care what strings are in those
fields. So if we add a whole lot more QErrors, or  deprecate error codes the
impact won't be serious apart from those two cases I mention.

>  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.

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 :|

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Daniel P. Berrange]

On Wed, Jun 09, 2010 at 12:18:20PM -0300, Luiz Capitulino wrote:
> On Tue, 08 Jun 2010 16:13:37 -0500
> Anthony Liguori <anthony@codemonkey.ws> wrote:
> 
> > On 06/08/2010 03:59 PM, Luiz Capitulino wrote:
> > >   Now, QError.
> > >
> > >   This is something I think we should fix for 0.13. However, I still don't
> > > know how to get it right: most of what you say in the wiki page has already
> > > been discussed before.
> > >
> > >   For example, you suggest the error object should be returned, this is
> > > probably a requirement to have async commands working, but this thread
> > > explains the problems we had with that:
> > >
> > >   http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00818.html
> > >    
> > 
> > Sometimes we have to make difficult changes and touch a lot of code.  
> > There's really no other way and we're just going to have to grit our 
> > teeth and do it.  Honestly, it's not that bad though having gone through 
> > much of the code at this point.
> 
>  Let's see, we should start working on this as soon as 0.13 is out.
> 
> > >   Another issue is that QErrors are getting too specific. I see two problems
> > > here, first how errors should be done and how to map errno properly, also
> > > already discussed:
> > >
> > >   http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg00314.html
> > >    
> > 
> > We're going to have to basically drop most of the QErrors we have today 
> > for 0.14 after we straighten out the error mess.
> > 
> > Errors are pretty easy to deprecate and replace.  All clients have to 
> > handle new types of errors so the worst thing that will happen is that 
> > they have less specific errors.
> 
>  Another problem is that a client might be waiting for a specific error
> that would never arrive. For example, say you wrote a shell and the
> CommandNotFound error is something expected to happen, this will break.
> 
>  Yes, well written clients should check the 'error' key first and won't
> panic if what they expect is not there. Even then, it's an annoying
> issue.

libvirt is even more paranoid than this. It checks for 'error' key
being present, and if that's not present, it then also for the 'return'
key not being present.

>  What we can do to minimize the damage is:
> 
>  1. Clearly state somewhere that errors are going to be removed
>  2. Keep errors undocumented (this turned out to be a feature!)
> 
> > The big problem is things like the block io error events.  I don't see 
> > how we can support that given what we have in 0.13.  Putting errno on 
> > the wire is a bad idea.  We need to marshal a QError object using the 
> > __class__ memory to identify it as QError and pass that with the event.  
> > It could potentially be made to work for 0.13 but it'll be ugly.
> 
>  Yes, that's the main problem of the whole thing I think.
> 
>  From QEMU pov, the best thing to do would be to let this event as it's
> today and wait for the new QError (it's a compatible change, anyway).

FYI, in terms of errors, libvirt currently relies on very little.

When dealing with 'balloon' and 'query-balloon' we check for
two explicit errors:

   class=DeviceNotActive 
   class=KVMMissingCap

in order to detect whether ballooning is supported in this guest.

In all other cases, we simply pass the 'class' and 'desc' field back up to
the libvirt error reporting code, and don't care what strings are in those
fields. So if we add a whole lot more QErrors, or  deprecate error codes the
impact won't be serious apart from those two cases I mention.

>  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.

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 :|

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Anthony Liguori]

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.

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

Regards,

Anthony Liguori

> Regards,
> Daniel
>    

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Anthony Liguori]

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.

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

Regards,

Anthony Liguori

> Regards,
> Daniel
>    

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Anthony Liguori]

On 06/09/2010 10:18 AM, Luiz Capitulino wrote:
>> The big problem is things like the block io error events.  I don't see
>> how we can support that given what we have in 0.13.  Putting errno on
>> the wire is a bad idea.  We need to marshal a QError object using the
>> __class__ memory to identify it as QError and pass that with the event.
>> It could potentially be made to work for 0.13 but it'll be ugly.
>>      
>   Yes, that's the main problem of the whole thing I think.
>
>   From QEMU pov, the best thing to do would be to let this event as it's
> today and wait for the new QError (it's a compatible change, anyway).
>    

I'd prefer that we just send the event with an embedded qerror (using 
__class__).  We can generate it directly instead of using 
qerror_report/qerror_new.  It's ugly but it'll work and be future 
compatible.  For now, let's just support a few types of qerror to 
basically distinguish between an unknown io error and ENOSPC.

>   However, libvirt was counting on this feature and on the snapshot commands
> to switch from the text Monitor. We have two options:
>    

I don't think snapshots are actually usable by libvirt in the current form.

Regards,

Anthony LIguori

>   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?
>    

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Daniel P. Berrange]

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 :|

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Daniel P. Berrange]

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 :|

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Kevin Wolf]

Am 09.06.2010 18:22, schrieb Anthony Liguori:
> 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

Huh, why this? Seems I still haven't understood all of qcow2 then... I
always thought that there's just a specific offset where VM state
starts, but no explicit end.

Kevin

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Kevin Wolf]

Am 09.06.2010 18:22, schrieb Anthony Liguori:
> 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

Huh, why this? Seems I still haven't understood all of qcow2 then... I
always thought that there's just a specific offset where VM state
starts, but no explicit end.

Kevin

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Anthony Liguori]

On 06/10/2010 04:43 AM, Kevin Wolf wrote:
>
> Huh, why this? Seems I still haven't understood all of qcow2 then... I
> always thought that there's just a specific offset where VM state
> starts, but no explicit end.
>    

A live snapshot can last for a very long time.  What happens if you need 
to allocate a new block for disk I/O while saving a snapshot?

Regards,

Anthony Liguori

> Kevin
>    

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Anthony Liguori]

On 06/10/2010 04:43 AM, Kevin Wolf wrote:
>
> Huh, why this? Seems I still haven't understood all of qcow2 then... I
> always thought that there's just a specific offset where VM state
> starts, but no explicit end.
>    

A live snapshot can last for a very long time.  What happens if you need 
to allocate a new block for disk I/O while saving a snapshot?

Regards,

Anthony Liguori

> Kevin
>    

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Kevin Wolf]

Am 10.06.2010 14:53, schrieb Anthony Liguori:
> On 06/10/2010 04:43 AM, Kevin Wolf wrote:
>>
>> Huh, why this? Seems I still haven't understood all of qcow2 then... I
>> always thought that there's just a specific offset where VM state
>> starts, but no explicit end.
>>    
> 
> A live snapshot can last for a very long time.  What happens if you need 
> to allocate a new block for disk I/O while saving a snapshot?

You allocate it, I guess?

Note that VM state must be virtually contiguous, but not necessarily
physically (virtually = on the virtual hard disk as seen by the guest;
physically = in the image file). It's just not seen by the guest because
it's saved at a high offset that is after the end of the real disk
content, but otherwise it should behave the same as guest data.

Kevin

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Kevin Wolf]

Am 10.06.2010 14:53, schrieb Anthony Liguori:
> On 06/10/2010 04:43 AM, Kevin Wolf wrote:
>>
>> Huh, why this? Seems I still haven't understood all of qcow2 then... I
>> always thought that there's just a specific offset where VM state
>> starts, but no explicit end.
>>    
> 
> A live snapshot can last for a very long time.  What happens if you need 
> to allocate a new block for disk I/O while saving a snapshot?

You allocate it, I guess?

Note that VM state must be virtually contiguous, but not necessarily
physically (virtually = on the virtual hard disk as seen by the guest;
physically = in the image file). It's just not seen by the guest because
it's saved at a high offset that is after the end of the real disk
content, but otherwise it should behave the same as guest data.

Kevin

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Avi Kivity]

On 06/10/2010 04:08 PM, Kevin Wolf wrote:
> It's just not seen by the guest because
> it's saved at a high offset that is after the end of the real disk
> content, but otherwise it should behave the same as guest data.
>    

That's very unfriendly towards extending the guest-visible portion of 
the disk.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Avi Kivity]

On 06/10/2010 04:08 PM, Kevin Wolf wrote:
> It's just not seen by the guest because
> it's saved at a high offset that is after the end of the real disk
> content, but otherwise it should behave the same as guest data.
>    

That's very unfriendly towards extending the guest-visible portion of 
the disk.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Kevin Wolf]

Am 10.06.2010 16:11, schrieb Avi Kivity:
> On 06/10/2010 04:08 PM, Kevin Wolf wrote:
>> It's just not seen by the guest because
>> it's saved at a high offset that is after the end of the real disk
>> content, but otherwise it should behave the same as guest data.
>>    
> 
> That's very unfriendly towards extending the guest-visible portion of 
> the disk.

Actually, it's not too bad: The start of the VM state area is aligned to
a L2 table start. It just requires moving some L1 table entries upwards.

Kevin

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Kevin Wolf]

Am 10.06.2010 16:11, schrieb Avi Kivity:
> On 06/10/2010 04:08 PM, Kevin Wolf wrote:
>> It's just not seen by the guest because
>> it's saved at a high offset that is after the end of the real disk
>> content, but otherwise it should behave the same as guest data.
>>    
> 
> That's very unfriendly towards extending the guest-visible portion of 
> the disk.

Actually, it's not too bad: The start of the VM state area is aligned to
a L2 table start. It just requires moving some L1 table entries upwards.

Kevin

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Anthony Liguori]

On 06/10/2010 08:08 AM, Kevin Wolf wrote:
> Am 10.06.2010 14:53, schrieb Anthony Liguori:
>    
>> On 06/10/2010 04:43 AM, Kevin Wolf wrote:
>>      
>>> Huh, why this? Seems I still haven't understood all of qcow2 then... I
>>> always thought that there's just a specific offset where VM state
>>> starts, but no explicit end.
>>>
>>>        
>> A live snapshot can last for a very long time.  What happens if you need
>> to allocate a new block for disk I/O while saving a snapshot?
>>      
> You allocate it, I guess?
>
> Note that VM state must be virtually contiguous, but not necessarily
> physically (virtually = on the virtual hard disk as seen by the guest;
> physically = in the image file). It's just not seen by the guest because
> it's saved at a high offset that is after the end of the real disk
> content, but otherwise it should behave the same as guest data.
>    

I guess you could just start writing and then once your finished, you 
could update the snapshot information.  So yeah, I think your right that 
it's doable with the current format.

Regards,

Anthony Liguori

> Kevin
>    

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Anthony Liguori]

On 06/10/2010 08:08 AM, Kevin Wolf wrote:
> Am 10.06.2010 14:53, schrieb Anthony Liguori:
>    
>> On 06/10/2010 04:43 AM, Kevin Wolf wrote:
>>      
>>> Huh, why this? Seems I still haven't understood all of qcow2 then... I
>>> always thought that there's just a specific offset where VM state
>>> starts, but no explicit end.
>>>
>>>        
>> A live snapshot can last for a very long time.  What happens if you need
>> to allocate a new block for disk I/O while saving a snapshot?
>>      
> You allocate it, I guess?
>
> Note that VM state must be virtually contiguous, but not necessarily
> physically (virtually = on the virtual hard disk as seen by the guest;
> physically = in the image file). It's just not seen by the guest because
> it's saved at a high offset that is after the end of the real disk
> content, but otherwise it should behave the same as guest data.
>    

I guess you could just start writing and then once your finished, you 
could update the snapshot information.  So yeah, I think your right that 
it's doable with the current format.

Regards,

Anthony Liguori

> Kevin
>    

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Luiz Capitulino]

On Thu, 10 Jun 2010 09:27:34 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 06/10/2010 08:08 AM, Kevin Wolf wrote:
> > Am 10.06.2010 14:53, schrieb Anthony Liguori:
> >    
> >> On 06/10/2010 04:43 AM, Kevin Wolf wrote:
> >>      
> >>> Huh, why this? Seems I still haven't understood all of qcow2 then... I
> >>> always thought that there's just a specific offset where VM state
> >>> starts, but no explicit end.
> >>>
> >>>        
> >> A live snapshot can last for a very long time.  What happens if you need
> >> to allocate a new block for disk I/O while saving a snapshot?
> >>      
> > You allocate it, I guess?
> >
> > Note that VM state must be virtually contiguous, but not necessarily
> > physically (virtually = on the virtual hard disk as seen by the guest;
> > physically = in the image file). It's just not seen by the guest because
> > it's saved at a high offset that is after the end of the real disk
> > content, but otherwise it should behave the same as guest data.
> >    
> 
> I guess you could just start writing and then once your finished, you 
> could update the snapshot information.  So yeah, I think your right that 
> it's doable with the current format.

 No more issues on having them in QMP for 0.13 then?

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Luiz Capitulino]

On Thu, 10 Jun 2010 09:27:34 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 06/10/2010 08:08 AM, Kevin Wolf wrote:
> > Am 10.06.2010 14:53, schrieb Anthony Liguori:
> >    
> >> On 06/10/2010 04:43 AM, Kevin Wolf wrote:
> >>      
> >>> Huh, why this? Seems I still haven't understood all of qcow2 then... I
> >>> always thought that there's just a specific offset where VM state
> >>> starts, but no explicit end.
> >>>
> >>>        
> >> A live snapshot can last for a very long time.  What happens if you need
> >> to allocate a new block for disk I/O while saving a snapshot?
> >>      
> > You allocate it, I guess?
> >
> > Note that VM state must be virtually contiguous, but not necessarily
> > physically (virtually = on the virtual hard disk as seen by the guest;
> > physically = in the image file). It's just not seen by the guest because
> > it's saved at a high offset that is after the end of the real disk
> > content, but otherwise it should behave the same as guest data.
> >    
> 
> I guess you could just start writing and then once your finished, you 
> could update the snapshot information.  So yeah, I think your right that 
> it's doable with the current format.

 No more issues on having them in QMP for 0.13 then?

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Anthony Liguori]

On 06/11/2010 07:55 AM, Luiz Capitulino wrote:
> On Thu, 10 Jun 2010 09:27:34 -0500
> Anthony Liguori<anthony@codemonkey.ws>  wrote:
>
>    
>> On 06/10/2010 08:08 AM, Kevin Wolf wrote:
>>      
>>> Am 10.06.2010 14:53, schrieb Anthony Liguori:
>>>
>>>        
>>>> On 06/10/2010 04:43 AM, Kevin Wolf wrote:
>>>>
>>>>          
>>>>> Huh, why this? Seems I still haven't understood all of qcow2 then... I
>>>>> always thought that there's just a specific offset where VM state
>>>>> starts, but no explicit end.
>>>>>
>>>>>
>>>>>            
>>>> A live snapshot can last for a very long time.  What happens if you need
>>>> to allocate a new block for disk I/O while saving a snapshot?
>>>>
>>>>          
>>> You allocate it, I guess?
>>>
>>> Note that VM state must be virtually contiguous, but not necessarily
>>> physically (virtually = on the virtual hard disk as seen by the guest;
>>> physically = in the image file). It's just not seen by the guest because
>>> it's saved at a high offset that is after the end of the real disk
>>> content, but otherwise it should behave the same as guest data.
>>>
>>>        
>> I guess you could just start writing and then once your finished, you
>> could update the snapshot information.  So yeah, I think your right that
>> it's doable with the current format.
>>      
>   No more issues on having them in QMP for 0.13 then?
>    

I still think it's wrong to expose a broken command with no way for a 
user to detect whether it works or not.  The fact that no other commands 
can run during it and the command may run for many minutes is still part 
of the protocol ABI IMHO.

Regards,

Anthony Liguori

> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

Re: [Qemu-devel] Re: KVM call minutes for June 8

[Anthony Liguori]

On 06/11/2010 07:55 AM, Luiz Capitulino wrote:
> On Thu, 10 Jun 2010 09:27:34 -0500
> Anthony Liguori<anthony@codemonkey.ws>  wrote:
>
>    
>> On 06/10/2010 08:08 AM, Kevin Wolf wrote:
>>      
>>> Am 10.06.2010 14:53, schrieb Anthony Liguori:
>>>
>>>        
>>>> On 06/10/2010 04:43 AM, Kevin Wolf wrote:
>>>>
>>>>          
>>>>> Huh, why this? Seems I still haven't understood all of qcow2 then... I
>>>>> always thought that there's just a specific offset where VM state
>>>>> starts, but no explicit end.
>>>>>
>>>>>
>>>>>            
>>>> A live snapshot can last for a very long time.  What happens if you need
>>>> to allocate a new block for disk I/O while saving a snapshot?
>>>>
>>>>          
>>> You allocate it, I guess?
>>>
>>> Note that VM state must be virtually contiguous, but not necessarily
>>> physically (virtually = on the virtual hard disk as seen by the guest;
>>> physically = in the image file). It's just not seen by the guest because
>>> it's saved at a high offset that is after the end of the real disk
>>> content, but otherwise it should behave the same as guest data.
>>>
>>>        
>> I guess you could just start writing and then once your finished, you
>> could update the snapshot information.  So yeah, I think your right that
>> it's doable with the current format.
>>      
>   No more issues on having them in QMP for 0.13 then?
>    

I still think it's wrong to expose a broken command with no way for a 
user to detect whether it works or not.  The fact that no other commands 
can run during it and the command may run for many minutes is still part 
of the protocol ABI IMHO.

Regards,

Anthony Liguori

> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>