[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)

[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]

 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

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)

[Peter Maydell]

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

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)

[Thomas Huth]

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

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)

[Daniel P. Berrange]

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

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)

[Markus Armbruster]

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

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)

[Jason Wang]

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

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)

[Thomas Huth]

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

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)

[Jason Wang]

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

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)

[Yongbok Kim]

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

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)

[Jason Wang]

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

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)

[Peter Maydell]

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

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)

[Thomas Huth]

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

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)

[Yongbok Kim]

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

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)

[Philippe Mathieu-Daudé]

[-- 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 --]

[Qemu-devel] external snapshots freezes block device since qemu 2.8

[Piotr Rybicki]

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

Re: [Qemu-devel] external snapshots freezes block device since qemu 2.8

[Dr. David Alan Gilbert]

* 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

Re: [Qemu-devel] external snapshots freezes block device since qemu 2.8

[John Snow]

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?

Re: [Qemu-devel] external snapshots freezes block device since qemu 2.8

[Dr. David Alan Gilbert]

* 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

Re: [Qemu-devel] external snapshots freezes block device since qemu 2.8

[Kashyap Chamarthy]

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

Re: [Qemu-devel] external snapshots freezes block device since qemu 2.8

[Piotr Rybicki]

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

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)

[Daniel P. Berrange]

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

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)

[Gerd Hoffmann]

  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

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)

[Marc-André Lureau]

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

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)

[Gerd Hoffmann]

  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

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)

[Kevin Wolf]

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

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)

[John Snow]

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

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)

[Thomas Huth]

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

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)

[Stefan Hajnoczi]

[-- 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 --]

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)

[Peter Maydell]

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

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)

[Stefan Hajnoczi]

[-- 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 --]

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)

[Markus Armbruster]

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.

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)

[Stefan Hajnoczi]

[-- 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 --]

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)

[Gerd Hoffmann]

  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

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)

[John Snow]

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
> 

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)

[Markus Armbruster]

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.

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)

[Gerd Hoffmann]

  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

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)

[Gerd Hoffmann]

  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

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)

[John Snow]

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
> 

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)

[Gerd Hoffmann]

  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

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)

[Philippe Mathieu-Daudé]

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

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

[Thomas Huth]

[-- 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 --]

Re: [Qemu-devel] Deprecating the -net option

[Thomas Huth]

[-- 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 --]

Re: [Qemu-devel] Deprecating the -net option

[Paolo Bonzini]

[-- 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 --]

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)

[John Snow]

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

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)

[Thomas Huth]

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

Re: [Qemu-devel] Deprecating old machine types

[Thomas Huth]

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

Re: [Qemu-devel] Deprecating old machine types

[Dr. David Alan Gilbert]

* 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

Re: [Qemu-devel] Deprecating old machine types

[Thomas Huth]

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

Re: [Qemu-devel] Deprecating old machine types

[Paolo Bonzini]

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

Re: [Qemu-devel] Deprecating old machine types

[Michael S. Tsirkin]

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

Re: [Qemu-devel] Deprecating old machine types

[Gerd Hoffmann]

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

[Qemu-devel] Deprecating the -drive option is a good point in time to get rid of old interfaces)

[Kevin Wolf]

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