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
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
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 Mon, Apr 26, 2010 at 08:13:03AM -0500, Anthony Liguori wrote:
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
On 04/26/2010 04:14 PM, Anthony Liguori wrote:
IOW, libvirt does not run guests as separate users which is why it
needs to deal with security in the first place.
What if one user has multiple guests? isolation is still needed.
Don't confuse a management application's concept of users
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 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: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 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 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 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
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 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 Fri, Apr 09, 2010 at 02:16:06PM -0400, Chris Lalancette wrote:
On 04/09/2010 10:27 AM, Daniel P. Berrange wrote:
Raw access to the qemu monitor will be disabled by default; the
monitorpassthrough/ tag enables the ability to send QMP (or
text, if you are using older qemu) messages
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 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 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 when using various hypervisors. The goals of
this API
On 04/09/2010 10:27 AM, Daniel P. Berrange wrote:
The concept of command line monitor is something that is QEMU specific
and thus is not suitable for the primary XML schema. IMHO, this needs to be
done as a separate schema, linked in via an XML namespace. For example
domain type='kvm'
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 07:41 AM, Chris Lalancette wrote:
Caveats:
3) Application developers will be strongly discouraged from using
this API because of the above 2 issues. To help in this, the
API's will be in a separate library that developers will explicitly
have to link to, and it will have a
49 matches
Mail list logo
