[Qemu-devel] feature idea: allow user to run custom scripts

[Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

Would you be open to a feature that allows the user to select and run a custom file that has commands in it that would run in the monitor? 

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Peter Maydell]

On 27 September 2015 at 04:39, Programmingkid <programmingkidx@gmail.com> wrote:
> Would you be open to a feature that allows the user to select
> and run a custom file that has commands in it that would run
> in the monitor?

Sounds like a VM management layer feature.

-- PMM

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Peter Crosthwaite]

On Sun, Sep 27, 2015 at 3:13 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 27 September 2015 at 04:39, Programmingkid <programmingkidx@gmail.com> wrote:
>> Would you be open to a feature that allows the user to select
>> and run a custom file that has commands in it that would run
>> in the monitor?
>
> Sounds like a VM management layer feature.
>

Should -monitor file:/foo/bar do something like this?

I notice the file: backend works for output only but is there a
chardev way of streaming a file as an input to a chardev frontend?

Regards,
Peter

> -- PMM
>

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Sep 27, 2015, at 2:53 PM, Peter Crosthwaite wrote:

> On Sun, Sep 27, 2015 at 3:13 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 27 September 2015 at 04:39, Programmingkid <programmingkidx@gmail.com> wrote:
>>> Would you be open to a feature that allows the user to select
>>> and run a custom file that has commands in it that would run
>>> in the monitor?
>> 
>> Sounds like a VM management layer feature.
>> 
> 
> Should -monitor file:/foo/bar do something like this?

If you are saying this command line argument loads monitor commands,
then it would only work when QEMU is first started. The feature I want
would work anytime during the running of QEMU. 

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Michael Roth]

Quoting Programmingkid (2015-09-27 20:49:24)
> 
> On Sep 27, 2015, at 2:53 PM, Peter Crosthwaite wrote:
> 
> > On Sun, Sep 27, 2015 at 3:13 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> >> On 27 September 2015 at 04:39, Programmingkid <programmingkidx@gmail.com> wrote:
> >>> Would you be open to a feature that allows the user to select
> >>> and run a custom file that has commands in it that would run
> >>> in the monitor?
> >> 
> >> Sounds like a VM management layer feature.
> >> 
> > 
> > Should -monitor file:/foo/bar do something like this?
> 
> If you are saying this command line argument loads monitor commands,
> then it would only work when QEMU is first started. The feature I want
> would work anytime during the running of QEMU. 

For that sort of flexibility I think writing commands to a socket via
a script/program is simple enough that an additional interface doesn't
seem worthwhile. Even our qtest unit tests use this approach. Plus you
get the flexibility of a being able to branch based on the return
value of commands (error-handling, stateful commands, incorporating
output from a serial console, etc.). It seems like a nice feature but
it's vastly inferior to what's possible with an external driver.

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Sep 27, 2015, at 10:30 PM, Michael Roth wrote:

> Quoting Programmingkid (2015-09-27 20:49:24)
>> 
>> On Sep 27, 2015, at 2:53 PM, Peter Crosthwaite wrote:
>> 
>>> On Sun, Sep 27, 2015 at 3:13 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>>>> On 27 September 2015 at 04:39, Programmingkid <programmingkidx@gmail.com> wrote:
>>>>> Would you be open to a feature that allows the user to select
>>>>> and run a custom file that has commands in it that would run
>>>>> in the monitor?
>>>> 
>>>> Sounds like a VM management layer feature.
>>>> 
>>> 
>>> Should -monitor file:/foo/bar do something like this?
>> 
>> If you are saying this command line argument loads monitor commands,
>> then it would only work when QEMU is first started. The feature I want
>> would work anytime during the running of QEMU. 
> 
> For that sort of flexibility I think writing commands to a socket via
> a script/program is simple enough that an additional interface doesn't
> seem worthwhile. Even our qtest unit tests use this approach. Plus you
> get the flexibility of a being able to branch based on the return
> value of commands (error-handling, stateful commands, incorporating
> output from a serial console, etc.). It seems like a nice feature but
> it's vastly inferior to what's possible with an external driver.

How many people know how to communicate with QEMU via a socket?
How do you even do it? It doesn't sound very easy to do. A menu item
that displays a file open dialog is very easy to use. The user just selects
a file and QEMU loads and runs all the commands in it. This feature
would make QEMU easier to use. It would also make QEMU easily
expandable. Typing long commands in the monitor is difficult and
error prone. Saving these commands in a file would make it much
easier for the user. An example command someone could put in a
file is sending Control-Alt-Delete to the emulator. Another command
could be mounting an image file. This feature would make things
much easier for the user.

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Markus Armbruster]

Programmingkid <programmingkidx@gmail.com> writes:

> On Sep 27, 2015, at 10:30 PM, Michael Roth wrote:
>
>> Quoting Programmingkid (2015-09-27 20:49:24)
>>> 
>>> On Sep 27, 2015, at 2:53 PM, Peter Crosthwaite wrote:
>>> 
>>>> On Sun, Sep 27, 2015 at 3:13 AM, Peter Maydell
>>>> <peter.maydell@linaro.org> wrote:
>>>>> On 27 September 2015 at 04:39, Programmingkid
>>>>> <programmingkidx@gmail.com> wrote:
>>>>>> Would you be open to a feature that allows the user to select
>>>>>> and run a custom file that has commands in it that would run
>>>>>> in the monitor?
>>>>> 
>>>>> Sounds like a VM management layer feature.
>>>>> 
>>>> 
>>>> Should -monitor file:/foo/bar do something like this?
>>> 
>>> If you are saying this command line argument loads monitor commands,
>>> then it would only work when QEMU is first started. The feature I want
>>> would work anytime during the running of QEMU. 
>> 
>> For that sort of flexibility I think writing commands to a socket via
>> a script/program is simple enough that an additional interface doesn't
>> seem worthwhile. Even our qtest unit tests use this approach. Plus you
>> get the flexibility of a being able to branch based on the return
>> value of commands (error-handling, stateful commands, incorporating
>> output from a serial console, etc.). It seems like a nice feature but
>> it's vastly inferior to what's possible with an external driver.
>
> How many people know how to communicate with QEMU via a socket?
> How do you even do it? It doesn't sound very easy to do.

It's easy, as QEMU command line goes:

    -qmp unix:test-hmp,server,nowait

This is syntactic sugar for something like

    -chardev socket,id=compat_monitor1,path=sock-qmp,server=on,wait=off
    -mon mode=control,chardev=compat_monitor1

The long form is more flexible.  If you use it, don't use
id=compat_monitor1, obviously.

Easier on the eyes as configuration file for -readconfig:

    [chardev "qmp"]
      backend = "socket"
      path = "sock-qmp"
      server = "on"
      wait = "off"

    [mon "qmp"]
      mode = "control"
      chardev = "qmp"

>                                                          A menu item
> that displays a file open dialog is very easy to use. The user just selects
> a file and QEMU loads and runs all the commands in it. This feature
> would make QEMU easier to use. It would also make QEMU easily
> expandable. Typing long commands in the monitor is difficult and
> error prone. Saving these commands in a file would make it much
> easier for the user. An example command someone could put in a
> file is sending Control-Alt-Delete to the emulator. Another command
> could be mounting an image file. This feature would make things
> much easier for the user.

You didn't mention you're talking about a *GUI* feature.

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:

