[Qemu-devel] KVM call agenda for September 25th

[Qemu-devel] KVM call agenda for September 25th

[Juan Quintela]

Hi

Please send in any agenda items you are interested in covering.

Thanks, Juan.

Re: [Qemu-devel] KVM call agenda for September 25th

[Paolo Bonzini]

Il 24/09/2012 13:28, Juan Quintela ha scritto:
> Hi
> 
> Please send in any agenda items you are interested in covering.

URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the
same code.

Paolo

Re: [Qemu-devel] KVM call agenda for September 25th

[Richard W.M. Jones]

On Mon, Sep 24, 2012 at 01:48:26PM +0200, Paolo Bonzini wrote:
> Il 24/09/2012 13:28, Juan Quintela ha scritto:
> > Hi
> > 
> > Please send in any agenda items you are interested in covering.
> 
> URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the
> same code.

I can't make this call, but I'm not fussed about the decision
here, go with whatever Paolo thinks.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

Re: [Qemu-devel] KVM call agenda for September 25th

[Anthony Liguori]

Paolo Bonzini <pbonzini@redhat.com> writes:

> Il 24/09/2012 13:28, Juan Quintela ha scritto:
>> Hi
>> 
>> Please send in any agenda items you are interested in covering.
>
> URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the
> same code.

The call is a bit late for Bharata but I think copying is the way to go.

Something I've been thinking about since this discussion started
though.  Maybe we could standardize on using URIs as short-hand syntax
for backends.

For example:

qemu -hda file:///foo.img

Or:

qemu -device virtio-net-pci,netdev=tap:///vnet0?script=/etc/qemu-ifup

Or:

qemu -device \
      isa-serial,index=0,chr=tcp://localhost:1025/?server=on&wait=off

This works particularly well with a "treat unknown options as -device"
mechanism so that we could do:

qemu -isa-serial chr=tcp://localhost:1025/?server=on&wait=off

We could even introduce a secondary implied option to shorten this
further to:

qemu -isa-serial tcp://localhost:1025/?server=on&wait=off

Regards,

Anthony Liguori

>
> Paolo
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] KVM call agenda for September 25th

[Richard W.M. Jones]

On Tue, Sep 25, 2012 at 07:57:53AM -0500, Anthony Liguori wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > Il 24/09/2012 13:28, Juan Quintela ha scritto:
> >> Hi
> >> 
> >> Please send in any agenda items you are interested in covering.
> >
> > URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the
> > same code.
> 
> The call is a bit late for Bharata but I think copying is the way to go.
> 
> Something I've been thinking about since this discussion started
> though.  Maybe we could standardize on using URIs as short-hand syntax
> for backends.
> 
> For example:
> 
> qemu -hda file:///foo.img
> 
> Or:
> 
> qemu -device virtio-net-pci,netdev=tap:///vnet0?script=/etc/qemu-ifup

This is roughly what the original URI code from libvirt is used for:

http://libvirt.org/remote.html#Remote_URI_reference

It works well because URIs are standardized, well understood, support
escaping, and are widely supported by client libraries/languages.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

Re: [Qemu-devel] KVM call agenda for September 25th

[Luiz Capitulino]

On Tue, 25 Sep 2012 07:57:53 -0500
Anthony Liguori <anthony@codemonkey.ws> wrote:

> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > Il 24/09/2012 13:28, Juan Quintela ha scritto:
> >> Hi
> >> 
> >> Please send in any agenda items you are interested in covering.
> >
> > URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the
> > same code.
> 
> The call is a bit late for Bharata but I think copying is the way to go.
> 
> Something I've been thinking about since this discussion started
> though.  Maybe we could standardize on using URIs as short-hand syntax
> for backends.

Agreed, just suggested this for qmp commands taking a file path and
a fd name in other thread.

Re: [Qemu-devel] KVM call agenda for September 25th

[Luiz Capitulino]

On Mon, 24 Sep 2012 13:48:26 +0200
Paolo Bonzini <pbonzini@redhat.com> wrote:

> Il 24/09/2012 13:28, Juan Quintela ha scritto:
> > Hi
> > 
> > Please send in any agenda items you are interested in covering.
> 
> URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the
> same code.

Case we're going to have the call (otherwise let's discuss it on the
list):

  - change blocking I/O to non-blocking I/O for qmp commands?

We have a few qmp commands that do blocking I/O (eg. screendump and
dump-guest-memory). Theoretically, those commands could block forever.
This is a more serious issue with the screendump command, which doesn't
stop vcpus.

I've never received a report about this, so maybe this is not an issue.
But, while the perfect solution here is to have async commands, I was
wondering if it would be feasible for synchronous commands like screendump
to be changed to use non-blocking fds. This way we don't risk blocking.

Re: [Qemu-devel] KVM call agenda for September 25th

[Paolo Bonzini]

