2010/4/26 Avi Kivity a...@redhat.com:
[...]
In theory, it does support this with the session urls but they are
currently second-class citizens in libvirt. The remote dispatch also adds
a
fair bit of complexity and at least for the use-cases I'm interested in,
it's not an important
Daniel P. Berrange wrote:
Much better to exact a commitment from libvirt to track all QMP (and
command line) capabilities. Instead of adding cleverness to QMP, add
APIs to libvirt.
Agreed. Despite adding this monitor / XML passthrough capability, we still
do not want apps to be using
On 04/26/2010 08:54 AM, Jamie Lokier wrote:
All the features? The qemu API is quite large already (look at all
the command line options and monitor commands). I'll be very
surprised if libvirt provides all of it that obscure apps may use.
I'm thinking of features which are relatively
On 04/26/2010 05:25 PM, Chris Lalancette wrote:
Right, and you are probably one of the users this work targets. But in
general, for those not very familiar with virtualization/qemu, we want
to steer them far clear of this API. That goes doubly true for application
developers; we want them to
On Mon, Apr 26, 2010 at 05:34:22PM +0300, Avi Kivity wrote:
On 04/26/2010 05:25 PM, Chris Lalancette wrote:
Right, and you are probably one of the users this work targets. But in
general, for those not very familiar with virtualization/qemu, we want
to steer them far clear of this API. That
On 04/26/2010 09:54 AM, Daniel P. Berrange wrote:
On Mon, Apr 26, 2010 at 05:34:22PM +0300, Avi Kivity wrote:
On 04/26/2010 05:25 PM, Chris Lalancette wrote:
Right, and you are probably one of the users this work targets. But in
general, for those not very familiar with
On Mon, Apr 26, 2010 at 10:08:33AM -0500, Anthony Liguori wrote:
On 04/26/2010 09:54 AM, Daniel P. Berrange wrote:
On Mon, Apr 26, 2010 at 05:34:22PM +0300, Avi Kivity wrote:
On 04/26/2010 05:25 PM, Chris Lalancette wrote:
Right, and you are probably one of the users this work
On 04/26/2010 10:20 AM, Daniel P. Berrange wrote:
For the sake of my analogy, I'd still group cairo in with gtk, not x11. It
is really just a re-implmentation of the GDK drawing layer from GTK. It
still provides a portable higher level abstraction over underlying graphics
rendering systems it
On 04/22/10 20:47, Anthony Liguori wrote:
On 04/12/2010 07:23 AM, Jamie Lokier wrote:
Some simple but versatile hook ideas:
-emulator-append-option (no space splitting, one option,
appended)
-emulator-append-options (space splitting multiple options)
-emulator-prepend-option
On Thu, Apr 22, 2010 at 01:47:55PM -0500, Anthony Liguori wrote:
On 04/12/2010 07:23 AM, Jamie Lokier wrote:
Daniel Veillard wrote:
On Sun, Apr 11, 2010 at 11:17:38PM +0100, Jamie Lokier wrote:
It's not that hard to write this for trivial extra options:
emulator/bin/sh -c
On Fri, Apr 23, 2010 at 05:24:34PM +0300, Avi Kivity wrote:
On 04/23/2010 04:48 PM, Anthony Liguori wrote:
On 04/23/2010 07:48 AM, Avi Kivity wrote:
On 04/22/2010 09:49 PM, Anthony Liguori wrote:
real API. Say, adding a device libvirt doesn't know about or
stopping the VM
while libvirt
On 04/12/2010 07:23 AM, Jamie Lokier wrote:
Daniel Veillard wrote:
On Sun, Apr 11, 2010 at 11:17:38PM +0100, Jamie Lokier wrote:
It's not that hard to write this for trivial extra options:
emulator/bin/sh -c 'qemu $0 $@ -extra-flag'/emulator
(if that works).
That
Daniel Veillard wrote:
On Sun, Apr 11, 2010 at 11:17:38PM +0100, Jamie Lokier wrote:
It's not that hard to write this for trivial extra options:
emulator/bin/sh -c 'qemu $0 $@ -extra-flag'/emulator
(if that works).
That won't work because we expect the emulator to be a path to
On Mon, Apr 12, 2010 at 01:23:08PM +0100, Jamie Lokier wrote:
Daniel Veillard wrote:
On Sun, Apr 11, 2010 at 11:17:38PM +0100, Jamie Lokier wrote:
Parsing libvirt output and having to guess which option corresponds to
what from the libvirt config sounds very fragile and also a rather
On 04/09/2010 11:30 PM, Eric Blake wrote:
Yeah, having the ability to specify an optional wrapper script, that
receives the name of the normal interpreter and all the arguments the
normal interpreter would have been given, sounds like the ultimate in
flexibility at a minimum of xml.
You can
On 04/09/2010 03:06 PM, Jamie Lokier wrote:
Daniel P. Berrange wrote:
I think this alteration of existing args is fr too complex fragile,
and way overkill.
Would it not be simpler, for the target audience, for the config to
contain a one-line shell script to transform particular
16 matches
Mail list logo