> Programmingkid <programmingkidx@gmail.com> writes:
> 
>> On Sep 27, 2015, at 10:30 PM, Michael Roth wrote:
>> 
>>> Quoting Programmingkid (2015-09-27 20:49:24)
>>>> 
>>>> On Sep 27, 2015, at 2:53 PM, Peter Crosthwaite wrote:
>>>> 
>>>>> On Sun, Sep 27, 2015 at 3:13 AM, Peter Maydell
>>>>> <peter.maydell@linaro.org> wrote:
>>>>>> On 27 September 2015 at 04:39, Programmingkid
>>>>>> <programmingkidx@gmail.com> wrote:
>>>>>>> Would you be open to a feature that allows the user to select
>>>>>>> and run a custom file that has commands in it that would run
>>>>>>> in the monitor?
>>>>>> 
>>>>>> Sounds like a VM management layer feature.
>>>>>> 
>>>>> 
>>>>> Should -monitor file:/foo/bar do something like this?
>>>> 
>>>> If you are saying this command line argument loads monitor commands,
>>>> then it would only work when QEMU is first started. The feature I want
>>>> would work anytime during the running of QEMU. 
>>> 
>>> For that sort of flexibility I think writing commands to a socket via
>>> a script/program is simple enough that an additional interface doesn't
>>> seem worthwhile. Even our qtest unit tests use this approach. Plus you
>>> get the flexibility of a being able to branch based on the return
>>> value of commands (error-handling, stateful commands, incorporating
>>> output from a serial console, etc.). It seems like a nice feature but
>>> it's vastly inferior to what's possible with an external driver.
>> 
>> How many people know how to communicate with QEMU via a socket?
>> How do you even do it? It doesn't sound very easy to do.
> 
> It's easy, as QEMU command line goes:
> 
>    -qmp unix:test-hmp,server,nowait
> 
> This is syntactic sugar for something like
> 
>    -chardev socket,id=compat_monitor1,path=sock-qmp,server=on,wait=off
>    -mon mode=control,chardev=compat_monitor1
> 
> The long form is more flexible.  If you use it, don't use
> id=compat_monitor1, obviously.
> 
> Easier on the eyes as configuration file for -readconfig:
> 
>    [chardev "qmp"]
>      backend = "socket"
>      path = "sock-qmp"
>      server = "on"
>      wait = "off"
> 
>    [mon "qmp"]
>      mode = "control"
>      chardev = "qmp"
> 
>>                                                         A menu item
>> that displays a file open dialog is very easy to use. The user just selects
>> a file and QEMU loads and runs all the commands in it. This feature
>> would make QEMU easier to use. It would also make QEMU easily
>> expandable. Typing long commands in the monitor is difficult and
>> error prone. Saving these commands in a file would make it much
>> easier for the user. An example command someone could put in a
>> file is sending Control-Alt-Delete to the emulator. Another command
>> could be mounting an image file. This feature would make things
>> much easier for the user.
> 
> You didn't mention you're talking about a *GUI* feature.

I'm thinking it would be easier to send in the patch rather than talk about 
what this feature could be. 

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Peter Maydell]

On 28 September 2015 at 20:43, Programmingkid <programmingkidx@gmail.com> wrote:
>
> On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
>
>> Programmingkid <programmingkidx@gmail.com> writes:
>>>                                                         A menu item
>>> that displays a file open dialog is very easy to use. The user just selects
>>> a file and QEMU loads and runs all the commands in it. This feature
>>> would make QEMU easier to use. It would also make QEMU easily
>>> expandable. Typing long commands in the monitor is difficult and
>>> error prone. Saving these commands in a file would make it much
>>> easier for the user. An example command someone could put in a
>>> file is sending Control-Alt-Delete to the emulator. Another command
>>> could be mounting an image file. This feature would make things
>>> much easier for the user.
>>
>> You didn't mention you're talking about a *GUI* feature.
>
> I'm thinking it would be easier to send in the patch rather than talk about
> what this feature could be.

I think Markus and I are trying to save you that effort by
pointing out that this is a VM management layer feature,
not a core QEMU feature.

thanks
-- PMM

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Sep 28, 2015, at 3:44 PM, Peter Maydell wrote:

> On 28 September 2015 at 20:43, Programmingkid <programmingkidx@gmail.com> wrote:
>> 
>> On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
>> 
>>> Programmingkid <programmingkidx@gmail.com> writes:
>>>>                                                        A menu item
>>>> that displays a file open dialog is very easy to use. The user just selects
>>>> a file and QEMU loads and runs all the commands in it. This feature
>>>> would make QEMU easier to use. It would also make QEMU easily
>>>> expandable. Typing long commands in the monitor is difficult and
>>>> error prone. Saving these commands in a file would make it much
>>>> easier for the user. An example command someone could put in a
>>>> file is sending Control-Alt-Delete to the emulator. Another command
>>>> could be mounting an image file. This feature would make things
>>>> much easier for the user.
>>> 
>>> You didn't mention you're talking about a *GUI* feature.
>> 
>> I'm thinking it would be easier to send in the patch rather than talk about
>> what this feature could be.
> 
> I think Markus and I are trying to save you that effort by
> pointing out that this is a VM management layer feature,
> not a core QEMU feature.

It would be a simple patch that would be short and sweet. The possibilities would
be endless with what the user could use this feature for. I will not implement it  :(

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Dr. David Alan Gilbert]

* Peter Maydell (peter.maydell@linaro.org) wrote:
> On 28 September 2015 at 20:43, Programmingkid <programmingkidx@gmail.com> wrote:
> >
> > On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
> >
> >> Programmingkid <programmingkidx@gmail.com> writes:
> >>>                                                         A menu item
> >>> that displays a file open dialog is very easy to use. The user just selects
> >>> a file and QEMU loads and runs all the commands in it. This feature
> >>> would make QEMU easier to use. It would also make QEMU easily
> >>> expandable. Typing long commands in the monitor is difficult and
> >>> error prone. Saving these commands in a file would make it much
> >>> easier for the user. An example command someone could put in a
> >>> file is sending Control-Alt-Delete to the emulator. Another command
> >>> could be mounting an image file. This feature would make things
> >>> much easier for the user.
> >>
> >> You didn't mention you're talking about a *GUI* feature.
> >
> > I'm thinking it would be easier to send in the patch rather than talk about
> > what this feature could be.
> 
> I think Markus and I are trying to save you that effort by
> pointing out that this is a VM management layer feature,
> not a core QEMU feature.

OK, so I'm going to agree with Programmingkid here.
I think this would be a useful feature to have in QEMU; I've
got gratuitous hacks in some of my test scripts that work
around it not being there.

I think there are two possible things, both of which seem fairly
easy:
  1) Add a -chardev from file that works in this case
     (I don't think the current chardev file works does it?)

  2) A 'source' like command.

Dave

> 
> thanks
> -- PMM
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Sep 29, 2015, at 9:11 AM, Dr. David Alan Gilbert wrote:

> * Peter Maydell (peter.maydell@linaro.org) wrote:
>> On 28 September 2015 at 20:43, Programmingkid <programmingkidx@gmail.com> wrote:
>>> 
>>> On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
>>> 
>>>> Programmingkid <programmingkidx@gmail.com> writes:
>>>>>                                                        A menu item
>>>>> that displays a file open dialog is very easy to use. The user just selects
>>>>> a file and QEMU loads and runs all the commands in it. This feature
>>>>> would make QEMU easier to use. It would also make QEMU easily
>>>>> expandable. Typing long commands in the monitor is difficult and
>>>>> error prone. Saving these commands in a file would make it much
>>>>> easier for the user. An example command someone could put in a
>>>>> file is sending Control-Alt-Delete to the emulator. Another command
>>>>> could be mounting an image file. This feature would make things
>>>>> much easier for the user.
>>>> 
>>>> You didn't mention you're talking about a *GUI* feature.
>>> 
>>> I'm thinking it would be easier to send in the patch rather than talk about
>>> what this feature could be.
>> 
>> I think Markus and I are trying to save you that effort by
>> pointing out that this is a VM management layer feature,
>> not a core QEMU feature.
> 
> OK, so I'm going to agree with Programmingkid here.
> I think this would be a useful feature to have in QEMU; I've
> got gratuitous hacks in some of my test scripts that work
> around it not being there.
> 
> I think there are two possible things, both of which seem fairly
> easy:
>  1) Add a -chardev from file that works in this case
>     (I don't think the current chardev file works does it?)
> 
>  2) A 'source' like command.

