* [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) @ 2017-03-08 8:26 Thomas Huth 2017-03-08 10:03 ` Peter Maydell ` (3 more replies) 0 siblings, 4 replies; 52+ messages in thread From: Thomas Huth @ 2017-03-08 8:26 UTC (permalink / raw) To: QEMU Developers; +Cc: Peter Maydell, Stefan Hajnoczi Hi everybody, what will be the next version of QEMU after 2.9? Will we go for a 2.10 (as I've seen it mentioned a couple of times on the mailing list already), or do we dare to switch to 3.0 instead? I personally dislike two-digit minor version numbers like 2.10 since the non-experienced users sometimes mix it up with 2.1 ... and there have been a couple of new cool features in the past releases that would justify a 3.0 now, too, I think. But anyway, the more important thing that keeps me concerned is: Someone once told me that we should get rid of old parameters and interfaces (like HMP commands) primarily only when we're changing to a new major version number. As you all know, QEMU has a lot of legacy options, which are likely rather confusing than helpful for the new users nowadays, e.g. things like the "-net channel" option (which is fortunately even hardly documented), but maybe also even the whole vlan/hub concept in the net code, or legacy parameters like "-usbdevice". If we switch to version 3.0, could we agree to remove at least some of them? Thomas ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-08 8:26 [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) Thomas Huth @ 2017-03-08 10:03 ` Peter Maydell 2017-03-08 11:22 ` Thomas Huth 2017-03-08 10:20 ` [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) Daniel P. Berrange ` (2 subsequent siblings) 3 siblings, 1 reply; 52+ messages in thread From: Peter Maydell @ 2017-03-08 10:03 UTC (permalink / raw) To: Thomas Huth; +Cc: QEMU Developers, Stefan Hajnoczi On 8 March 2017 at 09:26, Thomas Huth <thuth@redhat.com> wrote: > But anyway, the more important thing that keeps me concerned is: Someone > once told me that we should get rid of old parameters and interfaces > (like HMP commands) primarily only when we're changing to a new major > version number. As you all know, QEMU has a lot of legacy options, which > are likely rather confusing than helpful for the new users nowadays, > e.g. things like the "-net channel" option (which is fortunately even > hardly documented), but maybe also even the whole vlan/hub concept in > the net code, or legacy parameters like "-usbdevice". If we switch to > version 3.0, could we agree to remove at least some of them? I think if we are going to deprecate and remove options we need a clear transition plan for doing so, which means at least one release where options are "still works, but warn that they are going away with pointer to documentation or similar info about their replacement syntax", before actually dropping them. (Similar applies if we want to deprecate and remove old and unmaintained machine models.) thanks -- PMM ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-08 10:03 ` Peter Maydell @ 2017-03-08 11:22 ` Thomas Huth 2017-03-08 11:24 ` Daniel P. Berrange 2017-03-09 2:21 ` Jason Wang 0 siblings, 2 replies; 52+ messages in thread From: Thomas Huth @ 2017-03-08 11:22 UTC (permalink / raw) To: Peter Maydell Cc: QEMU Developers, Stefan Hajnoczi, Daniel P. Berrange, Gerd Hoffmann, Jason Wang On 08.03.2017 11:03, Peter Maydell wrote: > On 8 March 2017 at 09:26, Thomas Huth <thuth@redhat.com> wrote: >> But anyway, the more important thing that keeps me concerned is: Someone >> once told me that we should get rid of old parameters and interfaces >> (like HMP commands) primarily only when we're changing to a new major >> version number. As you all know, QEMU has a lot of legacy options, which >> are likely rather confusing than helpful for the new users nowadays, >> e.g. things like the "-net channel" option (which is fortunately even >> hardly documented), but maybe also even the whole vlan/hub concept in >> the net code, or legacy parameters like "-usbdevice". If we switch to >> version 3.0, could we agree to remove at least some of them? > > I think if we are going to deprecate and remove options we need > a clear transition plan for doing so, which means at least one > release where options are "still works, but warn that they > are going away with pointer to documentation or similar info > about their replacement syntax", before actually dropping them. Yes, that's certainly a good idea. But as Daniel suggested in his mail, I think we should also have the rule that the option should be marked as deprecated in multiple releases first - so that the users have a chance to speak up before something gets really removed (otherwise the option could be removed right on the first day after the initial release with the deprecation message, so there is no time for the user to notice this and complain). Not sure whether we need three releases, as Daniel suggested, though, but if that's common sense, that's fine for me, too. Anyway, I've now started a Wiki page where we could track the removal of deprecated interfaces: http://wiki.qemu-project.org/Features/LegacyRemoval Feedback / updates / addition of other legacy interfaces is welcome! Thomas ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-08 11:22 ` Thomas Huth @ 2017-03-08 11:24 ` Daniel P. Berrange 2017-03-09 12:33 ` Markus Armbruster 2017-03-09 2:21 ` Jason Wang 1 sibling, 1 reply; 52+ messages in thread From: Daniel P. Berrange @ 2017-03-08 11:24 UTC (permalink / raw) To: Thomas Huth Cc: Peter Maydell, QEMU Developers, Stefan Hajnoczi, Gerd Hoffmann, Jason Wang On Wed, Mar 08, 2017 at 12:22:24PM +0100, Thomas Huth wrote: > On 08.03.2017 11:03, Peter Maydell wrote: > > On 8 March 2017 at 09:26, Thomas Huth <thuth@redhat.com> wrote: > >> But anyway, the more important thing that keeps me concerned is: Someone > >> once told me that we should get rid of old parameters and interfaces > >> (like HMP commands) primarily only when we're changing to a new major > >> version number. As you all know, QEMU has a lot of legacy options, which > >> are likely rather confusing than helpful for the new users nowadays, > >> e.g. things like the "-net channel" option (which is fortunately even > >> hardly documented), but maybe also even the whole vlan/hub concept in > >> the net code, or legacy parameters like "-usbdevice". If we switch to > >> version 3.0, could we agree to remove at least some of them? > > > > I think if we are going to deprecate and remove options we need > > a clear transition plan for doing so, which means at least one > > release where options are "still works, but warn that they > > are going away with pointer to documentation or similar info > > about their replacement syntax", before actually dropping them. > > Yes, that's certainly a good idea. But as Daniel suggested in his mail, > I think we should also have the rule that the option should be marked as > deprecated in multiple releases first - so that the users have a chance > to speak up before something gets really removed (otherwise the option > could be removed right on the first day after the initial release with > the deprecation message, so there is no time for the user to notice this > and complain). Not sure whether we need three releases, as Daniel > suggested, though, but if that's common sense, that's fine for me, too. FYI, I didn't put any thought into my 3 releases / 12 months numbers. I just arbitrarily picked them out of the hat, so don't consider it my endorsement of that particular length of time :-) I think 2 is the minimum number of releases we should deprecate for, beyond that, I'm open minded Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-08 11:24 ` Daniel P. Berrange @ 2017-03-09 12:33 ` Markus Armbruster 0 siblings, 0 replies; 52+ messages in thread From: Markus Armbruster @ 2017-03-09 12:33 UTC (permalink / raw) To: Daniel P. Berrange Cc: Thomas Huth, Peter Maydell, Jason Wang, QEMU Developers, Stefan Hajnoczi, Gerd Hoffmann "Daniel P. Berrange" <berrange@redhat.com> writes: > On Wed, Mar 08, 2017 at 12:22:24PM +0100, Thomas Huth wrote: >> On 08.03.2017 11:03, Peter Maydell wrote: >> > On 8 March 2017 at 09:26, Thomas Huth <thuth@redhat.com> wrote: >> >> But anyway, the more important thing that keeps me concerned is: Someone >> >> once told me that we should get rid of old parameters and interfaces >> >> (like HMP commands) primarily only when we're changing to a new major >> >> version number. As you all know, QEMU has a lot of legacy options, which >> >> are likely rather confusing than helpful for the new users nowadays, >> >> e.g. things like the "-net channel" option (which is fortunately even >> >> hardly documented), but maybe also even the whole vlan/hub concept in >> >> the net code, or legacy parameters like "-usbdevice". If we switch to >> >> version 3.0, could we agree to remove at least some of them? >> > >> > I think if we are going to deprecate and remove options we need >> > a clear transition plan for doing so, which means at least one >> > release where options are "still works, but warn that they >> > are going away with pointer to documentation or similar info >> > about their replacement syntax", before actually dropping them. >> >> Yes, that's certainly a good idea. But as Daniel suggested in his mail, >> I think we should also have the rule that the option should be marked as >> deprecated in multiple releases first - so that the users have a chance >> to speak up before something gets really removed (otherwise the option >> could be removed right on the first day after the initial release with >> the deprecation message, so there is no time for the user to notice this >> and complain). Not sure whether we need three releases, as Daniel >> suggested, though, but if that's common sense, that's fine for me, too. > > FYI, I didn't put any thought into my 3 releases / 12 months numbers. I > just arbitrarily picked them out of the hat, so don't consider it my > endorsement of that particular length of time :-) I think 2 is the minimum > number of releases we should deprecate for, beyond that, I'm open minded I don't think a hard rule for the grace period makes sense. It really depends. A guideline like "normally 12 months" is of course fine. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-08 11:22 ` Thomas Huth 2017-03-08 11:24 ` Daniel P. Berrange @ 2017-03-09 2:21 ` Jason Wang 2017-03-09 8:50 ` Thomas Huth 1 sibling, 1 reply; 52+ messages in thread From: Jason Wang @ 2017-03-09 2:21 UTC (permalink / raw) To: Thomas Huth, Peter Maydell Cc: QEMU Developers, Stefan Hajnoczi, Daniel P. Berrange, Gerd Hoffmann On 2017年03月08日 19:22, Thomas Huth wrote: > On 08.03.2017 11:03, Peter Maydell wrote: >> On 8 March 2017 at 09:26, Thomas Huth <thuth@redhat.com> wrote: >>> But anyway, the more important thing that keeps me concerned is: Someone >>> once told me that we should get rid of old parameters and interfaces >>> (like HMP commands) primarily only when we're changing to a new major >>> version number. As you all know, QEMU has a lot of legacy options, which >>> are likely rather confusing than helpful for the new users nowadays, >>> e.g. things like the "-net channel" option (which is fortunately even >>> hardly documented), but maybe also even the whole vlan/hub concept in >>> the net code, or legacy parameters like "-usbdevice". If we switch to >>> version 3.0, could we agree to remove at least some of them? >> I think if we are going to deprecate and remove options we need >> a clear transition plan for doing so, which means at least one >> release where options are "still works, but warn that they >> are going away with pointer to documentation or similar info >> about their replacement syntax", before actually dropping them. > Yes, that's certainly a good idea. But as Daniel suggested in his mail, > I think we should also have the rule that the option should be marked as > deprecated in multiple releases first - so that the users have a chance > to speak up before something gets really removed (otherwise the option > could be removed right on the first day after the initial release with > the deprecation message, so there is no time for the user to notice this > and complain). Not sure whether we need three releases, as Daniel > suggested, though, but if that's common sense, that's fine for me, too. > > Anyway, I've now started a Wiki page where we could track the removal of > deprecated interfaces: > > http://wiki.qemu-project.org/Features/LegacyRemoval > > Feedback / updates / addition of other legacy interfaces is welcome! > > Thomas > I think we may want to add mipsnet to the list too. It's kernel driver was removed about 3 years ago. Thanks ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-09 2:21 ` Jason Wang @ 2017-03-09 8:50 ` Thomas Huth 2017-03-09 9:53 ` Jason Wang 2017-03-09 10:11 ` [Qemu-devel] external snapshots freezes block device since qemu 2.8 Piotr Rybicki 0 siblings, 2 replies; 52+ messages in thread From: Thomas Huth @ 2017-03-09 8:50 UTC (permalink / raw) To: Jason Wang, Peter Maydell Cc: QEMU Developers, Stefan Hajnoczi, Gerd Hoffmann, Aurelien Jarno, Yongbok Kim On 09.03.2017 03:21, Jason Wang wrote: > > > On 2017年03月08日 19:22, Thomas Huth wrote: >> On 08.03.2017 11:03, Peter Maydell wrote: >>> On 8 March 2017 at 09:26, Thomas Huth <thuth@redhat.com> wrote: >>>> But anyway, the more important thing that keeps me concerned is: >>>> Someone >>>> once told me that we should get rid of old parameters and interfaces >>>> (like HMP commands) primarily only when we're changing to a new major >>>> version number. As you all know, QEMU has a lot of legacy options, >>>> which >>>> are likely rather confusing than helpful for the new users nowadays, >>>> e.g. things like the "-net channel" option (which is fortunately even >>>> hardly documented), but maybe also even the whole vlan/hub concept in >>>> the net code, or legacy parameters like "-usbdevice". If we switch to >>>> version 3.0, could we agree to remove at least some of them? >>> I think if we are going to deprecate and remove options we need >>> a clear transition plan for doing so, which means at least one >>> release where options are "still works, but warn that they >>> are going away with pointer to documentation or similar info >>> about their replacement syntax", before actually dropping them. >> Yes, that's certainly a good idea. But as Daniel suggested in his mail, >> I think we should also have the rule that the option should be marked as >> deprecated in multiple releases first - so that the users have a chance >> to speak up before something gets really removed (otherwise the option >> could be removed right on the first day after the initial release with >> the deprecation message, so there is no time for the user to notice this >> and complain). Not sure whether we need three releases, as Daniel >> suggested, though, but if that's common sense, that's fine for me, too. >> >> Anyway, I've now started a Wiki page where we could track the removal of >> deprecated interfaces: >> >> http://wiki.qemu-project.org/Features/LegacyRemoval >> >> Feedback / updates / addition of other legacy interfaces is welcome! >> >> Thomas >> > > I think we may want to add mipsnet to the list too. It's kernel driver > was removed about 3 years ago. But that's still the default network of the "mipssim" machine ... is that machine considered as deprecated, too? Thomas ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-09 8:50 ` Thomas Huth @ 2017-03-09 9:53 ` Jason Wang 2017-03-09 10:20 ` Yongbok Kim 2017-03-09 10:11 ` [Qemu-devel] external snapshots freezes block device since qemu 2.8 Piotr Rybicki 1 sibling, 1 reply; 52+ messages in thread From: Jason Wang @ 2017-03-09 9:53 UTC (permalink / raw) To: Thomas Huth, Peter Maydell Cc: QEMU Developers, Stefan Hajnoczi, Gerd Hoffmann, Aurelien Jarno, Yongbok Kim On 2017年03月09日 16:50, Thomas Huth wrote: > On 09.03.2017 03:21, Jason Wang wrote: >> >> On 2017年03月08日 19:22, Thomas Huth wrote: >>> On 08.03.2017 11:03, Peter Maydell wrote: >>>> On 8 March 2017 at 09:26, Thomas Huth <thuth@redhat.com> wrote: >>>>> But anyway, the more important thing that keeps me concerned is: >>>>> Someone >>>>> once told me that we should get rid of old parameters and interfaces >>>>> (like HMP commands) primarily only when we're changing to a new major >>>>> version number. As you all know, QEMU has a lot of legacy options, >>>>> which >>>>> are likely rather confusing than helpful for the new users nowadays, >>>>> e.g. things like the "-net channel" option (which is fortunately even >>>>> hardly documented), but maybe also even the whole vlan/hub concept in >>>>> the net code, or legacy parameters like "-usbdevice". If we switch to >>>>> version 3.0, could we agree to remove at least some of them? >>>> I think if we are going to deprecate and remove options we need >>>> a clear transition plan for doing so, which means at least one >>>> release where options are "still works, but warn that they >>>> are going away with pointer to documentation or similar info >>>> about their replacement syntax", before actually dropping them. >>> Yes, that's certainly a good idea. But as Daniel suggested in his mail, >>> I think we should also have the rule that the option should be marked as >>> deprecated in multiple releases first - so that the users have a chance >>> to speak up before something gets really removed (otherwise the option >>> could be removed right on the first day after the initial release with >>> the deprecation message, so there is no time for the user to notice this >>> and complain). Not sure whether we need three releases, as Daniel >>> suggested, though, but if that's common sense, that's fine for me, too. >>> >>> Anyway, I've now started a Wiki page where we could track the removal of >>> deprecated interfaces: >>> >>> http://wiki.qemu-project.org/Features/LegacyRemoval >>> >>> Feedback / updates / addition of other legacy interfaces is welcome! >>> >>> Thomas >>> >> I think we may want to add mipsnet to the list too. It's kernel driver >> was removed about 3 years ago. > But that's still the default network of the "mipssim" machine ... > is that machine considered as deprecated, too? > > Thomas I think so, according to [1], it was deprecated. [1] https://www.linux-mips.org/wiki/MIPSsim Thanks ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-09 9:53 ` Jason Wang @ 2017-03-09 10:20 ` Yongbok Kim 2017-03-10 11:07 ` Jason Wang 0 siblings, 1 reply; 52+ messages in thread From: Yongbok Kim @ 2017-03-09 10:20 UTC (permalink / raw) To: Jason Wang, Thomas Huth, Peter Maydell Cc: QEMU Developers, Stefan Hajnoczi, Gerd Hoffmann, Aurelien Jarno On 09/03/2017 09:53, Jason Wang wrote: > > > On 2017年03月09日 16:50, Thomas Huth wrote: >> On 09.03.2017 03:21, Jason Wang wrote: >>> >>> On 2017年03月08日 19:22, Thomas Huth wrote: >>>> On 08.03.2017 11:03, Peter Maydell wrote: >>>>> On 8 March 2017 at 09:26, Thomas Huth <thuth@redhat.com> wrote: >>>>>> But anyway, the more important thing that keeps me concerned is: >>>>>> Someone >>>>>> once told me that we should get rid of old parameters and interfaces >>>>>> (like HMP commands) primarily only when we're changing to a new major >>>>>> version number. As you all know, QEMU has a lot of legacy options, >>>>>> which >>>>>> are likely rather confusing than helpful for the new users nowadays, >>>>>> e.g. things like the "-net channel" option (which is fortunately even >>>>>> hardly documented), but maybe also even the whole vlan/hub concept in >>>>>> the net code, or legacy parameters like "-usbdevice". If we switch to >>>>>> version 3.0, could we agree to remove at least some of them? >>>>> I think if we are going to deprecate and remove options we need >>>>> a clear transition plan for doing so, which means at least one >>>>> release where options are "still works, but warn that they >>>>> are going away with pointer to documentation or similar info >>>>> about their replacement syntax", before actually dropping them. >>>> Yes, that's certainly a good idea. But as Daniel suggested in his mail, >>>> I think we should also have the rule that the option should be marked as >>>> deprecated in multiple releases first - so that the users have a chance >>>> to speak up before something gets really removed (otherwise the option >>>> could be removed right on the first day after the initial release with >>>> the deprecation message, so there is no time for the user to notice this >>>> and complain). Not sure whether we need three releases, as Daniel >>>> suggested, though, but if that's common sense, that's fine for me, too. >>>> >>>> Anyway, I've now started a Wiki page where we could track the removal of >>>> deprecated interfaces: >>>> >>>> http://wiki.qemu-project.org/Features/LegacyRemoval >>>> >>>> Feedback / updates / addition of other legacy interfaces is welcome! >>>> >>>> Thomas >>>> >>> I think we may want to add mipsnet to the list too. It's kernel driver >>> was removed about 3 years ago. >> But that's still the default network of the "mipssim" machine ... >> is that machine considered as deprecated, too? >> >> Thomas > > I think so, according to [1], it was deprecated. > > [1] https://www.linux-mips.org/wiki/MIPSsim > > Thanks Indeed but we still use the platform to verify architectural compatibilities even for newer MIPS architectures. Regards, Yongbok ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-09 10:20 ` Yongbok Kim @ 2017-03-10 11:07 ` Jason Wang 2017-03-10 11:22 ` Peter Maydell 0 siblings, 1 reply; 52+ messages in thread From: Jason Wang @ 2017-03-10 11:07 UTC (permalink / raw) To: Yongbok Kim, Thomas Huth, Peter Maydell Cc: Aurelien Jarno, QEMU Developers, Stefan Hajnoczi, Gerd Hoffmann On 2017年03月09日 18:20, Yongbok Kim wrote: > > On 09/03/2017 09:53, Jason Wang wrote: >> >> On 2017年03月09日 16:50, Thomas Huth wrote: >>> On 09.03.2017 03:21, Jason Wang wrote: >>>> On 2017年03月08日 19:22, Thomas Huth wrote: >>>>> On 08.03.2017 11:03, Peter Maydell wrote: >>>>>> On 8 March 2017 at 09:26, Thomas Huth <thuth@redhat.com> wrote: >>>>>>> But anyway, the more important thing that keeps me concerned is: >>>>>>> Someone >>>>>>> once told me that we should get rid of old parameters and interfaces >>>>>>> (like HMP commands) primarily only when we're changing to a new major >>>>>>> version number. As you all know, QEMU has a lot of legacy options, >>>>>>> which >>>>>>> are likely rather confusing than helpful for the new users nowadays, >>>>>>> e.g. things like the "-net channel" option (which is fortunately even >>>>>>> hardly documented), but maybe also even the whole vlan/hub concept in >>>>>>> the net code, or legacy parameters like "-usbdevice". If we switch to >>>>>>> version 3.0, could we agree to remove at least some of them? >>>>>> I think if we are going to deprecate and remove options we need >>>>>> a clear transition plan for doing so, which means at least one >>>>>> release where options are "still works, but warn that they >>>>>> are going away with pointer to documentation or similar info >>>>>> about their replacement syntax", before actually dropping them. >>>>> Yes, that's certainly a good idea. But as Daniel suggested in his mail, >>>>> I think we should also have the rule that the option should be marked as >>>>> deprecated in multiple releases first - so that the users have a chance >>>>> to speak up before something gets really removed (otherwise the option >>>>> could be removed right on the first day after the initial release with >>>>> the deprecation message, so there is no time for the user to notice this >>>>> and complain). Not sure whether we need three releases, as Daniel >>>>> suggested, though, but if that's common sense, that's fine for me, too. >>>>> >>>>> Anyway, I've now started a Wiki page where we could track the removal of >>>>> deprecated interfaces: >>>>> >>>>> http://wiki.qemu-project.org/Features/LegacyRemoval >>>>> >>>>> Feedback / updates / addition of other legacy interfaces is welcome! >>>>> >>>>> Thomas >>>>> >>>> I think we may want to add mipsnet to the list too. It's kernel driver >>>> was removed about 3 years ago. >>> But that's still the default network of the "mipssim" machine ... >>> is that machine considered as deprecated, too? >>> >>> Thomas >> I think so, according to [1], it was deprecated. >> >> [1] https://www.linux-mips.org/wiki/MIPSsim >> >> Thanks > Indeed but we still use the platform to verify architectural > compatibilities even for newer MIPS architectures. > > Regards, > Yongbok > I see, but I believe it may need some modifications in the code to support newer architectures? If yes, plan to send them upstream? Since it has been deprecated, if no new codes it makes sense to deprecate it in qemu too. You can still use exist qemu versions to do the verification. Thanks ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-10 11:07 ` Jason Wang @ 2017-03-10 11:22 ` Peter Maydell 2017-03-10 11:53 ` Thomas Huth 0 siblings, 1 reply; 52+ messages in thread From: Peter Maydell @ 2017-03-10 11:22 UTC (permalink / raw) To: Jason Wang Cc: Yongbok Kim, Thomas Huth, Aurelien Jarno, QEMU Developers, Stefan Hajnoczi, Gerd Hoffmann On 10 March 2017 at 12:07, Jason Wang <jasowang@redhat.com> wrote: > On 2017年03月09日 18:20, Yongbok Kim wrote: >> Indeed but we still use the platform to verify architectural >> compatibilities even for newer MIPS architectures. > I see, but I believe it may need some modifications in the code to support > newer architectures? If yes, plan to send them upstream? Since it has been > deprecated, if no new codes it makes sense to deprecate it in qemu too. You > can still use exist qemu versions to do the verification. Taking a step back, the reason for deprecating and deleting code is to avoid having unmaintained and unused code in QEMU. If Yongbok is maintaining the mipssim board and devices and is willing to keep them up to spec with current QOM and other best practices, and there are test images to check they still work, I think that's fine. thanks -- PMM ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-10 11:22 ` Peter Maydell @ 2017-03-10 11:53 ` Thomas Huth 2017-03-10 11:58 ` Yongbok Kim 0 siblings, 1 reply; 52+ messages in thread From: Thomas Huth @ 2017-03-10 11:53 UTC (permalink / raw) To: Peter Maydell, Jason Wang Cc: Yongbok Kim, Aurelien Jarno, QEMU Developers, Stefan Hajnoczi, Gerd Hoffmann On 10.03.2017 12:22, Peter Maydell wrote: > On 10 March 2017 at 12:07, Jason Wang <jasowang@redhat.com> wrote: >> On 2017年03月09日 18:20, Yongbok Kim wrote: >>> Indeed but we still use the platform to verify architectural >>> compatibilities even for newer MIPS architectures. > >> I see, but I believe it may need some modifications in the code to support >> newer architectures? If yes, plan to send them upstream? Since it has been >> deprecated, if no new codes it makes sense to deprecate it in qemu too. You >> can still use exist qemu versions to do the verification. > > Taking a step back, the reason for deprecating and deleting > code is to avoid having unmaintained and unused code in QEMU. > If Yongbok is maintaining the mipssim board and devices > and is willing to keep them up to spec with current QOM > and other best practices, and there are test images to > check they still work, I think that's fine. But the Mipssim machine is currently marked as "Orphan" in our MAINTAINERS file ... Yongbok, if you're still using it, would you maybe be interested in doing at least "Odd fixes" here? BTW, I think "F: hw/net/mipsnet.c" should be added to the "Mipssim" section, too. Thomas ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-10 11:53 ` Thomas Huth @ 2017-03-10 11:58 ` Yongbok Kim 2018-04-24 19:45 ` Philippe Mathieu-Daudé 0 siblings, 1 reply; 52+ messages in thread From: Yongbok Kim @ 2017-03-10 11:58 UTC (permalink / raw) To: Thomas Huth, Peter Maydell, Jason Wang Cc: Aurelien Jarno, QEMU Developers, Stefan Hajnoczi, Gerd Hoffmann On 10/03/2017 11:53, Thomas Huth wrote: > On 10.03.2017 12:22, Peter Maydell wrote: >> On 10 March 2017 at 12:07, Jason Wang <jasowang@redhat.com> wrote: >>> On 2017年03月09日 18:20, Yongbok Kim wrote: >>>> Indeed but we still use the platform to verify architectural >>>> compatibilities even for newer MIPS architectures. >> >>> I see, but I believe it may need some modifications in the code to support >>> newer architectures? If yes, plan to send them upstream? Since it has been >>> deprecated, if no new codes it makes sense to deprecate it in qemu too. You >>> can still use exist qemu versions to do the verification. >> >> Taking a step back, the reason for deprecating and deleting >> code is to avoid having unmaintained and unused code in QEMU. >> If Yongbok is maintaining the mipssim board and devices >> and is willing to keep them up to spec with current QOM >> and other best practices, and there are test images to >> check they still work, I think that's fine. > > But the Mipssim machine is currently marked as "Orphan" in our > MAINTAINERS file ... Yongbok, if you're still using it, would you maybe > be interested in doing at least "Odd fixes" here? > BTW, I think "F: hw/net/mipsnet.c" should be added to the "Mipssim" > section, too. > > Thomas > Yes I am willing to maintain the machine. I will post a patch to the MAINTAINERS file for the machine and other MIPS machines. Regards, Yongbok ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-10 11:58 ` Yongbok Kim @ 2018-04-24 19:45 ` Philippe Mathieu-Daudé 0 siblings, 0 replies; 52+ messages in thread From: Philippe Mathieu-Daudé @ 2018-04-24 19:45 UTC (permalink / raw) To: Yongbok Kim, Jason Wang Cc: Thomas Huth, Peter Maydell, Stefan Hajnoczi, QEMU Developers, Aurelien Jarno, Gerd Hoffmann, Paul Burton [-- Attachment #1: Type: text/plain, Size: 4263 bytes --] Hi Yongbok Kim, On 03/10/2017 08:58 AM, Yongbok Kim wrote: > On 10/03/2017 11:53, Thomas Huth wrote: >> On 10.03.2017 12:22, Peter Maydell wrote: >>> On 10 March 2017 at 12:07, Jason Wang <jasowang@redhat.com> wrote: >>>> On 2017年03月09日 18:20, Yongbok Kim wrote: >>>>> Indeed but we still use the platform to verify architectural >>>>> compatibilities even for newer MIPS architectures. >>> >>>> I see, but I believe it may need some modifications in the code to support >>>> newer architectures? If yes, plan to send them upstream? Since it has been >>>> deprecated, if no new codes it makes sense to deprecate it in qemu too. You >>>> can still use exist qemu versions to do the verification. >>> >>> Taking a step back, the reason for deprecating and deleting >>> code is to avoid having unmaintained and unused code in QEMU. >>> If Yongbok is maintaining the mipssim board and devices >>> and is willing to keep them up to spec with current QOM >>> and other best practices, and there are test images to >>> check they still work, I think that's fine. >> >> But the Mipssim machine is currently marked as "Orphan" in our >> MAINTAINERS file ... Yongbok, if you're still using it, would you maybe >> be interested in doing at least "Odd fixes" here? >> BTW, I think "F: hw/net/mipsnet.c" should be added to the "Mipssim" >> section, too. >> > Yes I am willing to maintain the machine. I will post a patch to the > MAINTAINERS file for the machine and other MIPS machines. I'm trying to setup Avocado [1] VM tests on Unsupported machines from the MAINTAINERS file, which include the "Odd Fixes" status entry. Do you have images I can use for the MIPSsim board? It has been very hard to reproduce some. - Linux dropped MIPSsim support in v3.18 - I checkouted longterm v3.2.101 kernel, then hit: $ make mipssim_defconfig $ make vmlinux include/linux/compiler-gcc.h:105:30: fatal error: linux/compiler-gcc6.h: No such file or directory I backported include/linux/compiler-gcc.h from long term stable v3.16.56, but then: AS arch/mips/kernel/r4k_fpu.o arch/mips/kernel/r4k_fpu.S: Assembler messages: arch/mips/kernel/r4k_fpu.S:59: Error: opcode not supported on this processor: mips3 (mips3) `sdc1 $f0,272+0($4)' which is a binutils problem. After reading https://lkml.org/lkml/2015/7/15/26, I backported commit 842dfc11ea9a2 but then hitting other problems I gave out and started a different approach. - I checkouted the more recent long term stable v3.16.56 kernel and reverted commits b30fdd6f7395b and 270690e00cdb0. I then could rebuild a kernel for this board. You can find the signed tag I'll use for the Avocado tests here: https://github.com/philmd/linux/releases/tag/linux-mipssim-3.16.56 So far this kernel doesn't boot far, but at least I could test the console is working: $ ./mipsel-softmmu/qemu-system-mipsel -M mipssim -kernel /build/linux/mipssim/vmlinux -nographic Linux version 3.16.56-00002-g41a1a4f084a9 (phil@ugli) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 Tue Apr 24 15:20:39 -03 2018 Setting default memory size 0x02000000 bootconsole [early0] enabled CPU0 revision is: 00019300 (MIPS 24Kc) FPU revision is: 00739300 ... CPU frequency 12.00 MHz random: nonblocking pool is initialized CPU 0 Unable to handle kernel paging request at virtual address 00000080, epc == 80132d9c, ra == 801330a0 Oops[#1]: CPU: 0 PID: 0 Comm: swapper Not tainted 3.16.56-00002-g41a1a4f084a9 #1 Call Trace: [<80132d9c>] __queue_work+0x3c/0x2b8 [<801330a0>] queue_work_on+0x88/0xb4 [<8029df08>] credit_entropy_bits+0x21c/0x300 [<8015239c>] handle_irq_event_percpu+0xc8/0x1a0 [<80155ac8>] handle_percpu_irq+0x54/0x84 [<80151ac8>] generic_handle_irq+0x34/0x4c [<801056c0>] do_IRQ+0x18/0x28 [<80103628>] ret_from_irq+0x0/0x4 [<80120d80>] __do_softirq+0xc0/0x2dc [<80121290>] irq_exit+0x90/0x98 [<80103628>] ret_from_irq+0x0/0x4 [<8040ca48>] start_kernel+0x2e4/0x3e4 My setup is a Debian/Sid with mipsel-linux-gnu-gcc (GCC 6.3), I also used the following shell environment: $ export CROSS_COMPILE=mips-linux-gnu- ARCH=mips Regards, Phil. [1] http://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg03355.html [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* [Qemu-devel] external snapshots freezes block device since qemu 2.8 2017-03-09 8:50 ` Thomas Huth 2017-03-09 9:53 ` Jason Wang @ 2017-03-09 10:11 ` Piotr Rybicki 2017-03-09 12:26 ` Dr. David Alan Gilbert 2017-03-10 14:49 ` Kashyap Chamarthy 1 sibling, 2 replies; 52+ messages in thread From: Piotr Rybicki @ 2017-03-09 10:11 UTC (permalink / raw) To: qemu-devel Hello there. I discovered, that since qemu 2.8 , external snapshots (very similar to: http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit), freezes block device after: # virsh blockcommit (...) There is no error message after completion of the command above. I'm using gluster + ZFS fuse mount as a storage for a VM on gentoo. libvirt debug showed nothing helpful. With qemu <2.8 -: snapshots are working as expected. Is this a known issue? Is it qemu or libvirt ? If it helps, how can i diagnose this further? Thank You & Best regards Piotr Rybicki ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] external snapshots freezes block device since qemu 2.8 2017-03-09 10:11 ` [Qemu-devel] external snapshots freezes block device since qemu 2.8 Piotr Rybicki @ 2017-03-09 12:26 ` Dr. David Alan Gilbert 2017-04-05 22:18 ` John Snow 2017-03-10 14:49 ` Kashyap Chamarthy 1 sibling, 1 reply; 52+ messages in thread From: Dr. David Alan Gilbert @ 2017-03-09 12:26 UTC (permalink / raw) To: Piotr Rybicki; +Cc: qemu-devel, jsnow * Piotr Rybicki (piotr.rybicki@innervision.pl) wrote: > Hello there. > > I discovered, that since qemu 2.8 , external snapshots (very similar to: > http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit), > freezes block device after: > > # virsh blockcommit (...) > > There is no error message after completion of the command above. > I'm using gluster + ZFS fuse mount as a storage for a VM on gentoo. > libvirt debug showed nothing helpful. > With qemu <2.8 -: snapshots are working as expected. > > Is this a known issue? > Is it qemu or libvirt ? > > If it helps, how can i diagnose this further? I don't know of it, cc'd in jsnow. Have you tried bisecting? Dave > Thank You & Best regards > Piotr Rybicki > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] external snapshots freezes block device since qemu 2.8 2017-03-09 12:26 ` Dr. David Alan Gilbert @ 2017-04-05 22:18 ` John Snow 2017-04-06 9:25 ` Dr. David Alan Gilbert 0 siblings, 1 reply; 52+ messages in thread From: John Snow @ 2017-04-05 22:18 UTC (permalink / raw) To: Dr. David Alan Gilbert, Piotr Rybicki; +Cc: qemu-devel, Kashyap Chamarthy On 03/09/2017 07:26 AM, Dr. David Alan Gilbert wrote: > * Piotr Rybicki (piotr.rybicki@innervision.pl) wrote: >> Hello there. >> >> I discovered, that since qemu 2.8 , external snapshots (very similar to: >> http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit), >> freezes block device after: >> >> # virsh blockcommit (...) >> >> There is no error message after completion of the command above. >> I'm using gluster + ZFS fuse mount as a storage for a VM on gentoo. >> libvirt debug showed nothing helpful. >> With qemu <2.8 -: snapshots are working as expected. >> >> Is this a known issue? >> Is it qemu or libvirt ? >> >> If it helps, how can i diagnose this further? > > I don't know of it, cc'd in jsnow. > Have you tried bisecting? > > Dave > >> Thank You & Best regards >> Piotr Rybicki >> > -- > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > I'm cleaning out my inbox and I seem to have missed this thread. Was there any resolution? ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] external snapshots freezes block device since qemu 2.8 2017-04-05 22:18 ` John Snow @ 2017-04-06 9:25 ` Dr. David Alan Gilbert 0 siblings, 0 replies; 52+ messages in thread From: Dr. David Alan Gilbert @ 2017-04-06 9:25 UTC (permalink / raw) To: John Snow; +Cc: Piotr Rybicki, qemu-devel * John Snow (jsnow@redhat.com) wrote: > > > On 03/09/2017 07:26 AM, Dr. David Alan Gilbert wrote: > > * Piotr Rybicki (piotr.rybicki@innervision.pl) wrote: > >> Hello there. > >> > >> I discovered, that since qemu 2.8 , external snapshots (very similar to: > >> http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit), > >> freezes block device after: > >> > >> # virsh blockcommit (...) > >> > >> There is no error message after completion of the command above. > >> I'm using gluster + ZFS fuse mount as a storage for a VM on gentoo. > >> libvirt debug showed nothing helpful. > >> With qemu <2.8 -: snapshots are working as expected. > >> > >> Is this a known issue? > >> Is it qemu or libvirt ? > >> > >> If it helps, how can i diagnose this further? > > > > I don't know of it, cc'd in jsnow. > > Have you tried bisecting? > > > > Dave > > > >> Thank You & Best regards > >> Piotr Rybicki > >> > > -- > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > > > > I'm cleaning out my inbox and I seem to have missed this thread. Was > there any resolution? Not that I remember. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] external snapshots freezes block device since qemu 2.8 2017-03-09 10:11 ` [Qemu-devel] external snapshots freezes block device since qemu 2.8 Piotr Rybicki 2017-03-09 12:26 ` Dr. David Alan Gilbert @ 2017-03-10 14:49 ` Kashyap Chamarthy 2017-03-10 15:44 ` Piotr Rybicki 1 sibling, 1 reply; 52+ messages in thread From: Kashyap Chamarthy @ 2017-03-10 14:49 UTC (permalink / raw) To: Piotr Rybicki; +Cc: qemu-devel On Thu, Mar 09, 2017 at 11:11:09AM +0100, Piotr Rybicki wrote: > Hello there. > > I discovered, that since qemu 2.8 , external snapshots (very similar to: > http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit), When I wrote this Wiki page, I tested it only with regular QCOW2 files on EXT4 file system. > freezes block device after: > > # virsh blockcommit (...) > > There is no error message after completion of the command above. > I'm using gluster + ZFS fuse mount as a storage for a VM on gentoo. > libvirt debug showed nothing helpful. > With qemu <2.8 -: snapshots are working as expected. > > Is this a known issue? > Is it qemu or libvirt ? > > If it helps, how can i diagnose this further?a To see what libvirt is sending to QEMU, you can enable the debug log filters, which can give some clue: - In /etc/libvirt/libvirtd.conf, set these config attributes log_filters="1:libvirt 1:qemu 1:conf 1:security 3:event 3:json 3:file 3:object 1:util" log_outputs="1:file:/var/log/libvirt/libvirtd.log" - Restart libvirtd: $ systemctl restart libvirtd - Perform your `blockcommit` test. PS: A gentle reminder -- when reporting upstream, you'll likely better help if you at least test with the latest releases (libvirt-3.1.0, and QEMU 2.8), if not from Git. [...] -- /kashyap ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] external snapshots freezes block device since qemu 2.8 2017-03-10 14:49 ` Kashyap Chamarthy @ 2017-03-10 15:44 ` Piotr Rybicki 0 siblings, 0 replies; 52+ messages in thread From: Piotr Rybicki @ 2017-03-10 15:44 UTC (permalink / raw) To: Kashyap Chamarthy; +Cc: qemu-devel W dniu 2017-03-10 o 15:49, Kashyap Chamarthy pisze: > On Thu, Mar 09, 2017 at 11:11:09AM +0100, Piotr Rybicki wrote: >> Hello there. >> >> I discovered, that since qemu 2.8 , external snapshots (very similar to: >> http://wiki.libvirt.org/page/Live-disk-backup-with-active-blockcommit), > When I wrote this Wiki page, I tested it only with regular QCOW2 files > on EXT4 file system. It used to work very well with raw files on gluster via fuse. I've tested with local storage - it acts the same. > >> freezes block device after: >> >> # virsh blockcommit (...) >> >> There is no error message after completion of the command above. >> I'm using gluster + ZFS fuse mount as a storage for a VM on gentoo. >> libvirt debug showed nothing helpful. >> With qemu <2.8 -: snapshots are working as expected. >> >> Is this a known issue? >> Is it qemu or libvirt ? >> >> If it helps, how can i diagnose this further?a > To see what libvirt is sending to QEMU, you can enable the debug log > filters, which can give some clue: > > - In /etc/libvirt/libvirtd.conf, set these config attributes > > log_filters="1:libvirt 1:qemu 1:conf 1:security 3:event 3:json 3:file 3:object 1:util" > log_outputs="1:file:/var/log/libvirt/libvirtd.log" > > - Restart libvirtd: > > $ systemctl restart libvirtd > > - Perform your `blockcommit` test. > > PS: A gentle reminder -- when reporting upstream, you'll likely better > help if you at least test with the latest releases (libvirt-3.1.0, and > QEMU 2.8), if not from Git. Thanks for pinting this out. I've tried several libvirt versions, including latest 3.1.0 Qemu 2.7 / 2.7.1 works fine, only issue is at qemu 2.8 (git version is not usable right now - it crashes before i can start blockcommit) Command complete successfully, but qemu is locked when accessing it's disks. For example - one cannot ssh into vm. libvirtd.log: 2017-03-10 15:04:26.069+0000: 16381: debug : virIdentitySetAttr:248 : ident=0x7f4e08001660 attribute=7 value=C=PL,O=InnerVision Sp. z o.o.,L=Warszawa,ST=Mazowieckie,CN=adm 2017-03-10 15:04:26.069+0000: 16381: debug : virThreadJobSet:96 : Thread 16381 (virNetServerHandleJob) is now running job remoteDispatchAuthList 2017-03-10 15:04:26.069+0000: 16381: debug : virThreadJobClear:121 : Thread 16381 (virNetServerHandleJob) finished job remoteDispatchAuthList with ret=0 2017-03-10 15:04:26.070+0000: 16379: debug : virThreadJobSet:96 : Thread 16379 (virNetServerHandleJob) is now running job remoteDispatchConnectSupportsFeature 2017-03-10 15:04:26.070+0000: 16379: debug : virThreadJobClear:121 : Thread 16379 (virNetServerHandleJob) finished job remoteDispatchConnectSupportsFeature with ret=0 2017-03-10 15:04:26.071+0000: 16378: debug : virThreadJobSet:96 : Thread 16378 (virNetServerHandleJob) is now running job remoteDispatchConnectOpen 2017-03-10 15:04:26.071+0000: 16378: debug : virConnectOpen:1169 : name=qemu:///system 2017-03-10 15:04:26.071+0000: 16378: debug : virConfLoadConfig:1604 : Loading config file '/etc/libvirt/libvirt.conf' 2017-03-10 15:04:26.071+0000: 16378: debug : virConfReadFile:778 : filename=/etc/libvirt/libvirt.conf 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfAddEntry:241 : Add entry (null) (nil) 2017-03-10 15:04:26.071+0000: 16378: debug : virConfGetValueStringList:981 : Get value string list (nil) 0 2017-03-10 15:04:26.071+0000: 16378: debug : virConnectOpenInternal:1033 : Split "qemu:///system" to URI components: scheme qemu server <null> user <null> port -1 path /system 2017-03-10 15:04:26.071+0000: 16378: debug : virConnectOpenInternal:1083 : trying driver 0 (Test) ... 2017-03-10 15:04:26.071+0000: 16378: debug : virConnectOpenInternal:1098 : driver 0 Test returned DECLINED 2017-03-10 15:04:26.071+0000: 16378: debug : virConnectOpenInternal:1083 : trying driver 1 (VMWARE) ... 2017-03-10 15:04:26.071+0000: 16378: debug : virConnectOpenInternal:1098 : driver 1 VMWARE returned DECLINED 2017-03-10 15:04:26.071+0000: 16378: debug : virConnectOpenInternal:1083 : trying driver 2 (ESX) ... 2017-03-10 15:04:26.071+0000: 16378: debug : virConnectOpenInternal:1098 : driver 2 ESX returned DECLINED 2017-03-10 15:04:26.071+0000: 16378: debug : virConnectOpenInternal:1083 : trying driver 3 (remote) ... 2017-03-10 15:04:26.071+0000: 16378: debug : virConnectOpenInternal:1098 : driver 3 remote returned DECLINED 2017-03-10 15:04:26.071+0000: 16378: debug : virConnectOpenInternal:1083 : trying driver 4 (QEMU) ... 2017-03-10 15:04:26.071+0000: 16378: debug : virConnectOpenInternal:1098 : driver 4 QEMU returned SUCCESS 2017-03-10 15:04:26.071+0000: 16378: debug : virThreadJobClear:121 : Thread 16378 (virNetServerHandleJob) finished job remoteDispatchConnectOpen with ret=0 2017-03-10 15:04:26.072+0000: 16380: debug : virThreadJobSet:96 : Thread 16380 (virNetServerHandleJob) is now running job remoteDispatchConnectSupportsFeature 2017-03-10 15:04:26.072+0000: 16380: debug : virThreadJobClear:121 : Thread 16380 (virNetServerHandleJob) finished job remoteDispatchConnectSupportsFeature with ret=0 2017-03-10 15:04:26.072+0000: 16382: debug : virThreadJobSet:96 : Thread 16382 (virNetServerHandleJob) is now running job remoteDispatchConnectSupportsFeature 2017-03-10 15:04:26.072+0000: 16382: debug : virThreadJobClear:121 : Thread 16382 (virNetServerHandleJob) finished job remoteDispatchConnectSupportsFeature with ret=0 2017-03-10 15:04:26.072+0000: 16381: debug : virThreadJobSet:96 : Thread 16381 (virNetServerHandleJob) is now running job remoteDispatchConnectRegisterCloseCallback 2017-03-10 15:04:26.072+0000: 16381: debug : virConnectRegisterCloseCallback:1218 : conn=0x7f4e20002fe0 2017-03-10 15:04:26.072+0000: 16381: debug : virThreadJobClear:121 : Thread 16381 (virNetServerHandleJob) finished job remoteDispatchConnectRegisterCloseCallback with ret=0 2017-03-10 15:04:26.073+0000: 16379: debug : virThreadJobSet:96 : Thread 16379 (virNetServerHandleJob) is now running job remoteDispatchDomainLookupByName 2017-03-10 15:04:26.073+0000: 16379: debug : virDomainLookupByName:416 : conn=0x7f4e20002fe0, name=ESBEK-tor1 2017-03-10 15:04:26.073+0000: 16379: debug : virThreadJobClear:121 : Thread 16379 (virNetServerHandleJob) finished job remoteDispatchDomainLookupByName with ret=0 2017-03-10 15:04:26.074+0000: 16378: debug : virThreadJobSet:96 : Thread 16378 (virNetServerHandleJob) is now running job remoteDispatchConnectDomainEventCallbackRegisterAny 2017-03-10 15:04:26.074+0000: 16378: debug : virConnectDomainEventRegisterAny:9081 : dom=0x7f4e20002cd0, (VM: name=ESBEK-tor1, uuid=f40593c0-d196-bb4b-0886-f1b32f86c9a1), conn=0x7f4e20002fe0, eventID=8, cb=0x55ffc489d678, opaque=0x7f4e200035f0, freecb=0x55ffc489acf0 2017-03-10 15:04:26.074+0000: 16378: debug : virObjectEventCallbackListAddID:415 : conn=0x7f4e20002fe0 cblist=0x7f4dd81a1060 key=0x7f4e287cbb00 filter=(nil) filter_opaque=(nil) klass=0x7f4ddc012ce0 eventID=8 callback=0x55ffc489d678 opaque=0x7f4e200035f0 legacy=0 callbackID=0x7f4e287cbb94 serverFilter=0 2017-03-10 15:04:26.074+0000: 16378: debug : virThreadJobClear:121 : Thread 16378 (virNetServerHandleJob) finished job remoteDispatchConnectDomainEventCallbackRegisterAny with ret=0 2017-03-10 15:04:26.074+0000: 16380: debug : virThreadJobSet:96 : Thread 16380 (virNetServerHandleJob) is now running job remoteDispatchConnectDomainEventCallbackRegisterAny 2017-03-10 15:04:26.074+0000: 16380: debug : virConnectDomainEventRegisterAny:9081 : dom=0x7f4e10003210, (VM: name=ESBEK-tor1, uuid=f40593c0-d196-bb4b-0886-f1b32f86c9a1), conn=0x7f4e20002fe0, eventID=16, cb=0x55ffc489c8e0, opaque=0x7f4e10000cf0, freecb=0x55ffc489acf0 2017-03-10 15:04:26.074+0000: 16380: debug : virObjectEventCallbackListAddID:415 : conn=0x7f4e20002fe0 cblist=0x7f4dd81a1060 key=0x7f4e277c9b00 filter=(nil) filter_opaque=(nil) klass=0x7f4ddc012ce0 eventID=16 callback=0x55ffc489c8e0 opaque=0x7f4e10000cf0 legacy=0 callbackID=0x7f4e277c9b94 serverFilter=0 2017-03-10 15:04:26.075+0000: 16380: debug : virThreadJobClear:121 : Thread 16380 (virNetServerHandleJob) finished job remoteDispatchConnectDomainEventCallbackRegisterAny with ret=0 2017-03-10 15:04:26.075+0000: 16382: debug : virThreadJobSet:96 : Thread 16382 (virNetServerHandleJob) is now running job remoteDispatchDomainBlockCommit 2017-03-10 15:04:26.075+0000: 16382: debug : virDomainBlockCommit:10200 : dom=0x7f4e00003310, (VM: name=ESBEK-tor1, uuid=f40593c0-d196-bb4b-0886-f1b32f86c9a1), disk=vda, base=<null>, top=<null>, bandwidth=0, flags=4 2017-03-10 15:04:26.075+0000: 16382: debug : qemuDomainObjBeginJobInternal:3412 : Starting job: modify (vm=0x7f4dd81fd3c0 name=ESBEK-tor1, current job=none async=none) 2017-03-10 15:04:26.075+0000: 16382: debug : qemuDomainObjBeginJobInternal:3453 : Started job: modify (async=none vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.075+0000: 16382: debug : qemuSetupImagePathCgroup:72 : Allow path /data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img, perms: rw 2017-03-10 15:04:26.090+0000: 16382: debug : qemuDomainObjEnterMonitorInternal:3676 : Entering monitor (mon=0x7f4ddc000ec0 vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.090+0000: 16382: debug : qemuMonitorDiskNameLookup:3286 : mon:0x7f4ddc000ec0 vm:0x7f4dd81fd3c0 json:1 fd:20 2017-03-10 15:04:26.090+0000: 16382: debug : qemuMonitorJSONCommandWithFd:296 : Send command '{"execute":"query-block","id":"libvirt-27"}' for write with FD -1 2017-03-10 15:04:26.090+0000: 16382: info : qemuMonitorSend:1009 : QEMU_MONITOR_SEND_MSG: mon=0x7f4ddc000ec0 msg={"execute":"query-block","id":"libvirt-27"} fd=-1 2017-03-10 15:04:26.090+0000: 16377: info : qemuMonitorIOWrite:534 : QEMU_MONITOR_IO_WRITE: mon=0x7f4ddc000ec0 buf={"execute":"query-block","id":"libvirt-27"} len=45 ret=45 errno=0 2017-03-10 15:04:26.093+0000: 16377: info : qemuMonitorIOProcess:429 : QEMU_MONITOR_IO_PROCESS: mon=0x7f4ddc000ec0 buf={"return": [{"io-status": "ok", "device": "drive-ide0-1-0", "locked": false, "removable": true, "tray_open": false, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 1000, "detect_zeroes": "off", "image": {"backing-image": {"virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "format": "raw", "actual-size": 1400521216, "dirty-flag": false}, "backing-filename-format": "raw", "virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 29184, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false}}, "full-backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "dirty-flag": false}, "iops_wr": 1000, "group": "drive-virtio-disk0", "ro": false, "node-name len=1023 2017-03-10 15:04:26.093+0000: 16377: debug : qemuMonitorJSONIOProcess:260 : Total used 0 bytes out of 1023 available in buffer 2017-03-10 15:04:26.093+0000: 16377: info : qemuMonitorIOProcess:429 : QEMU_MONITOR_IO_PROCESS: mon=0x7f4ddc000ec0 buf={"return": [{"io-status": "ok", "device": "drive-ide0-1-0", "locked": false, "removable": true, "tray_open": false, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 1000, "detect_zeroes": "off", "image": {"backing-image": {"virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "format": "raw", "actual-size": 1400521216, "dirty-flag": false}, "backing-filename-format": "raw", "virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 29184, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false}}, "full-backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "dirty-flag": false}, "iops_wr": 1000, "group": "drive-virtio-disk0", "ro": false, "node-name": "#block382", "bps_wr_max_length": 1, "backing_file_depth": 1, "iops_rd_max_length": 1, "bps_wr_max": 10485760, "bps_rd_max_length": 1, "drv": "qcow2", "iops_rd_max": 100, "iops": 0, "bps_wr": 104857600, "bps_rd_max": 10485760, "write_threshold": 0, "backing_file": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "encrypted": false, "bps": 0, "bps_rd": 104857600, "cache": {"no-flush": false, "direct": false, "writeback": false}, "file": "/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2", "iops_wr_max_length": 1, "encryption_key_missing": false, "iops_wr_max": 100}, "type": "unknown"}], "id": "libvirt-27"} len=1645 2017-03-10 15:04:26.093+0000: 16377: debug : qemuMonitorJSONIOProcessLine:191 : Line [{"return": [{"io-status": "ok", "device": "drive-ide0-1-0", "locked": false, "removable": true, "tray_open": false, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 1000, "detect_zeroes": "off", "image": {"backing-image": {"virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "format": "raw", "actual-size": 1400521216, "dirty-flag": false}, "backing-filename-format": "raw", "virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 29184, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false}}, "full-backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "dirty-flag": false}, "iops_wr": 1000, "group": "drive-virtio-disk0", "ro": false, "node-name": "#block382", "bps_wr_max_length": 1, "backing_file_depth": 1, "iops_rd_max_length": 1, "bps_wr_max": 10485760, "bps_rd_max_length": 1, "drv": "qcow2", "iops_rd_max": 100, "iops": 0, "bps_wr": 104857600, "bps_rd_max": 10485760, "write_threshold": 0, "backing_file": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "encrypted": false, "bps": 0, "bps_rd": 104857600, "cache": {"no-flush": false, "direct": false, "writeback": false}, "file": "/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2", "iops_wr_max_length": 1, "encryption_key_missing": false, "iops_wr_max": 100}, "type": "unknown"}], "id": "libvirt-27"}] 2017-03-10 15:04:26.094+0000: 16377: info : qemuMonitorJSONIOProcessLine:211 : QEMU_MONITOR_RECV_REPLY: mon=0x7f4ddc000ec0 reply={"return": [{"io-status": "ok", "device": "drive-ide0-1-0", "locked": false, "removable": true, "tray_open": false, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 1000, "detect_zeroes": "off", "image": {"backing-image": {"virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "format": "raw", "actual-size": 1400521216, "dirty-flag": false}, "backing-filename-format": "raw", "virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 29184, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false}}, "full-backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "dirty-flag": false}, "iops_wr": 1000, "group": "drive-virtio-disk0", "ro": false, "node-name": "#block382", "bps_wr_max_length": 1, "backing_file_depth": 1, "iops_rd_max_length": 1, "bps_wr_max": 10485760, "bps_rd_max_length": 1, "drv": "qcow2", "iops_rd_max": 100, "iops": 0, "bps_wr": 104857600, "bps_rd_max": 10485760, "write_threshold": 0, "backing_file": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "encrypted": false, "bps": 0, "bps_rd": 104857600, "cache": {"no-flush": false, "direct": false, "writeback": false}, "file": "/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2", "iops_wr_max_length": 1, "encryption_key_missing": false, "iops_wr_max": 100}, "type": "unknown"}], "id": "libvirt-27"} 2017-03-10 15:04:26.094+0000: 16377: debug : qemuMonitorJSONIOProcess:260 : Total used 1645 bytes out of 1645 available in buffer 2017-03-10 15:04:26.094+0000: 16382: debug : qemuMonitorJSONCommandWithFd:301 : Receive command reply ret=0 rxObject=0x55ffc58d0930 2017-03-10 15:04:26.094+0000: 16382: debug : qemuMonitorDiskNameLookup:3286 : mon:0x7f4ddc000ec0 vm:0x7f4dd81fd3c0 json:1 fd:20 2017-03-10 15:04:26.094+0000: 16382: debug : qemuMonitorJSONCommandWithFd:296 : Send command '{"execute":"query-block","id":"libvirt-28"}' for write with FD -1 2017-03-10 15:04:26.094+0000: 16382: info : qemuMonitorSend:1009 : QEMU_MONITOR_SEND_MSG: mon=0x7f4ddc000ec0 msg={"execute":"query-block","id":"libvirt-28"} fd=-1 2017-03-10 15:04:26.094+0000: 16377: info : qemuMonitorIOWrite:534 : QEMU_MONITOR_IO_WRITE: mon=0x7f4ddc000ec0 buf={"execute":"query-block","id":"libvirt-28"} len=45 ret=45 errno=0 2017-03-10 15:04:26.096+0000: 16377: info : qemuMonitorIOProcess:429 : QEMU_MONITOR_IO_PROCESS: mon=0x7f4ddc000ec0 buf={"return": [{"io-status": "ok", "device": "drive-ide0-1-0", "locked": false, "removable": true, "tray_open": false, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 1000, "detect_zeroes": "off", "image": {"backing-image": {"virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "format": "raw", "actual-size": 1400521216, "dirty-flag": false}, "backing-filename-format": "raw", "virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 29184, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false}}, "full-backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "dirty-flag": false}, "iops_wr": 1000, "group": "drive-virtio-disk0", "ro": false, "node-name len=1023 2017-03-10 15:04:26.096+0000: 16377: debug : qemuMonitorJSONIOProcess:260 : Total used 0 bytes out of 1023 available in buffer 2017-03-10 15:04:26.096+0000: 16377: info : qemuMonitorIOProcess:429 : QEMU_MONITOR_IO_PROCESS: mon=0x7f4ddc000ec0 buf={"return": [{"io-status": "ok", "device": "drive-ide0-1-0", "locked": false, "removable": true, "tray_open": false, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 1000, "detect_zeroes": "off", "image": {"backing-image": {"virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "format": "raw", "actual-size": 1400521216, "dirty-flag": false}, "backing-filename-format": "raw", "virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 29184, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false}}, "full-backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "dirty-flag": false}, "iops_wr": 1000, "group": "drive-virtio-disk0", "ro": false, "node-name": "#block382", "bps_wr_max_length": 1, "backing_file_depth": 1, "iops_rd_max_length": 1, "bps_wr_max": 10485760, "bps_rd_max_length": 1, "drv": "qcow2", "iops_rd_max": 100, "iops": 0, "bps_wr": 104857600, "bps_rd_max": 10485760, "write_threshold": 0, "backing_file": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "encrypted": false, "bps": 0, "bps_rd": 104857600, "cache": {"no-flush": false, "direct": false, "writeback": false}, "file": "/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2", "iops_wr_max_length": 1, "encryption_key_missing": false, "iops_wr_max": 100}, "type": "unknown"}], "id": "libvirt-28"} len=1645 2017-03-10 15:04:26.096+0000: 16377: debug : qemuMonitorJSONIOProcessLine:191 : Line [{"return": [{"io-status": "ok", "device": "drive-ide0-1-0", "locked": false, "removable": true, "tray_open": false, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 1000, "detect_zeroes": "off", "image": {"backing-image": {"virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "format": "raw", "actual-size": 1400521216, "dirty-flag": false}, "backing-filename-format": "raw", "virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 29184, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false}}, "full-backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "dirty-flag": false}, "iops_wr": 1000, "group": "drive-virtio-disk0", "ro": false, "node-name": "#block382", "bps_wr_max_length": 1, "backing_file_depth": 1, "iops_rd_max_length": 1, "bps_wr_max": 10485760, "bps_rd_max_length": 1, "drv": "qcow2", "iops_rd_max": 100, "iops": 0, "bps_wr": 104857600, "bps_rd_max": 10485760, "write_threshold": 0, "backing_file": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "encrypted": false, "bps": 0, "bps_rd": 104857600, "cache": {"no-flush": false, "direct": false, "writeback": false}, "file": "/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2", "iops_wr_max_length": 1, "encryption_key_missing": false, "iops_wr_max": 100}, "type": "unknown"}], "id": "libvirt-28"}] 2017-03-10 15:04:26.096+0000: 16377: info : qemuMonitorJSONIOProcessLine:211 : QEMU_MONITOR_RECV_REPLY: mon=0x7f4ddc000ec0 reply={"return": [{"io-status": "ok", "device": "drive-ide0-1-0", "locked": false, "removable": true, "tray_open": false, "type": "unknown"}, {"io-status": "ok", "device": "drive-virtio-disk0", "locked": false, "removable": false, "inserted": {"iops_rd": 1000, "detect_zeroes": "off", "image": {"backing-image": {"virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "format": "raw", "actual-size": 1400521216, "dirty-flag": false}, "backing-filename-format": "raw", "virtual-size": 10737418240, "filename": "/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2", "cluster-size": 65536, "format": "qcow2", "actual-size": 29184, "format-specific": {"type": "qcow2", "data": {"compat": "1.1", "lazy-refcounts": false, "refcount-bits": 16, "corrupt": false}}, "full-backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "backing-filename": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "dirty-flag": false}, "iops_wr": 1000, "group": "drive-virtio-disk0", "ro": false, "node-name": "#block382", "bps_wr_max_length": 1, "backing_file_depth": 1, "iops_rd_max_length": 1, "bps_wr_max": 10485760, "bps_rd_max_length": 1, "drv": "qcow2", "iops_rd_max": 100, "iops": 0, "bps_wr": 104857600, "bps_rd_max": 10485760, "write_threshold": 0, "backing_file": "/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img", "encrypted": false, "bps": 0, "bps_rd": 104857600, "cache": {"no-flush": false, "direct": false, "writeback": false}, "file": "/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2", "iops_wr_max_length": 1, "encryption_key_missing": false, "iops_wr_max": 100}, "type": "unknown"}], "id": "libvirt-28"} 2017-03-10 15:04:26.096+0000: 16377: debug : qemuMonitorJSONIOProcess:260 : Total used 1645 bytes out of 1645 available in buffer 2017-03-10 15:04:26.096+0000: 16382: debug : qemuMonitorJSONCommandWithFd:301 : Receive command reply ret=0 rxObject=0x55ffc58d0930 2017-03-10 15:04:26.097+0000: 16382: debug : qemuMonitorBlockCommit:3258 : device=drive-virtio-disk0, top=/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2, base=/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img, backingName=<null>, bandwidth=0 2017-03-10 15:04:26.097+0000: 16382: debug : qemuMonitorBlockCommit:3260 : mon:0x7f4ddc000ec0 vm:0x7f4dd81fd3c0 json:1 fd:20 2017-03-10 15:04:26.097+0000: 16382: debug : qemuMonitorJSONCommandWithFd:296 : Send command '{"execute":"block-commit","arguments":{"device":"drive-virtio-disk0","top":"/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2","base":"/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img"},"id":"libvirt-29"}' for write with FD -1 2017-03-10 15:04:26.097+0000: 16382: info : qemuMonitorSend:1009 : QEMU_MONITOR_SEND_MSG: mon=0x7f4ddc000ec0 msg={"execute":"block-commit","arguments":{"device":"drive-virtio-disk0","top":"/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2","base":"/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img"},"id":"libvirt-29"} fd=-1 2017-03-10 15:04:26.097+0000: 16377: info : qemuMonitorIOWrite:534 : QEMU_MONITOR_IO_WRITE: mon=0x7f4ddc000ec0 buf={"execute":"block-commit","arguments":{"device":"drive-virtio-disk0","top":"/data/volumes/pool2/ESBEK/snap/ESBEK-tor1-sys.img.qcow2","base":"/data/volumes/pool2/ESBEK/ESBEK-tor1-sys.img"},"id":"libvirt-29"} len=208 ret=208 errno=0 2017-03-10 15:04:26.110+0000: 16377: info : qemuMonitorIOProcess:429 : QEMU_MONITOR_IO_PROCESS: mon=0x7f4ddc000ec0 buf={"return": {}, "id": "libvirt-29"} len=36 2017-03-10 15:04:26.110+0000: 16377: debug : qemuMonitorJSONIOProcessLine:191 : Line [{"return": {}, "id": "libvirt-29"}] 2017-03-10 15:04:26.110+0000: 16377: info : qemuMonitorJSONIOProcessLine:211 : QEMU_MONITOR_RECV_REPLY: mon=0x7f4ddc000ec0 reply={"return": {}, "id": "libvirt-29"} 2017-03-10 15:04:26.110+0000: 16377: debug : qemuMonitorJSONIOProcess:260 : Total used 36 bytes out of 36 available in buffer 2017-03-10 15:04:26.110+0000: 16382: debug : qemuMonitorJSONCommandWithFd:301 : Receive command reply ret=0 rxObject=0x55ffc58d0930 2017-03-10 15:04:26.110+0000: 16382: debug : qemuDomainObjExitMonitorInternal:3699 : Exited monitor (mon=0x7f4ddc000ec0 vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.111+0000: 16382: debug : qemuDomainObjEndJob:3607 : Stopping job: modify (async=none vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.111+0000: 16382: debug : virThreadJobClear:121 : Thread 16382 (virNetServerHandleJob) finished job remoteDispatchDomainBlockCommit with ret=0 2017-03-10 15:04:26.111+0000: 16381: debug : virThreadJobSet:96 : Thread 16381 (virNetServerHandleJob) is now running job remoteDispatchDomainGetBlockJobInfo 2017-03-10 15:04:26.111+0000: 16381: debug : virDomainGetBlockJobInfo:9654 : dom=0x7f4e08000e70, (VM: name=ESBEK-tor1, uuid=f40593c0-d196-bb4b-0886-f1b32f86c9a1), disk=vda, info=0x7f4e26fc8c70, flags=0 2017-03-10 15:04:26.111+0000: 16381: debug : qemuDomainObjBeginJobInternal:3412 : Starting job: query (vm=0x7f4dd81fd3c0 name=ESBEK-tor1, current job=none async=none) 2017-03-10 15:04:26.111+0000: 16381: debug : qemuDomainObjBeginJobInternal:3453 : Started job: query (async=none vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.111+0000: 16381: debug : qemuDomainObjEnterMonitorInternal:3676 : Entering monitor (mon=0x7f4ddc000ec0 vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.111+0000: 16381: debug : qemuMonitorGetBlockJobInfo:3434 : alias=virtio-disk0, info=0x7f4e26fc8b90 2017-03-10 15:04:26.111+0000: 16381: debug : qemuMonitorGetAllBlockJobInfo:3415 : mon:0x7f4ddc000ec0 vm:0x7f4dd81fd3c0 json:1 fd:20 2017-03-10 15:04:26.111+0000: 16381: debug : qemuMonitorJSONCommandWithFd:296 : Send command '{"execute":"query-block-jobs","id":"libvirt-30"}' for write with FD -1 2017-03-10 15:04:26.111+0000: 16381: info : qemuMonitorSend:1009 : QEMU_MONITOR_SEND_MSG: mon=0x7f4ddc000ec0 msg={"execute":"query-block-jobs","id":"libvirt-30"} fd=-1 2017-03-10 15:04:26.111+0000: 16377: info : qemuMonitorIOWrite:534 : QEMU_MONITOR_IO_WRITE: mon=0x7f4ddc000ec0 buf={"execute":"query-block-jobs","id":"libvirt-30"} len=50 ret=50 errno=0 2017-03-10 15:04:26.115+0000: 16377: info : qemuMonitorIOProcess:429 : QEMU_MONITOR_IO_PROCESS: mon=0x7f4ddc000ec0 buf={"timestamp": {"seconds": 1489158266, "microseconds": 115061}, "event": "BLOCK_JOB_READY", "data": {"device": "drive-virtio-disk0", "len": 65536, "offset": 65536, "speed": 0, "type": "commit"}} len=195 2017-03-10 15:04:26.115+0000: 16377: debug : qemuMonitorJSONIOProcessLine:191 : Line [{"timestamp": {"seconds": 1489158266, "microseconds": 115061}, "event": "BLOCK_JOB_READY", "data": {"device": "drive-virtio-disk0", "len": 65536, "offset": 65536, "speed": 0, "type": "commit"}}] 2017-03-10 15:04:26.115+0000: 16377: info : qemuMonitorJSONIOProcessLine:206 : QEMU_MONITOR_RECV_EVENT: mon=0x7f4ddc000ec0 event={"timestamp": {"seconds": 1489158266, "microseconds": 115061}, "event": "BLOCK_JOB_READY", "data": {"device": "drive-virtio-disk0", "len": 65536, "offset": 65536, "speed": 0, "type": "commit"}} 2017-03-10 15:04:26.115+0000: 16377: debug : qemuMonitorJSONIOProcessEvent:152 : mon=0x7f4ddc000ec0 obj=0x55ffc58d7e20 2017-03-10 15:04:26.115+0000: 16377: debug : qemuMonitorEmitEvent:1272 : mon=0x7f4ddc000ec0 event=BLOCK_JOB_READY 2017-03-10 15:04:26.115+0000: 16377: debug : qemuProcessHandleEvent:617 : vm=0x7f4dd81fd3c0 2017-03-10 15:04:26.115+0000: 16377: debug : virObjectEventNew:640 : obj=0x55ffc58d0760 2017-03-10 15:04:26.115+0000: 16377: debug : qemuMonitorJSONIOProcessEvent:177 : handle BLOCK_JOB_READY handler=0x7f4e1cd3aed0 data=0x55ffc58d8d50 2017-03-10 15:04:26.115+0000: 16377: debug : qemuMonitorEmitBlockJob:1464 : mon=0x7f4ddc000ec0 2017-03-10 15:04:26.115+0000: 16377: debug : qemuProcessHandleBlockJob:976 : Block job for device drive-virtio-disk0 (domain: 0x7f4dd81fd3c0,ESBEK-tor1) type 3 status 3 2017-03-10 15:04:26.115+0000: 16377: debug : qemuMonitorJSONIOProcess:260 : Total used 195 bytes out of 195 available in buffer 2017-03-10 15:04:26.115+0000: 16377: debug : virObjectEventDispose:134 : obj=0x55ffc58d0760 2017-03-10 15:04:26.115+0000: 16377: info : qemuMonitorIOProcess:429 : QEMU_MONITOR_IO_PROCESS: mon=0x7f4ddc000ec0 buf={"return": [{"io-status": "ok", "device": "drive-virtio-disk0", "busy": false, "len": 65536, "offset": 65536, "paused": false, "speed": 0, "ready": true, "type": "commit"}], "id": "libvirt-30"} len=195 2017-03-10 15:04:26.115+0000: 16377: debug : qemuMonitorJSONIOProcessLine:191 : Line [{"return": [{"io-status": "ok", "device": "drive-virtio-disk0", "busy": false, "len": 65536, "offset": 65536, "paused": false, "speed": 0, "ready": true, "type": "commit"}], "id": "libvirt-30"}] 2017-03-10 15:04:26.115+0000: 16377: info : qemuMonitorJSONIOProcessLine:211 : QEMU_MONITOR_RECV_REPLY: mon=0x7f4ddc000ec0 reply={"return": [{"io-status": "ok", "device": "drive-virtio-disk0", "busy": false, "len": 65536, "offset": 65536, "paused": false, "speed": 0, "ready": true, "type": "commit"}], "id": "libvirt-30"} 2017-03-10 15:04:26.115+0000: 16377: debug : qemuMonitorJSONIOProcess:260 : Total used 195 bytes out of 195 available in buffer 2017-03-10 15:04:26.115+0000: 19721: debug : virThreadJobSetWorker:77 : Thread 19721 is running worker qemuProcessEventHandler 2017-03-10 15:04:26.116+0000: 16381: debug : qemuMonitorJSONCommandWithFd:301 : Receive command reply ret=0 rxObject=0x55ffc58d7e20 2017-03-10 15:04:26.116+0000: 19721: debug : qemuProcessEventHandler:4579 : vm=0x7f4dd81fd3c0, event=5 2017-03-10 15:04:26.116+0000: 19721: debug : qemuDomainObjBeginJobInternal:3412 : Starting job: modify (vm=0x7f4dd81fd3c0 name=ESBEK-tor1, current job=query async=none) 2017-03-10 15:04:26.116+0000: 19721: debug : qemuDomainObjBeginJobInternal:3435 : Waiting for job (vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.116+0000: 16381: debug : qemuDomainObjExitMonitorInternal:3699 : Exited monitor (mon=0x7f4ddc000ec0 vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.116+0000: 16381: debug : qemuDomainObjEndJob:3607 : Stopping job: query (async=none vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.116+0000: 19721: debug : qemuDomainObjBeginJobInternal:3453 : Started job: modify (async=none vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.116+0000: 16381: debug : virThreadJobClear:121 : Thread 16381 (virNetServerHandleJob) finished job remoteDispatchDomainGetBlockJobInfo with ret=0 2017-03-10 15:04:26.117+0000: 19721: debug : qemuBlockJobEventProcess:104 : disk=vda, mirrorState=yes, type=3, status=3 2017-03-10 15:04:26.117+0000: 19721: debug : virObjectEventNew:640 : obj=0x7f4ddc013480 2017-03-10 15:04:26.117+0000: 19721: debug : virObjectEventNew:640 : obj=0x7f4ddc012970 2017-03-10 15:04:26.117+0000: 19721: debug : qemuDomainObjEndJob:3607 : Stopping job: modify (async=none vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.117+0000: 16377: debug : virObjectEventDispose:134 : obj=0x7f4ddc013480 2017-03-10 15:04:26.117+0000: 16377: debug : virObjectEventDispose:134 : obj=0x7f4ddc012970 2017-03-10 15:04:26.617+0000: 16379: debug : virThreadJobSet:96 : Thread 16379 (virNetServerHandleJob) is now running job remoteDispatchDomainGetBlockJobInfo 2017-03-10 15:04:26.617+0000: 16379: debug : virDomainGetBlockJobInfo:9654 : dom=0x7f4e18000b60, (VM: name=ESBEK-tor1, uuid=f40593c0-d196-bb4b-0886-f1b32f86c9a1), disk=vda, info=0x7f4e27fcac70, flags=0 2017-03-10 15:04:26.617+0000: 16379: debug : qemuDomainObjBeginJobInternal:3412 : Starting job: query (vm=0x7f4dd81fd3c0 name=ESBEK-tor1, current job=none async=none) 2017-03-10 15:04:26.617+0000: 16379: debug : qemuDomainObjBeginJobInternal:3453 : Started job: query (async=none vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.617+0000: 16379: debug : qemuDomainObjEnterMonitorInternal:3676 : Entering monitor (mon=0x7f4ddc000ec0 vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.617+0000: 16379: debug : qemuMonitorGetBlockJobInfo:3434 : alias=virtio-disk0, info=0x7f4e27fcab90 2017-03-10 15:04:26.617+0000: 16379: debug : qemuMonitorGetAllBlockJobInfo:3415 : mon:0x7f4ddc000ec0 vm:0x7f4dd81fd3c0 json:1 fd:20 2017-03-10 15:04:26.617+0000: 16379: debug : qemuMonitorJSONCommandWithFd:296 : Send command '{"execute":"query-block-jobs","id":"libvirt-31"}' for write with FD -1 2017-03-10 15:04:26.617+0000: 16379: info : qemuMonitorSend:1009 : QEMU_MONITOR_SEND_MSG: mon=0x7f4ddc000ec0 msg={"execute":"query-block-jobs","id":"libvirt-31"} fd=-1 2017-03-10 15:04:26.618+0000: 16377: info : qemuMonitorIOWrite:534 : QEMU_MONITOR_IO_WRITE: mon=0x7f4ddc000ec0 buf={"execute":"query-block-jobs","id":"libvirt-31"} len=50 ret=50 errno=0 2017-03-10 15:04:26.619+0000: 16377: info : qemuMonitorIOProcess:429 : QEMU_MONITOR_IO_PROCESS: mon=0x7f4ddc000ec0 buf={"return": [{"io-status": "ok", "device": "drive-virtio-disk0", "busy": false, "len": 65536, "offset": 65536, "paused": false, "speed": 0, "ready": true, "type": "commit"}], "id": "libvirt-31"} len=195 2017-03-10 15:04:26.619+0000: 16377: debug : qemuMonitorJSONIOProcessLine:191 : Line [{"return": [{"io-status": "ok", "device": "drive-virtio-disk0", "busy": false, "len": 65536, "offset": 65536, "paused": false, "speed": 0, "ready": true, "type": "commit"}], "id": "libvirt-31"}] 2017-03-10 15:04:26.619+0000: 16377: info : qemuMonitorJSONIOProcessLine:211 : QEMU_MONITOR_RECV_REPLY: mon=0x7f4ddc000ec0 reply={"return": [{"io-status": "ok", "device": "drive-virtio-disk0", "busy": false, "len": 65536, "offset": 65536, "paused": false, "speed": 0, "ready": true, "type": "commit"}], "id": "libvirt-31"} 2017-03-10 15:04:26.619+0000: 16377: debug : qemuMonitorJSONIOProcess:260 : Total used 195 bytes out of 195 available in buffer 2017-03-10 15:04:26.620+0000: 16379: debug : qemuMonitorJSONCommandWithFd:301 : Receive command reply ret=0 rxObject=0x55ffc58d8e00 2017-03-10 15:04:26.620+0000: 16379: debug : qemuDomainObjExitMonitorInternal:3699 : Exited monitor (mon=0x7f4ddc000ec0 vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.620+0000: 16379: debug : qemuDomainObjEndJob:3607 : Stopping job: query (async=none vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.620+0000: 16379: debug : virThreadJobClear:121 : Thread 16379 (virNetServerHandleJob) finished job remoteDispatchDomainGetBlockJobInfo with ret=0 2017-03-10 15:04:26.620+0000: 16378: debug : virThreadJobSet:96 : Thread 16378 (virNetServerHandleJob) is now running job remoteDispatchDomainBlockJobAbort 2017-03-10 15:04:26.620+0000: 16378: debug : virDomainBlockJobAbort:9592 : dom=0x7f4e20001040, (VM: name=ESBEK-tor1, uuid=f40593c0-d196-bb4b-0886-f1b32f86c9a1), disk=vda, flags=2 2017-03-10 15:04:26.620+0000: 16378: debug : qemuDomainObjBeginJobInternal:3412 : Starting job: modify (vm=0x7f4dd81fd3c0 name=ESBEK-tor1, current job=none async=none) 2017-03-10 15:04:26.620+0000: 16378: debug : qemuDomainObjBeginJobInternal:3453 : Started job: modify (async=none vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.620+0000: 16378: debug : qemuBlockJobSyncBegin:230 : disk=vda 2017-03-10 15:04:26.620+0000: 16378: debug : qemuDomainObjEnterMonitorInternal:3676 : Entering monitor (mon=0x7f4ddc000ec0 vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.620+0000: 16378: debug : qemuMonitorDrivePivot:3297 : device=drive-virtio-disk0 2017-03-10 15:04:26.620+0000: 16378: debug : qemuMonitorDrivePivot:3299 : mon:0x7f4ddc000ec0 vm:0x7f4dd81fd3c0 json:1 fd:20 2017-03-10 15:04:26.620+0000: 16378: debug : qemuMonitorJSONCommandWithFd:296 : Send command '{"execute":"block-job-complete","arguments":{"device":"drive-virtio-disk0"},"id":"libvirt-32"}' for write with FD -1 2017-03-10 15:04:26.620+0000: 16378: info : qemuMonitorSend:1009 : QEMU_MONITOR_SEND_MSG: mon=0x7f4ddc000ec0 msg={"execute":"block-job-complete","arguments":{"device":"drive-virtio-disk0"},"id":"libvirt-32"} fd=-1 2017-03-10 15:04:26.621+0000: 16377: info : qemuMonitorIOWrite:534 : QEMU_MONITOR_IO_WRITE: mon=0x7f4ddc000ec0 buf={"execute":"block-job-complete","arguments":{"device":"drive-virtio-disk0"},"id":"libvirt-32"} len=96 ret=96 errno=0 2017-03-10 15:04:26.624+0000: 16377: info : qemuMonitorIOProcess:429 : QEMU_MONITOR_IO_PROCESS: mon=0x7f4ddc000ec0 buf={"return": {}, "id": "libvirt-32"} len=36 2017-03-10 15:04:26.624+0000: 16377: debug : qemuMonitorJSONIOProcessLine:191 : Line [{"return": {}, "id": "libvirt-32"}] 2017-03-10 15:04:26.624+0000: 16377: info : qemuMonitorJSONIOProcessLine:211 : QEMU_MONITOR_RECV_REPLY: mon=0x7f4ddc000ec0 reply={"return": {}, "id": "libvirt-32"} 2017-03-10 15:04:26.624+0000: 16377: debug : qemuMonitorJSONIOProcess:260 : Total used 36 bytes out of 36 available in buffer 2017-03-10 15:04:26.624+0000: 16378: debug : qemuMonitorJSONCommandWithFd:301 : Receive command reply ret=0 rxObject=0x55ffc58d7e20 2017-03-10 15:04:26.624+0000: 16378: debug : qemuDomainObjExitMonitorInternal:3699 : Exited monitor (mon=0x7f4ddc000ec0 vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.624+0000: 16377: info : qemuMonitorIOProcess:429 : QEMU_MONITOR_IO_PROCESS: mon=0x7f4ddc000ec0 buf={"timestamp": {"seconds": 1489158266, "microseconds": 624625}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "drive-virtio-disk0", "len": 65536, "offset": 65536, "speed": 0, "type": "commit"}} len=199 2017-03-10 15:04:26.624+0000: 16377: debug : qemuMonitorJSONIOProcessLine:191 : Line [{"timestamp": {"seconds": 1489158266, "microseconds": 624625}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "drive-virtio-disk0", "len": 65536, "offset": 65536, "speed": 0, "type": "commit"}}] 2017-03-10 15:04:26.624+0000: 16377: info : qemuMonitorJSONIOProcessLine:206 : QEMU_MONITOR_RECV_EVENT: mon=0x7f4ddc000ec0 event={"timestamp": {"seconds": 1489158266, "microseconds": 624625}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "drive-virtio-disk0", "len": 65536, "offset": 65536, "speed": 0, "type": "commit"}} 2017-03-10 15:04:26.624+0000: 16377: debug : qemuMonitorJSONIOProcessEvent:152 : mon=0x7f4ddc000ec0 obj=0x55ffc58d7e20 2017-03-10 15:04:26.624+0000: 16377: debug : qemuMonitorEmitEvent:1272 : mon=0x7f4ddc000ec0 event=BLOCK_JOB_COMPLETED 2017-03-10 15:04:26.624+0000: 16377: debug : qemuProcessHandleEvent:617 : vm=0x7f4dd81fd3c0 2017-03-10 15:04:26.624+0000: 16377: debug : virObjectEventNew:640 : obj=0x55ffc58d0760 2017-03-10 15:04:26.624+0000: 16377: debug : qemuMonitorJSONIOProcessEvent:177 : handle BLOCK_JOB_COMPLETED handler=0x7f4e1cd3aee0 data=0x55ffc58d8d50 2017-03-10 15:04:26.624+0000: 16377: debug : qemuMonitorEmitBlockJob:1464 : mon=0x7f4ddc000ec0 2017-03-10 15:04:26.624+0000: 16377: debug : qemuProcessHandleBlockJob:976 : Block job for device drive-virtio-disk0 (domain: 0x7f4dd81fd3c0,ESBEK-tor1) type 3 status 0 2017-03-10 15:04:26.624+0000: 16377: debug : qemuMonitorJSONIOProcess:260 : Total used 199 bytes out of 199 available in buffer 2017-03-10 15:04:26.624+0000: 16378: debug : qemuBlockJobEventProcess:104 : disk=vda, mirrorState=pivot, type=3, status=0 2017-03-10 15:04:26.624+0000: 16377: debug : virObjectEventDispose:134 : obj=0x55ffc58d0760 2017-03-10 15:04:26.625+0000: 16378: debug : virObjectEventNew:640 : obj=0x7f4e200008e0 2017-03-10 15:04:26.625+0000: 16378: debug : virObjectEventNew:640 : obj=0x7f4e200032d0 2017-03-10 15:04:26.653+0000: 16378: debug : qemuBlockJobSyncEnd:250 : disk=vda 2017-03-10 15:04:26.653+0000: 16378: debug : qemuDomainObjEndJob:3607 : Stopping job: modify (async=none vm=0x7f4dd81fd3c0 name=ESBEK-tor1) 2017-03-10 15:04:26.653+0000: 16378: debug : virThreadJobClear:121 : Thread 16378 (virNetServerHandleJob) finished job remoteDispatchDomainBlockJobAbort with ret=0 2017-03-10 15:04:26.653+0000: 16377: debug : virObjectEventDispose:134 : obj=0x7f4e200008e0 2017-03-10 15:04:26.653+0000: 16377: debug : virObjectEventDispose:134 : obj=0x7f4e200032d0 2017-03-10 15:04:26.654+0000: 16380: debug : virThreadJobSet:96 : Thread 16380 (virNetServerHandleJob) is now running job remoteDispatchConnectDomainEventCallbackDeregisterAny 2017-03-10 15:04:26.654+0000: 16380: debug : virConnectDomainEventDeregisterAny:9134 : conn=0x7f4e20002fe0, callbackID=0 2017-03-10 15:04:26.654+0000: 16380: debug : virThreadJobClear:121 : Thread 16380 (virNetServerHandleJob) finished job remoteDispatchConnectDomainEventCallbackDeregisterAny with ret=0 2017-03-10 15:04:26.655+0000: 16382: debug : virThreadJobSet:96 : Thread 16382 (virNetServerHandleJob) is now running job remoteDispatchConnectDomainEventCallbackDeregisterAny 2017-03-10 15:04:26.655+0000: 16382: debug : virConnectDomainEventDeregisterAny:9134 : conn=0x7f4e20002fe0, callbackID=1 2017-03-10 15:04:26.655+0000: 16382: debug : virThreadJobClear:121 : Thread 16382 (virNetServerHandleJob) finished job remoteDispatchConnectDomainEventCallbackDeregisterAny with ret=0 2017-03-10 15:04:26.655+0000: 16381: debug : virThreadJobSet:96 : Thread 16381 (virNetServerHandleJob) is now running job remoteDispatchConnectUnregisterCloseCallback 2017-03-10 15:04:26.655+0000: 16381: debug : virConnectUnregisterCloseCallback:1253 : conn=0x7f4e20002fe0 2017-03-10 15:04:26.655+0000: 16381: debug : virThreadJobClear:121 : Thread 16381 (virNetServerHandleJob) finished job remoteDispatchConnectUnregisterCloseCallback with ret=0 2017-03-10 15:04:26.656+0000: 16379: debug : virThreadJobSet:96 : Thread 16379 (virNetServerHandleJob) is now running job remoteDispatchConnectClose 2017-03-10 15:04:26.656+0000: 16379: debug : virThreadJobClear:121 : Thread 16379 (virNetServerHandleJob) finished job remoteDispatchConnectClose with ret=0 2017-03-10 15:04:26.656+0000: 16377: debug : virIdentitySetAttr:248 : ident=0x55ffc58d17e0 attribute=4 value=16377 2017-03-10 15:04:26.656+0000: 16377: debug : virIdentitySetAttr:248 : ident=0x55ffc58d17e0 attribute=5 value=759159 2017-03-10 15:04:26.656+0000: 16377: debug : virIdentitySetAttr:248 : ident=0x55ffc58d17e0 attribute=0 value=root 2017-03-10 15:04:26.656+0000: 16377: debug : virIdentitySetAttr:248 : ident=0x55ffc58d17e0 attribute=1 value=0 2017-03-10 15:04:26.656+0000: 16377: debug : virIdentitySetAttr:248 : ident=0x55ffc58d17e0 attribute=2 value=root 2017-03-10 15:04:26.656+0000: 16377: debug : virIdentitySetAttr:248 : ident=0x55ffc58d17e0 attribute=3 value=0 2017-03-10 15:04:26.656+0000: 16377: debug : virConnectClose:1290 : conn=0x7f4e20002fe0 2017-03-10 15:04:26.656+0000: 16377: debug : virCloseCallbacksRun:325 : conn=0x7f4e20002fe0 Best regards Piotr Rybicki ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-08 8:26 [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) Thomas Huth 2017-03-08 10:03 ` Peter Maydell @ 2017-03-08 10:20 ` Daniel P. Berrange 2017-03-08 11:19 ` Gerd Hoffmann 2017-03-09 16:00 ` Kevin Wolf 2017-03-24 22:10 ` John Snow 3 siblings, 1 reply; 52+ messages in thread From: Daniel P. Berrange @ 2017-03-08 10:20 UTC (permalink / raw) To: Thomas Huth; +Cc: QEMU Developers, Peter Maydell, Stefan Hajnoczi On Wed, Mar 08, 2017 at 09:26:00AM +0100, Thomas Huth wrote: > > Hi everybody, > > what will be the next version of QEMU after 2.9? Will we go for a 2.10 > (as I've seen it mentioned a couple of times on the mailing list > already), or do we dare to switch to 3.0 instead? > > I personally dislike two-digit minor version numbers like 2.10 since the > non-experienced users sometimes mix it up with 2.1 ... and there have > been a couple of new cool features in the past releases that would > justify a 3.0 now, too, I think. If we need to debate whether to switch major version numbers, it is a sign we should set out a clearer policy on version numbering :-) AFAIK, QEMU's never documented semantics for changes in the major number part of the version. I don't think the 1.0 or 2.0 releases were particularly significant in what they introduced/changed, as opposed to many of the .x releases. It was a fairly arbitrary decision to bump the major version. libvirt suffered similar lack of clarity around when to bump major version number as opposed to minor version. To address this we recently adopted the rule[1] that major version number changes have no relation to features. The major number is simply incremented at the start of each calendar year. > But anyway, the more important thing that keeps me concerned is: Someone > once told me that we should get rid of old parameters and interfaces > (like HMP commands) primarily only when we're changing to a new major > version number. As you all know, QEMU has a lot of legacy options, which > are likely rather confusing than helpful for the new users nowadays, > e.g. things like the "-net channel" option (which is fortunately even > hardly documented), but maybe also even the whole vlan/hub concept in > the net code, or legacy parameters like "-usbdevice". If we switch to > version 3.0, could we agree to remove at least some of them? This would, by inference, say that increments of major part of the version number indicate backwards incompatible changes in QEMU API. That is certainly one option for a rule around major version number changes but is not one QEMU seems to have traditionally followed. The release notes show plenty of incompatible changes in arbitrary .x releases. >From the POV of libvirt, I don't think saying that .0 releases have incompatible changes is particularly useful in itself. What *is* useful is to have a clear rule around a deprecation cycle. ie, a rule that says a feature will be marked deprecated for 3 releases or 12 months, before it is permitted to be removed/changed. If that were followed, there is no need to batch up such changes in a .0 release IMHO. Regards, Daniel [1] http://libvirt.org/downloads.html#numbering -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-08 10:20 ` [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) Daniel P. Berrange @ 2017-03-08 11:19 ` Gerd Hoffmann 2017-04-12 13:47 ` Marc-André Lureau 0 siblings, 1 reply; 52+ messages in thread From: Gerd Hoffmann @ 2017-03-08 11:19 UTC (permalink / raw) To: Daniel P. Berrange Cc: Thomas Huth, Peter Maydell, QEMU Developers, Stefan Hajnoczi Hi, > libvirt suffered similar lack of clarity around when to bump major version > number as opposed to minor version. To address this we recently adopted the > rule[1] that major version number changes have no relation to features. The > major number is simply incremented at the start of each calendar year. I like the idea of time-based version numbering. Changing the plan for 2.9 still is probably a bad idea given we have a 2.9 machine type already etc. But we can start changing things afterwards. So we could start with 3.x after 2.9, and bump the major for the first release each year (libvirt-style). Or we could use the year as major number and jump straight to 17.x (mesa-style). > From the POV of libvirt, I don't think saying that .0 releases have > incompatible changes is particularly useful in itself. What *is* useful > is to have a clear rule around a deprecation cycle. ie, a rule that says > a feature will be marked deprecated for 3 releases or 12 months, before it > is permitted to be removed/changed. If that were followed, there is no > need to batch up such changes in a .0 release IMHO. Yes, it's probably a good idea to deprecate things first. When going with the 12 months rule it could be useful to batch things and do a yearly "spring cleaning" when the major is bumped. We could also create new machine types for major versions only, to keep the number somewhat under control. Not sure how well that would work in practice. We'd probably need a ${type}-next machine type then (future ${type}-4 machine type, for development, incompatible changes allowed) and make ${type}-3 the default machine type. cheers, Gerd ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-08 11:19 ` Gerd Hoffmann @ 2017-04-12 13:47 ` Marc-André Lureau 2017-04-12 14:10 ` Gerd Hoffmann 0 siblings, 1 reply; 52+ messages in thread From: Marc-André Lureau @ 2017-04-12 13:47 UTC (permalink / raw) To: Gerd Hoffmann, Daniel P. Berrange Cc: Peter Maydell, Thomas Huth, QEMU Developers, Stefan Hajnoczi Hi On Wed, Mar 8, 2017 at 12:20 PM Gerd Hoffmann <kraxel@redhat.com> wrote: > Hi, > > > libvirt suffered similar lack of clarity around when to bump major > version > > number as opposed to minor version. To address this we recently adopted > the > > rule[1] that major version number changes have no relation to features. > The > > major number is simply incremented at the start of each calendar year. > > I like the idea of time-based version numbering. Changing the plan for > 2.9 still is probably a bad idea given we have a 2.9 machine type > already etc. > > But we can start changing things afterwards. So we could start with 3.x > after 2.9, and bump the major for the first release each year > (libvirt-style). Or we could use the year as major number and jump > straight to 17.x (mesa-style). > > > From the POV of libvirt, I don't think saying that .0 releases have > > incompatible changes is particularly useful in itself. What *is* useful > > is to have a clear rule around a deprecation cycle. ie, a rule that says > > a feature will be marked deprecated for 3 releases or 12 months, before > it > > is permitted to be removed/changed. If that were followed, there is no > > need to batch up such changes in a .0 release IMHO. > > Yes, it's probably a good idea to deprecate things first. When going > with the 12 months rule it could be useful to batch things and do a > yearly "spring cleaning" when the major is bumped. > > What about deprecating GTK 2.0 ? SDL (1.2 or all?) I suspect there are also a number of arm boards that are not regularly tested and could be drop, who could tell? -- Marc-André Lureau ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-04-12 13:47 ` Marc-André Lureau @ 2017-04-12 14:10 ` Gerd Hoffmann 0 siblings, 0 replies; 52+ messages in thread From: Gerd Hoffmann @ 2017-04-12 14:10 UTC (permalink / raw) To: Marc-André Lureau Cc: Daniel P. Berrange, Peter Maydell, Thomas Huth, QEMU Developers, Stefan Hajnoczi Hi, > What about deprecating GTK 2.0 ? SDL (1.2 or all?) gtk2 + sdl1 makes sense. sdl2 proably has too many users to drop it. Not everybody prefers the gtk ui ... cheers, Gerd ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-08 8:26 [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) Thomas Huth 2017-03-08 10:03 ` Peter Maydell 2017-03-08 10:20 ` [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) Daniel P. Berrange @ 2017-03-09 16:00 ` Kevin Wolf 2017-03-24 22:10 ` John Snow 3 siblings, 0 replies; 52+ messages in thread From: Kevin Wolf @ 2017-03-09 16:00 UTC (permalink / raw) To: Thomas Huth; +Cc: QEMU Developers, Peter Maydell, Stefan Hajnoczi Am 08.03.2017 um 09:26 hat Thomas Huth geschrieben: > what will be the next version of QEMU after 2.9? Will we go for a 2.10 > (as I've seen it mentioned a couple of times on the mailing list > already), or do we dare to switch to 3.0 instead? > > I personally dislike two-digit minor version numbers like 2.10 since the > non-experienced users sometimes mix it up with 2.1 ... and there have > been a couple of new cool features in the past releases that would > justify a 3.0 now, too, I think. We never really defined what major version numbers meant (except "Anthony felt like using a new one"), so it's kind of arbitrary and we could decide either way. I don't think double digit minor version numbers make the switch necessary, though. We went up to 0.15 before without any problems. When this was discussed in IRC a while ago, the consensus seemed to be 2.10, so that's what I've been talking about since then - and from what I read, it seems most other people are still expecting the same. > But anyway, the more important thing that keeps me concerned is: Someone > once told me that we should get rid of old parameters and interfaces > (like HMP commands) primarily only when we're changing to a new major > version number. As you all know, QEMU has a lot of legacy options, which > are likely rather confusing than helpful for the new users nowadays, > e.g. things like the "-net channel" option (which is fortunately even > hardly documented), but maybe also even the whole vlan/hub concept in > the net code, or legacy parameters like "-usbdevice". If we switch to > version 3.0, could we agree to remove at least some of them? If we want to go this way, maybe this would actually be an argument for doing a 2.10 first to give people enough time to think about any incompatible changes they would like to make and then do 3.0 one release later. Kevin ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-08 8:26 [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) Thomas Huth ` (2 preceding siblings ...) 2017-03-09 16:00 ` Kevin Wolf @ 2017-03-24 22:10 ` John Snow 2017-03-27 8:06 ` Thomas Huth 3 siblings, 1 reply; 52+ messages in thread From: John Snow @ 2017-03-24 22:10 UTC (permalink / raw) To: qemu-devel On 03/08/2017 03:26 AM, Thomas Huth wrote: > > Hi everybody, > > what will be the next version of QEMU after 2.9? Will we go for a 2.10 > (as I've seen it mentioned a couple of times on the mailing list > already), or do we dare to switch to 3.0 instead? > > I personally dislike two-digit minor version numbers like 2.10 since the > non-experienced users sometimes mix it up with 2.1 ... and there have > been a couple of new cool features in the past releases that would > justify a 3.0 now, too, I think. > > But anyway, the more important thing that keeps me concerned is: Someone > once told me that we should get rid of old parameters and interfaces > (like HMP commands) primarily only when we're changing to a new major > version number. As you all know, QEMU has a lot of legacy options, which > are likely rather confusing than helpful for the new users nowadays, > e.g. things like the "-net channel" option (which is fortunately even > hardly documented), but maybe also even the whole vlan/hub concept in > the net code, or legacy parameters like "-usbdevice". If we switch to > version 3.0, could we agree to remove at least some of them? > > Thomas > As others have stated, we need a few releases to deprecate things first. Maybe we should develop a serious plan to develop some of our legacy interfaces first. Maybe 2.10 can introduce a list of things we want to deprecate, 2.11 can be the transition release, and then 3.0 can cut the cord and free of us our terrible burden? I have a list of things I want to axe... --js ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-24 22:10 ` John Snow @ 2017-03-27 8:06 ` Thomas Huth 2017-03-27 12:01 ` Stefan Hajnoczi ` (2 more replies) 0 siblings, 3 replies; 52+ messages in thread From: Thomas Huth @ 2017-03-27 8:06 UTC (permalink / raw) To: John Snow, qemu-devel On 24.03.2017 23:10, John Snow wrote: > > > On 03/08/2017 03:26 AM, Thomas Huth wrote: >> >> Hi everybody, >> >> what will be the next version of QEMU after 2.9? Will we go for a 2.10 >> (as I've seen it mentioned a couple of times on the mailing list >> already), or do we dare to switch to 3.0 instead? >> >> I personally dislike two-digit minor version numbers like 2.10 since the >> non-experienced users sometimes mix it up with 2.1 ... and there have >> been a couple of new cool features in the past releases that would >> justify a 3.0 now, too, I think. >> >> But anyway, the more important thing that keeps me concerned is: Someone >> once told me that we should get rid of old parameters and interfaces >> (like HMP commands) primarily only when we're changing to a new major >> version number. As you all know, QEMU has a lot of legacy options, which >> are likely rather confusing than helpful for the new users nowadays, >> e.g. things like the "-net channel" option (which is fortunately even >> hardly documented), but maybe also even the whole vlan/hub concept in >> the net code, or legacy parameters like "-usbdevice". If we switch to >> version 3.0, could we agree to remove at least some of them? >> >> Thomas >> > > As others have stated, we need a few releases to deprecate things first. > > Maybe we should develop a serious plan to develop some of our legacy > interfaces first. > > Maybe 2.10 can introduce a list of things we want to deprecate, > 2.11 can be the transition release, > and then 3.0 can cut the cord and free of us our terrible burden? > > I have a list of things I want to axe... I've started a Wiki page with such a list here: http://wiki.qemu-project.org/Features/LegacyRemoval Feel free to amend! Thomas ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-27 8:06 ` Thomas Huth @ 2017-03-27 12:01 ` Stefan Hajnoczi 2017-03-27 12:49 ` Peter Maydell 2017-03-27 12:56 ` [Qemu-devel] Deprecating the -net option (was: What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces)) Thomas Huth 2017-03-27 19:04 ` [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) John Snow 2017-03-28 17:18 ` [Qemu-devel] Deprecating the -drive option is a good point in time to get rid of old interfaces) Kevin Wolf 2 siblings, 2 replies; 52+ messages in thread From: Stefan Hajnoczi @ 2017-03-27 12:01 UTC (permalink / raw) To: Thomas Huth; +Cc: John Snow, qemu-devel, jasowang [-- Attachment #1: Type: text/plain, Size: 2121 bytes --] On Mon, Mar 27, 2017 at 10:06:09AM +0200, Thomas Huth wrote: > On 24.03.2017 23:10, John Snow wrote: > > > > > > On 03/08/2017 03:26 AM, Thomas Huth wrote: > >> > >> Hi everybody, > >> > >> what will be the next version of QEMU after 2.9? Will we go for a 2.10 > >> (as I've seen it mentioned a couple of times on the mailing list > >> already), or do we dare to switch to 3.0 instead? > >> > >> I personally dislike two-digit minor version numbers like 2.10 since the > >> non-experienced users sometimes mix it up with 2.1 ... and there have > >> been a couple of new cool features in the past releases that would > >> justify a 3.0 now, too, I think. > >> > >> But anyway, the more important thing that keeps me concerned is: Someone > >> once told me that we should get rid of old parameters and interfaces > >> (like HMP commands) primarily only when we're changing to a new major > >> version number. As you all know, QEMU has a lot of legacy options, which > >> are likely rather confusing than helpful for the new users nowadays, > >> e.g. things like the "-net channel" option (which is fortunately even > >> hardly documented), but maybe also even the whole vlan/hub concept in > >> the net code, or legacy parameters like "-usbdevice". If we switch to > >> version 3.0, could we agree to remove at least some of them? > >> > >> Thomas > >> > > > > As others have stated, we need a few releases to deprecate things first. > > > > Maybe we should develop a serious plan to develop some of our legacy > > interfaces first. > > > > Maybe 2.10 can introduce a list of things we want to deprecate, > > 2.11 can be the transition release, > > and then 3.0 can cut the cord and free of us our terrible burden? > > > > I have a list of things I want to axe... > > I've started a Wiki page with such a list here: > > http://wiki.qemu-project.org/Features/LegacyRemoval It would be nice to get rid of the legacy -net option in 3.0.0. I have added it and included pointers to loose ends. I think this is doable but will require some time to achieve. Stefan [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-27 12:01 ` Stefan Hajnoczi @ 2017-03-27 12:49 ` Peter Maydell 2017-04-03 14:19 ` Stefan Hajnoczi 2017-03-27 12:56 ` [Qemu-devel] Deprecating the -net option (was: What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces)) Thomas Huth 1 sibling, 1 reply; 52+ messages in thread From: Peter Maydell @ 2017-03-27 12:49 UTC (permalink / raw) To: Stefan Hajnoczi; +Cc: Thomas Huth, Jason Wang, John Snow, QEMU Developers On 27 March 2017 at 13:01, Stefan Hajnoczi <stefanha@gmail.com> wrote: > It would be nice to get rid of the legacy -net option in 3.0.0. I have > added it and included pointers to loose ends. I think this is doable > but will require some time to achieve. What's the syntax for using -netdev with embedded network devices that you can't create with -device ? (We should document this at http://wiki.qemu-project.org/Documentation/Networking) thanks -- PMM ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-27 12:49 ` Peter Maydell @ 2017-04-03 14:19 ` Stefan Hajnoczi 2017-04-11 12:53 ` Markus Armbruster 0 siblings, 1 reply; 52+ messages in thread From: Stefan Hajnoczi @ 2017-04-03 14:19 UTC (permalink / raw) To: Peter Maydell; +Cc: Thomas Huth, Jason Wang, John Snow, QEMU Developers [-- Attachment #1: Type: text/plain, Size: 721 bytes --] On Mon, Mar 27, 2017 at 01:49:44PM +0100, Peter Maydell wrote: > On 27 March 2017 at 13:01, Stefan Hajnoczi <stefanha@gmail.com> wrote: > > It would be nice to get rid of the legacy -net option in 3.0.0. I have > > added it and included pointers to loose ends. I think this is doable > > but will require some time to achieve. > > What's the syntax for using -netdev with embedded network > devices that you can't create with -device ? > (We should document this at > http://wiki.qemu-project.org/Documentation/Networking) I mentioned that on the wiki. This isn't an option we can drop easily. Work is necessary to make -netdev a complete replacement or to remove the legacy stuff from -net. Stefan [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-04-03 14:19 ` Stefan Hajnoczi @ 2017-04-11 12:53 ` Markus Armbruster 2017-04-18 9:51 ` Stefan Hajnoczi 0 siblings, 1 reply; 52+ messages in thread From: Markus Armbruster @ 2017-04-11 12:53 UTC (permalink / raw) To: Stefan Hajnoczi Cc: Peter Maydell, Thomas Huth, John Snow, Jason Wang, QEMU Developers Stefan Hajnoczi <stefanha@gmail.com> writes: > On Mon, Mar 27, 2017 at 01:49:44PM +0100, Peter Maydell wrote: >> On 27 March 2017 at 13:01, Stefan Hajnoczi <stefanha@gmail.com> wrote: >> > It would be nice to get rid of the legacy -net option in 3.0.0. I have >> > added it and included pointers to loose ends. I think this is doable >> > but will require some time to achieve. >> >> What's the syntax for using -netdev with embedded network >> devices that you can't create with -device ? >> (We should document this at >> http://wiki.qemu-project.org/Documentation/Networking) > > I mentioned that on the wiki. This isn't an option we can drop easily. > Work is necessary to make -netdev a complete replacement or to remove > the legacy stuff from -net. Just like -device is a general way to plug in devices, replacing multiple special ways (-net, -drive, -usb, ...), we could use a general way to configure onboard devices. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-04-11 12:53 ` Markus Armbruster @ 2017-04-18 9:51 ` Stefan Hajnoczi 2017-04-18 11:57 ` Gerd Hoffmann 0 siblings, 1 reply; 52+ messages in thread From: Stefan Hajnoczi @ 2017-04-18 9:51 UTC (permalink / raw) To: Markus Armbruster Cc: Peter Maydell, Thomas Huth, John Snow, Jason Wang, QEMU Developers [-- Attachment #1: Type: text/plain, Size: 1282 bytes --] On Tue, Apr 11, 2017 at 02:53:00PM +0200, Markus Armbruster wrote: > Stefan Hajnoczi <stefanha@gmail.com> writes: > > > On Mon, Mar 27, 2017 at 01:49:44PM +0100, Peter Maydell wrote: > >> On 27 March 2017 at 13:01, Stefan Hajnoczi <stefanha@gmail.com> wrote: > >> > It would be nice to get rid of the legacy -net option in 3.0.0. I have > >> > added it and included pointers to loose ends. I think this is doable > >> > but will require some time to achieve. > >> > >> What's the syntax for using -netdev with embedded network > >> devices that you can't create with -device ? > >> (We should document this at > >> http://wiki.qemu-project.org/Documentation/Networking) > > > > I mentioned that on the wiki. This isn't an option we can drop easily. > > Work is necessary to make -netdev a complete replacement or to remove > > the legacy stuff from -net. > > Just like -device is a general way to plug in devices, replacing > multiple special ways (-net, -drive, -usb, ...), we could use a general > way to configure onboard devices. I looked at the -device implementation to see if the bus= parameter could be used to specify onboard device addresses, but I think you may be right that we need a separate command-line argument for onboard devices. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 455 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-04-18 9:51 ` Stefan Hajnoczi @ 2017-04-18 11:57 ` Gerd Hoffmann 2017-04-18 17:18 ` John Snow 0 siblings, 1 reply; 52+ messages in thread From: Gerd Hoffmann @ 2017-04-18 11:57 UTC (permalink / raw) To: Stefan Hajnoczi Cc: Markus Armbruster, Peter Maydell, Thomas Huth, John Snow, Jason Wang, QEMU Developers Hi, > > Just like -device is a general way to plug in devices, replacing > > multiple special ways (-net, -drive, -usb, ...), we could use a general > > way to configure onboard devices. > > I looked at the -device implementation to see if the bus= parameter > could be used to specify onboard device addresses, but I think you may > be right that we need a separate command-line argument for onboard > devices. I think so. There is -global, which is actually used by libvirt to configure built-in floppy devices. But as the name suggests it sets properties globally, i.e. for all instances. Which works in this specific use case, as there can be only one floppy controller per machine, but I don't think this is something we want build on. There is -set, but that works only for devices created via -device, because it operates on QemuOpts, and we don't have QemuOpts for built-in devices. We probably want something like -qom-set-property {objpath|alias}.prop=value cheers, Gerd ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-04-18 11:57 ` Gerd Hoffmann @ 2017-04-18 17:18 ` John Snow 2017-04-19 5:53 ` Markus Armbruster 2017-04-19 10:15 ` Gerd Hoffmann 0 siblings, 2 replies; 52+ messages in thread From: John Snow @ 2017-04-18 17:18 UTC (permalink / raw) To: Gerd Hoffmann, Stefan Hajnoczi Cc: Markus Armbruster, Peter Maydell, Thomas Huth, Jason Wang, QEMU Developers On 04/18/2017 07:57 AM, Gerd Hoffmann wrote: > Hi, > >>> Just like -device is a general way to plug in devices, replacing >>> multiple special ways (-net, -drive, -usb, ...), we could use a general >>> way to configure onboard devices. >> >> I looked at the -device implementation to see if the bus= parameter >> could be used to specify onboard device addresses, but I think you may >> be right that we need a separate command-line argument for onboard >> devices. > > I think so. > > There is -global, which is actually used by libvirt to configure > built-in floppy devices. But as the name suggests it sets properties > globally, i.e. for all instances. Which works in this specific use > case, as there can be only one floppy controller per machine, but I Spec-wise, Can't you have two? > don't think this is something we want build on. > > There is -set, but that works only for devices created via -device, > because it operates on QemuOpts, and we don't have QemuOpts for built-in > devices. > > We probably want something like > -qom-set-property {objpath|alias}.prop=value > > cheers, > Gerd > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-04-18 17:18 ` John Snow @ 2017-04-19 5:53 ` Markus Armbruster 2017-04-19 10:35 ` Gerd Hoffmann 2017-04-19 10:15 ` Gerd Hoffmann 1 sibling, 1 reply; 52+ messages in thread From: Markus Armbruster @ 2017-04-19 5:53 UTC (permalink / raw) To: John Snow Cc: Gerd Hoffmann, Stefan Hajnoczi, Jason Wang, Peter Maydell, Thomas Huth, QEMU Developers John Snow <jsnow@redhat.com> writes: > On 04/18/2017 07:57 AM, Gerd Hoffmann wrote: >> Hi, >> >>>> Just like -device is a general way to plug in devices, replacing >>>> multiple special ways (-net, -drive, -usb, ...), we could use a general >>>> way to configure onboard devices. >>> >>> I looked at the -device implementation to see if the bus= parameter >>> could be used to specify onboard device addresses, but I think you may >>> be right that we need a separate command-line argument for onboard >>> devices. >> >> I think so. >> >> There is -global, which is actually used by libvirt to configure >> built-in floppy devices. But as the name suggests it sets properties >> globally, i.e. for all instances. Which works in this specific use >> case, as there can be only one floppy controller per machine, but I > > Spec-wise, Can't you have two? You can, but approximately nobody wants to. >> don't think this is something we want build on. >> >> There is -set, but that works only for devices created via -device, >> because it operates on QemuOpts, and we don't have QemuOpts for built-in >> devices. Yes. QAPIfying the command line wouldn't change that. >> We probably want something like >> -qom-set-property {objpath|alias}.prop=value Makes sense to me. We should be able to desugar -net, ... to -qom-set-property then. However, the desugaring would be machine-specific in general. Machines would need to provide data or code to guide the desugaring, replacing their code that rummages through global configuration such as nd_table[]. Sounds like an improvement to me. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-04-19 5:53 ` Markus Armbruster @ 2017-04-19 10:35 ` Gerd Hoffmann 0 siblings, 0 replies; 52+ messages in thread From: Gerd Hoffmann @ 2017-04-19 10:35 UTC (permalink / raw) To: Markus Armbruster Cc: John Snow, Stefan Hajnoczi, Jason Wang, Peter Maydell, Thomas Huth, QEMU Developers Hi, > >> We probably want something like > >> -qom-set-property {objpath|alias}.prop=value > > Makes sense to me. > > We should be able to desugar -net, ... to -qom-set-property then. > However, the desugaring would be machine-specific in general. Yes. Establishing rules for alias names for builtin devices should reduce the pain, and allow stuff like this: -netdev user,id=mynetdev \ -qom-set-property buildin-nic0.netdev=mynetdev We probably also want a shorter name for -qom-set-property, and maybe also syntax which allows to set multiple properties in one go, so the command line doesn't become too long. cheers, Gerd ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-04-18 17:18 ` John Snow 2017-04-19 5:53 ` Markus Armbruster @ 2017-04-19 10:15 ` Gerd Hoffmann 2017-04-19 23:08 ` John Snow 1 sibling, 1 reply; 52+ messages in thread From: Gerd Hoffmann @ 2017-04-19 10:15 UTC (permalink / raw) To: John Snow Cc: Stefan Hajnoczi, Markus Armbruster, Peter Maydell, Thomas Huth, Jason Wang, QEMU Developers Hi, > > There is -global, which is actually used by libvirt to configure > > built-in floppy devices. But as the name suggests it sets properties > > globally, i.e. for all instances. Which works in this specific use > > case, as there can be only one floppy controller per machine, but I > > Spec-wise, Can't you have two? You can have two floppy drives, but they are hooked to the same controller. isa-fdc has two properties (driveA and driveB) for that reason, so -global works even for two floppy drives. cheers, Gerd ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-04-19 10:15 ` Gerd Hoffmann @ 2017-04-19 23:08 ` John Snow 2017-04-20 5:40 ` Gerd Hoffmann 0 siblings, 1 reply; 52+ messages in thread From: John Snow @ 2017-04-19 23:08 UTC (permalink / raw) To: Gerd Hoffmann Cc: Stefan Hajnoczi, Markus Armbruster, Peter Maydell, Thomas Huth, Jason Wang, QEMU Developers On 04/19/2017 06:15 AM, Gerd Hoffmann wrote: > Hi, > >>> There is -global, which is actually used by libvirt to configure >>> built-in floppy devices. But as the name suggests it sets properties >>> globally, i.e. for all instances. Which works in this specific use >>> case, as there can be only one floppy controller per machine, but I >> >> Spec-wise, Can't you have two? > > You can have two floppy drives, but they are hooked to the same Yes, I'm aware. I'm just saying here "Spec-wise" because you can have two controllers, one at 0x3F0 and one at 0x370. I realize this isn't particularly relevant for discussions relating to CLI design, but... you *can* have two controllers if your heart truly desired it. --js > controller. isa-fdc has two properties (driveA and driveB) for that > reason, so -global works even for two floppy drives. > > cheers, > Gerd > ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-04-19 23:08 ` John Snow @ 2017-04-20 5:40 ` Gerd Hoffmann 2017-04-20 11:10 ` Philippe Mathieu-Daudé 0 siblings, 1 reply; 52+ messages in thread From: Gerd Hoffmann @ 2017-04-20 5:40 UTC (permalink / raw) To: John Snow Cc: Stefan Hajnoczi, Markus Armbruster, Peter Maydell, Thomas Huth, Jason Wang, QEMU Developers Hi, > > You can have two floppy drives, but they are hooked to the same > > Yes, I'm aware. > > I'm just saying here "Spec-wise" because you can have two controllers, > one at 0x3F0 and one at 0x370. Oh, ok. Wasn't aware of this detail. Can't remember to have ever seen a pc with more than two floppy drives (as-in: physical hardware). And even two floppy drives is pretty rare. Only in the early 90ies, while the transition from 5.25" floppies to 3.5" floppies happened, it was somewhat common to have two drives (one of each type). cheers, Gerd ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-04-20 5:40 ` Gerd Hoffmann @ 2017-04-20 11:10 ` Philippe Mathieu-Daudé 0 siblings, 0 replies; 52+ messages in thread From: Philippe Mathieu-Daudé @ 2017-04-20 11:10 UTC (permalink / raw) To: Gerd Hoffmann, John Snow Cc: Peter Maydell, Thomas Huth, Stefan Hajnoczi, Jason Wang, QEMU Developers, Markus Armbruster >>> You can have two floppy drives, but they are hooked to the same >> >> Yes, I'm aware. >> >> I'm just saying here "Spec-wise" because you can have two controllers, >> one at 0x3F0 and one at 0x370. > > Oh, ok. Wasn't aware of this detail. > > Can't remember to have ever seen a pc with more than two floppy drives > (as-in: physical hardware). And even two floppy drives is pretty rare. > Only in the early 90ies, while the transition from 5.25" floppies to > 3.5" floppies happened, it was somewhat common to have two drives (one > of each type). Preteens multitasking... Copying W4r3z while surfing on FidoNet and running PCBoard on your 1040ST before catching school bus. Remembering BBS life at 2400bps? __ / \ /|oo \ (_| /_) _`@/_ \ _ | | \ \\ | (*) | \ )) ______ |__U__| / \// / FIDO \ _//|| _\ / (________) (_/(_|(____/ (c) John Madil ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] Deprecating the -net option (was: What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces)) 2017-03-27 12:01 ` Stefan Hajnoczi 2017-03-27 12:49 ` Peter Maydell @ 2017-03-27 12:56 ` Thomas Huth 2017-03-27 13:09 ` [Qemu-devel] Deprecating the -net option Thomas Huth 1 sibling, 1 reply; 52+ messages in thread From: Thomas Huth @ 2017-03-27 12:56 UTC (permalink / raw) To: Stefan Hajnoczi; +Cc: jasowang, John Snow, qemu-devel, Paolo Bonzini [-- Attachment #1: Type: text/plain, Size: 2976 bytes --] On 27.03.2017 14:01, Stefan Hajnoczi wrote: > On Mon, Mar 27, 2017 at 10:06:09AM +0200, Thomas Huth wrote: >> On 24.03.2017 23:10, John Snow wrote: >>> >>> >>> On 03/08/2017 03:26 AM, Thomas Huth wrote: >>>> >>>> Hi everybody, >>>> >>>> what will be the next version of QEMU after 2.9? Will we go for a 2.10 >>>> (as I've seen it mentioned a couple of times on the mailing list >>>> already), or do we dare to switch to 3.0 instead? >>>> >>>> I personally dislike two-digit minor version numbers like 2.10 since the >>>> non-experienced users sometimes mix it up with 2.1 ... and there have >>>> been a couple of new cool features in the past releases that would >>>> justify a 3.0 now, too, I think. >>>> >>>> But anyway, the more important thing that keeps me concerned is: Someone >>>> once told me that we should get rid of old parameters and interfaces >>>> (like HMP commands) primarily only when we're changing to a new major >>>> version number. As you all know, QEMU has a lot of legacy options, which >>>> are likely rather confusing than helpful for the new users nowadays, >>>> e.g. things like the "-net channel" option (which is fortunately even >>>> hardly documented), but maybe also even the whole vlan/hub concept in >>>> the net code, or legacy parameters like "-usbdevice". If we switch to >>>> version 3.0, could we agree to remove at least some of them? >>>> >>>> Thomas >>>> >>> >>> As others have stated, we need a few releases to deprecate things first. >>> >>> Maybe we should develop a serious plan to develop some of our legacy >>> interfaces first. >>> >>> Maybe 2.10 can introduce a list of things we want to deprecate, >>> 2.11 can be the transition release, >>> and then 3.0 can cut the cord and free of us our terrible burden? >>> >>> I have a list of things I want to axe... >> >> I've started a Wiki page with such a list here: >> >> http://wiki.qemu-project.org/Features/LegacyRemoval > > It would be nice to get rid of the legacy -net option in 3.0.0. I have > added it and included pointers to loose ends. I think this is doable > but will require some time to achieve. Not sure whether we really can get rid of the -net option completely, since AFAIK it is the only way to configure on-board NICs at the moment, and Paolo complains if he needs to type longer command lines (https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg02448.html). But maybe we could get rid of the VLANs here at least, e.g. by matching "-net nic" and a following "-net user|bridge|tap|..." with an internal netdev ID instead of creating a "VLAN" hub? Or we could even turn the -net option into a full "convenience" option instead (similar to "-hda" and friends), so that you even do not have to specify "-net nic" anymore but create both, network source and sink with one "-net" statement, e.g.: qemu-system-xxx -net user,model=e1000,hostfwd=... Just my 0.02 € Thomas [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] Deprecating the -net option 2017-03-27 12:56 ` [Qemu-devel] Deprecating the -net option (was: What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces)) Thomas Huth @ 2017-03-27 13:09 ` Thomas Huth 2017-03-27 15:04 ` Paolo Bonzini 0 siblings, 1 reply; 52+ messages in thread From: Thomas Huth @ 2017-03-27 13:09 UTC (permalink / raw) To: Stefan Hajnoczi; +Cc: Paolo Bonzini, jasowang, John Snow, qemu-devel [-- Attachment #1: Type: text/plain, Size: 3597 bytes --] On 27.03.2017 14:56, Thomas Huth wrote: > On 27.03.2017 14:01, Stefan Hajnoczi wrote: >> On Mon, Mar 27, 2017 at 10:06:09AM +0200, Thomas Huth wrote: >>> On 24.03.2017 23:10, John Snow wrote: >>>> >>>> >>>> On 03/08/2017 03:26 AM, Thomas Huth wrote: >>>>> >>>>> Hi everybody, >>>>> >>>>> what will be the next version of QEMU after 2.9? Will we go for a 2.10 >>>>> (as I've seen it mentioned a couple of times on the mailing list >>>>> already), or do we dare to switch to 3.0 instead? >>>>> >>>>> I personally dislike two-digit minor version numbers like 2.10 since the >>>>> non-experienced users sometimes mix it up with 2.1 ... and there have >>>>> been a couple of new cool features in the past releases that would >>>>> justify a 3.0 now, too, I think. >>>>> >>>>> But anyway, the more important thing that keeps me concerned is: Someone >>>>> once told me that we should get rid of old parameters and interfaces >>>>> (like HMP commands) primarily only when we're changing to a new major >>>>> version number. As you all know, QEMU has a lot of legacy options, which >>>>> are likely rather confusing than helpful for the new users nowadays, >>>>> e.g. things like the "-net channel" option (which is fortunately even >>>>> hardly documented), but maybe also even the whole vlan/hub concept in >>>>> the net code, or legacy parameters like "-usbdevice". If we switch to >>>>> version 3.0, could we agree to remove at least some of them? >>>>> >>>>> Thomas >>>>> >>>> >>>> As others have stated, we need a few releases to deprecate things first. >>>> >>>> Maybe we should develop a serious plan to develop some of our legacy >>>> interfaces first. >>>> >>>> Maybe 2.10 can introduce a list of things we want to deprecate, >>>> 2.11 can be the transition release, >>>> and then 3.0 can cut the cord and free of us our terrible burden? >>>> >>>> I have a list of things I want to axe... >>> >>> I've started a Wiki page with such a list here: >>> >>> http://wiki.qemu-project.org/Features/LegacyRemoval >> >> It would be nice to get rid of the legacy -net option in 3.0.0. I have >> added it and included pointers to loose ends. I think this is doable >> but will require some time to achieve. > > Not sure whether we really can get rid of the -net option completely, > since AFAIK it is the only way to configure on-board NICs at the moment, > and Paolo complains if he needs to type longer command lines > (https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg02448.html). > > But maybe we could get rid of the VLANs here at least, e.g. by matching > "-net nic" and a following "-net user|bridge|tap|..." with an internal > netdev ID instead of creating a "VLAN" hub? > > Or we could even turn the -net option into a full "convenience" option > instead (similar to "-hda" and friends), so that you even do not have to > specify "-net nic" anymore but create both, network source and sink with > one "-net" statement, e.g.: > > qemu-system-xxx -net user,model=e1000,hostfwd=... > > Just my 0.02 € ... and I forgot to mention: We should at least try to get rid of the options first that only work with -net (or rather the VLAN concept), like "-net dump", "-net channel", "-tftp", "-smb", "-bootp" and "-redir", since these will hinder us from doing further reworks / clean-ups in this area. I think I've mentioned them all on the Wiki page now, if somebody is aware of another legacy option here that does not work with "-netdev" yet (apart from -net nic itself), please let me know. Thomas [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] Deprecating the -net option 2017-03-27 13:09 ` [Qemu-devel] Deprecating the -net option Thomas Huth @ 2017-03-27 15:04 ` Paolo Bonzini 0 siblings, 0 replies; 52+ messages in thread From: Paolo Bonzini @ 2017-03-27 15:04 UTC (permalink / raw) To: Thomas Huth, Stefan Hajnoczi; +Cc: jasowang, John Snow, qemu-devel [-- Attachment #1: Type: text/plain, Size: 667 bytes --] On 27/03/2017 15:09, Thomas Huth wrote: > ... and I forgot to mention: We should at least try to get rid of the > options first that only work with -net (or rather the VLAN concept), > like "-net dump", "-net channel", "-tftp", "-smb", "-bootp" and > "-redir", since these will hinder us from doing further reworks / > clean-ups in this area. I think I've mentioned them all on the Wiki page > now, if somebody is aware of another legacy option here that does not > work with "-netdev" yet (apart from -net nic itself), please let me know. Yes, please. No objections at all for those, except possibly "-net dump" (but I've never used it). Paolo [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-27 8:06 ` Thomas Huth 2017-03-27 12:01 ` Stefan Hajnoczi @ 2017-03-27 19:04 ` John Snow 2017-03-27 19:46 ` Thomas Huth 2017-03-29 16:21 ` [Qemu-devel] Deprecating old machine types Thomas Huth 2017-03-28 17:18 ` [Qemu-devel] Deprecating the -drive option is a good point in time to get rid of old interfaces) Kevin Wolf 2 siblings, 2 replies; 52+ messages in thread From: John Snow @ 2017-03-27 19:04 UTC (permalink / raw) To: Thomas Huth, qemu-devel On 03/27/2017 04:06 AM, Thomas Huth wrote: > On 24.03.2017 23:10, John Snow wrote: >> >> >> On 03/08/2017 03:26 AM, Thomas Huth wrote: >>> >>> Hi everybody, >>> >>> what will be the next version of QEMU after 2.9? Will we go for a 2.10 >>> (as I've seen it mentioned a couple of times on the mailing list >>> already), or do we dare to switch to 3.0 instead? >>> >>> I personally dislike two-digit minor version numbers like 2.10 since the >>> non-experienced users sometimes mix it up with 2.1 ... and there have >>> been a couple of new cool features in the past releases that would >>> justify a 3.0 now, too, I think. >>> >>> But anyway, the more important thing that keeps me concerned is: Someone >>> once told me that we should get rid of old parameters and interfaces >>> (like HMP commands) primarily only when we're changing to a new major >>> version number. As you all know, QEMU has a lot of legacy options, which >>> are likely rather confusing than helpful for the new users nowadays, >>> e.g. things like the "-net channel" option (which is fortunately even >>> hardly documented), but maybe also even the whole vlan/hub concept in >>> the net code, or legacy parameters like "-usbdevice". If we switch to >>> version 3.0, could we agree to remove at least some of them? >>> >>> Thomas >>> >> >> As others have stated, we need a few releases to deprecate things first. >> >> Maybe we should develop a serious plan to develop some of our legacy >> interfaces first. >> >> Maybe 2.10 can introduce a list of things we want to deprecate, >> 2.11 can be the transition release, >> and then 3.0 can cut the cord and free of us our terrible burden? >> >> I have a list of things I want to axe... > > I've started a Wiki page with such a list here: > > http://wiki.qemu-project.org/Features/LegacyRemoval > > Feel free to amend! > Absolutely! > Thomas > Should we make an effort to print warnings for any of these items in the list for 2.10 that they may disappear for 3.0? It'd be nice to turn this wiki list into something that we're actually definitely going to do. --js ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) 2017-03-27 19:04 ` [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) John Snow @ 2017-03-27 19:46 ` Thomas Huth 2017-03-29 16:21 ` [Qemu-devel] Deprecating old machine types Thomas Huth 1 sibling, 0 replies; 52+ messages in thread From: Thomas Huth @ 2017-03-27 19:46 UTC (permalink / raw) To: John Snow, qemu-devel On 27.03.2017 21:04, John Snow wrote: > > > On 03/27/2017 04:06 AM, Thomas Huth wrote: >> On 24.03.2017 23:10, John Snow wrote: >>> >>> >>> On 03/08/2017 03:26 AM, Thomas Huth wrote: >>>> >>>> Hi everybody, >>>> >>>> what will be the next version of QEMU after 2.9? Will we go for a 2.10 >>>> (as I've seen it mentioned a couple of times on the mailing list >>>> already), or do we dare to switch to 3.0 instead? >>>> >>>> I personally dislike two-digit minor version numbers like 2.10 since the >>>> non-experienced users sometimes mix it up with 2.1 ... and there have >>>> been a couple of new cool features in the past releases that would >>>> justify a 3.0 now, too, I think. >>>> >>>> But anyway, the more important thing that keeps me concerned is: Someone >>>> once told me that we should get rid of old parameters and interfaces >>>> (like HMP commands) primarily only when we're changing to a new major >>>> version number. As you all know, QEMU has a lot of legacy options, which >>>> are likely rather confusing than helpful for the new users nowadays, >>>> e.g. things like the "-net channel" option (which is fortunately even >>>> hardly documented), but maybe also even the whole vlan/hub concept in >>>> the net code, or legacy parameters like "-usbdevice". If we switch to >>>> version 3.0, could we agree to remove at least some of them? >>>> >>>> Thomas >>>> >>> >>> As others have stated, we need a few releases to deprecate things first. >>> >>> Maybe we should develop a serious plan to develop some of our legacy >>> interfaces first. >>> >>> Maybe 2.10 can introduce a list of things we want to deprecate, >>> 2.11 can be the transition release, >>> and then 3.0 can cut the cord and free of us our terrible burden? >>> >>> I have a list of things I want to axe... >> >> I've started a Wiki page with such a list here: >> >> http://wiki.qemu-project.org/Features/LegacyRemoval >> >> Feel free to amend! >> > > Absolutely! > > Should we make an effort to print warnings for any of these items in the > list for 2.10 that they may disappear for 3.0? Yes, I think there was something like a consensus earlier in this thread that we should warn for at least two releases before removing a legacy interface, so we should make sure that we add a warning for the listed items in 2.10. > It'd be nice to turn this wiki list into something that we're actually > definitely going to do. I definitely plan to add some warnings once the hard freeze is over and the development tree opens again. If you want to help with the patches, you're very welcome! Thomas ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] Deprecating old machine types 2017-03-27 19:04 ` [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) John Snow 2017-03-27 19:46 ` Thomas Huth @ 2017-03-29 16:21 ` Thomas Huth 2017-03-29 16:46 ` Dr. David Alan Gilbert 1 sibling, 1 reply; 52+ messages in thread From: Thomas Huth @ 2017-03-29 16:21 UTC (permalink / raw) To: qemu-devel Cc: John Snow, Michael S. Tsirkin, Paolo Bonzini, Dr. David Alan Gilbert, Juan Quintela On 27.03.2017 21:04, John Snow wrote: > > On 03/27/2017 04:06 AM, Thomas Huth wrote: >> On 24.03.2017 23:10, John Snow wrote: [...] >>> I have a list of things I want to axe... >> >> I've started a Wiki page with such a list here: >> >> http://wiki.qemu-project.org/Features/LegacyRemoval >> >> Feel free to amend! > > Absolutely! By the way, what about old machine types like "pc-0.10" ? Do we want to carry them along forever (e.g. since it is not too complicated to maintain?), or shall we get rid of those one day (e.g. with QEMU 3.0), too? Thomas ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] Deprecating old machine types 2017-03-29 16:21 ` [Qemu-devel] Deprecating old machine types Thomas Huth @ 2017-03-29 16:46 ` Dr. David Alan Gilbert 2017-03-29 16:54 ` Thomas Huth 2017-03-29 16:58 ` Paolo Bonzini 0 siblings, 2 replies; 52+ messages in thread From: Dr. David Alan Gilbert @ 2017-03-29 16:46 UTC (permalink / raw) To: Thomas Huth Cc: qemu-devel, John Snow, Michael S. Tsirkin, Paolo Bonzini, Juan Quintela * Thomas Huth (thuth@redhat.com) wrote: > On 27.03.2017 21:04, John Snow wrote: > > > > On 03/27/2017 04:06 AM, Thomas Huth wrote: > >> On 24.03.2017 23:10, John Snow wrote: > [...] > >>> I have a list of things I want to axe... > >> > >> I've started a Wiki page with such a list here: > >> > >> http://wiki.qemu-project.org/Features/LegacyRemoval > >> > >> Feel free to amend! > > > > Absolutely! > > By the way, what about old machine types like "pc-0.10" ? Do we want to > carry them along forever (e.g. since it is not too complicated to > maintain?), or shall we get rid of those one day (e.g. with QEMU 3.0), too? It seems reasonable to slowly deprecate them. I'm just not sure how slowly. Dave > > Thomas > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] Deprecating old machine types 2017-03-29 16:46 ` Dr. David Alan Gilbert @ 2017-03-29 16:54 ` Thomas Huth 2017-03-29 16:58 ` Paolo Bonzini 1 sibling, 0 replies; 52+ messages in thread From: Thomas Huth @ 2017-03-29 16:54 UTC (permalink / raw) To: Dr. David Alan Gilbert Cc: qemu-devel, John Snow, Michael S. Tsirkin, Paolo Bonzini, Juan Quintela On 29.03.2017 18:46, Dr. David Alan Gilbert wrote: > * Thomas Huth (thuth@redhat.com) wrote: >> On 27.03.2017 21:04, John Snow wrote: >>> >>> On 03/27/2017 04:06 AM, Thomas Huth wrote: >>>> On 24.03.2017 23:10, John Snow wrote: >> [...] >>>>> I have a list of things I want to axe... >>>> >>>> I've started a Wiki page with such a list here: >>>> >>>> http://wiki.qemu-project.org/Features/LegacyRemoval >>>> >>>> Feel free to amend! >>> >>> Absolutely! >> >> By the way, what about old machine types like "pc-0.10" ? Do we want to >> carry them along forever (e.g. since it is not too complicated to >> maintain?), or shall we get rid of those one day (e.g. with QEMU 3.0), too? > > It seems reasonable to slowly deprecate them. > I'm just not sure how slowly. We could maybe at least start with "pc-0.10", and maybe also "pc-0.11" ... if nobody complains afterwards, we can get rid of the other pc-0.x machines later with QEMU 4.0 (or so). Thomas ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] Deprecating old machine types 2017-03-29 16:46 ` Dr. David Alan Gilbert 2017-03-29 16:54 ` Thomas Huth @ 2017-03-29 16:58 ` Paolo Bonzini 2017-03-29 21:42 ` Michael S. Tsirkin 2017-03-30 8:04 ` Gerd Hoffmann 1 sibling, 2 replies; 52+ messages in thread From: Paolo Bonzini @ 2017-03-29 16:58 UTC (permalink / raw) To: Dr. David Alan Gilbert, Thomas Huth Cc: qemu-devel, John Snow, Michael S. Tsirkin, Juan Quintela On 29/03/2017 18:46, Dr. David Alan Gilbert wrote: >> By the way, what about old machine types like "pc-0.10" ? Do we want to >> carry them along forever (e.g. since it is not too complicated to >> maintain?), or shall we get rid of those one day (e.g. with QEMU 3.0), too? > It seems reasonable to slowly deprecate them. > I'm just not sure how slowly. Some data: - dropping 0.12, 0.13 _and_ isapc would let us kill the code for rombar=0 (i.e. where QEMU copies ROM BARs directly to low memory). - the oldest versions in use are probably 0.12 (CentOS 6) and 1.0 (Ubuntu 12.04) - migration from old versions is broken in various ways from at least QEMU 1.2 and older. Paolo ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] Deprecating old machine types 2017-03-29 16:58 ` Paolo Bonzini @ 2017-03-29 21:42 ` Michael S. Tsirkin 2017-03-30 8:04 ` Gerd Hoffmann 1 sibling, 0 replies; 52+ messages in thread From: Michael S. Tsirkin @ 2017-03-29 21:42 UTC (permalink / raw) To: Paolo Bonzini Cc: Dr. David Alan Gilbert, Thomas Huth, qemu-devel, John Snow, Juan Quintela On Wed, Mar 29, 2017 at 06:58:36PM +0200, Paolo Bonzini wrote: > > > On 29/03/2017 18:46, Dr. David Alan Gilbert wrote: > >> By the way, what about old machine types like "pc-0.10" ? Do we want to > >> carry them along forever (e.g. since it is not too complicated to > >> maintain?), or shall we get rid of those one day (e.g. with QEMU 3.0), too? > > It seems reasonable to slowly deprecate them. > > I'm just not sure how slowly. > > Some data: > > - dropping 0.12, 0.13 _and_ isapc would let us kill the code for > rombar=0 (i.e. where QEMU copies ROM BARs directly to low memory). > > - the oldest versions in use are probably 0.12 (CentOS 6) and 1.0 > (Ubuntu 12.04) > > - migration from old versions is broken in various ways from at least > QEMU 1.2 and older. > > Paolo Live-migration, yes. But live-migrations are a minority, most people update qemu and restart it but do not want to reinstall their guests and that is only reliable if you keep the old machine type. And that seems to work reasonably well. So one way would be to mark 0.10 and 0.11 unmigrateable, and drop rombar=0 hacks. -- MST ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [Qemu-devel] Deprecating old machine types 2017-03-29 16:58 ` Paolo Bonzini 2017-03-29 21:42 ` Michael S. Tsirkin @ 2017-03-30 8:04 ` Gerd Hoffmann 1 sibling, 0 replies; 52+ messages in thread From: Gerd Hoffmann @ 2017-03-30 8:04 UTC (permalink / raw) To: Paolo Bonzini Cc: Dr. David Alan Gilbert, Thomas Huth, Juan Quintela, John Snow, qemu-devel, Michael S. Tsirkin On Mi, 2017-03-29 at 18:58 +0200, Paolo Bonzini wrote: > > On 29/03/2017 18:46, Dr. David Alan Gilbert wrote: > >> By the way, what about old machine types like "pc-0.10" ? Do we want to > >> carry them along forever (e.g. since it is not too complicated to > >> maintain?), or shall we get rid of those one day (e.g. with QEMU 3.0), too? > > It seems reasonable to slowly deprecate them. > > I'm just not sure how slowly. > > Some data: > > - dropping 0.12, 0.13 _and_ isapc would let us kill the code for > rombar=0 (i.e. where QEMU copies ROM BARs directly to low memory). > > - the oldest versions in use are probably 0.12 (CentOS 6) and 1.0 > (Ubuntu 12.04) > > - migration from old versions is broken in various ways from at least > QEMU 1.2 and older. Maybe it is useful to discuss this more in terms of code we want drop instead of version numbers ... So, here is my (x86-centric) wishlist: * Drop support for isapc (already added that to the wiki a few days ago). Also isa-* devices where we have pci variants (isa-vga, isa-cirrus-vga, ne2k_isa). Any old guests without pci support (such as ms-dos) should be happy with "pc" having vga and ide ioports on the standard isa locations for backward compatibility and seabios handing all pci stuff. Plugging isa devices (soundblaster for example) into "pc" works too. So I can't see a compelling use case for isapc. IIRC we even had a release with broken isapc with nobody noticing during the -rc phase ... * Drop support for rombar, and also the code for the linear vbe framebuffer magically showing up at 0xe0000000. * Drop backward-compatibility with pre-memory-api qemu versions. I guess the memory api switch is one of the big reasons why live migration to older versions is broken. The memory api was merged in 1.0, so the above would imply dropping support for all pc-0.x machine types and isapc. The 1.0 release was tagged on Dec 1st 2011, more than five years ago. cheers, Gerd ^ permalink raw reply [flat|nested] 52+ messages in thread
* [Qemu-devel] Deprecating the -drive option is a good point in time to get rid of old interfaces) 2017-03-27 8:06 ` Thomas Huth 2017-03-27 12:01 ` Stefan Hajnoczi 2017-03-27 19:04 ` [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) John Snow @ 2017-03-28 17:18 ` Kevin Wolf 2 siblings, 0 replies; 52+ messages in thread From: Kevin Wolf @ 2017-03-28 17:18 UTC (permalink / raw) To: Thomas Huth; +Cc: John Snow, qemu-devel, armbru, qemu-block Am 27.03.2017 um 10:06 hat Thomas Huth geschrieben: > On 24.03.2017 23:10, John Snow wrote: > > On 03/08/2017 03:26 AM, Thomas Huth wrote: > >> > >> Hi everybody, > >> > >> what will be the next version of QEMU after 2.9? Will we go for a 2.10 > >> (as I've seen it mentioned a couple of times on the mailing list > >> already), or do we dare to switch to 3.0 instead? > >> > >> I personally dislike two-digit minor version numbers like 2.10 since the > >> non-experienced users sometimes mix it up with 2.1 ... and there have > >> been a couple of new cool features in the past releases that would > >> justify a 3.0 now, too, I think. > >> > >> But anyway, the more important thing that keeps me concerned is: Someone > >> once told me that we should get rid of old parameters and interfaces > >> (like HMP commands) primarily only when we're changing to a new major > >> version number. As you all know, QEMU has a lot of legacy options, which > >> are likely rather confusing than helpful for the new users nowadays, > >> e.g. things like the "-net channel" option (which is fortunately even > >> hardly documented), but maybe also even the whole vlan/hub concept in > >> the net code, or legacy parameters like "-usbdevice". If we switch to > >> version 3.0, could we agree to remove at least some of them? > >> > >> Thomas > >> > > > > As others have stated, we need a few releases to deprecate things first. > > > > Maybe we should develop a serious plan to develop some of our legacy > > interfaces first. > > > > Maybe 2.10 can introduce a list of things we want to deprecate, > > 2.11 can be the transition release, > > and then 3.0 can cut the cord and free of us our terrible burden? > > > > I have a list of things I want to axe... > > I've started a Wiki page with such a list here: > > http://wiki.qemu-project.org/Features/LegacyRemoval > > Feel free to amend! I propose deprecating -drive (in favour of -blockdev/-device) and added it to the list. Similar to -net, we still need to check that all block devices created internally by individual machines can still be configured. As far as I know, this is already true for the PC, not sure about other machines. But maybe we really should treat that as a problem of qdev/QOM, which should provide a mechanism to set options for automatically created devices rather than relying on subsystem-specific ways (like -net or -drive) to bypass the normal qdev configuration. Kevin ^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2018-04-24 19:45 UTC | newest] Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-03-08 8:26 [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) Thomas Huth 2017-03-08 10:03 ` Peter Maydell 2017-03-08 11:22 ` Thomas Huth 2017-03-08 11:24 ` Daniel P. Berrange 2017-03-09 12:33 ` Markus Armbruster 2017-03-09 2:21 ` Jason Wang 2017-03-09 8:50 ` Thomas Huth 2017-03-09 9:53 ` Jason Wang 2017-03-09 10:20 ` Yongbok Kim 2017-03-10 11:07 ` Jason Wang 2017-03-10 11:22 ` Peter Maydell 2017-03-10 11:53 ` Thomas Huth 2017-03-10 11:58 ` Yongbok Kim 2018-04-24 19:45 ` Philippe Mathieu-Daudé 2017-03-09 10:11 ` [Qemu-devel] external snapshots freezes block device since qemu 2.8 Piotr Rybicki 2017-03-09 12:26 ` Dr. David Alan Gilbert 2017-04-05 22:18 ` John Snow 2017-04-06 9:25 ` Dr. David Alan Gilbert 2017-03-10 14:49 ` Kashyap Chamarthy 2017-03-10 15:44 ` Piotr Rybicki 2017-03-08 10:20 ` [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) Daniel P. Berrange 2017-03-08 11:19 ` Gerd Hoffmann 2017-04-12 13:47 ` Marc-André Lureau 2017-04-12 14:10 ` Gerd Hoffmann 2017-03-09 16:00 ` Kevin Wolf 2017-03-24 22:10 ` John Snow 2017-03-27 8:06 ` Thomas Huth 2017-03-27 12:01 ` Stefan Hajnoczi 2017-03-27 12:49 ` Peter Maydell 2017-04-03 14:19 ` Stefan Hajnoczi 2017-04-11 12:53 ` Markus Armbruster 2017-04-18 9:51 ` Stefan Hajnoczi 2017-04-18 11:57 ` Gerd Hoffmann 2017-04-18 17:18 ` John Snow 2017-04-19 5:53 ` Markus Armbruster 2017-04-19 10:35 ` Gerd Hoffmann 2017-04-19 10:15 ` Gerd Hoffmann 2017-04-19 23:08 ` John Snow 2017-04-20 5:40 ` Gerd Hoffmann 2017-04-20 11:10 ` Philippe Mathieu-Daudé 2017-03-27 12:56 ` [Qemu-devel] Deprecating the -net option (was: What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces)) Thomas Huth 2017-03-27 13:09 ` [Qemu-devel] Deprecating the -net option Thomas Huth 2017-03-27 15:04 ` Paolo Bonzini 2017-03-27 19:04 ` [Qemu-devel] What's the next QEMU version after 2.9 ? (or: when is a good point in time to get rid of old interfaces) John Snow 2017-03-27 19:46 ` Thomas Huth 2017-03-29 16:21 ` [Qemu-devel] Deprecating old machine types Thomas Huth 2017-03-29 16:46 ` Dr. David Alan Gilbert 2017-03-29 16:54 ` Thomas Huth 2017-03-29 16:58 ` Paolo Bonzini 2017-03-29 21:42 ` Michael S. Tsirkin 2017-03-30 8:04 ` Gerd Hoffmann 2017-03-28 17:18 ` [Qemu-devel] Deprecating the -drive option is a good point in time to get rid of old interfaces) Kevin Wolf
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.