Re: [Qemu-devel] Re: KVM call minutes for June 8
On Thu, 10 Jun 2010 09:27:34 -0500 Anthony Liguori anth...@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? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call minutes for June 8
On 06/11/2010 07:55 AM, Luiz Capitulino wrote: On Thu, 10 Jun 2010 09:27:34 -0500 Anthony Liguorianth...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call minutes for June 8
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call minutes for June 8
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call minutes for June 8
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call minutes for June 8
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call minutes for June 8
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call minutes for June 8
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call minutes for June 8
On Tue, 08 Jun 2010 16:13:37 -0500 Anthony Liguori anth...@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? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call minutes for June 8
On Wed, Jun 09, 2010 at 12:18:20PM -0300, Luiz Capitulino wrote: On Tue, 08 Jun 2010 16:13:37 -0500 Anthony Liguori anth...@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 :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call minutes for June 8
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call minutes for June 8
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? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call minutes for June 8
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 :| -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call minutes for June 8
On Tue, 08 Jun 2010 11:01:19 -0500 Anthony Liguori anth...@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. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: KVM call minutes for June 8
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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
