KVM call for agenda for 2022-01-25

KVM call for agenda for 2022-01-25

[Juan Quintela]

Hi

Please, send any topic that you are interested in covering.

This week we have a continuation of 2 weeks ago call to discuss how to
enable creation of machines from QMP sooner on the boot.

There was already a call about this 2 weeks ago where we didn't finished
everything.
I have been on vacation last week and I haven't been able to send a
"kind of resume" of the call.

Basically what we need is:
- being able to create machines sooner that we are today
- being able to change the devices that are in the boards, in
  particular, we need to be able to create a board deciding what devices
  it has and how they are connected without recompiling qemu.
  This means to launch QMP sooner that we do today.
- Several options was proposed:
  - create a new binary that only allows QMP machine creation.
    and continue having the old command line
  - create a new binary, and change current HMP/command line to just
    call this new binary.  This way we make sure that everything can be
    done through QMP.
  - stay with only one binary but change it so we can call QMP sooner.
- There is agreement that we need to be able to call QMP sooner.
- There is NO agreement about how the best way to proceed:
  * We don't want this to be a multiyear effort, i.e. we want something
    that can be used relatively soon (this means that using only one
    binary can be tricky).
  * If we start with a new binary that only allows qmp and we wait until
    everything has been ported to QMP, it can take forever, and during
    that time we have to maintain two binaries.
  * Getting a new binary lets us to be more agreessive about what we can
    remove/change. i.e. easier experimentation.
  * Management Apps will only use QMP, not the command line, or they
    even use libvirt and don't care at all about qemu.  So it appears
    that HMP is only used for developers, so we can be loose about
    backwards compatibility. I.e. if we allow the same functionality,
    but the syntax is different, we don't care.

Discussion was longer, but it was difficult to take notes and as I said,
the only thing that appears that everybody agrees is that we need an
agreement about what is the plan to go there.

After discussions on the QEMU Summit, we are going to have always open a
KVM call where you can add topics.

 Call details:

By popular demand, a google calendar public entry with it

  https://www.google.com/calendar/embed?src=dG9iMXRqcXAzN3Y4ZXZwNzRoMHE4a3BqcXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ

(Let me know if you have any problems with the calendar entry.  I just
gave up about getting right at the same time CEST, CET, EDT and DST).

If you need phone number details,  contact me privately

Thanks, Juan.

Re: KVM call for agenda for 2022-01-25

[Markus Armbruster]

Juan Quintela <quintela@redhat.com> writes:

> Hi
>
> Please, send any topic that you are interested in covering.
>
> This week we have a continuation of 2 weeks ago call to discuss how to
> enable creation of machines from QMP sooner on the boot.
>
> There was already a call about this 2 weeks ago where we didn't finished
> everything.
> I have been on vacation last week and I haven't been able to send a
> "kind of resume" of the call.
>
> Basically what we need is:
> - being able to create machines sooner that we are today
> - being able to change the devices that are in the boards, in
>   particular, we need to be able to create a board deciding what devices
>   it has and how they are connected without recompiling qemu.
>   This means to launch QMP sooner that we do today.
> - Several options was proposed:
>   - create a new binary that only allows QMP machine creation.
>     and continue having the old command line
>   - create a new binary, and change current HMP/command line to just
>     call this new binary.  This way we make sure that everything can be
>     done through QMP.
>   - stay with only one binary but change it so we can call QMP sooner.
> - There is agreement that we need to be able to call QMP sooner.
> - There is NO agreement about how the best way to proceed:
>   * We don't want this to be a multiyear effort, i.e. we want something
>     that can be used relatively soon (this means that using only one
>     binary can be tricky).
>   * If we start with a new binary that only allows qmp and we wait until
>     everything has been ported to QMP, it can take forever, and during
>     that time we have to maintain two binaries.
>   * Getting a new binary lets us to be more agreessive about what we can
>     remove/change. i.e. easier experimentation.
>   * Management Apps will only use QMP, not the command line, or they
>     even use libvirt and don't care at all about qemu.  So it appears
>     that HMP is only used for developers, so we can be loose about
>     backwards compatibility. I.e. if we allow the same functionality,
>     but the syntax is different, we don't care.
>
> Discussion was longer, but it was difficult to take notes and as I said,
> the only thing that appears that everybody agrees is that we need an
> agreement about what is the plan to go there.
>
> After discussions on the QEMU Summit, we are going to have always open a
> KVM call where you can add topics.
>
>  Call details:
>
> By popular demand, a google calendar public entry with it
>
>   https://www.google.com/calendar/embed?src=dG9iMXRqcXAzN3Y4ZXZwNzRoMHE4a3BqcXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ
>
> (Let me know if you have any problems with the calendar entry.  I just
> gave up about getting right at the same time CEST, CET, EDT and DST).