My idea was to just send the command to the monitor as if the user typed them up.

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Dr. David Alan Gilbert]

* Programmingkid (programmingkidx@gmail.com) wrote:
> 
> On Sep 29, 2015, at 9:11 AM, Dr. David Alan Gilbert wrote:
> 
> > * Peter Maydell (peter.maydell@linaro.org) wrote:
> >> On 28 September 2015 at 20:43, Programmingkid <programmingkidx@gmail.com> wrote:
> >>> 
> >>> On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
> >>> 
> >>>> Programmingkid <programmingkidx@gmail.com> writes:
> >>>>>                                                        A menu item
> >>>>> that displays a file open dialog is very easy to use. The user just selects
> >>>>> a file and QEMU loads and runs all the commands in it. This feature
> >>>>> would make QEMU easier to use. It would also make QEMU easily
> >>>>> expandable. Typing long commands in the monitor is difficult and
> >>>>> error prone. Saving these commands in a file would make it much
> >>>>> easier for the user. An example command someone could put in a
> >>>>> file is sending Control-Alt-Delete to the emulator. Another command
> >>>>> could be mounting an image file. This feature would make things
> >>>>> much easier for the user.
> >>>> 
> >>>> You didn't mention you're talking about a *GUI* feature.
> >>> 
> >>> I'm thinking it would be easier to send in the patch rather than talk about
> >>> what this feature could be.
> >> 
> >> I think Markus and I are trying to save you that effort by
> >> pointing out that this is a VM management layer feature,
> >> not a core QEMU feature.
> > 
> > OK, so I'm going to agree with Programmingkid here.
> > I think this would be a useful feature to have in QEMU; I've
> > got gratuitous hacks in some of my test scripts that work
> > around it not being there.
> > 
> > I think there are two possible things, both of which seem fairly
> > easy:
> >  1) Add a -chardev from file that works in this case
> >     (I don't think the current chardev file works does it?)
> > 
> >  2) A 'source' like command.
> 
> My idea was to just send the command to the monitor as if the user typed them up.

Yeh, I'm not sure how easily that'll be to glue into the monitor,
because the monitor has a parser that's fed somehow from the chardev.

Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Peter Maydell]

On 29 September 2015 at 14:11, Dr. David Alan Gilbert
<dgilbert@redhat.com> wrote:
> * Peter Maydell (peter.maydell@linaro.org) wrote:
>> On 28 September 2015 at 20:43, Programmingkid <programmingkidx@gmail.com> wrote:
>> >
>> > On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
>> >> You didn't mention you're talking about a *GUI* feature.
>> >
>> > I'm thinking it would be easier to send in the patch rather than talk about
>> > what this feature could be.
>>
>> I think Markus and I are trying to save you that effort by
>> pointing out that this is a VM management layer feature,
>> not a core QEMU feature.
>
> OK, so I'm going to agree with Programmingkid here.
> I think this would be a useful feature to have in QEMU; I've
> got gratuitous hacks in some of my test scripts that work
> around it not being there.
>
> I think there are two possible things, both of which seem fairly
> easy:
>   1) Add a -chardev from file that works in this case
>      (I don't think the current chardev file works does it?)
>
>   2) A 'source' like command.

Yeah, these are both plausible. Neither of them are GUI features,
though...

-- PMM

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Dr. David Alan Gilbert]

* Peter Maydell (peter.maydell@linaro.org) wrote:
> On 29 September 2015 at 14:11, Dr. David Alan Gilbert
> <dgilbert@redhat.com> wrote:
> > * Peter Maydell (peter.maydell@linaro.org) wrote:
> >> On 28 September 2015 at 20:43, Programmingkid <programmingkidx@gmail.com> wrote:
> >> >
> >> > On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
> >> >> You didn't mention you're talking about a *GUI* feature.
> >> >
> >> > I'm thinking it would be easier to send in the patch rather than talk about
> >> > what this feature could be.
> >>
> >> I think Markus and I are trying to save you that effort by
> >> pointing out that this is a VM management layer feature,
> >> not a core QEMU feature.
> >
> > OK, so I'm going to agree with Programmingkid here.
> > I think this would be a useful feature to have in QEMU; I've
> > got gratuitous hacks in some of my test scripts that work
> > around it not being there.
> >
> > I think there are two possible things, both of which seem fairly
> > easy:
> >   1) Add a -chardev from file that works in this case
> >      (I don't think the current chardev file works does it?)
> >
> >   2) A 'source' like command.
> 
> Yeah, these are both plausible. Neither of them are GUI features,
> though...

Well, I don't use the GTK gui; I can see that those who do
might want features in it.

Dave

> 
> -- PMM
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Paolo Bonzini]

On 29/09/2015 15:23, Dr. David Alan Gilbert wrote:
> Yeh, I'm not sure how easily that'll be to glue into the monitor,
> because the monitor has a parser that's fed somehow from the chardev.

See how qmp_human_monitor_command is implemented.  It basically bypasses
the chardev part of the monitor.

Because this "source" command would be HMP-only, it wouldn't even need
to create a new monitor, save/restore cur_mon and fetch the output from
hmp.outbuf.  It could just read lines and pass them to
handle_hmp_command (possibly after removing newlines preceded by a
backslash?).

Paolo

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Markus Armbruster]

"Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:

> * Peter Maydell (peter.maydell@linaro.org) wrote:
>> On 29 September 2015 at 14:11, Dr. David Alan Gilbert
>> <dgilbert@redhat.com> wrote:
>> > * Peter Maydell (peter.maydell@linaro.org) wrote:
>> >> On 28 September 2015 at 20:43, Programmingkid
>> >> <programmingkidx@gmail.com> wrote:
>> >> >
>> >> > On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
>> >> >> You didn't mention you're talking about a *GUI* feature.
>> >> >
>> >> > I'm thinking it would be easier to send in the patch rather
>> >> > than talk about
>> >> > what this feature could be.
>> >>
>> >> I think Markus and I are trying to save you that effort by
>> >> pointing out that this is a VM management layer feature,
>> >> not a core QEMU feature.
>> >
>> > OK, so I'm going to agree with Programmingkid here.
>> > I think this would be a useful feature to have in QEMU; I've
>> > got gratuitous hacks in some of my test scripts that work
>> > around it not being there.
>> >
>> > I think there are two possible things, both of which seem fairly
>> > easy:
>> >   1) Add a -chardev from file that works in this case
>> >      (I don't think the current chardev file works does it?)

In general, character devices provide a bidirectional pipe, but -chardev
file is write-only.  I think you want -chardev pipe.  I don't use it
myself, because as socat user, I don't have to learn lesser tools :)

Here's how I use it.  Set up a local socket (any convenient
bidirectional pipe would do, actually).

Example: QMP

    # Configuration file for -readconfig
    [chardev "qmp"]
      backend = "socket"
      path = "sock-qmp"
      server = "on"
      wait = "off"

    [mon "qmp"]
      mode = "control"
      chardev = "qmp"

Example: HMP

    [chardev "hmp"]
      backend = "socket"
      path = "sock-hmp"
      server = "on"
      wait = "off"

    [mon "hmp"]
      mode = "readline"
      chardev = "hmp"

Then do stuff with it.

Example: interactive QMP

    $ socat UNIX:sock-qmp READLINE,history=$HOME/.qmp_history,prompt='QMP> '

Example: interactive HMP

    $ socat UNIX:sock-hmp READLINE,history=$HOME/.hmp_history

Arguably superior to our built-in not-quite readline monitor.

Example: send QMP input from a file, capture its output in a file

    $ socat UNIX:sock-qmp STDIO <input >output

>> >   2) A 'source' like command.

