KVM call agenda for September 25th
Hi
Please send in any agenda items you are interested in covering.
Thanks, Juan.
Paolo Bonzini
maintainerIl 24/09/2012 13:28, Juan Quintela ha scritto:
Quoted 3 lines
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
Quoted 7 lines · Paolo Bonzini
Il 24/09/2012 13:28, Juan Quintela ha scritto:
Quoted 3 lines
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.
Signature · 4 lines
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
Quoted 7 lines · Paolo Bonzini
Il 24/09/2012 13:28, Juan Quintela ha scritto:
Quoted 3 lines
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=offThis 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
Quoted 6 lines
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 16 lines · Anthony Liguori
Quoted 7 lines · Paolo Bonzini
Il 24/09/2012 13:28, Juan Quintela ha scritto:
Quoted 3 lines
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.
Quoted 7 lines
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.
Signature · 4 lines
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
Quoted 7 lines · On Tue, 25 Sep 2012 07:57:53 -0500 Anthony Liguori <[email protected]>…
Quoted 5 lines · Paolo Bonzini
Il 24/09/2012 13:28, Juan Quintela ha scritto:
Quoted 3 lines
Hi
Please send in any agenda items you are interested in covering.
Quoted 8 lines
Quoted 2 lines
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.
Paolo Bonzini
maintainerIl 25/09/2012 14:57, Anthony Liguori ha scritto:
Quoted 22 lines
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=offThis works particularly well with a "treat unknown options as -device" mechanism so that we could do:
Quoted 6 lines
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
Am 25.09.2012 14:57, schrieb Anthony Liguori:
Quoted 7 lines
Quoted 5 lines · Paolo Bonzini
Il 24/09/2012 13:28, Juan Quintela ha scritto:
Quoted 3 lines
Hi
Please send in any agenda items you are interested in covering.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 4 lines
For example:
qemu -hda file:///foo.img
Quoted 8 lines
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.
Quoted 9 lines
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
Quoted 7 lines · Kevin Wolf
Am 25.09.2012 14:57, schrieb Anthony Liguori:
Quoted 2 lines
qemu -device \ isa-serial,index=0,chr=tcp://localhost:1025/?server=on&wait=offYour 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.
Paolo Bonzini
maintainerIl 25/09/2012 17:33, Bharata B Rao ha scritto:
Quoted 9 lines
Quoted 6 lines
Quoted 6 lines
qemu -device \
Quoted 1 line
Quoted 1 line
isa-serial,index=0,chr=tcp://localhost:1025/?server=on&wait=offYour 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
Quoted 47 lines · Kevin Wolf
Am 25.09.2012 14:57, schrieb Anthony Liguori:
Quoted 7 lines
Quoted 5 lines · Paolo Bonzini
Il 24/09/2012 13:28, Juan Quintela ha scritto:
Quoted 3 lines
Hi
Please send in any agenda items you are interested in covering.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 4 lines
For example:
qemu -hda file:///foo.img
Quoted 8 lines
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=offYour 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.
Quoted 8 lines
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:
Quoted 8 lines
Quoted 1 line
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
Quoted 2 lines
Kevin
Quoted 44 lines · Anthony Liguori
Quoted 42 lines · Kevin Wolf
Am 25.09.2012 14:57, schrieb Anthony Liguori:
Quoted 7 lines
Quoted 5 lines · Paolo Bonzini
Il 24/09/2012 13:28, Juan Quintela ha scritto:
Quoted 3 lines
Hi
Please send in any agenda items you are interested in covering.
Quoted 8 lines
Quoted 2 lines
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.
Quoted 4 lines
For example:
qemu -hda file:///foo.img
Quoted 8 lines
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=offYour 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.
Quoted 3 lines
This works particularly well with a "treat unknown options as -device" mechanism so that we could do:
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
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.
Quoted 7 lines
Quoted 6 lines
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.
Quoted 8 lines
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.
Quoted 7 lines · On Mon, 24 Sep 2012 13:48:26 +0200 Paolo Bonzini <[email protected]> wrote:
Il 24/09/2012 13:28, Juan Quintela ha scritto:
Quoted 3 lines
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.