Il 25/09/2012 14:57, Anthony Liguori ha scritto:
> The call is a bit late for Bharata but I think copying is the way to go.
> 
> Something I've been thinking about since this discussion started
> though.  Maybe we could standardize on using URIs as short-hand syntax
> for backends.
> 
> For example:
> 
> qemu -hda file:///foo.img
> 
> Or:
> 
> qemu -device virtio-net-pci,netdev=tap:///vnet0?script=/etc/qemu-ifup
> 
> Or:
> 
> qemu -device \
>       isa-serial,index=0,chr=tcp://localhost:1025/?server=on&wait=off
> 
> This works particularly well with a "treat unknown options as -device"
> mechanism so that we could do:
> 
> qemu -isa-serial chr=tcp://localhost:1025/?server=on&wait=off
> 
> We could even introduce a secondary implied option to shorten this
> further to:
> 
> qemu -isa-serial tcp://localhost:1025/?server=on&wait=off

Interesting idea...

Paolo

Re: [Qemu-devel] KVM call agenda for September 25th

[Kevin Wolf]

Am 25.09.2012 14:57, schrieb Anthony Liguori:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
>> Il 24/09/2012 13:28, Juan Quintela ha scritto:
>>> Hi
>>>
>>> Please send in any agenda items you are interested in covering.
>>
>> URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the
>> same code.
> 
> The call is a bit late for Bharata but I think copying is the way to go.
> 
> Something I've been thinking about since this discussion started
> though.  Maybe we could standardize on using URIs as short-hand syntax
> for backends.

Compared with QemuOpts, it's not really short-hand or even convenient
for manual use. For management tools it might be nice because URIs have
a well-known syntax, can escape anything and implementations exist. But
I think we must still maintain an easy to use syntax for human users.

> For example:
> 
> qemu -hda file:///foo.img
> 
> Or:
> 
> qemu -device virtio-net-pci,netdev=tap:///vnet0?script=/etc/qemu-ifup
> 
> Or:
> 
> qemu -device \
>       isa-serial,index=0,chr=tcp://localhost:1025/?server=on&wait=off

Your examples kind of prove this: They aren't much shorter than what
exists today, but they contain ? and &, which are nasty characters on
the command line.

> This works particularly well with a "treat unknown options as -device"
> mechanism so that we could do:
> 
> qemu -isa-serial chr=tcp://localhost:1025/?server=on&wait=off
> 
> We could even introduce a secondary implied option to shorten this
> further to:
> 
> qemu -isa-serial tcp://localhost:1025/?server=on&wait=off

This is something that I was thinking of in the context of -blockdev a
while ago (without URLs): Define the block device inside of -device
specifications. The problem of nesting an option string inside another
one is solved in theory by URLs because they allow (nested) escaping,
but in practice we'll need to use some kind of brackets instead if we
want it to be usable.

Kevin

Re: [Qemu-devel] KVM call agenda for September 25th

[Bharata B Rao]

On Tue, Sep 25, 2012 at 04:51:15PM +0200, Kevin Wolf wrote:
> Am 25.09.2012 14:57, schrieb Anthony Liguori:
> > qemu -device \
> >       isa-serial,index=0,chr=tcp://localhost:1025/?server=on&wait=off
> 
> Your examples kind of prove this: They aren't much shorter than what
> exists today, but they contain ? and &, which are nasty characters on
> the command line.

Right. '&' can't even be specified directly on command line since that will
result in qemu command being treated as a background job with anything after
'&' being discarded. I realized that '&' needs to be escaped as %26.

Regards,
Bharata.

Re: [Qemu-devel] KVM call agenda for September 25th

[Paolo Bonzini]

Il 25/09/2012 17:33, Bharata B Rao ha scritto:
>>> qemu -device \
>>> > >       isa-serial,index=0,chr=tcp://localhost:1025/?server=on&wait=off
>> > 
>> > Your examples kind of prove this: They aren't much shorter than what
>> > exists today, but they contain ? and &, which are nasty characters on
>> > the command line.
> Right. '&' can't even be specified directly on command line since that will
> result in qemu command being treated as a background job with anything after
> '&' being discarded. I realized that '&' needs to be escaped as %26.

No, %26 is escaped at the URL level, i.e. it doesn't start a new
argumnt.  If you need to pass '&' in the shell, simply use quoting or
write it \&.

Paolo

Re: [Qemu-devel] KVM call agenda for September 25th

[Anthony Liguori]

Kevin Wolf <kwolf@redhat.com> writes:

> Am 25.09.2012 14:57, schrieb Anthony Liguori:
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>> 
>>> Il 24/09/2012 13:28, Juan Quintela ha scritto:
>>>> Hi
>>>>
>>>> Please send in any agenda items you are interested in covering.
>>>
>>> URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the
>>> same code.
>> 
>> The call is a bit late for Bharata but I think copying is the way to go.
>> 
>> Something I've been thinking about since this discussion started
>> though.  Maybe we could standardize on using URIs as short-hand syntax
>> for backends.
>
> Compared with QemuOpts, it's not really short-hand or even convenient
> for manual use. For management tools it might be nice because URIs have
> a well-known syntax, can escape anything and implementations exist. But
> I think we must still maintain an easy to use syntax for human users.
>
>> For example:
>> 
>> qemu -hda file:///foo.img
>> 
>> Or:
>> 
>> qemu -device virtio-net-pci,netdev=tap:///vnet0?script=/etc/qemu-ifup
>> 
>> Or:
>> 
>> qemu -device \
>>       isa-serial,index=0,chr=tcp://localhost:1025/?server=on&wait=off
>
> Your examples kind of prove this: They aren't much shorter than what
> exists today, but they contain ? and &, which are nasty characters on
> the command line.
>
>> This works particularly well with a "treat unknown options as -device"
>> mechanism so that we could do:
>> 
>> qemu -isa-serial chr=tcp://localhost:1025/?server=on&wait=off
>> 
>> We could even introduce a secondary implied option to shorten this
>> further to:
>> 
>> qemu -isa-serial tcp://localhost:1025/?server=on&wait=off
>
> This is something that I was thinking of in the context of -blockdev a
> while ago (without URLs): Define the block device inside of -device
> specifications. The problem of nesting an option string inside another
> one is solved in theory by URLs because they allow (nested) escaping,
> but in practice we'll need to use some kind of brackets instead if we
> want it to be usable.

qemu -isa-serial 'tcp://localhost:1025/?server=on&wait=off'

I don't think it's really that better.  And yeah, your thoughts are
exactly mine.  Having two syntaxes allows us to use a single option.

Hopefully most options could avoid having query parameters so escaping
wasn't a problem.  It's unfortunate that the TCP character device uses
client mode by default.

Regards,

Anthony Liguori


>
> Kevin

Re: [Qemu-devel] KVM call agenda for September 25th

[Markus Armbruster]

Anthony Liguori <anthony@codemonkey.ws> writes:

> Kevin Wolf <kwolf@redhat.com> writes:
>
>> Am 25.09.2012 14:57, schrieb Anthony Liguori:
>>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>> 
>>>> Il 24/09/2012 13:28, Juan Quintela ha scritto:
>>>>> Hi
>>>>>
>>>>> Please send in any agenda items you are interested in covering.
>>>>
>>>> URI parsing library for glusterfs: libxml2 vs. in-tree "fork" of the
>>>> same code.
>>> 
>>> The call is a bit late for Bharata but I think copying is the way to go.
>>> 
>>> Something I've been thinking about since this discussion started
>>> though.  Maybe we could standardize on using URIs as short-hand syntax
>>> for backends.
>>
>> Compared with QemuOpts, it's not really short-hand or even convenient
>> for manual use. For management tools it might be nice because URIs have
>> a well-known syntax, can escape anything and implementations exist. But
>> I think we must still maintain an easy to use syntax for human users.
>>
>>> For example:
>>> 
>>> qemu -hda file:///foo.img
>>> 
>>> Or:
>>> 
>>> qemu -device virtio-net-pci,netdev=tap:///vnet0?script=/etc/qemu-ifup
>>> 
>>> Or:
>>> 
>>> qemu -device \
>>>       isa-serial,index=0,chr=tcp://localhost:1025/?server=on&wait=off
>>
>> Your examples kind of prove this: They aren't much shorter than what
>> exists today, but they contain ? and &, which are nasty characters on
>> the command line.
>>
>>> This works particularly well with a "treat unknown options as -device"
>>> mechanism so that we could do:
>>> 
>>> qemu -isa-serial chr=tcp://localhost:1025/?server=on&wait=off
>>> 
>>> We could even introduce a secondary implied option to shorten this
>>> further to:
>>> 
>>> qemu -isa-serial tcp://localhost:1025/?server=on&wait=off

Too much magic for my taste.

I'm afraid it leads to rather obscure error messages on misspellings.

>> This is something that I was thinking of in the context of -blockdev a
>> while ago (without URLs): Define the block device inside of -device
>> specifications. The problem of nesting an option string inside another
>> one is solved in theory by URLs because they allow (nested) escaping,
>> but in practice we'll need to use some kind of brackets instead if we
>> want it to be usable.
>
> qemu -isa-serial 'tcp://localhost:1025/?server=on&wait=off'
>
> I don't think it's really that better.  And yeah, your thoughts are
> exactly mine.  Having two syntaxes allows us to use a single option.
>
> Hopefully most options could avoid having query parameters so escaping
> wasn't a problem.  It's unfortunate that the TCP character device uses
> client mode by default.

You could fold a limited set of common flags into the scheme.  Prior
art: socat supports syntax like

    TCP:<host>:<port>
    TCP4:<host>:<port>
    TCP-LISTEN:<port>

I'm not saying it's a good idea for QEMU.