QMP?  The command would have to take a filename as argument, and return
a list of replies.  Probably stop on first failed command.  Pretty
useless for remote clients, because if you have to upload the file, you
can just as well send it down the QMP pipe.  Actually, that pretty much
applies to local clients, too.  Except perhaps for interactive use.  I
feel a QMP client geared for such use would be the appropriate home for
this feature.  We have some in scripts/qmp/.

I don't have an opinion on HMP right now.

>> Yeah, these are both plausible. Neither of them are GUI features,
>> though...
>
> Well, I don't use the GTK gui; I can see that those who do
> might want features in it.

GUI users want GUI features, of course.

In my opinion, QEMU should leave them to separate GUI shells, because
doing everything in QEMU distracts from our core mission and we don't
have GUI expertise[*].  One more point: building in the GUI is
problematic when you don't trust the guest, because then you really want
to run QEMU with least privileges.


[*] Short version of the argument, for the long one, see
Message-ID: <87oahn51ys.fsf@blackfin.pond.sub.org>
http://lists.gnu.org/archive/html/qemu-devel/2015-08/msg03916.html

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Dr. David Alan Gilbert]

* Markus Armbruster (armbru@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
> 
> > * Peter Maydell (peter.maydell@linaro.org) wrote:
> >> On 29 September 2015 at 14:11, Dr. David Alan Gilbert
> >> <dgilbert@redhat.com> wrote:
> >> > * Peter Maydell (peter.maydell@linaro.org) wrote:
> >> >> On 28 September 2015 at 20:43, Programmingkid
> >> >> <programmingkidx@gmail.com> wrote:
> >> >> >
> >> >> > On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
> >> >> >> You didn't mention you're talking about a *GUI* feature.
> >> >> >
> >> >> > I'm thinking it would be easier to send in the patch rather
> >> >> > than talk about
> >> >> > what this feature could be.
> >> >>
> >> >> I think Markus and I are trying to save you that effort by
> >> >> pointing out that this is a VM management layer feature,
> >> >> not a core QEMU feature.
> >> >
> >> > OK, so I'm going to agree with Programmingkid here.
> >> > I think this would be a useful feature to have in QEMU; I've
> >> > got gratuitous hacks in some of my test scripts that work
> >> > around it not being there.
> >> >
> >> > I think there are two possible things, both of which seem fairly
> >> > easy:
> >> >   1) Add a -chardev from file that works in this case
> >> >      (I don't think the current chardev file works does it?)
> 
> In general, character devices provide a bidirectional pipe, but -chardev
> file is write-only.  I think you want -chardev pipe.  I don't use it
> myself, because as socat user, I don't have to learn lesser tools :)
> 
> Here's how I use it.  Set up a local socket (any convenient
> bidirectional pipe would do, actually).
> 
> Example: QMP
> 
>     # Configuration file for -readconfig
>     [chardev "qmp"]
>       backend = "socket"
>       path = "sock-qmp"
>       server = "on"
>       wait = "off"
> 
>     [mon "qmp"]
>       mode = "control"
>       chardev = "qmp"
> 
> Example: HMP
> 
>     [chardev "hmp"]
>       backend = "socket"
>       path = "sock-hmp"
>       server = "on"
>       wait = "off"
> 
>     [mon "hmp"]
>       mode = "readline"
>       chardev = "hmp"
> 
> Then do stuff with it.
> 
> Example: interactive QMP
> 
>     $ socat UNIX:sock-qmp READLINE,history=$HOME/.qmp_history,prompt='QMP> '
> 
> Example: interactive HMP
> 
>     $ socat UNIX:sock-hmp READLINE,history=$HOME/.hmp_history
> 
> Arguably superior to our built-in not-quite readline monitor.
> 
> Example: send QMP input from a file, capture its output in a file
> 
>     $ socat UNIX:sock-qmp STDIO <input >output

Yes, this example is exactly why I want something less painful.
A -chardev file that allowed read/write would be ideal, to be able to read
a series of commands at startup.

> >> >   2) A 'source' like command.
> 
> QMP?  The command would have to take a filename as argument, and return
> a list of replies.  Probably stop on first failed command.  Pretty
> useless for remote clients, because if you have to upload the file, you
> can just as well send it down the QMP pipe.  Actually, that pretty much
> applies to local clients, too.  Except perhaps for interactive use.  I
> feel a QMP client geared for such use would be the appropriate home for
> this feature.  We have some in scripts/qmp/.
> 
> I don't have an opinion on HMP right now.

If QMP doesn't have a user for it fine; I'm just saying it would be useful
from my point of view in HMP.

> >> Yeah, these are both plausible. Neither of them are GUI features,
> >> though...
> >
> > Well, I don't use the GTK gui; I can see that those who do
> > might want features in it.
> 
> GUI users want GUI features, of course.
> 
> In my opinion, QEMU should leave them to separate GUI shells, because
> doing everything in QEMU distracts from our core mission and we don't
> have GUI expertise[*].  One more point: building in the GUI is
> problematic when you don't trust the guest, because then you really want
> to run QEMU with least privileges.

Given that we have a built in GUI then I can see people wanting to expand
it.

Dave

> 
> 
> [*] Short version of the argument, for the long one, see
> Message-ID: <87oahn51ys.fsf@blackfin.pond.sub.org>
> http://lists.gnu.org/archive/html/qemu-devel/2015-08/msg03916.html
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Peter Maydell]

On 30 September 2015 at 09:14, Dr. David Alan Gilbert
<dgilbert@redhat.com> wrote:
> * Markus Armbruster (armbru@redhat.com) wrote:
>> In my opinion, QEMU should leave them to separate GUI shells, because
>> doing everything in QEMU distracts from our core mission and we don't
>> have GUI expertise[*].  One more point: building in the GUI is
>> problematic when you don't trust the guest, because then you really want
>> to run QEMU with least privileges.
>
> Given that we have a built in GUI then I can see people wanting to expand
> it.

Right, but where do you draw the line? We clearly don't have the
active maintainer and review capacity to do anything serious with
"ui/" (MAINTAINERS lists everything except SPICE as Odd Fixes).

This is why I tend to agree with Markus' opinion here: we should
provide enough graphical UI to make raw QEMU minimally usable,
and leave further user-friendliness to other projects which have
more direct interest in that.

If we had more regular contributors who were actively interested
in improving our UI layer my opinion might be different.

thanks
-- PMM

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Sep 30, 2015, at 6:53 AM, Peter Maydell wrote:

> On 30 September 2015 at 09:14, Dr. David Alan Gilbert
> <dgilbert@redhat.com> wrote:
>> * Markus Armbruster (armbru@redhat.com) wrote:
>>> In my opinion, QEMU should leave them to separate GUI shells, because
>>> doing everything in QEMU distracts from our core mission and we don't
>>> have GUI expertise[*].  One more point: building in the GUI is
>>> problematic when you don't trust the guest, because then you really want
>>> to run QEMU with least privileges.
>> 
>> Given that we have a built in GUI then I can see people wanting to expand
>> it.
> 
> Right, but where do you draw the line? We clearly don't have the
> active maintainer and review capacity to do anything serious with
> "ui/" (MAINTAINERS lists everything except SPICE as Odd Fixes).

This could be changed. 

> This is why I tend to agree with Markus' opinion here: we should
> provide enough graphical UI to make raw QEMU minimally usable,
> and leave further user-friendliness to other projects which have
> more direct interest in that.
> 
> If we had more regular contributors who were actively interested
> in improving our UI layer my opinion might be different.

It is really hard for more contributors to come when the maintainers
keep discouraging them. 

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Markus Armbruster]

"Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:

