On 04/26/2010 04:53 AM, Anthony Liguori wrote:
On 04/25/2010 06:51 AM, Avi Kivity wrote:
It depends on what things you think are important. A lot of
libvirt's complexity is based on the fact that it uses a daemon and
needs to deal with the security implications of that. You don't
need
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
On Sun, Apr 25, 2010 at 08:53:17PM -0500, Anthony Liguori wrote:
On 04/25/2010 06:51 AM, Avi Kivity wrote:
Qemu is special due to the nonexistence of qemud.
Why is sVirt implemented in libvirt? it's not the logical place for
it; rather the logical place doesn't exist.
sVirt is not
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 04:59 AM, Daniel P. Berrange wrote:
On Sun, Apr 25, 2010 at 08:53:17PM -0500, Anthony Liguori wrote:
On 04/25/2010 06:51 AM, Avi Kivity wrote:
Qemu is special due to the nonexistence of qemud.
Why is sVirt implemented in libvirt? it's not the logical place for
it;
On 04/25/2010 09:50 AM, Avi Kivity wrote:
On 04/23/2010 09:33 PM, Anthony Liguori wrote:
This is a different ambiguity, about the semantic results of the
commands,
where as I'm refering to the execution order. If I look at a libvirt
log
file and see a set of JSON commands logged, I want to
On 04/26/2010 12:56 AM, Avi Kivity wrote:
On 04/26/2010 04:53 AM, Anthony Liguori wrote:
On 04/25/2010 06:51 AM, Avi Kivity wrote:
It depends on what things you think are important. A lot of
libvirt's complexity is based on the fact that it uses a daemon and
needs to deal with the security
On 04/26/2010 08:31 AM, Daniel P. Berrange wrote:
What you describe is not inherant to the daemon model. This is why we have
two separate models in libvirt. The system instance is pre-spawned with
high privileges, to allow use of hosts resources which require high
privileges to access. The
On 04/26/2010 08:41 AM, Avi Kivity wrote:
Today, you have to make changes to libvirt whereas in a direct launch
model, you get all of the neat security features linux supports for
free.
But you lose tap networking, unless you have a privileged helper. And
how is the privileged helper to
On 04/26/2010 04:46 PM, Anthony Liguori wrote:
(3) The system management application can certainly create whatever
context it wants to launch a vm from. It's comes down to who's
responsible for creating the context the guest runs under. I think
doing that at the libvirt level takes away a
On Mon, Apr 26, 2010 at 08:46:46AM -0500, Anthony Liguori wrote:
On 04/26/2010 08:41 AM, Avi Kivity wrote:
(3) The system management application can certainly create whatever
context it wants to launch a vm from. It's comes down to who's
responsible for creating the context the guest runs
On 04/26/2010 04:43 PM, Anthony Liguori wrote:
The reason I lean toward the direct launch model is that it gives the
user a lot of flexibility in terms of using things like namespaces,
DAC, cgroups, capabilities, etc. A lot of potential features are lost
when you do indirect launch because
On 04/26/2010 09:01 AM, Avi Kivity wrote:
On 04/26/2010 04:43 PM, Anthony Liguori wrote:
The reason I lean toward the direct launch model is that it gives the
user a lot of flexibility in terms of using things like namespaces,
DAC, cgroups, capabilities, etc. A lot of potential features are
On 04/26/2010 05:19 PM, Anthony Liguori wrote:
On 04/26/2010 09:01 AM, Avi Kivity wrote:
On 04/26/2010 04:43 PM, Anthony Liguori wrote:
The reason I lean toward the direct launch model is that it gives
the user a lot of flexibility in terms of using things like
namespaces, DAC, cgroups,
On 04/26/2010 08:58 AM, Daniel P. Berrange wrote:
On Mon, Apr 26, 2010 at 08:46:46AM -0500, Anthony Liguori wrote:
On 04/26/2010 08:41 AM, Avi Kivity wrote:
(3) The system management application can certainly create whatever
context it wants to launch a vm from. It's comes down to
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 09:25 AM, Avi Kivity wrote:
On 04/26/2010 05:19 PM, Anthony Liguori wrote:
On 04/26/2010 09:01 AM, Avi Kivity wrote:
On 04/26/2010 04:43 PM, Anthony Liguori wrote:
The reason I lean toward the direct launch model is that it gives
the user a lot of flexibility in terms of using
On Mon, Apr 26, 2010 at 09:26:55AM -0500, Anthony Liguori wrote:
On 04/26/2010 08:58 AM, Daniel P. Berrange wrote:
On Mon, Apr 26, 2010 at 08:46:46AM -0500, Anthony Liguori wrote:
On 04/26/2010 08:41 AM, Avi Kivity wrote:
(3) The system management application can certainly create
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 04/26/2010 05:28 PM, Anthony Liguori wrote:
Or a library that the user-written launcher calls. Or a plugin that
qemud calls.
A plugin would lose the security context. It could attempt to
recreate it that seems like a lot of unnecessary complexity.
A plugin would create the security
On 04/26/2010 09:38 AM, Avi Kivity wrote:
On 04/26/2010 05:28 PM, Anthony Liguori wrote:
Or a library that the user-written launcher calls. Or a plugin that
qemud calls.
A plugin would lose the security context. It could attempt to
recreate it that seems like a lot of unnecessary
On 04/26/2010 05:48 PM, Anthony Liguori wrote:
We could easily reuse that. Any other security context code would
be custom written; so it can be written as a qemud plugin instead of
a bit of code that goes before a qemu launch.
I think we're mostly in agreement with respect to the need
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 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/25/2010 06:39 AM, Anthony Liguori wrote:
On 04/24/2010 04:46 AM, Avi Kivity wrote:
On 04/23/2010 09:29 PM, Anthony Liguori wrote:
Maybe. We'll still have issues. For example, sVirt: if a QMP
command names a labeled resource, the non-libvirt user will have no
way of knowing how to
On 04/23/2010 09:33 PM, Anthony Liguori wrote:
This is a different ambiguity, about the semantic results of the
commands,
where as I'm refering to the execution order. If I look at a libvirt log
file and see a set of JSON commands logged, I want to know that this
ordering
from the logs, was
On 04/25/2010 06:51 AM, Avi Kivity wrote:
It depends on what things you think are important. A lot of
libvirt's complexity is based on the fact that it uses a daemon and
needs to deal with the security implications of that. You don't need
explicit labelling if you don't use a daemon.
I
On 04/23/2010 09:29 PM, Anthony Liguori wrote:
Maybe. We'll still have issues. For example, sVirt: if a QMP
command names a labeled resource, the non-libvirt user will have no
way of knowing how to label it.
This is orthogonal to QMP and has to do strictly with how libvirt
prepares a
On 04/24/2010 04:46 AM, Avi Kivity wrote:
On 04/23/2010 09:29 PM, Anthony Liguori wrote:
Maybe. We'll still have issues. For example, sVirt: if a QMP
command names a labeled resource, the non-libvirt user will have no
way of knowing how to label it.
This is orthogonal to QMP and has to do
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:45:27PM -0500, Anthony Liguori wrote:
On 04/09/2010 09:27 AM, Daniel P. Berrange wrote:
On Fri, Apr 09, 2010 at 09:41:39AM -0400, Chris Lalancette wrote:
domain type='kvm'
namemyguest/name
...
debug
monitorpassthrough/
commandline
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 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 thinks it's still running or anything like that.
Another problem is issuing Monitor commands that could confuse
libvirt's
We need to make libvirt and
On 04/23/2010 05:28 AM, Daniel P. Berrange wrote:
On Thu, Apr 22, 2010 at 01:45:27PM -0500, Anthony Liguori wrote:
On 04/09/2010 09:27 AM, Daniel P. Berrange wrote:
On Fri, Apr 09, 2010 at 09:41:39AM -0400, Chris Lalancette wrote:
domain type='kvm'
namemyguest/name
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 thinks it's still running or anything like that.
Another problem is issuing Monitor commands that could confuse
On Fri, Apr 23, 2010 at 08:40:49AM -0500, Anthony Liguori wrote:
On 04/23/2010 05:28 AM, Daniel P. Berrange wrote:
On Thu, Apr 22, 2010 at 01:45:27PM -0500, Anthony Liguori wrote:
On 04/09/2010 09:27 AM, Daniel P. Berrange wrote:
On Fri, Apr 09, 2010 at 09:41:39AM -0400, Chris
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 thinks it's still running or anything like that.
Another problem
On Fri, Apr 23, 2010 at 08:48:51AM -0500, 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 thinks it's still running or anything like
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
Anthony Liguori anth...@codemonkey.ws writes:
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 thinks it's still running or anything like that.
Another
On 04/23/2010 09:24 AM, 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 thinks it's still
On 04/23/2010 09:21 AM, Daniel P. Berrange wrote:
Say libvirt is running a 'offline core dump' operation. This consists of
us invoking
stop
migrate exec:cat foo.dump
cont
I don't want other debug commands accidentally being issued in between
these steps. These 3 commands are in
On 04/09/2010 09:27 AM, Daniel P. Berrange wrote:
On Fri, Apr 09, 2010 at 09:41:39AM -0400, Chris Lalancette wrote:
Hello,
In response to a lot of the talk of qemud lately on qemu-devel, the
libvirt community would like to put forward a proposal to help enable
debug/advanced options
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
On 04/12/2010 10:20 AM, Luiz Capitulino wrote:
On Fri, 9 Apr 2010 15:27:17 +0100
Daniel P. Berrangeberra...@redhat.com wrote:
On Fri, Apr 09, 2010 at 09:41:39AM -0400, Chris Lalancette wrote:
Hello,
In response to a lot of the talk of qemud lately on qemu-devel, the
libvirt
On 04/22/2010 01:45 PM, Anthony Liguori wrote:
Which in turn, could be embedded as:
domain type='kvm' xmlns:qemu='http://qemu.org/schemas/qemu/1.0'
namemyguest/name
...
qemu:cpudef
nameOperon_G3/name
level5/level
vendorAuthenticAMD/vendor
/qemu:cpudef
/domain
With respect to injecting QMP
On Sun, Apr 11, 2010 at 11:17:38PM +0100, Jamie Lokier wrote:
Richard W.M. Jones wrote:
On Fri, Apr 09, 2010 at 10:06:51PM +0100, Jamie Lokier wrote:
Daniel P. Berrange wrote:
I think this alteration of existing args is fr too complex
fragile,
and way overkill.
Would
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 Sun, Apr 11, 2010 at 11:17:38PM +0100, Jamie Lokier wrote:
Richard W.M. Jones wrote:
On Fri, Apr 09, 2010 at 10:06:51PM +0100, Jamie Lokier wrote:
Daniel P. Berrange wrote:
I think this alteration of existing args is fr too complex
fragile,
and way overkill.
Would
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/12/2010 08:41 AM, Daniel P. Berrange wrote:
I don't think there's much to be gained from having an XML element to
turn on/off use of these APIs. If an app doesn't want to use them, it
can simply not link to libvirt-qemu.so
The reason I wanted to do this was mostly for debug/support
On Mon, Apr 12, 2010 at 09:56:50AM -0400, Chris Lalancette wrote:
On 04/12/2010 08:41 AM, Daniel P. Berrange wrote:
I don't think there's much to be gained from having an XML element to
turn on/off use of these APIs. If an app doesn't want to use them, it
can simply not link to
On Fri, 9 Apr 2010 15:27:17 +0100
Daniel P. Berrange berra...@redhat.com wrote:
On Fri, Apr 09, 2010 at 09:41:39AM -0400, Chris Lalancette wrote:
Hello,
In response to a lot of the talk of qemud lately on qemu-devel, the
libvirt community would like to put forward a proposal to help
On Fri, Apr 09, 2010 at 10:06:51PM +0100, 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
Richard W.M. Jones wrote:
On Fri, Apr 09, 2010 at 10:06:51PM +0100, 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
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
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 matched
arguments in any way that's wanted?
If the
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
59 matches
Mail list logo