2010/4/26 Avi Kivity :
>
[...]
>>
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
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 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
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 virtualizatio
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.
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 be
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 o
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 b
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
> >>
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:
> >>>
> >>>
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:
>>
>> - (no space splitting, one option,
>> appended)
>> - (space splitting multiple options)
>> -
>> -
>> -VALUE
>
> I'd strongly suggest not foc
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:
/bin/sh -c 'qemu "$0" "$@" -extra-flag'
(if that works).
That won't work becau
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 ra
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:
> >
> >/bin/sh -c 'qemu "$0" "$@" -extra-flag'
> >
> > (if that works).
>
> That won't work because we expect the emulator to be a path to
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 als
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 particula
16 matches
Mail list logo