> * Markus Armbruster (armbru@redhat.com) wrote:
>> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
>> 
>> > * Peter Maydell (peter.maydell@linaro.org) wrote:
>> >> On 29 September 2015 at 14:11, Dr. David Alan Gilbert
>> >> <dgilbert@redhat.com> wrote:
>> >> > * Peter Maydell (peter.maydell@linaro.org) wrote:
>> >> >> On 28 September 2015 at 20:43, Programmingkid
>> >> >> <programmingkidx@gmail.com> wrote:
>> >> >> >
>> >> >> > On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
>> >> >> >> You didn't mention you're talking about a *GUI* feature.
>> >> >> >
>> >> >> > I'm thinking it would be easier to send in the patch rather
>> >> >> > than talk about
>> >> >> > what this feature could be.
>> >> >>
>> >> >> I think Markus and I are trying to save you that effort by
>> >> >> pointing out that this is a VM management layer feature,
>> >> >> not a core QEMU feature.
>> >> >
>> >> > OK, so I'm going to agree with Programmingkid here.
>> >> > I think this would be a useful feature to have in QEMU; I've
>> >> > got gratuitous hacks in some of my test scripts that work
>> >> > around it not being there.
>> >> >
>> >> > I think there are two possible things, both of which seem fairly
>> >> > easy:
>> >> >   1) Add a -chardev from file that works in this case
>> >> >      (I don't think the current chardev file works does it?)
>> 
>> In general, character devices provide a bidirectional pipe, but -chardev
>> file is write-only.  I think you want -chardev pipe.  I don't use it
>> myself, because as socat user, I don't have to learn lesser tools :)
>> 
>> Here's how I use it.  Set up a local socket (any convenient
>> bidirectional pipe would do, actually).
>> 
>> Example: QMP
>> 
>>     # Configuration file for -readconfig
>>     [chardev "qmp"]
>>       backend = "socket"
>>       path = "sock-qmp"
>>       server = "on"
>>       wait = "off"
>> 
>>     [mon "qmp"]
>>       mode = "control"
>>       chardev = "qmp"
>> 
>> Example: HMP
>> 
>>     [chardev "hmp"]
>>       backend = "socket"
>>       path = "sock-hmp"
>>       server = "on"
>>       wait = "off"
>> 
>>     [mon "hmp"]
>>       mode = "readline"
>>       chardev = "hmp"
>> 
>> Then do stuff with it.
>> 
>> Example: interactive QMP
>> 
>>     $ socat UNIX:sock-qmp READLINE,history=$HOME/.qmp_history,prompt='QMP> '
>> 
>> Example: interactive HMP
>> 
>>     $ socat UNIX:sock-hmp READLINE,history=$HOME/.hmp_history
>> 
>> Arguably superior to our built-in not-quite readline monitor.
>> 
>> Example: send QMP input from a file, capture its output in a file
>> 
>>     $ socat UNIX:sock-qmp STDIO <input >output
>
> Yes, this example is exactly why I want something less painful.
> A -chardev file that allowed read/write would be ideal, to be able to read
> a series of commands at startup.

Have you tried -chardev pipe?  As I said, I don't use it myself, because
my "painful" setup is more flexible, and not painful at all once set up.

[...]

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Markus Armbruster]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 30 September 2015 at 09:14, Dr. David Alan Gilbert
> <dgilbert@redhat.com> wrote:
>> * Markus Armbruster (armbru@redhat.com) wrote:
>>> In my opinion, QEMU should leave them to separate GUI shells, because
>>> doing everything in QEMU distracts from our core mission and we don't
>>> have GUI expertise[*].  One more point: building in the GUI is
>>> problematic when you don't trust the guest, because then you really want
>>> to run QEMU with least privileges.
>>
>> Given that we have a built in GUI then I can see people wanting to expand
>> it.
>
> Right, but where do you draw the line? We clearly don't have the
> active maintainer and review capacity to do anything serious with
> "ui/" (MAINTAINERS lists everything except SPICE as Odd Fixes).
>
> This is why I tend to agree with Markus' opinion here: we should
> provide enough graphical UI to make raw QEMU minimally usable,
> and leave further user-friendliness to other projects which have
> more direct interest in that.
>
> If we had more regular contributors who were actively interested
> in improving our UI layer my opinion might be different.

Or not.

QEMU is a large project.  We can do what we do only because we managed
to set up a workable hierarchy of maintainers.

Still, adding more subsystems is not free.  Not even if they come with
ready-made, capable maintainers.

I'd rather spend our limited complexity credits on our core mission.  If
people come to us with a new target and a commitment to maintain it, we
don't want to say no.  That's because targets are core.

If people come to us to make QEMU compete with GUI-providing projects
sitting on top of QEMU, I want us to say no.

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Dr. David Alan Gilbert]

* Markus Armbruster (armbru@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
> 
> > * Markus Armbruster (armbru@redhat.com) wrote:
> >> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
> >> 
> >> > * Peter Maydell (peter.maydell@linaro.org) wrote:
> >> >> On 29 September 2015 at 14:11, Dr. David Alan Gilbert
> >> >> <dgilbert@redhat.com> wrote:
> >> >> > * Peter Maydell (peter.maydell@linaro.org) wrote:
> >> >> >> On 28 September 2015 at 20:43, Programmingkid
> >> >> >> <programmingkidx@gmail.com> wrote:
> >> >> >> >
> >> >> >> > On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
> >> >> >> >> You didn't mention you're talking about a *GUI* feature.
> >> >> >> >
> >> >> >> > I'm thinking it would be easier to send in the patch rather
> >> >> >> > than talk about
> >> >> >> > what this feature could be.
> >> >> >>
> >> >> >> I think Markus and I are trying to save you that effort by
> >> >> >> pointing out that this is a VM management layer feature,
> >> >> >> not a core QEMU feature.
> >> >> >
> >> >> > OK, so I'm going to agree with Programmingkid here.
> >> >> > I think this would be a useful feature to have in QEMU; I've
> >> >> > got gratuitous hacks in some of my test scripts that work
> >> >> > around it not being there.
> >> >> >
> >> >> > I think there are two possible things, both of which seem fairly
> >> >> > easy:
> >> >> >   1) Add a -chardev from file that works in this case
> >> >> >      (I don't think the current chardev file works does it?)
> >> 
> >> In general, character devices provide a bidirectional pipe, but -chardev
> >> file is write-only.  I think you want -chardev pipe.  I don't use it
> >> myself, because as socat user, I don't have to learn lesser tools :)
> >> 
> >> Here's how I use it.  Set up a local socket (any convenient
> >> bidirectional pipe would do, actually).
> >> 
> >> Example: QMP
> >> 
> >>     # Configuration file for -readconfig
> >>     [chardev "qmp"]
> >>       backend = "socket"
> >>       path = "sock-qmp"
> >>       server = "on"
> >>       wait = "off"
> >> 
> >>     [mon "qmp"]
> >>       mode = "control"
> >>       chardev = "qmp"
> >> 
> >> Example: HMP
> >> 
> >>     [chardev "hmp"]
> >>       backend = "socket"
> >>       path = "sock-hmp"
> >>       server = "on"
> >>       wait = "off"
> >> 
> >>     [mon "hmp"]
> >>       mode = "readline"
> >>       chardev = "hmp"
> >> 
> >> Then do stuff with it.
> >> 
> >> Example: interactive QMP
> >> 
> >>     $ socat UNIX:sock-qmp READLINE,history=$HOME/.qmp_history,prompt='QMP> '
> >> 
> >> Example: interactive HMP
> >> 
> >>     $ socat UNIX:sock-hmp READLINE,history=$HOME/.hmp_history
> >> 
> >> Arguably superior to our built-in not-quite readline monitor.
> >> 
> >> Example: send QMP input from a file, capture its output in a file
> >> 
> >>     $ socat UNIX:sock-qmp STDIO <input >output
> >
> > Yes, this example is exactly why I want something less painful.
> > A -chardev file that allowed read/write would be ideal, to be able to read
> > a series of commands at startup.
> 
> Have you tried -chardev pipe?  As I said, I don't use it myself, because
> my "painful" setup is more flexible, and not painful at all once set up.