https://wiki.qemu.org/Contribute claims the call is at

    $ date -d 'TZ="America/New_York" Tuesday 10:00 am'
    Tue Jan 25 16:00:00 CET 2022

Is that correct?

> If you need phone number details,  contact me privately
>
> Thanks, Juan.

Re: KVM call for agenda for 2022-01-25

[Philippe Mathieu-Daudé via]

On 1/25/22 12:36, Markus Armbruster wrote:
> Juan Quintela <quintela@redhat.com> writes:
> 
>> Hi
>>
>> Please, send any topic that you are interested in covering.
>>
>> This week we have a continuation of 2 weeks ago call to discuss how to
>> enable creation of machines from QMP sooner on the boot.
>>
>> There was already a call about this 2 weeks ago where we didn't finished
>> everything.
>> I have been on vacation last week and I haven't been able to send a
>> "kind of resume" of the call.
>>
>> Basically what we need is:
>> - being able to create machines sooner that we are today
>> - being able to change the devices that are in the boards, in
>>   particular, we need to be able to create a board deciding what devices
>>   it has and how they are connected without recompiling qemu.
>>   This means to launch QMP sooner that we do today.
>> - Several options was proposed:
>>   - create a new binary that only allows QMP machine creation.
>>     and continue having the old command line
>>   - create a new binary, and change current HMP/command line to just
>>     call this new binary.  This way we make sure that everything can be
>>     done through QMP.
>>   - stay with only one binary but change it so we can call QMP sooner.
>> - There is agreement that we need to be able to call QMP sooner.
>> - There is NO agreement about how the best way to proceed:
>>   * We don't want this to be a multiyear effort, i.e. we want something
>>     that can be used relatively soon (this means that using only one
>>     binary can be tricky).
>>   * If we start with a new binary that only allows qmp and we wait until
>>     everything has been ported to QMP, it can take forever, and during
>>     that time we have to maintain two binaries.
>>   * Getting a new binary lets us to be more agreessive about what we can
>>     remove/change. i.e. easier experimentation.
>>   * Management Apps will only use QMP, not the command line, or they
>>     even use libvirt and don't care at all about qemu.  So it appears
>>     that HMP is only used for developers, so we can be loose about
>>     backwards compatibility. I.e. if we allow the same functionality,
>>     but the syntax is different, we don't care.
>>
>> Discussion was longer, but it was difficult to take notes and as I said,
>> the only thing that appears that everybody agrees is that we need an
>> agreement about what is the plan to go there.
>>
>> After discussions on the QEMU Summit, we are going to have always open a
>> KVM call where you can add topics.
>>
>>  Call details:
>>
>> By popular demand, a google calendar public entry with it
>>
>>   https://www.google.com/calendar/embed?src=dG9iMXRqcXAzN3Y4ZXZwNzRoMHE4a3BqcXNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ
>>
>> (Let me know if you have any problems with the calendar entry.  I just
>> gave up about getting right at the same time CEST, CET, EDT and DST).
> 
> https://wiki.qemu.org/Contribute claims the call is at
> 
>     $ date -d 'TZ="America/New_York" Tuesday 10:00 am'
>     Tue Jan 25 16:00:00 CET 2022
> 
> Is that correct?

This was incorrect and now fixed, thanks!

Phil.