Yes, I do use -chardev pipe in some of my scripts, and yes it's simpler
than the socket setup, but it's still a lot more complex than just stuffing
a list of commands in.

Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Paolo Bonzini]

On 30/09/2015 16:23, Programmingkid wrote:
>> We clearly don't have the
>> active maintainer and review capacity to do anything serious with
>> "ui/" (MAINTAINERS lists everything except SPICE as Odd Fixes).
> 
> This could be changed. 

Sure it could.  Who's going to do the work?

>> This is why I tend to agree with Markus' opinion here: we should
>> provide enough graphical UI to make raw QEMU minimally usable,
>> and leave further user-friendliness to other projects which have
>> more direct interest in that.
>>
>> If we had more regular contributors who were actively interested
>> in improving our UI layer my opinion might be different.
> 
> It is really hard for more contributors to come when the maintainers
> keep discouraging them. 

Submitting patches is never discouraged.  Endless email threads are.

Paolo

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Kevin Wolf]

Am 01.10.2015 um 12:36 hat Paolo Bonzini geschrieben:
> 
> 
> On 30/09/2015 16:23, Programmingkid wrote:
> >> We clearly don't have the
> >> active maintainer and review capacity to do anything serious with
> >> "ui/" (MAINTAINERS lists everything except SPICE as Odd Fixes).
> > 
> > This could be changed. 
> 
> Sure it could.  Who's going to do the work?

I think he's talking about himself.

> >> This is why I tend to agree with Markus' opinion here: we should
> >> provide enough graphical UI to make raw QEMU minimally usable,
> >> and leave further user-friendliness to other projects which have
> >> more direct interest in that.
> >>
> >> If we had more regular contributors who were actively interested
> >> in improving our UI layer my opinion might be different.
> > 
> > It is really hard for more contributors to come when the maintainers
> > keep discouraging them. 
> 
> Submitting patches is never discouraged.  Endless email threads are.

To be fair, I can see how it is discouraging when you post patches and
they either get ignored or people start arguing that you are
implementing something that you shouldn't be implementing because doing
GUI work is bad. The latter is what causes endless email threads.

And you can already see the result: Instead of patches, we now only get
the question whether patches improving the UI would be acceptable at all
(and worse, people even answer no).

Why don't we just let him maintain the OS X GUI and accept the patches,
even if they aren't perfect and even if they mean committing the crime
of improving user friendliness?  It's one of those neglected areas in
our code base and we should be glad that someone is interested in
keeping it working and improving it.

Kevin

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Daniel P. Berrange]

On Wed, Sep 30, 2015 at 09:48:25AM +0200, Markus Armbruster wrote:
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
> 
> > * Peter Maydell (peter.maydell@linaro.org) wrote:
> >> On 29 September 2015 at 14:11, Dr. David Alan Gilbert
> >> <dgilbert@redhat.com> wrote:
> >> > * Peter Maydell (peter.maydell@linaro.org) wrote:
> >> >> On 28 September 2015 at 20:43, Programmingkid
> >> >> <programmingkidx@gmail.com> wrote:
> >> >> >
> >> >> > On Sep 28, 2015, at 3:29 AM, Markus Armbruster wrote:
> >> >> >> You didn't mention you're talking about a *GUI* feature.
> >> >> >
> >> >> > I'm thinking it would be easier to send in the patch rather
> >> >> > than talk about
> >> >> > what this feature could be.
> >> >>
> >> >> I think Markus and I are trying to save you that effort by
> >> >> pointing out that this is a VM management layer feature,
> >> >> not a core QEMU feature.
> >> >
> >> > OK, so I'm going to agree with Programmingkid here.
> >> > I think this would be a useful feature to have in QEMU; I've
> >> > got gratuitous hacks in some of my test scripts that work
> >> > around it not being there.
> >> >
> >> > I think there are two possible things, both of which seem fairly
> >> > easy:
> >> >   1) Add a -chardev from file that works in this case
> >> >      (I don't think the current chardev file works does it?)
> 
> In general, character devices provide a bidirectional pipe, but -chardev
> file is write-only.  I think you want -chardev pipe.  I don't use it
> myself, because as socat user, I don't have to learn lesser tools :)
> 
> Here's how I use it.  Set up a local socket (any convenient
> bidirectional pipe would do, actually).
> 
> Example: QMP
> 
>     # Configuration file for -readconfig
>     [chardev "qmp"]
>       backend = "socket"
>       path = "sock-qmp"
>       server = "on"
>       wait = "off"
> 
>     [mon "qmp"]
>       mode = "control"
>       chardev = "qmp"
> 
> Example: HMP
> 
>     [chardev "hmp"]
>       backend = "socket"
>       path = "sock-hmp"
>       server = "on"
>       wait = "off"
> 
>     [mon "hmp"]
>       mode = "readline"
>       chardev = "hmp"
> 
> Then do stuff with it.
> 
> Example: interactive QMP
> 
>     $ socat UNIX:sock-qmp READLINE,history=$HOME/.qmp_history,prompt='QMP> '
> 
> Example: interactive HMP
> 
>     $ socat UNIX:sock-hmp READLINE,history=$HOME/.hmp_history
> 
> Arguably superior to our built-in not-quite readline monitor.
> 
> Example: send QMP input from a file, capture its output in a file
> 
>     $ socat UNIX:sock-qmp STDIO <input >output
> 
> >> >   2) A 'source' like command.
> 
> QMP?  The command would have to take a filename as argument, and return
> a list of replies.  Probably stop on first failed command.  Pretty
> useless for remote clients, because if you have to upload the file, you
> can just as well send it down the QMP pipe.  Actually, that pretty much
> applies to local clients, too.  Except perhaps for interactive use.  I
> feel a QMP client geared for such use would be the appropriate home for
> this feature.  We have some in scripts/qmp/.
> 
> I don't have an opinion on HMP right now.
> 
> >> Yeah, these are both plausible. Neither of them are GUI features,
> >> though...
> >
> > Well, I don't use the GTK gui; I can see that those who do
> > might want features in it.
> 
> GUI users want GUI features, of course.
> 
> In my opinion, QEMU should leave them to separate GUI shells, because
> doing everything in QEMU distracts from our core mission and we don't
> have GUI expertise[*].  One more point: building in the GUI is
> problematic when you don't trust the guest, because then you really want
> to run QEMU with least privileges.

I don't find the lack of expertise argument very compelling in general, as
that's just a self-fullfilling prophecy really. I do agree though, that
building a fully featured mgmt UI in QEMU is a distraction from more
important work in QEMU's core mission.

I also think this last point about having security separation between QEMU
and the GUI layer is really a killer argument against having any kind of
non-trivial GUI built-in to QEMU.

I get the opinion that most maintainers consider that the QEMU GUI is just
there to provide the bare minimum infrastructure to interact with the guest
without relying on external services like SPICE/VNC. IOW it is not there as
a building block for creating a full management UI around QEMU. I think it
would be helpful to explicitly spell this out in docs somewhere, so people
looking at QEMU cna easily identify that we're not looking for patches to
add mgmt features in the QEMU GUI and they should invest their time in GUI
efforts built on top of QEMU.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Daniel P. Berrange]

On Wed, Sep 30, 2015 at 11:53:50AM +0100, Peter Maydell wrote:
> On 30 September 2015 at 09:14, Dr. David Alan Gilbert
> <dgilbert@redhat.com> wrote:
> > * Markus Armbruster (armbru@redhat.com) wrote:
> >> In my opinion, QEMU should leave them to separate GUI shells, because
> >> doing everything in QEMU distracts from our core mission and we don't
> >> have GUI expertise[*].  One more point: building in the GUI is
> >> problematic when you don't trust the guest, because then you really want
> >> to run QEMU with least privileges.
> >
> > Given that we have a built in GUI then I can see people wanting to expand
> > it.
> 
> Right, but where do you draw the line? We clearly don't have the
> active maintainer and review capacity to do anything serious with
> "ui/" (MAINTAINERS lists everything except SPICE as Odd Fixes).
> 
> This is why I tend to agree with Markus' opinion here: we should
> provide enough graphical UI to make raw QEMU minimally usable,
> and leave further user-friendliness to other projects which have
> more direct interest in that.
> 
> If we had more regular contributors who were actively interested
> in improving our UI layer my opinion might be different.

Even if we had more contributors interested in that, I still think
that we should not do it, because building a UI into QEMU is a
fundamentally bad design / architecture. QEMU is a security
sensitive component and we want to know the boundaries of what
a guest exploit can achieve - including a GUI massively expands
the attack surface making it more or less impossible to confine
any QEMU exploit, even with tools like SELinux/AppArmour, because
you have to allow use of the desktop protocol at which point you
can just talk to a separate app to perform the exploit.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Oct 2, 2015, at 8:33 AM, Daniel P. Berrange wrote:

> On Wed, Sep 30, 2015 at 11:53:50AM +0100, Peter Maydell wrote:
>> On 30 September 2015 at 09:14, Dr. David Alan Gilbert
>> <dgilbert@redhat.com> wrote:
>>> * Markus Armbruster (armbru@redhat.com) wrote:
>>>> In my opinion, QEMU should leave them to separate GUI shells, because
>>>> doing everything in QEMU distracts from our core mission and we don't
>>>> have GUI expertise[*].  One more point: building in the GUI is
>>>> problematic when you don't trust the guest, because then you really want
>>>> to run QEMU with least privileges.
>>> 
>>> Given that we have a built in GUI then I can see people wanting to expand
>>> it.
>> 
>> Right, but where do you draw the line? We clearly don't have the
>> active maintainer and review capacity to do anything serious with
>> "ui/" (MAINTAINERS lists everything except SPICE as Odd Fixes).
>> 
>> This is why I tend to agree with Markus' opinion here: we should
>> provide enough graphical UI to make raw QEMU minimally usable,
>> and leave further user-friendliness to other projects which have
>> more direct interest in that.
>> 
>> If we had more regular contributors who were actively interested
>> in improving our UI layer my opinion might be different.
> 
> Even if we had more contributors interested in that, I still think
> that we should not do it, because building a UI into QEMU is a
> fundamentally bad design / architecture.

Why is it a bad design? I know that the Linux custom is to make a command
then possibly make a GUI that wraps around the command, but QEMU
doesn't just run on Linux. It runs on Mac OS X, Windows, Solaris,
FreeBSD, and maybe some more OS's. Applying the design
decisions of one OS to all OS's isn't necessarily a good idea

> QEMU is a security
> sensitive component and we want to know the boundaries of what
> a guest exploit can achieve - including a GUI massively expands
> the attack surface making it more or less impossible to confine
> any QEMU exploit, even with tools like SELinux/AppArmour, because
> you have to allow use of the desktop protocol at which point you
> can just talk to a separate app to perform the exploit.

The answer is simple in this situation. Just don't run a GUI with QEMU.
There is --disable-sdl, --disable-gtk, and --disable-cocoa. No more
GUI - security problems solved. 

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Dr. David Alan Gilbert]

* Daniel P. Berrange (berrange@redhat.com) wrote:
> On Wed, Sep 30, 2015 at 09:48:25AM +0200, Markus Armbruster wrote:
> > "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:

> I don't find the lack of expertise argument very compelling in general, as
> that's just a self-fullfilling prophecy really. I do agree though, that
> building a fully featured mgmt UI in QEMU is a distraction from more
> important work in QEMU's core mission.
> 

> I also think this last point about having security separation between QEMU
> and the GUI layer is really a killer argument against having any kind of
> non-trivial GUI built-in to QEMU.

We already have a GUI (at least 2...)

Defining a 'core mission' is very difficult.  While it's true that many
of us have to mostly worry about security in big farms of servers, some people
just want to run another OS on their desktop, and while they want it secure
they also want it to have fast graphics.   I'm not sure we currently have
a story for how to do separation from QEMU and fast graphics.


> I get the opinion that most maintainers consider that the QEMU GUI is just
> there to provide the bare minimum infrastructure to interact with the guest
> without relying on external services like SPICE/VNC. IOW it is not there as
> a building block for creating a full management UI around QEMU. I think it
> would be helpful to explicitly spell this out in docs somewhere, so people
> looking at QEMU cna easily identify that we're not looking for patches to
> add mgmt features in the QEMU GUI and they should invest their time in GUI
> efforts built on top of QEMU.

But how bare do you want it to be?  Many users get put off by the sparsity
of the GUI and just use something else instead.

Dave

> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Daniel P. Berrange]

On Fri, Oct 02, 2015 at 02:33:22PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (berrange@redhat.com) wrote:
> > On Wed, Sep 30, 2015 at 09:48:25AM +0200, Markus Armbruster wrote:
> > > "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
> 
> > I don't find the lack of expertise argument very compelling in general, as
> > that's just a self-fullfilling prophecy really. I do agree though, that
> > building a fully featured mgmt UI in QEMU is a distraction from more
> > important work in QEMU's core mission.
> > 
> 
> > I also think this last point about having security separation between QEMU
> > and the GUI layer is really a killer argument against having any kind of
> > non-trivial GUI built-in to QEMU.
> 
> We already have a GUI (at least 2...)

Right, but they're very feature limited in what they do - essentially only
used by developers for ad-hoc testing - few people are using them in the
real world for production deployments. That's a reasonably well constrained
scenario with no need for growth in features.

> Defining a 'core mission' is very difficult.  While it's true that many
> of us have to mostly worry about security in big farms of servers, some people
> just want to run another OS on their desktop, and while they want it secure
> they also want it to have fast graphics.   I'm not sure we currently have
> a story for how to do separation from QEMU and fast graphics.

IIUC, the intention with virgl is to allowing QEMU to pass an FD back to the
SPICE/VNC client which they can use to access the render context to avoid
expensive copying.

> > I get the opinion that most maintainers consider that the QEMU GUI is just
> > there to provide the bare minimum infrastructure to interact with the guest
> > without relying on external services like SPICE/VNC. IOW it is not there as
> > a building block for creating a full management UI around QEMU. I think it
> > would be helpful to explicitly spell this out in docs somewhere, so people
> > looking at QEMU cna easily identify that we're not looking for patches to
> > add mgmt features in the QEMU GUI and they should invest their time in GUI
> > efforts built on top of QEMU.
> 
> But how bare do you want it to be?  Many users get put off by the sparsity
> of the GUI and just use something else instead.

Even if it were a fancier GUI, I don't think it would really go very far to
providing users a solution which is on a par with VirtualBox or VMWare Desktop
which are the benchmarks, as the GUI will forever be limited to only dealing
with a single VM at a time. As soon as you want to deal with more than 1 VM
at a time, a GUI built-in to QEMU is a non-starter as you need to manage many
QEMUs. So encouraging new users to use a built-in QEMU GUI is sending them
down a dead-end - we should be ensuring they can find the viable long term
UI straight away. This means directing them to things like GNOME Boxes or
virt-manager or one of the other UIs that exist.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Oct 2, 2015, at 10:28 AM, Daniel P. Berrange wrote:

> On Fri, Oct 02, 2015 at 02:33:22PM +0100, Dr. David Alan Gilbert wrote:
>> * Daniel P. Berrange (berrange@redhat.com) wrote:
>>> On Wed, Sep 30, 2015 at 09:48:25AM +0200, Markus Armbruster wrote:
>>>> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
>> 
>>> I don't find the lack of expertise argument very compelling in general, as
>>> that's just a self-fullfilling prophecy really. I do agree though, that
>>> building a fully featured mgmt UI in QEMU is a distraction from more
>>> important work in QEMU's core mission.
>>> 
>> 
>>> I also think this last point about having security separation between QEMU
>>> and the GUI layer is really a killer argument against having any kind of
>>> non-trivial GUI built-in to QEMU.
>> 
>> We already have a GUI (at least 2...)
> 
> Right, but they're very feature limited in what they do - essentially only
> used by developers for ad-hoc testing - few people are using them in the
> real world for production deployments. That's a reasonably well constrained
> scenario with no need for growth in features.
> 
>> Defining a 'core mission' is very difficult.  While it's true that many
>> of us have to mostly worry about security in big farms of servers, some people
>> just want to run another OS on their desktop, and while they want it secure
>> they also want it to have fast graphics.   I'm not sure we currently have
>> a story for how to do separation from QEMU and fast graphics.
> 
> IIUC, the intention with virgl is to allowing QEMU to pass an FD back to the
> SPICE/VNC client which they can use to access the render context to avoid
> expensive copying.
> 
>>> I get the opinion that most maintainers consider that the QEMU GUI is just
>>> there to provide the bare minimum infrastructure to interact with the guest
>>> without relying on external services like SPICE/VNC. IOW it is not there as
>>> a building block for creating a full management UI around QEMU. I think it
>>> would be helpful to explicitly spell this out in docs somewhere, so people
>>> looking at QEMU cna easily identify that we're not looking for patches to
>>> add mgmt features in the QEMU GUI and they should invest their time in GUI
>>> efforts built on top of QEMU.
>> 
>> But how bare do you want it to be?  Many users get put off by the sparsity
>> of the GUI and just use something else instead.
> 
> Even if it were a fancier GUI, I don't think it would really go very far to
> providing users a solution which is on a par with VirtualBox or VMWare Desktop
> which are the benchmarks, as the GUI will forever be limited to only dealing
> with a single VM at a time. As soon as you want to deal with more than 1 VM
> at a time, a GUI built-in to QEMU is a non-starter as you need to manage many
> QEMUs. So encouraging new users to use a built-in QEMU GUI is sending them
> down a dead-end - we should be ensuring they can find the viable long term
> UI straight away. This means directing them to things like GNOME Boxes or
> virt-manager or one of the other UIs that exist.

Sorry to say but this belief you have it exactly what is keeping
the GUI in QEMU from being great. Can only deal with one VM at a time?
I can have both qemu-system-ppc and qemu-system-i386 running at the
same time and they both have the same GUI. They are two separate
programs so no problems with them both running. 

Conditional codes can make the GUI more self-customizing to the various
machine emulators. Features like USB can be detected at runtime and
handled accordingly. 

The GUI in QEMU can become great. We just have to let it do so. 

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 2354 bytes --]

On 10/02/2015 08:37 AM, Programmingkid wrote:
>> Even if it were a fancier GUI, I don't think it would really go very far to
>> providing users a solution which is on a par with VirtualBox or VMWare Desktop
>> which are the benchmarks, as the GUI will forever be limited to only dealing
>> with a single VM at a time. As soon as you want to deal with more than 1 VM
>> at a time, a GUI built-in to QEMU is a non-starter as you need to manage many
>> QEMUs. So encouraging new users to use a built-in QEMU GUI is sending them
>> down a dead-end - we should be ensuring they can find the viable long term
>> UI straight away. This means directing them to things like GNOME Boxes or
>> virt-manager or one of the other UIs that exist.
> 
> Sorry to say but this belief you have it exactly what is keeping
> the GUI in QEMU from being great. Can only deal with one VM at a time?

A good gui will have a single process dealing with multiple guests at a
single time.

When you are reading email, do you want to fire up two separate email
processes per mail?  Or do you want to fire up a single email reader,
that can then browse multiple mails, and maybe even open multiple
windows to compare mails side by side?

When you open your browser, do you want to have two browser processes
for separate URLs open at the same time?  Or do you want a single
browser with multiple tabs?

We already KNOW that qemu only manages one guest at a time.  But I argue
that any GOOD gui for managing guests can manage multiple guests in a
single gui process. So qemu is NOT the place to be working on a GOOD
gui.  It only needs enough of a gui to make development easier, NOT to
make end user life easier.

We WANT to point end users to a better application, _built on top of
qemu_.  Whether that be GNOME boxes, virt-manager, or some new tool, I
don't care.  But we do NOT want qemu to become that tool.

Instead of wasting our time beating a dead horse, you'd get further if
you started porting one of the existing VM guis that can already manage
qemu to run well on OS X.

> The GUI in QEMU can become great. We just have to let it do so. 

No.  Please don't.  I do not want the qemu gui to be a selling point of
qemu.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [Qemu-devel] feature idea: allow user to run custom scripts

[Programmingkid]

On Oct 2, 2015, at 12:21 PM, Eric Blake wrote:

> On 10/02/2015 08:37 AM, Programmingkid wrote:
>>> Even if it were a fancier GUI, I don't think it would really go very far to
>>> providing users a solution which is on a par with VirtualBox or VMWare Desktop
>>> which are the benchmarks, as the GUI will forever be limited to only dealing
>>> with a single VM at a time. As soon as you want to deal with more than 1 VM
>>> at a time, a GUI built-in to QEMU is a non-starter as you need to manage many
>>> QEMUs. So encouraging new users to use a built-in QEMU GUI is sending them
>>> down a dead-end - we should be ensuring they can find the viable long term
>>> UI straight away. This means directing them to things like GNOME Boxes or
>>> virt-manager or one of the other UIs that exist.
>> 
>> Sorry to say but this belief you have it exactly what is keeping
>> the GUI in QEMU from being great. Can only deal with one VM at a time?
> 
> A good gui will have a single process dealing with multiple guests at a
> single time.

Going to have to agree to disagree on this point.

> 
> When you are reading email, do you want to fire up two separate email
> processes per mail?  Or do you want to fire up a single email reader,
> that can then browse multiple mails, and maybe even open multiple
> windows to compare mails side by side?
> When you open your browser, do you want to have two browser processes
> for separate URLs open at the same time?  Or do you want a single
> browser with multiple tabs?

This may be fine for emails and web pages, but we are talking about
emulators here. I'm not against this idea, but improving QEMU's GUI and
implementing this megaGUI can happen at the same time. 

> We already KNOW that qemu only manages one guest at a time.  But I argue
> that any GOOD gui for managing guests can manage multiple guests in a
> single gui process. So qemu is NOT the place to be working on a GOOD
> gui.  It only needs enough of a gui to make development easier, NOT to
> make end user life easier.

Definitely going to have to agree to disagree on this point.

> 
> We WANT to point end users to a better application, _built on top of
> qemu_.  Whether that be GNOME boxes, virt-manager, or some new tool, I
> don't care.  But we do NOT want qemu to become that tool.

Everybody can win in this situation. The Anti-GUI people can win by using 
--disable-gtk/--disable-cocoa, and the Pro-GUI people can win by using
their respective GUI's. 

> Instead of wasting our time beating a dead horse, you'd get further if
> you started porting one of the existing VM guis that can already manage
> qemu to run well on OS X.

That is much easier said than done. What you want could take years to
accomplish. Adding a few features to the GUI doesn't sound that bad. It
also doesn't hurt someone who doesn't use the GUI, so why have a problem
with it?

> 
>> The GUI in QEMU can become great. We just have to let it do so. 
> 
> No.  Please don't.  I do not want the qemu gui to be a selling point of
> qemu.

Selling point? Are you afraid a really good GUI for QEMU might put
Libvirt out of business? Isn't the general trend in technology for things
to become better? Trying to hold back the GUI is anti-technology 
thinking. We need pro-technology thinkers to advance our way of
life. I am sure that technology has put people out of business. If you 
want to cling to the pony express way of life, good luck. I think you 
and everyone else would be much better suited to moving forward
and adapting to change.